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 ..
>
>Sanjiva.
>
>
>
>  
>

-- 
Thanks,
Deepal
................................................................
~Future is Open~ 


Reply via email to