Re: [1.x] implementation.spring component type generation

[Ramkumar R <ra...@gmail.com>]

The ComponentPreProcessor approach seems to be working well for this issue
and the fix is now available as part of TUSCANY-2875.

This is how its going to work using this approach, If the bean property is
not already resolved as a reference then it may be an SCA reference OR a SCA
property, but it really depends on how the SCDL has defined references and
properties for this component. So we will assume all unresolved bean
properties as references and store them as list of unresolvedBeanRef in the
SpringImplementation instance.

When the preProcess method of the SpringImplementation is called, these
unresolvedBeanRefs will be validated against the SCDL definitions and the
appropriate componentType is derived.

On Fri, Feb 27, 2009 at 3:37 PM, Ramkumar R <ra...@gmail.com> wrote:

> Hi Simon,
>
> I agree with you, its a good idea to look into the SCDL for the references
> and properties that are defined compare them with the bean info.
>
> Looking at the possiblity to implement the same, looks like its pretty hard
> to read the SCDL information from the SpringImplementationProcessor resolve
> method, due to some restrictions/limitations imposed by the Tuscany runtime.
>
> I spoke with Ant over the chat, and he suggested to use the
> ComponentPreProcessor (implemented within SpringImplementation.java) to get
> the component information once the resolve phase is complete. This approach
> would allow us to determine the references and properties at the beginning
> of the ConfigurationBuilder Phase.
>
> I will use the above approach to solve this issue and see how it goes.
>
>
>
> On Wed, Feb 25, 2009 at 11:36 PM, Simon Laws <si...@googlemail.com>wrote:
>
>> Thanks for the update Ram
>>
>>
>>>
>>> Simon, you had suggested that we should be looking back at the component
>>> in the SCDL to see what has actually been defined as a reference and what
>>> has been defined as a service and using this information to build the
>>> component type. Does this comply with the specs, do we follow such model for
>>> other implementation types?
>>>
>>>
>>>
>> I was looking at these words in section 2.1 of the latest version of the
>> OASIS spec I have...
>>
>> "The SCDL also contains the <reference> element named “SCAReference”. The
>> reference name becomes an addressable name within the Spring application
>> context – so, in this case, “SCAReference” can be referred to by bean “Y” in
>> the Spring configuration above."
>>
>> In particular "The reference name becomes an addressable name within the
>> Spring application context" which I took to mean that the runtime uses
>> reference information from the SCDL file to define an addressable name in
>> the Spring context in order that it can then resolve bean refs
>> approrpiately.
>>
>> In the context of this particular problem we can look into the SCDL for
>> the references and properties that are defined there and hence determine
>> which bean refs are references and which ones are properties.
>>
>> Regards
>>
>> Simon
>>
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>



-- 
Thanks & Regards,
Ramkumar Ramalingam