You have to break eggs to make an omlette [was: LONG TERM PLAN]

[ru...@us.ibm.com]

Warning: this messages is meant to be lighthearted.  Don't spend too much
time analyzing it for hidden messages.  Enjoy it.

Kevin Saffer wrote:
> re-architecting, refactoring, redesigning, whatever you want to call
> it is always a good idea, time permitting.
>
> In this case I don't see any time constraints, I have read a lot of
> talk about PMC and Timelines, where are they?  This is open source, lets
do
> whats best for the product, not an individual entity invloved.

I seem to have been elected release manager.  For a project like this, I'm
sure I would be more successful trying to herd cats.  What this somewhat
lofty title essentially amounts to is the responsibility of collecting the
README and ensuring that the jar files match the source at time of release.

With this in mind, you can find the current goals and schedules here:
http://jakarta.apache.org/cvsweb/index.cgi/jakarta-tomcat/RELEASE-PLAN?rev=1.1&content-type=text/x-cvsweb-markup

Note that these were not designed with any particular organizational entity
in mind.

> Parallel development of branches or not, Tomcat needs a new
> infrastructure.

Let me comment on the continuing "evolution" vs. "revolution" discussion
going on.  As an observation, this project appears to be running under the
implicit assumption that we need to keep the contents of the README empty
at all times.

I would prefer a different set of assumptions/goals:
1) Try to minimize unplanned failures
2) Keep system more or less recognizable at all times.

I venture to guess that if the next milestone build actually can start
serving web pages on JDKs other than 1.2.2, and doesn't trap the JVM if you
happen to set an option on, and if request.getServletPath() returned
something coherent, and if the known failures were explicitly listed in the
release notes, then many if not most people will perceive the next
milestone release as an increase in quality over the 3.0 final release.

And if the code is made more maintainable in the process, then we all win.

For that reason, I would like keep tomcat.next on the main branch.  That
way it gets the most focus, and some degree of confidence that the next bug
patch I commit I won't have to do again.  All I ask is that the schedule
outlined by Anil be given due consideration.  Brief pauses at designated
times to make the system more recognizable than most.   And a complete
shutdown around the time of ApacheCon, presuming that the this still makes
sense when we get there.

Deal?

- Sam Ruby

Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]

[co...@costin.dnt.ro]

>
> > Why? Is it because the interceptors are picked from server.xml and are
> > configured in by core?
> >
>
> The current approach taken by the Tomcat.Next "Lifecycle" interface passes a DOM node
> that you use to configure yourself.  The intent is that the Lifecycle pattern would
> be generally used for setting up most Tomcat.Next components, but it's not required.
>
> I'm not hung up on this approach, but the Tomcat.Current technique (convert the DOM
> to an XmlTree and deal with that) seems like overkill when Tomcat requires an XML
> parser to configure itself anyway -- you're pretty much guaranteed to have the DOM
> interfaces hanging around as well.

No, the current Startup is broken.

Tomcat.current architecture allows you to start and configure tomcat using APIs,
in fact J2EE doesn't use at all the tomcat.shell package, and if you embed tomcat
you don't need any XML at all.

The rule in the current architecture is: no XML in core, the configuration is done
via APIs ( with all the strong typing mechanisms ). You can't require a system
that embeds tomcat to use XML.

( BTW - fixing Startup is a big item on the todo list and has nothing to do with
the core architecture - anyone can work on it and it's ok to have alternative
starters - take a look at etc/SimpleStartup.java in the distribution)

Costin

Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]

["Craig R. McClanahan" <cm...@mytownnet.com>]

"Anil K. Vijendran" wrote:

> On Tue, 11 Jan 2000 costin@costin.dnt.ro wrote:
>
> > Does everyone agree that tomcat.core will have a dependency on DOM ?
> > ( tomcat.current doesn't - is this a feature we want for the new architecture?)
>
> Why? Is it because the interceptors are picked from server.xml and are
> configured in by core?
>

The current approach taken by the Tomcat.Next "Lifecycle" interface passes a DOM node
that you use to configure yourself.  The intent is that the Lifecycle pattern would
be generally used for setting up most Tomcat.Next components, but it's not required.

I'm not hung up on this approach, but the Tomcat.Current technique (convert the DOM
to an XmlTree and deal with that) seems like overkill when Tomcat requires an XML
parser to configure itself anyway -- you're pretty much guaranteed to have the DOM
interfaces hanging around as well.

>
> It would be nice if core didn't have a dependency. It makes core lesser
> embeddable. I'd like to see APIs that allow us to plug interceptors in and
> the server.xml file is read and then these APIs are called at startup
> time.
>

I'd be fine with alternatives that removed this dependency.  As the Javadocs for
Lifecycle state, I consider validating this choice to be a FIXME type issue.

>
> >
> > Costin
> >
>

Craig

Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]

["Craig R. McClanahan" <cm...@mytownnet.com>]

costin@costin.dnt.ro wrote:

>
> The "cleaned-up" architecture wants to use introspection, like in ant.
>

+1 on introspection-based configuration ... this is one of the coolest things about
ant.

What do you suggest be passed as an argument to the configuration methods?  One of the
things I like about the DOM approach is that it matches component hierarchies pretty
nicely (via recursive configuration of subcomponents using the lower nodes in the
tree), and I would hope we don't have to give that up.

Craig

Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]

[Assaf Arkin <ar...@exoffice.com>]

Introspection would be nice thing to have, but rather limited in its
capabilities (I'm talking about Ant-like introspection).

However, having developed such an interceptor, if Tomcat can perform Ant
like configuration on the interceptor and map attributes into
properties, that would give my interceptor enough information to get up
and running, and won't bore me with DOM/XmlTree details.

Once I have that minimum set of information I can grab the proper
configuration file, which relies on substantially more complicated and
non trivial Java - XML mapping, or I can lookup them up in an LDAP
server, etc.

I believe that interceptors should either require simple configuration
which server.xml can contain, or complex configuration which should
exist outside of server.xml. This approach caters for the simple and
easy, as well as the overly complicated.

So, +1 on Ant-like introspection.

arkin



costin@costin.dnt.ro wrote:
> 
> "Anil K. Vijendran" wrote:
> 
> > On Tue, 11 Jan 2000 costin@costin.dnt.ro wrote:
> >
> > > Does everyone agree that tomcat.core will have a dependency on DOM ?
> > > ( tomcat.current doesn't - is this a feature we want for the new architecture?)
> >
> > Why? Is it because the interceptors are picked from server.xml and are
> > configured in by core?
> 
> One of the core interfaces in tomcat.next - Livecycle, has:
> configure( org.w3c.dom.Node ).
> 
> That mean components developed for tomcat.next require dom.
> 
> The current architecture is that each component has getter/setter for
> all properties of interest, and the configuration code calls them. That
> will also allow dynamic reconfiguration.
> 
> The "cleaned-up" architecture wants to use introspection, like in ant.
> 
> There are 3 models, and it seems everybody wants that we just throw
> away the last to and do the Tomcat.Next one.
> 
> Costin
> 
> >
> > It would be nice if core didn't have a dependency. It makes core lesser
> > embeddable. I'd like to see APIs that allow us to plug interceptors in and
> > the server.xml file is read and then these APIs are called at startup
> > time.
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]

[co...@costin.dnt.ro]

"Anil K. Vijendran" wrote:

> On Tue, 11 Jan 2000 costin@costin.dnt.ro wrote:
>
> > Does everyone agree that tomcat.core will have a dependency on DOM ?
> > ( tomcat.current doesn't - is this a feature we want for the new architecture?)
>
> Why? Is it because the interceptors are picked from server.xml and are
> configured in by core?

One of the core interfaces in tomcat.next - Livecycle, has:
configure( org.w3c.dom.Node ).

That mean components developed for tomcat.next require dom.

The current architecture is that each component has getter/setter for
all properties of interest, and the configuration code calls them. That
will also allow dynamic reconfiguration.

The "cleaned-up" architecture wants to use introspection, like in ant.

There are 3 models, and it seems everybody wants that we just throw
away the last to and do the Tomcat.Next one.

Costin



>
> It would be nice if core didn't have a dependency. It makes core lesser
> embeddable. I'd like to see APIs that allow us to plug interceptors in and
> the server.xml file is read and then these APIs are called at startup
> time.
>

Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]

["Anil K. Vijendran" <An...@eng.sun.com>]

On Tue, 11 Jan 2000 costin@costin.dnt.ro wrote:

> Does everyone agree that tomcat.core will have a dependency on DOM ?
> ( tomcat.current doesn't - is this a feature we want for the new architecture?)

Why? Is it because the interceptors are picked from server.xml and are
configured in by core? 

It would be nice if core didn't have a dependency. It makes core lesser
embeddable. I'd like to see APIs that allow us to plug interceptors in and
the server.xml file is read and then these APIs are called at startup
time. 

> 
> Costin
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 

--
Peace, Anil +<:-)

Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]

