Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Service Component Architecture (SCA) Tools » Re: [frascati] SCA API in the STP/SCA project
Re: [frascati] SCA API in the STP/SCA project [message #7867] Mon, 25 May 2009 01:28 Go to next message
Vincent Zurczak is currently offline Vincent Zurczak
Messages: 140
Registered: July 2009
Senior Member
Hi Lionel.

I CC'ed this question to the SCA Tools newsgroup.


Vincent.




Lionel Seinturier a écrit :
> Hi Stéphane,
>
> I have a couple of remarks about the SCA Java API that you committed
in the STP/SCA SVN:
>
>
http://dev.eclipse.org/svnroot/stp/org.eclipse.stp.sca-tools /org.eclipse.stp.sca/trunk/org.eclipse.stp.sca.osoa.java
>
> I'm not sure whether there is a mailing list where these remarks can
be sent, so I'm sending them to you privately. In any case such a ML
exists and I missed it, do not hesitate to mention it: I'll resend my
message for the record and the community.
>
>
> 1/ In interface Conversation: shouldn't method getConversionID() be
spelled getConversationID()?
>
> Version 1.00 of the specs (Java Client and Implementation
Specification) says:
>
> ----------------------------
> public interface Conversation {
> Object getConversionID();
> void end();
> }
>
> The ServiceReference (sic!!) Java interface has the following methods:
> * getConversationID() – Returns the identifier for this conversation.
If a user-defined identity had been supplied for this reference then its
value will be returned; otherwise the identity generated by the system
when the conversation was initiated will be returned.
> * end() – Ends this conversation.
> ----------------------------
>
> The code snippet declares getConversionID, but the comment provides
the more intuitive version getConversationID. I guess we can assume that
the code snippet contains a typo and that the correct version is
getConversationID.
>
> BTW it is also clear that the comment contains a typo: one should
read "The Conversation Java interface" and not "The ServiceReference
Java interface".
>
>
> 2/ Shouldn't class NoRegistredCallbackException be spelled
NoRegisteredCallbackException?
>
>
> 3/ It would be nice if the ConversationEndedException,
ServiceRuntimeException and ServiceUnavailableException exceptions would
declare four constructors to override the ones declared in RuntimeException:
> - no arg
> - (String)
> - (String,Throwable)
> - (Throwable)
>
>
> Lionel.
>


--
Vincent Zurczak
EBM WebSourcing
+33 (0) 4 38 12 16 77
Re: [frascati] SCA API in the STP/SCA project [message #7888 is a reply to message #7867] Mon, 25 May 2009 08:53 Go to previous messageGo to next message
Stephane Drapeau is currently offline Stephane Drapeau
Messages: 198
Registered: July 2009
Senior Member
Hi Lionel,

You're right about these 3 issues. Can you open a bug?

Thanks,

Stephane Drapeau
Obeo

Vincent Zurczak a écrit :
> Hi Lionel.
>
> I CC'ed this question to the SCA Tools newsgroup.
>
>
> Vincent.
>
>
>
>
> Lionel Seinturier a écrit :
> > Hi Stéphane,
> >
> > I have a couple of remarks about the SCA Java API that you committed
> in the STP/SCA SVN:
> >
> >
> http://dev.eclipse.org/svnroot/stp/org.eclipse.stp.sca-tools /org.eclipse.stp.sca/trunk/org.eclipse.stp.sca.osoa.java
>
> >
> > I'm not sure whether there is a mailing list where these remarks can
> be sent, so I'm sending them to you privately. In any case such a ML
> exists and I missed it, do not hesitate to mention it: I'll resend my
> message for the record and the community.
> >
> >
> > 1/ In interface Conversation: shouldn't method getConversionID() be
> spelled getConversationID()?
> >
> > Version 1.00 of the specs (Java Client and Implementation
> Specification) says:
> >
> > ----------------------------
> > public interface Conversation {
> > Object getConversionID();
> > void end();
> > }
> >
> > The ServiceReference (sic!!) Java interface has the following methods:
> > * getConversationID() – Returns the identifier for this conversation.
> If a user-defined identity had been supplied for this reference then its
> value will be returned; otherwise the identity generated by the system
> when the conversation was initiated will be returned.
> > * end() – Ends this conversation.
> > ----------------------------
> >
> > The code snippet declares getConversionID, but the comment provides
> the more intuitive version getConversationID. I guess we can assume that
> the code snippet contains a typo and that the correct version is
> getConversationID.
> >
> > BTW it is also clear that the comment contains a typo: one should
> read "The Conversation Java interface" and not "The ServiceReference
> Java interface".
> >
> >
> > 2/ Shouldn't class NoRegistredCallbackException be spelled
> NoRegisteredCallbackException?
> >
> >
> > 3/ It would be nice if the ConversationEndedException,
> ServiceRuntimeException and ServiceUnavailableException exceptions would
> declare four constructors to override the ones declared in
> RuntimeException:
> > - no arg
> > - (String)
> > - (String,Throwable)
> > - (Throwable)
> >
> >
> > Lionel.
> >
>
>
Re: [frascati] SCA API in the STP/SCA project [message #7909 is a reply to message #7888] Wed, 27 May 2009 07:44 Go to previous messageGo to next message
Lionel Seinturier is currently offline Lionel Seinturier
Messages: 4
Registered: July 2009
Junior Member
Hi Stephane,

On 25/05/2009 14:53, Stephane Drapeau wrote:
> Hi Lionel,
>
> You're right about these 3 issues. Can you open a bug?

Thanks for having solved these issues.

I'd like to report another issue which I'm facing. It is related to the
ComponentContext interface and the 2 cast methods which are declared:

-------------
<B, R extends CallableReference<B>> R cast(B target) throws
IllegalArgumentException;
<B> ServiceReference<B> cast(B target) throws IllegalArgumentException;
-------------

These two declarations are apparently consistent with the specs (see p13
of Java Client and Implementation Specification 1.00). I'm saying
apparently since the comment which follows on p14 only provides some
information for the 1st one.

-------------
cast(B target) - Casts a type-safe reference to a CallableReference
-------------

So it is not really clear to me whether the intent of the authors was to
really define 2 methods or if the 2nd version can be considered as a
typo which should have been removed from the final version of the specs.

Anyway, assuming that both versions should be present, the issue arises
when compiling some code which uses ComponentContext. E.g.

-------------
ComponentContext cc = null; // a non-null value fits also
A a = new A();
ServiceReference<A> sr = cc.cast(a);
-------------

Both Sun JDK 5 and 6 javac (on Windows - I haven't try but I guess this
is the same under Linux and MacOS) fails with the following error message:

-------------
src\org\osoa\sca\A.java:8: reference to cast is ambiguous, both method
<B,R>cast(B) in org.osoa.sca.ComponentContext and method <B>cast(B) in
org.osoa.sca.ComponentContext match
ServiceReference<A> sr = cc.cast(a);
^
1 error
-------------

JDK is unable to lookup the correct version of cast. JDT is more
optimistic and compiles the code, but in fact, select the first version
(which is wrong since the intent is here to select the 2nd one.)

So my first remark is: is there a Java generics guru who can explain how
to use these two versions correctly?


My second remark consists in reporting that some friends chose to keep
only the first version of the cast method and to remove the second one:

see
http://svn.apache.org/repos/asf/tuscany/java/sca/modules/sca -api-osoa/src/main/java/org/osoa/sca/ComponentContext.java

I find that this choice is the most logical one. I would then suggest
that we consider that this is the de facto standard and that the 2nd
version of cast() should be removed from the
org.eclipse.stp.sca.osoa.java module.

WDYT?

Lionel.
Re: [frascati] SCA API in the STP/SCA project [message #7925 is a reply to message #7909] Wed, 27 May 2009 08:10 Go to previous message
Stephane Drapeau is currently offline Stephane Drapeau
Messages: 198
Registered: July 2009
Senior Member
Yep, the second method "is a spurious hangover from ancient history":
http://www.osoa.org/jira/browse/JAVA-112

Can you open a bug?

Stephane Drapeau
Obeo


Lionel Seinturier a écrit :
> Hi Stephane,
>
> On 25/05/2009 14:53, Stephane Drapeau wrote:
>> Hi Lionel,
>>
>> You're right about these 3 issues. Can you open a bug?
>
> Thanks for having solved these issues.
>
> I'd like to report another issue which I'm facing. It is related to the
> ComponentContext interface and the 2 cast methods which are declared:
>
> -------------
> <B, R extends CallableReference<B>> R cast(B target) throws
> IllegalArgumentException;
> <B> ServiceReference<B> cast(B target) throws IllegalArgumentException;
> -------------
>
> These two declarations are apparently consistent with the specs (see p13
> of Java Client and Implementation Specification 1.00). I'm saying
> apparently since the comment which follows on p14 only provides some
> information for the 1st one.
>
> -------------
> cast(B target) - Casts a type-safe reference to a CallableReference
> -------------
>
> So it is not really clear to me whether the intent of the authors was to
> really define 2 methods or if the 2nd version can be considered as a
> typo which should have been removed from the final version of the specs.
>
> Anyway, assuming that both versions should be present, the issue arises
> when compiling some code which uses ComponentContext. E.g.
>
> -------------
> ComponentContext cc = null; // a non-null value fits also
> A a = new A();
> ServiceReference<A> sr = cc.cast(a);
> -------------
>
> Both Sun JDK 5 and 6 javac (on Windows - I haven't try but I guess this
> is the same under Linux and MacOS) fails with the following error message:
>
> -------------
> src\org\osoa\sca\A.java:8: reference to cast is ambiguous, both method
> <B,R>cast(B) in org.osoa.sca.ComponentContext and method <B>cast(B) in
> org.osoa.sca.ComponentContext match
> ServiceReference<A> sr = cc.cast(a);
> ^
> 1 error
> -------------
>
> JDK is unable to lookup the correct version of cast. JDT is more
> optimistic and compiles the code, but in fact, select the first version
> (which is wrong since the intent is here to select the 2nd one.)
>
> So my first remark is: is there a Java generics guru who can explain how
> to use these two versions correctly?
>
>
> My second remark consists in reporting that some friends chose to keep
> only the first version of the cast method and to remove the second one:
>
> see
> http://svn.apache.org/repos/asf/tuscany/java/sca/modules/sca -api-osoa/src/main/java/org/osoa/sca/ComponentContext.java
>
>
> I find that this choice is the most logical one. I would then suggest
> that we consider that this is the de facto standard and that the 2nd
> version of cast() should be removed from the
> org.eclipse.stp.sca.osoa.java module.
>
> WDYT?
>
> Lionel.
Re: [frascati] SCA API in the STP/SCA project [message #575102 is a reply to message #7867] Mon, 25 May 2009 08:53 Go to previous message
Stephane Drapeau is currently offline Stephane Drapeau
Messages: 198
Registered: July 2009
Senior Member
Hi Lionel,

You're right about these 3 issues. Can you open a bug?

Thanks,

Stephane Drapeau
Obeo

Vincent Zurczak a écrit :
> Hi Lionel.
>
> I CC'ed this question to the SCA Tools newsgroup.
>
>
> Vincent.
>
>
>
>
> Lionel Seinturier a écrit :
> > Hi Stéphane,
> >
> > I have a couple of remarks about the SCA Java API that you committed
> in the STP/SCA SVN:
> >
> >
> http://dev.eclipse.org/svnroot/stp/org.eclipse.stp.sca-tools /org.eclipse.stp.sca/trunk/org.eclipse.stp.sca.osoa.java
>
> >
> > I'm not sure whether there is a mailing list where these remarks can
> be sent, so I'm sending them to you privately. In any case such a ML
> exists and I missed it, do not hesitate to mention it: I'll resend my
> message for the record and the community.
> >
> >
> > 1/ In interface Conversation: shouldn't method getConversionID() be
> spelled getConversationID()?
> >
> > Version 1.00 of the specs (Java Client and Implementation
> Specification) says:
> >
> > ----------------------------
> > public interface Conversation {
> > Object getConversionID();
> > void end();
> > }
> >
> > The ServiceReference (sic!!) Java interface has the following methods:
> > * getConversationID() – Returns the identifier for this conversation.
> If a user-defined identity had been supplied for this reference then its
> value will be returned; otherwise the identity generated by the system
> when the conversation was initiated will be returned.
> > * end() – Ends this conversation.
> > ----------------------------
> >
> > The code snippet declares getConversionID, but the comment provides
> the more intuitive version getConversationID. I guess we can assume that
> the code snippet contains a typo and that the correct version is
> getConversationID.
> >
> > BTW it is also clear that the comment contains a typo: one should
> read "The Conversation Java interface" and not "The ServiceReference
> Java interface".
> >
> >
> > 2/ Shouldn't class NoRegistredCallbackException be spelled
> NoRegisteredCallbackException?
> >
> >
> > 3/ It would be nice if the ConversationEndedException,
> ServiceRuntimeException and ServiceUnavailableException exceptions would
> declare four constructors to override the ones declared in
> RuntimeException:
> > - no arg
> > - (String)
> > - (String,Throwable)
> > - (Throwable)
> >
> >
> > Lionel.
> >
>
>
Re: [frascati] SCA API in the STP/SCA project [message #575128 is a reply to message #7888] Wed, 27 May 2009 07:44 Go to previous message
Lionel Seinturier is currently offline Lionel Seinturier
Messages: 4
Registered: July 2009
Junior Member
Hi Stephane,

On 25/05/2009 14:53, Stephane Drapeau wrote:
> Hi Lionel,
>
> You're right about these 3 issues. Can you open a bug?

Thanks for having solved these issues.

I'd like to report another issue which I'm facing. It is related to the
ComponentContext interface and the 2 cast methods which are declared:

-------------
<B, R extends CallableReference<B>> R cast(B target) throws
IllegalArgumentException;
<B> ServiceReference<B> cast(B target) throws IllegalArgumentException;
-------------

These two declarations are apparently consistent with the specs (see p13
of Java Client and Implementation Specification 1.00). I'm saying
apparently since the comment which follows on p14 only provides some
information for the 1st one.

-------------
cast(B target) - Casts a type-safe reference to a CallableReference
-------------

So it is not really clear to me whether the intent of the authors was to
really define 2 methods or if the 2nd version can be considered as a
typo which should have been removed from the final version of the specs.

Anyway, assuming that both versions should be present, the issue arises
when compiling some code which uses ComponentContext. E.g.

-------------
ComponentContext cc = null; // a non-null value fits also
A a = new A();
ServiceReference<A> sr = cc.cast(a);
-------------

Both Sun JDK 5 and 6 javac (on Windows - I haven't try but I guess this
is the same under Linux and MacOS) fails with the following error message:

-------------
src\org\osoa\sca\A.java:8: reference to cast is ambiguous, both method
<B,R>cast(B) in org.osoa.sca.ComponentContext and method <B>cast(B) in
org.osoa.sca.ComponentContext match
ServiceReference<A> sr = cc.cast(a);
^
1 error
-------------

JDK is unable to lookup the correct version of cast. JDT is more
optimistic and compiles the code, but in fact, select the first version
(which is wrong since the intent is here to select the 2nd one.)

So my first remark is: is there a Java generics guru who can explain how
to use these two versions correctly?


My second remark consists in reporting that some friends chose to keep
only the first version of the cast method and to remove the second one:

see
http://svn.apache.org/repos/asf/tuscany/java/sca/modules/sca -api-osoa/src/main/java/org/osoa/sca/ComponentContext.java

I find that this choice is the most logical one. I would then suggest
that we consider that this is the de facto standard and that the 2nd
version of cast() should be removed from the
org.eclipse.stp.sca.osoa.java module.

WDYT?

Lionel.
Re: [frascati] SCA API in the STP/SCA project [message #575139 is a reply to message #7909] Wed, 27 May 2009 08:10 Go to previous message
Stephane Drapeau is currently offline Stephane Drapeau
Messages: 198
Registered: July 2009
Senior Member
Yep, the second method "is a spurious hangover from ancient history":
http://www.osoa.org/jira/browse/JAVA-112

Can you open a bug?

Stephane Drapeau
Obeo


Lionel Seinturier a écrit :
> Hi Stephane,
>
> On 25/05/2009 14:53, Stephane Drapeau wrote:
>> Hi Lionel,
>>
>> You're right about these 3 issues. Can you open a bug?
>
> Thanks for having solved these issues.
>
> I'd like to report another issue which I'm facing. It is related to the
> ComponentContext interface and the 2 cast methods which are declared:
>
> -------------
> <B, R extends CallableReference<B>> R cast(B target) throws
> IllegalArgumentException;
> <B> ServiceReference<B> cast(B target) throws IllegalArgumentException;
> -------------
>
> These two declarations are apparently consistent with the specs (see p13
> of Java Client and Implementation Specification 1.00). I'm saying
> apparently since the comment which follows on p14 only provides some
> information for the 1st one.
>
> -------------
> cast(B target) - Casts a type-safe reference to a CallableReference
> -------------
>
> So it is not really clear to me whether the intent of the authors was to
> really define 2 methods or if the 2nd version can be considered as a
> typo which should have been removed from the final version of the specs.
>
> Anyway, assuming that both versions should be present, the issue arises
> when compiling some code which uses ComponentContext. E.g.
>
> -------------
> ComponentContext cc = null; // a non-null value fits also
> A a = new A();
> ServiceReference<A> sr = cc.cast(a);
> -------------
>
> Both Sun JDK 5 and 6 javac (on Windows - I haven't try but I guess this
> is the same under Linux and MacOS) fails with the following error message:
>
> -------------
> src\org\osoa\sca\A.java:8: reference to cast is ambiguous, both method
> <B,R>cast(B) in org.osoa.sca.ComponentContext and method <B>cast(B) in
> org.osoa.sca.ComponentContext match
> ServiceReference<A> sr = cc.cast(a);
> ^
> 1 error
> -------------
>
> JDK is unable to lookup the correct version of cast. JDT is more
> optimistic and compiles the code, but in fact, select the first version
> (which is wrong since the intent is here to select the 2nd one.)
>
> So my first remark is: is there a Java generics guru who can explain how
> to use these two versions correctly?
>
>
> My second remark consists in reporting that some friends chose to keep
> only the first version of the cast method and to remove the second one:
>
> see
> http://svn.apache.org/repos/asf/tuscany/java/sca/modules/sca -api-osoa/src/main/java/org/osoa/sca/ComponentContext.java
>
>
> I find that this choice is the most logical one. I would then suggest
> that we consider that this is the de facto standard and that the 2nd
> version of cast() should be removed from the
> org.eclipse.stp.sca.osoa.java module.
>
> WDYT?
>
> Lionel.
Previous Topic:Re: [frascati] SCA API in the STP/SCA project
Next Topic:STP/SCA org.eclipse.stp.sca.osoa.java module as a Maven artifact?
Goto Forum:
  


Current Time: Fri Aug 22 23:55:15 EDT 2014

Powered by FUDForum. Page generated in 0.09372 seconds