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. :)
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
> 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.
> david jencks
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot