oad the meaning. If we want something to control
instance lifecycle, we should have a separate annotation.
Dave
- Original Message -
From: "Raymond Feng" <[EMAIL PROTECTED]>
To:
Sent: Thursday, September 13, 2007 5:35 PM
Subject: Re: Resetting state of service references
ymond
- Original Message -
From: "scabooz" <[EMAIL PROTECTED]>
To:
Sent: Thursday, September 13, 2007 2:12 PM
Subject: Re: Resetting state of service references at conversation end
Please Java spec errata #11 at this link:
http://www.osoa.org/display/Main/Errata+for+Java+Annotatio
L PROTECTED]>
To:
Sent: Sunday, September 09, 2007 6:44 PM
Subject: Re: Resetting state of service references at conversation end
On 9/9/07, Simon Nash <[EMAIL PROTECTED]> wrote:
I don't think this makes it completely clear whether there is one
conversation A->B->A or two co
To:
Sent: Tuesday, September 11, 2007 9:07 AM
Subject: Re: Resetting state of service references at conversation end
Raymond Feng wrote:
OK. I'll add the interfaces first for review. Should they go to the
core-spi?
Thanks,
Raymond
Only the interfaces actually used by binding and im
y, September 11, 2007 9:07 AM
Subject: Re: Resetting state of service references at conversation end
Raymond Feng wrote:
OK. I'll add the interfaces first for review. Should they go to the
core-spi?
Thanks,
Raymond
Only the interfaces actually used by binding and implementation extensions
shou
ssage - From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To:
Sent: Tuesday, September 11, 2007 2:02 AM
Subject: Re: Resetting state of service references at conversation end
I'm overall +1 with this proposal, with some minor changes described
in comments inline.
Ra
More comments inline.
[snip]
Simon Laws wrote:
Right, if I understand correctly we need to keep the state of a
conversation in a central place in a Tuscany runtime that all
participants can point to, allowing one to end the conversation, and the
other conversation participants to see that it h
OK. I'll add the interfaces first for review. Should they go to the
core-spi?
Thanks,
Raymond
- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, September 11, 2007 2:02 AM
Subject: Re: Resetting state of service reference
Raymond Feng <[EMAIL PROTECTED]> writes:
>
> Hi,
>
> As we agreed, the conversation id alone is not sufficient to deal with
> conversations. We need to maintain the state of the conversations (STARTED,
> ENDED or EXPIRED).
>
> I propose that we do the following:
>
> 1) Define a ConversationM
conversation before it's used.
> >>
> >>
> >> This would still involve updating the scope containers to record the
> >> conversation status against conversation id. But maybe this is an
> easier
> >> generic change. I.e. instigate a collection a
on Laws"
<[EMAIL PROTECTED]>
To:
Sent: Sunday, September 09, 2007 11:10 AM
Subject: Re: Resetting state of service references at conversation end
Hi Raymond
some comments below...
Simon
On 9/9/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
I have been thinking of th
OTECTED]>
To:
Sent: Sunday, September 09, 2007 11:10 AM
Subject: Re: Resetting state of service references at conversation end
Hi Raymond
some comments below...
Simon
On 9/9/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
I have been thinking of this problem as well. It's not re
ersationViolation fault."
> >
> > My understanding is that in your scenatio, both A->B and B->A are in the
>
> > same conversation and step 3 will ends the conversation for both A and
> B.
> >
> > Thanks,
> > Raymond
> >
> > - Origin
tion fault."
My understanding is that in your scenatio, both A->B and B->A are in the
same conversation and step 3 will ends the conversation for both A and B.
Thanks,
Raymond
- Original Message - From: "Simon Nash" <[EMAIL PROTECTED]>
To:
Sent: Sunday, S
sage -
From: "Simon Nash" <[EMAIL PROTECTED]>
To:
Sent: Sunday, September 09, 2007 1:05 PM
Subject: Re: Resetting state of service references at conversation end
Please can you explain the scenario in a little more detail. If I am
understanding the scenario correctly, the
Please can you explain the scenario in a little more detail. If I am
understanding the scenario correctly, the client's conversation ID
should not be set back to null. Here's what I think the scenario is:
1. client A calls Service B on a conversational interface
2. service B calls back to cl
ccess a conversation object given conversationId during callback at the
client end.
Thanks,
> Raymond
>
> - Original Message -
> From: "Simon Laws" <[EMAIL PROTECTED]>
> To: "tuscany-dev"
> Sent: Sunday, September 09, 2007 4:15 AM
> Subject:
4:15 AM
Subject: Resetting state of service references at conversation end
When @ConversationEnd is called on a satefull callback the conversation id
of the client reference is not reset back to null. I have put a fix in in
the case where the scope of the originating component is CONVER
When @ConversationEnd is called on a satefull callback the conversation id
of the client reference is not reset back to null. I have put a fix in in
the case where the scope of the originating component is CONVERSATION. This
relies on storing the Conversation object in the conversational scope
cont
19 matches
Mail list logo
