Mailing-List: contact server-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "James Developers List" <server-dev@james.apache.org>
From: "Noel J. Bergman" <noel@devtech.com>
To: "James Developers List" <server-dev@james.apache.org>
Subject: RE: Merge progress? (was RE: New matcher to MAIN or 2.1 branch?)
Date: Sun, 8 Feb 2004 20:12:32 -0500
Message-ID: <NBBBJGEAGJAKLIDBKJOPAEBNHDAB.noel@devtech.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <HKEFKPNPJLANNFPFMDKJIEAHKOAA.danny@apache.org>

> > I will post notes on the Mailet API in a bit, and see where we're all
at.

> Good point, one thing I want to do is get JNDI in there for resource
> location & service binding via mailets

There are also lots of ideas for JNDI and James in the archives from
discussions last year.

Coincidentally, I posted a brief note on that topic last night to the
directory-dev list:


http://nagoya.apache.org/eyebrowse/ReadMsg?listName=directory-dev@incubator.
apache.org&msgNo=639

asking who would like to help out.  Phil Steitz is interested in helping us.

> I want to know know how J2EE app servers maintain web-app context
> seperation and "local refrences" to the "real" bound objects

Current versions of Tomcat use the classloader to seperate JNDI contexts.
In our case, since (unlike J2EE) we do not permit chaining, we could use a
thread local, which the Processor could set before calling a matcher or
mailet.

> At the risk of pre-empting your mailet API debate I reckon we could
> abandon some or all of the experimental service access methods in
> the mailet context in favour of a JNDI future.

Absolutely.  Those weren't the changes I was concerned about.  The ones I
was looking at were the ones related to moving the

  RFC2980DateFormat.java
  RFC822DateFormat.java
  RFC977DateFormat.java
  SimplifiedDateFormat.java
  SynchronizedDateFormat.java

classes from o.a.j.util to o.a.m.dates, methods like:

    String getName();
    void setName(String name);
    void setLastUpdated(Date date);
    Date getLastUpdated();

in o.a.m.Mail, etc.

I have left them in for the moment, with an @since that indicates they are
part of an unstable API.

My thought with respect to lastUpdated is that it is specific to spooling,
and is only of use for a mailet like RemoteDelivery which has its own
internal queue.  I suggest that we could refactor RemoteDelivery into a
generic base class and a specialized subclass.  A grep of the codebase shows
that the only mailet calls to those methods are in RemoteDelivery (and a
debug output in AbstractRedirect).

I can more easily see a requirement that a mailet container assign a locally
unique ID, but I would think it should be a read-only property.  The
exception in the current code is in RemoteDelivery, where instead of cloning
a mail instance, we keep changing it as we writing it into the queue.

And then we have the question of where to put the Date classes.

That appears to be it, other than the mail repository changes (which I think
we are agreed to postone so that we can do it via JNDI), and the SMTP host
lookup changes in branch_2_1_fcs, for which I have a modification I'd like
to suggest for the merged code.

So ...

  - last updated property
  - name property
  - o.a.m.dates

Any thoughts on those, or anything else I might have overlooked?

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org