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 Andrei Ivanov <my...@surfeu.fi> on 2002/07/28 23:14:55 UTC
Handlers' streams RE: [Bug 11235]
Ok, then there will be
1. new AbstractServer
2. modified SMTPServer
3. modified SMTPHandler
4. modified MimeMessageInputStreamSource
5. modified SmsImpl (only one new constructor)
There will be no changes in configs so that no compatibility hazards. Hope
it will not be so little slow to apply these changes.
How does this sound now?
Heh, I would like to add to this logging levels for mailets, but this is
totally another story ;-). I am just recalling broken lances over mailet
logging :-( ...to no avail.
Andrei
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Sunday, July 28, 2002 11:51 PM
Subject: RE: [Bug 11235] Extensive use of string concatenation throughout
code base
>
>
> > I can
> > provide fixed SMTPHandler (since I ve been working a lot with this part
of
> > James for my project) so that other handlers can be fixed as well
similar
> > way. How does this sound?
>
> Andrei,
> We're *always* happy to accept contributions.
> If a little slow, at times, to apply them.
>
> d.
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE:
[Bug 11235]
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Stephen,
>
>What are the relationships between Merlin, Fortress and Phoenix?
>
In the beginning there was ECM (Excalibur Component Manager) and
Phoenix. ECM was basically a component manager implementation running
on steroids. It came about as a result of the needs of the Cocoon
community for dynamic service activation. Phoenix went in a different
direction, focussing much more of well structured service management
(dependency control, etc). About twleve months ago Fortress emerged -
the next generation of the Cocoon style dynamic service management but
formally structured as a container. About the same time, Merlin 1.0
arrived on the scene - basically a compoent runner along the lines of
Phoneix (xinfo based management and so on - but with auto assembly
abilities). Three months ago some work was initiated on a common
meta-model for all of these containers in a package called Containerkit.
That got forked as part of the work relating to Merlin 2.0 - a next
generation service management platform. Merlin 2.0 is progressivly
incorporating Fortress features concerning lifecycle and lifestlke
management and Fortress is adopting the Merlin 2.0 meta-model.
>Are they all containers for Avalon Frameworks components?
>
Yes - but with variations.
* Fortress supports different component lifestyles (threadsafe,
per-thread, pooled, etc.) but weak in respect to dependency
management and formal meta-model.
* Phoenix provides a reasonably complete app-server framework
for a linear service management model.
* Merlin provides a container hierachy, automated assembly,
dynamic component installation, automated context management,
package deployment profiles, and more.
>Cornerstone and Excalibre classes work with any of them?
>
Merlin will provide support for Phoenix blocks reasonably soon. The DTD
for Merlin xinfo files is very similar to a block info (but more stuff
concerning lifecycle extensions, and extension depedencies). In the
near future Merlin will automatically build a meta-model from a Phoenix
block defintion. Things like BlockListeners may be provided as
lifecycle extensions. As Fortress moves forward with implemetation
above the Merlin meta-model it will aquire the ability to run blocks as
well.
Merlin 2.0 lives in the following CVS:
akarta-avalon-excalibur/assembly
>Feel free to post a link to an FAQ.
>
Merlin Home Page
----------------
http://home.osm.net/doc/merlin
Merlin FAQ
----------
http://home.osm.net/doc/merlin/faq.html
Cheers, Steve.
>
>
> --- Noel
>
>-----Original Message-----
>From: Stephen McConnell [mailto:mcconnell@apache.org]
>Sent: Tuesday, August 13, 2002 23:24
>To: James Developers List
>Subject: Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams
>RE: [Bug 11235]
>
>Andrei Ivanov wrote:
>
>
>>2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
>>rules!!!)
>>
>>
>
>You may want to hold off on this for a little while. Currently over in
>Avalon land there is work going on concerning a standard "meta model"
>that will be described using an xinfo resource that has the potential to
>enable component deployment across a number of different containers.
> Currently James uses Phoenix as its container and describes component
>meta-info in a blockinfo descriptor. It is expected that Phoenix will
>be enhanced to support a more standard meta info DTD in the near future.
> In the meantime there is work on-going with two other containers -
>Fortress and Merlin. The authors of these containers are working
>together to ensure the establishment of a meta-model that completely
>addresses not only the defintions of component services and depenedecies
>along the lines of the blockinfo model, but addition contextn such as
>lifecycle extensions, lifestyle management, and so on. When this all
>settles down I expect we will see support in Phoenix for the
>Fortress/Merlin meta-model and support for blockinfo declarations inside
>Merlin.
>
>Cheers, Steve.
>
>--
>
>Stephen J. McConnell
>
>OSM SARL
>digital products for a global economy
>mailto:mcconnell@osm.net
>http://www.osm.net
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE: [Bug 11235]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen,
What are the relationships between Merlin, Fortress and Phoenix? Are they
all containers for Avalon Frameworks components? Cornerstone and Excalibre
classes work with any of them?
Feel free to post a link to an FAQ.
--- Noel
-----Original Message-----
From: Stephen McConnell [mailto:mcconnell@apache.org]
Sent: Tuesday, August 13, 2002 23:24
To: James Developers List
Subject: Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams
RE: [Bug 11235]
Andrei Ivanov wrote:
>2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
>rules!!!)
>
You may want to hold off on this for a little while. Currently over in
Avalon land there is work going on concerning a standard "meta model"
that will be described using an xinfo resource that has the potential to
enable component deployment across a number of different containers.
Currently James uses Phoenix as its container and describes component
meta-info in a blockinfo descriptor. It is expected that Phoenix will
be enhanced to support a more standard meta info DTD in the near future.
In the meantime there is work on-going with two other containers -
Fortress and Merlin. The authors of these containers are working
together to ensure the establishment of a meta-model that completely
addresses not only the defintions of component services and depenedecies
along the lines of the blockinfo model, but addition contextn such as
lifecycle extensions, lifestyle management, and so on. When this all
settles down I expect we will see support in Phoenix for the
Fortress/Merlin meta-model and support for blockinfo declarations inside
Merlin.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE:
[Bug 11235]
Posted by Stephen McConnell <mc...@apache.org>.
Andrei Ivanov wrote:
>2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
>rules!!!)
>
You may want to hold off on this for a little while. Currently over in
Avalon land there is work going on concerning a standard "meta model"
that will be described using an xinfo resource that has the potential to
enable component deployment across a number of different containers.
Currently James uses Phoenix as its container and describes component
meta-info in a blockinfo descriptor. It is expected that Phoenix will
be enhanced to support a more standard meta info DTD in the near future.
In the meantime there is work on-going with two other containers -
Fortress and Merlin. The authors of these containers are working
together to ensure the establishment of a meta-model that completely
addresses not only the defintions of component services and depenedecies
along the lines of the blockinfo model, but addition contextn such as
lifecycle extensions, lifestyle management, and so on. When this all
settles down I expect we will see support in Phoenix for the
Fortress/Merlin meta-model and support for blockinfo declarations inside
Merlin.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE:
[Bug 11235]
Posted by Paul Hammant <Pa...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE: [Bug 11235]
Posted by Andrei Ivanov <my...@surfeu.fi>.
WOW!
And next things I would like to do
1. securing the SMTP remote delivery. Now I have answers to Serges's
questions he asked me long ago. After this we will be able really to secure
everything in James and make it even more attractive for business!
2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
rules!!!)
Andrei
----- Original Message -----
From: "Peter M. Goldstein" <pe...@yahoo.com>
To: "'James Developers List'" <ja...@jakarta.apache.org>
Sent: Wednesday, August 14, 2002 1:09 AM
Subject: RE: Contribution: Re: Handlers' streams RE: [Bug 11235]
>
> All,
>
> I'm going to be taking these files, making some alterations to bring
> them into line with James code standards, and basically getting them in
> the standard form for submission. In addition to these modifications, I
> will be unifying all of the server/handlers under this connection
> paradigm. At that point I'll discuss with Andrei, and resubmit the
> modified code to the list for discussion. Hopefully we'll get that
> taken care of in a week or so, as I'd really like to see this code
> incorporated into the code base.
>
> --Peter
>
> > -----Original Message-----
> > From: Andrei Ivanov [mailto:myfam@surfeu.fi]
> > Sent: Tuesday, August 13, 2002 3:09 PM
> > To: James Developers List
> > Subject: Contribution: Re: Handlers' streams RE: [Bug 11235]
> >
> > Hi,
> > finally it's done (see attachment)
> >
> > Comments:
> >
> > Attached are only modified and new files for current James.
> > If you check out new james and copy src directory from zip over
> existing
> > src
> > dir and build james distribution it will run right away.
> > When you'll look at sources you'll see what I've done. It is not well
> > commented in the code though...
> >
> > There are two things you have to pay attention first of all
> >
> > 1. "connection" package structure doesn't correspond james structure
> where
> > interfaces defined in "services" and implementation is spread over
> other
> > packages (I've been always wandering why James originators hadn't
> adapted
> > cornerstone package structure from very beginning). So you may want to
> > modify connection package structure (move interfaces and
> implementations)
> >
> > 2. About SMTPHandler. I adapted only doAUTH(..) method from the latest
> > James
> > (you will see it because it is shifted right). I think that most of
> the
> > recent changes were done to this method so I copied it from current
> James
> > and modified it according to my changes. If other methods have changed
> > recently you'll have to add those modifications to new SMTPHandler
> (use
> > doAUTH(..) as an example).
> >
> >
> > Andrei
> >
> > ----- Original Message -----
> > From: "Andrei Ivanov" <my...@surfeu.fi>
> > To: "James Developers List" <ja...@jakarta.apache.org>
> > Sent: Monday, July 29, 2002 12:14 AM
> > Subject: Handlers' streams RE: [Bug 11235]
> >
> >
> > > Ok, then there will be
> > >
> > > 1. new AbstractServer
> > > 2. modified SMTPServer
> > > 3. modified SMTPHandler
> > > 4. modified MimeMessageInputStreamSource
> > > 5. modified SmsImpl (only one new constructor)
> > >
> > > There will be no changes in configs so that no compatibility
> hazards.
> > Hope
> > > it will not be so little slow to apply these changes.
> > >
> > > How does this sound now?
> > >
> > > Heh, I would like to add to this logging levels for mailets, but
> this is
> > > totally another story ;-). I am just recalling broken lances over
> > mailet
> > > logging :-( ...to no avail.
> > >
> > > Andrei
> > >
> > > ----- Original Message -----
> > > From: "Danny Angus" <da...@apache.org>
> > > To: "James Developers List" <ja...@jakarta.apache.org>
> > > Sent: Sunday, July 28, 2002 11:51 PM
> > > Subject: RE: [Bug 11235] Extensive use of string concatenation
> > throughout
> > > code base
> > >
> > >
> > > >
> > > >
> > > > > I can
> > > > > provide fixed SMTPHandler (since I ve been working a lot with
> this
> > part
> > > of
> > > > > James for my project) so that other handlers can be fixed as
> well
> > > similar
> > > > > way. How does this sound?
> > > >
> > > > Andrei,
> > > > We're *always* happy to accept contributions.
> > > > If a little slow, at times, to apply them.
> > > >
> > > > d.
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Contribution: Re: Handlers' streams RE: [Bug 11235]
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
I'm going to be taking these files, making some alterations to bring
them into line with James code standards, and basically getting them in
the standard form for submission. In addition to these modifications, I
will be unifying all of the server/handlers under this connection
paradigm. At that point I'll discuss with Andrei, and resubmit the
modified code to the list for discussion. Hopefully we'll get that
taken care of in a week or so, as I'd really like to see this code
incorporated into the code base.
--Peter
> -----Original Message-----
> From: Andrei Ivanov [mailto:myfam@surfeu.fi]
> Sent: Tuesday, August 13, 2002 3:09 PM
> To: James Developers List
> Subject: Contribution: Re: Handlers' streams RE: [Bug 11235]
>
> Hi,
> finally it's done (see attachment)
>
> Comments:
>
> Attached are only modified and new files for current James.
> If you check out new james and copy src directory from zip over
existing
> src
> dir and build james distribution it will run right away.
> When you'll look at sources you'll see what I've done. It is not well
> commented in the code though...
>
> There are two things you have to pay attention first of all
>
> 1. "connection" package structure doesn't correspond james structure
where
> interfaces defined in "services" and implementation is spread over
other
> packages (I've been always wandering why James originators hadn't
adapted
> cornerstone package structure from very beginning). So you may want to
> modify connection package structure (move interfaces and
implementations)
>
> 2. About SMTPHandler. I adapted only doAUTH(..) method from the latest
> James
> (you will see it because it is shifted right). I think that most of
the
> recent changes were done to this method so I copied it from current
James
> and modified it according to my changes. If other methods have changed
> recently you'll have to add those modifications to new SMTPHandler
(use
> doAUTH(..) as an example).
>
>
> Andrei
>
> ----- Original Message -----
> From: "Andrei Ivanov" <my...@surfeu.fi>
> To: "James Developers List" <ja...@jakarta.apache.org>
> Sent: Monday, July 29, 2002 12:14 AM
> Subject: Handlers' streams RE: [Bug 11235]
>
>
> > Ok, then there will be
> >
> > 1. new AbstractServer
> > 2. modified SMTPServer
> > 3. modified SMTPHandler
> > 4. modified MimeMessageInputStreamSource
> > 5. modified SmsImpl (only one new constructor)
> >
> > There will be no changes in configs so that no compatibility
hazards.
> Hope
> > it will not be so little slow to apply these changes.
> >
> > How does this sound now?
> >
> > Heh, I would like to add to this logging levels for mailets, but
this is
> > totally another story ;-). I am just recalling broken lances over
> mailet
> > logging :-( ...to no avail.
> >
> > Andrei
> >
> > ----- Original Message -----
> > From: "Danny Angus" <da...@apache.org>
> > To: "James Developers List" <ja...@jakarta.apache.org>
> > Sent: Sunday, July 28, 2002 11:51 PM
> > Subject: RE: [Bug 11235] Extensive use of string concatenation
> throughout
> > code base
> >
> >
> > >
> > >
> > > > I can
> > > > provide fixed SMTPHandler (since I ve been working a lot with
this
> part
> > of
> > > > James for my project) so that other handlers can be fixed as
well
> > similar
> > > > way. How does this sound?
> > >
> > > Andrei,
> > > We're *always* happy to accept contributions.
> > > If a little slow, at times, to apply them.
> > >
> > > d.
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Contribution: Re: Handlers' streams RE: [Bug 11235]
Posted by Andrei Ivanov <my...@surfeu.fi>.
Hi,
finally it's done (see attachment)
Comments:
Attached are only modified and new files for current James.
If you check out new james and copy src directory from zip over existing src
dir and build james distribution it will run right away.
When you'll look at sources you'll see what I've done. It is not well
commented in the code though...
There are two things you have to pay attention first of all
1. "connection" package structure doesn't correspond james structure where
interfaces defined in "services" and implementation is spread over other
packages (I've been always wandering why James originators hadn't adapted
cornerstone package structure from very beginning). So you may want to
modify connection package structure (move interfaces and implementations)
2. About SMTPHandler. I adapted only doAUTH(..) method from the latest James
(you will see it because it is shifted right). I think that most of the
recent changes were done to this method so I copied it from current James
and modified it according to my changes. If other methods have changed
recently you'll have to add those modifications to new SMTPHandler (use
doAUTH(..) as an example).
Andrei
----- Original Message -----
From: "Andrei Ivanov" <my...@surfeu.fi>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Monday, July 29, 2002 12:14 AM
Subject: Handlers' streams RE: [Bug 11235]
> Ok, then there will be
>
> 1. new AbstractServer
> 2. modified SMTPServer
> 3. modified SMTPHandler
> 4. modified MimeMessageInputStreamSource
> 5. modified SmsImpl (only one new constructor)
>
> There will be no changes in configs so that no compatibility hazards. Hope
> it will not be so little slow to apply these changes.
>
> How does this sound now?
>
> Heh, I would like to add to this logging levels for mailets, but this is
> totally another story ;-). I am just recalling broken lances over mailet
> logging :-( ...to no avail.
>
> Andrei
>
> ----- Original Message -----
> From: "Danny Angus" <da...@apache.org>
> To: "James Developers List" <ja...@jakarta.apache.org>
> Sent: Sunday, July 28, 2002 11:51 PM
> Subject: RE: [Bug 11235] Extensive use of string concatenation throughout
> code base
>
>
> >
> >
> > > I can
> > > provide fixed SMTPHandler (since I ve been working a lot with this
part
> of
> > > James for my project) so that other handlers can be fixed as well
> similar
> > > way. How does this sound?
> >
> > Andrei,
> > We're *always* happy to accept contributions.
> > If a little slow, at times, to apply them.
> >
> > d.
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
RE: Handlers' streams RE: [Bug 11235]
Posted by Danny Angus <da...@apache.org>.
I believe that this argument was settled with the commiters deciding not to
include logging in the API.
Of course you are entitled to produce your own extensions/frameowrks and
whatever you need to allow you to make useful mailet applications, but they
are not part of the API.
d.
> I will provide patches and difs for logging.
> When we can
> review this and put it to the scratch (or whatever cvs) branch.
> So ones who
> badly need fine grained logging in mailet (like me for example)
> will be able
> to take it and test it. This change doesn't break mailet API, it
> just extend
> it a little bit, so there should be NO compatibility risk. After testing
> (and time) this can go into main code. And when new mailet API will be
> developed this change can be adopted or dropped out but still this will be
> done when there is at least one implemented and tested approach.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Handlers' streams RE: [Bug 11235]
Posted by Andrei Ivanov <my...@surfeu.fi>.
Hi
> LOL Yeah, because no one could agree how to expose fine-grained logging
in
> the Mailet API. :-) One of these days, I'm sure it will be revisited.
Agree, let's do so: I will provide patches and difs for logging. When we can
review this and put it to the scratch (or whatever cvs) branch. So ones who
badly need fine grained logging in mailet (like me for example) will be able
to take it and test it. This change doesn't break mailet API, it just extend
it a little bit, so there should be NO compatibility risk. After testing
(and time) this can go into main code. And when new mailet API will be
developed this change can be adopted or dropped out but still this will be
done when there is at least one implemented and tested approach.
Andrei
>
> > Heh, I would like to add to this logging levels for mailets, but this is
> > totally another story ;-). I am just recalling broken lances over
mailet
> > logging :-( ...to no avail.
>
> LOL Yeah, because no one could agree how to expose fine-grained logging
in
> the Mailet API. :-) One of these days, I'm sure it will be revisited.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Handlers' streams RE: [Bug 11235]
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Heh, I would like to add to this logging levels for mailets, but this is
> totally another story ;-). I am just recalling broken lances over mailet
> logging :-( ...to no avail.
LOL Yeah, because no one could agree how to expose fine-grained logging in
the Mailet API. :-) One of these days, I'm sure it will be revisited.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Handlers' streams RE: [Bug 11235]
Posted by Danny Angus <da...@apache.org>.
> Heh, I would like to add to this logging levels for mailets, but this is
> totally another story ;-). I am just recalling broken lances over mailet
> logging :-( ...to no avail.
;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>