Re: cvs commit: jakarta-james build.bat

[Paul Hammant]

Paul,

>I will do some more *investigation* at home, but am this stage I am satisfied that I 
>am off the
>hook.  
>
I've installed JDK 1.4.1 on my second machine with Ant 1.4.1 and 
Intellij's IDEA (EAP 650).  It produces identical results to my primary 
machine (Ant 1.5, JDK 1.4, TortoiseCVS). i.e. build.bat is modified by 
the build process.  On my primary machine, Tortoise has marked build.bat 
as changed.  On my secondary machine CVS built into Intellij has marked 
build.bat as changed.  In both cases the same change had occurred (line 
endings).  Yes, I was using fresh CVS HEAD.

I'm rationalizing my commitments presently, and that means I bowing out 
of the JAMES list, and will not be making more commits.  I've helped a 
little in the past and am very pleased to see a new and enthusiastic set 
of committers on JAMES.  There are exciting things happening here and I 
am looking forward to releases.  I hope to bump into Charles again in 
London, as he is one smart dude.  I'll hopefully get him along to 
eXtreme Tuesday (which I frequently attend).  If people are to peddle my 
opinions in absentia they are :

1) Don't diss Avalon
2) Hold all Apache committers in high regard.
3) Don't confuse Avalon sub-components (FUD)
4) Avalon-Framework for all comps including mailets
5) Phoenix is cool, so is Fortress (coming real soon now).
6) Mailets should be in separate jars in separate classloaders and be 
hot installable (easy).
7) Shift storage of mail to standard archive formats.
8) Test (unit) first!

I trust Stephen McConnell to be the Avalon advocate for JAMES now. 
 Peter Donald (an Avalon and Ant longtimer) is also intermittently here 
and knows his stuff.  These are very smart people and can more or less 
do anything they set their minds to.  Keep up the good work all!!

Regards,

- Paul
 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-james build.bat

[Paul Hammant]

Peter,

> It's very simple, and clearly laid out in the thread.  You committed an
> essentially unchanged build.bat (see your last commit) and you actually
> did the same thing once before (check the history of the build.bat
> file).  The commit changed the line endings from CRLF to LF.  The
> build.bat file is a Windows only file, and the James build changes it to
> CRLF so it's kind of annoying to see a constant diff for the entire
> file.  Thus I reverted it back to the previous version, which had CRLF
> line endings.

Right, thanks for the clarification. 

Seeing as I've never eddited that file, use the excellent Textpad on Windows2000, with 
Tortoise
for CVS, I doubted it ws me (personally) that made the mistake.  So moments ago I did 
a problem
reproduction. 

Steps to reproduce
--

1) Update to latest CVS HEAD revision.
2) Commit on root (only go to preview pane).  

  - Note *no* files pending.

3) 'ant dist'
4) Commit on root (only go to the preview pane)

  - Note build.bat, build.sh and dozens of java 
sources are listed as changed.  Indeed they 
have changed (line endings).

Conclusion
--

Given the nature of the investigation, I'm claiming that the build script changed 
them.  I'm using
Ant 1.5 (which could conceivably be the problem), but I think it is more likely that 
build.xml is
at fault.

I will do some more *investigation* at home, but am this stage I am satisfied that I 
am off the
hook.  If this remains unfixed by the time the next Phoenix is booked in (and if it is 
me doing
it), I will delete the java sources, build.bat etc before commit.

- Paul

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-james build.xml

[Paul Hammant]

Steve,

Yes, I run Phoenix and poke it through NNTP.  It is still running, but 
that's of little consequence.
There are no test targets so it is the best I can do, unless somone 
gives me a quick way to setup local-loop SMTP/POP3/IMAP testing.

- Paul

>Question:  are the other comitters running James before comitting their
>changes to CVS?  I don't mean this in a critical, negative way, and I
>know it is easy to have jars lying around so stuff still works until you
>do a cleanup, but when the Phoenix server doesn't even startup I feel
>the question has to be asked.
>  
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-james build.bat

[Paul Hammant]

Peter,

Couls you clarify what I am being accused of.

- Paul

>Danny,
>
>  
>
>>ant does this at build.
>>
>>
>
>Yes, I know.  Which is why it's annoying to see that constant diff after
>I run a build.  We had this discussion the last time Paul checked in a
>new Phoenix - he did the same thing at that time.
>
>--Peter
>  
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Class loading

[Paul Hammant]

Noel, Peter,

Guys,  given you nobbled the Class.forName(..) usage, could you have 
another go at trying phoenix with mail_1_2.jar, activation.jar and 
commons-net.jar in the SAR file, before you move them back to phoenix\libs?

Cheers,

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Build failure

[Paul Hammant]

Noel,

>cvs update -Pd
>./build.sh clean
>./build.sh
>
>Result:
>
>BUILD FAILED
>
>/home/noel/jakarta/jakarta-james/build.xml:366: Could not create task of
>type: sar due to java.lang.NoClassDefFoundError:
>org/apache/tools/ant/types/AbstractFileSet
>
>Does the ANT in the James CVS need to be updated, too?
>
Yes, if you folks are committed to still using it.  When 1.4.1 emerged, 
most projects ditched internal Ant instances.  1.4.x and 1.5.x for most 
projects are interchangable.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Cornertsone just uploaded.

[Paul Hammant]

http://jakarta.apache.org/builds/jakarta-avalon-cornerstone/nightly/2002-09-25/

We'll try to push ahead with a release shcedule...

-ph


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Class loading

[Paul Hammant]

Noel,

>I just ran grep on the James sources:
>
>AvalonMailStore.java: reply = (MailRepository)
>Class.forName(repClass).newInstance();
>AvalonUsersStore.java: UsersRepository rep = (UsersRepository)
>Class.forName(repClass).newInstance();
>JdbcDataSource.java: Class.forName(jdbcDriver, true,
>Thread.currentThread().getContextClassLoader());
>NNTPUtil.java: Object obj = Class.forName(clsName).newInstance();
>MailetLoader.java: Mailet mailet = (Mailet)
>Class.forName(className).newInstance();
>MatchLoader.java: Matcher matcher = (Matcher)
>Class.forName(className).newInstance();
>
>I guess that you'd like these changed?  :-)
>  
>
Indeed.

Class.forName(..) without the classloader param is always a looming 
problem for classloader trees.

- ph


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Phoenix 4.0 final pushed up.

[Paul Hammant]

Steve,

>Yes it's:
>
> java.lang.NoClassDefFoundError: javax/mail/internet/ParseException
>
>It can't work with mailet.jar in the phoenix/lib directory and
>mail_1_2.jar in the James SAR because this means that mailet.jar is
>loaded by the extenation ClassLoader and mail_1_2.jar is loaded by the
>Phoenix PolicyClassLoader. Since the PolicyClassLoader is higher in the
>delegation chain, mailet.jar cannot load any javax.mail.* classes.
>
Actaually, given that it is NoClassDefFoundError (and not 
ClassNotFoundException) , it is dependancy of java/mail that cannot be 
found, not the mailet jar itself.  I'd say that is the activaton jar and 
some shitty use of Class.ForName(..) on Sun's part.

For the record both of my containers publish a mailet.jar-like server to 
their hosted components without requiring any mokying with Phoenix's lib 
directory.

>I've since read Peter's mail which says he added the mailet classes into
>james.jar file and this approach also works, but only if the mailet.jar
>file does not also exist in the phoenix/lib.  The current build.xml file
>builds a separate mailet.jar file and then copies it into ${dist}/lib,
>i.e. the target phoenix/lib dir.
>  
>
As I say, this should not be necessary.

As long as we use ..

   this.getClass().getClassLoader().loadClass(..)

.. instead of ...

  Class.forName(..)

.. we should be fine (five occurences by the looks of things).


When we shift to hot installable mailets, you'll have a seperate 
classloader per mailet archive (the norm for these things).  Then you'll 
do ..

   mailetArchive.getClassLoader().loadClass(..)

.. or some such.

-ph


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Phoenix 4.0 final pushed up.

[Paul Hammant]

Peter,

>>I tried this with a clean checkout and build and I'm afraid it doesn't
>>work.  I think you need to move mailet.jar back into the james.sar
>>
>>
>file,
>  
>
>>path SAR-INF/lib.
>>
>>
>
>No, you don't.  
>
?

>I resolved that problem the other day to deal with the
>broken build, mailet classes are now included in the james.jar. 
>
>Although personally I'm having problems with Ant and the sar task now.
>I suspect that the required version of Ant might have been pushed up a
>notch with this change.
>  
>
I have done nothng that would affect the version of Ant in use.

-ph


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Replace Component Classes with Service Equivalents

[Paul Hammant]

Peter,

>>>1) Take the hit convert ComponentManager to ServiceManager
>>>
>>>  - Three mailets affected
>>>  - Some contention that they are non-mailet spec anyway.
>>>  
>>>
>>With all due respect, I'm going to have to say that you are again
>>missing the point.  It's not three mailets affected.  It's a totally
>>unknown number of custom mailets that people have written and deployed.
>>That said...
>>
>>
>
>Can you actually point to an exception or problem that occurs when running 
>under Phoenix? I would like to know if there is actually a problem or if it 
>is just aesthetic concerns or something.
>  
>
There is an exception, but nobody sees it anymore as the Cornerstone.jar 
is Comonent regressed one.  

At least I thought it was, but looking at the CVS hstory makes it look 
like the one I popped in allegedly causeing this problem many months ago

  http://cvs.apache.org/viewcvs/jakarta-james/lib/cornerstone.jar

Can someone help me out on my newfound confusion here?

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Replace Component Classes with Service Equivalents

[Paul Hammant]

Peter,

>With all due respect, I'm going to have to say that you are again
>missing the point.  It's not three mailets affected.  It's a totally
>unknown number of custom mailets that people have written and deployed.
>That said...
>  
>
I may be a little, but so are you a little :-)

* James has no hot-install mailet capability yet.  
* There is nor MAILET-APPS dir nor MAILET-INF/ dir in mailet using jars.
* Your user community are developers not users.  
* Developers are recompile savvy and there a 1000 times less of them 
that there are for deployments of the servlet API.  
* That API, has a lower barrier to entry.

When you folks change to support drop in mailet jars, then, and only 
then, do you have an upgrade cost worth worry about to this level.

You know you can take code from EOB for this, or we could share 
repository components :-)

-ph



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Phoenix 4.0 final pushed up.

[Paul Hammant]

Steve,

>I tried this with a clean checkout and build and I'm afraid it doesn't
>work.  I think you need to move mailet.jar back into the james.sar file,
>path SAR-INF/lib.
>  
>
What did not work dude?  What were the exceptions logged?  

I was able to launch Phoenix and poke things thru the NNTP server, I'm 
going to need some advice on how to configure a local-loop SMTP test so 
that this does not happen again (no unit tests for that?).

Could you test the moving back of the mailet jar into the primordial 
class loader (what phoenix/lib becomes)

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Replace Component Classes with Service Equivalents

[Paul Hammant]

Folks,

I think we are down to a few options...

1) Take the hit convert ComponentManager to ServiceManager

  - Three mailets affected
  - Some contention that they are non-mailet spec anyway.

2) Keep ComponentManager, use Avalon-Excalibur's container package to 
represent a Component interface for Cornerstone components.

  - No changes to existing mailets (we hope).

3) Like (1), but go futher and add to the mailet spec for MailStore  and 
JDBCDelegate (hiding DataSourceSelector and Store).

  - Reasons for (1) justification here too.

Thoughts?

Regards,

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Phoenix 4.0 final pushed up.

[Paul Hammant]

Folks,

Phoenix 4.0
---

I have committed Avalon-Phoenix 4.0 to CVS.
I have not touched Avalon-Conerstone
I have moved activation.jar, mail_1_2.jar and commons-net.jar to 
/lib as that is the correct place for them. I have updated the 
build script for that.

  - Have your folks considered the license conditions from Sun for the 
two Sun jars?  They differentiate between the rules concerning CVS 
listing versus, the availability of the same jar in a 'finished 
product'.  i.e. it may be OK for you to include them in james.sar (if 
available as a download) or in james-bin.zip.

JMX
---

MX4J is launched on start of Phoenix.  It listens on localhost:8082, and 
is bound to localhost.  You can turn it off in kernel.conf.  There is 
bugger-all managable in James, though it is really easy to setup.

Wrapper
---

The wrapper project's Windows executables are included.  This allows you 
to install James to the Windows Services (see control panel).  To do 
this do:

  wrapper -i ..\conf\wrapper.conf

You can then start stop James from the control panel, or command line :

  net start James
  net stop James

It will relaunch if it abends (I have tested this for other sars and it 
is cool).

I have not done any work for Unix, as I cannot test this.  Volunteers?

Regards,

- Paul



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Replace Component Classes with Service Equivalents

[Paul Hammant]

Steve,

>I agree, although I submitted the patch and have no voting status within
>Avalon.  I had no idea it was going to be such a problem for James,
>especially since I warned them days before that I was going to do it and
>noone even commented!
>
>Apologies for the inconvenience.
>  
>
Nahh, nobody is bitter, keep it up dude.  Activity like this is good :-)

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Replace Components with Services

[Paul Hammant]

Peter,

Firstly dude, could you try to dofferentiate between Avalon-Framework, 
Avalon-Phoenix, and Avalon-Cornerstone when referring to classes.  I 
know it's sightly rudeof me to raise this, and I mean no offence, it's 
just that I spent loads of effort explaining the difference before 
mid-August (your entry point to the mail-list), with some level of 
achivement :-))

I'd agree that the nascent Mailet API should not refer to Avanlo-Phoenix 
or Avalon-Cornerstone.  I don't agree there is a problem with 
Avalon-Framework, but then I am subjective.  As stephen says the 
lifecycle interfaces are very strong (arguably the best aspect of the 
avalon project).  Like Stephen I am a two time container author, and 
would not consider a new hosted component design without them now.

 From other mails

I dissagree that non-Avalon mail containers will be able to host Mailets 
if Avalon-Framework is used.  It is really easy to roll your own 
container - the Turbine team is doing it.

