Re: Configuration...

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

> > If you can integrate Avalon and Preferences JSR, plus JNDI  - probably
> > your code will be better and I guess most people will use it, and it can
> > be the default configurator for tomcat.
> 
> My main goal is to define a simple interface that can be implemented for
> anything. I am using the Avalon and Preferences JSR as a model to build
> that interface. I'm also influenced by the 1.2 collections and some
> other distributed config stuff I've done.

Right now tomcat ( the core and all existing modules)  doesn't need any
configuration interface - that was a design decision, and it allows to
start tomcat using Startup + server.xml ( tomcat standalone) and using 
J2EE native config interfaces when integrated into J2EE, or using whatever
other mechanism is used by the "parent" application.

Everything is perfect with any Interface you define as long as it doesn't
require tomcat to change it's behavior - if you plan to change that and
have tomcat to _require_ the use of the interface - then we need to
discuss, it will be a significant revolution ( I'm very much against that,
and you need a very good solution for the embeded case ).


> The plugability of configuration depends on the factory that someone
> uses to build/load it. Everyone currently uses their own.

Let's see the code - as long as it doesn't try to be the only
configuration mechanism ( and uses the API provided by tomcat ).

> > the program that embed tomcat to use your config).
> > J2EE will not like it, neither all people who want to use tomcat as a
> > component in their program.
> 
> Just to make sure I've got it right: Something loads config and uses
> config to set up Context. Context is then used by tomcat.core. to run
> the system.

> This is tricky. How is it being handled currently? Or is XML required to
> be embedded?

Something loads config and set up all tomcat components - adapters,
context manager, contexts, etc. 

That something can get the information from XML ( as in tomcat
standalone), JNDI ( I think that's J2EE right now ), or anything else.

Tomcat has an API ( like addContext() or HttpAdapter.setPort() ), and
regardless of the information source it will still work.
Plus, that allows run-time changes ( like adding a context after tomcat 
was started).
( for example, J2EE will call addContext() when a new application is
deployed )
XML is not required ( except in reading web.xml, but that's a different
story ).


( again - I would like to see some code - the interface and how it is
used)

Costin

Re: Configuration...

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

> So there is an external "assembler" (as opposed to an internal factory)
> and this assembler is responsible for loading the config and setting up
> the proper stuff within Tomcat, but it exists outside of tomcat.core.
> Right?

Yes. This allows any configuration framework to work with tomcat 
( including multiple - user can select what he likes) 

> A few questions:
> 
> Why does tomcat.core/Constants.java refer directly to an XML file?
> 
> 97:	public static final String ConfigFile = WebInfDir + "/web.xml";

It should be moved - old code hanging.
( WebXmlInterceptor is the only place using it - to read WEB-INF/web.xml
and configure the context )


> Why does tomcat.core/Context.java refer directly to WebXmlInterceptor, a
> class that is in tomcat.context?
> 
> 540:	new WebXmlInterceptor().handleContextInit( this );

It shouldn't - the context intereptors will be configurable too.
Since there is no other implementation I just hardcoded it till I'll
have time or someone else will see it and fix it.

( WebXmlInterceptor() reads web.xml - a smarter one may read it 
from a different source, assuming the deploy tool will create an
equivalent implementation )

As a general answer - there are many lines like you pointed, 
I did a round of code cleanup but you can't do everything in
2 weeks. 

My intention was to decouple a bit the context initalization
and request processing and move it outside core , so people 
can enhance them without changing core. 

For example: WebXmlInterceptor can be replaced with a better
one as soon as someone has the time to do it. Same is true
for almost all components of tomcat.



Costin

Re: Configuration...

[Paul Philion <ph...@acmerocket.com>]

costin@costin.dnt.ro wrote:
> Something loads config and set up all tomcat components - adapters,
> context manager, contexts, etc.
> 
> That something can get the information from XML ( as in tomcat
> standalone), JNDI ( I think that's J2EE right now ), or anything else.
> 
> Tomcat has an API ( like addContext() or HttpAdapter.setPort() ), and
> regardless of the information source it will still work.
> Plus, that allows run-time changes ( like adding a context after tomcat
> was started).
> ( for example, J2EE will call addContext() when a new application is
> deployed )
> XML is not required ( except in reading web.xml, but that's a different
> story ).

So there is an external "assembler" (as opposed to an internal factory)
and this assembler is responsible for loading the config and setting up
the proper stuff within Tomcat, but it exists outside of tomcat.core.
Right?

That's fine. I'll just make sure that I can easily write an "assembler"
that can set up Tomcat.

A few questions:

Why does tomcat.core/Constants.java refer directly to an XML file?

97:	public static final String ConfigFile = WebInfDir + "/web.xml";

Why does tomcat.core/Context.java refer directly to WebXmlInterceptor, a
class that is in tomcat.context?

540:	new WebXmlInterceptor().handleContextInit( this );

> ( again - I would like to see some code - the interface and how it is
> used)

I'll send a note to the list when I've got something worth looking at.

- Paul Philion