+1 from me. -- dims
On 1/17/06, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: > > 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 ? > > Thanks, > Deepal > ................................................................ > ~Future is Open~ > > > ----- Original Message ----- > From: Ajith Ranabahu > To: [email protected] > 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-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 -- Davanum Srinivas : http://wso2.com/blogs/
