Adding profile for WebLogic
arjantijms opened this issue · 7 comments
Oracle will at some time in the (hopefully near) future release their Java EE 7 version of WebLogic.
I've locally prepared a configuration for WebLogic based on the Arquillian WebLogic remote 12.1.2 container (http://arquillian.org/modules/arquillian-wls-remote-12.1.2-container-adapter) and I've got it on good authority that it works with the work in progress EE 7 version of WebLogic.
Unfortunately, the profile is a little bit elaborate to use. Even though it's a remote profile, it requires a specific WebLogic library to be installed in a local Maven repository AND it needs a reference to the filesystem path where WebLogic is installed.
How to best handle this?
Just put a dummy path in the configuration file (arquillian.xml) in this case, or put a path there that is ideal for the Java EE samples server, or externalize the setting to a separate .properties file that's not under version control?
And how to best handle the requirement for a WebLogic library to be locally installed in Maven? Just document it?
Thoughts about this?
Arjan, that was on my radar as well. We were experimenting with that during hackergarten in Gdańsk - not very successfully.
Likewise, I had Arquillian working with WebLogic 12.1.3 for some of my projects and I fully agree - it was a bit pain to start. If I remember correctly no proprietary Maven library was needed, but the arquillian.xml was verbose with the local path - indeed - required. However, the path is required for deployment libraries, not to actually place the artifacts.
The weblogic-maven-plugin was used for deployments but it wasn't related with Arquillian itself.
Anyway, for the project I was extensively using docker (https://github.com/weblogic-community/weblogic-docker) and that was initial idea here: point users to this repository, provide manual on installing and assume weblogic running (say under weblogic name, somewhere in the background). After that we would be able to run the whole suit in a second container referencing hosts (--link) and paths (--volumes-from).
Due to licensing restrictions we cannot redistribute WebLogic,neither it can be in the maven repository. I was thinking that this might be the lease intrusive way. Additionally, that will limit the external dependencies to Docker ('just' ;-)) but should make the build pretty repeatable - which is the aim of this showcase project after all.
But as I said - that was just a though and maybe we will try that approach during the next hackergarten.
However, the path is required for deployment libraries, not to actually place the artifacts.
With the latest version of the Arquillian container it's unfortunately needed. It uses the t3 protocol to communicate with the remote server, and this URL protocol needs to be placed on the classpath, for which you need a library. Once everything is setup, the tests run fine (I did only run the JASPIC tests though, which are my main area of interest).
I personally contributed to this container (see commit log ;)) and we worked together with Oracle engineer YY Snyder (who provided most of the code). We briefly discussed how to make this all easier for a next version of the Arquillian WLS container, but didn't proceed since then.
Due to licensing restrictions we cannot redistribute WebLogic
Of course, but it can be used for development and evaluation purposes. Installing it locally on your own server is not distribution. And for running the tests no access to the installed server has to be given to any (public) user.
I also did not mean to install the WebLogic lib in any public Maven repo. It just needs to be installed in a local Maven repo (which likely is on the same machine where WebLogic itself is installed) so Arun can run the tests on his Jenkins server (which used to be here btw, but is now gone: https://javaee-support.ci.cloudbees.com/)
I think we do have to ask Oracle if this is indeed allowed, but I think IBM Liberty was also tested this way before it was free for usage in small instances (not sure though).
Other users who want to run the tests on WebLogic simply have to install WebLogic themselves locally and point aruillian.xml to it.
With the latest version of the Arquillian container it's unfortunately needed.
Didn't. I was using 1.1.5.Final and don't recon any problems - but my memory might fail me here.
As in this project https://github.com/kubamarchwicki/weblogic-producers - I had some issues with @produces annotation on WLS
Of course, but it can be used for development and evaluation purposes. Installing it locally on your own server is not distribution.
Sure. Though, no matter how containers will be provided it will never be as smooth process as with other app servers - a number of manual steps will be required.
Because one thing is running tests on Jenkins but I often see people use this project as a guidance how to actually run Arquillian against particular servers (a reference as the configuration can be sometime trouble some). I was more referring to the latter.
Ideally I would see no need to change the arquillian.xml, when running with a container of our choice. That would keep the approach consistent with other servers (which more or less just works). This container approach is still on my backlog. But as I said, that was my only idea and I'm note sure if I'm not overcomplicating things
Didn't. I was using 1.1.5.Final and don't recon any problems - but my memory might fail me here.
Hmmm, we may be talking about different things ;)
I'm referring to this one: http://arquillian.org/modules/arquillian-wls-remote-12.1.2-container-adapter
Part of the code in this container adapter was provided by myself and we had a long discussion with the other authors about it, and a URL handler for the t3 protocol is really needed.
Ok - now it reminds me what I was sticking to http://arquillian.org/modules/arquillian-wls-remote-12.1-container-adapter/ (mind the version) on the latest weblogic.
Not sure about t3 protocal or a different problems made me stick to the older version
The older version is incredibly unstable, unfortunately. It seems to work at first, but then keeps failing intermittently. It uses the deployer command, which doesn't give enough feedback for programmatic usage.
I just did a PR for the profile: #301
As it appeared the mentioned library didn't needed to be added to the pom.xml after all.
The handler for the t3 protocol is of course needed, but the Arquillian container takes care of this via a custom class loader. We though this didn't work before, but the path to the library wasn't entirely correct, and this was silently ignored. I could workaround this via Arquillian.xml, but will look into fixing this in the container itself.