Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Remote" argument support for weblogic.Deployer #20

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

JeanRev
Copy link

@JeanRev JeanRev commented Feb 26, 2015

Hi everyone,

I'm currently using Arquillian on a weblogic instance running on a remote machine (ie. not sharing the file system of the arquillian instance).

To do so, I had to add support for the "-remote" argument to the weblogic.Deployer command, here is the associated branch. This argument is available from at least WLS 9: http://docs.oracle.com/cd/E13222_01/wls/docs90/deployment/wldeployer.html

I also searched for a similar workaround for the full-JMX client (used in the 12.1.2 adapter), but without luck so far (there seems to be no way to upload the application file to the target instance using only JMX).

However, I was able to sucessfuly perform a deployment with the JSR-88 API (used internally by weblogic.Deployer). This API is available at least from WLS 10.3 and permits to easily monitor the deployment progress, so this could be an interesting alternative. If I manage to get a solution working smoothly, would you be interested in a pull request as well?

Thanks,
Jean

*/
// Note: getter-only, setter must be implemented in child classes.
public boolean isRemoteMachine() {
return remoteMachine;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we not assume remoteMachine when adminUrl != localhost|12.7.0.0.1 ?

What harm does it do to use remote even if it's not 100% remote, e.g. some other local ip interface used then 127.0.0.1?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now, I do not see what could possibly go wrong with using -remote also for local deployments (maybe deploying will takes a little while longer)... So yes, this seems a relatively safe assumption to make regarding the adminUrl.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, testing the adminUrl may not always provide a satisfying result if the server is running on the local host but is somehow on a isolated filesystem (eg. if the target server is in a Docker container). In such case, you may want to force the remoteMachine flag as well.

If we want to make the handling of this flag more transparent to the end-user, I would suggest that we either:

  • Test for the adminUrl first and then fallback to the remoteMachine property.
  • Always enable the "-remote" argument for the remote adapters...

@pzampino
Copy link
Contributor

The REST-based remote adapter should solve the problem addressed by this change.

@rwilco89
Copy link

I'd still like to see the JMX adapter fixed, it's a small change to correct it.

The REST adapter requires a lot more dependencies.
It also appears to have other issues with remote deployments being merged incorrectly.
I have never had this issue with JMX deploys.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants