You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by co...@covalent.net on 2002/04/05 01:25:13 UTC
Coyote: replacing Processor with ProtocolHandler
Hi,
In order to merge the connector-related code in Coyote and jk, I need
a different abstraction. Processor takes InputStream/OutputStream params,
and assumes the connector will listen on the port, etc.
The problem is that it doesn't map to things like JNI and is hard to
abstract things like UnixSocket.
I would like to replace it with a similar interface, ProtocolHandler,
which is stateless ( Servlet-like ) and will just have a init()/destroy()
method, letting the protocol deal with the threads.
It's easy to implement it in http11 - this is duplicated in the 33/40
versions. I would prefer to use the 33 thread pool from util, but
I'm ok with the code used in 40 ( or I can implement both, with an
option ).
Also, I would like to reduce/eliminate the use of Socket and the other
dependencies between Coyote and the protocol impl ( it is supposed
to abstract it, but there are few details.. )
Remy, Bill - is it ok ?
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CoyoteRequest: the socket
Posted by Eric Rescorla <ek...@rtfm.com>.
"Remy Maucherat" <re...@apache.org> writes:
> > The way it works - the connector ( or protocol handler ) creates the
> > socket, using plain, jsse, pureTLS. And Remy is saying that some othe
> > valves are calling getSocket() and use the socket/JSSE to extract info (
> > I assume using JSSE specific code).
> >
> > That is going to fail if PureTLS or Ajp are used.
> >
> > But I don't think we can do anything about it - the method must be
> > deprecated and the code that calls it must be changed to call the right
> > methods ( req.getAttribute() or similar ).
>
> Yes, unfortunately, I don't see a way to make it work.
Yes, it sounds like the calling code will have to change. How bad
will that be?
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CoyoteRequest: the socket
Posted by Remy Maucherat <re...@apache.org>.
> On 5 Apr 2002, Eric Rescorla wrote:
>
> > "Remy Maucherat" <re...@apache.org> writes:
> > > > On Fri, 5 Apr 2002, Remy Maucherat wrote:
> > > > I have big doubts the code that calls getSocket() can even work with
ajp
> > > > or pureTLS or other things. Probably a good idea to find where it is
and
> > > > call the right thing ( like getAttribute for certs, etc ).
> > >
> > > I'm not sure about it, but it doesn't look like client-cert would work
with
> > > PureTLS.
>
> > Hmm... I need to dig into this. Why do you think it wouldn't?
>
> The way it works - the connector ( or protocol handler ) creates the
> socket, using plain, jsse, pureTLS. And Remy is saying that some othe
> valves are calling getSocket() and use the socket/JSSE to extract info (
> I assume using JSSE specific code).
>
> That is going to fail if PureTLS or Ajp are used.
>
> But I don't think we can do anything about it - the method must be
> deprecated and the code that calls it must be changed to call the right
> methods ( req.getAttribute() or similar ).
Yes, unfortunately, I don't see a way to make it work.
> BTW, with the new protocol handler - I still haven't implemented the
> ActionCode to support req.getAttribute. I need a way to pass information
> up ( all existing ActionCode are passing info from connector to protocol,
> and I need a way to return info ).
>
> After Remy reviews the o.a.t.util.handler.TcHandlerContext, I plan to
> use the context as a second param in the ActionHook - and use notes to
> pass/return all informations we need.
I don't like this habit of allowing bad design to live forever. The Action*
must go, and be replaced by the TcHandler.
The Http11Protocol appears to be working fine with the new Catalina
connector, with the exception of the note below.
Note: I have a problem implementing getRemoteHost and getRemoteAddr. I don't
think it can be done lazily.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CoyoteRequest: the socket
Posted by co...@covalent.net.
On 5 Apr 2002, Eric Rescorla wrote:
> "Remy Maucherat" <re...@apache.org> writes:
> > > On Fri, 5 Apr 2002, Remy Maucherat wrote:
> > > I have big doubts the code that calls getSocket() can even work with ajp
> > > or pureTLS or other things. Probably a good idea to find where it is and
> > > call the right thing ( like getAttribute for certs, etc ).
> >
> > I'm not sure about it, but it doesn't look like client-cert would work with
> > PureTLS.
> Hmm... I need to dig into this. Why do you think it wouldn't?
The way it works - the connector ( or protocol handler ) creates the
socket, using plain, jsse, pureTLS. And Remy is saying that some othe
valves are calling getSocket() and use the socket/JSSE to extract info (
I assume using JSSE specific code).
That is going to fail if PureTLS or Ajp are used.
But I don't think we can do anything about it - the method must be
deprecated and the code that calls it must be changed to call the right
methods ( req.getAttribute() or similar ).
BTW, with the new protocol handler - I still haven't implemented the
ActionCode to support req.getAttribute. I need a way to pass information
up ( all existing ActionCode are passing info from connector to protocol,
and I need a way to return info ).
After Remy reviews the o.a.t.util.handler.TcHandlerContext, I plan to
use the context as a second param in the ActionHook - and use notes to
pass/return all informations we need.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CoyoteRequest: the socket
Posted by Eric Rescorla <ek...@rtfm.com>.
"Remy Maucherat" <re...@apache.org> writes:
> > On Fri, 5 Apr 2002, Remy Maucherat wrote:
> > I have big doubts the code that calls getSocket() can even work with ajp
> > or pureTLS or other things. Probably a good idea to find where it is and
> > call the right thing ( like getAttribute for certs, etc ).
>
> I'm not sure about it, but it doesn't look like client-cert would work with
> PureTLS.
Hmm... I need to dig into this. Why do you think it wouldn't?
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CoyoteRequest: the socket
Posted by Remy Maucherat <re...@apache.org>.
> On Fri, 5 Apr 2002, Remy Maucherat wrote:
>
> > Some valves in the Catalina pipeline use that.
> >
> > It probably should be done at the protocol layer, but I can't do that
for
> > compatibility reasons, so I think the socket should be set as a note in
the
> > Request object (as is suggested in the commented out code in the
HTTP/1.1
> > protocol handler).
>
> Ok. I hope the code can deal with 'no socket' case - since in Ajp case
> the socket is completely useless.
Apparently, the only class which uses that method is
o.a.c.valves.CertificatesValve. It handles the case where getSocket returns
null.
> I have big doubts the code that calls getSocket() can even work with ajp
> or pureTLS or other things. Probably a good idea to find where it is and
> call the right thing ( like getAttribute for certs, etc ).
I'm not sure about it, but it doesn't look like client-cert would work with
PureTLS.
> > > - Any reason for not extending HttpBaseRequest ?
> >
> > You mean HttpRequestBase in Catalina ?
> > This object's implementation is bad, and I wanted to deprecate it to
make
> > that obvious. There's little code duplication overall.
> > There's also no ugly casts to the XXBase objects in the Catalina
pipeline
> > (everthing uses the interfaces), so it works fine.
> >
> > I'll do a CoyoteConnector2 for Catalina soon too to see how it works.
> > Probably tomorrow.
>
> Ok, what about CoyoteConnector3 ? I already started with 2 :-)
It's quite simple to do.
I'll do it at least to learn how to manipulate the new interface, and see if
there are problems with the new Http11Protocol class.
> ( but I'll start working on Jk if you do the Connector )
That's not something I can do, so that looks like a good idea :)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CoyoteRequest: the socket
Posted by co...@covalent.net.
On Fri, 5 Apr 2002, Remy Maucherat wrote:
> Some valves in the Catalina pipeline use that.
>
> It probably should be done at the protocol layer, but I can't do that for
> compatibility reasons, so I think the socket should be set as a note in the
> Request object (as is suggested in the commented out code in the HTTP/1.1
> protocol handler).
Ok. I hope the code can deal with 'no socket' case - since in Ajp case
the socket is completely useless.
I have big doubts the code that calls getSocket() can even work with ajp
or pureTLS or other things. Probably a good idea to find where it is and
call the right thing ( like getAttribute for certs, etc ).
> > - Any reason for not extending HttpBaseRequest ?
>
> You mean HttpRequestBase in Catalina ?
> This object's implementation is bad, and I wanted to deprecate it to make
> that obvious. There's little code duplication overall.
> There's also no ugly casts to the XXBase objects in the Catalina pipeline
> (everthing uses the interfaces), so it works fine.
>
> I'll do a CoyoteConnector2 for Catalina soon too to see how it works.
> Probably tomorrow.
Ok, what about CoyoteConnector3 ? I already started with 2 :-)
( but I'll start working on Jk if you do the Connector )
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CoyoteRequest: the socket
Posted by Remy Maucherat <re...@apache.org>.
> 2 questions ( for Remy ):
>
> - is anyone using the getSocket() method in CoyoteRequest ? It's obvious
> this can't work for other protocols, and extracting SSL info is
> specific to the SSL impl and should be done at the protocol layer.
Some valves in the Catalina pipeline use that.
It probably should be done at the protocol layer, but I can't do that for
compatibility reasons, so I think the socket should be set as a note in the
Request object (as is suggested in the commented out code in the HTTP/1.1
protocol handler).
> - Any reason for not extending HttpBaseRequest ?
You mean HttpRequestBase in Catalina ?
This object's implementation is bad, and I wanted to deprecate it to make
that obvious. There's little code duplication overall.
There's also no ugly casts to the XXBase objects in the Catalina pipeline
(everthing uses the interfaces), so it works fine.
I'll do a CoyoteConnector2 for Catalina soon too to see how it works.
Probably tomorrow.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
CoyoteRequest: the socket
Posted by co...@covalent.net.
2 questions ( for Remy ):
- is anyone using the getSocket() method in CoyoteRequest ? It's obvious
this can't work for other protocols, and extracting SSL info is
specific to the SSL impl and should be done at the protocol layer.
- Any reason for not extending HttpBaseRequest ?
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Coyote: replacing Processor with ProtocolHandler
Posted by Remy Maucherat <re...@apache.org>.
> On Fri, 5 Apr 2002, Remy Maucherat wrote:
>
> > > There is no problem if we use 2 Http11Protocol, one with ThreadPool
the
> > > other with 4.0 threads. Right now I'm working on the TP one.
> >
> > We don't need two, so I'll try yours ;-)
> > Do you plan to write the Http11ProtocolHandler ?
>
> Already done, but I have a bug I'm trying to fix ( the classical body
> sent before headers or mixed up, I've seen this at least 10 times :-).
>
> I'll check it in, it doesn't affect anything else ( it's not pretty yet,
> I moved code from few places ).
Ok, please do. Since I'll probably use it, I'll try to improve it (assuming
it needs improving).
> Now the big question - can you take a look at util.handler.TcHandler ?
> I'm don't want to replace ActionHook ( for now :-), but maybe have Action
> extend TcHandler - or something similar, so the hook can use the ctx
> ( and pass and return information ). I can also use TcHandlerContext (
> i.e. just a set of int-indexed notes ) as param for Action hook as the
> first step.
I have no problems getting rid of the current 'action' mechanism and
replacing it with your handler.
> Long term I think we should use TcHandler as the main hook and deprecate
> ActionHook/JkHandler/etc. Of course, the name and interface is open
> to change - we can rename it TcHook and make it interface, or use
> action() and pass an object similar with ActionCode ( maybe ActionChain -
> since each ActionCode represents a specific category of hooks chained )
Given what and where the ActionHook/Code is used, I really have no problem
replacing it if the replacement object allows me to do the same things.
>From TC, the action stuff is used through the Catalina API, so there's
nothing impacted outside of Coyote.
The protocol handler change should also have zero impact, as I just need to
rewrite the CatalinaConnector wrapper to use it instead of using its own
pooling. Very easy to do overall.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Coyote: replacing Processor with ProtocolHandler
Posted by co...@covalent.net.
On Fri, 5 Apr 2002, Remy Maucherat wrote:
> > There is no problem if we use 2 Http11Protocol, one with ThreadPool the
> > other with 4.0 threads. Right now I'm working on the TP one.
>
> We don't need two, so I'll try yours ;-)
> Do you plan to write the Http11ProtocolHandler ?
Already done, but I have a bug I'm trying to fix ( the classical body
sent before headers or mixed up, I've seen this at least 10 times :-).
I'll check it in, it doesn't affect anything else ( it's not pretty yet,
I moved code from few places ).
Now the big question - can you take a look at util.handler.TcHandler ?
I'm don't want to replace ActionHook ( for now :-), but maybe have Action
extend TcHandler - or something similar, so the hook can use the ctx
( and pass and return information ). I can also use TcHandlerContext (
i.e. just a set of int-indexed notes ) as param for Action hook as the
first step.
Long term I think we should use TcHandler as the main hook and deprecate
ActionHook/JkHandler/etc. Of course, the name and interface is open
to change - we can rename it TcHook and make it interface, or use
action() and pass an object similar with ActionCode ( maybe ActionChain -
since each ActionCode represents a specific category of hooks chained )
Just review it - pluging it in can be done later ( and smoothly )
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Coyote: replacing Processor with ProtocolHandler
Posted by Remy Maucherat <re...@apache.org>.
> On Fri, 5 Apr 2002, Remy Maucherat wrote:
>
> > > It's easy to implement it in http11 - this is duplicated in the 33/40
> > > versions. I would prefer to use the 33 thread pool from util, but
> > > I'm ok with the code used in 40 ( or I can implement both, with an
> > > option ).
> >
> > The 4.0 pool works good, so I don't plan to fix it since it's not broken
:)
>
> There is no problem if we use 2 Http11Protocol, one with ThreadPool the
> other with 4.0 threads. Right now I'm working on the TP one.
We don't need two, so I'll try yours ;-)
Do you plan to write the Http11ProtocolHandler ?
> > > Also, I would like to reduce/eliminate the use of Socket and the other
> > > dependencies between Coyote and the protocol impl ( it is supposed
> > > to abstract it, but there are few details.. )
> > >
> > > Remy, Bill - is it ok ?
> >
> > The HTTP/1.1 processor is written for IS and OS, and in general blocking
IO.
> > You can't use any message based processing with it, that's for sure.
> > Will it still work after abstracting this ?
>
> Nothing fundamental change in how things work - it'll just move the (
> duplicated ) thread and socket code to a lower layer.
That's what I understood (but it took me 10 more minutes).
> If we can pick one threading model - great, if not - we'll have 2, and
> each server can pick either one at runtime.
>
> ( and you get TP and all ssl support from 3.3 for free, useable with the
> 4.0 connector )
You need to add them in j-t-c/util then.
> > Also, since the current code is stable and works good, I wanted to make
a
> > 1.0 release of Coyote and the HTTP/1.1 processor so I have something to
fall
> > back on if there are some problems with merging to JK.
> >
> > I'd like to:
> > - Release a Coyote 1.0 RC with the current code
> > - Create a 1.0 branch in j-t-c based on the current code
>
> What about:
>
> - tag the code ( at the latest beta ).
> - I'll just add code, with minimal changes to the existing code.
> - If it works out, release another beta with Coyote supporting both
> HTTP/1.1 and AJP13. If not, fall back to the branch.
Yes, we can create the branch at any time based on the tag. No problem about
that.
I'll do that.
> Are you at least ok with adding the o.a.t.u.net ( the 3.3 SSL stuff ) to
> util, and leaving the ProtocolHandler in ?
Yes, of course.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Coyote: replacing Processor with ProtocolHandler
Posted by co...@covalent.net.
On Fri, 5 Apr 2002, Remy Maucherat wrote:
> > It's easy to implement it in http11 - this is duplicated in the 33/40
> > versions. I would prefer to use the 33 thread pool from util, but
> > I'm ok with the code used in 40 ( or I can implement both, with an
> > option ).
>
> The 4.0 pool works good, so I don't plan to fix it since it's not broken :)
There is no problem if we use 2 Http11Protocol, one with ThreadPool the
other with 4.0 threads. Right now I'm working on the TP one.
> > Also, I would like to reduce/eliminate the use of Socket and the other
> > dependencies between Coyote and the protocol impl ( it is supposed
> > to abstract it, but there are few details.. )
> >
> > Remy, Bill - is it ok ?
>
> The HTTP/1.1 processor is written for IS and OS, and in general blocking IO.
> You can't use any message based processing with it, that's for sure.
> Will it still work after abstracting this ?
Nothing fundamental change in how things work - it'll just move the (
duplicated ) thread and socket code to a lower layer.
If we can pick one threading model - great, if not - we'll have 2, and
each server can pick either one at runtime.
( and you get TP and all ssl support from 3.3 for free, useable with the
4.0 connector )
> Also, since the current code is stable and works good, I wanted to make a
> 1.0 release of Coyote and the HTTP/1.1 processor so I have something to fall
> back on if there are some problems with merging to JK.
>
> I'd like to:
> - Release a Coyote 1.0 RC with the current code
> - Create a 1.0 branch in j-t-c based on the current code
What about:
- tag the code ( at the latest beta ).
- I'll just add code, with minimal changes to the existing code.
- If it works out, release another beta with Coyote supporting both
HTTP/1.1 and AJP13. If not, fall back to the branch.
Are you at least ok with adding the o.a.t.u.net ( the 3.3 SSL stuff ) to
util, and leaving the ProtocolHandler in ?
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Coyote: replacing Processor with ProtocolHandler
Posted by Remy Maucherat <re...@apache.org>.
> Hi,
>
> In order to merge the connector-related code in Coyote and jk, I need
> a different abstraction. Processor takes InputStream/OutputStream params,
> and assumes the connector will listen on the port, etc.
>
> The problem is that it doesn't map to things like JNI and is hard to
> abstract things like UnixSocket.
I know.
> I would like to replace it with a similar interface, ProtocolHandler,
> which is stateless ( Servlet-like ) and will just have a init()/destroy()
> method, letting the protocol deal with the threads.
>
> It's easy to implement it in http11 - this is duplicated in the 33/40
> versions. I would prefer to use the 33 thread pool from util, but
> I'm ok with the code used in 40 ( or I can implement both, with an
> option ).
The 4.0 pool works good, so I don't plan to fix it since it's not broken :)
> Also, I would like to reduce/eliminate the use of Socket and the other
> dependencies between Coyote and the protocol impl ( it is supposed
> to abstract it, but there are few details.. )
>
> Remy, Bill - is it ok ?
The HTTP/1.1 processor is written for IS and OS, and in general blocking IO.
You can't use any message based processing with it, that's for sure.
Will it still work after abstracting this ?
Anyway, the init/destroy and other things are probably needed.
I'll have to look into the design a lot more ....
Also, since the current code is stable and works good, I wanted to make a
1.0 release of Coyote and the HTTP/1.1 processor so I have something to fall
back on if there are some problems with merging to JK.
I'd like to:
- Release a Coyote 1.0 RC with the current code
- Create a 1.0 branch in j-t-c based on the current code
Is it ok ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Coyote: replacing Processor with ProtocolHandler
Posted by co...@covalent.net.
On Thu, 4 Apr 2002, Bill Barker wrote:
> It's fine with me. I also have a slight preference for the 33 ThreadPool,
> but it's not a big deal either way.
>
> If we're going to move the socket handling into o.a.c.http11, what about
> importing o.a.t.util.net? It should mean that Tomcat 4.x should be able to
> get PureTLS support fairly cheaply.
Yes, I'm already working on that.
Remy - your call. PureTLS is 'bundled' with ThreadPool :-)
I'll get it working with ThreadPool, I'm more familiar with it and I think
it's pretty well tested and optimized. I can add the threading code
from 4.0, it's not hard - but then we'll have to plug PureTLS and
many other things that are only implemented in 3.3.
Costin
> ----- Original Message -----
> From: <co...@covalent.net>
> To: <to...@jakarta.apache.org>
> Sent: Thursday, April 04, 2002 3:25 PM
> Subject: Coyote: replacing Processor with ProtocolHandler
>
>
> > Hi,
> >
> > In order to merge the connector-related code in Coyote and jk, I need
> > a different abstraction. Processor takes InputStream/OutputStream params,
> > and assumes the connector will listen on the port, etc.
> >
> > The problem is that it doesn't map to things like JNI and is hard to
> > abstract things like UnixSocket.
> >
> > I would like to replace it with a similar interface, ProtocolHandler,
> > which is stateless ( Servlet-like ) and will just have a init()/destroy()
> > method, letting the protocol deal with the threads.
> >
> > It's easy to implement it in http11 - this is duplicated in the 33/40
> > versions. I would prefer to use the 33 thread pool from util, but
> > I'm ok with the code used in 40 ( or I can implement both, with an
> > option ).
> >
> > Also, I would like to reduce/eliminate the use of Socket and the other
> > dependencies between Coyote and the protocol impl ( it is supposed
> > to abstract it, but there are few details.. )
> >
> > Remy, Bill - is it ok ?
> >
> > Costin
> >
> >
> > --
> > 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: Coyote: replacing Processor with ProtocolHandler
Posted by Bill Barker <wb...@wilshire.com>.
It's fine with me. I also have a slight preference for the 33 ThreadPool,
but it's not a big deal either way.
If we're going to move the socket handling into o.a.c.http11, what about
importing o.a.t.util.net? It should mean that Tomcat 4.x should be able to
get PureTLS support fairly cheaply.
----- Original Message -----
From: <co...@covalent.net>
To: <to...@jakarta.apache.org>
Sent: Thursday, April 04, 2002 3:25 PM
Subject: Coyote: replacing Processor with ProtocolHandler
> Hi,
>
> In order to merge the connector-related code in Coyote and jk, I need
> a different abstraction. Processor takes InputStream/OutputStream params,
> and assumes the connector will listen on the port, etc.
>
> The problem is that it doesn't map to things like JNI and is hard to
> abstract things like UnixSocket.
>
> I would like to replace it with a similar interface, ProtocolHandler,
> which is stateless ( Servlet-like ) and will just have a init()/destroy()
> method, letting the protocol deal with the threads.
>
> It's easy to implement it in http11 - this is duplicated in the 33/40
> versions. I would prefer to use the 33 thread pool from util, but
> I'm ok with the code used in 40 ( or I can implement both, with an
> option ).
>
> Also, I would like to reduce/eliminate the use of Socket and the other
> dependencies between Coyote and the protocol impl ( it is supposed
> to abstract it, but there are few details.. )
>
> Remy, Bill - is it ok ?
>
> Costin
>
>
> --
> 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>