[jira] Updated: (TUSCANY-1447) Service introspection for a java implementation class behaves differently from what's the SCA java spec 1.0

["Raymond Feng (JIRA)" <tu...@ws.apache.org>]

     [ https://issues.apache.org/jira/browse/TUSCANY-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Raymond Feng updated TUSCANY-1447:
----------------------------------

    Attachment: HeuristicPojoProcessor.java

Here's a updated file based on 05/30 code base. Please review and apply.

> Service introspection for a java implementation class behaves differently from what's the SCA java spec 1.0
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-1447
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1447
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Java Implementation Extension
>    Affects Versions: Java-SCA-0.91, Java-SCA-Next
>            Reporter: Raymond Feng
>         Attachments: HeuristicPojoProcessor.java
>
>
> Here's the e-mail exchange I had with the spec group:
> Yes that is by design.  At one point in time, the algorithm was based on
> the one interface implemented by the class, if there was one. The
> problem had to do with classes defined like:
> public class MyService implements java.io.Serializable {
> }
> It would be wrong to have a single service whose type was Serializable.
> Having the class itself represent the type, probably isn't such a bad
> thing, since it provides a superset of the operations available on any
> of its implemented interfaces.
> However, having a service whose _name_ is "MyServiceImpl" is certainly
> awkward.  I simple fix would be to introduce a simple modification to
> the naming rule that accounts for this common idiom.  If the class ends
> with "Impl" then "Impl" is dropped from the service name.
> Michael
> -----Original Message-----
> From: Raymond Feng [mailto:enjoyjava@gmail.com] 
> Sent: Thursday, July 12, 2007 6:13 PM
> To: java@sca.projects.dev2dev.bea.com
> Subject: Algorithm to introspect the services offered by a java class 
> Hi,
> The SCA Java Component Implementation Spec defines an algorithm to 
> introspect the services offered by a java class as quoted below:
> Line 143:
> "1.2.1.3. Introspecting services offered by a Java implementation
> In the cases described below, the services offered by a Java
> implementation 
> class may be determined through introspection, eliding the need to
> specify 
> them using @Service. The following algorithm is used to determine how 
> services are introspected from an implementation class:
> If the interfaces of the SCA services are not specified with the
> @Service 
> annotation on the implementation class, it is assumed that all
> implemented 
> interfaces that have been annotated as @Remotable are the service
> interfaces 
> provided by the component. If none of the implemented interfaces is 
> remotable, then by default the implementation offers a single service
> whose 
> type is the implementation class."
> public interface MyService {
> ...
> }
> public class MyServiceImpl implements MyService {
> ...
> }
> By the spec, the service type would be MyServiceImpl.class and the name 
> would be "MyServiceImpl" since the MyService interface is not annotated
> with 
> @Remotable.
> I think the algorithm is a bit anti-heuristic for some simple cases
> where a 
> java class implements one or more local interfaces and many SCA users
> assume 
> MyService.class is the service type in this case. Can somebody confirm
> that 
> the algorithm is by design?
> Thanks,
> Raymond Feng
> Apache Tuscany
> rfeng@apache.org

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org