You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Stefano Mazzocchi <st...@apache.org> on 2000/01/31 17:06:58 UTC
[Proposal] "Relayed" Apache API Project
People,
first, I would like to apologize for those of you who do not care about
this issue, sorry for the reduced signal/noise ration this will generate
to you.
second, I'm an Apache member but I know almost nothing about the Apache
web server, so I feel kind of dumb to propose an addiction to a project
I know very little about. Anyway, having partecipated in apache projects
for years, I know enough about how to attach external heavy things to
apache, even if I always worked on their java side.
What follows is a proposal I made for the internal committers mail list
to understand if something like this had a value before "asking for
flames" on more public forums like these ones. This was mainly due to my
lack of experience with httpd, not because I wanted this to remain
hidden. Rather the opposite.
So you find quoted my original proposal I made a few days ago. Many
comments were already made on that list, but nothing has been resolved.
Some would like Corba to be considered, some others consider Corba too
much and too slow. Some would like to go on with AJP (the Apache jserv
protocol used by mod_jserv to
connect to jserv). Some would like MUX, or simple HTTP, some don't see
the need for such a thing.
The Apache JServ and Jakarta Tomcat projects are both interested in a
complete and web server abstacted architecture to connect heavy modules
to the web server remotely.
But I would like the discussion to happen at a higher level,
incorporating ideas from all perspectives. The java-related apache
projects lacked a good talking relationship with the other
non-java-related projects and this is very unfortunate, IMO. This would
like to be a small step in a better unification of efforts.
So, here it is.
[please, keep the CC list since not everybody interested in this
discussion is subscribed on all the lists. For those that are, I
apologize for the mail flood, but this is somewhat necessary at this
point.]
Stefano Mazzocchi wrote:
>
> [note: since I didn't want to crosspost on tons of mail lists, so this
> sounds about the right place for talking about this and to have an
> opinion on how feasible is a project like this. For those of you who
> cannot care less about something like this, I apologize in advance]
>
> People,
>
> while Apache 2.0 will address the issues regarding embedding a JVM
> inside the web server with multi-threading, the need for remote and
> multi-tiered operation will always remain, expecially given the
> scalability issues and fault tollerance involved (would you trust a JVM
> enough to embed it into your mission critical web server?).
>
> On the other hand, it is evident that such requirements of "relayed"
> operation are shared by many projects, most notably those regarding the
> need for JVMs, but I think others might find this useful for other
> projects (mod_perl? mod_php? you tell me)
>
> Such apache module, should make transparently available the Apache APIs
> the other side of a connection (either TCP/IP based, or any other
> ordered stream connection).
>
> This picture explains what I mean:
>
> apache <-> mod_relay <------------------> mod_relay <-> module
>
> note the two-ways arrows.
>
> I propose that a project is started to take care of its development,
> protocol creation and maintentance, hopefully leading to the inclusion
> in main-stream web server architecture and distribution.
>
> Don't get me wrong, since I'm a java-type guy and I am admittedly very
> ignorant about the apache internals, I'd like to discuss this with you
> before going on.
>
> Ed Korthof, Ian Kluft and I were the original authors of the AJP 2.0
> protocol that was designed two years ago to fullfill such requirement in
> the Apache JServ project (thus the name: Apache JServ Protocol). It
> turned out to be a very big project and we didn't have the skills to
> make this happen.
>
> Today, many people are interested in the jakarta mail list in adding a
> better protocol between apache and java-based applications such as
> servlet engines. Going a little further, it could be helpful for many
> others, hence this request for comments.
>
> Costin expressed early the opinion that the best way of adding java
> capabilities to the Apache web server is using something like this
>
> apache -> mod_java -> java module
>
> where mod_java is a module that exposes the Apache APIs in Java. If this
> java module is a servlet engine we get
>
> apache -> mod_java -> servlet engine -> servlet
>
> both of which, of course, requires the JVM to reside on the same web
> server process connected thru a JNI interface. This is, of course, the
> fastest way of doing it, no matter what, but may not feed all needs
> (expecially now that you have to spawn a new JVM for every process you
> have. Note: a JVM (java virtual machine) is a very heavy process, even
> if more modern JVMs can share memory resources if more than one is
> executed on the same system, but don't ask me how this is done or how
> portable this is!).
>
> On the other hand, if we want the web server and JVM to reside on
> different machines (or on totally isolated processes on the same
> machine), we need something like
>
> apache <-> mod_relay <====> mod_relay <-> mod_java <-> servlet engine
>
> where "<====>" indicates an ordered stream full-duplex connection
> (pipes? tcp/ip? you name it).
>
> Such "Apache relay protocol" server could be either written in C or with
> other languages, depending on the needs (i.e. for relayed servlet
> engines, mod_relay + mod_java should become a single protocol adapting
> layer that drives the servlet engine request/response generation
> facility) and should be able to handle multiple connections at once,
> keeping them alive for performance reasons.
>
> The "Apache Relay Protocol" could be based on existing AJP, or based on
> more standard full-duplex protocols such as IIOP or anything else.
>
> Also, it would be nice to provide "flavors" of this mod_relay module for
> both ISAPI and NSAPI, performing a sort of "Apache emulation" layer than
> would simplify the adoption of apache projects even on those systems
> that do not operate the apache web server for a number of reasons. This
> might help to gain more users since it would simplify transition.
>
> Let me know what you think... then we'll decide what to do and where to
> locate such an effort.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------
Re: [Proposal] "Relayed" Apache API Project
Posted by Assaf Arkin <ar...@exoffice.com>.
costin@eng.sun.com wrote:
> First VM is very expensive, next is cheaper.
> With Apache 2.0 it's not a problem - and we are talking about future here.
> ( mod_java is intended for Apache 2.0, and it's just an option you'll
> have, the default will still be relay ).
Not on my Linux box. I'm using JDK 1.2.2 from Sun, seems to generate a
new VM each time it needs one.
If it's a bug that will be fixed, then it's not big deal.
> IIOP is binary :-) Probably too binary, and it support straight TCP/IP (
> plus unix sockets, etc). I just hate re-inventing the wheel, but I agree
> IIOP is probably too complex.
I know, but IIOP contains additional stuff that we just don't care
about. I pointed out binary in case anyone thinks out loud the
possibility of using XML for that.
arkin
>
> Costin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: [Proposal] "Relayed" Apache API Project
Posted by co...@costin.dnt.ro.
> As far as I can remember, the situation with IIOP was pay for what you
> use. If you use the dynamic subsystem (DII/DSI), typecode-based
> marshalling/unmarshalling or recently Objects-by-Value (with fragmentation
> and all that nonsense), then your roundtrip perf could go out the window.
> But all we need it is for simple RPC. In fact given that IIOP is a
> backward compatible protocol; we can just pick some ORB out there that
> just supports 1.0!
In our case, we'll have methods with string params returning strings.
The CDR encoding for strings is almost identical with what AJP use!!
There are only small differences between IIOP messages and what AJP uses,
i.e. a header that is almost allways the same ( + magic, version,
byte_order, etc). Probably implementing a new protocol will require the
same work as implementing the subset of IIOP we need, but we'll get many
extra benefits by using the IIOP - we may be able to interoperate with
"real" ORBs, if we need more complex methods we can re-use existing code,
etc. ( and we'll not need to implement it - we can use something that
exist and optimize if needed)
And we'll not have to spend time reinventing Corba.
Costin
Re: [Proposal] "Relayed" Apache API Project
Posted by "Anil K. Vijendran" <An...@eng.sun.com>.
On Mon, 31 Jan 2000, Shachor Gal wrote:
> I guess that the question here is what are we looking for, CORBA is good
> when you need to implement a flexible general purpose object interface.
> IMHO this is not such case, I think (and correct me if I am wrong) that
> what we are looking for is a fast request forwarding with callback
> capabiliies...
>
> - We are not going to pass object references...
> - Most of the data is going to be plain strings/integers representing a
> well known value
> - Callbacks should happen at the same thread that initiated the request,
> in CORBA on the other hand due to (good) generalization limits callbacks
> are done in another thread...
>
> We can find more reasons if we will look for them.
>
> So, it seems that using an AJP2.1 based protocol is going to be a much
> simpler and adequate approach.
CORBA is basically an API description system (IDL) and a protocol (IIOP).
This allows you to make arbitrary function calls.
Data you pass can be plain predefined IDL types (integers, strings etc) in
which case it doesn't hurt very much to use IIOP in its simple basic form.
There are atleast two objects -- one on the Apache side and one on the
Tomcat side and these objrefs can either be exchanged as initial
references or using a naming service that comes with any ORB.
I'm not worried about the overkill factor of using CORBA for fast request
forwarding with callback capabilities; what worries me is the
singlethreaded restriction. There is support for singlethreaded invocation
using an event poll and dispatch mechanism. Unfortunately not many people
implement it :-)
>From the ORBit sources:
1082 /* Section 4.9.1 */
1083 CORBA_boolean CORBA_ORB_work_pending(CORBA_ORB orb, CORBA_Environment
*ev)
1084 {
1085 g_assert(!"Not yet implemented");
1086 return(CORBA_FALSE);
1087 }
1088
1089 /* Section 4.9.2 */
1090 void CORBA_ORB_perform_work(CORBA_ORB orb, CORBA_Environment *ev)
1091 {
1092 g_assert(!"Not yet implemented");
1093 return;
1094 }
The advantage I see in using something like CORBA is that there is a
easy and well defined way to define interfaces and make RPCs. That ensures
a good evolutionary path as the need for richer communication between
Apache and Tomcat increases. With new-httpd, there is the multi-threading
flexibility as well.
Again, are there any users of mod_corba here that can shed more light?
--
Peace, Anil +<:-)
Re: [Proposal] "Relayed" Apache API Project
Posted by "Anil K. Vijendran" <An...@eng.sun.com>.
On Mon, 31 Jan 2000 Costin.Manolache@eng.sun.com wrote:
> Corba is a huge thing, IIOP is just a simple binary protocol.
> Well, it's not simple - but that's because it support many complex types,
> etc - for our purpose we can just use a subset of IIOP.
Subsets are dangerous unless we can make sure we actually interoperate,
which is possible. Least of all there is value in atleast writing the
Tomcat side of the connector/adapter using the JavaIDL ORB in JDK (1.2).
> Yes, we need a request forwarding and callback protocol - but instead of
> defining an arbitrary encoding and arbitrary message format we can just
> reuse CDR ( strings are sent as legth + bytes - like in AJP ), and we can
> just use the message format of IIOP ( MsgType, magic, version, etc).
We can use the GIOP message format, CDR encoding and add the *IOR* format.
That would make it interoperable.
For this, there's lots of places we can steal code from :-)
--
Peace, Anil +<:-)
Re: [Proposal] "Relayed" Apache API Project
Posted by "Anil K. Vijendran" <An...@eng.sun.com>.
On Mon, 31 Jan 2000 Costin.Manolache@eng.sun.com wrote:
> Corba is a huge thing, IIOP is just a simple binary protocol.
> Well, it's not simple - but that's because it support many complex types,
> etc - for our purpose we can just use a subset of IIOP.
Subsets are dangerous unless we can make sure we actually interoperate,
which is possible. Least of all there is value in atleast writing the
Tomcat side of the connector/adapter using the JavaIDL ORB in JDK (1.2).
> Yes, we need a request forwarding and callback protocol - but instead of
> defining an arbitrary encoding and arbitrary message format we can just
> reuse CDR ( strings are sent as legth + bytes - like in AJP ), and we can
> just use the message format of IIOP ( MsgType, magic, version, etc).
We can use the GIOP message format, CDR encoding and add the *IOR* format.
That would make it interoperable.
For this, there's lots of places we can steal code from :-)
--
Peace, Anil +<:-)
Re: [Proposal] "Relayed" Apache API Project
Posted by co...@eng.sun.com.
> I guess that the question here is what are we looking for, CORBA is good
> when you need to implement a flexible general purpose object interface.
> IMHO this is not such case, I think (and correct me if I am wrong) that
> what we are looking for is a fast request forwarding with callback
> capabiliies...
Corba is a huge thing, IIOP is just a simple binary protocol.
Well, it's not simple - but that's because it support many complex types,
etc - for our purpose we can just use a subset of IIOP.
Yes, we need a request forwarding and callback protocol - but instead of
defining an arbitrary encoding and arbitrary message format we can just
reuse CDR ( strings are sent as legth + bytes - like in AJP ), and we can
just use the message format of IIOP ( MsgType, magic, version, etc).
> So, it seems that using an AJP2.1 based protocol is going to be a much
> simpler and adequate approach.
Agree - but with minimal changes in Ajp2.1 we can use the same encoding
and same message format ( it's not a big difference between what we have
now), and we'll end up with a subset of IIOP ( which hopefully will be
interoperable with real ORBs).
The cost is not so big - but it'll give us a many benefits !
Just take a look at IIOP spec, remove everything that we don't use, and
what remains is almost AJP21.
Costin
Re: [Proposal] "Relayed" Apache API Project
Posted by co...@eng.sun.com.
> I guess that the question here is what are we looking for, CORBA is good
> when you need to implement a flexible general purpose object interface.
> IMHO this is not such case, I think (and correct me if I am wrong) that
> what we are looking for is a fast request forwarding with callback
> capabiliies...
Corba is a huge thing, IIOP is just a simple binary protocol.
Well, it's not simple - but that's because it support many complex types,
etc - for our purpose we can just use a subset of IIOP.
Yes, we need a request forwarding and callback protocol - but instead of
defining an arbitrary encoding and arbitrary message format we can just
reuse CDR ( strings are sent as legth + bytes - like in AJP ), and we can
just use the message format of IIOP ( MsgType, magic, version, etc).
> So, it seems that using an AJP2.1 based protocol is going to be a much
> simpler and adequate approach.
Agree - but with minimal changes in Ajp2.1 we can use the same encoding
and same message format ( it's not a big difference between what we have
now), and we'll end up with a subset of IIOP ( which hopefully will be
interoperable with real ORBs).
The cost is not so big - but it'll give us a many benefits !
Just take a look at IIOP spec, remove everything that we don't use, and
what remains is almost AJP21.
Costin
Re: [Proposal] "Relayed" Apache API Project
Posted by "Anil K. Vijendran" <An...@eng.sun.com>.
On Mon, 31 Jan 2000, Shachor Gal wrote:
> I guess that the question here is what are we looking for, CORBA is good
> when you need to implement a flexible general purpose object interface.
> IMHO this is not such case, I think (and correct me if I am wrong) that
> what we are looking for is a fast request forwarding with callback
> capabiliies...
>
> - We are not going to pass object references...
> - Most of the data is going to be plain strings/integers representing a
> well known value
> - Callbacks should happen at the same thread that initiated the request,
> in CORBA on the other hand due to (good) generalization limits callbacks
> are done in another thread...
>
> We can find more reasons if we will look for them.
>
> So, it seems that using an AJP2.1 based protocol is going to be a much
> simpler and adequate approach.
CORBA is basically an API description system (IDL) and a protocol (IIOP).
This allows you to make arbitrary function calls.
Data you pass can be plain predefined IDL types (integers, strings etc) in
which case it doesn't hurt very much to use IIOP in its simple basic form.
There are atleast two objects -- one on the Apache side and one on the
Tomcat side and these objrefs can either be exchanged as initial
references or using a naming service that comes with any ORB.
I'm not worried about the overkill factor of using CORBA for fast request
forwarding with callback capabilities; what worries me is the
singlethreaded restriction. There is support for singlethreaded invocation
using an event poll and dispatch mechanism. Unfortunately not many people
implement it :-)
Re: [Proposal] "Relayed" Apache API Project
Posted by Shachor Gal <sh...@techunix.technion.ac.il>.
<disclaimer>
I am not considering myself a CORBA guru but
<disclaimer/>
I guess that the question here is what are we looking for, CORBA is good
when you need to implement a flexible general purpose object interface.
IMHO this is not such case, I think (and correct me if I am wrong) that
what we are looking for is a fast request forwarding with callback
capabiliies...
- We are not going to pass object references...
- Most of the data is going to be plain strings/integers representing a
well known value
- Callbacks should happen at the same thread that initiated the request,
in CORBA on the other hand due to (good) generalization limits callbacks
are done in another thread...
We can find more reasons if we will look for them.
So, it seems that using an AJP2.1 based protocol is going to be a much
simpler and adequate approach.
Gal Shachor
On Mon, 31 Jan 2000, Anil K. Vijendran wrote:
> On Mon, 31 Jan 2000 Costin.Manolache@eng.sun.com wrote:
>
> > IIOP is binary :-) Probably too binary, and it support straight TCP/IP (
> > plus unix sockets, etc). I just hate re-inventing the wheel, but I agree
> > IIOP is probably too complex.
>
> I'd like us to consider CORBA, despite its complexity. If we are using
> CORBA, I'm not too sure why we need to be worried about the complexity of
> the IIOP implementation (unless there's a performance issue there).
>
> I have implemented IIOP 1.0/1.1 and various other ORB stuff and I believe
> there is not much intrinsic in the protocol itself that would make it a
> performance bottleneck -- implementations might be screwed up, though.
>
> The advantage of using something like CORBA is that it gives a whole lot
> of freedom -- in terms of languages (API is in IDL), no co-location
> constraints, ample opportunities for local optimizations (I suspect almost
> every ORB does some good short-circuiting for "RPC" between objects that
> are local) etc.
>
> As far as I can remember, the situation with IIOP was pay for what you
> use. If you use the dynamic subsystem (DII/DSI), typecode-based
> marshalling/unmarshalling or recently Objects-by-Value (with fragmentation
> and all that nonsense), then your roundtrip perf could go out the window.
> But all we need it is for simple RPC. In fact given that IIOP is a
> backward compatible protocol; we can just pick some ORB out there that
> just supports 1.0!
>
> One thing I'd like ask around here is: what has the experience been with
> mod_corba and ORBit?
>
>
> --
> Peace, Anil +<:-)
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Re: [Proposal] "Relayed" Apache API Project
Posted by "Anil K. Vijendran" <An...@eng.sun.com>.
On Mon, 31 Jan 2000 Costin.Manolache@eng.sun.com wrote:
> IIOP is binary :-) Probably too binary, and it support straight TCP/IP (
> plus unix sockets, etc). I just hate re-inventing the wheel, but I agree
> IIOP is probably too complex.
I'd like us to consider CORBA, despite its complexity. If we are using
CORBA, I'm not too sure why we need to be worried about the complexity of
the IIOP implementation (unless there's a performance issue there).
I have implemented IIOP 1.0/1.1 and various other ORB stuff and I believe
there is not much intrinsic in the protocol itself that would make it a
performance bottleneck -- implementations might be screwed up, though.
The advantage of using something like CORBA is that it gives a whole lot
of freedom -- in terms of languages (API is in IDL), no co-location
constraints, ample opportunities for local optimizations (I suspect almost
every ORB does some good short-circuiting for "RPC" between objects that
are local) etc.
As far as I can remember, the situation with IIOP was pay for what you
use. If you use the dynamic subsystem (DII/DSI), typecode-based
marshalling/unmarshalling or recently Objects-by-Value (with fragmentation
and all that nonsense), then your roundtrip perf could go out the window.
But all we need it is for simple RPC. In fact given that IIOP is a
backward compatible protocol; we can just pick some ORB out there that
just supports 1.0!
One thing I'd like ask around here is: what has the experience been with
mod_corba and ORBit?
--
Peace, Anil +<:-)
Re: [Proposal] "Relayed" Apache API Project
Posted by "Anil K. Vijendran" <An...@eng.sun.com>.
On Mon, 31 Jan 2000 Costin.Manolache@eng.sun.com wrote:
> IIOP is binary :-) Probably too binary, and it support straight TCP/IP (
> plus unix sockets, etc). I just hate re-inventing the wheel, but I agree
> IIOP is probably too complex.
I'd like us to consider CORBA, despite its complexity. If we are using
CORBA, I'm not too sure why we need to be worried about the complexity of
the IIOP implementation (unless there's a performance issue there).
I have implemented IIOP 1.0/1.1 and various other ORB stuff and I believe
there is not much intrinsic in the protocol itself that would make it a
performance bottleneck -- implementations might be screwed up, though.
The advantage of using something like CORBA is that it gives a whole lot
of freedom -- in terms of languages (API is in IDL), no co-location
constraints, ample opportunities for local optimizations (I suspect almost
every ORB does some good short-circuiting for "RPC" between objects that
are local) etc.
As far as I can remember, the situation with IIOP was pay for what you
use. If you use the dynamic subsystem (DII/DSI), typecode-based
marshalling/unmarshalling or recently Objects-by-Value (with fragmentation
and all that nonsense), then your roundtrip perf could go out the window.
But all we need it is for simple RPC. In fact given that IIOP is a
backward compatible protocol; we can just pick some ORB out there that
just supports 1.0!
One thing I'd like ask around here is: what has the experience been with
mod_corba and ORBit?
--
Peace, Anil +<:-)
Re: [Proposal] "Relayed" Apache API Project
Posted by co...@eng.sun.com.
On Mon, 31 Jan 2000, Assaf Arkin wrote:
> > > Such "Apache relay protocol" server could be either written in C or with
> > > other languages, depending on the needs (i.e. for relayed servlet
> > > engines, mod_relay + mod_java should become a single protocol adapting
> > > layer that drives the servlet engine request/response generation
> > > facility) and should be able to handle multiple connections at once,
> > > keeping them alive for performance reasons.
>
> Makes all the sense in the world. Considering the cost of spawning a JVM
> process, using a TCP/IP relay (or any other IPC mechanism) would work
> better.
First VM is very expensive, next is cheaper.
With Apache 2.0 it's not a problem - and we are talking about future here.
( mod_java is intended for Apache 2.0, and it's just an option you'll
have, the default will still be relay ).
> > > The "Apache Relay Protocol" could be based on existing AJP, or based on
> > > more standard full-duplex protocols such as IIOP or anything else.
>
> I would recommend some binary protocol over IIOP. The module is not
> resuable outside of a small set of servers, so we don't need to cater to
> the fancy of IIOP, RMI, XML, etc. Plus, straight TCP/IP is leaner and
> meaner.
IIOP is binary :-) Probably too binary, and it support straight TCP/IP (
plus unix sockets, etc). I just hate re-inventing the wheel, but I agree
IIOP is probably too complex.
Costin
Re: [Proposal] "Relayed" Apache API Project
Posted by co...@eng.sun.com.
On Mon, 31 Jan 2000, Assaf Arkin wrote:
> > > Such "Apache relay protocol" server could be either written in C or with
> > > other languages, depending on the needs (i.e. for relayed servlet
> > > engines, mod_relay + mod_java should become a single protocol adapting
> > > layer that drives the servlet engine request/response generation
> > > facility) and should be able to handle multiple connections at once,
> > > keeping them alive for performance reasons.
>
> Makes all the sense in the world. Considering the cost of spawning a JVM
> process, using a TCP/IP relay (or any other IPC mechanism) would work
> better.
First VM is very expensive, next is cheaper.
With Apache 2.0 it's not a problem - and we are talking about future here.
( mod_java is intended for Apache 2.0, and it's just an option you'll
have, the default will still be relay ).
> > > The "Apache Relay Protocol" could be based on existing AJP, or based on
> > > more standard full-duplex protocols such as IIOP or anything else.
>
> I would recommend some binary protocol over IIOP. The module is not
> resuable outside of a small set of servers, so we don't need to cater to
> the fancy of IIOP, RMI, XML, etc. Plus, straight TCP/IP is leaner and
> meaner.
IIOP is binary :-) Probably too binary, and it support straight TCP/IP (
plus unix sockets, etc). I just hate re-inventing the wheel, but I agree
IIOP is probably too complex.
Costin
Re: [Proposal] "Relayed" Apache API Project
Posted by Assaf Arkin <ar...@exoffice.com>.
> > Such "Apache relay protocol" server could be either written in C or with
> > other languages, depending on the needs (i.e. for relayed servlet
> > engines, mod_relay + mod_java should become a single protocol adapting
> > layer that drives the servlet engine request/response generation
> > facility) and should be able to handle multiple connections at once,
> > keeping them alive for performance reasons.
Makes all the sense in the world. Considering the cost of spawning a JVM
process, using a TCP/IP relay (or any other IPC mechanism) would work
better.
> > The "Apache Relay Protocol" could be based on existing AJP, or based on
> > more standard full-duplex protocols such as IIOP or anything else.
I would recommend some binary protocol over IIOP. The module is not
resuable outside of a small set of servers, so we don't need to cater to
the fancy of IIOP, RMI, XML, etc. Plus, straight TCP/IP is leaner and
meaner.
arkin
> > Also, it would be nice to provide "flavors" of this mod_relay module for
> > both ISAPI and NSAPI, performing a sort of "Apache emulation" layer than
> > would simplify the adoption of apache projects even on those systems
> > that do not operate the apache web server for a number of reasons. This
> > might help to gain more users since it would simplify transition.
> >
> > Let me know what you think... then we'll decide what to do and where to
> > locate such an effort.
> >
> > --
> > Stefano Mazzocchi One must still have chaos in oneself to be
> > able to give birth to a dancing star.
> > <st...@apache.org> Friedrich Nietzsche
> > --------------------------------------------------------------------
> > Come to the first official Apache Software Foundation Conference!
> > ------------------------- http://ApacheCon.Com ---------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: [Proposal] "Relayed" Apache API Project
Posted by Manoj Kasichainula <ma...@io.com>.
If what we're talking about here is making the Apache HTTP server into
a CORBA object (sorry if my terminology is off here), then I think the
main problem is that the API isn't well defined enough for this.
There's probably still way too much digging by modules into places
that they don't belong, so this would have to be resolved first.
But once this is done, I don't see a mod_relay being difficult. I also
don't see any real barriers to having the wrapper that exports a CORBA
interface be thin and completely separate from the rest of Apache, so
that writing another wrapper that uses XML RPC, or whatever, is easy.
But then again, I know little about CORBA.
BTW, I think Ryan pondered this very idea (while doing mod_cgid) and
had some problems with it as well.
An aside...
On Mon, Jan 31, 2000 at 05:06:58PM +0100, Stefano Mazzocchi wrote:
> > while Apache 2.0 will address the issues regarding embedding a JVM
> > inside the web server with multi-threading
I'm curious what these issues are exactly. Once reason I ask is that
all MPMs might not address these issues. For example, there will be a
single-threaded MPM (or a mode for an MPM, anyway) in Apache 2.0. This
could very well be the prefork MPM, which is essentially the process
management code from 1.3. So, if there's something that you believe
2.0 is solving, I'd like to know what that is, so that I can try and
make sure that this actually gets solved.
Re: [Proposal] "Relayed" Apache API Project
Posted by brian moseley <ix...@maz.org>.
On Tue, 1 Feb 2000, Shachor Gal wrote:
> Costin, other then mime and uri translation, what other
> sub-request services do you think of?
i'd really like tomcat to be able to generate subrequests
and internal redirects, and set up custom error responses.
Re: [Proposal] "Relayed" Apache API Project
Posted by brian moseley <ix...@maz.org>.
On Tue, 1 Feb 2000, Shachor Gal wrote:
> Costin, other then mime and uri translation, what other
> sub-request services do you think of?
i'd really like tomcat to be able to generate subrequests
and internal redirects, and set up custom error responses.
Re: [Proposal] "Relayed" Apache API Project
Posted by Shachor Gal <sh...@techunix.technion.ac.il>.
> My proposal is to separate the discussion it 2 or 3:
1. What API do we want to expose to remote engines ( for example
sub_request but not pool ).
2. What wire protocol should we use ( message format and encoding, CDR
or
XDR or AJP or something else ?)
2 or 3. What communication mechanism - TCP is a clear one, but we want
to
support unix pipes or shared memory or doors.
Lets follow this proposal..
>
> It is not very difficult to make it modular - and probably the best way
to
> start would be to re-use some existing code and then invent new
protocols.
>
True, and we will probably end up with a modular approach.
>
> I think the API is the most difficult and important part, it's a big
> difference between local calls and IPC ( we must expose non-trivial
> calls, etc).
>
True, lets ask ourselves what is worth exposing...
IMO we must be able to provide the following information:
- Apache environment variables
- CGI environment variables
- SSL data
- Initial path translations.
- HTTP data including:
- Headers
- Body
We should also provide the following services/:
- Start response
- Set status
- Set headers
- Log data
- Reject a request (do we really need it)
- Translate path to mime and
- Translate url to path
(this is an initial list and I may have forgot something.)
Note that I am using abstract terms rather then the actual APIs. This is
because I
think that we should not do an RPC call for each api call (for example we
should
not make an RPC callback whenever someone adds header, but instead flush
all
headers when ap_send_http_header(rec) is called). This also makes it
possible to
check and see if the suggested set of APIs can be supported by Netscape
and IIS.
Costin, other then mime and uri translation, what other sub-request
services
do you think of?
>
> 2. What wire protocol should we use ( message format and encoding, CDR
or
> XDR or AJP or something else ?)
>
Gee, here we go again...
- I do not reject to CDR
- We can use the GIOP header as our message header
I think that re-implementing an ORB or just putting one inside the web
server and
Tomcat/Catalina is a good way to kill performance (I am talking from
experience here)
>
> 2 or 3. What communication mechanism - TCP is a clear one, but we want
to
> support unix pipes or shared memory or doors.
>
Unix domain sockets/Pipes/shared memory or doors are all OK, all we need
is a stream
based interface (in any case Unix domain socket/Pipes are all based on
shared memory
so using shared memory + synchronization may not yield improved
performance).
For WinNT (or W2K or whatever) we should also consider Named Pipes.
The WinNT Named Pipes are *not* similar to what happens on UNIX, but they
do provide
a very fast (shared memory based) transport layer.
Gal Shachor
Re: [Proposal] "Relayed" Apache API Project
Posted by Ben Laurie <be...@algroup.co.uk>.
"Daniel L. Rall" wrote:
> What license does ORBit get distributed with and how does it effect me?
>
> The idl compiler is GNU Public licensed (GPL). The libaries are Library
> GPL licensed. The code generated from the idl compiler have no
> restriction. Bascially this means you can use ORBit in
> your own applications (including proprietary applications), the only
> restriction being that people who you distribute your working code to
> must be able to up date the ORBit libraries at will. If you
> wish to modify and distribute the ORBit idl compiler you have to
> distribute that modification under the GPL.
Aha. That sounds compatible to me.
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
Y19100 no-prize winner!
http://www.ntk.net/index.cgi?back=2000/now0121.txt
Re: [Proposal] "Relayed" Apache API Project
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
> I know almost nothing about Corba so I can't really say anything here.
> But if we remove all the Corba-ish stuff from the orb and use IIOP like
> we use AJP today, I don't think it's a huge issue.
ORBit is a possiblity for an Object Request Broker.
Homepage:
http://www.labs.redhat.com/orbit/
Beginner's Documentation:
http://icps.u-strasbg.fr/~genaud/ORBIT/c41.htm
Except (rather long, sorry):
What is ORBit?
ORBit is an implementation of CORBA, which is used (amongst other
things) in the GNOME project.
Why aren't you using ILU/MICO/TAO?
Most of GNOME is written in C, both for performance reasons, and because
C++ still isn't as portable and widely available. So integration with
CORBA should use the IDL C mapping, which
rules out TAO and MICO. ILU was ruled out because the license appeared
as too restrictive at the time for free software.
Is ORBit stable?
ORBit is used in pretty much any GNOME application, which gives quite
some testing for the features used. Other features have seen little or
no testing.
Does ORBit work with other ORBs?
Yes. This is one of the primary features of CORBA, and available through
the Internet Inter-ORB Protocol (IIOP). There is one pitfall: ORBit has
a proprietary security mechanism to
authenticate clients. If interoperability is desired then you might have
to figure out a work around for this
What license does ORBit get distributed with and how does it effect me?
The idl compiler is GNU Public licensed (GPL). The libaries are Library
GPL licensed. The code generated from the idl compiler have no
restriction. Bascially this means you can use ORBit in
your own applications (including proprietary applications), the only
restriction being that people who you distribute your working code to
must be able to up date the ORBit libraries at will. If you
wish to modify and distribute the ORBit idl compiler you have to
distribute that modification under the GPL.
--
Daniel L. Rall (dlr@finemaltcoding.com)
Re: [Proposal] "Relayed" Apache API Project
Posted by Stefano Mazzocchi <st...@apache.org>.
"Anil K. Vijendran" wrote:
>
> Ben Laurie wrote:
>
> > But isn't that the huge attraction of CORBA? I define the API and the
> > wire is handled for me? Also, I get cross-language compatibility, as
> > well as cross-platform.
>
> Yep, right on. Using IDL and IIOP also lets us evolve the Apache-Tomcat
> communication much more easily. But its not so simple.
>
> * We need to find a free C ORB out there with an acceptable license.
I just spent three days in germany consulting a company that has written
a huge software system for distributed device-independent information
systems all based on CORBA and open source software. They are using MICO
and they say it's pretty clean and solid.
But, quoting them, they easily scale "up", not so easily scale "down".
True, the deal of module relaying is about scalability and separation,
but imposing basic CORBA knowledge and installation for simply having
jserv on another process on the same machine is a little too much for
me.
Question: is there a way we can use both? I mean: if we use IIOP as a
wire protocol, we could write tomcat to _appear_ as a orb, a really
simple one, of course. Or, in case a real ORB is in place, tomcat will
just become a service for that.
We get the best of both worlds: if you have a CORBA environment, tomcat
and apache fit it, otherwise, this mod_relay (now mod_corba??) just
connects directly with tomcat and no other configurations or things like
that.
> * We need to find one that supports single threaded dispatches of
> callbacks -- this can be overcome by writing our own small ORB.
Yes, if we do this "inside" the other side of the wire, we win.
> * We need to find Java ORB that'll work -- there's one in JDK 1.2 but
> that's another debate -- can we move totally into JDK 1.2? (I can
> comfortably say its an hr's job to get it running on 1.1.x but there's
> the licensing nightmares associated with it.)
I know almost nothing about Corba so I can't really say anything here.
But if we remove all the Corba-ish stuff from the orb and use IIOP like
we use AJP today, I don't think it's a huge issue.
Thoughts?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: [Proposal] "Relayed" Apache API Project
Posted by Stefano Mazzocchi <st...@apache.org>.
"Anil K. Vijendran" wrote:
>
> Ben Laurie wrote:
>
> > But isn't that the huge attraction of CORBA? I define the API and the
> > wire is handled for me? Also, I get cross-language compatibility, as
> > well as cross-platform.
>
> Yep, right on. Using IDL and IIOP also lets us evolve the Apache-Tomcat
> communication much more easily. But its not so simple.
>
> * We need to find a free C ORB out there with an acceptable license.
I just spent three days in germany consulting a company that has written
a huge software system for distributed device-independent information
systems all based on CORBA and open source software. They are using MICO
and they say it's pretty clean and solid.
But, quoting them, they easily scale "up", not so easily scale "down".
True, the deal of module relaying is about scalability and separation,
but imposing basic CORBA knowledge and installation for simply having
jserv on another process on the same machine is a little too much for
me.
Question: is there a way we can use both? I mean: if we use IIOP as a
wire protocol, we could write tomcat to _appear_ as a orb, a really
simple one, of course. Or, in case a real ORB is in place, tomcat will
just become a service for that.
We get the best of both worlds: if you have a CORBA environment, tomcat
and apache fit it, otherwise, this mod_relay (now mod_corba??) just
connects directly with tomcat and no other configurations or things like
that.
> * We need to find one that supports single threaded dispatches of
> callbacks -- this can be overcome by writing our own small ORB.
Yes, if we do this "inside" the other side of the wire, we win.
> * We need to find Java ORB that'll work -- there's one in JDK 1.2 but
> that's another debate -- can we move totally into JDK 1.2? (I can
> comfortably say its an hr's job to get it running on 1.1.x but there's
> the licensing nightmares associated with it.)
I know almost nothing about Corba so I can't really say anything here.
But if we remove all the Corba-ish stuff from the orb and use IIOP like
we use AJP today, I don't think it's a huge issue.
Thoughts?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: [Proposal] "Relayed" Apache API Project
Posted by "Anil K. Vijendran" <An...@eng.sun.com>.
Ben Laurie wrote:
> But isn't that the huge attraction of CORBA? I define the API and the
> wire is handled for me? Also, I get cross-language compatibility, as
> well as cross-platform.
Yep, right on. Using IDL and IIOP also lets us evolve the Apache-Tomcat
communication much more easily. But its not so simple.
* We need to find a free C ORB out there with an acceptable license.
* We need to find one that supports single threaded dispatches of
callbacks -- this can be overcome by writing our own small ORB.
* We need to find Java ORB that'll work -- there's one in JDK 1.2 but
that's another debate -- can we move totally into JDK 1.2? (I can
comfortably say its an hr's job to get it running on 1.1.x but there's
the licensing nightmares associated with it.)
> Cheers,
>
> Ben.
--
Peace, Anil +<:-)
Re: [Proposal] "Relayed" Apache API Project
Posted by Costin Manolache <Co...@eng.sun.com>.
> > My proposal is to separate the discussion it 2 or 3:
> >
> > 1. What API do we want to expose to remote engines ( for example
> > sub_request but not pool ).
> >
> > 2. What wire protocol should we use ( message format and encoding, CDR or
> > XDR or AJP or something else ?)
> >
> > 2 or 3. What communication mechanism - TCP is a clear one, but we want to
> > support unix pipes or shared memory or doors.
> >
> > It is not very difficult to make it modular - and probably the best way to
> > start would be to re-use some existing code and then invent new protocols.
> >
> > I think the API is the most difficult and important part, it's a big
> > difference between local calls and IPC ( we must expose non-trivial
> > calls, etc).
>
> But isn't that the huge attraction of CORBA? I define the API and the
> wire is handled for me? Also, I get cross-language compatibility, as
> well as cross-platform.
Yes, we should use something out of CORBA - at least the ideea of defining
the API independent of wire protocol.
Full Corba may be a bad ideea - it is big, complex, will have problems
with Apache thread model and I don't know any Apache-license-compatible
ORBs. But using some IIOP _ideas_ is not bad at all - the CDR encoding is
not much worse than AJP, and the wire protocol is not much worse than AJP.
If we use CDR and the wire protocol it will not be very hard to make our
protocol interoperable with a real ORB ( and save a lot of programming
on the other side ), and it's good to use some standards instead of defining
new one.( assuming CDR and basic GIOP are not too heavy - I really don't
think this is the case).
Costin
Re: [Proposal] "Relayed" Apache API Project
Posted by "Anil K. Vijendran" <An...@eng.sun.com>.
Ben Laurie wrote:
> But isn't that the huge attraction of CORBA? I define the API and the
> wire is handled for me? Also, I get cross-language compatibility, as
> well as cross-platform.
Yep, right on. Using IDL and IIOP also lets us evolve the Apache-Tomcat
communication much more easily. But its not so simple.
* We need to find a free C ORB out there with an acceptable license.
* We need to find one that supports single threaded dispatches of
callbacks -- this can be overcome by writing our own small ORB.
* We need to find Java ORB that'll work -- there's one in JDK 1.2 but
that's another debate -- can we move totally into JDK 1.2? (I can
comfortably say its an hr's job to get it running on 1.1.x but there's
the licensing nightmares associated with it.)
> Cheers,
>
> Ben.
--
Peace, Anil +<:-)
Re: [Proposal] "Relayed" Apache API Project
Posted by Ben Laurie <be...@algroup.co.uk>.
costin@eng.sun.com wrote:
>
> > > Such "Apache relay protocol" server could be either written in C or with
> > > other languages, depending on the needs (i.e. for relayed servlet
> > > engines, mod_relay + mod_java should become a single protocol adapting
> > > layer that drives the servlet engine request/response generation
> > > facility) and should be able to handle multiple connections at once,
> > > keeping them alive for performance reasons.
> > >
> > > The "Apache Relay Protocol" could be based on existing AJP, or based on
> > > more standard full-duplex protocols such as IIOP or anything else.
>
> My proposal is to separate the discussion it 2 or 3:
>
> 1. What API do we want to expose to remote engines ( for example
> sub_request but not pool ).
>
> 2. What wire protocol should we use ( message format and encoding, CDR or
> XDR or AJP or something else ?)
>
> 2 or 3. What communication mechanism - TCP is a clear one, but we want to
> support unix pipes or shared memory or doors.
>
> It is not very difficult to make it modular - and probably the best way to
> start would be to re-use some existing code and then invent new protocols.
>
> I think the API is the most difficult and important part, it's a big
> difference between local calls and IPC ( we must expose non-trivial
> calls, etc).
But isn't that the huge attraction of CORBA? I define the API and the
wire is handled for me? Also, I get cross-language compatibility, as
well as cross-platform.
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
Y19100 no-prize winner!
http://www.ntk.net/index.cgi?back=2000/now0121.txt
Re: [Proposal] "Relayed" Apache API Project
Posted by Ben Laurie <be...@algroup.co.uk>.
costin@eng.sun.com wrote:
>
> > > Such "Apache relay protocol" server could be either written in C or with
> > > other languages, depending on the needs (i.e. for relayed servlet
> > > engines, mod_relay + mod_java should become a single protocol adapting
> > > layer that drives the servlet engine request/response generation
> > > facility) and should be able to handle multiple connections at once,
> > > keeping them alive for performance reasons.
> > >
> > > The "Apache Relay Protocol" could be based on existing AJP, or based on
> > > more standard full-duplex protocols such as IIOP or anything else.
>
> My proposal is to separate the discussion it 2 or 3:
>
> 1. What API do we want to expose to remote engines ( for example
> sub_request but not pool ).
>
> 2. What wire protocol should we use ( message format and encoding, CDR or
> XDR or AJP or something else ?)
>
> 2 or 3. What communication mechanism - TCP is a clear one, but we want to
> support unix pipes or shared memory or doors.
>
> It is not very difficult to make it modular - and probably the best way to
> start would be to re-use some existing code and then invent new protocols.
>
> I think the API is the most difficult and important part, it's a big
> difference between local calls and IPC ( we must expose non-trivial
> calls, etc).
But isn't that the huge attraction of CORBA? I define the API and the
wire is handled for me? Also, I get cross-language compatibility, as
well as cross-platform.
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
Y19100 no-prize winner!
http://www.ntk.net/index.cgi?back=2000/now0121.txt
Re: [Proposal] "Relayed" Apache API Project
Posted by co...@eng.sun.com.
> > Such "Apache relay protocol" server could be either written in C or with
> > other languages, depending on the needs (i.e. for relayed servlet
> > engines, mod_relay + mod_java should become a single protocol adapting
> > layer that drives the servlet engine request/response generation
> > facility) and should be able to handle multiple connections at once,
> > keeping them alive for performance reasons.
> >
> > The "Apache Relay Protocol" could be based on existing AJP, or based on
> > more standard full-duplex protocols such as IIOP or anything else.
My proposal is to separate the discussion it 2 or 3:
1. What API do we want to expose to remote engines ( for example
sub_request but not pool ).
2. What wire protocol should we use ( message format and encoding, CDR or
XDR or AJP or something else ?)
2 or 3. What communication mechanism - TCP is a clear one, but we want to
support unix pipes or shared memory or doors.
It is not very difficult to make it modular - and probably the best way to
start would be to re-use some existing code and then invent new protocols.
I think the API is the most difficult and important part, it's a big
difference between local calls and IPC ( we must expose non-trivial
calls, etc).
Costin
Re: [Proposal] "Relayed" Apache API Project
Posted by co...@eng.sun.com.
> > Such "Apache relay protocol" server could be either written in C or with
> > other languages, depending on the needs (i.e. for relayed servlet
> > engines, mod_relay + mod_java should become a single protocol adapting
> > layer that drives the servlet engine request/response generation
> > facility) and should be able to handle multiple connections at once,
> > keeping them alive for performance reasons.
> >
> > The "Apache Relay Protocol" could be based on existing AJP, or based on
> > more standard full-duplex protocols such as IIOP or anything else.
My proposal is to separate the discussion it 2 or 3:
1. What API do we want to expose to remote engines ( for example
sub_request but not pool ).
2. What wire protocol should we use ( message format and encoding, CDR or
XDR or AJP or something else ?)
2 or 3. What communication mechanism - TCP is a clear one, but we want to
support unix pipes or shared memory or doors.
It is not very difficult to make it modular - and probably the best way to
start would be to re-use some existing code and then invent new protocols.
I think the API is the most difficult and important part, it's a big
difference between local calls and IPC ( we must expose non-trivial
calls, etc).
Costin
Re: [Proposal] "Relayed" Apache API Project
Posted by Shachor Gal <sh...@techunix.technion.ac.il>.
> > On the other hand, it is evident that such requirements of "relayed"
> > operation are shared by many projects, most notably those regarding the
> > need for JVMs, but I think others might find this useful for other
> > projects (mod_perl? mod_php? you tell me)
Is there such requirement on other project (seems like should be)?
> >
> > Such apache module, should make transparently available the Apache APIs
> > the other side of a connection (either TCP/IP based, or any other
> > ordered stream connection).
> >
We need to define the meaning of "Apache APIs" in the context of this
proposal, I assume that what you call APIs are the Apache APIs for
handling request/response and translating path-mime and uri-path.
> >
> > both of which, of course, requires the JVM to reside on the same web
> > server process connected thru a JNI interface. This is, of course, the
> > fastest way of doing it, no matter what, but may not feed all needs
> > (expecially now that you have to spawn a new JVM for every process you
> > have. Note: a JVM (java virtual machine) is a very heavy process, even
> > if more modern JVMs can share memory resources if more than one is
> > executed on the same system, but don't ask me how this is done or how
> > portable this is!).
> >
Embedding a JVM in the web server is not allays a good idea. Embedding it
just for the sake of sending messages is a no no!!! Most web servers can
not afford that (unless you are using that explicitly for an in process
servlet engine).
> > On the other hand, if we want the web server and JVM to reside on
> > different machines (or on totally isolated processes on the same
> > machine), we need something like
> >
> > apache <-> mod_relay <====> mod_relay <-> mod_java <-> servlet engine
> >
> > where "<====>" indicates an ordered stream full-duplex connection
> > (pipes? tcp/ip? you name it).
> >
> > Such "Apache relay protocol" server could be either written in C or with
> > other languages, depending on the needs (i.e. for relayed servlet
> > engines, mod_relay + mod_java should become a single protocol adapting
> > layer that drives the servlet engine request/response generation
> > facility) and should be able to handle multiple connections at once,
> > keeping them alive for performance reasons.
> >
This is probably the way to go.
> > The "Apache Relay Protocol" could be based on existing AJP, or based on
> > more standard full-duplex protocols such as IIOP or anything else.
> >
IIOP is too generalized, to heavy... if someone wants to see what does
dispatching HTTP requests with IIOP means he can use Netscapes WAI... The
response time really sucks (IMHO).
> > Also, it would be nice to provide "flavors" of this mod_relay module for
> > both ISAPI and NSAPI, performing a sort of "Apache emulation" layer than
> > would simplify the adoption of apache projects even on those systems
> > that do not operate the apache web server for a number of reasons. This
> > might help to gain more users since it would simplify transition.
> >
Again, we need to restrict the set of APIs to something that can be done
for these servers too. Request/Response and Mime/Path translations can be
implemented with these servers too.
Gal Shachor
> > Let me know what you think... then we'll decide what to do and where to
> > locate such an effort.
> >
> > --
> > Stefano Mazzocchi One must still have chaos in oneself to be
> > able to give birth to a dancing star.
> > <st...@apache.org> Friedrich Nietzsche
> > --------------------------------------------------------------------
> > Come to the first official Apache Software Foundation Conference!
> > ------------------------- http://ApacheCon.Com ---------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>