[co...@costin.dnt.ro]

>
> > re-architecting, refactoring, redesigning, whatever you want to call
> > it is always a good idea, time permitting.

And keep in mind that you shouldn't eat only eggs, and no
eggs in the evening!

Tomcat.Next is about the architecture of the core of tomcat.

With Tomcat.Next or Tomcat.Next.Next or any other core, you'll still
have the same problems - the fact that Tomcat doesn't start on NT
with JDK1.2.1 is not a core problem, there are some documentation
or installation problems.

The fact that it doesn't reload is not in core - is a class loader that
has to be fixed.
You want speed improvement - take MapperInterceptor and change
the parsing.

Want features - add new modules,  and I'll spend all the time I have to
to make sure that your new modules will work with Tomcat.Next and
Tomcat.Current.

You feel core architecture is the most important thing - join the discussion
about individual asspects.
Does everyone agree that tomcat.core will have a dependency on DOM ?
( tomcat.current doesn't - is this a feature we want for the new architecture?)

Costin

Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]

[Assaf Arkin <ar...@exoffice.com>]

> You can read web.xml yourself, using getDocumentBase(), or if you want
> a different way to read web.xml - just create a new interceptor.

That is what I'm doing right now. I copied the code from Tomcat so I get
the document base and acquire the web.xml, so I'm compatible with 3.0.
I'm just not sure if it's a portable way. Is it possible that a future
version will acquire the document in some other way (e.g. using a
different loader) which will not be accessible to me directly?

arkin


> 
> Costin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]

[co...@costin.dnt.ro]

Assaf Arkin wrote:

> On the topic of web.xml, can Tomcat either provide the web.xml
> information in the form of deployment objects or a document locator?
>
> arkin

See tomcat.context.WebXmlInterceptor
Tomcat doesn't care how Context is configured, it just provide
getDocumentBase()
( which is also set by the initilization code  in tomcat.shell or any other Startup
)

You can read web.xml yourself, using getDocumentBase(), or if you want
a different way to read web.xml - just create a new interceptor.

Costin

Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]

[Assaf Arkin <ar...@exoffice.com>]

On the topic of web.xml, can Tomcat either provide the web.xml
information in the form of deployment objects or a document locator?

arkin


