Hi Scott, we tried to do just that, e.g. we have an abstract class that uses the Servicable interface in order to set a member variable. The funny thing is, a subclass in the same package does work as expected, e.g. it gets served via the service() method, but another subclass in another package does not work. We pointed that out in http://www.mail-archive.com/[EMAIL PROTECTED]/msg03272.html but did not get an exact answer on that ...
So right now we implement avalon meta tags only in non-abstract classes. Cheers /peter > -----Ursprungligt meddelande----- > Fr�n: Timothy Bennett [mailto:[EMAIL PROTECTED] > Skickat: den 24 februari 2004 23:03 > Till: [EMAIL PROTECTED] > �mne: Re: [Meta] @avalon.dependency requirements > > > Scott Brickner wrote: > > > Seems like that ought to apply to @avalon tags. The various > descriptors > > ought to be merged for each of the classes in the inheritance tree. > > I've always been confused about what would happen with regard to the > meta tags if I decided to subclass a component. > > One prime example of that is in porting the Cornerstone components to > using the @avalon tags. The socket manager blocks has just such an > abstract base class with derived components for plain socket > servers and > TLS socket servers. Would be curious how those components would > re-tooled with @avalon tags without redesigning the classes > themselves. > > - timothy > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
