You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Da...@empolis.com on 2008/04/04 18:39:39 UTC
Question about Conversational OSGi Services and Service References
Hi all,
We currently have a problem when using OSGi bundles
(implementation.osgi) for SCA components instead of pure Java
(implementation.java ).
Again here is my "formidable" example using 3 Services Alpha, Beta and
Gamma.
Alpha.doSomething() calls Beta.getRef() which creates a reference to
Gamma and returns it to Alpha.
Alpha then executes Gamme.doSomethingElse().
Gamma is marked wirh @Conversational and it's implementation with
@Scope("CONVERSATION")
If Alpha.doSomething() is executed twice (one after the other) the
sample works well (without any error). ConversationIDs are created and
reused. However, the OSGi implementation uses the same ConversationID in
both calls of Alpha.doSomething(). In the pure Java implementation the
ConversationIDs are different. Also, the Constructor for Gamma is not
called in Beta.getRef() in the OSGi implementation.
If I mark Alpha.doSomething() with @OneWay and Alpha.doSomething() is
executed twice (now in "parallel" because of @OneWay) the sample still
works for the pure Java implementation, but not for the OSGi
implementation.
The difference is, that in the OSGi implementation Beta.getRef(), which
creates the ServiceReference to Gamma, the constructor of Gamma is NOT
called. Thus, only one instance of Gamma exists and so only one
ConversationId exists and is used two times (once for each call of
Alpha.doSomething(). This leads to internal eerrors in
Gamme.doSomethingElse().
In the pure Java implementation the Constructor of Gamma is called
twice, resulting in two instances and two seperate ConversationIDs.
Is there something special we have to configure for OSGi services ? Do
they support "Conversations" or do we have to implement conversation
logic seperately ?
Help is most welcome.
Bye,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
AW: Question about Conversational OSGi Services and Service References
Posted by Da...@empolis.com.
I just created a JIRA for this:
https://issues.apache.org/jira/browse/TUSCANY-2209
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
AW: Question about Conversational OSGi Services and Service References
Posted by Da...@empolis.com.
Hi Rajini,
> Looking at the invocation code for OSGi and Java which
> creates the instances for conversations, there shouldn't be
> any difference between the two (except that OSGi instance
> creation takes much longer).
>
> One of the differences between implementation.java and
> implementation.osgi is that the default scope for OSGi is
> COMPOSITE, but the default for Java is STATELESS. In your
> code, do you set the scope for Alpha?
Yes, I use scope COMPOSITE in Alpha. I just tried STATELESS with the
same result (same problem).
> If Alpha uses COMPOSITE scope, and you call
> Alpha.doSomething() with @OneWay twice, as far as I can tell
> you may end up with either one conversation or two (either
> one Gamma object or two), depending on timing.
> And this should be true even if you are using
> implementation.java with COMPOSITE scope (I dont know whether
> this is the expected behaviour for SCA, but from the code it
> looks that way).
This is not what I expected. I don't understand why it is not
deterministic how many instances of Gamma are created. To handle 2
different "sessions" one needs 2 instances of Gamma, or you have to do
the work in Gamma itself (using static members and selfmade session
ids). But this is exactly what I expected from @Conversational resp.
Scope CONVERSATION.
I also testet it with two instances of Alpha -> same result.
So this behavior looks like a bug to me.
> Is your initialize method called from Tuscany (is it
> annotated with @Init, and does it have a corresponding
> @Destroy)?
No, I did not use @Init. My initialize() method has a parameter (to
configure Gamma) which is not allowed by @Init.
I also did not use @Destroy.
I only annotated stop() with @EndConversation.
When exactly would methdos anotated with @Init and @Destroy be executed
? The documentation says "... is called when the scope defined for the
local servic implemented by this class starts/ends." Does that mean
- Constructor
- @Init
- some methods (e.g. in my initialize(), doSomethingElse())
- @EndConversation
- @Destroy
Would usage of either @Init or @Destroy be of any help with my problem?
>In the failing case, do you see two Gamma objects
> being created and calls to 'initialize' for both? Is it
> possible that the same Gamma object is being used in both
> calls, and the first one calls 'stop' while the second call
> has not yet completed?
Well, the Constructor is called two times creating two different
objects. Initialize() then creates 2 different ConversationIDs.
Is there anything special to take care about when getting the
ServiceReference to Gamm in Beta ?
Here is a code snippet of Beta:
public CallableReference<Gamma> getRef(Config config)
{
ServiceReference<Gamma> gammaRef =
componentContext.getServiceReference(Gamma.class, "gamma");
Gamma dynamicGamma = gammaRef.getService();
dynamicGamma.initialize(config);
return gammaRef;
}
So Alpha should not able to call any methods on Gamma before
initialize() was executed in Beta and the ServiceRefference returned to
Alpha.
Of course because of multithreading if there is some internal bug, a
call stop() on the first refference to gamma could affect the 2nd
refference to Gamma, causing the problems. However, the errors happen
both before and after stop() was called, so I think this is not the
case.
I just noticed, that if an error occurs, the Constructor of Gamma is
called three times, not just two times !?
This is getting really strange ...
> Sorry I am asking more questions instead of providing
> answers. If your test case is small could you raise a JIRA
> and attach the testcase?
No need to apologize, I'm glad for every kind of feedback. And your
answers/questions were all very helpful.
I'll check if I can provide a testcase.
Bye,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Question about Conversational OSGi Services and Service References
Posted by Rajini Sivaram <ra...@googlemail.com>.
Daniel,
Looking at the invocation code for OSGi and Java which creates the instances
for conversations, there shouldn't be any difference between the two
(except that OSGi instance creation takes much longer).
One of the differences between implementation.java and implementation.osgi
is that the default scope for OSGi is COMPOSITE, but the default for Java is
STATELESS. In your code, do you set the scope for Alpha?
If Alpha uses COMPOSITE scope, and you call Alpha.doSomething() with
@OneWay twice, as far as I can tell you may end up with either one
conversation or two (either one Gamma object or two), depending on timing.
And this should be true even if you are using implementation.java with
COMPOSITE scope (I dont know whether this is the expected behaviour for SCA,
but from the code it looks that way).
Is your initialize method called from Tuscany (is it annotated with @Init,
and does it have a corresponding @Destroy)? In the failing case, do you see
two Gamma objects being created and calls to 'initialize' for both? Is it
possible that the same Gamma object is being used in both calls, and the
first one calls 'stop' while the second call has not yet completed?
Sorry I am asking more questions instead of providing answers. If your test
case is small could you raise a JIRA and attach the testcase?
On 4/8/08, Daniel.Stucky@empolis.com <Da...@empolis.com> wrote:
>
> Hi Rajini,
>
> Yes, after adding classes to my .composite file the Scope is found.
> Now, if Alpha.doSomething() is executed twice (one after the other
> without using @OneWay) it works and each call uses different
> ConversationIDs.
>
> However, if I annotate Alpha.doSomething() with @OneWay and call
> Alpha.doSomething() twice (now executed in "parallel") it behaves
> strangely. Some more details:
>
> This is the sequence in that Gamma is accessed:
> 1x Gamma(), constructor does nothing but a println
> 1x initialize(), initializes members
> Nx doSomethingElse() , performs some actions on members
> 1x stop(), closes the conversation
>
> When debugging the two calls to Alpha.doSomething() one after another, I
> see that Gamma() is called twice and that in initialize() two different
> ConversationIDs are created and reused in doSomethingElse() and it works
> without any error
>
> If I only set a breakpoint in Gamma.initialize() my JVM crashes:
> #
> # An unexpected error has been detected by HotSpot Virtual Machine:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d794743, pid=2708,
> tid=3612
> #
> # Java VM: Java HotSpot(TM) Client VM (1.5.0_10-b03 mixed mode)
> # Problematic frame:
> # V [jvm.dll+0x64743]
> #
> # An error report file with more information is saved as
> hs_err_pid2708.log
> #
> # If you would like to submit a bug report, please visit:
> # http://java.sun.com/webapps/bugreport/crash.jsp
> #
>
>
> If I simply execute the test, most of the time I get a NullPointer in
> doSomethingElse(), because a member of Gamma is null. In some rare cases
> the test runs correctly.
> If I add "synchronize" to method initialze(), the test runs without any
> errors, using the correct ConversationIDs.
>
> This seems to be some kind of threading problem, but as there are two
> instances of Gamma I can't see any problem in my code. Besides, as I
> said in a previous mail, without using implementation.osgi the test runs
> well.
>
>
> Bye,
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
--
Thank you...
Regards,
Rajini
AW: Question about Conversational OSGi Services and Service References
Posted by Da...@empolis.com.
Hi Rajini,
Yes, after adding classes to my .composite file the Scope is found.
Now, if Alpha.doSomething() is executed twice (one after the other
without using @OneWay) it works and each call uses different
ConversationIDs.
However, if I annotate Alpha.doSomething() with @OneWay and call
Alpha.doSomething() twice (now executed in "parallel") it behaves
strangely. Some more details:
This is the sequence in that Gamma is accessed:
1x Gamma(), constructor does nothing but a println
1x initialize(), initializes members
Nx doSomethingElse() , performs some actions on members
1x stop(), closes the conversation
When debugging the two calls to Alpha.doSomething() one after another, I
see that Gamma() is called twice and that in initialize() two different
ConversationIDs are created and reused in doSomethingElse() and it works
without any error
If I only set a breakpoint in Gamma.initialize() my JVM crashes:
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d794743, pid=2708,
tid=3612
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_10-b03 mixed mode)
# Problematic frame:
# V [jvm.dll+0x64743]
#
# An error report file with more information is saved as
hs_err_pid2708.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
If I simply execute the test, most of the time I get a NullPointer in
doSomethingElse(), because a member of Gamma is null. In some rare cases
the test runs correctly.
If I add "synchronize" to method initialze(), the test runs without any
errors, using the correct ConversationIDs.
This seems to be some kind of threading problem, but as there are two
instances of Gamma I can't see any problem in my code. Besides, as I
said in a previous mail, without using implementation.osgi the test runs
well.
Bye,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Question about Conversational OSGi Services and Service References
Posted by Rajini Sivaram <ra...@googlemail.com>.
Daniel,
You are on the right track. Sorry, I should have mentioned this before. The
classes from which @Scope annotations are processed in implementation.osgi
should be listed under the attribute "classes" in <implementation.osgi/> in
the composite file.
<implementation.osgi
xmlns=http://tuscany.apache.org/xmlns/sca/1.0bundleSymbolicName="gamma"
classes="services.GammaImpl"/>
There are some examples which use servicefactory in
itest/osgi-implementation (eg. factory-ds-test.composite). Most annotations
like @Property are processed from the implementation class of the service
(GammaImpl) once the service instance is obtained, even if the class is not
listed in <implementation.osgi/>. But since scope needs to be determined
before the service instance is obtained from OSGi, the class(es) from which
@Scope annotation is processed should be listed in the composite file.
On 4/7/08, Daniel.Stucky@empolis.com <Da...@empolis.com> wrote:
>
> Hi Radjini,
>
> > You cannot set servicefactory to true inside an immediate
> > component. Since the service is not registered by OSGi DS in
> > the OSGi registry in this case, implementation.osgi never
> > finds it - hence the infinite loop.
>
> Yes, configuring it in this way makes no sense. A warning would be nice
> :-)
>
>
> > With immediate=false, I would have expected a new instance to
> > be created for Gamma for each conversation.
> >
> > Could you check if the following are true?
> >
> >
> > 1. GammaImpl should contain the annotation
> > @Scope("CONVERSATION") on
> > the class. Not necessarily conversation - anything other
> > than COMPOSITE.
>
> Yes, this is true. It is marked with @Scope("CONVERSATION")
>
>
> > 2. The bundle containing GammaImpl should import
> > org.osoa.sca.annotations
> > (ie. @Scope annotation should be visible from the bundle)
>
> Yes, this is also true
>
>
> > 3. If 1) and 2) are true, could you breakpoint in the
> > constructor of
> > GammaImpl (or anywhere in that class) and check that you
> > have a bundle
> > installed with name "dummy.sca.xxxxx"? implementation.osgi
> > should be using a
> > dummy bundle to get a reference to the Gamma service if it
> > has identified
> > that the scope is not composite.
>
> I could not see a bundle "dummy.sca.*" in the equinox console.
>
> While debugging, I noticed the following in class OSGiInstanceWrapper:
> In line 119
> if (!annotationProcessor.getScope().equals(Scope.COMPOSITE))
> the getScope() returns "COMPOSITE", not "CONVERSATION"
> So line 118
> refBundle = getDummyReferenceBundle();
> is not executed
>
> So it seems that the annotation was not found or not processed
> correctly.
>
> After some further debugging:
>
> In OSGiImplementationProvider in line 162 implementation.getClassList()
> returns an empty list.
> Therefore method processAnnotations() of class OSGiAnnotations has no
> classes to iterate over an leaves the default scope to "COMPOSITE".
> Maybe there's something missing in the bundles manifest file ? What
> should be included in this calls list and where/how is it configured.
> Or am I on a wrong track ?
>
>
> Bye,
> Daniel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
--
Thank you...
Regards,
Rajini
AW: Question about Conversational OSGi Services and Service References
Posted by Da...@empolis.com.
Hi Radjini,
> You cannot set servicefactory to true inside an immediate
> component. Since the service is not registered by OSGi DS in
> the OSGi registry in this case, implementation.osgi never
> finds it - hence the infinite loop.
Yes, configuring it in this way makes no sense. A warning would be nice
:-)
> With immediate=false, I would have expected a new instance to
> be created for Gamma for each conversation.
>
> Could you check if the following are true?
>
>
> 1. GammaImpl should contain the annotation
> @Scope("CONVERSATION") on
> the class. Not necessarily conversation - anything other
> than COMPOSITE.
Yes, this is true. It is marked with @Scope("CONVERSATION")
> 2. The bundle containing GammaImpl should import
> org.osoa.sca.annotations
> (ie. @Scope annotation should be visible from the bundle)
Yes, this is also true
> 3. If 1) and 2) are true, could you breakpoint in the
> constructor of
> GammaImpl (or anywhere in that class) and check that you
> have a bundle
> installed with name "dummy.sca.xxxxx"? implementation.osgi
> should be using a
> dummy bundle to get a reference to the Gamma service if it
> has identified
> that the scope is not composite.
I could not see a bundle "dummy.sca.*" in the equinox console.
While debugging, I noticed the following in class OSGiInstanceWrapper:
In line 119
if (!annotationProcessor.getScope().equals(Scope.COMPOSITE))
the getScope() returns "COMPOSITE", not "CONVERSATION"
So line 118
refBundle = getDummyReferenceBundle();
is not executed
So it seems that the annotation was not found or not processed
correctly.
After some further debugging:
In OSGiImplementationProvider in line 162 implementation.getClassList()
returns an empty list.
Therefore method processAnnotations() of class OSGiAnnotations has no
classes to iterate over an leaves the default scope to "COMPOSITE".
Maybe there's something missing in the bundles manifest file ? What
should be included in this calls list and where/how is it configured.
Or am I on a wrong track ?
Bye,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Question about Conversational OSGi Services and Service References
Posted by Rajini Sivaram <ra...@googlemail.com>.
Daniel,
You cannot set servicefactory to true inside an immediate component. Since
the service is not registered by OSGi DS in the OSGi registry in this case,
implementation.osgi never finds it - hence the infinite loop.
With immediate=false, I would have expected a new instance to be created for
Gamma for each conversation.
Could you check if the following are true?
1. GammaImpl should contain the annotation @Scope("CONVERSATION") on
the class. Not necessarily conversation - anything other than COMPOSITE.
2. The bundle containing GammaImpl should import org.osoa.sca.annotations
(ie. @Scope annotation should be visible from the bundle)
3. If 1) and 2) are true, could you breakpoint in the constructor of
GammaImpl (or anywhere in that class) and check that you have a bundle
installed with name "dummy.sca.xxxxx"? implementation.osgi should be using a
dummy bundle to get a reference to the Gamma service if it has identified
that the scope is not composite.
On 4/7/08, Daniel.Stucky@empolis.com <Da...@empolis.com> wrote:
> Hi Rajini,
>
> Thanks for your answer. It improved my understanding of SCA scopes in OSGi
> services.
> The last part (using osgi bundles but not osgi services) works fine, I
> just wanted to experiment with osgi Declarative Services.
>
> I added servicefactory="true" to my osgi service description. It still
> also contained immediate="true", which seems to be opposed.
> With these settings my test ran into an infinite loop in method
> getOSGiServiceReference(Interface serviceInterface, String filter, String
> scaServiceName) of class OSGiImplementationProvider. The while loop never
> completes, as osgiServiceReference is always null.
>
> So I set immediate="true". Now I have the same behavior as described in my
> previous mail. So servicefactory="true" seems to have no effect.
>
> As I understood your comments, there is no need to implement a Factory
> class when using Declarative Services, right ?
> This is my component description file:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <component name="GammaDS" immediate="false">
> <implementation class="services.GammaImpl" />
> <service servicefactory="true">
> <provide interface="services.Gamma"/>
> </service>
> <property name="org.eclipse.test.type" value="test1"/>
> </component>
>
> Any ideas what's the issue here ?
> Thanks in advance.
>
> Bye,
> Daniel
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Rajini Sivaram [mailto:rajinisivaram@googlemail.com]
> > Gesendet: Sonntag, 6. April 2008 22:02
> > An: tuscany-user@ws.apache.org
> > Betreff: Re: Question about Conversational OSGi Services and
> > Service References
> >
> > Daniel,
> >
> > The default scope for implementation.osgi components is
> > COMPOSITE - this matches standard OSGi services where a
> > single instance of the service is added to the OSGi service
> > registry and the same instance is returned by any OSGi
> > registry lookup. Other SCA scopes including CONVERSATION are
> > supported by implementation.osgi, but they require the OSGi
> > service to be implemented using service factories. If a
> > service factory is registered for Gamma, Tuscany will force a
> > new instance of Gamma to be created for every new
> > conversation. There is an example of conversational services
> > using OSGi procedural services under
> > itest/osgi-implementation. It is much simpler with
> > declarative services since you would just need to specify the
> > servicefactory flag for the service.
> >
> > If you want to use a conversational service with Tuscany
> > without registering the service in the OSGi registry, you can
> > use implementation.java. Since your contribution is a bundle,
> > OSGi will still be used to resolve your classes, but the
> > conversational service instances can be created directly
> > without going through OSGi service factories.
> >
> > Hope this helps.
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
--
Thank you...
Regards,
Rajini
AW: Question about Conversational OSGi Services and Service References
Posted by Da...@empolis.com.
Hi Rajini,
Thanks for your answer. It improved my understanding of SCA scopes in OSGi services.
The last part (using osgi bundles but not osgi services) works fine, I just wanted to experiment with osgi Declarative Services.
I added servicefactory="true" to my osgi service description. It still also contained immediate="true", which seems to be opposed.
With these settings my test ran into an infinite loop in method getOSGiServiceReference(Interface serviceInterface, String filter, String scaServiceName) of class OSGiImplementationProvider. The while loop never completes, as osgiServiceReference is always null.
So I set immediate="true". Now I have the same behavior as described in my previous mail. So servicefactory="true" seems to have no effect.
As I understood your comments, there is no need to implement a Factory class when using Declarative Services, right ?
This is my component description file:
<?xml version="1.0" encoding="UTF-8"?>
<component name="GammaDS" immediate="false">
<implementation class="services.GammaImpl" />
<service servicefactory="true">
<provide interface="services.Gamma"/>
</service>
<property name="org.eclipse.test.type" value="test1"/>
</component>
Any ideas what's the issue here ?
Thanks in advance.
Bye,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: Rajini Sivaram [mailto:rajinisivaram@googlemail.com]
> Gesendet: Sonntag, 6. April 2008 22:02
> An: tuscany-user@ws.apache.org
> Betreff: Re: Question about Conversational OSGi Services and
> Service References
>
> Daniel,
>
> The default scope for implementation.osgi components is
> COMPOSITE - this matches standard OSGi services where a
> single instance of the service is added to the OSGi service
> registry and the same instance is returned by any OSGi
> registry lookup. Other SCA scopes including CONVERSATION are
> supported by implementation.osgi, but they require the OSGi
> service to be implemented using service factories. If a
> service factory is registered for Gamma, Tuscany will force a
> new instance of Gamma to be created for every new
> conversation. There is an example of conversational services
> using OSGi procedural services under
> itest/osgi-implementation. It is much simpler with
> declarative services since you would just need to specify the
> servicefactory flag for the service.
>
> If you want to use a conversational service with Tuscany
> without registering the service in the OSGi registry, you can
> use implementation.java. Since your contribution is a bundle,
> OSGi will still be used to resolve your classes, but the
> conversational service instances can be created directly
> without going through OSGi service factories.
>
> Hope this helps.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Question about Conversational OSGi Services and Service References
Posted by Rajini Sivaram <ra...@googlemail.com>.
Daniel,
The default scope for implementation.osgi components is COMPOSITE - this
matches standard OSGi services where a single instance of the service is
added to the OSGi service registry and the same instance is returned by any
OSGi registry lookup. Other SCA scopes including CONVERSATION are supported
by implementation.osgi, but they require the OSGi service to be implemented
using service factories. If a service factory is registered for Gamma,
Tuscany will force a new instance of Gamma to be created
for every new conversation. There is an example of conversational services
using OSGi procedural services under itest/osgi-implementation. It is much
simpler with declarative services since you would just need to specify the
servicefactory flag for the service.
If you want to use a conversational service with Tuscany without registering
the service in the OSGi registry, you can use implementation.java. Since
your contribution is a bundle, OSGi will still be used to resolve your
classes, but the conversational service instances can be created directly
without going through OSGi service factories.
Hope this helps.
On 4/4/08, Daniel.Stucky@empolis.com <Da...@empolis.com> wrote:
>
> Hi all,
>
> We currently have a problem when using OSGi bundles
> (implementation.osgi) for SCA components instead of pure Java
> (implementation.java ).
>
> Again here is my "formidable" example using 3 Services Alpha, Beta and
> Gamma.
> Alpha.doSomething() calls Beta.getRef() which creates a reference to
> Gamma and returns it to Alpha.
> Alpha then executes Gamme.doSomethingElse().
> Gamma is marked wirh @Conversational and it's implementation with
> @Scope("CONVERSATION")
>
>
> If Alpha.doSomething() is executed twice (one after the other) the
> sample works well (without any error). ConversationIDs are created and
> reused. However, the OSGi implementation uses the same ConversationID in
> both calls of Alpha.doSomething(). In the pure Java implementation the
> ConversationIDs are different. Also, the Constructor for Gamma is not
> called in Beta.getRef() in the OSGi implementation.
>
>
> If I mark Alpha.doSomething() with @OneWay and Alpha.doSomething() is
> executed twice (now in "parallel" because of @OneWay) the sample still
> works for the pure Java implementation, but not for the OSGi
> implementation.
>
> The difference is, that in the OSGi implementation Beta.getRef(), which
> creates the ServiceReference to Gamma, the constructor of Gamma is NOT
> called. Thus, only one instance of Gamma exists and so only one
> ConversationId exists and is used two times (once for each call of
> Alpha.doSomething(). This leads to internal eerrors in
> Gamme.doSomethingElse().
>
> In the pure Java implementation the Constructor of Gamma is called
> twice, resulting in two instances and two seperate ConversationIDs.
>
> Is there something special we have to configure for OSGi services ? Do
> they support "Conversations" or do we have to implement conversation
> logic seperately ?
>
> Help is most welcome.
>
> Bye,
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
--
Thank you...
Regards,
Rajini