You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@avalon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/07/10 11:44:02 UTC

RE: cvs commit: jakarta-avalon-excalibur/xmlutil/src/java/org/apache/avalon/excalibur/xml/xslt XSLTProcessorImpl.java


> -----Original Message-----
> From: donaldp@apache.org [mailto:donaldp@apache.org]
> Sent: Wednesday, July 10, 2002 11:37 AM
> To: jakarta-avalon-excalibur-cvs@apache.org
> Subject: cvs commit:
> jakarta-avalon-excalibur/xmlutil/src/java/org/apache/avalon/excalibur/xm
> l/xslt XSLTProcessorImpl.java
> 
> 
> donaldp     2002/07/10 02:36:54
> 
>   Modified:    xmlutil/src/java/org/apache/avalon/excalibur/xml/xslt
>                         XSLTProcessorImpl.java
>   Log:
>   Aquire store during compose method but only use it if correct 
> flag is set
>   
Why do you want to aquire the store even if it is not used?

Carsten 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Optional Dependencies

Posted by Berin Loritsch <bl...@apache.org>.

> From: Peter Donald [mailto:peter@apache.org] 
> 
> On Wed, 10 Jul 2002 19:55, Carsten Ziegeler wrote:
> > Peter Donald wrote:
> > > > Why do you want to aquire the store even if it is not used?
> > >
> > > Basically to avoid warnings in a container I am working on. ie If 
> > > you declare dependencies (even if they are optional dependencies) 
> > > and the container provides you component but you dont use it then 
> > > the container will wanr you
> > > saying something like
> > >
> > > "You have misdeclared a dependency on X as it was never used."
> > >
> > > or similar.
> >
> > Hmmm, I'm not sure if this is a good feature - because an optional 
> > dependency means it's - well - optional. And I see two use cases
> > their:
> > a) The optional component is only used if it is available
> 
> thats the usecase I had in mind.

ServiceManager.hasService()

Is supposed to be the low cost way of providing the functionality.

> > b) The optional component is used only in some circumstances
> 
> That is the usecase that I originally liked but Berin jumped 
> on me back in ye 
> old days for it. Then we both jumped on Fede (one of the 
> original avalon 
> developers).

It may have been a misunderstanding or something like that.  We
all have grown as developers since then.

> Whats everyone else think. Should optional dependencies be "optional" 
> depending on the presence of some attribute (be it config variable or 
> something). 
> 
> Or should it be the assemblers decision, ie If they provide 
> the component then 
> it is used else it is not.

Any optional dependancy is just that, "optional".  As such, the
component should be able to handle the absence of that component.

In the case of the variable/flag/attribute dependency, you still
need to check if it is available.  If your configuration says
that you should use the store, check to see if your container has
it.  The component declared it as an optional dependancy, so if
it doesn't exist it doesn't exist.

In that case the "useStore" attribute is more a way to override the
default behavior.  We can prevent its use even if it exists, or we
can say it is ok to use when it does exist.

I could be wrong, but that is my understanding of it.

I think it would be more work than really necessary to make the
container aware of the content for the configuration information
for the component to determine if a component is optional or not.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Optional Dependencies

Posted by Peter Donald <pe...@apache.org>.

At 09:01 AM 7/10/2002 -0400, you wrote:
> > From: Peter Donald [mailto:peter@apache.org]
> >
> > It is unfortunate that ECMs lookup is costly. Does Fortresss
> > have this problem
> > aswell? Most containers I work with are little more than a hashlookup.
>
>
>Nope!
>
>Doing pure lookup invocations on ECM vs. Fortress under load from
>several
>threads has Fortress coming out ahead 15 to 1.

Kool!


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Optional Dependencies

Posted by Carsten Ziegeler <cz...@s-und-n.de>.

Peter Donald wrote:
>
> On Wed, 10 Jul 2002 20:30, Carsten Ziegeler wrote:
> > > It is unfortunate that ECMs lookup is costly. Does Fortresss have
> > > this problem
> > > aswell? Most containers I work with are little more than a hashlookup.
> >
> > Even if the lookup is not costly, what about non ThreadSafe components?
> > For example the XSLTProcessor is configured to not use the Store,
> > the Store would be Poolable (as the XSLTProcessor is) and the
> XSLTProcessor
> > looksup a Store in compose().
> > So each XSLTProcessor component would block a Store component, although
> > this would not be necessary.
>
> true. But XSLTProcessor would bugger up all those components now
> as I removed
> the release() ;)
>
> I looked at all the store implementations and they all were
> threadsafe and I
> applied the same logic as I did wrt the XMLizer/Parser. ie If all
> implementations are threadsafe then dont worry about releasing
> the component.
>
> If the component was poolable then what I did would not be good -
> it would
> suck actually ;)
>
Yupp :)

