You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Danny Angus <da...@apache.org> on 2004/02/07 12:36:55 UTC
Merge progress? (was RE: New matcher to MAIN or 2.1 branch?)
Good q. Serge.
Noel..
I seem to recall you opting to "take point" on this, how is it going? do you need help? what is the estimated timescale?
I'm not harrasing you, but would like to know if we're going to get there soon, there's a lot of stuff I'm interested in doing (like IP based POP3 vhosting), and I may have a little time soon (!) but I'd much rather wait until we've sorted out the tags.
BTW on another matter I gather theres new support for svn & eclipse 3 available.
d.
> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com]
> Sent: 06 February 2004 20:29
> To: server-dev@james.apache.org
> Subject: New matcher to MAIN or 2.1 branch?
>
>
> I have a trivial matcher I was going to add to CVS, but wasn't sure how
> far along the merge is. Should I commit it to both 2.1 and MAIN, or
> just MAIN?
>
> --
> Serge Knystautas
> President
> Lokitech >> software . strategy . design >> http://www.lokitech.com
> p. 301.656.5501
> e. sergek@lokitech.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Merge progress? (was RE: New matcher to MAIN or 2.1 branch?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Would this be a good time to move the mailet API into it's own
> repository, or at least separate it in CVS more distinctly?
We might wait to do that when we move to SVN. Our build processes are
integrated still.
But I do agree that we should be really careful what goes into the Mailet
API, and keep it focused on what should be in a portable Mailet container,
not just James. Since Danny has probably given the most thought to those
issues, I hope that he'll aggressively police keeping the Mailet API clean.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Merge progress? (was RE: New matcher to MAIN or 2.1 branch?)
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> Once we get the Mailet API root dependency out of the way, everyone with
> time can help make the changes.
Would this be a good time to move the mailet API into it's own
repository, or at least separate it in CVS more distinctly? Heck, once
we work out any issues with it, stick it in SVN and just have
james-server work off of a jar. :)
--
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Merge progress? (was RE: New matcher to MAIN or 2.1 branch?)
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
> 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.
+1
--
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Merge progress? (was RE: New matcher to MAIN or 2.1 branch?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > 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
RE: Merge progress? (was RE: New matcher to MAIN or 2.1 branch?)
Posted by Danny Angus <da...@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, I want to know know how J2EE app servers maintain web-app context seperation and "local refrences" to the "real" bound objects first though.
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.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Merge progress? (was RE: New matcher to MAIN or 2.1 branch?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> how is it going?
I started by taking a cvs diff of the two branches. Most of it is rote for
the Avalon changes, which is relatively easy to handle. But in order to
know which code to adapt, the real issue is the Mailet API.
I will post notes on the Mailet API in a bit, and see where we're all at.
> do you need help?
Once we get the Mailet API root dependency out of the way, everyone with
time can help make the changes.
> what is the estimated timescale?
Soon as we decide on the Mailet API, I think it should go fairly quickly.
> I have some time to help with this, not that I want you to do it
> quickly just so I can get on.. :-)
:-) We all want to get this out of the way.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Merge progress? (was RE: New matcher to MAIN or 2.1 branch?)
Posted by Danny Angus <da...@apache.org>.
I mean I have some time to help with this, not that I want you to do it quickly just so I can get on.. :-)
d.
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: 07 February 2004 11:37
> To: James Developers List
> Subject: Merge progress? (was RE: New matcher to MAIN or 2.1 branch?)
>
>
>
> Good q. Serge.
> Noel..
> I seem to recall you opting to "take point" on this, how is it
> going? do you need help? what is the estimated timescale?
> I'm not harrasing you, but would like to know if we're going to
> get there soon, there's a lot of stuff I'm interested in doing
> (like IP based POP3 vhosting), and I may have a little time soon
> (!) but I'd much rather wait until we've sorted out the tags.
>
> BTW on another matter I gather theres new support for svn &
> eclipse 3 available.
>
> d.
>
>
> > -----Original Message-----
> > From: Serge Knystautas [mailto:sergek@lokitech.com]
> > Sent: 06 February 2004 20:29
> > To: server-dev@james.apache.org
> > Subject: New matcher to MAIN or 2.1 branch?
> >
> >
> > I have a trivial matcher I was going to add to CVS, but wasn't sure how
> > far along the merge is. Should I commit it to both 2.1 and MAIN, or
> > just MAIN?
> >
> > --
> > Serge Knystautas
> > President
> > Lokitech >> software . strategy . design >> http://www.lokitech.com
> > p. 301.656.5501
> > e. sergek@lokitech.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org