Re "tightly coupled to the Avalon lifecycle framework", not true.  the 
current situation is because Avalon-Cornerstone (and Avalon-Cornerstone 
*only*) dropped Component references., and is not becuase of a prior 
change in Avalon-Framework.  This problem is not to do with the fact 
that James impl incidentally uses Avalon-Excalibur interfaces.  Nor is 
it to do with the fact that James Impl happens to run on Avalon-Phoenix 
as a containter.  James impl is a container in a container, is is sweet 
apart from the lack of hot installable lifecyle-activated mailets and 
this Avalon-Cornerstone issue.

 From Noel's  "One of the biggest items is that an interface to object 
repositories needs to be part of the mailet specification, and mapped to 
the platform, rather than having to break the veil."

  - Agree. And that should not expose Avalon-Cornerstone interfaces.  It 
should expose Mailet interfaces (who's impl may use Avalon-Cornerstone 
things).

Finaly, you guys should stick with the forked Cornerstone, if it is that 
big an issue.

Maybe I should I get my act together and write a demo of the future 
mailet design (as promised).  I'm sure stephen and I could write a tiny 
demo that could show how it should work. It would only use the 
Avalon-Framework classes for dependencies, so there would be no isses 
born of confusion on imports for the container versus for the mailet API.

- Paul

>Please consider this my -1 to replacing ComponentManager in the Mailet
>API with ServiceManager as a long term approach.
>
>There have been extensive discussions on this list about the coupling
>between the Mailet API and Avalon.  How extensive should this coupling
>be, what form should it take?
>
>For my part, I don't really have a tremendous objection to a tighter
>coupling between Avalon and the Mailet API.  I know that some do,
>because they want to see the Mailet API become a server-independent
>standard.  I respect that opinion, but it's not the reason I'm voting
>against this as a long term proposal.  I'm interested in James as an
>enterprise quality mail server, not in the Mailet API in the abstract.
>If the mailet API were to incorporate some subset of the Avalon
>lifecycle, I'd have no objection in principle.
>
>I do object however to an attempt to slip things in the back door.  The
>current situation is the worst of both worlds.  We're tightly coupled to
>the Avalon lifecycle framework (see the current situation), but gain
>none of its benefits.  There is no ordered lifecycle, no well defined
>series of events.  There isn't even a wrapper method for the
>MailetContext to ensure that when we get the ComponentManager /
>ServiceManager we're actually getting a ComponentManager /
>ServiceManager object because that would introduce Avalon classes into
>the Mailet API.  That's supposedly a guarantee of the container, but it
>can't be a real guarantee because not every Mailet container is
>necessarily an Avalon container.  So these mailets aren't really
>portable even though their interfaces all say they are.  Arrgh.  But we
>don't have any Avalon interfaces in our API, so we're Avalon independent
>(wink, wink).  Double arrgh.
>   
>For a long term solution I see three possibilities:
>
>i) Incorporate the Avalon classes into the Mailet API - there is strong
>objection to this and it ties us to Avalon
>
>ii) Incorporate some other set of classes that provide much of this
>functionality (i.e. JDK 1.4 for logging) and write adaptors for the
>relevant Avalon classes - probably incur strong objections, adaptors
>might be tricky
>
>iii) Do it all ourselves, making a more rigorous lifecycle for the
>mailet and write adaptors for the relevant Avalon classes - probably the
>least objections from those who want the Mailet API to be independent,
>adaptors might be tricky
>
>Anyway, that's why I'm voting -1 on simply replacing ComponentManager
>with ServiceManager for the long haul.  I understand we may need to do
>it temporarily.  If we do, I want us to 

Re: [PATCH] Replace Components with Services

[Paul Hammant]

Noel,

>>your users are far smaller in number that those to say Servlet
>>(or those to say jdbc - a real balls-up of backwards compatability)
>>
>>
>
>I've migrated JDBC client code and servlets for several years now without
>having to change them.  
>
Writing a JDBC driver became harder because of 15 new methods on 
interfaces.  Writing code that would work on 1.3 and 1.4 became nearly 
impossible.

There are some 200 driver writers out there that Sun forced to fix 
invent novel solutions of backards compatability.

The reason it is analagous - is that the installed user base?  It is not 
like your have a WAR-file like drop in of Mailets to James, users have 
to be build-savvy to develop for James.

Just an anecdote..

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Replace Components with Services

[Paul Hammant]

Folks,

>+1 from me,
>I tried it at home, but straight off got a build exception from ant with the
>sar taskdef, I 'xpect you'd nail that one in a second..
>  
>
Phoenix can be commited separately to any changes we talk of to 
Cornerstone.

Shal I go ahead?

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Replace Components with Services

[Paul Hammant]

sion of Phoenix, and there's
>actually been a discussion on Avalon-dev about keeping us on a special
>forked version of Cornerstone.  We need to do the Serviceable switchover
>to continue to keep up with our third party provided software.  As far
>as I'm concerned, that makes some sort of switchover effectively
>mandatory.
>
>So that leaves us in search of a third option.  My suggestion would be
>the following:
>
>i) Keep everything in James labeled Component.  As discussed, this is
>just a deprecated marker instance.  This doesn't cost us anything.
>
>ii) Change the ComponentManager in the Mailet API to be an
>AdaptingComponentManager that wraps a ServiceManager.  Document this
>feature of the API as deprecated in the documentation.  Describe the
>issue with Cornerstone in the documentation.  Document which of the
>standard blocks will not be accessible.
>
>iii) Add a ServiceManager to the Mailet API in an identical fashion as
>the ComponentManager.  This is necessary to expose those darn
>Cornerstone implementations to mailets.  Mark it as immediately
>deprecated, with a note that mailets designed for this revision that use
>this feature will not be compatible with 2.2.  This will give us time to
>have the relevant discussion without making it necessary to push our
>next release even farther out.
>
>iv) Update all James core code (service implementations, mailets we
>store in CVS, etc.) to use Serviceable rather than Composable and to
>employ the ServiceManager rather than the ComponentManager.
>
>That's my suggestion.  Thoughts?
>
I have pointed out that the wrapper solution, though clever, will not 
work for two of the mailets in James codebase ( JDBCAlias and 
JDBCListserv ).

So...

v) Have a JamesDataSourceSelector that wraps the actual 
DataSourceSelector implementation and additonally implements Component. 
It will be a hand-coded proxy of course.

- Paul




>
>--Peter
>
>  
>
>>-Original Message-
>>From: Steve Short [mailto:[EMAIL PROTECTED]]
>>Sent: Tuesday, September 24, 2002 1:13 PM
>>To: James Developers List
>>Subject: RE: [PATCH] Replace Components with Services
>>
>>I agree.  If James has to keep any references to Component then we
>>needn't bother doing any changes at all. Component is currently
>>deprecated and presumably it will be remove entirely in future
>>
>>
>release.
>  
>
>>Steve
>>
>>
>>
>>>-Original Message-
>>>From: Paul Hammant [mailto:[EMAIL PROTECTED]]
>>>Sent: Tuesday, September 24, 2002 1:00 PM
>>>To: James Developers List
>>>Subject: Re: [PATCH] Replace Components with Services
>>>
>>>
>>>Peter,
>>>
>>>  
>>>
>>>>As we've discussed before on the james-dev list, it's a little more
>>>>indepth than this patch addresses.
>>>>
>>>>
>>>>
>>>>i) The Mailet API is to remain invariant
>>>>
>>>>
>>>- that is,
>>>  
>>>
>>>>mailets must be able to access the same components as
>>>>
>>>>
>>>previously using
>>>  
>>>
>>>>the component manager that was provided to them through the
>>>>MailetContext.
>>>>
>>>>ii)   Point (i) requires that all James services
>>>>continue to implement the Component marker interface.  No
>>>>
>>>>
>>>biggie, it's
>>>  
>>>
>>>>just a marker interface
>>>>
>>>>
>>>>
>>>True, but it has been eliminated from Cornerstone in Apache
>>>HEAD CVS.
>>>
>>>  
>>>
>>>>iii)  Point (i) also requires that we use an
>>>>AdaptingComponentManager (sic?) to wrap the ServiceManager
>>>>
>>>>
>>>and provide
>>>  
>>>
>>>>components to the mailets.
>>>>
>>>>
>>>>
>>>>
>>>(wrapping) Perfectly possible. but .
>>>
>>>Take init() from org.apache.james.transport.mailets.ToRepository
>>>
>>>ComponentManager compMgr =
>>>(ComponentManager)getMailetContext().getAttribute(Constants.AV
>>>  
>>>
>>ALON_COMPONENT_MANAGER);
>>
>>
>>>try {
>>>MailStore mailstore = (MailStore)
>>>compMgr.lookup("org.apache.james.services.M

Re: [PATCH] Replace Components with Services

[Paul Hammant]

Noel,

>How does it differ from what we have?  I guess we have a prerelease of
>Phoenix 4?  Seems like a good idea to migrate us to the official release,
>although Steve seems to be saying that we need a version that includes some
>patches he submitted this week, and which are already in your CVS.
>  
>
Steve's patches concern Cornerstone.  Phoenix should be able to be 
upgraded on its own.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Replace Components with Services

[Paul Hammant]

Peter,

>As we've discussed before on the james-dev list, it's a little more
>indepth than this patch addresses.
>
> 
>
>i) The Mailet API is to remain invariant - that is,
>mailets must be able to access the same components as previously using
>the component manager that was provided to them through the
>MailetContext.  
>
>ii)   Point (i) requires that all James services
>continue to implement the Component marker interface.  No biggie, it's
>just a marker interface
>
True, but it has been eliminated from Cornerstone in Apache HEAD CVS.  

>iii)  Point (i) also requires that we use an
>AdaptingComponentManager (sic?) to wrap the ServiceManager and provide
>components to the mailets.
>  
>
(wrapping) Perfectly possible. but .

Take init() from org.apache.james.transport.mailets.ToRepository

ComponentManager compMgr = 
(ComponentManager)getMailetContext().getAttribute(Constants.AVALON_COMPONENT_MANAGER);
try {
MailStore mailstore = (MailStore) 
compMgr.lookup("org.apache.james.services.MailStore");

1) If MailStore extends Component this will work.

Well it does not anymore, it extends Cornerstone's store, but you have 
the source for MailStore, so can to "extends Store, Component".

2) If all ComponentManager looked up things are in your codebase, then 
you have a strategy in (1).

Well, that is not true, JDBCAlias (and JDBCListserv) returns 
DataSourceSelector on lookup, which is in Cornerstone's CVS.  You could 
invent JamesDataSourceSelector which wraps the Cornerstone one and adds 
an impl of Component, then it it will work fine, but it changes the 
JDBCAlias source, which breaks the backwads compatible directive.

>If it weren't for these little issues, we'd probably have gotten to it a
>while back.  If you'd like, you can update the patch to address these
>issues and resubmit.  Thanks.
>  
>
The patch can be fixed as per the strategy outlines in (1) and (2) 
above.  It will mean that the DataSourceSelector usage will end, but 
that is only two mailets in your codebase.

If I were you I'd decomission ComponentManager completely for the sake 
of ServiceManager (Component for Object, and Composable for 
Serviceable).  It is a brave step and does break backwars compatability, 
but it is very nearly a word replacement issue for the user community. 
 If James mailets were distributed as shrink wrapped, then you'd have a 
problem, but they are not.

You choice, I'm an honarary committer here (my capacity is limited to 
Phoenix related issues).

Regards,

- Paul




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Replace Components with Services

[Paul Hammant]

Noel,

><> All I know is that they appear magically in the Jemaes CVS, and if
>there are necessary changes to the James code/config, he makes those, too.
>
>Ask Paul.  :-)
>  
>
Well I handled Phoenix CVS, and was responsible for the slight, ahem, 
mishap last time when James did not actually run.  Though I launched it 
prior to commit and poked thru the NNTP server as an eyeball test, none 
of the mailets were invoked which meant that the latent feature in 
Cornerstone was not noticed.  That featre was that the comps no longer 
extend Component.  I think it was perfectly possible for me to update 
Phoenix without updating Cornerstone (they are after all seperate).

Fellow Avaloner Stephen McConnell noticed this and provided a manually 
patched version of Cornerstone in his private CVS.

I could update Phoenix again, but we have an issue in that we have 
forked from the HEAD CVS in Apache CVS.  To get back to compatability, 
we need to take the brave step of doing the Serviceable change completely.

   -> More on that in another thread.

Regards,

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Replace Components with Services

[Paul Hammant]

Steve,

>Cool - are these made available to the public or only internally to
>Avalon folk?
>  
>
Most of the Phoenix comunity (thats about 20 companies + open-source 
usages from what I can see) builds from CVS.  I appreciate that is not 
ideal.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Replace Components with Services

[Paul Hammant]

Folks,

Should I push Phoenix into James CVS. It has been out for a week and the 
only reported issue is with MX4J which you guys are hardly using yet.

I am using Phoenix 4.0 in work, and it is fine.  

Regards,

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Replace Components with Services

[Paul Hammant]

>
>
>Paul Hammant provides the relevant Avalon binaries for inclusion in James.
>  
>
Yawn... waking up ... hey you guys have been busy :-)


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: fetchpop

[Paul Hammant]

Danny,

> (I may have made a mistake by commiting this jar to phoenix/lib rather than
> lib/)

Phoenix-lib\lib is for stuff that comes with Phoenix.  The commons-net jar should go 
in the lib
dor at root, and be included in the  element of  in the build file.

- Paul

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Phoenix and James

[Paul Hammant]

Not quite.  Will test tonight.

Getting rid of Composable completely before you ramp up www.mailets.org would be good 
too.

- Paul

 --- "Peter M. Goldstein" <[EMAIL PROTECTED]> wrote: > 
> All,
> 
> Are we up to date on Phoenix, or are we using an out-of-date version?
> If the latter, are there changes we need to make to the James code (i.e.
> Composable->Serviceable) before we can migrate to the newly release
> Phoenix 4.0?
> 
> --Peter
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>  

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Erasing error/ and spam/

