| From | Sent On | Attachments |
|---|---|---|
| Michael Rowley | Sep 25, 2007 3:21 pm | |
| Barack, Ron | Oct 4, 2007 2:30 am | |
| Michael Rowley | Oct 4, 2007 6:30 am | |
| Michael Rowley | Oct 18, 2007 11:48 am | |
| David Booz | Nov 1, 2007 9:53 am | |
| Michael Rowley | Nov 5, 2007 8:53 am | |
| Simon Nash | Nov 5, 2007 10:46 am | |
| Reza Shafii | Nov 5, 2007 10:54 am | |
| Simon Nash | Nov 5, 2007 1:10 pm | |
| David Booz | Nov 7, 2007 12:59 pm | |
| Blohm, Henning | Nov 8, 2007 5:55 am | |
| Michael Rowley | Nov 14, 2007 1:34 am | |
| Michael Rowley | Nov 14, 2007 1:34 am | |
| David Booz | Nov 14, 2007 7:41 am | |
| Simon Nash | Nov 14, 2007 2:46 pm |
| Subject: | RE: [sca-j] ISSUE 3 - Local services expose implementation classes as their type | |
|---|---|---|
| From: | Michael Rowley (mrow...@bea.com) | |
| Date: | Nov 5, 2007 8:53:40 am | |
| List: | org.oasis-open.lists.sca-j | |
inline...
-----Original Message----- From: David Booz [mailto:bo...@us.ibm.com] Sent: Thursday, November 01, 2007 12:55 PM To: sca...@lists.oasis-open.org Subject: RE: [sca-j] ISSUE 3 - Local services expose implementation classes as their type
I think we haven't completely dealt with this issue of local interfaces. In
the context of this proposal, I have to raise the question of why there is
no corresponding assembly model change.
I don't believe a change to the assembly model is needed. The @Local annotation does not actually change the semantics of an interface. Merely _not_ having an @Remotable also means that the interface is local. However, by using @Local, you are causing classes that implement that interface to have a <service> declaration generated for it, where it wouldn't have had a service declared if there hadn't been a @Local annotation. It also plays a documentation role - making it clearer that the interface is purposefully using local semantics (the @Remotable annotation wasn't just forgotten).
What does the generated
componentType look like when used with @Local interfaces?
A service declaration for each implemented interface that had been marked @Local, pointing to that interface for its type.
Is it legal to
specify a <sca:binding/> on the <sca:service/> that is derived from
implementing an @Local interface?
The main reason I would think that the answer is "no", is that I don't think it makes sense for local communication by-reference calls to go through a binding. Can you think of a case where that would be useful?
If not, how do you know it's local?
Because of the @Local annotation on the interface that is referenced. (Although, perhaps I didn't understand your question.)
This is certainly a problem in the existing spec, so maybe this is a new
issue, we can discuss on the call.
Michael
Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:bo...@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
"Michael Rowley"
<mrow...@bea.com>
To
10/18/2007 02:48 "Michael Rowley" <mrow...@bea.com>,
PM <sca...@lists.oasis-open.org>
cc
Subject
RE: [sca-j] ISSUE 3 - Local
services expose implementation
classes as their type
PROPOSAL:
Introduce a new interface annotation called @Local. If a component
implementation implements an interface that has been marked as @Local, then
the component type will include a service whose type is that
(non-remotable) interface. In this way, the @Local annotation is similar
to the @Remotable annotation, but without implying remote-call semantics.
The rules for generating services for a class that does not include the
@Service annotation are the following:
1) If the class implements interfaces, generate services for each
implemented interface that has been marked as either @Remotable or @Local,
where the type of the service is that interface. Any implemented
interfaces that have not been marked as either @Remotable or @Local do not
have services generated for them.
2) If none of the interfaces implemented by the class has been marked as
@Remotable or @Local, then generate a service for each implemented
interface that is not a "marker interface" (i.e. an interface with no
methods, like Serializable).
3) If the class implements no interfaces, then it offers a single service
whose type is that class.
Michael
From: Barack, Ron [mailto:ron....@sap.com]
Sent: Thursday, October 04, 2007 5:27 AM.
To: sca...@lists.oasis-open.org
Subject: [sca-j] ISSUE LOGGED: JAVA-3: Local services expose
implementation classes as their type
http://www.osoa.org/jira/browse/JAVA-3
Von:: Michael Rowley [mailto:mrow...@bea.com]
Gesendet: Mittwoch, 26. September 2007 00:22.
An: sca...@lists.oasis-open.org
Betreff: [sca-j] NEW ISSUE: Local services expose
implementation classes as their type
TARGET: Java Common Annotations and APIs specification
Java Component Implementation Specification
Section titled: "Local and Remotable Services"
DESCRIPTION:
Currently, this section states the following:
If an implementation class has implemented interfaces that
are not decorated with an @Remotable annotation, the class
is considered to implement a single local service whose type
is defined by the class.
This is unfortunate, since the extremely common pattern of:
class FooImpl implements Foo {}
Will result in a component that offers a service whose type is
FooImpl (assuming that Foo hasn't been marked as @Remotable).
It should be possible for this pattern to result in a service
whose type is the Foo interface.'
PROPOSAL:
Introduce a new interface annotation called @Local. If a
component implementation implements an interface that has been
marked as @Local, then the component type will include a
service whose type is that interface.