Ok, I totally agree with you that if I know that the component is
ThreadSafe, your solution is OK.
But I repeat my message from some weeks ago: the client should not
know anything about if the used component is thread safe or not.
But that's (only?) my opinion.

So, keeping it short: you won ;)

Carsten


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Optional Dependencies

Posted by Vadim Gritsenko <va...@verizon.net>.

> From: Peter Royal [mailto:proyal@apache.org]
> 
> On Wednesday 10 July 2002 09:51 am, Vadim Gritsenko wrote:
> > > Think of the design practicality.  If a store were poolable, you
have
> > > no guarantee of getting a hold of the store that has the object
you
> > > placed in it again.  You would be SOL.
> >
> > With the exception of SQL store, XML:DB store, filesystem store, FTP
> > store, etc.
> 
> Which could all be ThreadSafe easily :)

That's not the point. I can come up with non-threadsafe store easily
(say, JMS publisher is not thread safe by specification).

Point is either Store interface extends ThreadSafe or it is *clearly*
marked with *huge* letters that container *assumes* that all stores are
threadsafe.

Vadim

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Optional Dependencies

Posted by Peter Royal <pr...@apache.org>.

On Wednesday 10 July 2002 09:51 am, Vadim Gritsenko wrote:
> > Think of the design practicality.  If a store were poolable, you have
> > no guarantee of getting a hold of the store that has the object you
> > placed in it again.  You would be SOL.
>
> With the exception of SQL store, XML:DB store, filesystem store, FTP
> store, etc.

Which could all be ThreadSafe easily :)
-pete

-- 
peter royal -> proyal@apache.org

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Optional Dependencies

Posted by Vadim Gritsenko <va...@verizon.net>.



Vadim

--
Resistance is futile. 

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, July 10, 2002 10:01 AM
> To: 'Avalon Developers List'
> Subject: RE: Optional Dependencies
> 
> > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> >
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > >
> > > > From: Peter Donald [mailto:peter@apache.org]
> > > >
> > > > I looked at all the store implementations and they all were
> > > > threadsafe and I applied the same logic as I did wrt the
> > > > XMLizer/Parser. ie If all implementations are threadsafe
> > > > then dont
> > > > worry about releasing the component.
> > > >
> > > > If the component was poolable then what I did would not
> > > > be good - it
> > > > would suck actually ;)
> > >
> > >
> > > :)
> > >
> > > Think of the design practicality.  If a store were
> > > poolable, you have
> > > no guarantee of getting a hold of the store that has the object
you
> > > placed in it again.  You would be SOL.
> >
> > With the exception of SQL store, XML:DB store, filesystem store, FTP
> > store, etc.
> 
> I would hope that your goal is to write components that are either
> threadsafe, or can supply implementations that are threadsafe.

Ideally, yes, of course.


> Precluding
> that ability in the interface (like Cocoon's fatal flaw) really forces
> the container to eat up resources unnecessarily.
> 
> The Store interface has no guarantee of persistence, even more
> importantly
> there is no guarantee of immediate persistence.  If your object is
> eventually stored in a database, an intelligently designed store
object
> will hold on to it in memory until the load on a machine goes down.

It depends on concrete store implementation semantics. Memory store does
not has persistence, filesystem store got only persistence, mru is
combination, etc.


> Having multiple instances of a store object when the storage is
> persistent
> has the additional overhead of thread monitoring for the resources
> because
> they have to manage the independent calls on the external resource
> between
> several instances of the same component.  It's a whole lot easier to
> manage
> that in one instance because your synchronization mechanisms are
managed
> internally instead of externally.

It is easier, I do agree, perfect world will have only thread safe
components, PhD-s as designers, and people who know what is hexadecimal
numbers are as coders.

But all this is beside the point. My point is that this (decision
"stores are threadsafe") must be either enforced (by store interface
extending threadsafe) or *very* good documented, so no stupid (but
educated enough to RTFM) soul could implement Recyclable store.


Vadim



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Optional Dependencies

Posted by Berin Loritsch <bl...@apache.org>.

> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net] 
> 
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > 
> > > From: Peter Donald [mailto:peter@apache.org]
> > >
> > > I looked at all the store implementations and they all were 
> > > threadsafe and I applied the same logic as I did wrt the 
> > > XMLizer/Parser. ie If all implementations are threadsafe 
> then dont 
> > > worry about releasing the component.
> > >
> > > If the component was poolable then what I did would not 
> be good - it 
> > > would suck actually ;)
> > 
> > 
> > :)
> > 
> > Think of the design practicality.  If a store were 
> poolable, you have
> > no guarantee of getting a hold of the store that has the object you
> > placed in it again.  You would be SOL.
> 
> With the exception of SQL store, XML:DB store, filesystem store, FTP
> store, etc.

