axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject [axis2] proposal for restructuring the packaging a bit
Date Mon, 16 Jan 2006 16:59:42 GMT
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.


Mime
View raw message