Hi Folks,
I have written a wrapper for Catalina that allows it to be deployed as a
sar file into Apache's Avalon/Phoenix server application framework.
To some it seems unecessary, but Phoenix can serve multiple server
applications from one JVM. Currently these could include :
JAMES (the
Craig,
[ .. Avalon intro, and existing blocks snipped .. ]
One general question -- are you creating a class loader hierarchy (like
the Bootstrap class does), or are you loading everything from a single
class loader? The latter approach might cause you some grief, because
it's never been tested
Folks,
Back in a thread that ended on the 16th October we talked of some fixes
to the code that makes the interface abstractions ( interfaces classes
in org.apache.catalina package ) no longer dependant on implementation
of Catalina.
The reason we needed this is that it will make Catalina
Tom, Folks,
Thanks for that. I can't comment really either as I am not a committer.
Bip's last revision to Cluster is from July.
I think there are a couple more classes in org.apache.catalina.startup
that should have interfaces extracted from them and placed in
org.apache.catalina. These
Thanks Remy,
This is really great news.
What is the feeling nearly three months on? Are we still aiming at full
separation in terms both of dependancy and Jar? Are these five fixable?
No. Just package your JARs differently.
cluster, deploy and net are self-contained packages, so just
As extracted by IDEA/2 an Embedded interface is attached.
There is also a one line change to Embedded (the class). From
public class Embedded implements Lifecycle {
... to ...
public class Embedded implements Lifecycle,
org.apache.catalina.Embedded {
At some convenient point in
Remy, Kevin, Jena-Frederic, Bill, Craig et al,
Could we also do...
* the jar split (my email Jan 7th, 14:28)
* Embbeded interface (my email Jan 7th, 18:51)
Regards,
- Paul H
Hi,
Here goes the list:
- Tag the JK + util directories in j-t-c with some tag (Costin proposed
jk_14)
- Build the
Remy,
* Embbeded interface (my email Jan 7th, 18:51)
-1, because it's an API change for cosmetic reasons only.
In the head branch again then? It of course changes nothing if the
class is not renamed. It is not for cosmetic reasons, it will help
third party applications instantiate
Remy,
Only the core objects have interfaces. Embedded is a helper object, so it's
not an interface. Just like Catalina is not an interface.
By the way, I don't see how having an interface makes it easier to work with
Catalina. The only useful thing with interfaces is if you want to extend or
Remy,
If our helper object for embedding doesn't fit your needs, I suggest you
write your own instead. It doesn't take long, and it will do what you want
(including having an interface, so it fits into your virtual OS dream).
I am talking about Avalon (another Jakarta project). It is not a
Remy,
And why don't you want to write your own wrapper (I doubt Embedded is
adapted to your use case anyway), and put it in the Avalon tree ? That's why
I do with the various Catalina wrappers Slide has, and it doesn't cause any
problems.
Also, not having separated interfaces and
Craig,
Paul, this needs to be turned around as well. *Please* consider that what
you are asking for has a very substantial backwards compatibility cost --
making this change would mean it's impossible to have compiled Java code
that works with both 4.0.1 and 4.0.2, because the class inheritance
I've been looking at Embedded, Context, StandardContext, Wrapper and
StandardWrapper and want a way participating in the instantiation of a
servlet. i.e. ...
context = embedded.createContext(fooContext);
context.addServlet(barServlet, myServlet);
I know there are mechanisms for adding a
13 matches
Mail list logo
