Neeme,
I'm glad someone cited a concrete example of the Interface
inheritance issues associated with the use of the ROLE constant.
I had a few cached somewhere in my head but couldn't tap em.
[snip]
> From: Neeme Praks <[EMAIL PROTECTED]>
> public interface TimeProvider {
> Date getTime();
> }
>
> public interface MutableTimeProvider extends TimeProvider {
> void setTime(Date time);
> }
>
> The reason here is that the two work interfaces are very closely
> related, but nevertheless they are two different interfaces and it would
> be undesirable to merge the two interfaces. My current workaround (with
> Fortress) is to separate the interfaces and to use
> DelegatingTimeProvider as the TimeProvider implementation:
>
> public interface TimeProvider {
> final static String ROLE = TimeProvider.class.getName();
> Date getTime();
> }
>
> public interface MutableTimeProvider {
> final static String ROLE = MutableTimeProvider.class.getName();
> void setTime(Date time);
> }
>
> public class DelegatingTimeProvider implements TimeProvider, Serviceable {
> private MutableTimeProvider timeProvider;
>
> public Date getTime() {
> return this.timeProvider.getTime();
> }
>
> public void service(ServiceManager sm) throws ServiceException {
> this.timeProvider = (MutableTimeProvider)
> sm.lookup(MutableTimeProvider.ROLE);
> }
> }
>
> But this is not very elegant and requires the component developer to
> always write a delegating implementation whenever he/she wants to
> achieve this effect. And the whole issue becomes many magnitudes more
> complex when we increase the complexity of the inheritance hierarchy
> just a bit.
Yes this is my problem. Without putting words in Leo's mouth, he feels
these barriers are things that help contrain users from making mistakes
or incorrectly building service interfaces et cetera. Forgive me if I
have incorrectly paraphrased you, Leo. I respectfully disagree and think
there are valid situations like the one here where the ROLE constant gets
in the way.
> So my suggestion would be: allow simple things be simple and complex
> things possible (similar to the PERL slogan). Leo has a point about the
> simplicity and enforceability of the ROLE strings. Alex also has a point
> about the extended capabilities of the meta solution. So how about we
> just document both approaches and highlight pro's and con's of both? So
> the recommended approach depends directly on the container where we plan
> to deploy the component. And if we need cross-container compatibility,
> just add in both: ROLEs and meta-data.
K' wit me!
> (and it would be about time to meta-enable fortress, but that is
> entirely separate thread...)
That's a good call.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
