james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: [Mailet API] Logging Proposal
Date Wed, 12 Jun 2002 03:24:12 GMT
> The discussion is primariy comp sci pattern focused instead of usage
focused.

>From my end, I'm just trying to assure that Mailet authors will have common
and sufficiently rich interfaces to implement vendor-neutral Mailets.  I am
not interested in an academic exercise.  I look at each thing from the
perspective of "what do I need, as a developer."

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

> I think I'm missing the criticism of this approach.  The mailet API is
> allowing you access to container specific features.

I was not criticizing.  I was simply pointing out that this is how the
current Mailet API supported what you had asked me, namely what to do about
mailets that want something, e.g., a repository, that is not supported on a
specific container.  I then further noted that (since this mechanism uses
Avalon Frameworks), that Best Practices with the Avalon Frameworks
programming model would work a bit differently, and I gave an example.

> What you call future-proofing, I would call adding a bunch of imports
> and implements for no benefit to someone as a non-interface A user.

Not sure I follow that ... can you illustrate?  I do not believe that we are
saying the same thing at all.

> What logging capabilities does a mailing list need that log() doesn't
> support?  How many listsoft or ezmlm admins look at their log files?

I look at the log files, for one.  :-)  And we've had at least 6 voices
raised asking for better control that just log().

> The storage issue is much more difficult.  I honestly can't see how you
> standardize an API around tailored multiple applications.  Start with
> the user repositories... I can think of half a dozen very different ways
> that a mailing list might work.

>From what you described, I can't think of a problem representing any or all
of the scenarios (not quoted) in a JNDI style node.  More over, I think that
all of those items represented perfectly legitimate information that I
*WANT* to have available.  Perhaps one problem is that a User is represented
as Bean with properties, when it should probably be more of a property table
(method-per-property vs keyed-access).

> And to some extent, we've tried to create a standard user repository
> API... it doesn't quite work though.  The idea was to let a standard
> user repository API support POP3 logins, SMTP auth, mailing lists, and
> anything else.

See above for a suggestion on how the interface can be improved by opening
it up the range of storable attributes.  Sort of a JNDI-lite, instead of
having to deal with the complexity of JNDI (I've written JNDI code,
including on the SPI side).

> Ahem... JSR 47 HAS produced a common API for logging.  It's called
> java.util.logging.

True ... but it is neither in the Servlet API nor exposed to Mailets, which
was sort of the context of the discourse.

> Beware of the rotten tomatoes incoming from the Avalon developers.  :)

Fair enough. :-)  Apparently, though the Avalon Frameworks supports JSR 47.

> I guess I still don't see what you're suggesting that James +
> Avalon-framework doesn't already do.

Wait, I have not said that James + Avalon Frameworks doesn't do something!
I said that a Mailet API *WITHOUT* Avalon Frameworks is anemic, and that if
we don't specify how to fill the gaps (using the Avalon Frameworks is one
way), then those gaps will be filled with vendor-specific solutions, and
that is the thing that is unacceptable.


> You've got a mailet API... you've got composable, etc-able
> interfaces that you can get as servlet context attributes.
> You can log, you can store, and whatever else that the
> Avalon-framework is providing.

Exactly!  And I want to be able to RELY upon that regardless of whose
container implementation I'm using.  That's it exactly!

	--- Noel [off to get some sleep before ENG v NGA in a few hours]


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


Mime
View raw message