Tomcat.Next Component Interfaces Checked In

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

In order to enable the Tomcat.Next compatible session management, I have
checked in the Tomcat.Next component interfaces (in the
org.apache.tomcat package).  Only "Manager" and "Session" will be used
now, but the interfaces all have interdependencies.

The current CVS tree will utilize the new Tomcat.Next compatible
implementation of Manager and Session, which has also been checked in.

Unfortunately, the check-in message for the component interfaces was too
long, so it got bounced by the mailer program.  The commentary was as
follows:

=====================================

craigmcc    00/01/08 19:20:03

  Added:       src/share/org/apache/tomcat Adapter.java Container.java
                        Context.java ContextConfig.java Engine.java
                        Host.java Interceptor.java Lifecycle.java
                        LifecycleException.java Loader.java Logger.java
                        Manager.java Realm.java Request.java
Resources.java
                        Response.java Session.java Wrapper.java
                        WrapperConfig.java WrapperParam.java
                        WrapperRole.java
  Log:
  Initial checkin of the "Tomcat.Next" component interfaces in the main
  source tree.  At this point, only Manager and Session will be used,
but
  the interfaces have mutual interdependencies that require all of them
  to be compiled together.

=====================================

Craig McClanahan

Re: Tomcat.Next Component Interfaces Checked In

[co...@eng.sun.com]

"Craig R. McClanahan" wrote:

> In order to enable the Tomcat.Next compatible session management, I have
> checked in the Tomcat.Next component interfaces (in the
> org.apache.tomcat package).  Only "Manager" and "Session" will be used
> now, but the interfaces all have interdependencies.

Ok, my comments on Manager:
- getContainer()/setContainer() are not _required_,  I see no reason why a
session manager needs a one-one relation with the Container and why all
managers need to remember the container they belong to.

- findSessions() - again, I don's see why a container should be required to

support this contract - nothing in tomcat require it. It may be needed by
reaper, but it's not a contract of interest to Tomcat, it's of interest to
the local implementation of session management.

- getInfo() - not needed, IMHO the place for info is in meta-data,
not in code ( i.e. documentation, a separate "inforamable" intreface, etc).

A Manager can exist without this, so it shouldn't be in the base intreface.



Everything else is fine ( for me ).