I would hope that your goal is to write components that are either
threadsafe, or can supply implementations that are threadsafe.
Precluding
that ability in the interface (like Cocoon's fatal flaw) really forces
the
container to eat up resources unnecessarily.

The Store interface has no guarantee of persistence, even more
importantly
there is no guarantee of immediate persistence.  If your object is
eventually stored in a database, an intelligently designed store object
will hold on to it in memory until the load on a machine goes down.

Having multiple instances of a store object when the storage is
persistent
has the additional overhead of thread monitoring for the resources
because
they have to manage the independent calls on the external resource
between
several instances of the same component.  It's a whole lot easier to
manage
that in one instance because your synchronization mechanisms are managed
internally instead of externally.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Optional Dependencies

Posted by Vadim Gritsenko <va...@verizon.net>.

> From: Berin Loritsch [mailto:bloritsch@apache.org]
> 
> > From: Peter Donald [mailto:peter@apache.org]
> >
> > I looked at all the store implementations and they all were
> > threadsafe and I
> > applied the same logic as I did wrt the XMLizer/Parser. ie If all
> > implementations are threadsafe then dont worry about
> > releasing the component.
> >
> > If the component was poolable then what I did would not be
> > good - it would
> > suck actually ;)
> 
> 
> :)
> 
> Think of the design practicality.  If a store were poolable, you have
> no guarantee of getting a hold of the store that has the object you
> placed in it again.  You would be SOL.

With the exception of SQL store, XML:DB store, filesystem store, FTP
store, etc.


Vadim


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Optional Dependencies

Posted by Berin Loritsch <bl...@apache.org>.

> From: Peter Donald [mailto:peter@apache.org] 
> 
> I looked at all the store implementations and they all were 
> threadsafe and I 
> applied the same logic as I did wrt the XMLizer/Parser. ie If all 
> implementations are threadsafe then dont worry about 
> releasing the component.
> 
> If the component was poolable then what I did would not be 
> good - it would 
> suck actually ;)


:)

Think of the design practicality.  If a store were poolable, you have
no guarantee of getting a hold of the store that has the object you
placed in it again.  You would be SOL.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Optional Dependencies

Posted by Vadim Gritsenko <va...@verizon.net>.

> From: Peter Donald [mailto:peter@apache.org]
> 
> On Wed, 10 Jul 2002 20:30, Carsten Ziegeler wrote:
> > > It is unfortunate that ECMs lookup is costly. Does Fortresss have
> > > this problem
> > > aswell? Most containers I work with are little more than a
hashlookup.
> >
> > Even if the lookup is not costly, what about non ThreadSafe
components?
> > For example the XSLTProcessor is configured to not use the Store,
> > the Store would be Poolable (as the XSLTProcessor is) and the
XSLTProcessor
> > looksup a Store in compose().
> > So each XSLTProcessor component would block a Store component,
although
> > this would not be necessary.
> 
> true. But XSLTProcessor would bugger up all those components now as I
removed
> the release() ;)
> 
> I looked at all the store implementations and they all were threadsafe
and I
> applied the same logic as I did wrt the XMLizer/Parser. ie If all
> implementations are threadsafe then dont worry about releasing the
component.

Does this mean that users of the Avalon framework are prohibited from
writing own (non-threadsafe) implementation of the Store component?

This must be clearly marked in the documentation, something like "for
internal use only, do not try to implement yourself".


Vadim


> If the component was poolable then what I did would not be good - it
would
> suck actually ;)
> 
> --
> Cheers,
> 
> Peter Donald
> *------------------------------------------------*
> | You can't wake a person who is pretending      |
> |       to be asleep. -Navajo Proverb.           |
> *------------------------------------------------*


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Optional Dependencies

Posted by Peter Donald <pe...@apache.org>.

