axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepal Jayasinghe" <>
Subject Re: [axis2] proposal for restructuring the packaging a bit
Date Tue, 17 Jan 2006 10:39:36 GMT
Hi all;

I am big +1 for this approach.

At the Apache con axis2 user came with this kind idea (he had a chat with me after the Axis2
tutorial), so if we can implement this proposal then deployment architecture gives us more
flexible axis2 system. With this approach ur axis2.xml should not be in the repository that
can be in some other country if you want.

so shall I go ahead and implement that ?

~Future is Open~

  ----- Original Message ----- 
  From: Ajith Ranabahu 
  Sent: Tuesday, January 17, 2006 4:23 PM
  Subject: Re: [axis2] proposal for restructuring the packaging a bit

  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 jars, dependent jars etc. ..
          .. the scripts ..
          .. log files ..
            .. mar files .. 
              .. libs shared across the mars ..
            .. aar files ..
              .. libs shared across the aars ..
            .. 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 jars, dependent jars etc. ..
              .. mar files ..
                .. libs shared across the mars ..
              .. aar files ..
                .. libs shared across the aars ..
              .. 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 .. 


  Overall this proposal seems quite ok for me. 

  Ajith Ranabahu 
View raw message