From: Henri Gomez
As many I feel that jk (and maybe also jk2) are now pretty stable, and I don't see the need for a new just web/tomcat connector.
Finally someone :-).
That's why I did try to use the revolutionary approach. Jet another connector wouldn't make a much difference (quite contrary thought).
If there is a need among community for slightly different-then-connector approach (I've used the term integrator, and IMO it would better describe that new concept), we should discuss that further.
But this time I'd like to spend a month or so doing 'real' design without the single line of code. If we manage to put and describe our needs on the paper, the coding itself will took insignificant amount of time. If this plan shows that 90% of the existing codebase can be reused; even better.
Good luck with that... I don't believe in "real design without a single line of code" - and I'm not quite sure about "putting the needs on paper" ( at least not in the sense you seem to mean it ).
One thing should be clear - existing needs must continue to work - for example even if a fancy new autoconfig is used, users should still have the ability to do manual configuration.
For example:
- support for apache1.3 and multiprocess servers -> deal with the limitations of the back-communication.
- ability to serve static pages with apache -> no mod_webapp "dumb server" approach
There are 2 major areas to discuss:
- low-level model - object model, extension points and request processing model
- various modules - to implement whatever protocol, to implement configuration, etc.
The first thing ( IMO ) is to decide on what improvements we need
on the lower layer so it can satisfy any additional needs you may have -
configuration, performance, integration with a wider set of applications, etc.
Costin
But once again, I don't wish to be limited by the existing codebase, that will limit the design from the start. If we manage to put ourselves in the neutral possition, we might do something.
And we even a little more ambitious, we could think in term of Java to Native broker, not sure Tomcat to Native...
If we on the end decide that this new integrator isn't what we need (or we don't have enough resources to implement it), at least it will show some directions for the existing connectors to follow.
MT.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
