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 Ruchith Fernando <ru...@gmail.com> on 2007/08/09 13:53:28 UTC
Re: [axis2] Re: svn commit: r559011 - in /webservices/axis2/trunk/java/modules: addressing/src/META-INF/ integration/conf/ integration/test-resources/deployment/ integration/test-resources/mtom/ integration/test-resources/swa/ integration/test/org/ap
Apologies for jumping in late! Please see my comments below:
On 7/30/07, David Illsley <da...@gmail.com> wrote:
> Ah, the perrenial ws-sec+ws-a problem.
> This is a really complex issue, and unfortunately I don't think it can
> be resolved this simply i.e. what happens if security rejects the ws-a
> headers as invalid? There isn't any code to roll-back the ws-a related
> fields in the message context, so suddenly one of the main reasons to
> require signed ws-a headers (preventing your server from being used to
> DoS via ReplyTo) is bypassed.
>
> I think we probably need to split the addressing processing itself
> into 2 parts - the first which provides a guess of the AxisOperation
> based onthe To/Action/RelatesTo and the second which does the full
> ws-a processing (afer the security handler).
I'm trying to understand the various placements of the addressing
dispatcher and its affect on the DoS attack that David mentioned.
Please correct me if I have missed something.
With the addressing dispatcher running before the security handler
- An attacker changes the signed ReplyTo header of a message to a service
- Addressing handled extracts this information and addressing
dispatcher finds the operation.
- Signature verification fails and the fault is sent to the *changed*
ReplyTo address
Now with David's proposal (The way I understood it) the earlier three
steps happen anyway ... its true that the fault is sent to the changed
ReplyTo but the message never reaches the service in either case.
Now ... In case of a aync message invocation, even if we do *not* do
any addressing processing/dispatch before security processing when
signature verification fails due to someone modifying an addressing
header we will not be able to send an asyc response anyway, since at
the point where processing fails we do not know the ReplyTo address.
David can you please explain how the DoS attack happen with the
current approach and how it can be prevented by splitting addressing
based dispatching?
Thanks,
Ruchith
>
> Do you have a list of use-cases you're trying to support?
> David
>
> On 27/07/07, Deepal jayasinghe <de...@gmail.com> wrote:
> > In the case of WS-Security there are instance that the only way to
> > dispatch is using addressing , and service and operation must be found
> > before running the security handlers. If you take transport like SMTP
> > the only way to dispatch is using addressing so we need to run
> > addressing before security.
> >
> > May be Ruchith can add some more infor into this.
> >
> > Thanks
> > Deepal
> > > Um deepal, can you explain why we should have the
> > > AddressingBased*Dispatcher* running before the *Dispatch* phase?
> > > Thanks,
> > > David
> > >
> > > On 25/07/07, Deepal jayasinghe <de...@gmail.com> wrote:
> > >
> > >> Hi Glen,
> > >> Yes I have to agree with you , but let's do that for next release. I
> > >> would like to consider that as the first item to be fixed.
> > >>
> > >> Thanks
> > >> Deepal
> > >>
> > >>> [Forward with correct prefix]
> > >>>
> > >>> Gosh. If only Modules ...
> > >>>
> > >>> http://marc.info/?l=axis-dev&m=118117804705440&w=2
> > >>>
> > >>> ... could define their own Phases
> > >>>
> > >>> http://marc.info/?l=axis-dev&m=114404998012486&w=2
> > >>>
> > >>> this commit could have consisted of a simple change to the Addressing
> > >>> module's module.xml, and that would basically be it. This demonstrates,
> > >>> once again, exactly the problem with the current overly-static design.
> > >>>
> > >>> I still stand by the position I wrote up last year:
> > >>>
> > >>> http://marc.info/?l=axis-dev&m=114417377917696&w=2
> > >>>
> > >>> This needs to be fixed after 1.3, folks.
> > >>>
> > >>> --Glen
> > >>>
> > >>>
> > >>> deepal@apache.org wrote:
> > >>>
> > >>>> Author: deepal
> > >>>> Date: Tue Jul 24 04:41:00 2007
> > >>>> New Revision: 559011
> > >>>>
> > >>>> URL: http://svn.apache.org/viewvc?view=rev&rev=559011
> > >>>> Log:
> > >>>> -Add a phase called Addressing as I mentioned in the mailing list -
> > >>>> Move all the addressing handlers into Addressing phase
> > >>>> - Had to modify a set of axis2.xml and test cases to cope this chang
> > >>>>
> > >>>> [This is a big commit but no need to worry :) ]
> > >>>>
> > >>>> Modified:
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/addressing/src/META-INF/module.xml
> > >>>> webservices/axis2/trunk/java/modules/integration/conf/axis2.xml
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/deployment/deployment.both.axis2.xml
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/mtom/MTOM-enabled-axis2.xml
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/mtom/MTOM-fileCache-enabled-axis2.xml
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/swa/SwA-enabled-axis2.xml
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/swa/SwA-fileCache-enabled-axis2.xml
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/HandlerExecutionTest.java
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/chunking-disabled-axis2.xml
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/chunking-enabled-axis2.xml
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/commons-http-enabled-axis2.xml
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/jms/jms-enabled-client-axis2.xml
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/jms/jms-enabled-server-axis2.xml
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/mail/mail-enabled-axis2.xml
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/mail/mail-enabled-client-axis2.xml
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/mail/mail-enabled-server-axis2.xml
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/kernel/conf/axis2.xml
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/deployment/axis2_default.xml
> > >>>>
> > >>>>
> > >>>> webservices/axis2/trunk/java/modules/kernel/test/org/apache/axis2/deployment/ModuleDisengagementTest.java
> > >>>>
> > >>>>
> > >>>>
> > >> ---------------------------------------------------------------------
> > >> 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
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
www.ruchith.org
www.wso2.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Re: svn commit: r559011 - in /webservices/axis2/trunk/java/modules: addressing/src/META-INF/ integration/conf/ integration/test-resources/deployment/ integration/test-resources/mtom/ integration/test-resources/swa/ integration/test/org/ap
Posted by Ruchith Fernando <ru...@gmail.com>.
Got it! :-)
Thanks for the explanation David.
- Ruchith
On 8/9/07, David Illsley <da...@gmail.com> wrote:
> The DoS is not against the service itself, but using the service to
> send messages to a victim indirectly. To prevent the use of your
> server in this way, the suggestion from the WS-A group is to require
> the ReplyTo is signed. However, given that we populate the ReplyTo
> field before the security handler now, Axis2+Rampart users get no such
> protection because when Rampart throws an exception, a fault will be
> sent to the victim, not the originator of the request message.
>
> Given that we don't have (and I see no appetite for) roll-back-able
> handlers, the solution I see is to split the reading of the addressing
> headers into 2. Part that runs before security and part that runs
> after. That way, anything which is security-sensitive (like ReplyTo
> processing) can run after security validation.
>
> Cheers,
> David
>
> On 09/08/07, Ruchith Fernando <ru...@gmail.com> wrote:
> > Apologies for jumping in late! Please see my comments below:
> >
> > On 7/30/07, David Illsley <da...@gmail.com> wrote:
> > > Ah, the perrenial ws-sec+ws-a problem.
> > > This is a really complex issue, and unfortunately I don't think it can
> > > be resolved this simply i.e. what happens if security rejects the ws-a
> > > headers as invalid? There isn't any code to roll-back the ws-a related
> > > fields in the message context, so suddenly one of the main reasons to
> > > require signed ws-a headers (preventing your server from being used to
> > > DoS via ReplyTo) is bypassed.
> > >
> > > I think we probably need to split the addressing processing itself
> > > into 2 parts - the first which provides a guess of the AxisOperation
> > > based onthe To/Action/RelatesTo and the second which does the full
> > > ws-a processing (afer the security handler).
> >
> > I'm trying to understand the various placements of the addressing
> > dispatcher and its affect on the DoS attack that David mentioned.
> > Please correct me if I have missed something.
> >
> > With the addressing dispatcher running before the security handler
> > - An attacker changes the signed ReplyTo header of a message to a service
> > - Addressing handled extracts this information and addressing
> > dispatcher finds the operation.
> > - Signature verification fails and the fault is sent to the *changed*
> > ReplyTo address
> >
> > Now with David's proposal (The way I understood it) the earlier three
> > steps happen anyway ... its true that the fault is sent to the changed
> > ReplyTo but the message never reaches the service in either case.
> >
> > Now ... In case of a aync message invocation, even if we do *not* do
> > any addressing processing/dispatch before security processing when
> > signature verification fails due to someone modifying an addressing
> > header we will not be able to send an asyc response anyway, since at
> > the point where processing fails we do not know the ReplyTo address.
> >
> > David can you please explain how the DoS attack happen with the
> > current approach and how it can be prevented by splitting addressing
> > based dispatching?
> >
> > Thanks,
> > Ruchith
> >
> > >
> > > Do you have a list of use-cases you're trying to support?
> > > David
> > >
> > > On 27/07/07, Deepal jayasinghe <de...@gmail.com> wrote:
> > > > In the case of WS-Security there are instance that the only way to
> > > > dispatch is using addressing , and service and operation must be found
> > > > before running the security handlers. If you take transport like SMTP
> > > > the only way to dispatch is using addressing so we need to run
> > > > addressing before security.
> > > >
> > > > May be Ruchith can add some more infor into this.
> > > >
> > > > Thanks
> > > > Deepal
> > > > > Um deepal, can you explain why we should have the
> > > > > AddressingBased*Dispatcher* running before the *Dispatch* phase?
> > > > > Thanks,
> > > > > David
> > > > >
> > > > > On 25/07/07, Deepal jayasinghe <de...@gmail.com> wrote:
> > > > >
> > > > >> Hi Glen,
> > > > >> Yes I have to agree with you , but let's do that for next release. I
> > > > >> would like to consider that as the first item to be fixed.
> > > > >>
> > > > >> Thanks
> > > > >> Deepal
> > > > >>
> > > > >>> [Forward with correct prefix]
> > > > >>>
> > > > >>> Gosh. If only Modules ...
> > > > >>>
> > > > >>> http://marc.info/?l=axis-dev&m=118117804705440&w=2
> > > > >>>
> > > > >>> ... could define their own Phases
> > > > >>>
> > > > >>> http://marc.info/?l=axis-dev&m=114404998012486&w=2
> > > > >>>
> > > > >>> this commit could have consisted of a simple change to the Addressing
> > > > >>> module's module.xml, and that would basically be it. This demonstrates,
> > > > >>> once again, exactly the problem with the current overly-static design.
> > > > >>>
> > > > >>> I still stand by the position I wrote up last year:
> > > > >>>
> > > > >>> http://marc.info/?l=axis-dev&m=114417377917696&w=2
> > > > >>>
> > > > >>> This needs to be fixed after 1.3, folks.
> > > > >>>
> > > > >>> --Glen
> > > > >>>
> > > > >>>
> > > > >>> deepal@apache.org wrote:
> > > > >>>
> > > > >>>> Author: deepal
> > > > >>>> Date: Tue Jul 24 04:41:00 2007
> > > > >>>> New Revision: 559011
> > > > >>>>
> > > > >>>> URL: http://svn.apache.org/viewvc?view=rev&rev=559011
> > > > >>>> Log:
> > > > >>>> -Add a phase called Addressing as I mentioned in the mailing list -
> > > > >>>> Move all the addressing handlers into Addressing phase
> > > > >>>> - Had to modify a set of axis2.xml and test cases to cope this chang
> > > > >>>>
> > > > >>>> [This is a big commit but no need to worry :) ]
> > > > >>>>
> > > > >>>> Modified:
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/addressing/src/META-INF/module.xml
> > > > >>>> webservices/axis2/trunk/java/modules/integration/conf/axis2.xml
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/deployment/deployment.both.axis2.xml
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/mtom/MTOM-enabled-axis2.xml
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/mtom/MTOM-fileCache-enabled-axis2.xml
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/swa/SwA-enabled-axis2.xml
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/swa/SwA-fileCache-enabled-axis2.xml
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/HandlerExecutionTest.java
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/chunking-disabled-axis2.xml
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/chunking-enabled-axis2.xml
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/commons-http-enabled-axis2.xml
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/jms/jms-enabled-client-axis2.xml
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/jms/jms-enabled-server-axis2.xml
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/mail/mail-enabled-axis2.xml
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/mail/mail-enabled-client-axis2.xml
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/mail/mail-enabled-server-axis2.xml
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/kernel/conf/axis2.xml
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/deployment/axis2_default.xml
> > > > >>>>
> > > > >>>>
> > > > >>>> webservices/axis2/trunk/java/modules/kernel/test/org/apache/axis2/deployment/ModuleDisengagementTest.java
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >> ---------------------------------------------------------------------
> > > > >> 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
> > > >
> > > >
> > >
> > >
> > > --
> > > David Illsley - IBM Web Services Development
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > www.ruchith.org
> > www.wso2.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
www.ruchith.org
www.wso2.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Re: svn commit: r559011 - in /webservices/axis2/trunk/java/modules: addressing/src/META-INF/ integration/conf/ integration/test-resources/deployment/ integration/test-resources/mtom/ integration/test-resources/swa/ integration/test/org/ap
Posted by David Illsley <da...@gmail.com>.
The DoS is not against the service itself, but using the service to
send messages to a victim indirectly. To prevent the use of your
server in this way, the suggestion from the WS-A group is to require
the ReplyTo is signed. However, given that we populate the ReplyTo
field before the security handler now, Axis2+Rampart users get no such
protection because when Rampart throws an exception, a fault will be
sent to the victim, not the originator of the request message.
Given that we don't have (and I see no appetite for) roll-back-able
handlers, the solution I see is to split the reading of the addressing
headers into 2. Part that runs before security and part that runs
after. That way, anything which is security-sensitive (like ReplyTo
processing) can run after security validation.
Cheers,
David
On 09/08/07, Ruchith Fernando <ru...@gmail.com> wrote:
> Apologies for jumping in late! Please see my comments below:
>
> On 7/30/07, David Illsley <da...@gmail.com> wrote:
> > Ah, the perrenial ws-sec+ws-a problem.
> > This is a really complex issue, and unfortunately I don't think it can
> > be resolved this simply i.e. what happens if security rejects the ws-a
> > headers as invalid? There isn't any code to roll-back the ws-a related
> > fields in the message context, so suddenly one of the main reasons to
> > require signed ws-a headers (preventing your server from being used to
> > DoS via ReplyTo) is bypassed.
> >
> > I think we probably need to split the addressing processing itself
> > into 2 parts - the first which provides a guess of the AxisOperation
> > based onthe To/Action/RelatesTo and the second which does the full
> > ws-a processing (afer the security handler).
>
> I'm trying to understand the various placements of the addressing
> dispatcher and its affect on the DoS attack that David mentioned.
> Please correct me if I have missed something.
>
> With the addressing dispatcher running before the security handler
> - An attacker changes the signed ReplyTo header of a message to a service
> - Addressing handled extracts this information and addressing
> dispatcher finds the operation.
> - Signature verification fails and the fault is sent to the *changed*
> ReplyTo address
>
> Now with David's proposal (The way I understood it) the earlier three
> steps happen anyway ... its true that the fault is sent to the changed
> ReplyTo but the message never reaches the service in either case.
>
> Now ... In case of a aync message invocation, even if we do *not* do
> any addressing processing/dispatch before security processing when
> signature verification fails due to someone modifying an addressing
> header we will not be able to send an asyc response anyway, since at
> the point where processing fails we do not know the ReplyTo address.
>
> David can you please explain how the DoS attack happen with the
> current approach and how it can be prevented by splitting addressing
> based dispatching?
>
> Thanks,
> Ruchith
>
> >
> > Do you have a list of use-cases you're trying to support?
> > David
> >
> > On 27/07/07, Deepal jayasinghe <de...@gmail.com> wrote:
> > > In the case of WS-Security there are instance that the only way to
> > > dispatch is using addressing , and service and operation must be found
> > > before running the security handlers. If you take transport like SMTP
> > > the only way to dispatch is using addressing so we need to run
> > > addressing before security.
> > >
> > > May be Ruchith can add some more infor into this.
> > >
> > > Thanks
> > > Deepal
> > > > Um deepal, can you explain why we should have the
> > > > AddressingBased*Dispatcher* running before the *Dispatch* phase?
> > > > Thanks,
> > > > David
> > > >
> > > > On 25/07/07, Deepal jayasinghe <de...@gmail.com> wrote:
> > > >
> > > >> Hi Glen,
> > > >> Yes I have to agree with you , but let's do that for next release. I
> > > >> would like to consider that as the first item to be fixed.
> > > >>
> > > >> Thanks
> > > >> Deepal
> > > >>
> > > >>> [Forward with correct prefix]
> > > >>>
> > > >>> Gosh. If only Modules ...
> > > >>>
> > > >>> http://marc.info/?l=axis-dev&m=118117804705440&w=2
> > > >>>
> > > >>> ... could define their own Phases
> > > >>>
> > > >>> http://marc.info/?l=axis-dev&m=114404998012486&w=2
> > > >>>
> > > >>> this commit could have consisted of a simple change to the Addressing
> > > >>> module's module.xml, and that would basically be it. This demonstrates,
> > > >>> once again, exactly the problem with the current overly-static design.
> > > >>>
> > > >>> I still stand by the position I wrote up last year:
> > > >>>
> > > >>> http://marc.info/?l=axis-dev&m=114417377917696&w=2
> > > >>>
> > > >>> This needs to be fixed after 1.3, folks.
> > > >>>
> > > >>> --Glen
> > > >>>
> > > >>>
> > > >>> deepal@apache.org wrote:
> > > >>>
> > > >>>> Author: deepal
> > > >>>> Date: Tue Jul 24 04:41:00 2007
> > > >>>> New Revision: 559011
> > > >>>>
> > > >>>> URL: http://svn.apache.org/viewvc?view=rev&rev=559011
> > > >>>> Log:
> > > >>>> -Add a phase called Addressing as I mentioned in the mailing list -
> > > >>>> Move all the addressing handlers into Addressing phase
> > > >>>> - Had to modify a set of axis2.xml and test cases to cope this chang
> > > >>>>
> > > >>>> [This is a big commit but no need to worry :) ]
> > > >>>>
> > > >>>> Modified:
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/addressing/src/META-INF/module.xml
> > > >>>> webservices/axis2/trunk/java/modules/integration/conf/axis2.xml
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/deployment/deployment.both.axis2.xml
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/mtom/MTOM-enabled-axis2.xml
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/mtom/MTOM-fileCache-enabled-axis2.xml
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/swa/SwA-enabled-axis2.xml
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/swa/SwA-fileCache-enabled-axis2.xml
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/HandlerExecutionTest.java
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/chunking-disabled-axis2.xml
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/chunking-enabled-axis2.xml
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/commons-http-enabled-axis2.xml
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/jms/jms-enabled-client-axis2.xml
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/jms/jms-enabled-server-axis2.xml
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/mail/mail-enabled-axis2.xml
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/mail/mail-enabled-client-axis2.xml
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/mail/mail-enabled-server-axis2.xml
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/kernel/conf/axis2.xml
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/deployment/axis2_default.xml
> > > >>>>
> > > >>>>
> > > >>>> webservices/axis2/trunk/java/modules/kernel/test/org/apache/axis2/deployment/ModuleDisengagementTest.java
> > > >>>>
> > > >>>>
> > > >>>>
> > > >> ---------------------------------------------------------------------
> > > >> 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
> > >
> > >
> >
> >
> > --
> > David Illsley - IBM Web Services Development
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> www.ruchith.org
> www.wso2.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org