[Paul Hammant]

> if they're being erased now its phoenix doing it.

With the greatest of respect, is that a fact or conjecture?

- Paul
 
> > -Original Message-
> > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> > Sent: 20 August 2002 23:30
> > To: James-Dev Mailing List
> > Subject: Erasing error/ and spam/
> > 
> > 
> > Could someone please point out where the code is that erases 
> > var/mail/spam/
> > and var/mail/error/ when restarting James?  Or is this courtesy 
> > of Phoenix?
> > Whatever it is, I either need to make this an optional feature, 
> > or I need to
> > change my startup script to save these items until they can be 
> > doublechecked
> > by other tools.
> > 
> > --- Noel
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > 
> > For additional commands, e-mail: 
> > 
> > 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>  

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: NNTP auth issues

[Paul Hammant]

Noel,  Jason,

>Shouldn't be any different.  Did you make any progress on this?
>
>You might want to ask Paul Hammant to take a look at it.  For example, I
>don't know what the relationship is between the .xinfo files and things like
>the assembly file, but the .xinfo for the nntp server doesn't have an entry
>for the UsersStore, which is present in the .xinfo for other services.
>
There is a strong relationship is Noel suspects.

You will have to fork the root NNTP block to declare its need for and 
get DataSource from ComponentManager in its compose method.

At least until we find a way of eliminating the dar I suggest insecure 
anti-pattern of Mailets getting free reign of the ComponentManager.

- Paul

>   --- Noel
>
>-Original Message-
>From: Jason Webb [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, August 15, 2002 6:30
>To: 'James Developers List'
>Subject: NNTP auth issues
>
>
>I'm trying to link our database into the NNTP auth mechanism as we
>provide an MLM that has a lot of NNTP style features. However, when I
>ask for a DataSource from the ComponentManager, I get an exception
>thrown at me:
>
>org.apache.avalon.framework.component.ComponentException: Unable to
>provide implementation for
>org.apache.avalon.cornerstone.services.datasource.DataSourceSelector
>at
>org.apache.avalon.framework.component.DefaultComponentManager.lookup
>DefaultComponentManager.java:70)
>at
>org.apache.james.nntpserver.AuthServiceImpl.isAuthenticated(AuthServiceI
>mpl.java:84)
>at
>org.apache.james.nntpserver.AuthServiceImpl.isAuthorized(AuthServiceImpl
>.java:53)
>
>
>Etc
>
>It all works fine in the mailet we use for our MLM. Is NNTP special with
>regards to DataSources?
>
>Help!
>
>-- Jason
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>  
>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Jakarta James Nightly Build

[Paul Hammant]

Stephen,

>> To more knowledgeable heads than I,
>>
>> Noel and I have been looking at the nightly build process and are a
>> little disturbed by the fact that:
>>
>> i) It is failing
>> ii) It is failing without notifying james-dev
>>
>
> This explains a lot.  With no notification of failures, the Avalon 
> Community have been moving along in ignorant bliss (relative to the 
> James Commnity).  Over the last few days that has been discussion 
> concerning inconsitencies in Cornerstone jar brough about by some 
> recent testing I've been doing of James using the Avalon CVS builds of 
> Cornerstone. With gump working we would have spotted the issue months ago.
>
> Getting this back in place would be really good becuse you can 
> validate that the Avalon Community are not braking anything as a 
> result of maintainance and service development.

Err not true dude.  The problem exists because casting (I think) which 
neither gump nor a guy doing 'ant clean, ant dist' can test for.  

>> See the nightly build report here:
>>
>> http://jakarta.apache.org/builds/gump/latest/jakarta-james.html
>>
>> After examining the definition file here,
>>
>> http://jakarta.apache.org/builds/gump/latest/module_jakarta-james.html
>>
>> it is very clear that this definition is pretty far out of date.  Among
>> other things, the file refers to a James.bar, which if I recall
>> correctly was the predecessor to the current James.sar.  So the file
>> needs to be updated.
>>
>
> Pete the right person to talk to - he knows this stuff inside out.

Indeed he is.  Confuses the hell out me me.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jakarta James Nightly Build

[Paul Hammant]

Peter,

>To more knowledgeable heads than I,
>
>Noel and I have been looking at the nightly build process and are a
>little disturbed by the fact that:
>
>i) It is failing
>ii) It is failing without notifying james-dev
>
>See the nightly build report here:
>
>http://jakarta.apache.org/builds/gump/latest/jakarta-james.html
>
>After examining the definition file here,
>
>http://jakarta.apache.org/builds/gump/latest/module_jakarta-james.html
>
>it is very clear that this definition is pretty far out of date.  Among
>other things, the file refers to a James.bar, which if I recall
>correctly was the predecessor to the current James.sar.  So the file
>needs to be updated.
>
No, the bar (block archive) was simply replaced with jar.  bars (now 
jars) sit inside sars.

>The build is currently failing because of unnecessary dependencies -
>James builds off snapshots of the assorted Avalon subprojects and hence
>does not need those project builds to succeed.  So the dependency
>entries need to be updated.
>
>I'm willing to volunteer to do the jakarta-james.xml file update.  My
>big problem is that I don't know where the file is, and I don't think I
>have write-access to it.  I'd like to get one of the Apache elders to
>give me a hand with this.  As Peter Donald is listed in the nag tag, I'm
>cc'ing him on this email.  Any help would be greatly appreciated.
>

jakarta-alexandria/proposal/gump/project/jakarta-james.xml I think.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: James under Merlin

[Paul Hammant]

Stephen,

>  1. The class AvalonUsersStore is referenced as a Component
> somewhere or other but doesn't implement the Component
> interface

If this really is the case, then we should put Component back as an 
interface it impls.  We need to take a long term decision about the 
maillets uses of Component.  This was the blocker for Component's 
complete removal from JAMES (and Conposable's replacement with Serviceable).

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: James under Merlin

[Paul Hammant]

Stephen,

> I've been playing around with James under Merlin.
>
> During the process I came accross a runtime problem:
>
>  1. The class AvalonUsersStore is referenced as a Component
> somewhere or other but doesn't implement the Component
> interface

Err should be able to fix that one.

>  2. After starting James inside Merlin, then sending an email
> to an arbitary name on the server James is running on,
> I get NPE - which is where I figure I may need some help
> from you guys ...

This is where we wich we could unit test each comp.

A guy at BP has written a generic AbstractPhoenixTestCase (where Phoenix 
is mocked).  I'll get him to write it up and someone might do the same 
thing inside Phoenix CVS or maybe Merlin CVS ? :-)

Failing that we'll have to do good old fashioned debugging.  Question do 
you use IntelliJ ?  Have you got interactive debuging working with Phoenix?

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Error with new MBean stuff

[Paul Hammant]

Noel,

>In the meantime, though, it really is a good normative policy to log both
>the port and address when you get a BindException error.
>  
>
Of course Phoenix does that.  Problem is that this is delegated to MX4J. 
 Refer http://mx4j.sourceforge.net

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Error with new MBean stuff

[Paul Hammant]

Noel,

>Would you PLEASE log the bind address and port!!!
>  
>
If you are having a problem (which I am trying to look at)  comment out 
the entire

   mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

Re: Stats and monitoring James

[Paul Hammant]

Jason

>I notice at the moment there seems to be no facility for monitoring what
>James is actually doing (Queue sizes, delivery throughput etc). One of
>the things we need to do for customers is show what's going on in the
>mail server. So, my question is, if there is nothing in James to do
>this, would the best way to expose such information be via JMX or via
>the RemoteManager interface?
>

Both!  Send patches dude:)

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

addUser(..) by JMX now.

[Paul Hammant]

Folks,

To give you an example, for JMX enablement, I have made addUser(..) in 
the main JAMES block callable from inside the main MX4J webapp.  See the 
new MBean class in the james package and the new .mxinfo file.   I have 
only delivered an 'operation'.  'Attributes' are simpler.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE:[Bug 11235]

[Paul Hammant]

Andrei,

>2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
>rules!!!)
>  
>
It does but it bloats the download by 700K and adds multiple seconds to 
the build times.  I personally prefer hand crafted xinfo files, but 
understand that many do not.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Phoenix 4.0 beta

[Paul Hammant]

Folks,

>Double check: Are we talking about the build files for JAMES or Pheonix.  Have you 
>tried doing a
>build with just 'ant compile' rather than 'build compile'  All the Avalon projects 
>got rid of
>build.bat and build.sh ages ago...
>  
>
I have upgraded Xerces to 2,0,2 but the build.bat|sh issue is still 
there.  I would suggest if you folks keep Ant, that you upgrade it in 
the tools/ dir to 1.4.1 or 1.5.

Ant, if you have it installed outside JAMES and have ANT_HOME set, works 
fine :-)

Regards,

- Paul



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Phoenix 4.0 beta

[Paul Hammant]

Double check: Are we talking about the build files for JAMES or Pheonix.  Have you 
tried doing a
build with just 'ant compile' rather than 'build compile'  All the Avalon projects got 
rid of
build.bat and build.sh ages ago...

- Paul

 --- "Noel J. Bergman" <[EMAIL PROTECTED]> wrote: > The problem is caused by upgrading 
to Xerces
v2.  If you replace:
> 
>   CLASSPATH=phoenix-bin/lib/xerces.jar
> 
> with:
> 
>   CLASSPATH=phoenix-bin/lib/xerces-2.0.1.jar:phoenix-bin/lib/xml-apis.jar
> 
> the build runs cleanly.
> 
> The reason that the build worked when jakarta-site2 was present is that
> xerces v1 is part of the site2 module, and xerces v1 had everything in one
> jar.  With Xerces v2, there are two jar files.  FWIW, Xerces 2.0.2 calls
> them xercesImpl.jar and xmlParserAPIs.jar.
> 
> And the Windows build file, build.bat, is completely different!  It says:
> 
>   set
> CLASSPATH=lib\xerces-1.4.3.jar;tools\lib\velocity-1.3-dev.jar;tools\lib\jdom
> -b7.jar
> 
> There isn't a xerces-1.4.*.jar in the lib/ directory.
> 
>   --- Noel
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>  

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Phoenix 4.0 beta

[Paul Hammant]

Folks,

In your CVS now is Phoenix 4.0 beta.  Enjoy.

The most interesting thing delivered is JMX via MX4J's HTTP adapter. 
 Launch the app, and navigate a web browser to http://localhost:8082. 
 There is nothing there that is specific to JAMES, but there could be if 
you create some interfaces like 
http://cvs.apache.org/viewcvs/jakarta-avalon-apps/demo/src/java/org/apache/avalon/apps/demos/helloworldserver/HelloWorldServerMBean.java

You have two choices to complete the JMX picture.

1) Use xdoclet like the 
http://cvs.apache.org/viewcvs/jakarta-avalon-apps/demo/ project (see the 
javadocs tags in the two interfaces -> 
http://cvs.apache.org/viewcvs/jakarta-avalon-apps/demo/src/java/org/apache/avalon/apps/demos/helloworldserver/)

2) Hand craft the .xinfo and .mxinfo files.  Here are the two that are 
generated by the xdoclet technology mentioned above:


http://jakarta.apache.org/phoenix/blockinfo_1_0.dtd";>

  
  
1.0
  
  
  

  
  
  

  
  
  

  


  

  



http://jakarta.apache.org/phoenix/mxinfo_1_0.dtd";>


  
  
  



- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Noel 

>>I am not using [James] logging since we have logging facilities of our own
>>
>>
>
>If you could have James use YOUR logging facilities, without your having to
>change Jame's code, would you?
>
>  
>
He does.  It is a static logger.  Completely compatible with JAMES core, 
but not very transportable.  When we move to classloader separated 
maillet jars (1..n mailets in one jar), the staticd logger solution does 
not work unless the logger classes are mounted in a mutually visible 
classloader (like phoenix/libs/).

This is the same problem that people using EJB encounter if the seperate 
their beans.  

Static logging is fine for a team to choose, it's just that they should 
not think their Mailets (I'm not going to say MAILET anymore despite 
being instructed to do so ;-) are components worthy of sale.

- Paul



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Noel,

>>Avalon is a project.  How many times do I have to ask you to say
>>Avalon-Framework to mean the multi-use IoC interfaces?
>>
>>
>
>When I mean Avalon Framework, I say Avalon Framework.  When I meant the
>programming model, I have used Avalon model.  Are you saying that you prefer
>the term framework to be overloaded to refer to the programming MODEL, too?
>  
>
I'm saying that in the email in question, you were using just the word 
Avalon in a few significant places.  I also have a prob with 'Avalon 
programming model' and 'Avalon model' as it's completely new as a term. 
 You'll not find me using or advocating the term 'framework'  I suprised 
you drew these conclusions.

>>I'm still uneasy about your use of the word platform.  I'd prefer
>>container as platform means Win32 / unix / etc to me.
>>
>>
>
>Hmmm ... I'll give that some thought.  I understand your point.  I think it
>would make things clearer for Danny, too.
>  
>
Thanks :-)

>  
>
>>Ohh blimey, I should read ahead in mails.
>>
>>
>
>Yes you should!  LOL  I thought I did a good job in that one of presenting
>first the way it is now, and then the way Avalon Best Practices would
>suggest.  You jumped the gun.  :-)  But that's OK.  My revenge comes when
>you sit down to do the sample container.  ;-)  I very much look forward to
>seeing it.
>  
>
I know.  I think I am going to do a container and a unit test container. 
 Can someone give me the new design (single method?) Mailet API to start 
with?

Cheers,

-ph


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

MAILET API....

[Paul Hammant]

Folks,

Can we suspend this topic.  Though there has been movement and increased 
grok (do you all know where that word came from ?), we're still typing 
loads about the same stuff.

Can we divert to some other topic till I get the demo done.

How about folding in the proposals or thinking about management?

-ph



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Noel

