Noel,
>>>interface MailetContext
>>>{
>>> org.apache.avalon.framework.logger.Logger getLogger();
>>>
>>>
>>-1 , breaks IoC.
>>
>>
>
>Might surprise you to know that I agree. However, it follows the current
>patterns used in the Mailet API (borrowed from the Servlet API), so I put it
>out in code for people to discuss.
>
>
Agree? Great, please go the final couple of inches dude then :-)
>>>interface Mailet extends org.apache.avalon.framework.logger.LogEnabled
>>>
>>>
>>-1 , breaks SoC.
>>
>>
>
>You prefer to keep interfaces clean, and compose on a base class, like:
>
> class AbstractMailet
> implements Mailet,
> org.apache.avalon.framework.logger.LogEnabled
>
>instead. The container has to inspect the Mailet, since it does not know if
>a Mailet implements LogEnabled. IF you have a container with that
>capability, it is an appealing construct.
>
I cannot imagine *any* container written in Java that does not have the
capability to do instanceof. It is probably a set-once concept. Please
explain to me your scenario.
>As you must have noted, there seems to be a great deal of resistance to the
>Avalon-ization of the Mailet API.
>
From some but not all quarters.
>That seems to be the real issue to
>address. If these patterns were embedded in javax.frameworks.*, I doubt
>that we'd be having this part of the discussion.
>
JSR 111? Hmnm, let me see, Avalon's Framework is shortlisted as a
candidate.
You gunna vote for JDK1.4 logging? I thought not.
- Paul.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
