You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2005/09/06 04:32:05 UTC
How do we ship jetty and tomcat versions? Please respond
As part of my work on breaking up our monolithic configuration into
smaller pieces, I now have a set of configurations that modularize
jetty and tomcat into two configurations each. These can be turned on
and off individually, by means of starting with different config.list
files or by an appropriate command line. It is equally easy to run
both at once if you arrange the ports to avoid collisions.
I'm planning on cleaning this up a bit more and committing it soon
(maybe tonight). If you don't like this idea please speak up soon.
I wrote a namespace-driven switching module builder to determine if the
jetty or tomcat builder is used. It has a defaultNamespace option
which is what currently determines the target. The module builders
register themselves with the switch and supply their namespace.
I would like to:
-- keep the current geronimo-web.xsd with its "any" based deployer
specific configuration bits
--write jetty and tomcat specific schemas that include the deployer
specific configuration directly
In this way, if you know which your target environment is, you can
write in that schema and the correct deployer will be selected
automatically. If you don't, the choice of target environment will
come from the defaultNamespace setting in the switch.
The remaining nasty point is the offline deployer, which currently
includes both the jetty and tomcat builders. I have not found a way to
configure the offline deployer to start more than one configuration, so
I have been forced to include everything in the j2ee-deployer-plan.xml.
I think we should consider if we have progressed far enough to
eliminate the offline deployer as a separate configuration and always
use the runtime deployer configs both online and offline. There are
still some classloader issues I don't understand well enough for me to
try this right now.
So, in more detail, I propose we ship:
-all the configurations, for both jetty and tomcat, installed
- 3 pairs of config.list and config.xml files that run both, only
jetty, and only tomcat
- both containers and builders running by default.
- installer stuff that lets you pick which option you want installed.
thanks
david jencks
Re: How do we ship jetty and tomcat versions? Please respond
Posted by Jeremy Boynes <jb...@apache.org>.
Jeff Genender wrote:
> I like what you have done here. Very nice work.
>
> However, IMHO, I would be concerned in the long run of shipping Jetty
> and Tomcat together. We will be accused of being too "heavy weight".
> Then also, where do we draw the line of shipping everything (ie.
> multiple orbs, and multiple EB containers, etc).
>
I would hope that in that time frame we have a more modular distribution
mechanism that allows people to download their choice of components - a
bit like the way most Linux distros work.
It's not just basic functions like web or EJB containers, but also
higher level components such as clustering, directory, JBI, portal, etc.
All of these have the potential to bloat the footprint and we need to be
diligent about what really is core and what is add-on.
I think David's work here is a major step in the right direction as it
sets up the framework for this kind of modular structure. Thanks.
--
Jeremy
RE: How do we ship jetty and tomcat versions? Please respond
Posted by Jeff Genender <jg...@savoirtech.com>.
> well... we are already shipping all the tomcat and jetty jars
> together no matter which one is activated. Shipping both
> configurations as well doesn't add much bulk.
True, and I am aware of this, but I hope this is a short term thing. I
would hope that down the road, we won't be shipping everything. IMHO, a
300MB download due to the fact that we have everything in it would not be a
good thing (no its not 300MB now, but as we expand our offerings, it easily
can be). I would love to see where you click on what you want...then boot
strap a download, and it builds an appserver for you by getting only the
necessary files.
So yes, I agree, right now, there is no harm done...and it's a definate step
in the right direction.
Jeff
Re: How do we ship jetty and tomcat versions? Please respond
Posted by David Jencks <da...@yahoo.com>.
On Sep 5, 2005, at 9:38 PM, Jeff Genender wrote:
> I like what you have done here. Very nice work.
thanks :-)
>
> However, IMHO, I would be concerned in the long run of shipping Jetty
> and Tomcat together. We will be accused of being too "heavy weight".
> Then also, where do we draw the line of shipping everything (ie.
> multiple orbs, and multiple EB containers, etc).
well... we are already shipping all the tomcat and jetty jars together
no matter which one is activated. Shipping both configurations as well
doesn't add much bulk. I think using something like the assembly
plugin to build a server is a more plausible way to assemble a
limited-functionality version.
thanks
david jencks
>
> Jeff
>
> David Jencks wrote:
>> As part of my work on breaking up our monolithic configuration into
>> smaller pieces, I now have a set of configurations that modularize
>> jetty and tomcat into two configurations each. These can be turned
>> on and off individually, by means of starting with different
>> config.list files or by an appropriate command line. It is equally
>> easy to run both at once if you arrange the ports to avoid
>> collisions.
>> I'm planning on cleaning this up a bit more and committing it soon
>> (maybe tonight). If you don't like this idea please speak up soon.
>> I wrote a namespace-driven switching module builder to determine if
>> the jetty or tomcat builder is used. It has a defaultNamespace
>> option which is what currently determines the target. The module
>> builders register themselves with the switch and supply their
>> namespace.
>> I would like to:
>> -- keep the current geronimo-web.xsd with its "any" based deployer
>> specific configuration bits
>> --write jetty and tomcat specific schemas that include the deployer
>> specific configuration directly
>> In this way, if you know which your target environment is, you can
>> write in that schema and the correct deployer will be selected
>> automatically. If you don't, the choice of target environment will
>> come from the defaultNamespace setting in the switch.
>> The remaining nasty point is the offline deployer, which currently
>> includes both the jetty and tomcat builders. I have not found a way
>> to configure the offline deployer to start more than one
>> configuration, so I have been forced to include everything in the
>> j2ee-deployer-plan.xml. I think we should consider if we have
>> progressed far enough to eliminate the offline deployer as a separate
>> configuration and always use the runtime deployer configs both online
>> and offline. There are still some classloader issues I don't
>> understand well enough for me to try this right now.
>> So, in more detail, I propose we ship:
>> -all the configurations, for both jetty and tomcat, installed
>> - 3 pairs of config.list and config.xml files that run both, only
>> jetty, and only tomcat
>> - both containers and builders running by default.
>> - installer stuff that lets you pick which option you want installed.
>> thanks
>> david jencks
>
Re: How do we ship jetty and tomcat versions? Please respond
Posted by Jeff Genender <jg...@savoirtech.com>.
Geir Magnusson Jr. wrote:
>
> On Sep 6, 2005, at 12:38 AM, Jeff Genender wrote:
>
>> I like what you have done here. Very nice work.
>>
>> However, IMHO, I would be concerned in the long run of shipping Jetty
>> and Tomcat together. We will be accused of being too "heavy weight".
>> Then also, where do we draw the line of shipping everything (ie.
>> multiple orbs, and multiple EB containers, etc).
>
>
> How about to distinct distributions, one w/ Tomcat and one w/ Jetty?
> That might make it clearer and easier for users, as well as let us know
> what's popular by download count.
+1...I think this is what people will be expecting.
>
> As for the multiple orbs, multiple EJBs, etc, I think that depends on
> if there is a demand and if someone steps up to do the work? I'm not
> sure if we have enough info yet, as we only have this issue w/ the web
> tier.
>
> geir
>
>>
>> Jeff
>>
>> David Jencks wrote:
>>
>>> As part of my work on breaking up our monolithic configuration into
>>> smaller pieces, I now have a set of configurations that modularize
>>> jetty and tomcat into two configurations each. These can be turned
>>> on and off individually, by means of starting with different
>>> config.list files or by an appropriate command line. It is equally
>>> easy to run both at once if you arrange the ports to avoid collisions.
>>> I'm planning on cleaning this up a bit more and committing it soon
>>> (maybe tonight). If you don't like this idea please speak up soon.
>>> I wrote a namespace-driven switching module builder to determine if
>>> the jetty or tomcat builder is used. It has a defaultNamespace
>>> option which is what currently determines the target. The module
>>> builders register themselves with the switch and supply their
>>> namespace.
>>> I would like to:
>>> -- keep the current geronimo-web.xsd with its "any" based deployer
>>> specific configuration bits
>>> --write jetty and tomcat specific schemas that include the deployer
>>> specific configuration directly
>>> In this way, if you know which your target environment is, you can
>>> write in that schema and the correct deployer will be selected
>>> automatically. If you don't, the choice of target environment will
>>> come from the defaultNamespace setting in the switch.
>>> The remaining nasty point is the offline deployer, which currently
>>> includes both the jetty and tomcat builders. I have not found a way
>>> to configure the offline deployer to start more than one
>>> configuration, so I have been forced to include everything in the
>>> j2ee-deployer-plan.xml. I think we should consider if we have
>>> progressed far enough to eliminate the offline deployer as a
>>> separate configuration and always use the runtime deployer configs
>>> both online and offline. There are still some classloader issues I
>>> don't understand well enough for me to try this right now.
>>> So, in more detail, I propose we ship:
>>> -all the configurations, for both jetty and tomcat, installed
>>> - 3 pairs of config.list and config.xml files that run both, only
>>> jetty, and only tomcat
>>> - both containers and builders running by default.
>>> - installer stuff that lets you pick which option you want installed.
>>> thanks
>>> david jencks
>>>
>>
>>
>
Re: How do we ship jetty and tomcat versions? Please respond
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Sep 6, 2005, at 12:38 AM, Jeff Genender wrote:
> I like what you have done here. Very nice work.
>
> However, IMHO, I would be concerned in the long run of shipping
> Jetty and Tomcat together. We will be accused of being too "heavy
> weight". Then also, where do we draw the line of shipping
> everything (ie. multiple orbs, and multiple EB containers, etc).
How about to distinct distributions, one w/ Tomcat and one w/ Jetty?
That might make it clearer and easier for users, as well as let us
know what's popular by download count.
As for the multiple orbs, multiple EJBs, etc, I think that depends on
if there is a demand and if someone steps up to do the work? I'm not
sure if we have enough info yet, as we only have this issue w/ the
web tier.
geir
>
> Jeff
>
> David Jencks wrote:
>
>> As part of my work on breaking up our monolithic configuration
>> into smaller pieces, I now have a set of configurations that
>> modularize jetty and tomcat into two configurations each. These
>> can be turned on and off individually, by means of starting with
>> different config.list files or by an appropriate command line. It
>> is equally easy to run both at once if you arrange the ports to
>> avoid collisions.
>> I'm planning on cleaning this up a bit more and committing it
>> soon (maybe tonight). If you don't like this idea please speak
>> up soon.
>> I wrote a namespace-driven switching module builder to determine
>> if the jetty or tomcat builder is used. It has a
>> defaultNamespace option which is what currently determines the
>> target. The module builders register themselves with the switch
>> and supply their namespace.
>> I would like to:
>> -- keep the current geronimo-web.xsd with its "any" based deployer
>> specific configuration bits
>> --write jetty and tomcat specific schemas that include the
>> deployer specific configuration directly
>> In this way, if you know which your target environment is, you can
>> write in that schema and the correct deployer will be selected
>> automatically. If you don't, the choice of target environment
>> will come from the defaultNamespace setting in the switch.
>> The remaining nasty point is the offline deployer, which currently
>> includes both the jetty and tomcat builders. I have not found a
>> way to configure the offline deployer to start more than one
>> configuration, so I have been forced to include everything in the
>> j2ee-deployer-plan.xml. I think we should consider if we have
>> progressed far enough to eliminate the offline deployer as a
>> separate configuration and always use the runtime deployer configs
>> both online and offline. There are still some classloader issues
>> I don't understand well enough for me to try this right now.
>> So, in more detail, I propose we ship:
>> -all the configurations, for both jetty and tomcat, installed
>> - 3 pairs of config.list and config.xml files that run both, only
>> jetty, and only tomcat
>> - both containers and builders running by default.
>> - installer stuff that lets you pick which option you want installed.
>> thanks
>> david jencks
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: How do we ship jetty and tomcat versions? Please respond
Posted by Jeff Genender <jg...@savoirtech.com>.
I like what you have done here. Very nice work.
However, IMHO, I would be concerned in the long run of shipping Jetty
and Tomcat together. We will be accused of being too "heavy weight".
Then also, where do we draw the line of shipping everything (ie.
multiple orbs, and multiple EB containers, etc).
Jeff
David Jencks wrote:
> As part of my work on breaking up our monolithic configuration into
> smaller pieces, I now have a set of configurations that modularize jetty
> and tomcat into two configurations each. These can be turned on and off
> individually, by means of starting with different config.list files or
> by an appropriate command line. It is equally easy to run both at once
> if you arrange the ports to avoid collisions.
>
> I'm planning on cleaning this up a bit more and committing it soon
> (maybe tonight). If you don't like this idea please speak up soon.
>
> I wrote a namespace-driven switching module builder to determine if the
> jetty or tomcat builder is used. It has a defaultNamespace option
> which is what currently determines the target. The module builders
> register themselves with the switch and supply their namespace.
>
> I would like to:
> -- keep the current geronimo-web.xsd with its "any" based deployer
> specific configuration bits
> --write jetty and tomcat specific schemas that include the deployer
> specific configuration directly
>
> In this way, if you know which your target environment is, you can write
> in that schema and the correct deployer will be selected automatically.
> If you don't, the choice of target environment will come from the
> defaultNamespace setting in the switch.
>
> The remaining nasty point is the offline deployer, which currently
> includes both the jetty and tomcat builders. I have not found a way to
> configure the offline deployer to start more than one configuration, so
> I have been forced to include everything in the j2ee-deployer-plan.xml.
> I think we should consider if we have progressed far enough to
> eliminate the offline deployer as a separate configuration and always
> use the runtime deployer configs both online and offline. There are
> still some classloader issues I don't understand well enough for me to
> try this right now.
>
> So, in more detail, I propose we ship:
>
> -all the configurations, for both jetty and tomcat, installed
> - 3 pairs of config.list and config.xml files that run both, only jetty,
> and only tomcat
> - both containers and builders running by default.
> - installer stuff that lets you pick which option you want installed.
>
> thanks
> david jencks
RE: How do we ship jetty and tomcat versions? Please respond
Posted by Jeff Genender <jg...@savoirtech.com>.
> -----Original Message-----
> From: Joe Bohn [mailto:joe.bohn@earthlink.net]
> Sent: Tuesday, September 06, 2005 7:27 AM
> To: dev@geronimo.apache.org
> Subject: Re: How do we ship jetty and tomcat versions? Please respond
>
> I too am confused about the use case scenario that would
> drive this?
> Also, can we be more specific on the level of granularity
> that is being considered here? Would it be just: 1 tomcat
> container, 1 jetty
> container, both a single tomcat and a single jetty container?
> Or is it
> also being considered that we would support multiple tomcat
> containers and multiple jetty containers (possibly even at
> different container versions).
In theory, right now, you could easily have multiples of a single Tomcat
version by declaring the necessary Gbeans. However, having multiple
versions of the same appserver would be a bit more tough due to clashes in
the classes, and would likely need some serious classloader work.
However, the simple fact of having multiple containers is difficult at best.
We all forget that the EJB containers can only have a single listener for
the web services, so even if we do run multiple containers, only one will be
able to support ejb endpoints (that is unless we duplicate the OpenEJB
configs - and I don't know the implications of this).
>
>
> Do any other application servers support multiple concurrent
> web containers?
>
>
> If it is decided that this is a valid scenario, then the
> implications of
> this would ripple throughout the code. This is especially
> problematic
> for the web console where we would have to visually keep track of
> multiple containers, applications, connections, etc.. active on each
> container, logs associated with each container, configuration
> attributes
> of each container, etc... But I think this approach would have
> significant implications for other components as well, including 3rd
> party software that might need to interact with our server (such as
> external management applications using JMX).
Yep...IMHO, you are correct on this.
>
> Joe
>
>
> Jacek Laskowski wrote:
>
> > David Jencks wrote:
> >
> > ...
> >
> >> I wrote a namespace-driven switching module builder to
> determine if
> >> the jetty or tomcat builder is used. It has a defaultNamespace
> >> option which is what currently determines the target. The module
> >> builders register themselves with the switch and supply
> their namespace.
> >
> > ...
> >
> >> So, in more detail, I propose we ship:
> >>
> >> -all the configurations, for both jetty and tomcat, installed
> >> - 3 pairs of config.list and config.xml files that run both, only
> >> jetty, and only tomcat
> >> - both containers and builders running by default.
> >
> >
> > Hi Dave,
> >
> > Both, by default? Interesting. Will there be a way in your
> proposal to
> > deploy a WAR to *both* containers? Since the
> defaultNamespace option
> > is to drive what container a WAR is deployed to I think the
> answer is
> > negative, isn't it? (or alternatively it could assume that no
> > defaultNamespace would mean both) If so, why would a user
> want to run
> > Jetty and Tomcat? I don't mind having two containers and builders
> > running at the same time, but wonder if there's a user case
> for it (a
> > web hosting provider?).
> >
> >> david jencks
> >
> >
> > Jacek
> >
> >
>
> --
> Joe Bohn
> joe.bohn@earthlink.net
>
> "He is no fool who gives what he cannot keep, to gain what he
> cannot lose." -- Jim Elliot
>
Re: How do we ship jetty and tomcat versions? Please respond
Posted by Joe Bohn <jo...@earthlink.net>.
I too am confused about the use case scenario that would drive this?
Also, can we be more specific on the level of granularity that is being
considered here? Would it be just: 1 tomcat container, 1 jetty
container, both a single tomcat and a single jetty container? Or is it
also being considered that we would support multiple tomcat containers
and multiple jetty containers (possibly even at different container
versions).
Do any other application servers support multiple concurrent web
containers?
If it is decided that this is a valid scenario, then the implications of
this would ripple throughout the code. This is especially problematic
for the web console where we would have to visually keep track of
multiple containers, applications, connections, etc.. active on each
container, logs associated with each container, configuration attributes
of each container, etc... But I think this approach would have
significant implications for other components as well, including 3rd
party software that might need to interact with our server (such as
external management applications using JMX).
Joe
Jacek Laskowski wrote:
> David Jencks wrote:
>
> ...
>
>> I wrote a namespace-driven switching module builder to determine if
>> the jetty or tomcat builder is used. It has a defaultNamespace
>> option which is what currently determines the target. The module
>> builders register themselves with the switch and supply their namespace.
>
> ...
>
>> So, in more detail, I propose we ship:
>>
>> -all the configurations, for both jetty and tomcat, installed
>> - 3 pairs of config.list and config.xml files that run both, only
>> jetty, and only tomcat
>> - both containers and builders running by default.
>
>
> Hi Dave,
>
> Both, by default? Interesting. Will there be a way in your proposal to
> deploy a WAR to *both* containers? Since the defaultNamespace option
> is to drive what container a WAR is deployed to I think the answer is
> negative, isn't it? (or alternatively it could assume that no
> defaultNamespace would mean both) If so, why would a user want to run
> Jetty and Tomcat? I don't mind having two containers and builders
> running at the same time, but wonder if there's a user case for it (a
> web hosting provider?).
>
>> david jencks
>
>
> Jacek
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
RE: How do we ship jetty and tomcat versions? Please respond
Posted by Jeff Genender <jg...@savoirtech.com>.
> -----Original Message-----
> From: Jacek Laskowski [mailto:jlaskowski@apache.org]
> Sent: Tuesday, September 06, 2005 4:36 AM
> To: dev@geronimo.apache.org
> Subject: Re: How do we ship jetty and tomcat versions? Please respond
> Hi Dave,
>
> Both, by default? Interesting. Will there be a way in your
> proposal to deploy a WAR to *both* containers? Since the
> defaultNamespace option is to drive what container a WAR is
> deployed to I think the answer is negative, isn't it? (or
> alternatively it could assume that no defaultNamespace would
> mean both) If so, why would a user want to run Jetty and
> Tomcat? I don't mind having two containers and builders
> running at the same time, but wonder if there's a user case
> for it (a web hosting provider?).
>
I don't think there is a huge user case for this, but what DJ has done is
enormous in where it will take Geronimo relative to dynamic builders based
on namespaces. This takes our deployment to the next level. IMHO, I think
the web was a good area to try it out, even though we may never run both at
the same time.
Jeff
Re: How do we ship jetty and tomcat versions? Please respond
Posted by Jacek Laskowski <jl...@apache.org>.
David Jencks wrote:
...
> I wrote a namespace-driven switching module builder to determine if the
> jetty or tomcat builder is used. It has a defaultNamespace option
> which is what currently determines the target. The module builders
> register themselves with the switch and supply their namespace.
...
> So, in more detail, I propose we ship:
>
> -all the configurations, for both jetty and tomcat, installed
> - 3 pairs of config.list and config.xml files that run both, only jetty,
> and only tomcat
> - both containers and builders running by default.
Hi Dave,
Both, by default? Interesting. Will there be a way in your proposal to
deploy a WAR to *both* containers? Since the defaultNamespace option is
to drive what container a WAR is deployed to I think the answer is
negative, isn't it? (or alternatively it could assume that no
defaultNamespace would mean both) If so, why would a user want to run
Jetty and Tomcat? I don't mind having two containers and builders
running at the same time, but wonder if there's a user case for it (a
web hosting provider?).
> david jencks
Jacek