james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: [Mailet API] Logging Proposal
Date Tue, 11 Jun 2002 04:06:14 GMT
Noel,

>>>The question is: will Mailet be Avalon dependant or not?
>>>      
>>>
>>Correction: Will the MAILET compatible container recognize optional
>>Avalon-Framework interfaces or not?
>>    
>>
>
>Either way, it must be possible to author a Mailet that implements
>LogEnabled, and have it able to load within the container.  
>
That reads like you agree... seems to contradict previous comment of 
yours...?

>That does impose
>certain requirements, e.g., the LogEnabled interface must be in classpath.
>
Bzzt *no*.  Classpath is for beginners.  Containers hosting comps will 
always mount complex classloader trees.  This would be better : 
"LogEnabled interface must be visible to the host component's 
classloader".  It may be that classpath (the system classloader) is fine 
for one container, but not for another.

>Perhaps it would help if you gave an overview of what it takes to write a
>container that supports the specific IoC/SoC approach favored by Avalon's
>designers.  Danny wants to ensure that a Mailet SDK can run on other
>platforms....  
>
Other Java platforms?  Please elaborate.

>...Understanding the requirements for an Avalon-Framework
>compatible mailet container would go a long way for everyone concerned.
>
OK, I'll post the smallest possible insecure, non-classloader separated 
Mailet container to this mail-list.  It won't be till the weekend.  It 
will be explanation by example, given that the Framework website docs 
are the justificatin from the applicable pattern's advocates.

>Consider that the current mailet container is not compatible in that regard,
>so this would lead to an exercise in implementing that change.
>
Err yup.  You worried about revolution over evolution?

>>So much FUD has been said about some misunderstood project called
>>'Avalon' which was perfectly good for years of this project, that
>>it is now esablished as a must-avoid without ever being investigated
>>by those running from it.
>>    
>>
>
>No, wait.  That is unfair to the people working on James and working on
>Avalon.  
>
Not all of the people who are working on (or have previously worked on) 
JAMES.  It's fair to the current mis-use of 'Avalon' as a term. In so 
far that people who should know better are bandying about issues 
concerning 'Avalon' so often, that it amounts to very effective FUD, and 
I feel it falls to me to defend the Avalon project.  There are tens of 
lurkers in this mail-list that would use things from the Avalon project 
but are less likely to now as they have been infected with an 'Avalon is 
bad' Meme.  For the record, the Avalon projects technologies are 
excellent, well designed and applicable to many server concepts. 

>The perception appears to be that Avalon means a platform, and
>Danny is concerned about platform-independence.  In his discussion, he has
>said he wants a minimum number of package dependencies. His list of
>acceptable packages was org.apache.mailet, java.* and javax.mail.*. You are
>arguing that org.apache.avalon.framework.* should be on the list, and
>represents platform-independent interfaces that are well-designed, ought to
>be, and in fact are being, adopted on multiple server platforms.
>
I claim and advocate that.

>This is why I suggested that you provide the aforementioned overview, and
>illustrate why using the Avalon Frameworks should not be avoided.
>  
>
Fine by me.  I'm pleased with you correct use of terms in that statement.

- Paul


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message