You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Raymond Feng (JIRA)" <tu...@ws.apache.org> on 2007/07/17 23:34:04 UTC
[jira] Created: (TUSCANY-1447) Service introspection for a java
implementation class behaves differently from what's the SCA java spec 1.0
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
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
[jira] Resolved: (TUSCANY-1447) Service introspection for a java
implementation class behaves differently from what's the SCA java spec 1.0
Posted by "Jean-Sebastien Delfino (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Sebastien Delfino resolved TUSCANY-1447.
---------------------------------------------
Resolution: Fixed
Applied the patch and adjusted the few test cases that were not in line with the spec.
Thanks!
> 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
> Assignee: Jean-Sebastien Delfino
> 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
[jira] Assigned: (TUSCANY-1447) Service introspection for a java
implementation class behaves differently from what's the SCA java spec 1.0
Posted by "Jean-Sebastien Delfino (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Sebastien Delfino reassigned TUSCANY-1447:
-----------------------------------------------
Assignee: Jean-Sebastien Delfino
> 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
> Assignee: Jean-Sebastien Delfino
> 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
[jira] Updated: (TUSCANY-1447) Service introspection for a java
implementation class behaves differently from what's the SCA java spec 1.0
Posted by "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
[jira] Updated: (TUSCANY-1447) Service introspection for a java
implementation class behaves differently from what's the SCA java spec 1.0
Posted by "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:
----------------------------------
Patch Info: [Patch Available]
> 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