>[...]
>Now, back to your other question "what is the other mail server going to do
>since it does not support the concept [of inboxes or repositories]?"
>
>The answer is that it depends.  It depends upon how we specify things.  This
>is part of the challenge.  Right now, the Mailet requires a store component
>from the context:
>
>  compMgr =
>getMailetContext().getAttribute(Constants.AVALON_COMPONENT_MANAGER);
>  MailStore mailstore =
>compMgr.lookup("org.apache.james.services.MailStore");
>  
>
-1.  I'd vote for MAILETS implementing Composable or Servicable :---

 MyMailet implements Mailet, Composable {
MailStore ms;
Blah processMailRequest(Blah blah) BlahException {
   return null;
}
public void compose(ComponentManager cm) throw ComponentException {
  ms = cm.lookup("org.apache.james.services.MailStore");
}
 }

It is better IoC.

MailetContext should be specific to things that are peculiar the 
mail-context.

>As I understand it, the Avalon "Best Practice" on this would be to have
>Mailet components be composable.  If the configuration for the component
>said that it needs the MailStore service, the container will (a) know, and
>(b) make it available early in the component's lifecycle.
>  
>
Ohh blimey, I should read ahead in mails.

>I believe I am correct about this (and this also seems to be Nico's
>suggestion).  If so, I hope that Paul's example Mailet Container, which he
>has indicated he will post, will illustrate this point.
>  
>
Gawd, this is gunna be heavy for me to write ;-)

>As to the nature of Repositories and Stores, we already have interfaces for
>UsersRepository, MailRepository, SpoolRepository, MailStore, etc.  If those
>are sufficient, then we just use them with composable mailets.  If not, then
>perhaps the most flexible approach would be JNDI with some specific helpers
>to make life easier.  Some aspects of JNDI make sense (keyed access to node,
>dynamic keyed attributes on node), if we can keep it SIMPLE for simple
>cases.
>  
>
A lot of people are beginning to think of JNDI as part of the problem, 
not part of the solution.

>The problem isn't that Avalon-Framework has a failing.  The issue is whether
>we are willing to mandate that Mailet containers must support the Avalon
>programming model, as proposed for JSR 111.  As I understand it, this
>requirement does not impose significant development requirements on the
>container, but does result in benefits.  We'll see at the weekend, when Paul
>provides his proof-of-concept container.
>  
>
Gulp, me again ;-)

>>Frankly, I don't feel smart enough to know what the best solution is,
>>so I don't want to add logging to the mailet API and impose my
>>technical opinions on other mailet developers.  I don't think it's
>>appropriate to say SHALL.
>>
>>
>
>If we go with the Avalon model, then if someone didn't like interface A, and
>came up with a better A', they can instrument the container to support both
>components that use A, and components that use A'.  This future-proofing is
>one of the benefits.
>
People like our API so much it is cloned all over the place.  Typically 
they do not like the work apache in the package name.  For thise that 
do, but still clone, they don't like the word Avalon.  It is changing 
now though.

-ph




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Noel,

>>Because then we'd end up having to rip off, or re-invent, a logging
>>mechanism for ourselves. Which seems daft.
>>
>>
>
>Agreed.  Although there is a difference between a mechanism
>(implementation), and a standard interface.  In the latter case, container
>authors simply have to adapt the standard interface to the "native" logging
>mechanism.
>
>  
>
>>So the choice is either to use a logging framework which can overlay a
>>number of common logging products, [or] to leave logging to the
>>discretion of the writers of Mailets.
>>
>>
>
>It isn't sufficient to say take that you'll "leave logging to the discretion
>of the writers of Mailets", and keep the Mailet API "clean."
>
>If the "writers of Mailets" lack a common INTERFACE to access logging, then
>every mailet that needs access to logging will be required to be
>platform-specific.
>
>Avalon addresses this in two cooperative parts:
>
> 1. Avalon Frameworks provide common interfaces that components expose
> 2. Avalon containers inspect components to see what interfaces they expose,
>and provide them with the services they need.
>
>This means that a vendor specific container can support both components that
>use the platform-neutral interfaces, and components that use
>platform-specific interfaces.  Component authors are afforded the choice of
>platform-independence or additional functionality on a
>component-by-component basis.  If a container does support a service, e.g.,
>logging, it can simply not provide that service to the component.
>Configuration files can provide further refinement over runtime bindings.
>
>Paul will correct me, in sure, if I've gotten any points wrong.
>  
>
I'm still uneasy about your use of the word platform.  I'd prefer 
container as platform means Win32 / unix / etc to me.

-ph



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Noel dude,

Avalon is a project.  How many times do I have to ask you to say 
Avalon-Framework to mean the multi-use IoC interfaces?

>>the question becomes do we link the Mailet API to the avalon framework
>>components.
>>
>>
>
>Yes, the real question is how to make use of the Avalon programming MODEL in
>the Mailet SDK.  The answer is that if you adopt the Avalon model, you do
>keep clean interfaces because Avalon builds components by composition of
>interfaces.  Other approaches, e.g., the current Servlet API, are less
>finely factored.  This is a reason why the JSR 111 specification refers to
>refactoring existing API sets in time.
>
[...]

-ph




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Dave,

>A few ideas to add to the discussion 
>
>What about other 'services' which the container could/should provide.
>Configuration being a case in point.
>
>The avalon framework provides a rich configuration toolkit.
>The current Mailet API restricts the configuration to name value pairs.
>
>If you are going to add (or link) the avalon framework logging components to the
>Mailet API, then why only add one part of the framework.
>Surely, there would be a case for also adding the configuration components, and
>possibly others as well.
>  
>
>So, the question becomes do we link the Mailet API to the avalon framework
>components.
>Not just the logging components, but logging, configuration and possibly others.
>  
>
+1

>(I'm not suggesting that we should, just extending the scope of the question)
>
>If the aim is to make the Mailet API general purpose, similar to the Servlet
>API.
>Then it might be useful to look at some simple and complex Servlets as possible
>use cases.
>
>To write a simple request/response Servlet, all you need is the stripped down
>Servlet API.
>No logging, no configuration, just handle the request and response.
>One (theoretical) application would be a simple Servlet running on an embedded
>device in a domestic appliance.
>A web server in a fridge which responds to a HTTP request with an XML fragment
>containing the current temperature.
>No logging API required, because there isn't anywhere to log to.
>
>For a complex content management system, have a look at Cocoon.
>Cocoon is a whole framework on its own, providing a rich set of tools to the
>components inside it, including hooks to the Avalon framework configuration and
>logging components.
>
>If we look at the Mailet API in the same way.
>One (theoretical) application would be a simple Mailet running on an embedded
>device in a domestic appliance.
>Send an email to the fridge, and it replies with an email containing an XML
>fragment with the current temperature.
>No logging, as there is no where to log to.
>No configuration, everything apart from IP address is hard wired in silicon.
>
>On the other hand, for a full scale enterprise level messaging system, with JDBC
>repositories, LDAP user repositories, mailing lists, multiple user aliases etc.
>you need a rich toolkit including both configuration and logging components.
>
>Perhaps there are three projects in one.
>1) The Mailet API (equivalent to Servlet).
>2) The reference server implementation (equivalent to Tomcat).
>
>plus, people working to extend this to implement
>3) An Enterprise scale mail management system (equivalent to Cocoon).
>  
>
That includes me.  We have _working_ HSQLDB working as a block.  Jo! 
Webserver as a block (Cataina in some days).  EnterpriseObjectBroker as 
a block.
Other teams are doing work on a multiple impl Authentication block. 
 Others still are making a JMS block.  Stephen on the Avalon-apps 
project is making a CORBA ORB block.

There is no reason why a MAILET thru the Serviceable API could not 
lookup anyone of these.

>To be honest, I missed this distinction when I started working on my own
>Mailets.
>I saw the 'E' in JamEs and immediately started thinking in terms of a full scale
>Enterprise system.
>It is only really since reading the ideas and thoughts in this discussion that
>the three distinct parts have become clearer.
>
>Following the Servlet/Mailet analogy.
>How about this :
>1) The Mailet API is the absolute minimum required to process an email.
>2) The current implementation of James as a container for the Mailet API, with
>the required protocol handlers and basic storage, e.g. file based MailRepository
>and SpoolRepository.
>3) The Enterprise components (and here I would include things like the JDBC
>Repository etc.) could live inside an EnterpriseMailProcessor, which _is_a_
>Mailet.
>
-1.  That is what Phoenix is for.  Classic provision of different 
services.  A particlar MAILET when packaged with some of these blocks 
for a bespoke need, could be interoperation (publishing) to a web page.

Hell, A different MAILET could be using Cocoon for rendering of an 
XSP/XSL html-email page that is sent as the body of an email.  The 
Cocoon team have stated they you like to be able to run outside of 
servlet context as a rendering engine.  They have done the abstractions 
already, just noone has made the block wrapper. V.cool.

>Much like Cocoon _is_a_ Servlet, but also acts as a container for XML
>Generators, Transformers and Processors etc. with its own configuration and
>logging services. The EnterpriseMailProcessor Mailet would provide access to the
>Avalon framework services such as logging and configuration required by a
>complex Enterprise scale message system.
>  
>
-1 again dude.  Not a maillet, a block.  Design is finished, no need for 
hacked container impl

>Hope this helps.
>  
>
A quality posting.

-ph




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Darrell,

Well put.  Not sure whether you're in favour of mymidon or not.

On the issue of subset, I'm going to move on to A-F's Initializable 
interface instead of the current init() (as per previous emails of mine).

- ph

>On Tue, 11 Jun 2002 15:38, Noel J. Bergman wrote:
>  
>
>>Now you just need to convince people with voting rights.  ;-)
>>
>>  --- Noel
>>
>>
>
>Ummm, I'd be one of those I guess, although I'd be extremely reluctant to use 
>it, since I've been off in Myrmidon (Ant2 proposal) for some time.
>
>I read this thread with interest, and I have a few comments.
>
>* I pretty much agree with Danny and Serge that the Mailet API itself 
>shouldn't have any direct dependencies on the Avalon Framework, if possible.
>
>* Any Mailet written solely against the Mailet API will function perfectly in 
>James, the Reference implementation of a Mailet container.
>
>* This doesn't mean that a particular Mailet shouldn't be able to use Avalon 
>Framework interfaces, in a container that supports those interfaces. eg 
>LogEnabled: I think that LogEnabled provides a clean, implementation neutral 
>way of getting a Logger from the Mailet container, but some mailets may 
>choose other ways. However, in using LogEnabled the Mailet author is saying:
> "this mailet can be used in any container which supports both the Mailet 
>API and the Avalon LogEnabled contract".
>
>* I believe that James should provide support for a relevant subset of Avalon 
>contracts, maybe just LogEnabled, or any others that seem very useful. This 
>would be value-added behaviour of James the Mailet container, providing 
>additional services (beyond the Mailet API) to any hosted Mailets. 
>
>* If a Mailet writer wants their *LogEnabled* Mailet to work in a 
>non-avalonized container, they would need to ensure that they provide a 
>default Logger themselves in the case that "enableLogging(Logger logger)" 
>isn't called.
>
>* The big question is whether the core James mailets use LogEnabled. I say 
>"why not?". After all, these are just mailet implementations, and not part of 
>the MailetAPI itself. Maybe we can provide an adapter which can be used to 
>run LogEnabled Mailets in non-avalonized containers, but I wouldn't be 
>surprised if *all* Mailet containers end up supporting LogEnabled directly. 
>
>I guess the main point is that we can have the Mailet API completely 
>independent of Avalon-Framework, yet still *support* Avalon-Framework 
>contracts in James, the Mailet Container. This keeps the Mailet API clean, 
>and hopefully future-resistant, while allowing us to reuse some of the 
>concepts and strategies which have proven so useful in Avalon.
>
>  
>





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Andrei,

>Thank Paul for explanation of the terms.
>One of my points to participate in this discussion is to learn right
>terminology and see the things (Avalon etc) from point of view of
>developers.
>  
>
:-)

>>* Avalon is a project.
>>* A-F are interfaces that are a good match for _any_ hosted comps
>>* Phoenix is a container
>>* JAMES is the reference impl container for the MAILET API and sits on
>>Phoenix.
>>
>>
>
>As I see it the problem is that James acts as both:
>
>-as reference impl
>-as container
>
>Does it mean that there is no Mailet API reference impl at all (because
>there is no Mailet API, one which is known and used), and we are just
>thinking (because of different reasons etc) that there is one?
>  
>
Yes there is one.

Think org.apache.james.mailet.*
Think org.apache.james.server.*

These are not representative of now, but they are ilustrative of the 
separation.  The former compiles to mailet.jar, the latter to 
james-server.jar

- Paul




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Danny,

>>A small point (on the otherwise fair rollup below):  An individual
>>changing their mind on a subject or even moving slightly can be a good
>>thing.  Typically school leaves us westerers with a
>>don't-admit-you're-wrong-or-say-you-are-sorry attitude, that affected me
>>personally until I was about 25. I'd like to apologise to all those that
>>suffered unjustly at my hands before then ;-)
>>
>>
>
>Thank you Paul,
>I'm not "flip-flopping" I'm modifying and refining my own opinion based upon
>a discussion of the issues with other interested people.
>
>I have reduced my oposition to dependance on a.f and increased my resistance
>to providing sophistcated logging based upon consideration of the opinions
>expressed on this list.
>  
>
Yes I know, all is good stuff I think ;-)

-ph




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Danny,

>[...]
>So the choice is either to use a logging framework which can overlay a
>number of common logging products, we're discussing parts of
>avalon.framework for this role, or to leave logging to the discretion of the
>writers of Mailets.
>  
>
Push versus pull
IoC versus static logging apis.

IoC based loggers are runtime reassignable by the container

Fault noted with Mailet01.  Adminr signs in and bumps the logging level, 
or actions a remote logger for Mailet01

-ph




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Noel,

>>I cannot imagine *any* container written in Java that does not have the
>>capability to do instanceof.
>>
>>
>
>You miss understand.  I do not mean that a container is somehow unable to
>have the capability.  I simply mean that containers cannot naively assume
>that the Mailet interface is the only interface implemented by the object.
>
Yup. I can only imagine a max of say five containers for MAILET for the 
first five years.  It will be easy to ensure compatability.  Especially 
if the JAMES project publishes some 'unit test' MAILETs.

