Installing JBossWS Native on JBAS 5.1.0

[anil.saldhana]

This is my use case part of my automated build :

a) I take a JBossAS 5.1.0.GA zip. Unzip it.

b) I need to install JBossWS native onto it.

Currently, what I see is that I need to download this JBossWS zip. Unzip it and fix an ant.properties file pointing to jboss.home and run an "ant deploy".

As it stands, the JBossWS install is so bloated with multiple directories and jars that in fact could have been replaced by a simple zip that was created for each release of JBAS.

I could then just unzip this install at the base of the JBAS5.1 and get the updated jars.

This is for PicketLink integration tests and the current JBossWS install method is totally not working for me.

Any possibilities of getting a zip that I can just unzip at the base of 5.1?

[anil.saldhana]

Please take this as a feature request.

Stefan just told me that I can use AS5.1 direct to test out the PicketLink STS tests. So I will just use AS5.1 for my integration automated tests.

[asoldano]

JBossWS 3.3.0 has a bug with the installation using the binary distribution, see http://community.jboss.org/message/545991#545991

[asoldano]

A new release is coming next week, including the fix for JBWS-3048: http://lists.jboss.org/pipermail/jbossws-dev/2010-June/002100.html

Regarding the way the installation is performed, simply extracting a zip would now work; one of the reasons is that, depending on the WS/AS versions, some files need to be removed without being overwritten. Hence the requirement for an actual installation script.

[anil.saldhana]

If I need to integration testing with JBossWS, I would prefer to see an ant script that does not have many directories with a lot of duplicated jars and tests/docs etc. What you guys were doing is packaging your maven/ant build scripts as install scripts.

The requirement is very simple - provide the least painful means to install the latest version of JBossWS on to an existing AS install.

[asoldano]

ANIL SALDHANA wrote:

If I need to integration testing with JBossWS, I would prefer to see an ant script that does not have many directories with a lot of duplicated jars and tests/docs etc.

which duplicated jars? The only things I see that might seem "duplicated" (but actually are not) are the container integration related directories (deploy/resources/jbossws-jbossXYZ). Of course just one of them is used, depending on the selected target container.

The requirement is very simple - provide the least painful means to install the latest version of JBossWS on to an existing AS install.

We do run integration testing using the binary distribution every night. We had an issue with 3.3.0 testing that went un-noticed (the reason being the hudson job not starting from a clean AS at every binary distribution installation), but that problem with testing is being resolved, while the actual issue in the distribution is fixed in 3.3.1 (available since yesterday).

Besides that, installing the binary distribution for integration testing is really a matter of 2 commands:

cp ant.properties.example ant.properties
ant -Djboss510.home=/home/alessio/jboss-5.1.0.GA -Djbossws.integration.target=jboss510 deploy-jboss51

.. assuming you're using AS 5.1.0. Please note the contents in ant.properties are overwritten by the env props you provide to ant, so you don't need to edit ant.properties in a automatic job running the tests.

If that really hurts, we can even try avoiding enforcing the copy of ant.properties.example when env props are provided. The rest does not seem that painfull to me.

The script removes what needs to be removed from the AS and copies what needs to be copied.

[anil.saldhana]

I am wondering if you are able to provide a zip with each release of JBossWS, that I can just plug into my integration test workspace.  Before the test startup, I want to unzip this jbossws distribution on a stock AS 5.1, to get everything replaced (that needs to be replaced) for the new stack to be running on AS5.1

If we have to certify PicketLink STS to run against JBossWS stacks, we need the zips.

[asoldano]

Sorry, as I said previously, that's not possible. Let's forget for now that we'd have to provide 3 (stacks) * 3 (supported target containers) = 9 additional zips for each release; depending on the jbossws and application server versions, there're some files that are just to be delated, not replaced. So, again, just expanding a zip is not going to work. We provide an installation script (which can be run with just 2 commands) because there's need for that.

Just as an example, installing 3.3.1 on AS 5.1.0 implies removing the following files:

client: jbossws-jboss50.jar
client: jbossws-native-jaxrpc.jar
client: jbossws-native-jaxws.jar
client: jbossws-native-saaj.jar
common/lib: jbossws-native-jaxrpc.jar
common/lib: jbossws-native-jaxws.jar
common/lib: jbossws-native-saaj.jar
server/default/deploy: jbossws.sar
server/default/deployers/jbossws.deployer: FastInfoset.jar
server/default/deployers/jbossws.deployer: jboss-jaxb-intros.jar
server/default/deployers/jbossws.deployer: jbossws-common.jar
server/default/deployers/jbossws.deployer: jbossws-framework.jar
server/default/deployers/jbossws.deployer: jbossws-jboss50.jar
server/default/deployers/jbossws.deployer: jbossws-native-core.jar
server/default/deployers/jbossws.deployer: jettison.jar
server/default/deployers/jbossws.deployer/META-INF: jboss-beans.xml
server/default/deployers/jbossws.deployer/META-INF: jbossws-deployer-jboss-beans.xml
server/default/deployers/jbossws.deployer/META-INF: standard-jaxrpc-client-config.xml
server/default/deployers/jbossws.deployer/META-INF: standard-jaxrpc-endpoint-config.xml
server/default/deployers/jbossws.deployer/META-INF: standard-jaxws-client-config.xml
server/default/deployers/jbossws.deployer/META-INF: standard-jaxws-endpoint-config.xml
server/default/deployers/jbossws.deployer: policy.jar
server/default/deployers/jbossws.deployer: wsdl4j.jar
server/default/deployers/jbossws.deployer: xmlsec.jar

In case you're going to ask me why the files above need to be removed, as an example the jbossws-native-jaxrpc, jbossws-native-jaxws and jbossws-native-saaj jars do not exist anymore in JBWS 3.3.x, so leaving those there would basically break the installation.

[anil.saldhana]

At this time, for PicketLink integration test suite, we use JBAS 5.1.0 in a zip form that we extract few times before the tests. The JBossWS installation in current form is not usable for our build (I already looked into it).  I am repeating again, that it is a bloated distribution. You need to listen to your end users.

Look at our downloads for PicketLink:  http://jboss.org/picketlink/downloads.html

We do all the hard work for our users.

All I require is the following:

1. The bare distribution of jars/xml DD etc in a zip/tar format that I can use for AS 5.1
2. If there is a list of jars that I need to remove from the AS 5.1 distribution after the unzip, I can incorporate that into my build for "post-install".

But I cannot accept the installation process that you have for JBossWS at this time.

[anil.saldhana]

Alessio, Stefan and I are discussing how we can solve this long term.  Maybe PicketLink has to figure out a way to do JBossWS install.