axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ajith Ranabahu <>
Subject Re: [axis2] proposal for restructuring the packaging a bit
Date Tue, 17 Jan 2006 10:23:10 GMT
Hi all,
This seems quite ok.

- 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 flexibilty of having two parameters, one to specify the home and the
other pointing to the repository is nice since the users can keep the lib
and the the repo's seperately. Having a remote repo is a cool idea too.

> 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.)

This structure  is fine ,specially the  addition of the  repository
directory back is a good move. (This dir was removed and caused all kinds of
messy errors in the scripts last time). However we also need to put the
tools jar back into the dist. Users need to have the Axis2 ant task.

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).

It seems that this is a better way to distribute the mars. as soon as we
take the mar out we have the flexibilty of updating the mar ;)

Thoughts please ..
> Sanjiva.

Overall this proposal seems quite ok for me.

Ajith Ranabahu

View raw message