Re: Role of HttpServer

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

> I have been looking at the code and especially Costin's latest changes and I
> wonder if the HttpServer class is needed at all. I had thought this for a
> while and the recent changes just reinforce this, as most behaviour is now
> delegated to the context manager. Why not just get rid of it and use the
> ContextManager in its place? Is this the plan? (The new config file seems to
> suggest this)

It is not needed as it is, but it is used by J2EE.

Also, instead of removing it should be re-factored as a "Container" for
ContextManagers ( for example to deal with multiple tomcat engines 
in the same VM).

Just ignore it for a while - it's just a way to start tomcat.

> Another thing I have noticed is that a lot of methods are throwing
> java.lang.Exception (such as ServerConnector). This seems a little dangerous
> to me. It tends to spread throughout the code and might hide an exception
> which should be caught and handled appropriately.

I agree with you - it should be fixed.
Also, after log is added - we should replace all println() with 
calls to log() or error(), and move the strings in locale.

Costin

RE: Role of HttpServer

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

> The result of all that is that it seems to me to be possible for the
> connectors to set the server name and server port to appropriate values
> without needing those values to be held by the ContextManager. Where the
> server is remote, the protocol supplies the info, where tomcat is providing
> the HTTP connection, the info comes from the local side of the socket.

> > Tomcat still have "legacy" code from the "standalone" case, HttpServer
> > used to implement the http server,
> 
> I started this thread wondering if we can remove that legacy code.

I think we should. 

Probably port and host can be removed from ContextManager without harm,
and we can move the responsability for setting serverName and serverPort
to adapters ( who will create Request implementations anyway).

+1 on your changes, please send the diffs - next week I'll start
commiting them. It would be usefull to have a SimpleStartup.java
also - without HttpServer.  ( that will also solve the kaffe problem,
it seems kaffe doesn't like introspection nor RMI, but works after that ).

Costin

RE: Role of HttpServer

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

> > Is there something special about that port compared to all the
> other ports
> > on which the ContextManager's connectors may be listing. As far as I can
> > tell the ContextManager's port and hostname values are only used for the
> > naming of entries in the workdir. Perhaps giving ContextManager a name
> > attribute and using it to name the workdir would be as good.
>
> :-)
>
> It's the "real" hostname and port.
> You may have tomcat on a different computer with Apache on the main
> web server. Servlet.getPort(), getHostname() need to respond with
>  the name and port of the real web server ( != adapter port and local
> hostname).
>

OK I understand the motivation. Unfortunately it isn't actually used like
that currently as far as I can tell. The only calls to getHostname and
getPort on the ContextManager are by the workdir code.

By Servlet.getPort and getHostname() I am presuming you actually mean
ServletRequest.getServerPort() and ServletRequest.getServerName()? Looking
at the Tomcat code, these methods are actually implemented in RequestImpl
and HttpRequestAdapter. For both of these classes the serverName can be set
explicitly otherwise it defaults to the value of the host header or the
value "localhost". The port value in RequestImpl can be set explicitly or
defaults to 8080. For the HttpRequestAdapter the port Value comes from the
local port of the socket used to receive the request.

The serverPort is set explicitly by AJPRequestAdapter in
AJP11ConnectionHandler,
by AJP12RequestAdapter in AJP12ConnectionHandler, and in ConnectorRequest
invoked by AJP23ConnectionHandler

The serverName is set explicitly by Ajp12ConnectionHandler and in the
HttpConnectionHandler it is set from the host header or from the local
address of the receiving socket.

The result of all that is that it seems to me to be possible for the
connectors to set the server name and server port to appropriate values
without needing those values to be held by the ContextManager. Where the
server is remote, the protocol supplies the info, where tomcat is providing
the HTTP connection, the info comes from the local side of the socket.

What happens if the ContextManager has the wrong values (ie the server which
sends the request is not the one which is identified in the ContextManager)?
Should I need to change the tomcat config to move my Apache server to a
different port?

I don't know why all the connectors don't set the serverName. I don't have a
detailed understanding of the AJP protocols.


> Tomcat still have "legacy" code from the "standalone" case, HttpServer
> used to implement the http server,

I started this thread wondering if we can remove that legacy code.

> we added ContextManager because
> in a "multi-adapter" server you can have more complex models.
> ( ContextManager is not a singleton - you can have multiple
> instances, each handling a different web server )
>

Indeed.

>
> > A model whereby a contextManager contains a set of connectors
> (and contexts,
> > interceptors, etc) and all port information is managed by those
> connectors
> > seems more regular to me. This seems to correspond to the model in
> > tomcat.xml but not yet in the code.
>
> Except the "default" port a hostname, which is different from what
> adapters have.
>

