Tomcat/Jetty Handling

[Aaron Mulder <am...@alumni.princeton.edu>]

I think we need to finalize our plan for Tomcat and Jetty for M5 (or
whatever we call it).

I believe we agreed earlier to produce separate Tomcat and Jetty releases.

Currently, our "modules/assembly" build creates a distribution with
BOTH Tomcat and Jetty, and I believe even starts both by default
(though I'm not sure of that).

I don't like that solution very much, for reasons which I think I've
covered in other threads.  I'd like to actually remove the
configuration(s) for the product not included in the desired
distribution.  The most pressing reason for this is so that the
console can safely assume that only one web container is present. 
While we need to correct it to handle multiple web containers, I think
that's a lot of unnecessary work for M5, compared to limiting
ourselves to deploying one web container in each build.

So the question is, how to we get two different builds for Jetty and
Tomcat?  The short-term options (e.g. not switching to assemblies/*,
which I assume would be a major undertaking) seem to be:

 - Change "modules/assembly" so that the Jetty/Tomcat decision
actually doesn't deploy or undeploys the non-matching web container
configuration(s), instead of just changing the list of modules to
start by default.

 - Create two wrapper modules that each take the output of
"modules/assembly" and one strips the Tomcat stuff and configures it
for Jetty and the other does vice versa.

The former is certainly the quick+dirty solution, but it results in us
needing to run the build twice and creates two output artifacts with
the same name but different contents.  I suspect that will be
objectionable, which leads me to believe that the second option would
be preferable.  Anyone else have thoughts on this (or the best way to
do this)?

Thanks,
    Aaron

Re: Tomcat/Jetty Handling

[Aaron Mulder <am...@alumni.princeton.edu>]

We, we have a workable solution on this. There's a common interface and then
Jetty and Tomcat interfaces that extend it. Not that we've applied that to
statistics yet, but I think we can.

Generally, statistics is something that we haven't looked at in much detail
yet (and our current implementation is totally against JSR-77 so it needs to
be looked at), so I'm not as worried if it's not great yet. I also think
Tomcat can cough up a ton of statistics and we're just not capturing them
yet, so I think it'll be relatively easy for us to come up with a robust set
of common statistics, particularly for purposes of the portal. But maybe I'm
being overly optimistic. :)

Aaron

On 9/20/05, Joe Bohn <jo...@earthlink.net> wrote:
>
> There's one other thing to consider here related to the console that
> I'll toss out. It appears that it may not always be feasible to have a
> single, common management portlet (or API) to always address the needs
> of both containers. I know this is another controversial topic (to have
> common management or not). However I'm not convinced we can achieve
> 100% common management or that we would even want to in all cases. This
> probably makes sense 90%+ of the time ... but we're starting to see some
> differences in particular areas where things are not as standardized.
> One example on the tomcat and jetty front appears to be in the type
> performance/measurement statistics available. Until we can get a more
> dynamic console (possibly by using a more robust Portal server) we can't
> fully accommodate the different possible configurations in a clean
> manner (even for tomcat and jetty). I think that the two assemblies is
> the right approach anyway, but we might not have a choice when it comes
> to the console requirements.
>
> David Jencks wrote:
>
> >
> > On Sep 19, 2005, at 10:24 PM, Aaron Mulder wrote:
> >
> >> I think we need to finalize our plan for Tomcat and Jetty for M5 (or
> >> whatever we call it).
> >
> >
> > I'll call it M5 for the purposes of this reply :-)
> >
> >>
> >> I believe we agreed earlier to produce separate Tomcat and Jetty
> >> releases.
> >
> >
> > I would like to revisit this decision for M5. I think it will produce
> > an unwarranted amount of disruption for essentially no gain.
> >
> >>
> >> Currently, our "modules/assembly" build creates a distribution with
> >> BOTH Tomcat and Jetty, and I believe even starts both by default
> >> (though I'm not sure of that).
> >
> >
> > It shouldn't, only one should start.
> >
> >>
> >> I don't like that solution very much, for reasons which I think I've
> >> covered in other threads. I'd like to actually remove the
> >> configuration(s) for the product not included in the desired
> >> distribution. The most pressing reason for this is so that the
> >> console can safely assume that only one web container is present.
> >> While we need to correct it to handle multiple web containers, I think
> >> that's a lot of unnecessary work for M5, compared to limiting
> >> ourselves to deploying one web container in each build.
> >>
> >> So the question is, how to we get two different builds for Jetty and
> >> Tomcat? The short-term options (e.g. not switching to assemblies/*,
> >> which I assume would be a major undertaking) seem to be:
> >>
> >> - Change "modules/assembly" so that the Jetty/Tomcat decision
> >> actually doesn't deploy or undeploys the non-matching web container
> >> configuration(s), instead of just changing the list of modules to
> >> start by default.
> >>
> > I am strongly against trying to get one module to produce two
> > barely-related outputs. This is really against maven principles. If
> > we want separate jetty and tomcat distros, we need to have two
> > assembly modules, one for each. IMO the "dual use" one has some
> > utility, so that means 3 assembly modules.
> >
> >> - Create two wrapper modules that each take the output of
> >> "modules/assembly" and one strips the Tomcat stuff and configures it
> >> for Jetty and the other does vice versa.
> >
> >
> > this is sort of ridiculous IMO.
> >
> >>
> >> The former is certainly the quick+dirty solution, but it results in us
> >> needing to run the build twice and creates two output artifacts with
> >> the same name but different contents. I suspect that will be
> >> objectionable, which leads me to believe that the second option would
> >> be preferable. Anyone else have thoughts on this (or the best way to
> >> do this)?
> >>
> >
> > Using our current ad-hoc assembly module, we would have 3 copies of
> > essentially the same code and be generating mostly the same
> > configurations 3 times over. This is pretty silly and extremely hard
> > to maintainable. IMO the only reasonable approach that is compatible
> > with maven principles is to separate building the configurations and
> > assembling them into the distros.
> >
> > I think this is a good idea, but I think we should get what we have
> > now out. My understanding of the main purpose of M5 was to
> > demonstrate tomcat integration rather than a complete web console.
> > What we have now, with both jetty and tomcat included, demonstrates
> > that to my mind. I think certification is plenty to work for.
> >
> > thanks
> > david jencks
> >
> >
> >
>
> --
> 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: Tomcat/Jetty Handling

[Joe Bohn <jo...@earthlink.net>]

There's one other thing to consider here related to the console that 
I'll toss out.  It appears that it may not always be feasible to have a 
single, common management portlet (or API) to always address the needs 
of both containers.  I know this is another controversial topic (to have 
common management or not).   However I'm not convinced we can achieve 
100% common management or that we would even want to in all cases.  This 
probably makes sense 90%+ of the time ... but we're starting to see some 
differences in particular areas where things are not as standardized.  
One example on the tomcat and jetty front appears to be in the type 
performance/measurement statistics available.  Until we can get a more 
dynamic console (possibly by using a more robust Portal server) we can't 
fully accommodate the different possible configurations in a clean 
manner (even for tomcat and jetty).  I think that the two assemblies is 
the right approach anyway, but we might not have a choice when it comes 
to the console requirements.

David Jencks wrote:

>
> On Sep 19, 2005, at 10:24 PM, Aaron Mulder wrote:
>
>> I think we need to finalize our plan for Tomcat and Jetty for M5 (or
>> whatever we call it).
>
>
> I'll call it M5 for the purposes of this reply :-)
>
>>
>> I believe we agreed earlier to produce separate Tomcat and Jetty 
>> releases.
>
>
> I would like to revisit this decision for M5.  I think it will produce 
> an unwarranted amount of disruption for essentially no gain.
>
>>
>> Currently, our "modules/assembly" build creates a distribution with
>> BOTH Tomcat and Jetty, and I believe even starts both by default
>> (though I'm not sure of that).
>
>
> It shouldn't, only one should start.
>
>>
>> I don't like that solution very much, for reasons which I think I've
>> covered in other threads.  I'd like to actually remove the
>> configuration(s) for the product not included in the desired
>> distribution.  The most pressing reason for this is so that the
>> console can safely assume that only one web container is present.
>> While we need to correct it to handle multiple web containers, I think
>> that's a lot of unnecessary work for M5, compared to limiting
>> ourselves to deploying one web container in each build.
>>
>> So the question is, how to we get two different builds for Jetty and
>> Tomcat?  The short-term options (e.g. not switching to assemblies/*,
>> which I assume would be a major undertaking) seem to be:
>>
>>  - Change "modules/assembly" so that the Jetty/Tomcat decision
>> actually doesn't deploy or undeploys the non-matching web container
>> configuration(s), instead of just changing the list of modules to
>> start by default.
>>
> I am strongly against trying to get one module to produce two 
> barely-related outputs.  This is really against maven principles.  If 
> we want separate jetty and tomcat distros, we need to have two 
> assembly modules, one for each.  IMO the "dual use" one has some 
> utility, so that means 3  assembly modules.
>
>>  - Create two wrapper modules that each take the output of
>> "modules/assembly" and one strips the Tomcat stuff and configures it
>> for Jetty and the other does vice versa.
>
>
> this is sort of ridiculous IMO.
>
>>
>> The former is certainly the quick+dirty solution, but it results in us
>> needing to run the build twice and creates two output artifacts with
>> the same name but different contents.  I suspect that will be
>> objectionable, which leads me to believe that the second option would
>> be preferable.  Anyone else have thoughts on this (or the best way to
>> do this)?
>>
>
> Using our current ad-hoc assembly module, we would have 3 copies of 
> essentially the same code and be generating mostly the same 
> configurations 3 times over.  This is pretty silly and extremely hard 
> to maintainable.  IMO the only reasonable approach that is compatible 
> with maven principles is to separate building the configurations and 
> assembling them into the distros.
>
> I think this is a good idea, but I think we should get what we have 
> now out.  My understanding of the main purpose of M5 was to 
> demonstrate tomcat integration rather than  a complete web console.  
> What we have now, with both jetty and tomcat included, demonstrates 
> that to my mind.  I think certification is plenty to work for.
>
> thanks
> david jencks
>
>
>

-- 
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: Tomcat/Jetty Handling

[David Jencks <da...@yahoo.com>]

On Sep 19, 2005, at 10:24 PM, Aaron Mulder wrote:

> I think we need to finalize our plan for Tomcat and Jetty for M5 (or
> whatever we call it).

I'll call it M5 for the purposes of this reply :-)
>
> I believe we agreed earlier to produce separate Tomcat and Jetty 
> releases.

I would like to revisit this decision for M5.  I think it will produce 
an unwarranted amount of disruption for essentially no gain.
>
> Currently, our "modules/assembly" build creates a distribution with
> BOTH Tomcat and Jetty, and I believe even starts both by default
> (though I'm not sure of that).

It shouldn't, only one should start.
>
> I don't like that solution very much, for reasons which I think I've
> covered in other threads.  I'd like to actually remove the
> configuration(s) for the product not included in the desired
> distribution.  The most pressing reason for this is so that the
> console can safely assume that only one web container is present.
> While we need to correct it to handle multiple web containers, I think
> that's a lot of unnecessary work for M5, compared to limiting
> ourselves to deploying one web container in each build.
>
> So the question is, how to we get two different builds for Jetty and
> Tomcat?  The short-term options (e.g. not switching to assemblies/*,
> which I assume would be a major undertaking) seem to be:
>
>  - Change "modules/assembly" so that the Jetty/Tomcat decision
> actually doesn't deploy or undeploys the non-matching web container
> configuration(s), instead of just changing the list of modules to
> start by default.
>
I am strongly against trying to get one module to produce two 
barely-related outputs.  This is really against maven principles.  If 
we want separate jetty and tomcat distros, we need to have two assembly 
modules, one for each.  IMO the "dual use" one has some utility, so 
that means 3  assembly modules.

>  - Create two wrapper modules that each take the output of
> "modules/assembly" and one strips the Tomcat stuff and configures it
> for Jetty and the other does vice versa.

this is sort of ridiculous IMO.
>
> The former is certainly the quick+dirty solution, but it results in us
> needing to run the build twice and creates two output artifacts with
> the same name but different contents.  I suspect that will be
> objectionable, which leads me to believe that the second option would
> be preferable.  Anyone else have thoughts on this (or the best way to
> do this)?
>

Using our current ad-hoc assembly module, we would have 3 copies of 
essentially the same code and be generating mostly the same 
configurations 3 times over.  This is pretty silly and extremely hard 
to maintainable.  IMO the only reasonable approach that is compatible 
with maven principles is to separate building the configurations and 
assembling them into the distros.

I think this is a good idea, but I think we should get what we have now 
out.  My understanding of the main purpose of M5 was to demonstrate 
tomcat integration rather than  a complete web console.  What we have 
now, with both jetty and tomcat included, demonstrates that to my mind. 
  I think certification is plenty to work for.

thanks
david jencks