You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Mark Combellack <mc...@ubiquitysoftware.com> on 2007/05/03 13:14:30 UTC
Questions about getting Conversational scope working
Hi,
I've been attempting to get the Conversational Scope to work in Tuscany. I have had some success and managed to get some of the unit tests to work with Conversational Scope.
Things that are currently working:
* @Scope("CONVERSATION")
* @ConversationID injection
* I can invoke Conversational Components and the correct instances are being used.
* Callback between Conversational Components is generally working.
* The following core unit tests have been re-enabled and are passing:
* BasicConversationalScopeTestCase
* ConversationalScopeContainerDestroyOnExpirationTestCase
* ConversationalScopeContainerMaxAgeTestCase
* ConversationalScopeContainerMaxIdleTimeTestCase
* ConversationalScopeContainerPersistenceTestCase
I've got a few questions/issues that I spotted and I was after the mailing lists advice.
How should Conversational Impls be detected?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Looking in the visitClass() method of org.apache.tuscany.implementation.java.introspect.impl.ConversationProcessor the code looks for the @ConversationalAttributes annotation.
Is it mandatory for a Conversational Implementation to define the @ConversationalAttributes annotation? I could not find anywhere in the specifications that said this.
Should the code consider classes with @Scope("CONVERSATION") as conversational as well?
Detecting Conversational Components in BuilderRegistryImpl
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Looking at the build() method of org.apache.tuscany.core.builder.BuilderRegistryImpl in the core project, the scope of an implementation is checked by looking for the Scopeable interface as shown below.
134 Scope scope = Scope.STATELESS;
135 Implementation implementation = componentDef.getImplementation();
136 if(implementation instanceof Scopeable) {
137 scope = ((Scopeable) implementation).getScope();
138 }
When I use a Java Implementation, the implementation is an instance of the JavaImplementationProvider class from the implementation-java-runtime project. However, this class does not implement Scopeable. As a result of this, my Conversational implementation is treated as Stateless.
My question is, should JavaImplementationProvider be updated to implement Scopeable?
MemoryStore
-=-=-=-=-=-
Currently the memory store Java class used by the Conversational implementation is under the src/test/java folder of the core project. As this is used by the Conversational implementation, should this class be moved to the src/main/java folder?
Submitting patches - individual files or logical groupings?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The conversational changes have required changes to 10 to 15 files. The patch submission process at http://cwiki.apache.org/confluence/display/TUSCANY/Issue+Tracking says to create a patch for the file. If I need to patch multiple files, should I create a patch file for each individual file or can I logically group them together to produce a smaller number of patches.
For example, suppose I need to modify 1 class file in core and 6 files in the unit tests - should I submit 7 patch files? Or can I submit 2 patches, one containing the core file change and another containing the changes to the 6 unit tests.
Thanks,
Mark
Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Questions about getting Conversational scope working
Posted by Raymond Feng <en...@gmail.com>.
Hi, Mark.
Thank you for looking into this area. And your contribution are very
welcome.
Please see my comments inline.
Raymond
----- Original Message -----
From: "Mark Combellack" <mc...@ubiquitysoftware.com>
To: <tu...@ws.apache.org>
Sent: Thursday, May 03, 2007 4:14 AM
Subject: Questions about getting Conversational scope working
Hi,
I've been attempting to get the Conversational Scope to work in Tuscany. I
have had some success and managed to get some of the unit tests to work with
Conversational Scope.
Things that are currently working:
* @Scope("CONVERSATION")
* @ConversationID injection
* I can invoke Conversational Components and the correct instances are
being used.
* Callback between Conversational Components is generally working.
* The following core unit tests have been re-enabled and are passing:
* BasicConversationalScopeTestCase
* ConversationalScopeContainerDestroyOnExpirationTestCase
* ConversationalScopeContainerMaxAgeTestCase
* ConversationalScopeContainerMaxIdleTimeTestCase
* ConversationalScopeContainerPersistenceTestCase
I've got a few questions/issues that I spotted and I was after the mailing
lists advice.
How should Conversational Impls be detected?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Looking in the visitClass() method of
org.apache.tuscany.implementation.java.introspect.impl.ConversationProcessor
the code looks for the @ConversationalAttributes annotation.
Is it mandatory for a Conversational Implementation to define the
@ConversationalAttributes annotation? I could not find anywhere in the
specifications that said this.
Should the code consider classes with @Scope("CONVERSATION") as
conversational as well?
<rfeng>
I think there are multiple annotations that play a role here:
1) The service interface is marked with @Conversational
2) The impl class is marked with @ConversationalAttributes
3) An operation is marked with @EndsConversation
4) The scope is CONVERSATION.
I assume 1, 2, 3 can only be valid if 4 happens at the same time.
</rfeng>
Detecting Conversational Components in BuilderRegistryImpl
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Looking at the build() method of
org.apache.tuscany.core.builder.BuilderRegistryImpl in the core project, the
scope of an implementation is checked by looking for the Scopeable interface
as shown below.
134 Scope scope = Scope.STATELESS;
135 Implementation implementation = componentDef.getImplementation();
136 if(implementation instanceof Scopeable) {
137 scope = ((Scopeable) implementation).getScope();
138 }
When I use a Java Implementation, the implementation is an instance of the
JavaImplementationProvider class from the implementation-java-runtime
project. However, this class does not implement Scopeable. As a result of
this, my Conversational implementation is treated as Stateless.
My question is, should JavaImplementationProvider be updated to implement
Scopeable?
<rfeng>We're moving away from the builders. We understand it is a bit
difficult and confusing because there are two parallel code paths during the
transistion. We'll clean up soon. Please see org.apache.tuscany.core package
in the core-spi module for the new extension interfaces. The
JavaImplementationProvider now extends ScopedImplementationProvider to
support the scope management. We might need something for the conversational
too.</rfeng>
MemoryStore
-=-=-=-=-=-
Currently the memory store Java class used by the Conversational
implementation is under the src/test/java folder of the core project. As
this is used by the Conversational implementation, should this class be
moved to the src/main/java folder?
<rfeng>I guess we need to reactivate the store for the
conversations.</rfeng>
Submitting patches - individual files or logical groupings?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The conversational changes have required changes to 10 to 15 files. The
patch submission process at
http://cwiki.apache.org/confluence/display/TUSCANY/Issue+Tracking says to
create a patch for the file. If I need to patch multiple files, should I
create a patch file for each individual file or can I logically group them
together to produce a smaller number of patches.
For example, suppose I need to modify 1 class file in core and 6 files in
the unit tests - should I submit 7 patch files? Or can I submit 2 patches,
one containing the core file change and another containing the changes to
the 6 unit tests.
<rfeng>I would say you could just create one patch. It would be easier for
you :-)</rfeng>
Thanks,
Mark
Information contained in this e-mail and any attachments are intended for
the use of the addressee only, and may contain confidential information of
Ubiquity Software Corporation. All unauthorized use, disclosure or
distribution is strictly prohibited. If you are not the addressee, please
notify the sender immediately and destroy all copies of this email. Ubiquity
Software Corporation plc, a company registered under the laws of England and
Wales, Registration 2719723, registered offices at Eastern Business Park,
Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United
Kingdom.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org