>They must go through the introspection process not only for possible
>"platform-specific" functionality, but also for optional
>platform-independent functionality, such as logging.  This is nice way to
>add fine grained composition to Java, but it is not a common paradigm SO
>FAR.
>
We'll see.  May other significant teams/projects have done the same but 
with a knock-off of Avalon Framework interfaces, without 
acknowledgement.  With a smal refactoring that for the large part is 
hidden from their user base, they could be Phoenix compatible quite 
quickly...  

>>From some but not all quarters.
>>
>>
>
>Not from all, but some of them are key.  
>
Agree.

>In any case, the purpose for the
>discussion is to look over and discussion the options.
>
:-)

>>>If these patterns were embedded in javax.frameworks.*, I doubt
>>>that we'd be having this part of the discussion.
>>>  
>>>
>>JSR 111?   [Aalon's Framework] is shortlisted as a candidate.
>>
>>
>
>Seems like the best choice I've seen so far.  It is interesting to
>contemplate how other Java interfaces might be different if javax.service
>had been in place first.
>
>Actually, I would argue that even if Avalon Framework is not accepted, it is
>a safe bet to use Avalon's programming approach.  Because whatever is
>adopted, post-JSR 111 Phoenix should be able to support both A-F and JSR 111
>objects.
>
Phoenix just being one container.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Noel,

A small point (on the otherwise fair rollup below):  An individual 
changing their mind on a subject or even moving slightly can be a good 
thing.  Typically school leaves us westerers with a 
don't-admit-you're-wrong-or-say-you-are-sorry attitude, that affected me 
personally until I was about 25. I'd like to apologise to all those that 
suffered unjustly at my hands before then ;-)

>Danny Angus:
>
> -1: org.apache.avalon.framework.logger.Logger getLogger();
>
>Fine.  One of the purposes for putting forth this strawman was because I
>perceived a certain amount of flip-flopping on the issues.  For example,
>this was your original stance, but I perceived you to change your mind in
>some of your replies to Paul, after he explained that the logger framework
>was purely an interface.
>
>Serge:
>
> -1: org.apache.avalon.framework.logger.Logger
> -1: logging in the Mailet API at all
> Alternative:
>getServletContext().getAttribute("avalon.framework.logger")
>
>I understand Danny's point.  I related that point several times to Paul, but
>I perceived Danny to flip-flop, which is one of the reasons behind this
>exercise.
>
>I strongly DISAGREE with removing logging from the Mailet API.  You look at
>the logging in James.  Go ahead and remove it all.  I dare you.  ;-)  Humor
>aside, there is clearly a need for components to have a standard,
>platform-neutral, way to log information.
>
>Your alternative does us no good, because it creates platform specific
>matchers and mailets.  We need to specify the interface for logging, so that
>components can log regardless of which platform they are running on.
>
>Andrei Ivanov:
>
>  
>
>>This solution still stores all log data into one file.
>>
>>
>
>No it does not.  It says NOTHING about the implementation.  It only
>specifies the interface.
>
>  
>
>>Can "per mailet" logger configuratuon be implemented?
>>
>>
>
>That depends upon the implementation of getLogger().
>
... and up to the container.  The container may even want to have a JMS 
impl of logging to fire off log events to some remote manager.

>>Why GenericMailet can not simply extend AbstractLogEnabled
>>
>>
>
>Because Danny does not want to "contaminate" the Mailet API with Avalon
>Frameworks.  I am not agreeing or disagreeing at the moment.  I am trying to
>get the options explored in concrete terms.
>
>Now, Paul and Nic want to go the Avalon Frameworks route.  Instead of
>defining an interface that tells a Mailet that it can have a logger, there
>is nothing in the Mailet interfaces that would suggesting logging is
>possible.  HOWEVER, the abstract base class implements LogEnabled, and that
>tells the mailet container that it can (and should) setup logging on that
>Mailet.  The definition of the abstract base class would be part of the
>Mailet specification,
>
The abstract base class is optional of course.  An individual MAILET 
could choose to implement LogEnabled directly (or not at all). 
 AbstractLogEnabled is
an almost insignifiant time-saver.

> so that's not a bad thing, just rather a different
>approach from the current scheme, which borrows design ideas from the
>Servlet specification.
>
>Regardless of whether or not Mailets are running on a system using Avalon
>frameworks or not, there is a need for platform-neutral logging capability.
>
I'm confused about the use of the word 'platform' ;-) Noel dude, could 
you elaborate :-)

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

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:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

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:   
For additional commands, e-mail: 

Re: Finer Logging Control for Mailets/Matchers

[Paul Hammant]

Danny,

>>Java API is one.
>>For Apache Java servers, it's Avalon Framework.
>>
>>
>
>Thats exacly the point, the Mailet API isn't an Apache Java Server, it
>provides an API which James implements, but I'd like to see other products
>implement it as well.
>(and in fact my new employers are already doing just that)
>  
>
This is good.  A second impl of a container that is MAILET API capable. 
 Be careful not to change JAMES into your coman's app in the process 
dude ;-)

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Andrei,

>I think there is still principal question which has to be addressed first.
>The question is: will Mailet be Avalon dependant or not?
>
Correction: Will the MAILET compatible container recognize optional 
Avalon-Framework interfaces or not?

>If Mailet is clean from Avalon then logging can be removed from Mailet API,
>but if Mailets will be Avalonized then logging must (more precisely may) be
>in API. 
>
v.v ?

>Before this is decided no further speculations make sense.
>I don't see anything against Avalonization of Mailets.
>What is the bottom line of this discussion since James runs on the top of
>Phoenix and Phoenix is on the top of Avalon? 
>
Correction: JAMES (the reference MAILET impl) runs on top of 
Avalon-Phoenix.  In the future, a proposition is that classes 
implementing the MAILET API, _may_ also implement selected interfaces 
from the Avalon-Framework APIm which is also part of the Avalon project.

>James (like Mailet API) shall be Avalonized, or... whole James has to be
>rewritten from ground up to keep it consistent with something else than
>Avalon...
>  
>
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.

_Please_ could people get their terms right.  
* Avalon is a project.  
* A-F are interfaces that are a good match for _any_ hosted comps
* Phoenix is a container
* JAMES is the reference impl container for the MAILET API and sits on 
Phoenix.

-ph


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Serge,

>> Alternative would be to break with the Mailet v1 API entirely, and go 
>> with:
>>
>>interface Mailet extends 
>> org.apache.avalon.framework.logger.LogEnabled
>>
>
> -1 for Avalon dependency (danny's spoken on this), and -1 for logging 
> in the mailet API.  I don't believe there is clear enough demand for 
> this, and the demand I do have seen has varied requirements.

You are misisng the fact that _all_ Avalon-Framework interfaces are 
optional.  The barest minimum MAILET API impl is :

  MyMailet implements Mailet {
 Blah processMailRequest(Blah blah) BlahException {
return null;
 }
  }

You are missing completely the nature and long development & design by 
Apache luminaries of the framework interfaces.  The container's role is 
to see which of these interfaces the MAILET implements and decorate the 
(with method invocations) accordingly.

There is no dependancy.  They are container recognised optionals.  This 
is fundamental SoC, with the container decorating with method calls 
according to IoC.

> I'd +1 an approach that leaves logging out of the mailet API but 
> provides a convenient way to get a logger object from the container 
> (maybe something like 
> getServletContext().getAttribute("avalon.framework.logger")).

-1  ( I appreciate that according to my original contract with you folks 
that my vote on JAMES matters is worthless).

-ph


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Nicola,

> > abstract class GenericMailet implements Mailet, MailetConfig
>
I'd prefer name of AbstractMailet.

>Let me try to show you a more deeply Avalonized solution...
>
>
>interface MailetContext
>implements org.apache.avalon.framework.context.Context
>{
> void log(String message);  // deprecated
> void log(String message, Throwable t); // deprecated
>}
>
>abstract class Mailet
>   implements org.apache.avalon.framework.logging.LogEnabled,
>  org.apache.avalon.framework.context.Contextualizable
>  org.apache.avalon.framework.parameters.Parameterizable
>  
>
Oh excellent.  Ideal in fact.

Good SoC.

-ph



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Mailet API] Logging Proposal

[Paul Hammant]

Noel,

>interface MailetContext
>{
>   org.apache.avalon.framework.logger.Logger getLogger();
>
>
>  
>
-1  ,  breaks IoC.

>Alternative would be to break with the Mailet v1 API entirely, and go with:
>
>   interface Mailet extends org.apache.avalon.framework.logger.LogEnabled
>  
>
-1 , breaks SoC.

-ph



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet API was RE: Finer Logging Control for Mailets/Matchers

[Paul Hammant]

Serge,

>> I did not mention clone(), and I'll reassert that it is pointless to 
>> consider instantiation issues for a heavy TCP/IP using tool.
>
>
> You've now twice made the point that this is a heavy TCP/IP tool as a 
> reason to not worry about performance related issues.  While it's true 
> that for a single mail message, network speeds will be the larger 
> determinant of its delivery time, it is wrong to think that such a 
> server doesn't have to take performance issues into account. 

I did not say _does not have to_ , I said for worrying about immutable 
objects in an API.

>>> However, it is a bit
>>> of a moot point, since the mail object is largely a carrier for
>>> javax.mail.internet.MimeMessage, which is not immutable (more on 
>>> this in a
>>> moment).
>>>
>> Perhaps you should consider a clean MimeMessage interface for your 
>> maillet API.
>
>
> I'm sorry, but I consider this is absolutely out of the question.  
> Years have gone into that standard and implementation, thousands of 
> people know it, and there have been no compeling arguments to use a 
> different API.

Fine but you are already dubsetting the javax.mail api...

> Also, it's MAILET, not maillet.  Sorry, just my version of your 
> "Avalon" pet-peeve.

I'll learn this first time.

- Paul



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: newavalon dir in CVS.

[Paul Hammant]

> I did not see that this had been uploaded. I've put (I am guessing) a 
> more recent release of Avalon-Phoenix in the phoenix-bin directory.  
> Can I delete the 'newavalon' directory please?


no objections ?

-ph



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet API was RE: Finer Logging Control for Mailets/Matchers

[Paul Hammant]

Noel J. Bergman wrote:

>Paul,
>
>Yes, TCP/IP is a factor, but I'd be more concerned about GC and memory
>issues, not the CPU impact of performing the clone().  
>
I did not mention clone(), and I'll reassert that it is pointless to 
consider instantiation issues for a heavy TCP/IP using tool.

>However, it is a bit
>of a moot point, since the mail object is largely a carrier for
>javax.mail.internet.MimeMessage, which is not immutable (more on this in a
>moment).
>
Perhaps you should consider a clean MimeMessage interface for your 
maillet API.

>>There is _nothing_ wrong with having a small tree of interfaces for
>>Maillet types.
>>
>>
>
>A "small tree of interfaces" wasn't the issue.  The issue was the loss of
>polymorphism.  Although that isn't always a fatal flaw, the loss of
>polymorphism is never a good thing, and should be avoided without very good
>reason.  That is just good general policy.  In this case, I think that there
>are other ways to achieve the desired goal(s).
>
>One simple solution would be something like:
>
>  recipients = matcher.match(matcher.isAllowedChange() ? mail :
>mail.duplicate());
>
>  mailet.service(mailet.isAllowedChange() ? mail : mail.duplicate());
>
Yup that is good too.  I'd vote for a single multi-purpose method as 
long as the container had pre-profiled the _XML_ declarations for the 
maillet.

The downside is that it is a smell to return void when the maillet has 
no need for forwaring a mail back into the pipeline.

>(nb: if we care about mail.getState(), we'll have to keep a reference long
>enough to check it).  That would create a copy for any matcher or mailet not
>allowed to affect a change in the content of the object.
>
>The aforementioned approach says, "we don't know what you might do, and
>can't keep track, so we'll simply give you a copy to damage as you might"
>but it does not address the general problem of malicious components.  For
>example, a malicious mailet involved in industrial espionage could still
>quietly queue up copies.
>
>This is a general problem, of which the same could be said of rogue Blocks,
>servlets, or any other pluggable component in a pluggable architecture.
>
I disagree.  The applet model has not been broken ( in terms of security 
) in anything other than a denial of service attack (redirect, opening 
of windows).  Blocks similarly are fine in terms of security, a 
malicious block cannot hack the kernel...

>
>The Java answer to this general problem appears to be Java Security.  
>
Yes yes, which Phoenix (and other containers) leverage too.

>A
>wrapper on mutable components, e.g., MimeMessage, could do security checks
>to see if there is permission to affect the desired change.  Likewise, there
>could be a permission check to see if a mailet is permitted to post a new
>message to a processor queue.  Now the administrator can control exactly
>what operations are permitted by a given component.
>
Yup given their XML declarations in MAILLET-INF/maillet.xml

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet API was RE: Finer Logging Control for Mailets/Matchers

[Paul Hammant]

Noel,

You are dealing with TCP/IP yes.  Including marshalling, it is 1000's of 
times slower than object instantiation yes? Even local loop is 100s of 
times slower.

There is _nothing_ wrong with having a small tree of interfaces for 
Maillet types.

I am only mildly in favour of the immutable parms.  It seems better 
security for the container against the malicious maillet, but as I say 
for this TCP/IP using beast, performance is not a justification for 
avoiding immutable. It also fits well with the AltRMI tool that the 
Avalon team developed (Which I'm guessing that still none of you have 
read up on).  This would allow the concept of a remote Maillet without 
changing or adapting the Maillet API at all.  Then again there is a case 
for having Mail as an interface, and for those Maillets that XML 
declared that they were non-modifying, the setters were disabled in a 
hand-crafted proxy.

Regards,

- Paul

>The processor should only have to know that it is calling a Mailet.
>Consider how this would be called from the processor.  The difference in
>return type means that you have to know what you are calling in order to
>call it.
>
>The Mail is not be immutable, give that the MimeMessage is not immutable.
>Matchers and Mailets are permitted, if not sometimes required, to change the
>contents during processing.  Having to clone something just to make a change
>is not a happy pattern when it comes to performance.
>
>The init() and service() interfaces are part of the general *let pattern.
>
>I do wish, however, that the bean pattern for mutators had been
>
>   Class C { C setProp(T p); }
>
>instead of
>
>   Class C { void setProp(T p); }
>
>but Sun blew that one ages ago.
>
>   --- Noel
>
>-Original Message-
>From: Paul Hammant [mailto:[EMAIL PROTECTED]]
>Sent: Saturday, June 08, 2002 18:16
>To: James Developers List
>Subject: Re: Mailet API was RE: Finer Logging Control for
>Mailets/Matchers
>
>
>Danny,
>
>I'd vote for ...
>
>interface Maillet {}
>interface ConsumingMaillet extends Maillet {
>
>  void processMailRequest(Mail mail) throws MailetException;
>
>}
>interface ModifyingMaillet extends Maillet {
>
>  Mail processMailRequest(Mail mail) throws MailetException;
>
>}
>class Mail {  // value objects
>  private final Foo foo;
>  private final Bar bar;
>  public Mail(Foo foo, Bar bar){
> this.foo = foo;
> this.bar = bar;
>  }
>  Foo getFoo() { // etc.
>}
>
>I like the immutable Mail bean. All part of the API.
>
>Idon;t like the service() method name :-)
>
>- Paul
>
>
>  
>
>>>I'll hope that you have a simple API like :
>>>
>>>  MailAction mailRequest(MailItem mailItem) throw MailRequestException;
>>>
>>>  
>>>
>>'s funny you should say that, 'cos I'd like to hear your opinion on this..
>>
>>two alternatives;
>>
>>a) Mail service(Mail mail) throws MailetException;
>>
>>and
>>
>>b) void service(Mail mail) throws MailetException;
>>
>>the difference being that a returns a Mail which continues through the
>>processing, _as__if_ the Mail had been passed by value, and b alters the
>>existing message as if it had been passed by refrence (which of course it
>>has).
>>
>>Now I did a lot of C programming, where the refrence approach was the
>>conventional one, but in Java the by-value analogy seems to be the expected
>>way.
>>
>>the argument in favour of b is that it is more efficient, and actually
>>constrains processors to acting in a linear fashion, by not allowing new
>>Mails to be returned.
>>
>>Alternatively it might be argued (perhaps by me ;-) that a is the more
>>expected/acceptable signature and that anyway there is nothing stopping a
>>mailet from replacing the value of Mail mail with a new Mail anyway.
>>
>>d.
>>
>>
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
>  
>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Finer Logging Control for Mailets/Matchers

