Definitely a +1 . Thanks, Ruchith
On 1/16/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> 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. > >
