RE: [sca-j] ISSUE 3 - Local services expose implementation classes as their type

["Reza Shafii" <rshafii@bea.com>]

The argument for point 2 is that it allows the use of a Java class and
its implemented interfaces as a component implementation without the
need to modify them at all. I think that this would be useful in
situations where:

A) You would rather not introduce any SCA markup within your code.
B) Have access to the implementation code as a library but cannot modify
it. 

Cheers,

Reza

-----Original Message-----
From: Simon Nash [mailto:NASH@uk.ibm.com] 
Sent: Monday, November 05, 2007 10:46 AM
To: sca-j@lists.oasis-open.org
Subject: RE: [sca-j] ISSUE 3 - Local services expose implementation
classes as their type

I'm OK with most of this but I don't agree with the paragraph starting
2). 
 The value of having @Local is that it makes the definition of local 
services explicit, either by @Service or @Local.  I don't think services

should ever be generated from interfaces without an explicit indication 
that this was intended.

    Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999



"Michael Rowley" <mrowley@bea.com> 
18/10/2007 19:48

To
"Michael Rowley" <mrowley@bea.com>, <sca-j@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.barack@sap.com] 
Sent: Thursday, October 04, 2007 5:27 AM
To: sca-j@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:mrowley@bea.com] 
Gesendet: Mittwoch, 26. September 2007 00:22
An: sca-j@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.
 






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number

741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU







---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.