[Paul Hammant]

Noel ,

_Please_  Avalon-Framework not Avalon.

You're wrong tooyou mention 'Avalon object' (again context is 
misleading) yet the LogEnabled.java is an interface.  For alternate 
containers, it would return an alternate-conatiner object. For JAMES it 
would likely return a JAMES object, that might delgate thru to the A-F 
LogEnabled obj passed to it by the Avalon-Phoenix container.

You are going to end up with an undeniable knock-off of LogEnabled...

- Paul

>Paul,
>
>I believe that Danny's point is this: "Because other applications which use
>mailets to process mail might not have or want avalon ..."
>
>Therefore, he wants an org.apache.mailet.Logger interface, even if the
>implementation of MailetContext.getLogger() returns an Avalon object.  The
>Mailet Logger API might not differ from the Avalon Logger API, other than to
>effectively put it in the "right" package.  So the James implementation can
>happily use Avalon, since James is an Avalon applcation, but mailets should
>not have to import anything other than org.apache.mailets.*, java.* and
>javax.mail.* in order to access the Mailet API.
>
>The Mailet API definition will be interesting later, because such things as
>a mailing list mailet want to be able to control the underly mail platform,
>not just manipulate message content.
>
>   --- Noel
>
>-Original Message-
>From: Paul Hammant [mailto:[EMAIL PROTECTED]]
>Sent: Saturday, June 08, 2002 17:14
>To: James Developers List
>Subject: Re: Finer Logging Control for Mailets/Matchers
>
>
>Danny,
>
>  
>
>>>I agree ... so please explain exactly how this "wrapper interface" would
>>>differ from the logger facade in org.apache.avalon.framework.logger.  Are
>>>you simply saying that you want to put a facade over their facade so that
>>>the naming space is part of the Mailet API instead of Avalon?
>>>
>>>
>>>  
>>>
>>Yes, in a nutshell.
>>Because other applications which use mailets to process mail might not have
>>or want avalon or log4j or whatever.
>>
>>
>>
>Avalon is a project. I think you are referring to Logkit.  You will find
>that there is a truly excellent abstraction called LogEnabled in the
>Avalon-Framework interfaces. We have already implementations for this
>that route method invocations to Log4J, LogKit, JDK1.4 logging, The
>console and null: This is a really great API for an implementation
>neutral API to implicate.
>
>The Avalon-Phoenix container patches such calls thru to LogKit. The
>maillet API being evolved naturally will not name Avalon-Phoenix as a
>pre-requisite.  JAMES (the reference impl of the maillet API) sits on
>Phoenix.
>
>- Paul
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
>  
>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Mailet API was RE: Finer Logging Control for Mailets/Matchers

[Paul Hammant]

Danny,

I'd vote for ...

interface Maillet {}
interface ConsumingMaillet extends Maillet {

  void processMailRequest(Mail mail) throws MailetException;

}
interface ModifyingMaillet extends Maillet {

  Mail processMailRequest(Mail mail) throws MailetException;

}
class Mail {  // value objects
  private final Foo foo;
  private final Bar bar;
  public Mail(Foo foo, Bar bar){
 this.foo = foo;
 this.bar = bar;
  }
  Foo getFoo() { // etc.
}

I like the immutable Mail bean. All part of the API.

Idon;t like the service() method name :-)

- Paul
 

>>I'll hope that you have a simple API like :
>>
>>   MailAction mailRequest(MailItem mailItem) throw MailRequestException;
>>
>
>'s funny you should say that, 'cos I'd like to hear your opinion on this..
>
>two alternatives;
>
>a) Mail service(Mail mail) throws MailetException;
>
>and
>
>b) void service(Mail mail) throws MailetException;
>
>the difference being that a returns a Mail which continues through the
>processing, _as__if_ the Mail had been passed by value, and b alters the
>existing message as if it had been passed by refrence (which of course it
>has).
>
>Now I did a lot of C programming, where the refrence approach was the
>conventional one, but in Java the by-value analogy seems to be the expected
>way.
>
>the argument in favour of b is that it is more efficient, and actually
>constrains processors to acting in a linear fashion, by not allowing new
>Mails to be returned.
>
>Alternatively it might be argued (perhaps by me ;-) that a is the more
>expected/acceptable signature and that anyway there is nothing stopping a
>mailet from replacing the value of Mail mail with a new Mail anyway.
>
>d.
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

newavalon dir in CVS.

[Paul Hammant]

Folks,

I did not see that this had been uploaded. I've put (I am guessing) a 
more recent release of Avalon-Phoenix in the phoenix-bin directory.  Can 
I delete the 'newavalon' directory please?

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Finer Logging Control for Mailets/Matchers

[Paul Hammant]

Danny,

>>I agree ... so please explain exactly how this "wrapper interface" would
>>differ from the logger facade in org.apache.avalon.framework.logger.  Are
>>you simply saying that you want to put a facade over their facade so that
>>the naming space is part of the Mailet API instead of Avalon?
>>
>>
>
>Yes, in a nutshell.
>Because other applications which use mailets to process mail might not have
>or want avalon or log4j or whatever.
>
Avalon is a project. I think you are referring to Logkit.  You will find 
that there is a truly excellent abstraction called LogEnabled in the 
Avalon-Framework interfaces. We have already implementations for this 
that route method invocations to Log4J, LogKit, JDK1.4 logging, The 
console and null: This is a really great API for an implementation 
neutral API to implicate.

The Avalon-Phoenix container patches such calls thru to LogKit. The 
maillet API being evolved naturally will not name Avalon-Phoenix as a 
pre-requisite.  JAMES (the reference impl of the maillet API) sits on 
Phoenix.

- Paul



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Avalon terms - important please read

[Paul Hammant]

There is some confusion about Apache's Avalon project...

1) Avalon-Framework is a set of interfaces that an /arbitary/ container 
can use for hosted components.
2) Avalon-Phoenix is container that hosts fairly much any bizarre vision 
of a server written in Java.  Web servers, EJB servers, and Mail servers 
are good examples of such things.
3) Avalon-Excalibur is a very general set of helper classes for app 
development. Not exclusively server apps.
4) Avalon-Cornerstone is a set of Phoenix ready comps that do thing that 
servers are likely to need.  
5) Avalon-Logkit is an optional API for logging that fits the IoC 
pattern.  Itis quite well hidden by the LogEnabled Avalon-Framework 
interface.

Where we in JAMES are going wrong with terms/ideas

1) Avalon is nothing other than a project
2) Avalon-Framework is *not* tied to phoenix. Any container can use its 
amazingly logical interfaces for hosted components. JAMES is one such 
container.  Maillets are a good definition of hosted components.
3) If maillets implement Avalon-Framework they will not be touched by 
the Avalon-Phoenix container.

Can we :   Stop using the term Avalon as if it were a product *please*.

By the way the Avalon-Framework interfaces are so logical they have been 
both silently and with acknowledgement borrowed by other Apache projects 
and others outside Apache.  They are also being analysed by the JSR 111 
committee from the community process.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet API was RE: Finer Logging Control for Mailets/Matchers

[Paul Hammant]

Danny,

>It might be worth mentioning that I've been spending my free hours up to my
>armpits in a UML version of a possible new version of Mailet API.
>I hope to offer it as a proposal once I've created a successful
>implementation of it.
>
I'll hope that you have a simple API like :

   MailAction mailRequest(MailItem mailItem) throw MailRequestException;

...where MailAction and MailItem are either API specified interfaces or 
value objects.

I'd hope that the enitre set of Avalon-Framework (please don't use 
Avalon as a term for an API) interfaces are complimentary _interfaces_ 
for maillets.  They are Configurable, Contextualizable, Initializable, 
Suspendable, Parameterizable etc ( see 
http://jakarta.apache.org/avalon/framework/reference-the-lifecycle hmmm, 
this needs some mods ).

>I'm not convinced that a getLogger method is appropriate for the API
>
I agree. It isout of keeping with any peer. It is bad Soc / IoC.

> if it
> is going to make the mailet API depend upon any particular logging product,

>I firmly believe that the mailet API should be as independant of all but
>java.* and JavaMail as is possible to encourage its implementation in other
>vendors applications.
>
Agree, JavaMail ignorant.

-ph


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: PHOENIX_SECURE?

[Paul Hammant]

Noel,

>"Phoenix 4.0a4
>
>org.apache.avalon.framework.component.ComponentException: Cannot find or
>init repository: access denied (java.io.FilePermission
>/opt/james-2.1a1-cvs/apps/james/var/mail/spool read)
>
>...
>"
>
>This error goes away when I export PHOENIX_SECURE=false.  What do we need to
>do to run with PHOENIX_SECURE?
>  
>
I think you might be able to play with permissions in environment.xml


  

  

  

  


- Paul



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: lib/ changes?

[Paul Hammant]

Noel,

>   No JAXP compliant XML parser found. Please visit http://xml.apache.org
>for a suitable parser
>  
>
My apologies.  I switch between 1.3 amd 1.4 and 1.4 has the built in 
Xerces.  The default is 1.4 so if I invoke either 'ant' or 'build' it 
sees the parser in rt.jar.

- Paul



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: SAR-INF

[Paul Hammant]

Noel,

>Is SAR-INF/ the new home for config.xml, or will it move back to conf/ ?  If
>SAR-INF/ is going to stay the new home, we need to provide migration
>instructions to users.
>  
>
Inside the SAR file? yes it is the new home.

It should not be hard to write a small page describing the new  ant 
task ...

















- Paul



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Local security issue?

[Paul Hammant]

Noel J. Bergman wrote:

>Paul,
>
>  
>
>>Perhaps passwords should not be echoed to the log.
>>
>>
>
>LOL No kidding.  :-) My initial thought was to alert *current* users of the
>potential problem, and advise them of steps they could take immediately.
>
>The code can be changed.  As it stands, logging is at a point where it is
>just echoing back the command entered
>
>private boolean parseCommand(String commandRaw) {
>if (commandRaw == null) return false;
>getLogger().info("Command received: " + commandRaw);
>   ...
>
>We haven't gotten to the code that does the parsing, so we don't yet know
>that the line IS a password.
>
Ahhh OK :-)

Well either way, the user community must believe that JAMES will never 
journal/log passwords or they'll depart to other servers.

>
>I can move the log statement to after we parse out the verb.  FWIW, I also
>believe that this should be DEBUG, not INFO.
>
>Anyone object to these changes?
>

There is some wisdom that user ids should not be logged on failure of 
auth, as they might have been transposed with passwords by a hapless 
user.  Of course, if there are say 5 attempts with the same user id (and 
failing) then it is evidence of hacking and thus should be logged.

-ph

>  
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: SAR-INF

[Paul Hammant]

Noel,

I'm missing the start of this threadperhaps someone could be kind 
enough to forward postings from the last 24 hours concerning directly or 
indirectly Avalon...

>From: "Noel J. Bergman" <[EMAIL PROTECTED]>
>
>  
>
>>I guess we'll have to wait and see.  We're kind of hostage to whatever
>>Avalon does.  I really hope that they remember that some of us run servers
>>that DO NOT HAVE A GUI installed!  Making installation easier with
>>self-packaging is great, but not at the expense of ease of administration.
>>
>>
Referring to my BeanShell development that is alternate Kernel ?

Well, I'm going to make a third kernel that is headless but allows the 
user to telnet in and do the same Beanshell operations.  There are 
security issues, but they can be overcome too (SSH block)

- Paul



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Local security issue?

[Paul Hammant]

Noel,

Perhaps passwords shouldnot be echoed to the log. * instead ?

