axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruchith Fernando <>
Subject Re: [axis2] proposal for restructuring the packaging a bit
Date Wed, 18 Jan 2006 10:40:04 GMT
Definitely a +1 .


On 1/16/06, Sanjiva Weerawarana <> wrote:
> We currently package a default axis.xml in the jar file and have a model
> where we create a .axis directory in the user's home dir and do some
> copying of stuff. That's a non scalable plan and leads to version issues
> too (old modules etc.). A proposal to clean this up follows:
> - Use AXIS2_HOME as the environment var to point to the installation
> directory of the Axis2 distribution. The batch and shell scripts can try
> to infer this and if it can't then it'll catch fire and die (like most
> startup scripts for servers).
> - Use AXIS2_REPOSITORY for the repository directory. This is the directory
> that contains the "modules" and "services" folders (as well as possibly
> the shared lib folder). This, by default, lives inside the AXIS2_HOME
> but the user may point it elsewhere. In the default server startup using
> the scripts, the user does not have to set this variable to point to a
> repository because it will default to $AXIS2_HOME/repository.
> These two variables will be propagated into the world of Java using Java
> properties. For the case of AXIS2_HOME, the world of Java never needs
> the entire home - what it needs is the location of the axis2
> configuration file: axis2.xml (which is $AXIS2_HOME/conf/axis2.xml).
> Therefore, we pass just that into Java using the property name
> "org.apache.axis2.configuration". The value of this property is a URL,
> thereby allowing the file to be remote even.
> The AXIS2_REPOSITORY will be passed into Java using the property
> "org.apache.axis2.repository", which too is URL valued, thereby allowing
> the repository to be remote event.
> Ain't that cool?
> So, the full result of the AXIS2_HOME directory structure is:
>   axis2-VERSION/
>     lib/
>       .. axis2 jars, dependent jars etc. ..
>     bin/
>       .. the scripts ..
>     conf/
>       axis2.xml
>     logs/
>       .. log files ..
>     repository/
>       modules/
>         .. mar files ..
>         lib/
>           .. libs shared across the mars ..
>       services/
>         .. aar files ..
>         lib/
>           .. libs shared across the aars ..
>       lib/
>         .. libs shared across services and modules ..
> Notice that the same structure is present on both client and server side
> scenarios. However, to make the trivial client case (of just having the
> jar files and writing a client) easy, we will include in
> axis2-core-VERSION.jar, a default configuration called axis2-default.xml
> which will get picked up if no configuration URL is provided via the
> property described above. However, we will not copy that default
> configuration anywhere - it will simply get used and that's it. (This is
> unlike the current model where we do copy it into .axis2.)
> Note that in the case of the webapp, the appropriate parts of the file
> hierarchy described above will appear inside the WEB-INF directory. Of
> course the "bin" directory will be missing as that only applies to
> non-Webapp scenarios. The "logs" directory will also not appear because
> those will appear outside somewhere (depending on the servlet's
> container's configuration). Thus, the packaging hierarchy will be:
>   axis2-VERSION/
>     WEB-INF/
>       lib/
>         .. axis2 jars, dependent jars etc. ..
>       conf/
>         axis2.xml
>       repository/
>         modules/
>           .. mar files ..
>           lib/
>             .. libs shared across the mars ..
>         services/
>           .. aar files ..
>           lib/
>             .. libs shared across the aars ..
>         lib/
>           .. libs shared across services and modules ..
> In order to avoid the problem we had with the 0.94 release, future
> axis2-default.xml configurations will not have addressing enabled.
> However, the axis2.xml that ships with all the releases (in the conf/
> directory as shown above) will have addressing enabled because the
> addressing mar will be in the modules directory.
> The motivation for this review and change was the boo-boo with 0.94 not
> including address.mar in the jar .. so this proposal which basically
> attempts to solve the problem we were solving earlier without having to
> put mars in jars (or cars in buses, which would be equally unhealthy).
> Thoughts please ..
> Sanjiva.

View raw message