#298 Added Maven profile for WebLogic

[arjantijms]

No description provided.

[kubamarchwicki]

Hi Arjan,
I was trying to run it locally, but failed.

No matter how I try (or with which project) I keep getting a following error

Caused by: javax.management.RuntimeMBeanException: java.lang.RuntimeException: 
    [Deployer:149003]Unable to access application source information in 
    "/tmp/arquillian5857872175899783504test.war/test.war" for application "test". 
    The specific error is: No application files exist.

I'm running my weblogic in docker container and I started to wonder if that might be that case. I'll follow it up on arq issues, but (as you wrote at some point) you coauthored this particular arquillian container - maybe you've come across smth similar.

The previous version of container (arquillian-wls-remote-12.1) works fine. Any clue?

Nonetheless looks solid, if smb (maybe @buttso) can give it a try - we should be merging it. I suspect my problem is rather local.

--Kuba

[arjantijms]

That's indeed a peculiar error. I tested the profile on two different systems; OS X and Ubuntu. Additionally I asked someone from Oracle to try and verify it, and she mentioned it worked as well.

There was one change though, and that concerned the JMX client library. First wlthint3client.jar was used by setting it as a Maven dependency, but later this was changed (back) to wljmxclient.jar that the arquillian container uses internally via a custom classloader (we overlooked a part of the path earlier and it failed silently).

If WebLogic is in a docker container, does that mean you changed the admin url from t3://localhost:7001 to something else? My guess would be that the JMX deployer doesn't accept truly remote connections, but only ones coming from the same host.

In my experience arquillian-wls-remote-12.1 only seems to work correctly, but unfortunately after running more tests it fails intermittently.

[arjantijms]

@kubamarchwicki @arun-gupta anyone tried a "regular" (local/non-docker) install yet?

[arun-gupta]

@m-reza-rahman might have a few WebLogic installations on his machine and should be able to try it.

[buttso]

I'd been looking at this myself recently based on a Docker test environment that I was using.

I think the issue here is that the adapter that uses the JMX API is unable to copy the file from the dev environment into a remote server environment so that it can then be deployed from the AdminServer. The JMX API can perform a deployment operation, which is why it works when the dev/test environments are co-located, but it appears to have no way to also perform the archive upload required to perform a true remote deployment. For the Docker case, this reflects a local/remote setup since there is no shared file system from which to deploy the application (unless you specifically set the Docker/host up that way).

I'm still getting it confirmed but that's my understanding of what is happening.

The adapters that use the weblogic.Deployer utility (or underlying class directly) can perform a remote deployment since it has an option that uploads the archive to the remote server as part of the deployment process.

[kubamarchwicki]

That's an interesting path. When I run my wls with -v /tmp:/tmp I got a different exception

org.jboss.arquillian.container.spi.client.container.DeploymentException: Failed to populate the HTTPContext with the deployment details
    at  at org.jboss.arquillian.container.wls.WebLogicJMXClient.deploy(WebLogicJMXClient.java:98)
    at org.jboss.arquillian.container.wls.jmx.FullJMXRemoteContainer.deploy(FullJMXRemoteContainer.java:62)
    at org.jboss.arquillian.container.wls.remote_12_1_2.WebLogicContainer.deploy(WebLogicContainer.java:61)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
    org.jboss.arquillian.container.wls.WebLogicJMXClient.verifyDeployment(WebLogicJMXClient.java:119)
        [...]
Caused by: org.jboss.arquillian.container.spi.client.container.DeploymentException: An unexpected condition was encountered. The HTTPContext could not be created.
    at org.jboss.arquillian.container.wls.HttpContextBuilder.createContext(HttpContextBuilder.java:98)
    at org.jboss.arquillian.container.wls.WebLogicJMXClient.verifyDeployment(WebLogicJMXClient.java:116)

Anyway - I've risen this issue: arquillian/arquillian-container-wls#21 as more relevant :-) will see how it gets

[arjantijms]

@kubamarchwicki @buttso Those are surely good points to look at for the Arquillian container in general. I have some small fixes queued up first (the missing "wlserver" part of the path for instance), but if no one else looks at this first I can take a look later.

As for now the "remote" profile for the Java EE 7 samples project for WebLogic does assume both tests and server run on the same host. This is incidentally the same assumption the Liberty profile makes. There, setting up the profile to be truly remote would necessitate setting up a rather nasty and involved SSL configuration.

So what do you think, can this PR be accepted?

[kubamarchwicki]

Squashed and merged. Thx - I'll followup on the discussion about remote-wls container where needed :)