On Wed, 10 Jul 2002 20:30, Carsten Ziegeler wrote:
> > It is unfortunate that ECMs lookup is costly. Does Fortresss have
> > this problem
> > aswell? Most containers I work with are little more than a hashlookup.
>
> Even if the lookup is not costly, what about non ThreadSafe components?
> For example the XSLTProcessor is configured to not use the Store,
> the Store would be Poolable (as the XSLTProcessor is) and the XSLTProcessor
> looksup a Store in compose().
> So each XSLTProcessor component would block a Store component, although
> this would not be necessary.

true. But XSLTProcessor would bugger up all those components now as I removed 
the release() ;)

I looked at all the store implementations and they all were threadsafe and I 
applied the same logic as I did wrt the XMLizer/Parser. ie If all 
implementations are threadsafe then dont worry about releasing the component.

If the component was poolable then what I did would not be good - it would 
suck actually ;)

-- 
Cheers,

Peter Donald
*------------------------------------------------*
| You can't wake a person who is pretending      |
|       to be asleep. -Navajo Proverb.           |
*------------------------------------------------* 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Optional Dependencies

Posted by Vadim Gritsenko <va...@verizon.net>.

> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> 
> Peter Donald wrote:
> > > I think the XSLTProcessor is a good example for a use-case of b).
> > >
> > > A store is available in (nearly) every system, so this component
is
> > > always present. If we only have use-case a), then the
XSLTProcessor
> > > always uses the store for caching stylesheets.
> >
> > true but thats only true in the container where there is no such
> > thing as an
> > assembler. ECM has a global namespace for components where as other
> > containers may or may not have this but even so...
> >
> > Just because you aquire a service does not mean you have to use
> > it. ie You can
> > aquire service but only use it in certain locations. One of which
> > may be you
> > only use it if a flag is true or similar (Similar to how I
> > implemented it in
> > XSLTProcessor).
> >
> Ok, I understand this.
> 
> > It is unfortunate that ECMs lookup is costly. Does Fortresss have
> > this problem aswell?

If it does not have Lists (and it does not... for what I could
understand), then it should be faster then ECM.


> > Most containers I work with are little more than a hashlookup.
> >
> Even if the lookup is not costly, what about non ThreadSafe
components?
> For example the XSLTProcessor is configured to not use the Store,
> the Store would be Poolable (as the XSLTProcessor is) and the
XSLTProcessor

Neither XSLTProcessor, nor XSLTProcessorImpl is Poolable.
XSLTProcessorImpl is SingleThreaded ATM.


Vadim


> looksup a Store in compose().
> So each XSLTProcessor component would block a Store component,
although
> this would not be necessary.
> 
> Carsten


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Optional Dependencies

Posted by Carsten Ziegeler <cz...@s-und-n.de>.

Peter Donald wrote:
> > I think the XSLTProcessor is a good example for a use-case of b).
> >
> > A store is available in (nearly) every system, so this component is
> > always present. If we only have use-case a), then the XSLTProcessor
> > always uses the store for caching stylesheets.
> 
> true but thats only true in the container where there is no such 
> thing as an 
> assembler. ECM has a global namespace for components where as other 
> containers may or may not have this but even so...
> 
> Just because you aquire a service does not mean you have to use 
> it. ie You can 
> aquire service but only use it in certain locations. One of which 
> may be you 
> only use it if a flag is true or similar (Similar to how I 
> implemented it in 
> XSLTProcessor).
> 
Ok, I understand this.

> It is unfortunate that ECMs lookup is costly. Does Fortresss have 
> this problem 
> aswell? Most containers I work with are little more than a hashlookup.
> 
Even if the lookup is not costly, what about non ThreadSafe components?
For example the XSLTProcessor is configured to not use the Store,
the Store would be Poolable (as the XSLTProcessor is) and the XSLTProcessor
looksup a Store in compose().
So each XSLTProcessor component would block a Store component, although
this would not be necessary.

Carsten

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Optional Dependencies

Posted by Berin Loritsch <bl...@apache.org>.

> From: Peter Donald [mailto:peter@apache.org] 
> 
> It is unfortunate that ECMs lookup is costly. Does Fortresss 
> have this problem 
> aswell? Most containers I work with are little more than a hashlookup.


Nope!

Doing pure lookup invocations on ECM vs. Fortress under load from
several
threads has Fortress coming out ahead 15 to 1.


ECM's overhead has to do with all the logic to determine if the
component
is already set up, if it isn't, then set it up.  It is perticularly
expensive
on factory components and undersized pool components.  The reason is
that
the component has to go through full lifecycle on the spot.

