> > > Will it be possible to deploy A4 component in an A5
> > environment wihout
> > > rewriting a single character of code?
> > >
> > in the CM case, that means:
> >
> > - we cannot change the return value of CM.lookup() to Object
> > - we cannot remove CM.release()
>
> No, that means we provide a compatibility jar like Xalan did
> for a long time for Xalan 1 compatibility.
of course. We can have
org.apache.avalon.framework.component.ComponentManager
(A4 compatibility jar, with "Component lookup( Object )"
and "release()" methods; marked as deprecated)
and an
org.apache.XXXXXXXXX.component.ComponentManager
(A5, with "Object lookup( Object )" and no
"release()")
I ment:
- we should not change the return value of
o.a.a.f.component.ComponentManager.lookup() to Object
- we should not remove
o.a.a.f.component.ComponentManager.release()
> > this means we will have an avalon 5 container that will have
> > to determine whether it deals with an A4 or A5 component, and
> > choose which CM to use based on that.
> >
> > This is possible only if we add some meta-information for
> > components. So while it means we will not have to rewrite
> > code, we might have to rewrite some meta-information.
>
> Meta-info is easy to rewrite. Just like Peter did for the
> Avalon 3 to Avalon 4 migration, we should also provide a
> script to change the imports and change Component to Object.
...and to remove any call to release() on the CM...
> That way there is very little hand coding that has to occur
> for migration of legacy components.
yup. I agree. It will still mean code changes to migrate, or a
compatibility mode... =)
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
