[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-j] ISSUE 3 - Local services expose implementation classes as theirtype
My comment about the side file was not related to the use of annotations.
It was related to the proposed rule that in the absence of annotations,
all non-marker interfaces should be considered to represent local
services. I think it's enough to support annotations (we are still
discussing which ones) and side files. We don't need a third case with
some arbitrary default rule.
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>
14/11/2007 09:34
To
Simon Nash/UK/IBM@IBMGB, <sca-j@lists.oasis-open.org>
cc
Subject
RE: [sca-j] ISSUE 3 - Local services expose implementation classes as
their type
Yes, this scenario could be handled by a component type side file.
However, we've also added annotations for many of the things that can be
accomplished in a side file. I think this one qualifies.
Michael
-----Original Message-----
From: Simon Nash [mailto:NASH@uk.ibm.com]
Sent: Monday, November 05, 2007 2:02 PM
To: sca-j@lists.oasis-open.org
Subject: RE: [sca-j] ISSUE 3 - Local services expose implementation
classes as their type
Can't this scenario be handled by specifying a componentType file?
What if my Java class is implementing non-marker interfaces A and B, and
I
want A to be a service but not B?
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
"Reza Shafii" <rshafii@bea.com>
05/11/2007 18:54
To
Simon Nash/UK/IBM@IBMGB, <sca-j@lists.oasis-open.org>
cc
Subject
RE: [sca-j] ISSUE 3 - Local services expose implementation classes as
their type
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.
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
---------------------------------------------------------------------
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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]