You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Ramkumar R <ra...@gmail.com> on 2008/08/07 20:13:56 UTC
[DISCUSS] Spring Implicit Services Specs Vs Implementation
Hi All,
This discussion is taken into account with reference to the JIRA,
TUSCANY-2258. Lets see some background from the specs as well as with the
current implementation on this issue.
FROM THE SPECS:
Each <service> element used with <implementation.spring> should include the
name of the Spring bean that is to be exposed as an SCA service in its name
attribute. So, for Spring, the name attribute of a service plays two roles:
it identifies a Spring bean, and it names the service for the component.
Example-Spring Application Context:
<beans>
<bean id="X" class="org.xyz.someapp.SomeClass">
<property name="foo" ref="Y"/>
</bean>
</beans>
Example-SCA Composite using the above Spring Context:
<composite name="BazComposite">
<component name="SpringComponent">
<implementation.spring location=".."/>
<service name="X"/>
<reference name="SCAReference" .../> <!-- binding info specified -->
</component>
</composite>
As per the specs, The service element above has a name of "X", so there
should be a Spring bean with that name.
CURRENT IMPLEMENTATION: When explicit service definition in the Spring
Context is absent, current implementation introspects the java classes and
identifies the implemented interface of "org.xyz.someapp.SomeClass" as
service name.
SO WHAT IS THE CONFUSION HERE:
The specs only says that in case of implicit services the bean name and the
service name should be the same, instead of saying that the bean, service
and the interface name should be identical is such cases.
For me the implementation provided makes more sense, I believe the Specs
need a change here.
Please let me know any suggestions/comments for the same. Thanks.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Spring Implicit Services Specs Vs Implementation
Posted by Ramkumar R <ra...@gmail.com>.
Hi Mike,
My Comments inline....
On Fri, Aug 8, 2008 at 11:24 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
>
> On Thu, Aug 7, 2008 at 11:43 PM, Ramkumar R <ramkumar.rj@gmail.com<mailto:
>> ramkumar.rj@gmail.com>> wrote:
>>
>>
>> SO WHAT IS THE CONFUSION HERE:
>> The specs only says that in case of implicit services the bean name
>> and the service name should be the same, instead of saying that the
>> bean, service and the interface name should be identical is such cases.
>>
>>
>> Wanted to make a small correction from my previous statement, it should be
>> "The specs says that in case of implicit services the bean name and the
>> service name should be the same, instead of saying the service name and the
>> interface name should be identical".
>> More finding on this ground: There seems to be a correction required for
>> Implicit References too. In case of implicit references the property name
>> and the ref name should be identical to the interface name as shown
>> below....
>>
>> <property name="addService" ref="addService"/>
>>
>
> Why should this be the case? I don't follow. Could you explain in some
> detail, please?
I apologize for my comments regarding the implicit references, the statement
"In case of implicit references the property name and the ref name should be
identical to the interface name" is not true. Implicit references seems to
be working fine as per the specs.
> Additionally, in both the above scenarios where implicit
> services/references are used, its mandatory that the implementation class
> must use proper annotations to mark its services and references as shown
> below.
>
> @Service(CalculatorService.class)
> public class CalculatorServiceImpl implements CalculatorService {
>
> private AddService addService;
>
> @Reference
> public void setAddService(AddService addService) {
> this.addService = addService;
> }
>
> I don't think this is right at all. The whole point of the implicit case
> is that the classes (and the Application Context) are NOT SCA-aware - so
> would not normally have any annotations - remember, the use case is re-use
> of existing Application Contexts. Making the annotations mandatory
> undermines this scenario completely.
>
> If the app context is being created as SCA-aware, then it is easy to
> provide the appropriate annotations in the Application Context - of course,
> annotations in the code are fine too, but they are not a requirement.
>
Regarding Annotations I just wanted to update that, with current
implementation the implicit serivces seems to be working when @Service
annotation is used, that's the reason why i thought this might be mandatory.
As you explained that the use-case is to re-use the existing application
context this would not make sense. I agree on that, so the implementation
needs a change here.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Spring Implicit Services Specs Vs Implementation
Posted by Mike Edwards <mi...@gmail.com>.
Ramkumar,
More comments inline....
Ramkumar R wrote:
> On Thu, Aug 7, 2008 at 11:43 PM, Ramkumar R <ramkumar.rj@gmail.com
> <ma...@gmail.com>> wrote:
>
>
> SO WHAT IS THE CONFUSION HERE:
> The specs only says that in case of implicit services the bean name
> and the service name should be the same, instead of saying that the
> bean, service and the interface name should be identical is such cases.
>
>
> Wanted to make a small correction from my previous statement, it should
> be "The specs says that in case of implicit services the bean name and
> the service name should be the same, instead of saying the service name
> and the interface name should be identical".
>
> More finding on this ground: There seems to be a correction required for
> Implicit References too. In case of implicit references the property
> name and the ref name should be identical to the interface name as shown
> below....
>
> <property name="addService" ref="addService"/>
Why should this be the case? I don't follow. Could you explain in some detail, please?
>
> Additionally, in both the above scenarios where implicit
> services/references are used, its mandatory that the implementation
> class must use proper annotations to mark its services and references as
> shown below.
>
> @Service(CalculatorService.class)
> public class CalculatorServiceImpl implements CalculatorService {
>
> private AddService addService;
>
> @Reference
> public void setAddService(AddService addService) {
> this.addService = addService;
> }
>
I don't think this is right at all. The whole point of the implicit case is that the classes (and
the Application Context) are NOT SCA-aware - so would not normally have any annotations - remember,
the use case is re-use of existing Application Contexts. Making the annotations mandatory
undermines this scenario completely.
If the app context is being created as SCA-aware, then it is easy to provide the appropriate
annotations in the Application Context - of course, annotations in the code are fine too, but they
are not a requirement.
> --
> Thanks & Regards,
> Ramkumar Ramalingam
Re: [DISCUSS] Spring Implicit Services Specs Vs Implementation
Posted by Ramkumar R <ra...@gmail.com>.
On Thu, Aug 7, 2008 at 11:43 PM, Ramkumar R <ra...@gmail.com> wrote:
>
> SO WHAT IS THE CONFUSION HERE:
> The specs only says that in case of implicit services the bean name and the
> service name should be the same, instead of saying that the bean, service
> and the interface name should be identical is such cases.
>
Wanted to make a small correction from my previous statement, it should be
"The specs says that in case of implicit services the bean name and the
service name should be the same, instead of saying the service name and the
interface name should be identical".
More finding on this ground: There seems to be a correction required for
Implicit References too. In case of implicit references the property name
and the ref name should be identical to the interface name as shown
below....
<property name="addService" ref="addService"/>
Additionally, in both the above scenarios where implicit services/references
are used, its mandatory that the implementation class must use proper
annotations to mark its services and references as shown below.
@Service(CalculatorService.class)
public class CalculatorServiceImpl implements CalculatorService {
private AddService addService;
@Reference
public void setAddService(AddService addService) {
this.addService = addService;
}
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Spring Implicit Services Specs Vs Implementation
Posted by Ramkumar R <ra...@gmail.com>.
On Mon, Aug 18, 2008 at 7:54 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> Ramkumar,
>
> Sorry - I missed that final question of yours.
>
> What do you mean by "support Spring based services within SCA"?
>
> The SCA Spring Implementation specification is all about using a Spring
> Application Context to implement a service which is available to any other
> components in SCA. What other function are you looking for?
>
>
Hi Mike,
I understand the specs point of view, at the same time I am just curious to
bring this scenario to understand if we can support this....
Scenario: Lets says we have an existing spring application context, which
exposes a spring based web services in its application. Now the aim is to
use this existing application context within SCA and I would like to convert
all the spring based services now using SCA bindings. In such a scenario can
Tuscany help to make this convertion for me. Because I have all the data
required to create a web serivces like WSDL and other information available
within my spring application context.
Your inputs on this scenario, would be of great help.
Also I have another question, which I believe is already being raised
sometime back in the user list. Should Tuscany support multiple spring
context files all belonging to a single application context?
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Spring Implicit Services Specs Vs Implementation
Posted by Mike Edwards <mi...@gmail.com>.
Ramkumar R wrote:
> Thanks, Mike.
>
> Using a name like "BeanName.ServiceName" is a good idea, makes more sense.
>
> Another question on the specs I have is, how do we support spring based
> services within SCA?
>
Ramkumar,
Sorry - I missed that final question of yours.
What do you mean by "support Spring based services within SCA"?
The SCA Spring Implementation specification is all about using a Spring Application Context to
implement a service which is available to any other components in SCA. What other function are you
looking for?
Yours, Mike.
Re: [DISCUSS] Spring Implicit Services Specs Vs Implementation
Posted by Ramkumar R <ra...@gmail.com>.
Thanks, Mike.
Using a name like "BeanName.ServiceName" is a good idea, makes more sense.
Another question on the specs I have is, how do we support spring based
services within SCA?
On Fri, Aug 8, 2008 at 11:19 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> Ramkumar,
>
> Thanks for raising this. It identifies more than 1 problem - and the
> problems are partly with the code and partly with the specifications.
>
> Comments inline....
>
> Ramkumar R wrote:
>
>> Hi All,
>> This discussion is taken into account with reference to the JIRA,
>> TUSCANY-2258. Lets see some background from the specs as well as with the
>> current implementation on this issue.
>>
>> FROM THE SPECS:
>> Each <service> element used with <implementation.spring> should include
>> the name of the Spring bean that is to be exposed as an SCA service in its
>> name attribute. So, for Spring, the name attribute of a service plays two
>> roles: it identifies a Spring bean, and it names the service for the
>> component.
>>
>> Example-Spring Application Context:
>> <beans>
>> <bean id="X" class="org.xyz.someapp.SomeClass">
>> <property name="foo" ref="Y"/>
>> </bean>
>> </beans>
>>
>> Example-SCA Composite using the above Spring Context:
>> <composite name="BazComposite">
>> <component name="SpringComponent">
>> <implementation.spring location=".."/>
>> <service name="X"/>
>> <reference name="SCAReference" .../> <!-- binding info specified -->
>> </component>
>> </composite>
>>
>> As per the specs, The service element above has a name of "X", so there
>> should be a Spring bean with that name.
>>
>
> One thing that the specification SHOULD do and does not do today is to
> provide a normative definition of how the componentType is computed for a
> Spring Application Context. I will raise an issue to deal with this.
>
>
>> CURRENT IMPLEMENTATION: When explicit service definition in the Spring
>> Context is absent, current implementation introspects the java classes and
>> identifies the implemented interface of "org.xyz.someapp.SomeClass" as
>> service name.
>>
>>
> I think that there are two separate problems here:
>
> a) For the case where the Spring Bean implements a single interface, the
> code gets it wrong. It should create a single Service element, with the
> name set to the name of the Spring Bean. Clearly, it creates the Service
> element but with the name set to the name of the interface. This should be
> corrected - the name should be set to the name of the bean.
>
> b) For the case where the Spring Bean implements more than one interface,
> the specification is silent. This is a hole in the spec, pure & simple - I
> will raise an issue to deal with this. The code creates multiple <service/>
> elements - one for each interface, and it gives them the name of the
> interface (as it uses the default Java class introspection for this). While
> this ensures that all the services have distinct names, there is no sanction
> for this in the specification.
>
> My thought would be to use a name like "BeanName.ServiceName" - unique but
> also clearly linked to the structure of the Application Context - I'd
> welcome opinions on this.
>
>
> SO WHAT IS THE CONFUSION HERE:
>> The specs only says that in case of implicit services the bean name and
>> the service name should be the same, instead of saying that the bean,
>> service and the interface name should be identical is such cases.
>>
>> For me the implementation provided makes more sense, I believe the Specs
>> need a change here.
>>
>> Please let me know any suggestions/comments for the same. Thanks.
>>
>> --
>> Thanks & Regards,
>> Ramkumar Ramalingam
>>
>
>
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Spring Implicit Services Specs Vs Implementation
Posted by Mike Edwards <mi...@gmail.com>.
Ramkumar,
Thanks for raising this. It identifies more than 1 problem - and the problems are partly with the
code and partly with the specifications.
Comments inline....
Ramkumar R wrote:
> Hi All,
> This discussion is taken into account with reference to the JIRA,
> TUSCANY-2258. Lets see some background from the specs as well as with
> the current implementation on this issue.
>
> FROM THE SPECS:
> Each <service> element used with <implementation.spring> should include
> the name of the Spring bean that is to be exposed as an SCA service in
> its name attribute. So, for Spring, the name attribute of a service
> plays two roles: it identifies a Spring bean, and it names the service
> for the component.
>
> Example-Spring Application Context:
> <beans>
> <bean id="X" class="org.xyz.someapp.SomeClass">
> <property name="foo" ref="Y"/>
> </bean>
> </beans>
>
> Example-SCA Composite using the above Spring Context:
> <composite name="BazComposite">
> <component name="SpringComponent">
> <implementation.spring location=".."/>
> <service name="X"/>
> <reference name="SCAReference" .../> <!-- binding info specified -->
> </component>
> </composite>
>
> As per the specs, The service element above has a name of "X", so there
> should be a Spring bean with that name.
One thing that the specification SHOULD do and does not do today is to provide a normative
definition of how the componentType is computed for a Spring Application Context. I will raise an
issue to deal with this.
>
> CURRENT IMPLEMENTATION: When explicit service definition in the Spring
> Context is absent, current implementation introspects the java classes
> and identifies the implemented interface of "org.xyz.someapp.SomeClass"
> as service name.
>
I think that there are two separate problems here:
a) For the case where the Spring Bean implements a single interface, the code gets it wrong. It
should create a single Service element, with the name set to the name of the Spring Bean. Clearly,
it creates the Service element but with the name set to the name of the interface. This should be
corrected - the name should be set to the name of the bean.
b) For the case where the Spring Bean implements more than one interface, the specification is
silent. This is a hole in the spec, pure & simple - I will raise an issue to deal with this. The
code creates multiple <service/> elements - one for each interface, and it gives them the name of
the interface (as it uses the default Java class introspection for this). While this ensures that
all the services have distinct names, there is no sanction for this in the specification.
My thought would be to use a name like "BeanName.ServiceName" - unique but also clearly linked to
the structure of the Application Context - I'd welcome opinions on this.
> SO WHAT IS THE CONFUSION HERE:
> The specs only says that in case of implicit services the bean name and
> the service name should be the same, instead of saying that the bean,
> service and the interface name should be identical is such cases.
>
> For me the implementation provided makes more sense, I believe the Specs
> need a change here.
>
> Please let me know any suggestions/comments for the same. Thanks.
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam