On Thu, 2 Nov 2000, Ole Husgaard wrote:
> The problem we have here is that we do imports from Tomcat
> and that creates a license conflict, as the Tomcat license
> is not GPL-compatible.
> The question I would like answered is: Do we have to import
> from Tomcat?
> This question is raised due to the license problems, but I
> think it is valid from a technical viewpoint too:
> - Do we really want to create this dependency ?
> - Wouldn't it be better to have a generic way of
> interoperating with a web application server ?
> - Shouldn't we allow users to configure which web
> application they want to use without having to hack
> the jBoss code ?
Well, as a general problem this is unpleasant. We need a servlet
container to let us share a ClassLoader for EJBs in the same web app as
the servlets. That either means we use its, or it uses ours, and both of
those are unpleasant solutions (since the servlet one needs to be able to
load stuff from WARs or directories, and the EJB one needs to be able to
load stuff from JARs or directories). Either we need to ask it for a
"native" ClassLoader, and then return a CL that wraps both its and ours,
or we need it to tell us what directories and/or JARs/WARs to use and we
create one giant combined URLClassLoader or whatever. Either way, we
probably need some coordinating "framework" beyond just an interface.
This, plus a Class/Method name to start and stop the server really
ought to be enough to run an EJB container and servlet container in the
same VM.
However, this does not provide any configurability at all. In
reality, we'd like some way to control the servlet engine (deploy a new
EAR into WARs and JARs, for example), we need some interface for sharing
security information (login once to both products), we probably want to
share a JNDI implementation, log to the same place, etc.
Personally, I think a simple answer is right out the door. I
think we should be thinking about a product like Avalon, which aims to
provide exactly this. However, it is a non-trivial project in and of
itself. So for my two cents, if the licensing prevents us from an easy
but not featureful integration, let's work on a hard but much better
integration with Avalon.
Aaron
