n where MR. was not able to deliver the
messages. (if any)
Thanks,
Jaliya
- Original Message -
From: Chamikara Jayalath
To: axis-dev@ws.apache.org ; sandesha-dev@ws.apache.org
Sent: Wednesday, December 07, 2005 1:41 AM
Subject: Re: [Axis2] Implications of WSRM interfaces on Axis2 Clie
In fact the problem of explicitly knowing the Last message may go away because the WS-RX committee voted last week to remove the LastMessage from the spec. However, you do need to know when the sequence has ended - the only thing was before you needed to know before you sent the last message -- now
Hi Guys,
I'm cleaning up my mailbox a bit (long flight) and ran into this thread.
I see that it hasn't concluded. I like this last proposal by Chamikara -
have two "session" like hints that a user can assert via Call (or
another MEP client). In fact, we may need exactly something like this to
dea
Hi Eran,
The problem comes when we have to group messages that does not exactly
fit into any mep. For example users can define a group that expand
several meps. In this case there is no way to detect the Last Message
using the mep. Also it is very possible for a sequence to end in the
middle of a
be handled by the
> > client code.
> >
> > Thanks,
> >
> > Jaliya
> >
> >
> >
> > - Original Message -
> > From: Eran Chinthaka
> > To: axis-dev@ws.apache.org
> > Sent: Sunday, October 30, 2005 11:40 AM
> > Subject
t;
>
> - Original Message -
> From: Eran Chinthaka
> To: axis-dev@ws.apache.org
> Sent: Sunday, October 30, 2005 11:40 AM
> Subject: Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
>
>
> This is just a thought came to my mind about the LastMessage.
>
&g
the
client code.
Thanks,
Jaliya
- Original Message -
From: Eran Chinthaka
To: axis-dev@ws.apache.org
Sent: Sunday, October 30, 2005 11:40 AM
Subject: Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
This is just a thought came to my mind about the LastMessage.
Facts :
1.ON-
all
API
rather than having another Context or some other Object to transfer
properties.
Thanks,
Jaliya
- Original Message -
From: "Srinath Perera" <[EMAIL PROTECTED]>
To:
Sent: Saturday, October 29, 2005 10:11 AM
Subject: Re: [Axis2] Implications of WSRM interfaces on Axi
On Sat, 2005-10-29 at 15:27 -0600, Paul Fremantle wrote:
> Guys
>
> I agree we don't want to add RM specific APIs to Axis2. However, as I
> think my long post, and Chamikara's much neater append point out,
> there is a way of looking at these as being general concepts in WS and
> not specific RM c
era" <[EMAIL PROTECTED]>> To: <axis-dev@ws.apache.org>> Sent: Saturday, October 29, 2005 7:37 AM
> Subject: Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI>>> I am 0- on moving the constants to the core>> how about following>> Call call
n the Call API
rather than having another Context or some other Object to transfer
properties.
Thanks,
Jaliya
- Original Message -
From: "Srinath Perera" <[EMAIL PROTECTED]>
To:
Sent: Saturday, October 29, 2005 10:11 AM
Subject: Re: [Axis2] Implications of WSRM interfac
> - Original Message -
> From: "Srinath Perera" <[EMAIL PROTECTED]>
> To:
> Sent: Saturday, October 29, 2005 7:37 AM
> Subject: Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
>
>
> I am 0- on moving the constants to the core
>
> h
This is what we have in Sandesha 1.0. It introduce this new RMContext that
requires the jar to be in the classpath.
Thanks,
Jaliya
- Original Message -
From: "Srinath Perera" <[EMAIL PROTECTED]>
To:
Sent: Saturday, October 29, 2005 7:37 AM
Subject: Re: [Axis2] Impl
H Dims,
If it is aboug moving something specific to RM into Axis2 I will also
totally disagree. But if we look in a different point of view some of
these constants convey a general idea that is not at all specific to RM.
LAST_MESSAGE
This simply indicate that the next invocation is the Last Mess
I am 0- on moving the constants to the core
how about following
Call call = new Call();
call.engageModule("RM");
RMContext rcontext = (RMContext)call.getExtentionContext(RM_MODULE);
//return the RMContext from extension registry
RMContext will have RM specific methods and provide way to monitor
On Sat, 2005-10-29 at 01:52 -0400, Davanum Srinivas wrote:
> Chamikara,
>
> In the generated code when RM module is engaged, we can generate what
> we want. Am -0 to this proposal. I don't agree that the constants
> should move to the core itself. If we start doing this we have to be
> consistent
Chamikara,
In the generated code when RM module is engaged, we can generate what
we want. Am -0 to this proposal. I don't agree that the constants
should move to the core itself. If we start doing this we have to be
consistent and do the same for wss4j, kandula and others.
thanks,
dims
On 10/29/
Hi All,
Actually this is the way we have currently developed the client API for
Sandesha2. I hope following bit of code will clarify the issue.
Call call = new Call(AXIS2_CLIENT_PATH);
call.engageModule(new QName("sandesha"));
call.setTo(new EndpointReference(toEPR));
call.set(org.apache.sandesha
Hi All,
The requirement of supporting additional properties required for RM
through some client API was the case from the beginning of Sandesha. When
we initially write Sandesha, we had the same issue. With the 1.0
implementation and we end up using a SandeshaContext that will be
initialized with
Paul Eran ..I do not read complete message ..but one option is to use
properties with the RM and give a RMClient interface that wrap the
Axis2 client and give first level support that properties.
My gut feeling is brunning the RM to Axis2 client API is not right ..
But we need to discuss
it more :
One more reason to move these constants from Sandesha to Axis2 is so I don't need Sandesha in my classpath to write and run code that might one day use RM.PaulOn 10/28/05,
Paul Fremantle <[EMAIL PROTECTED]> wrote:
OkI wasn't clear. Sorry. I also agree with Glen's comments :-) What I'm actually ask
OkI wasn't clear. Sorry. I also agree with Glen's comments :-) What I'm actually asking is that we move from: org.apache.sandesha.Constants.ClientPropertiesString LAST_MESSAGE = "lastMessage";
String CALL_KEY = "callKey";into org.apache.axis2.Constants.I am talking about using the property model, s
A BIG +1 from me for Glen's comments.
As Glen explained the base API should be as simple as possible and it
should not depend on any of the things like security/transaction/RM,
etc,
Paul, why do you wanna do that (I know you must be having a good
reason), when you can do the same thing using
Hi Paul:
Great message! As I read it you're asking for three things:
1. Ability to pass SequenceKey in client API
2. Last message marker in client API
IMO, neither of these needs to be put as first-class concepts into the
Axis2 Call class, because we have easy-to-use mechanisms which allow
thi
24 matches
Mail list logo
