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 m
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 a
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 jus
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 th
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 t
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 C
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 implement
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 inherita
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 ma
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 tes
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