ECM has been improved tremendously with Lief's pooling code, but it is
still
way more inefficient than Fortress.  Not to mention that ECM has longer
times
where we can have thread contention.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Optional Dependencies

Posted by Peter Donald <pe...@apache.org>.

On Wed, 10 Jul 2002 20:14, Carsten Ziegeler wrote:
> Peter Donald wrote:
> > > Hmmm, I'm not sure if this is a good feature - because an optional
> > > dependency means it's - well - optional. And I see two use cases
> > > their:
> > > a) The optional component is only used if it is available
> >
> > thats the usecase I had in mind.
> >
> > > b) The optional component is used only in some circumstances
> >
> > That is the usecase that I originally liked but Berin jumped on
> > me back in ye
> > old days for it. Then we both jumped on Fede (one of the original avalon
> > developers).
> >
> > Whats everyone else think. Should optional dependencies be "optional"
> > depending on the presence of some attribute (be it config variable or
> > something).
> >
> > Or should it be the assemblers decision, ie If they provide the
> > component then
> > it is used else it is not.
>
> I think the XSLTProcessor is a good example for a use-case of b).
>
> A store is available in (nearly) every system, so this component is
> always present. If we only have use-case a), then the XSLTProcessor
> always uses the store for caching stylesheets.

true but thats only true in the container where there is no such thing as an 
assembler. ECM has a global namespace for components where as other 
containers may or may not have this but even so...

Just because you aquire a service does not mean you have to use it. ie You can 
aquire service but only use it in certain locations. One of which may be you 
only use it if a flag is true or similar (Similar to how I implemented it in 
XSLTProcessor).

It is unfortunate that ECMs lookup is costly. Does Fortresss have this problem 
aswell? Most containers I work with are little more than a hashlookup.

-- 
Cheers,

Peter Donald
------------------------------------------------
| We shall not cease from exploration, and the |
|  end of all our exploring will be to arrive  |
|  where we started and know the place for the |
|            first time -- T.S. Eliot          |
------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Optional Dependencies

Posted by Carsten Ziegeler <cz...@s-und-n.de>.

Peter Donald wrote:
> 
> >
> > Hmmm, I'm not sure if this is a good feature - because an optional
> > dependency means it's - well - optional. And I see two use cases
> > their:
> > a) The optional component is only used if it is available
> 
> thats the usecase I had in mind.
> 
> > b) The optional component is used only in some circumstances
> 
> That is the usecase that I originally liked but Berin jumped on 
> me back in ye 
> old days for it. Then we both jumped on Fede (one of the original avalon 
> developers).
> 
> Whats everyone else think. Should optional dependencies be "optional" 
> depending on the presence of some attribute (be it config variable or 
> something). 
> 
> Or should it be the assemblers decision, ie If they provide the 
> component then 
> it is used else it is not.
> 
I think the XSLTProcessor is a good example for a use-case of b).

A store is available in (nearly) every system, so this component is
always present. If we only have use-case a), then the XSLTProcessor
always uses the store for caching stylesheets. 
That would be a realy problem if you have many, changing stylesheets.
The caching would reduce performance.

So, I think b) is needed - unless we want to XSLTProcessors (
a caching and a non-caching one)...


Carsten

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Optional Dependencies

Posted by Peter Donald <pe...@apache.org>.

On Wed, 10 Jul 2002 19:55, Carsten Ziegeler wrote:
> Peter Donald wrote:
> > > Why do you want to aquire the store even if it is not used?
> >
> > Basically to avoid warnings in a container I am working on. ie If
> > you declare
> > dependencies (even if they are optional dependencies) and the container
> > provides you component but you dont use it then the container
> > will wanr you
> > saying something like
> >
> > "You have misdeclared a dependency on X as it was never used."
> >
> > or similar.
>
> Hmmm, I'm not sure if this is a good feature - because an optional
> dependency means it's - well - optional. And I see two use cases
> their:
> a) The optional component is only used if it is available

thats the usecase I had in mind.

> b) The optional component is used only in some circumstances

That is the usecase that I originally liked but Berin jumped on me back in ye 
old days for it. Then we both jumped on Fede (one of the original avalon 
developers).

Whats everyone else think. Should optional dependencies be "optional" 
depending on the presence of some attribute (be it config variable or 
something). 

Or should it be the assemblers decision, ie If they provide the component then 
it is used else it is not.

-- 
Cheers,

Peter Donald
"The ability to quote is a serviceable substitute for wit." -- Maugham 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>