axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepal Jayasinghe <>
Subject Re: [axis2] refactoring deployment config configurators
Date Wed, 05 Apr 2006 11:06:54 GMT
I hope we have to do these changes for 1.0 release.

Is that OK if I assume the changing is just adding two more
AxisConfigurators and there wont be any changes to FileSystemConfigurator :)

I'm +1 on adding the URL based repository support to Axis2.

Sanjiva Weerawarana wrote:

>Currently we have a file system based configurator for creating config
>contexts which loads up axis2.xml and does various things. Unfortunately
>its doing a bit more than what its name advertises. Here's a refactoring
>that cleans stuff up properly:
>- create a new configurator called the ClassPathConfigurator which works
>as follows:
>	- finds the default axis2.xml from the classpath
>	- finds modules from the classpath
>	- no services deployed by the configurator: so this is primarily for
>stand-alone client scenarios
>NOTE: This is basically how our client side works now. The idea is to
>move the code to a specific configurator to clean up the pieces.
>- create a configurator called URLConfigurator which works as follows:
>	- constructor takes a URL to the axis2.xml file (or whatever the
>name .. basically the URL of a resource which has axis2.xml stuff)
>		- if the URL is null, then a default axis2.xml is loaded from the
>classpath (as above)
>		[This may seems a bit weird, but its designed to make the simple case
>simple: in many cases there's no need to change the default axis2.xml.]
>	- configurator has a method called loadRepository which takes a URL to
>the repository
>		- if the URL is a file: URL, then we treat that as we do now and load
>the stuff off the file system .. and support hot deployment etc.
>		- if the URL is another kind of URL, then we assume the shape of the
>repository pointed to is as follows:
>	.../
>		services/
>			services.list
>			service1.aar
>			service2.aar
>			...
>		modules/
>			modules.list
>			module1.mar
>			module2.mar
>			...
>		- Note that we need the services.list and modules.list files because
>there's no way to generically get a list of stuff from a URL to a
>directory. (And no, we're not going to do screen scraping.)
>		- The services.list and modules.list files are simply naming the .aar
>and .mar files respectively one per line. 
>This is basically a small cleanup ..

~Future is Open~ 

View raw message