For Session - I see no need to introduce this interface as "binding
contract"
for all sessions.
There is no reason to not use HttpSession as return value - and cast it
internaly to an interface specific to a certain Manager.
- get/setManager() - same discution, a Session is doesn't have to know
the manager ( ResultSet doesn't have a getStatement in JDBC, and
HttpSession doesn't have getHttpSessionContext() ).

Costin




Costin

Re: Tomcat.Next Component Interfaces Checked In

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

costin@eng.sun.com wrote:
> 
> Assaf Arkin wrote:
> 
> > I can think of several reasons why the interceptor would like to know
> > what container it's bound to, e.g. to find out what realm it's running,
> > or get the context configuration, etc.
> >
> > In that case only setInterceptor is required, not getInterceptor, and
> > will be called only once thrown an ILSE if called twice. The same design
> > pattern is also used in EJB with setSessionContext called on a Bean.
> 
> Well, it's difference between "interceptor would like to know the
> container" and "interceptor _is required_ to know it".
> That method in the interface means ALL interceptors are REQUIRED
> to remember the container, and as a hidden effect means "an interceptor
> can be used ONLY for one container, you CAN'T have a singleton
> used by all containers, like a CountInterceptor"

That's precisely why I see getInterceptor as redundant.
+1

> 
> I would agree with a "setContainer" without "getContainer" ( or better
> "addContainer" ). My problem is with the "one-to-many" instead of
> "many-to-many" relationship ( which I don't think it good to REQUIRE,
> in EJB it is by design, I disagree with designing interceptors with
> one-to-many
> requirements).

I look at the Interceptor as an accessor into a larger system. If Tomcat
is running four containers, it will have four inteceptors with different
configuration talking to one Tyrex engine. Or it will have four logger
interceptors synchronizing access to the same file.

Your many-many relation is between the container and the back-end
through a one-many interceptor relationship.

arkin


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

RE: Tomcat.Next Component Interfaces Checked In

[Conor MacNeill <co...@m64.com>]

> From: costin@costin [mailto:costin@costin]On Behalf Of
>
> Assaf Arkin wrote:
>
> > I can think of several reasons why the interceptor would like to know
> > what container it's bound to, e.g. to find out what realm it's running,
> > or get the context configuration, etc.
> >
> > In that case only setInterceptor is required, not getInterceptor, and
> > will be called only once thrown an ILSE if called twice. The same design
> > pattern is also used in EJB with setSessionContext called on a Bean.
>
> Well, it's difference between "interceptor would like to know the
> container" and "interceptor _is required_ to know it".
> That method in the interface means ALL interceptors are REQUIRED
> to remember the container, and as a hidden effect means "an interceptor
> can be used ONLY for one container, you CAN'T have a singleton
> used by all containers, like a CountInterceptor"
>
> I would agree with a "setContainer" without "getContainer" ( or better
> "addContainer" ). My problem is with the "one-to-many" instead of
> "many-to-many" relationship ( which I don't think it good to REQUIRE,
> in EJB it is by design, I disagree with designing interceptors with
> one-to-many
> requirements).
>

Perhaps the container should be passed to the interceptor's preServce and
postServoce methods. This allows the interceptor to know the container that
is executing the request without binding the interceptor to a single
container.

Re: Tomcat.Next Component Interfaces Checked In

[co...@eng.sun.com]

Assaf Arkin wrote:

> I can think of several reasons why the interceptor would like to know
> what container it's bound to, e.g. to find out what realm it's running,
> or get the context configuration, etc.
>
> In that case only setInterceptor is required, not getInterceptor, and
> will be called only once thrown an ILSE if called twice. The same design
> pattern is also used in EJB with setSessionContext called on a Bean.

Well, it's difference between "interceptor would like to know the
container" and "interceptor _is required_ to know it".
That method in the interface means ALL interceptors are REQUIRED
to remember the container, and as a hidden effect means "an interceptor
can be used ONLY for one container, you CAN'T have a singleton
used by all containers, like a CountInterceptor"

I would agree with a "setContainer" without "getContainer" ( or better
"addContainer" ). My problem is with the "one-to-many" instead of
"many-to-many" relationship ( which I don't think it good to REQUIRE,
in EJB it is by design, I disagree with designing interceptors with
one-to-many
requirements).

Costin

Re: Tomcat.Next Component Interfaces Checked In

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

I can think of several reasons why the interceptor would like to know
what container it's bound to, e.g. to find out what realm it's running,
or get the context configuration, etc.

In that case only setInterceptor is required, not getInterceptor, and
will be called only once thrown an ILSE if called twice. The same design
pattern is also used in EJB with setSessionContext called on a Bean.

arkin

> The next from my point of view is Interceptor - I think it should be
> minimal ( no getContainer() or getInfo() ) - and this is the style for
> most interfaces and the current defined interface. Why do we need
> an Interceptor have a pointer to a Container - we can have one
> instance of interceptor that counts ( the number of requests served
> by the server).
> We create a new CountInterceptor() and add it to all Containers
> ( same instance).  It's a perfectly valid problem and solution -
> and it's made imposible by the Interceptor interface, which doesn't
> allow one Interceptor to be used by 2 Containers.
> 
> Costin
> ( again too long, I'm too tired )
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: Tomcat.Next Component Interfaces Checked In

[co...@eng.sun.com]

"Craig R. McClanahan" wrote:

> In order to enable the Tomcat.Next compatible session management, I have
> checked in the Tomcat.Next component interfaces (in the
> org.apache.tomcat package).  Only "Manager" and "Session" will be used
> now, but the interfaces all have interdependencies.

Sorry about the previous mail, I was very tired and I didn't shorted them
up.

What I was trying to say: it is very unlikely that the interfaces will be
implemented
in very soon ( i.e. 2-3 months), and it's better to not have them so
visible,
at least where there are big differences from the current model.

It would be very usefull if you can take a look at the new code which
I think is
much cleaner, and give the feedback about what can we do to get closer to
your design and why do so ( we can start with Loader - since this is a very

requested feature that Sam will have to implement ).

The next from my point of view is Interceptor - I think it should be
minimal ( no getContainer() or getInfo() ) - and this is the style for
most interfaces and the current defined interface. Why do we need
an Interceptor have a pointer to a Container - we can have one
instance of interceptor that counts ( the number of requests served
by the server).
We create a new CountInterceptor() and add it to all Containers
( same instance).  It's a perfectly valid problem and solution -
and it's made imposible by the Interceptor interface, which doesn't
allow one Interceptor to be used by 2 Containers.

Costin
( again too long, I'm too tired )

Re: Tomcat.Next Component Interfaces Checked In

[co...@eng.sun.com]

"Craig R. McClanahan" wrote:

> In order to enable the Tomcat.Next compatible session management, I have
> checked in the Tomcat.Next component interfaces (in the
> org.apache.tomcat package).  Only "Manager" and "Session" will be used
> now, but the interfaces all have interdependencies.

Craig,
Can you use a different package ( like org.apache.tomcat.xxx )?

I think it's a bit confusing ( since the interfaces are not yet used in
tomcat),
and the rule was to group related classes in a package.

We can vote on that, or you can give more arguments - I think it's not the
best place to put them.

If you want we can even use tomcat.core - I still think it's not a good
place for
now, but even that is better than apache.tomcat.

Also, some of the interfaces _need_ to be changed - not only because they
do not
fit with the current code and will require far too much work.

For example, Adapter is already specified in core, while the new interface
is
empty. I spent a lot of time defining Adapter - and all Tomcat adapters are

using it. I can agree it's not the best interface, but it's not so bad to
require
a complete rewrite without a reason.

For Loader  - right now from the current code results that there is no need
for
any interface ( the current interface cosists of loadServlet and
getClassPath,
and even those are not _required_).  I see no reason for the Loader to
keep a pointer to Container, or to have a getInfo() - the ClassLoader
interface
is simple and we shouldn't make it complex without very good reason.

Interceptor - it doesn't _need_ to have a pointer to Container - the
interfaces
should be minimal.

What I am trying to say is that we should still try to find a "common
ground",
without imposing revolutionary changes where not needed (like in Loader).

My proposal:
let's add them one at a time, based on your requirements.

I'm almost done with the request cleanup, and moving to initialization, and

I can spend the time to discuss the interfaces one by one, but I can't
comment
on all of them. My major complain is that the current set have too big
requirements,
i.e. the component need to follow a contract that is not based on the
components functionality ( a Loader needs to load a servlet, and the engine
needs to
set up it's class path - anything else is not _required_, and shouldn't be
part of the
interface. All interfaces in Servlet API and in all specs I know follow
this principle -
give me any contra-example. ).

Please understand I'm not against Tomcat.Next, but there are many details
where
I think the interfaces are wrong, and I'm sure there are many points where
you disagree with the changes I've done to tomcat.core. Please take a look
at the current code ( which I think it's much better and is closer to a
coherent
style that you can at least take into consideration for inclusion in
Tomcat.Next),
and see where we can meet.

"Simpler is better"

Costin