> Tomcat.next will _have_ to parse the request and to read a web.xml file.
> I can say that 90% of the code is ( or should be ) outside core.
> 
> Session and Manager show one thing - it is very easy to bridge from
> one set of interfaces to the other.
> 
> It is easy and clear to even have the 2 models running at the same time:
> Context.setManager() and Context.setSessionManager() ( the 2 proposed
> and conflicting implementations), and tomcat will use whatever the
> user configured in.
> Yes, a session manager that implements Manager will not be as
> flexible as a SessionManager, but it will be clearer and will not have
> unused parameters in methods. Who cares ? - as long as we can
> use both, the user will benefit.
> 
> The ideea of keeping both in the main branch is exactly that -
> will allow the user to decide what model he wants, or to
> compare the 2 and then use one.
> 
> Craig seems prety convinced that the "hierarchy of Containers"
> is the way to go and will probably implement it shortly,
> and I'm convinced that "Interceptors processing Request"
> is better and I'm going to work on it.
> As soon as Craig gets tomcat.next up people will have 2
> choices - in the main branch.
> 
> The only important thing is to agree on interfaces or provide
> bridges. It's clear that the current code base has a lot of
> usefull code, while Tomcat.next is just a set of interfaces.
> It's the individual developer's decision to develop
> for one or the other - and as long as we have bridges we
> can share the new code.
> 
> > My main concern, as I have said before, is that Tomcat.current's lack of
> > documentation and comments makes it very hard to grasp for people who has
> 
> I will work on this - I just need time and maybe help.
> Or just read Apache documentation, as the model is very similar.
> ( with Java instead of C and a slightly different interface, since we
> benefit from OO ).
> 
> > could also serve as a starting point. The main point is that I believe
> > it will be much more efficient long term and allow more people to participate
> > if we start from scratch on a new branch than to cleanup and document the
> > current implementation. If we don't do that, I'm afraid Costin and a few
> 
> Both architectures are based on modules behind interfaces. It's the modules
> that need to be written in both cases.
> 
> Project that are needed in both Tomcat.next and Tomcat.current:
> -class loader
> -admin tool ( the interfaces are similar, it's just few method names that are
> different)
> -better parser
> -load balancing
> -aliases
> -documentation on how to start it up
> 
> Use whatever architecture you want to implement a faster parser and
> mapper - I'll port it to the other architecture. Implement the
> class loader for either of them, and it will work in the other with
> small cosmetic changes.
> 
> Costin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]

[co...@costin.dnt.ro]

> I'm afraid not. Tomcat.current and Tomcat.next use different models. Craig,
> I guy I really admire for his willingness to work towards a common goal,
> offered to try to work with Tomcat.next on the main branch by adding the
> Manager and Session interfaces. And immediately ran into opposition because
> there's a model clash between Tomcat.current and Tomcat.next. We've been
> discussing this back and forth now for a while, but to me it seems like
> it's very hard to find a compromise that everyone's happy with.

I can't agree with that.

Tomcat.current and Tomcat.next  have one thing in common - they
rely on independent modules to do the work, and provide in "core" only
a framework and a set of interfaces.

Tomcat.next will _have_ to parse the request and to read a web.xml file.
I can say that 90% of the code is ( or should be ) outside core.

Session and Manager show one thing - it is very easy to bridge from
one set of interfaces to the other.

It is easy and clear to even have the 2 models running at the same time:
Context.setManager() and Context.setSessionManager() ( the 2 proposed
and conflicting implementations), and tomcat will use whatever the
user configured in.
Yes, a session manager that implements Manager will not be as
flexible as a SessionManager, but it will be clearer and will not have
unused parameters in methods. Who cares ? - as long as we can
use both, the user will benefit.

The ideea of keeping both in the main branch is exactly that -
will allow the user to decide what model he wants, or to
compare the 2 and then use one.

Craig seems prety convinced that the "hierarchy of Containers"
is the way to go and will probably implement it shortly,
and I'm convinced that "Interceptors processing Request"
is better and I'm going to work on it.
As soon as Craig gets tomcat.next up people will have 2
choices - in the main branch.

The only important thing is to agree on interfaces or provide
bridges. It's clear that the current code base has a lot of
usefull code, while Tomcat.next is just a set of interfaces.
It's the individual developer's decision to develop
for one or the other - and as long as we have bridges we
can share the new code.


> My main concern, as I have said before, is that Tomcat.current's lack of
> documentation and comments makes it very hard to grasp for people who has