-ph

>Should we be warning admins that if the mail server has shell users or
>network file visibility, they need to be sure to lock down the directory
>containing the james logs, or at least the pop3server log?  The reason being
>that all commands received are echoed to the log ... including the user's
>password.
>
>Alternatively, they could be told to change the logging level from DEBUG to
>WARN.
>
>Comments?
>
>   --- Noel
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>
>  
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Apps Site upgrade and downloads available

[Paul Hammant]

Berin,

>On http://jakarta.apache.org/avalon/apps/apps/db/index.html
>the link to the API docs is a link to
>
>http://hack.hack/
>
>It needs to be fixed.
>  
>
Fixed.

-ph


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Apps Site upgrade and downloads available

[Paul Hammant]

Folks,

News on pre-release Apps for Phoenix

I've uploaded jakarta-avalon-apps/ source and binaries to my site at 
Apache http://cvs.apache.org/~hammant/apps/

Though the CVS versions use xdoclet to generate.xnfo etc, these 
downloadables use a pre-generated zip of those and the manifests to save 
bytes.

I have also updated the site for http://jakarta.apache.org/avalon/apps/ 
but am not sure if it completed properly.  It certainly has not been 
copied from CVS yet.  The principle reason for my confusion is that the 
process of committing the changes killed my yahoo account ("you are not 
allowed to send mails in excess of 400K").  The account was disabled for 
a while, but is OK now.  My other problem is that my ADSL provider 
disabled my account a week early.  I was planning to upgrade to another 
with a faster and cheaper connection. I can now expect two weeks of 
'slow' time as I use v.90.  Good old British Telecom and Homechoice 
(not).  The point is that I am not going to be so active in this 
relatively disconnected time and I have had a least a day of missed 
mail-list mail.  If there are any I have missed that scream 'Paul' could 
someone give me a heads-up.

Regards,

- Paul H


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: spurious messages!?!

[Paul Hammant]

Serge,

> No problem.  It wasn't until around the 4th message that I realized 
> what was going on myself. :)  As always, I really appreciate the work 
> you're doing to get James up to speed with Avalon. 

:-)

OK, I have booked in the changed code.  I cant for the life of me see 
how it compiles though, so there is a possibility that a trivial change 
will not compile.  I must be a manual cut/paste job for the wannabe user 
of those proposed features.  Could someone advise so that I can complete 
the job.

- Paul




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Beanshell Phoenix Kernel spyglass

[Paul Hammant]

Folks,

I've been working on hacker's Phoenix Kernel.  It basically extends the 
current Kernel but also launches a Beanshell window to allow inspection 
and interoperation on the running Phoenix machine.

Here is a log that I cut/paste from BeanShell ( I typed all these 
interactively... 'bsh %' is the promt):

bsh % prtapps();
0 james
bsh % prtblocks("james");
0 objectstorage
1 nntp-repository
2 nntpserver
3 nntpauth
4 remotemanager
5 dnsserver
6 scheduler
7 thread-manager
8 database-connections
9 mailstore
10 smtpserver
11 sockets
12 pop3server
13 James
14 users-store
15 connections
16 spoolmanager
bsh % o = getblock("james","dnsserver");
bsh % o2 = o.findMXRecords("microsoft.com");
bsh % print(o2);
[microsoft.com]
bsh % it = o2.iterator();
bsh % r0 = it.next();
bsh % print(r0);
microsoft.com

Interesting possibilities huh?  We're striving towards telnet into that 
shell.
By using this instead of the Phoenix in JAMES CVS, it give you a view of 
JAMES blocks from the reusers point of view.

For instance the above is a trail of the DNS Server.  I was hoping to 
drill into the DNS Record, but alas the collection returned 
by findMXRecords is of strings (should it be findMXRecordNames).  Still 
there are great possibilities.  For me, this level of block interaction 
is the prime API delivered by JAMES.  I'm always approaching blocks from 
the reuse point of view.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: spurious messages!?!

[Paul Hammant]

Serge,

OK, my apologies.  I am on to it.

I should have asked about the proposal dir.

- Paul

> Paul, Danny,
>
> Please read Samuel's full email.  He says he's trying to use the IMAP 
> proposal and was seeing if anybody knew why that wasn't working.  I 
> would assume it's because we didn't update Avalon dependencies in the 
> proposal dir, right?





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: spurious messages!?!

[Paul Hammant]

Samuel,

I am going to confirm that following a fresh & clean checkout of james 
CVS (just for you), the problem as you describe it does not exists for 
me.  Here is the entire boot log:

  Phoenix 4.0a4
  James 2.1a1-cvs
  Started POP3 Server plain:110
  Started SMTP Server plain:25
  Started NNTP Server plain:119

- Paul




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: spurious messages!?!

[Paul Hammant]

Samuel,

I refer you to my previous answer.  With latest CVS for _ALL_ 
directories you should not get this.
Are you running blocks or any java classes that are not from the latest 
HEAD revision of JAMEs CVS?

- Paul

> Hi all,
>
> I am using the latest version of James 2.1a1 from CVS.
>
> After successfully upgrading James from 2.03a to 2.1a1 and run the 
> program, I keep getting the following messages:
>
> The Block named "imapsystem" (implementation class 
> "org.apache.james.imapserver.
> IMAPSystem"), implements a service 
> "org.apache.james.imapserver.IMAPSystem" whic
> h extends a Lifecycle interface 
> "org.apache.avalon.framework.context.Contextuali
> zable". This violates the expected usage patterns.
> The Block named "imapsystem" (implementation class 
> "org.apache.james.imapserver.
> IMAPSystem"), implements a service 
> "org.apache.james.imapserver.IMAPSystem" whic
> h extends a Lifecycle interface 
> "org.apache.avalon.framework.component.Composabl
> e". This violates the expected usage patterns.
> The Block named "imapsystem" (implementation class 
> "org.apache.james.imapserver.
> IMAPSystem"), implements a service 
> "org.apache.james.imapserver.IMAPSystem" whic
> h extends a Lifecycle interface 
> "org.apache.avalon.framework.configuration.Confi
> gurable". This violates the expected usage patterns.
> James 2.1a1-cvs
> Started IMAP Server plain:143
> Started SMTP Server plain:25
>
> I am using only SMTP and IMAP protocol (of which I'm currently 
> evaluating). I have removed and replaced all instances of Block in 
> IMAP to Component type.
>
> There is no problem with James mail server at all, it's just 
> curiosity. I suspect these are warning messages and wanted to find out 
> their meaning.
>
> Can someone also explain to me the current differences between 2.03a 
> and 2.1a1?
>
> Look forward to your comments and valuable feedback.
>
> Thanks in advance,
>
> Sam.
>
>
> _
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
>
> -- 
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
>
>
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: spurious messages!?!

[Paul Hammant]

Samuel,

The latest code from CVS has no such spurious messages.  Your CVS update 
must be incomplete

I am not sure what configuration you are running.

- Paul

> Hi all,
>
> I have upgraded my release of James 2.03a to the latest version held 
> in the CVS repository using the latest version of Phoenix jar files. 
> I'm using IMAP server and have removed all instances of Block class 
> referenced in the IMAP srcs and replaced these with Component type. I 
> re-compiled the classes using latest libs in CVS and ran James 2.1a1 
> against and got some spurious messages output to my terminal screen:
>
> Using PHOENIX_HOME:   F:\James
> Using PHOENIX_TMPDIR: F:\James\temp
> Using JAVA_HOME:  E:\bea\jdk131
>
> Phoenix 4.0a4
>
> The Block named "imapsystem" (implementation class 
> "org.apache.james.imapserver.
> IMAPSystem"), implements a service 
> "org.apache.james.imapserver.IMAPSystem" whic
> h extends a Lifecycle interface 
> "org.apache.avalon.framework.context.Contextuali
> zable". This violates the expected usage patterns.
> The Block named "imapsystem" (implementation class 
> "org.apache.james.imapserver.
> IMAPSystem"), implements a service 
> "org.apache.james.imapserver.IMAPSystem" whic
> h extends a Lifecycle interface 
> "org.apache.avalon.framework.component.Composabl
> e". This violates the expected usage patterns.
> The Block named "imapsystem" (implementation class 
> "org.apache.james.imapserver.
> IMAPSystem"), implements a service 
> "org.apache.james.imapserver.IMAPSystem" whic
> h extends a Lifecycle interface 
> "org.apache.avalon.framework.configuration.Confi
> gurable". This violates the expected usage patterns.
> James 2.1a1-cvs
> Started IMAP Server plain:143
> Started SMTP Server plain:25
>
> I am only only interested in using SMTP and IMAP protocols suite and 
> have observed the warning messages above. I do not understand what 
> these mean and would appreciate it if someone can shed some light into 
> this. Also, on the same wavelength, what are the current differences 
> of 2.03a and 2.1a1?
>
> I look forward to any feedback.
>
> Thanks in advance.
>
> Sam.
>
>
> _
> Get your FREE download of MSN Explorer at 
> http://explorer.msn.com/intl.asp.
>
>
> -- 
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
>
>
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat + James in a single jvm process

[Paul Hammant]

Michael,

We're trying to make Phoenix an industrial strength app.  Think 
WebLogic.  Love it or hate it, it is big.
We'd certainly suggest that an 'assembler' could choose one or two VMs 
for such a configuration.

- Paul

>Mohan,
>
>While it is true that starting and running a single JVM instance is less
>expensive (mostly in terms of memory)
>than starting and running two or more JVMs on the same processor/box,
>there are several good reasons for
>keeping Tomcat and James running in separate JVMs. Trying to avoid the
>"overhead" of two JVMs really
>doesn't gain you anything significant. What is more critical is the work
>done inside the two threads (James,Tomcat).
>
>Heap size is a concern. JVMs have a limit on the amount of memory they use
>by default. You can run the JVM with a -server
>option, which AFAIK increases that limit. However, depending on your load,
>having both Tomcat and James in the same JVM may cause you to run
>into a shortage of resources within the JVM, even though you may have
>saved on memory outside the JVM.
>
>Second, you are putting all your eggs in one basket (sorry for the idiom).
>Putting both Tomcat and James in the same JVM
>is not a fault-tolerant solution. If the JVM crashes, you lose both your
>servers. If your clients have a two processor machine,
>or two boxes, keeping them separate will provide you and them with a more
>scaleable solution.
>
>Third, it should be relatively simple for you to write a custom
>start/build script that runs both Tomcat and James. In this way, it
>still "looks" like you are starting a single process, but inside the
>script you start 2 JVMs (or call the Tomcat startup script and the James
>startup script). That approach is much easier than trying to tie the two
>binaries together or compile a custom version.
>
>If you are looking for tutorials for Tomcat, the documentation within the
>Tomcat distributions and on the tomcat website is
>very good. http://jakarta.apache.org/tomcat/  The default configuration
>for the Tomcat distribution runs with minimal changes.
>Of course, what JSP/webapps you put in from there is another story ;) The
>tomcat-users mailing list should be fairly helpful along with the docs.
>I hope this has been helpful.
>
>Cheers,
>Michael
>
>
>- Original Message -
>From: "mohan narayanaswamy" <[EMAIL PROTECTED]>
>To: "James Developers List" <[EMAIL PROTECTED]>
>Sent: Tuesday, June 04, 2002 7:02 AM
>Subject: RE: Tomcat + James in a single jvm process
>
>
>  
>
>>single JVM process will reduce the overload.
>>u will be required less cpu,memory and moreover
>>efficient when compared to two process server.
>>
>>
>>
>
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>
>  
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat + James in a single jvm process

[Paul Hammant]

Mohan,

>hi everybody,
> is here anybody know how to configure tomcat+james to
>run in a single process. suggestions are all welcome.
>  
>
A tomcat 'block' is being worked on, so yes it will shortly.

An 'assembler' will be able to make a custom package of JAMES and Tomcat 
(Catalina).  In the fullness of time, we'll be able to allow servlets 
ditrect access to the service interfaces of JAMES.  Subject to suitable 
configuration of course.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet API v2

[Paul Hammant]

Danny,

>As far as mailet API dependancies on james utility classes, that just
>requires a simple re-factoring to deprecate the classes in o.a.james in
>favour of identical classes in o.a.mailet.
>
>I know that there is work involved in this, and I do still believe that it
>is worth embarking on it.
>
You'd be better splitting those maillet visible james classes into 
interfaces in the aillet API and keeping the impl in the james codebase. 
This way the maillet-api.jar is a lean as possible.  Interface/impl 
separation is good thing : 
 http://jakarta.apache.org/avalon/framework/guide-patterns-soii.html. 
 It is possible f course that I've caught the 'wrong end of the stick' 
and this is already the case...

- Paul



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet API v2

[Paul Hammant]

Noel,

>Wait a minute ... are we talking about the same thing?  I agree that there
>needs be a Mailet API that is a real, first class, Java API for
>Matchers/Mailets to interact with the container environment.  
>
+1

>I am
>disagreeing with the proposals that use AJP or other protocol to effectively
>run matchers/mailets in RMI servers separate from the container.  I am
>disagreeing with an archtecture organized around distributing the server
>across its internal architecture, as opposed to distributing process at the
>message level, using the RFC-defined protocols.
>
Well I am not against remote capaility.  I'm not a JAMES user, I'm just 
Avaloner interloper looking for a block-centric Java world.  I'm here to 
advocate solutions from the Avalon family.

>I thought that you were advocating the use of AltRMI or SOAP.  I didn't
>realize that you were raising those spectres purely to suggest that the
>issue of distribution be ignored, and the actual API be the focus.
>
I am for the use of such tools to publish _arbitary_ Java interfaces if 
you need to publish them.

  http://www.themindelectric.com/glue/index.html
  http://jakarta.apache.org/avalon/excalibur/altrmi/

I am avocating them *over* RMI or AJP11/12/13 or similar which are tied 
to a particular transport. and cost the API developer much angst.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet API v2

[Paul Hammant]

Noel,

>>You missing a central point of what I propose - have a first class API
>>
>>
>
>Define a message delivery API, do it in SOAP, make it language neutral, and
>submit it as an RFC.  THEN you'll have something.  A SOAP interface to
>replace SMTP and other message delivery protocols makes sense, but the model
>should not be tightly tied to any language or implementation.  My objection
>is to an ad hoc protocol entwined with a particular architecture, rather
>than abstract concepts of message delivery.
>
SOAP is not first class. I am not proposing it.  I am proposing a Java API.

>>constructing something around SMTP, then forgetting easier
>>(from the programmers point of view) ways of poking it.
>>
>>
>
>I've never thought of SMTP as a difficult protocol.  But then again, I've
>been known to send e-mail via telnet.  SMTP can have a perfectly simple
>object interface: set content, set recipients, send the message.  It is not
>an interactive interface, but that's not its purpose.
>  
>
It is more difficult than Java.  If it is great why do we not have a 
Hashmap interoperated with via SMTP (for example).

>>What we are talking about here is direct to JAMES/maillets API, yes?
>>
>>
>
>That became clear later, and I maintain that THAT is a bad idea.  Having to
>take into account that any given matcher or mailet could be remote (and
>perforce unreliable) is going to really complicate spool processing, and I
>honestly see no point to it when I can send the message via SMTP or LMTP
>from one mail server to another, just as we do with almost every other mail
>server on the planet.
>
All of them, any of them, some of them Some front end API that 
firewalled them all.  It is not such a bad idea.

>>For you information, there are loads of people using AltRMI and SOAP for
>>
>>
>RPC.
>
>I am well aware of SOAP and other RMI mechanisms (I'm one of those sick
>people who browses http://www.xmethods.net to see what's new).  As I said,
>I'm in favor of a SOAP interface that is based upon the problem domain, not
>the solution domain.
>
I am not propsing a SOAP or AltRMI or SMTP API.  I am proposing a Java 
one.  Then and only then thing of secondary adapters that present it to 
the outside world.  Add in additional concepts like TLS, AAA and you're 
got multiple faces to the same JAMES concept - a specially designed API.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet API v2

[Paul Hammant]

Noel,

>>Nothing, but it is hardly a Java friendly API.
>>
>>
>
>How so?  Create a mail message, add recipients, subject, content, send to
>server.   Easy as pie.  Even without javax.mail (a bit over engineered),
>there are ez-mail classes (or wrappers).  I've been using the same simple
>MailBean for years with servlets and JSP pages.
>  
>
hello("Is this a Java firendly API"); ?
SMTP, whether with helper libs or not, is not a first class Java API. 
 It is a plain-text using protocol that is ubiquitous and has multiple 
implementations.

You missing a central point of what I propose - have a first class API 
in Java, and have a number of ways of poking it (including SMTP).  What 
I think is inferior is constructing something around SMTP, then 
forgetting easier (from the programmers point of view) ways of poking it.

>>Besides, stategic use of AltRMI or Glue will allow publishing
>>of arbiary Java interfaces.  There are a dozen places in JAMES
>>code where a niche publication could occur... at no cost of
>>developing the remote API.
>>
>>
>
>I am firmly against protocol proliferation when it is unnecessary.  If/when
>there is a change from SMTP/IMAP/POP/NNTP to some XML messaging protocol(s),
>there would need to be RFCs with the same kind of scope as the current
>protocols.  Not ad hoc SOAP or RMI interfaces.
>
Who said change?  JAMES is a mail server, it must speak RFC specified 
protocols.  Whet we are talking about here is direct to JAMES/maillets 
API, yes?

For you information, there are loads of people using AltRMI and SOAP for 
RPC.  They have not felt the need to get an RFC around their API.  You 
folks don't have to either. Whether you talk of a new JSR or not (I am 
on the committee of JSR 111).  You can make a defacto standard you know. 
 It is not wrong to do so as you are the only mail server of consequence 
in the Java world.

- Paul



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet API v2

[Paul Hammant]

Danny,

>>Either way, you could have you external app do 1 thing or a hundred
>>things, so long as they ultimately tell you how they modified the
>>MimeMessage and any adjustments made to the recipient list.
>>
>>
>
>Absolutely, thats exactly what I had in mind, an AJP mailet.
>.. But also a receptor that would create a MIME message and insert it into
>the spool, although it would probably make more sense to expose a spool
>entry point via RMI and provide a utility method that would create simple
>pre-defined MIME messages from strings, like
>  
>
There is no need to use anything as cumersome as RMI.  We (in 
Avalon-Excalibur) have developer AltRMI which allow publishing via 
normal interfaces (no extends remote, no throws RemoteException, no 
extends UnicastRemoteObject).  There is also as SOAP publisher (that 
uses Glue) if you want to interoperate with other languages...

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Phoenix + Cornerstone upgraded....

[Paul Hammant]

Folks,

I've ..
* upgraded Phoenix inside James to latest
* upgraded Cornerstone to latest
* eliminated use of marker interface Block

I've not ..
* changed use of Composable to Serviceable
- it could be partially done, before maillet V2.0 is decided.

Giacomo has responded to my query on his use of AbstractService :

"We have no problem moving from Composable to Servicable. We don't use
AbstractService (out approach is to extend AbstractLogEnabled).

So, from my side you'll have a go to change over to Serviceable.

Thanks for contacting me as I wasn't able to follow the lists recently
as well as in the next couple of weeks seriously because of huge
workload."

We have green light for go, but we have to decide if we can make a 
backward-incompatile to maillet 1.0.  We could do it (bump to maillet 
1.1) but we'd have to know if the entire JAMES community could adapt the 
change.  This is not as hard work as it would be to change the, say, 
servlet spec.  Until it has been discussed I'm reluctant to do it.

- Paul





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet API v2

[Paul Hammant]

Noel,

>>AltRMI (transport package of Cornerstone), SOAP (Glue)   :-)))
>>
>>
>
>What is wrong with instantiating an SMTP or IMAP client if I want to send
>mail?
>  
>
Nothing, but it is hardly a Java friendly API.  Besides, stategic use of 
AltRMI or Glue will allow publishing of arbiary Java interfaces.  There 
are a dozen places in JAMES code where a niche publication could 
occur... at no cost of developing the remote API.

-ph


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet API v2

[Paul Hammant]

Danny,

>If you want to have extensive mail functionality available to your
>application, but *not* on the same box(es) use James.
>  
>
AltRMI (transport package of Cornerstone), SOAP (Glue)   :-)))

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet API v2

