terminating configuration context
> >
> > Modified:
> >
>
> webservices/axis2/tags/java/v1.5/modules/kernel/src/org/apache/axis2/context/ConfigurationContext.java
> >
>
> webservices/axis2/tags/java/v1.5/modules/kernel/src/org/apache/axis2/dispatchers/Addressing
URL: http://svn.apache.org/viewvc?rev=835262&view=rev
>> > Log:
>> > set the axis message for addressing based dispatcher and destroy the
>> > listner manager when terminating configuration context
>> >
>> > Modified:
>> >
>>
ebservices/axis2/tags/java/v1.5/modules/kernel/src/org/apache/axis2/dispatchers/AddressingBasedDispatcher.java
>
> Modified:
> webservices/axis2/tags/java/v1.5/modules/kernel/src/org/apache/axis2/context/ConfigurationContext.java
> URL:
> http://svn.apache.org/viewvc/webservices/axi
new dispatchers can't
> resolve the required operation
>
>
> Key: AXIS2-2864
> URL: https://issues.apache.org/jira/browse/AXIS2-2864
>
a test case.
> JMS addressing (SOAPBody addressing) is broken. The new dispatchers can't
> resolve the required operation
>
>
> Key: AXIS2-2864
>
ing) is broken. The new dispatchers can't
> resolve the required operation
>
>
> Key: AXIS2-2864
> URL: https://issues.apache.org
is is related to the JMS transport implementation.. could you
taka a look at this since its marked a blocker? If its something to do with the
transport - please assign back to me.
thanks
asankha
> JMS addressing (SOAPBody addressing) is broken. The new dispatchers can't
> reso
new dispatchers can't
> resolve the required operation
>
>
> Key: AXIS2-2864
> URL: https://issues.apache.org/jira/browse/AXIS2-2864
>
JMS addressing (SOAPBody addressing) is broken. The new dispatchers can't
resolve the required operation
Key: AXIS2-2864
URL: https://issues.apache.org
Please comment that line out from your axis2.xml
thanks,
dims
On 6/26/07, Mark Badorrek <[EMAIL PROTECTED]> wrote:
Dear all,
I'm doing some debugging with WebsphereMQ as the axis2 JMS provider and I've
adopted the new dispatcher layout of axis2.xml in the nightly build.
Suddenly I can't seem
Dear all,
I'm doing some debugging with WebsphereMQ as the axis2 JMS provider and I've
adopted the new dispatcher layout of axis2.xml in the nightly build.
Suddenly I can't seem to get JMS to work.
Specifically the following code in axis2.xml:
results in the following:
t;
>
>
> *Eran Chinthaka <[EMAIL PROTECTED]>*
>
> 06/25/2007 10:44 AM
> Please respond to
> axis-dev@ws.apache.org
>
>
>
> To
>
> axis-dev@ws.apache.org
>
MAIL PROTECTED]>
*Eran Chinthaka <[EMAIL PROTECTED]>*
06/25/2007 10:44 AM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
Subject
Re: [Axis2] Dispatch
So, IMO, lets move them, lets get the API/SPI right if we can (while
maintaining backwards compatibility).
+1 to this, and to the "move, extend, and deprecate" pattern that's
being discussed.
--Glen
-
To unsubscribe, e-mai
>"Davanum
> Srinivas" <[EMAIL PROTECTED]>
>
>
> *"Davanum Srinivas" <[EMAIL PROTECTED]>*
>
> 06/25/2007 09:29 AM
> Please respond to
> axis-dev@ws.apa
AM
Subject
Re: [Axis2] Dispatchers in
Please respond to org.apache.axis2.engine package
[EMAI
Srinivas" <[EMAIL PROTECTED]>*
>
> 06/25/2007 09:29 AM
> Please respond to
> axis-dev@ws.apache.org
>
>
>
> To
>
> "Afkham Azeez" <[EMAIL PROTECTED]>
&
Subject
Re: [Axis2] Dispatchers in
org.apache.axis2.engine package
Please respond to
[EMAIL PROTECTED]
/24/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
>
> Team,
>
> Anyone object to moving the following classes to
org.apache.axis2.dispatchers?
>
> AddressingBasedDispatcher.java
> HTTPLocationBasedDispatcher.java
> InstanceDispatcher.j
Aaaargh.
Sorry, this is all my fault. I was trying to do the *right thing* and
have them in .engine but I keep on getting distracted. I think in
.dispatchers is the right place - I've always said I don't think any
user should have to look in the .engine package.
If we do move the dispa
last
thing we need at the moment is unhappy users. This is a mistake we may have
to live with.
-- Azeez
On 6/24/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
Team,
Anyone object to moving the following classes to
org.apache.axis2.dispatchers?
AddressingBasedDispatche
Guess, i am trying to get the public API "right"...Right now there are
some *Dispatcher classes in org.apache.axis2.dispatchers and some
*Dispatchers in org.apache.axis2.engine.
-- dims
On 6/24/07, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
Also, aren't the package
Also, aren't the package names of dispatchers sort of a "public API" bit
of Axis2?? If so I'm against this unless there's something to be gained by it.
Sanjiva.
Eran Chinthaka wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have no objection to this but is
lasses to
> org.apache.axis2.dispatchers?
>
> AddressingBasedDispatcher.java
> HTTPLocationBasedDispatcher.java
> InstanceDispatcher.java
> RequestURIBasedDispatcher.java
> RequestURIOperationDispatcher.java
> SOAPActionBasedDispatcher.java
> SOAPMessageB
Team,
Anyone object to moving the following classes to org.apache.axis2.dispatchers?
AddressingBasedDispatcher.java
HTTPLocationBasedDispatcher.java
InstanceDispatcher.java
RequestURIBasedDispatcher.java
RequestURIOperationDispatcher.java
SOAPActionBasedDispatcher.java
Sure Glem,
Per discussion an age ago, (around and in AXIS2-1457) I've been trying
to move to separated service and operation dispatchers. This is, I
think, a good thing as there will be less duplicated code (the
dispatchers, no offence to anyone, have been a bit messy for a while)
as the
,
David
> AddressingValidation prevents other dispatchers from executing
> --
>
> Key: AXIS2-2350
> URL: https://issues.apache.org/jira/browse/AXIS2-2350
> Projec
> AddressingValidation prevents other dispatchers from executing
> --
>
> Key: AXIS2-2350
> URL: https://issues.apache.org/jira/browse/AXIS2-2350
> Project: Axis 2.0 (Axis2)
>
AddressingValidation prevents other dispatchers from executing
--
Key: AXIS2-2350
URL: https://issues.apache.org/jira/browse/AXIS2-2350
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Hi all,
In trying to complete AXIS2-1457 I've been looking at the dispatchers
we have and trying to work out the cleanest way of dealing with them.
I think that the best approach will be to move them out of the
o.a.a.engine package into an o.a.a.dispatchers package (and mov
Well we had to move dispatchers here and there to solve security
(ws-sec) problem. I mean they wanted to dispatch using request uri. I
will update the documents to cope with the changes. I am very sorry for
our problem.
Brian De Pradine wrote:
>
> Should have added [Axis2] to the s
Should have added [Axis2] to the subject
originally.
Cheers
Brian DePradine
Web Services Development
IBM Hursley
External +44 (0) 1962 816319 Internal
246319
If you can't find the time to do it right the first time, where will you
find the time to do it again?
- Forwarded by Brian
Hello,
Does anyone know why the core/conf/axis2.xml
file includes the RequestURIBasedDispatcher and the SOAPActionBasedDispatcher
in the Transport phase of the Inflow? This seems to contradict the phase
descriptions in the section "Processing an Incoming SOAP Message"
of the Apache Axis2 Architec
Hi Ruchith:
I very much like the ability to quickly configure the handler chain
using axis2.xml. As long as nothing creates conflicts, why shouldn't we
allow this?
Are you talking about handlers in general?
If so... I was under the impression that with Axis2 the users will NOT
not have access
Hi Deepal:
As I understand we came to a conclusion that the only way to deploy
handlers using module. So if some one want to add a handler he has to
create module and write it module.xml correctly and engage that module.
(I know the fact that it make simple case harder). But I do not think we
here is my +1
Thanks,
Deepal
~Future is Open~
- Original Message -
From: "Sanjiva Weerawarana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, October 26, 2005 5:15 AM
Subject: R
directory.
comments ...
Thanks,
Deepal
~Future is Open~
- Original Message -
From: "Glen Daniels" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, October 26, 2005 4:42 AM
Subject: Re: [axis2] Dispatchers
Hi
en't two ways of doing the same thing. I also think
> hard-coding this stuff makes it confusing when you look at axis2.xml
> (not everything is "really" there).
>
> We have a great mechanism for deploying and ordering handlers -
> dispatchers are nothing specia
On Tue, 2005-10-25 at 19:01 -0400, Davanum Srinivas wrote:
> +1 from me. Glen please go ahead and clean it up :) I agree with the
> principle, default should come from axis2.xml
+1 from me too!
Sanjiva.
lt way. If you *do* want to change it, it's obvious how to do it
> and there aren't two ways of doing the same thing. I also think
> hard-coding this stuff makes it confusing when you look at axis2.xml
> (not everything is "really" there).
>
> We hav
to do it
and there aren't two ways of doing the same thing. I also think
hard-coding this stuff makes it confusing when you look at axis2.xml
(not everything is "really" there).
We have a great mechanism for deploying and ordering handlers -
dispatchers are nothing specia
Hi
see my comments below;
Thanks,
Deepal
~Future is Open~
- Original Message -
From: "Sanjiva Weerawarana" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, October 25, 2005 9:05 AM
Subject: Re: [axis2] Dispa
>
> class="package.MyDispatcher"/>
>
>
Does the latter syntax imply we can remove the first form? If so +1 for
the latter otherwise I don't think we need alternate syntax for this
type of stuff because changing dispatchers type work is not a regular
user activity .. or even close to it.
Sanjiva.
Hi Glen, Deepal;
I think I am the one who hardcode the dispatchers in the first place.
But I am convinced
that it is a *bad* thing to do. I am +1 to add them all to the
dispatcher phase in the axis2.xml and let them be just Handlers
Thanks
Srinath
On 10/24/05, Glen Daniels <[EMAIL PROTEC
Hi Deepal:
I agree on that Dispatcher itself is a handler
Ok.
but the name "Dispatcher" implies different meaning than a handler , it
is obvious that a module can configure to put handlers into Dispatch
phase we are not avoiding doing that (in fact I did the same thing to a
the SypaseToy t
ks,
Deepal
~Future is Open~
- Original Message -
From: "Glen Daniels" <[EMAIL PROTECTED]>
To:
Sent: Monday, October 24, 2005 9:52 AM
Subject: Re: [axis2] Dispatchers
Glen Daniels wrote:
* I don't like having the default d
Glen Daniels wrote:
* I don't like having the default dispatchers be deployed in a way that
causes them NOT to appear in the standard axis2.xml file.
To be clear here, I'm talking about
AxisConfigurationImpl.setDefaultDispatchers()...
The basic idea of that whole message is that
Hi folks!
A few comments about dispatchers/handlers:
* Does having an "AbstractDispatcher" class really help us in any way?
The only thing it really seems to do that's useful is the "relatesTo"
check... but shouldn't that check itself happen elsewhere (like in a
48 matches
Mail list logo