I will work on this - I just need time and maybe help.
Or just read Apache documentation, as the model is very similar.
( with Java instead of C and a slightly different interface, since we
benefit from OO ).

> could also serve as a starting point. The main point is that I believe
> it will be much more efficient long term and allow more people to participate
> if we start from scratch on a new branch than to cleanup and document the
> current implementation. If we don't do that, I'm afraid Costin and a few

Both architectures are based on modules behind interfaces. It's the modules
that need to be written in both cases.

Project that are needed in both Tomcat.next and Tomcat.current:
-class loader
-admin tool ( the interfaces are similar, it's just few method names that are
different)
-better parser
-load balancing
-aliases
-documentation on how to start it up

Use whatever architecture you want to implement a faster parser and
mapper - I'll port it to the other architecture. Implement the
class loader for either of them, and it will work in the other with
small cosmetic changes.

Costin

Re: You have to break eggs to make an omlette [was: LONG TERM PLAN]

[Hans Bergsten <ha...@gefionsoftware.com>]

rubys@us.ibm.com wrote:
> [...]
> Let me comment on the continuing "evolution" vs. "revolution" discussion
> going on.  As an observation, this project appears to be running under the
> implicit assumption that we need to keep the contents of the README empty
> at all times.
> 
> I would prefer a different set of assumptions/goals:
> 1) Try to minimize unplanned failures
> 2) Keep system more or less recognizable at all times.
> 
> I venture to guess that if the next milestone build actually can start
> serving web pages on JDKs other than 1.2.2, and doesn't trap the JVM if you
> happen to set an option on, and if request.getServletPath() returned
> something coherent, and if the known failures were explicitly listed in the
> release notes, then many if not most people will perceive the next
> milestone release as an increase in quality over the 3.0 final release.
> 
> And if the code is made more maintainable in the process, then we all win.

Yes, development of the currently planned 3.1 features and bugfixes need
to go on, no argument there. 

> For that reason, I would like keep tomcat.next on the main branch.  That
> way it gets the most focus, and some degree of confidence that the next bug
> patch I commit I won't have to do again.  All I ask is that the schedule
> outlined by Anil be given due consideration.  Brief pauses at designated
> times to make the system more recognizable than most.   And a complete
> shutdown around the time of ApacheCon, presuming that the this still makes
> sense when we get there.
> 
> Deal?

I'm afraid not. Tomcat.current and Tomcat.next use different models. Craig,
I guy I really admire for his willingness to work towards a common goal,
offered to try to work with Tomcat.next on the main branch by adding the
Manager and Session interfaces. And immediately ran into opposition because
there's a model clash between Tomcat.current and Tomcat.next. We've been
discussing this back and forth now for a while, but to me it seems like
it's very hard to find a compromise that everyone's happy with.

My main concern, as I have said before, is that Tomcat.current's lack of
documentation and comments makes it very hard to grasp for people who has
not been with it for a long time. I'm not saying the architecture is wrong,
I'm saying it's not clear and therefore I can't really comment on it. To
me this means it will be very hard to get others to help making any big
contributions, such as the type of cleanup Costin is currently doing, or
adding load balancing, administration tools, security, etc. All these things
require a good understanding of the overall design.

I would therefore like to see a new branch where we start with a clear,
documented architecture and design. Craig made a proposal that looks good
to me on a high level. But I'm not married to it. If the model used in
Tomcat.current was documented so we could analyze it and discuss it, it
could also serve as a starting point. The main point is that I believe
it will be much more efficient long term and allow more people to participate 
if we start from scratch on a new branch than to cleanup and document the
current implementation. If we don't do that, I'm afraid Costin and a few
others who know the code will have to do a lot of heavy lifting. The barrier
for others to get a good enough feel for the current code base is just too
high.

I'm actually very surprised that this is such a big issue. Here we have
someone who's willing to offer a lot of time to help out in the best way he 
knows by trying out a new architecture, on a separate branch not to
interfere with the ongoing cleanup effort. And it get's "-1'ned". What's wrong
with this picture?

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com