Sure, but the connectors can set the values appropriately without referring
to the ContextManager. So I still think the port information can be defined
solely in the connectors.

I am wondering whether a single ContextManager can talk to more than one
Apache server. I haven't thought whether that would be useful but it would
mean that the ContextManager can't know about a single "real" hostname and
port. The real host info would need to come from the connectors.

Conor

RE: Role of HttpServer

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

> > It is not needed as it is, but it is used by J2EE.
> >
> 
> What is the relationship between J2EE and tomcat? Does J2EE just have links
> into tomcat internals? It would be nice if there were some interfaces
> defined for J2EE integration and documented as such.

Tomcat is used by J2EE. It uses some internals - it adds security,
deployment ,etc. We need to define the interfaces, that will happen
probably soon.

> > Just ignore it for a while - it's just a way to start tomcat.
> >
> 
> OK. However, once I removed it (just to see if it was possible) I began to
> wonder why port, hostname, address etc are properties of the ContextManager.
> Surely these are just properties of one of the ContextManager's connectors?
> Is there something special about that port compared to all the other ports
> on which the ContextManager's connectors may be listing. As far as I can
> tell the ContextManager's port and hostname values are only used for the
> naming of entries in the workdir. Perhaps giving ContextManager a name
> attribute and using it to name the workdir would be as good.

:-)

It's the "real" hostname and port. 
You may have tomcat on a different computer with apache on the main
web server. Servlet.getPort(), getHostname() need to respond with
 the name and port of the real web server ( != adapter port and local
hostname).

Tomcat still have "legacy" code from the "standalone" case, HttpServer
used to implement the http server, we added ContextManager because
in a "multi-adapter" server you can have more complex models. 
( ContextManager is not a singleton - you can have multiple
instances, each handling a different web server ) 


> A model whereby a contextManager contains a set of connectors (and contexts,
> interceptors, etc) and all port information is managed by those connectors
> seems more regular to me. This seems to correspond to the model in
> tomcat.xml but not yet in the code.

Except the "default" port a hostname, which is different from what
adapters have.

> > I agree with you - it should be fixed.
> 
> I'll try and add some patches then, although I'm not sure of the
> implications of the 3.1M1 freeze.

Me neither. I'm waiting for P1 bugs - and I'll start coding again 
after we're done with the "burn-in".

Costin

RE: Role of HttpServer

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

>
> > I have been looking at the code and especially Costin's latest
> changes and I
> > wonder if the HttpServer class is needed at all. I had thought
> this for a
> > while and the recent changes just reinforce this, as most
> behaviour is now
> > delegated to the context manager. Why not just get rid of it and use the
> > ContextManager in its place? Is this the plan? (The new config
> file seems to
> > suggest this)
>
> It is not needed as it is, but it is used by J2EE.
>

What is the relationship between J2EE and tomcat? Does J2EE just have links
into tomcat internals? It would be nice if there were some interfaces
defined for J2EE integration and documented as such.

> Also, instead of removing it should be re-factored as a "Container" for
> ContextManagers ( for example to deal with multiple tomcat engines
> in the same VM).

Well it seems to have a dual personality. In Startup.java an HttpServer is
created for each ContextManager so I don't see it as a contextManager
container. I guess, however, that you have used it almost as a container in
Tomcat.java if I understand the mapping of the Server element to HttpServer
class.

I think a new class to contain the ContextManagers would be just as good
since I don't see much of the current HttpServer code surviving any
refactoring.

>
> Just ignore it for a while - it's just a way to start tomcat.
>

OK. However, once I removed it (just to see if it was possible) I began to
wonder why port, hostname, address etc are properties of the ContextManager.
Surely these are just properties of one of the ContextManager's connectors?
Is there something special about that port compared to all the other ports
on which the ContextManager's connectors may be listing. As far as I can
tell the ContextManager's port and hostname values are only used for the
naming of entries in the workdir. Perhaps giving ContextManager a name
attribute and using it to name the workdir would be as good.

A model whereby a contextManager contains a set of connectors (and contexts,
interceptors, etc) and all port information is managed by those connectors
seems more regular to me. This seems to correspond to the model in
tomcat.xml but not yet in the code.


> > Another thing I have noticed is that a lot of methods are throwing
> > java.lang.Exception (such as ServerConnector). This seems a
> little dangerous
> > to me. It tends to spread throughout the code and might hide an
> exception
> > which should be caught and handled appropriately.
>
> I agree with you - it should be fixed.

I'll try and add some patches then, although I'm not sure of the
implications of the 3.1M1 freeze.

Conor