Nicola Ken Barozzi wrote:
>
> Berin Loritsch wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>> >
>> > Berin Loritsch wrote:
>> >
>> >
>> > What about all the client code that checks for Component and won't
>> find it in the Cocoon components, and the ones that extend Cocoon
>> components?
>>
>>
>> It won't break compilation. Cocoon component interfaces extend the
>> (Component) interface so all the clients have to do to release is
>> m_manager.release(foo);
>
>
> You lost me here.
>
> We want to remove depecation warnings. Or we remove @deprecated, or we
> remove Component from the Cocoon component interfaces.
>
> If we do the latter, as Vadim points out, this is not going to work for
> our users:
>
> Component c = ((ComponentSelector)manager.lookup(Generator.ROLE +
> "Selector")).select("something");
>
> Basically all the code that casts to Component will stop working.
>
> I'm trying to see all the tradeoffs.
>
Not if we create a proxy.
The ECM and FOrtress et. al. will continue working.
The Component interface is added at runtime, and the Composable
interface is supported by creating a proxy that implements the Component
interface.
Do a little experiment.
1) Upgrade the ECM used in Cocoon.
2) Remove the "implements Component" from the Generator interface.
3) Run Cocoon.
BAM!
It still works.
_It has already been taken care of_
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
