Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
I do not want to object but I would like to understand one thing... Given this
code:
public class FooComponent extends AbstractLogEnabled
implements ..., ThreadSafe, Component
public class BarComponent extends AbstractLogEnabled
implements ..., ThreadSafe
You suggest that BarComponent is POJO, while FooComponent is not. Can you
explain me why is that?
:) No, I'm not suggesting this, but...we had two different cases:
a) Component is used in an interface. This prevents the usage of the
interface in a non Avalon world and should really be avoided.
Rather, "... prevents the usage of the interface if Avalon JAR is missing".
b) Component is used in the implementation (as you show above). Removing
the interface from the implementation is the first step towards having a
POJO. But it is not possible to remove all avalon lifecycle interfaces
from the implementation without breaking the usage inside an avalon
container.
My primary goal is to use the interfaces in a POJO world; I don't care
that much about the implementation. But at the same time I want to
reduce the dependency to avalon even in the implementation as much as
possible.
I remember they discussed this metadata thingy way back on avalon list - this
should be a ticket! You could have all metadata out of implementation class in
the XML files ;-)
Perhaps one could do a:
public class POJOBarCompomnent implements ...
and
public class BarComponent extends POJOBarComponent implements
ThreadSafe, LogEnabled
I'm not sure if this is worth the effort.
Agree.
Does this all make sense somehow?
Yes.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