[Paul Hammant]

  Danny,

>Ok anything then, I stuck on ajp because my use cases are wholly concerned
>with integrating tomcat webapps with james and vv.
>
A quick clarification question if I may, bespoke sevlet in WAR needs to 
interoperate with James maillets/core ?  Or arbiatry maillets (or mail 
posting facade) need to be re-published as a home grown XML web-services 
API ? ( I need context to understand ).

>The point is that i think there needs to be *some* protocol that will allow
>james to be used in an integrated way with other applications using
>configuration only, so that it can become a mail gateway without the need to
>write special mailets for each special case.
>
I Agree.  

Humour me for a second - Is the API in MailServer.java a good one, if it 
were available for external use?  Yes I think it is.  It provides a 
conceptual entry point for internally generated mails yet-to-be subject 
to mailet processing.

Second question - Is a hypotehical maillet API (the one now or a proposd 
V2 one) a good thing for external use?  Yes, I guess it is again.  

The point is that you could publish those over a number of transport 
schemes to remote applications.  These could be Java or non-Java 
depending on the publication blocks/tools available today.

>I dont suggest that this be in the mailet API, although I did mention it in
>the same mail (because I believe that its part of the same endgame of making
>james more attractive to architects/developers), just that james embraces
>the concept of running as a tool for other applications.
>
As per promise of Phoenix, of via various tranports the promise for 
outside-th-phoenix-vm apps.

>And a server daemon which processes richer requests than SMTP or POP seems
>to me to be a requirement.
>  
>
Agree.  Conjour up your purest API ( and leave publication to other 
blocks )  is my recommendation.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Serviceable to Composable changeover

[Paul Hammant]

Danny,

>>Err, actually I am advocating closer binding with Avalon-Framework
>>interfaces.
>>
>>
>
>I'd rather see the mailet API developed completely independant of any
>dependancies at all, apart from Java Mail.
>It would then be up to James' implementation to conform to avalon design
>imperatives, and benefit accordingly.
>  
>
Yes, a maillet may impl all, any or none of the Avalon-Framework 
methods.  James (the container) recognises that is it instantiates 
maillets and decorates them accorting to lifecycle concepts.  What I'm 
anxious for you folks to avoid is the duplication of things illustrated 
by Avalon-Framework.

>I'd like to see mailet being used by people and products with no connection
>to James at all, and no reason for them to even know about James.
>  
>
Multiple implementation of maillet aware container.  Agree.

- Paul


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mailet API v2

[Paul Hammant]

Danny,

>>>I also wondered if we should support ajp13
>>>  
>>>
>>Do we really need Yet Another Transport Protocol?
>>
>>
>
>The idea of using ajp for this is that it exists already and allows non-java
>applications to make or respond to these requests, and recieve the
>responses.
>It allows the mail server and the content server to be remote from one
>another, and avoids the limitations of the mail protocols, which dont
>provide very sophisticated requests and responses.
>  
>
I'm against ajp for JAMES (for what it is worth).

Purist reason :  Do not tie an API to a particular transport

Explanation : We're rolling out JMS blocks for general phoenix app use. 
 We're already rolled out a block that uses Graham Glass's truly 
excellent Glue product to publish arbiatary interfaces to remote SOAP 
enabled langauges and systems.  We're rolled out the transport package 
in Cornerstone to similarly publish arbitary interfaces using AltRMI 
(you guys have still not checked this out).  When the Axis team have a 
product that is as simple to use as Glue, we'll have a block for that. 
 If Netscape make available a Java API for the truly-visionary XPCOM. 
we'll write a block for that.  Same story for .Net (assuming we can 
masquerade as the proprietary TCP based transport).  

If we could make a general ajp13 adapter for arbitarty interfaces, then 
perhaps it would be a good thing.  Asa general transport rather than a 
tightly-coupled solution for Maillets, that is.

Regards,

- Paul



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Serviceable to Composable changeover

[Paul Hammant]

Serge,

> As for the servlet-design thoughts, I think one of the biggest 
> mistakes of the original servlet designers was believing they could 
> design an API that could be used by multiple protocols.  I started 
> using the first preview of this spec 5 years ago, and 5 years later, 
> the servlet API still hasn't found a second protocol that it can 
> handle.  Anyway, my point is I think newslets would be a great idea, 
> but trying to make mailets able to handle both isn't really feasible. 

Agree.

> I think the directions of Paul's email only underscore my point.  I 
> think the mailet API could stand to use some additions, like providing 
> what this mail server's local users and hostnames are, and otherwise 
> remove dependencies to Avalon that we have in core mailets and 
> matchers.  These kinds of additions to the API would tie mailets to an 
> SMTP processing environment. 

Err, actually I am advocating closer binding with Avalon-Framework 
interfaces.  It is what I have done for hot-installable Enterprise 
Object Broker (EOB) jars.  LogEnabled, Initializable, Startable, 
Contextualizable, Configurable all have direct relevence to EOB-beans, 
blocks, maillets and newslets.  The difference for each is exhibited in 
Contextualizable.  Blocks are passes a Conext and cast them to 
BlockContext, EOB-beans take a Context and cast them to BeanContext.   I 
see that working very well.

To supplement the Avalon-framework interfaces, I tagree that you of 
course need mail-request/reply and news-request/reply interfaces for 
strongly contracted mail/news event behaviour.

> I kind of like the mail concept of ".war"... I'd suggest we call it 
> "mar" (mail application archive), but with Avalon we've already got 
> sar and bar, and do we really need another ?ar filetype. :) 

.mar would be good, but we learned a lesson with .bar in that .jar is 
more accptable to developers as a concept.  For EOB we have .jars with 
EOB-INF/ manifests.  We also have a .eob file that contains individual 
eob-bean .jar files as well as a real .war if applicable (remember this 
is a clean replacement for .ear files).

I'd suggest that individual maillets and newslets are in jar files and 
you reserver your specially named zip for an application level concept.

There should be lots of borrowable code and concepts in EOB's Apache 
licensed code.

> Anyway, and to your final points... isn't the mailet API already 
> separated from James code?  It's compiled to separate JARs.  The two 
> (minor) changes I have on tap for the next version of the mailet API 
> are adding attributes to Mail objects, and log-levels to the logging. 
> Renaming matchers to interceptors certainly makes it sound more 
> comp-sci like, and that might help people used to looking at APIs 
> understand what we're doing.  Like I said above, we could stand to add 
> other key concepts to the mailet context to support notions in SMTP 
> processing.
>
> I know there's been yet another discussion of tying matchers to 
> mailets, but I still don't like the results.  First, most approaches 
> tie us more to Avalon, which I'm against.  Second, most approaches 
> also tie a single matcher to a single mailet.  Granted we've been 
> unable to provide anything beyond this, I'm reluctant to have the API 
> enforce this relationship because I think there are alternate ways to 
> accomplish the integration betwen mailets and matchers without this tie. 

I think if you move the APIs (multiple) for maillets etc further from 
Avalon-Framework ('Avalon' a a wingle work has no context other than for 
a project), then you will regret the thousands of possibilities.

Imagine an abstract class that implements Avalon-Framework interfaces. 
 It is extended into a final Maillet that additionally implements 
pertinent mailet APIs - e.g. ForwardingMaillet.  Imagine also that 
abstract class being extended into say a n EOB-bean for some modicum of 
shared functionality.  Not for EOB? Wel then, how about for FtpLet.  Not 
convinced there is any shared functionality?  Well how about shared 
understandability.  A coder for JAMES maillets can quickly arrive 
writing FtpLets without earning complete new APIs.

> There are my 2 cents for the night, sparked by drinking too much 
> Mountain Dew during the NBA game.

Not a fan of the Football world cup heh?  Currently drawing a couple of 
billion viewers?

- Paul



--
To unsubscribe, e-mail:   
For additional commands, e-mail: