axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject Re: [axis2] Architecture question - why <moduleConfig>?
Date Sun, 10 Jun 2007 21:06:36 GMT
Hi Deepal!

Deepal Jayasinghe wrote:
> The main idea of introducing that was to provide module related data
> from services . Say for an instance we engage module called "foo"
> globally by putting <module ref="foo"> in axis2.xml . And let's say that
> module to be work every service needs provide some kind of data , then
> those data can be added in side that.

I see two situations here.  In the first, the Module explicitly knows 
that it wants data from the active AxisService that is relevant to its 
operation.  So the Module in this case should ensure that it runs after 
dispatch has occurred, and IMO it should just pull this configuration 
information out of the AxisService properties 
(mc.getService().getProperty("myModule.shoeSize") in the code and 
<service><parameter name="myModule.shoeSize"> in the XML).

In the second situation, the service wants to make sure the module is 
engaged and configured in a particular way, without the module caring 
whether it gets these params from the service or not.  In this case, I 
don't see any reason it couldn't do:

  <module ref="myModule">
   <parameter name="shoeSize">

This assumes (reasonably, I think) that it's fine for a Service to 
engage a module that's already engaged globally.  More generally, it's 
fine for any AxisDescription to engage a module that's already active at 
a higher level.  The question comes up though whether they should be 
able to override the parameter settings - this is really a configuration 
choice, since in some situations you DO want to be able to override 
defaults, and in other situations the global deployer is setting 
site-wide policies that should NOT be changeable.  Good use case for 
locked parameters....

The net is that I still don't see a need to introduce a separate 
<moduleConfig> structure, since we can handle the use-case you describe 
with either of the (simpler, I think) patterns above.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message