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.
