You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Glen Daniels <gl...@thoughtcraft.com> on 2007/06/08 19:09:38 UTC
[axis2] Architecture question - why ?
Hi folks!
Subj pretty much says it. Why do we have a separate <moduleConfig>
instead of just putting configuration directly inside <module
ref="foo">? This seems needlessly complex, causes extra hashtable
lookups, and I think it's confusing to new users.
Is there a good reason for doing it this way?
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Architecture question - why ?
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Glen Daniels wrote:
> 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).
+1; this is simply a choice of the module author which must be
appropriately documented by them.
I think you meant <service><property name="..">.
> 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:
>
> <service>
> <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.
+1; seems cleaner to me.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Architecture question - why ?
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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:
<service>
<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.
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Architecture question - why ?
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Glen,
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.
We can not add those inside <module ref="foo"> , since we could engage
that for globally and we need to configure them service level.
Thanks
Deepal
Glen Daniels wrote:
> Hi folks!
>
> Subj pretty much says it. Why do we have a separate <moduleConfig>
> instead of just putting configuration directly inside <module
> ref="foo">? This seems needlessly complex, causes extra hashtable
> lookups, and I think it's confusing to new users.
>
> Is there a good reason for doing it this way?
>
> Thanks,
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
--
Thanks,
Deepal
................................................................
"The highest tower is built one brick at a time"
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Rampart download links
Posted by George Stanchev <Gs...@serena.com>.
I think the download links are messed up:
On
http://ws.apache.org/axis2/modules/index.html
In the "Rampart" table row, column "Download"
All the links there ("Distro zip", "MD5", "PGP")
are pointing to the rampart 1.1 release:
[Distro zip]
http://www.apache.org/dyn/mirrors/mirrors.cgi/ws/rampart/1_1/rampart-1.1
.zip
[MD5]
http://www.apache.org/dyn/mirrors/mirrors.cgi/ws/rampart/1_1/rampart-1.1
.zip.md5
[PGP]http://www.apache.org/dyn/mirrors/mirrors.cgi/ws/rampart/1_1/rampar
t-1.1.zip.asc
You might want to fix this.
George
**********************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
**********************************************************************
Rampart download links
Posted by George Stanchev <Gs...@serena.com>.
I think the download links are messed up:
On
http://ws.apache.org/axis2/modules/index.html
In the "Rampart" table row, column "Download"
All the links there ("Distro zip", "MD5", "PGP")
are pointing to the rampart 1.1 release:
[Distro zip]
http://www.apache.org/dyn/mirrors/mirrors.cgi/ws/rampart/1_1/rampart-1.1
.zip
[MD5]
http://www.apache.org/dyn/mirrors/mirrors.cgi/ws/rampart/1_1/rampart-1.1
.zip.md5
[PGP]http://www.apache.org/dyn/mirrors/mirrors.cgi/ws/rampart/1_1/rampar
t-1.1.zip.asc
You might want to fix this.
George
**********************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org