geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Tomcat/Jetty Handling
Date Wed, 21 Sep 2005 01:41:39 GMT
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 <joe.bohn@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
>
>

Mime
View raw message