You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Paul Hammant <Pa...@yahoo.com> on 2001/10/13 17:40:44 UTC
Catalina on Avalon
Hi folks,
As mentioned some weeks ago, I have Catalina more or less working inside
Avalon. In short this means it can run inside the same virtual machine
as JAMES (mail server) FtpServer (another Avalon app) and other servers.
See picture at this link : http://jakarta.apache.org/avalon/phoenix/
Request :
Summary : Seperation of interfaces and implementation. Different
jars in same ditribution.
Detail : There are 39 interfaces & support classes in
org.apache.catalina. Sub packages of that implement those abstractions.
It's a very neat design apart from one thing. They are all in the same
jar file and hence classloader. In Avalon we mount classloaders one or
two levels deeper than the primordial that would load the core of
Catalina if launched from a shell. We'd like to be able to mount the
interfaces at top level for general visibility and sharing, and
implementation, like other server applications in a branch/leaf class
loader. If those 39 interfaces and classes were moved to a different
package (say org.apache.catalina.api), then a split into two jars would
be possible and our dreams could come true.
Have I convinced of need?
Is 4.0.1 beta too touchy a distribution to instigate package migrations
on (however trivial) ?
Regards,
- Paul H
Re: Catalina on Avalon
Posted by Remy Maucherat <rm...@home.com>.
> On Tue, 16 Oct 2001, Denis Balazuc wrote:
>
> > Date: Tue, 16 Oct 2001 14:27:21 -0400
> > From: Denis Balazuc <de...@trader.com>
> > Reply-To: tomcat-dev@jakarta.apache.org
> > To: tomcat-dev@jakarta.apache.org
> > Subject: Re: Catalina on Avalon
> >
> > > I love Avalon's concept and idea, but I'm not at all happy with the
> > > implementation. It is too heavy and 'framework-ish', and the fact that
it
> > > is a JSR or not doesn't change this. The 'component loading'
service/idea
> > > is just great, but configuration, logging, etc are not that good idea.
> >
> > If Avalon is bound to be a framework-support API, I myself wonder why
the
> > logging API does not use Jakarta-Log4J
> > and does not seem to foresee that JDK1.4 has its own logging API as well
?
> >
>
> Folks, can we *please* not have a rehash of this old discussion here? If
> you like talking about what Avalon is or isn't, there's plenty of fodder
> in the archives of general@jakarta.apache.org and the various Avalon
> lists.
Also an interesting discussion on the subject when the Commons were created.
Remy
Re: Catalina on Avalon
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 16 Oct 2001, Denis Balazuc wrote:
> Date: Tue, 16 Oct 2001 14:27:21 -0400
> From: Denis Balazuc <de...@trader.com>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Catalina on Avalon
>
> > I love Avalon's concept and idea, but I'm not at all happy with the
> > implementation. It is too heavy and 'framework-ish', and the fact that it
> > is a JSR or not doesn't change this. The 'component loading' service/idea
> > is just great, but configuration, logging, etc are not that good idea.
>
> If Avalon is bound to be a framework-support API, I myself wonder why the
> logging API does not use Jakarta-Log4J
> and does not seem to foresee that JDK1.4 has its own logging API as well ?
>
Folks, can we *please* not have a rehash of this old discussion here? If
you like talking about what Avalon is or isn't, there's plenty of fodder
in the archives of general@jakarta.apache.org and the various Avalon
lists.
Thanks,
> Cheers
> Denis
>
Craig
Re: Catalina on Avalon
Posted by Denis Balazuc <de...@trader.com>.
> I love Avalon's concept and idea, but I'm not at all happy with the
> implementation. It is too heavy and 'framework-ish', and the fact that it
> is a JSR or not doesn't change this. The 'component loading' service/idea
> is just great, but configuration, logging, etc are not that good idea.
If Avalon is bound to be a framework-support API, I myself wonder why the
logging API does not use Jakarta-Log4J
and does not seem to foresee that JDK1.4 has its own logging API as well ?
Cheers
Denis
Re: Catalina on Avalon
Posted by Paul Hammant <Pa...@yahoo.com>.
Remy,
>I think it is perfectly embeddable (just use the whole catalina.jar, instead
>of trying to subdivide it in multiple sealed JARs, and putting it in
>separate loaders; separating it is not possible at the moment, because there
>are indeed two very minor issues with (1), as explained in my other email).
>
I'll wait for 4.2 (or whatever).
Yes, you are right it is embedable, but not as seperate interface and
implementation. And not as interface with hidden implementation.
Regards,
- Paul H
Re: Catalina on Avalon
Posted by Remy Maucherat <rm...@home.com>.
> On Tue, 16 Oct 2001, Paul Hammant wrote:
>
> > OK, I've been asked to clarify a few things from various emails.
> >
> > 1) Separation of interface / impl ----> why?
>
> I don't think you have to answer this ( at least not on tomcat-dev ) :-)
>
> > 5) Resitance.
> >
> > Re : Remy's email on "Pauls Dream", and how he does not subscribe *at*
> > *all* to the Avalon idea.
>
> > Is this a common belief amongst committers to Apache? I might remind
> > you that Avalon is a candidate for Sun's JSR 111 Community API. It
>
> I love Avalon's concept and idea, but I'm not at all happy with the
> implementation. It is too heavy and 'framework-ish', and the fact that it
> is a JSR or not doesn't change this. The 'component loading' service/idea
> is just great, but configuration, logging, etc are not that good idea.
>
> But of course, I agree that tomcat should be usable with Avalon - after
> all that's one of our goals, to be 'embedable' and 'modular'.
I think it is perfectly embeddable (just use the whole catalina.jar, instead
of trying to subdivide it in multiple sealed JARs, and putting it in
separate loaders; separating it is not possible at the moment, because there
are indeed two very minor issues with (1), as explained in my other email).
Remy
Re: Catalina on Avalon
Posted by Paul Hammant <Pa...@yahoo.com>.
Costin,
>>OK, I've been asked to clarify a few things from various emails.
>>
>>1) Separation of interface / impl ----> why?
>>
>
>I don't think you have to answer this ( at least not on tomcat-dev ) :-)
>
Chortle ;-)
>>5) Resitance.
>>
>> Re : Remy's email on "Pauls Dream", and how he does not subscribe *at*
>>*all* to the Avalon idea.
>>
>>Is this a common belief amongst committers to Apache? I might remind
>>you that Avalon is a candidate for Sun's JSR 111 Community API. It
>>
>
>I love Avalon's concept and idea, but I'm not at all happy with the
>implementation. It is too heavy and 'framework-ish', and the fact that it
>is a JSR or not doesn't change this. The 'component loading' service/idea
>is just great, but configuration, logging, etc are not that good idea.
>
It kinda grows on you. We're also moving in the right direction and
have some fine minds on the project. We've seen an influx of new talent
in the last month or so since posting the first 4.0 releases. Real
world companies are using Avalon as a framework now for true server
applications. Yes, Logkit is controvercial. That said, a server team
does not have to use it.
The JSR business will take time to pan out. There are competing
frameworks from HP and some others. The spec lead, Jon Maron, is HP guy
and apart from an accident when HP launched hardware with a press
release <paraphrase> "Preinstalled with Sun standard Java Services
Framework" </paraphrase>, all has been ticking along quite nicely. Jon
laughed like the rest of us at that was quick to apologize for the
overzealousness of their marketiing arm.
>But of course, I agree that tomcat should be usable with Avalon - after
>all that's one of our goals, to be 'embedable' and 'modular'.
>
:-)
Regards,
- Paul H
Re: Catalina on Avalon
Posted by cm...@yahoo.com.
On Tue, 16 Oct 2001, Paul Hammant wrote:
> OK, I've been asked to clarify a few things from various emails.
>
> 1) Separation of interface / impl ----> why?
I don't think you have to answer this ( at least not on tomcat-dev ) :-)
> 5) Resitance.
>
> Re : Remy's email on "Pauls Dream", and how he does not subscribe *at*
> *all* to the Avalon idea.
> Is this a common belief amongst committers to Apache? I might remind
> you that Avalon is a candidate for Sun's JSR 111 Community API. It
I love Avalon's concept and idea, but I'm not at all happy with the
implementation. It is too heavy and 'framework-ish', and the fact that it
is a JSR or not doesn't change this. The 'component loading' service/idea
is just great, but configuration, logging, etc are not that good idea.
But of course, I agree that tomcat should be usable with Avalon - after
all that's one of our goals, to be 'embedable' and 'modular'.
Costin
Re: Catalina on Avalon
Posted by Paul Speed <ps...@progeeks.com>.
Paul Hammant wrote:
>
> Craig,
>
> >>OK, I've been asked to clarify a few things from various emails.
> >>
> >>1) Separation of interface / impl ----> why?
> >>
> >>Well, consider Apache's flagship mail/news server JAMES. It might want
> >>to provide a web interface for, say, stats. It would be nice if it
> >>could hand Catalina a war file that contained all necessary to display
> >>such info. That war file app would use RMI or SOAP to invoke model
> >>method calls in JAMES. JAMES, during it's initialize() phase, would
> >>lookup Catalina internally and pass the URL to a WAR file to it. To do
> >>that it needs "the 39" interfaces visible to it's classloader. Those
> >>interfaces also need to be visible to Catalina. For both those cases,
> >>the classes must be made visible in the same classloader or the JVM will
> >>barf claiming they are not the same thing. Therefore separation needed
> >>as you clearly don't want implementation visible to possibly
> >>hostile/ropey server applications. Yes I know there is a
> >>http://localhost based web api for interaction with the machine, but
> >>that is definately second class.
> >>
> >
> >We're just talking alternatives and options here -- I'm not trying to
> >disagree. However, the JAMES initialization code would not actually need
> >any access at all to the Catalina classes in order to deploy it's webapp
> >-- it can use HTTP via the Manager webapp for this particular function.
> >
> Yes, but as I said that is a bit second class (no offence).
>
> >
> >
> >Now, of course, there are other situations where you really will need toe
> >core API classes in your classpath (i.e. if you were embedding Tomcat the
> >way that the J2EE RI does, for example).
> >
> >However, I'm still in dense mode -- OK, so you need the core API classes.
> >*Why* does it matter whether the package containing them is named
> >"org.apache.catalina" or "org.apache.catalina.api"? Exactly the same
> >number of classes ends up getting exposed (modulo some of the refactoring
> >that is also being discussed), and (other than import statements), your
> >code that utilizes the API is identical. This is the kind of change that
> >I would like to avoid unless there are compelling reasons.
> >
> It's not so much the package name, it's more that the interface(s) are
> in a parent package to the implementation. Placing in seperate jars
> would interfere with long term needs for sealing (again - sealing is not
> my strong point). There is also a minor need to remedy the imperfect
> separation of interface and impl (ref Costin : Date: Mon, 15 Oct 2001
> 19:51:19 -0700 (PDT) )
>
> I'm sure I could do a custom split of the 39 into a different jar and
> have them mounted at a higher classloader point now.... and it would all
> work. But when you folks play around with sealing, it would/could kill
> our wrapping of Catalina. Actually I'm not so sure, due to the
> imperfect separation.
>
> There is such *massive* resitance to any API fix, that I think I'll wait
> until 4.1 or whatever.
>
> Regards,
>
> - Paul H
Ok, I'm a long-time lurker and don't have that much familiarity
with Avalon... however, it seems to me that an Avalon-based set
of interfaces and adapter classes could fix the problem. The
interfaces could be loaded by a higher level class loader that
sits within scope of the whole framework and the adapter classes
could be loaded by the catalina class loader.
Yeah, I know it means possibly duplicating classes and interfaces,
etc... or at least ones that will look very similar. But it seems
to me that in the long run this would make you less dependent on
every little change to the catalina internal APIs.
Since I don't know much about Avalon and how it's used in practice,
my comments may be meaningless... but it certainly seems safer on
the surface to add an extra abstraction layer.
-Paul Speed
Re: Catalina on Avalon
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 16 Oct 2001, Paul Hammant wrote:
> >
> >However, I'm still in dense mode -- OK, so you need the core API classes.
> >*Why* does it matter whether the package containing them is named
> >"org.apache.catalina" or "org.apache.catalina.api"? Exactly the same
> >number of classes ends up getting exposed (modulo some of the refactoring
> >that is also being discussed), and (other than import statements), your
> >code that utilizes the API is identical. This is the kind of change that
> >I would like to avoid unless there are compelling reasons.
> >
> It's not so much the package name, it's more that the interface(s) are
> in a parent package to the implementation. Placing in seperate jars
> would interfere with long term needs for sealing (again - sealing is not
> my strong point).
As long as each package is completely stored in one and only one JAR file,
it doesn't matter (from a sealing perspective) that the interfaces are in
a parent package or not.
> There is also a minor need to remedy the imperfect
> separation of interface and impl (ref Costin : Date: Mon, 15 Oct 2001
> 19:51:19 -0700 (PDT) )
>
> I'm sure I could do a custom split of the 39 into a different jar and
> have them mounted at a higher classloader point now.... and it would all
> work. But when you folks play around with sealing, it would/could kill
> our wrapping of Catalina. Actually I'm not so sure, due to the
> imperfect separation.
>
> There is such *massive* resitance to any API fix, that I think I'll wait
> until 4.1 or whatever.
>
The cleanups needed to deal with sealing are totally independent of moving
"org.apache.catalina" --> "org.apache.catalina.api". I'm OK with fixing
the little stuff over time. I'm not OK with the massive change, which
doesn't even fix the potential problem with sealing that you are concerned
about (because the cross-package dependencies would still be there).
> Regards,
>
> - Paul H
>
>
Craig
Re: Catalina on Avalon
Posted by Paul Hammant <Pa...@yahoo.com>.
Craig,
>>OK, I've been asked to clarify a few things from various emails.
>>
>>1) Separation of interface / impl ----> why?
>>
>>Well, consider Apache's flagship mail/news server JAMES. It might want
>>to provide a web interface for, say, stats. It would be nice if it
>>could hand Catalina a war file that contained all necessary to display
>>such info. That war file app would use RMI or SOAP to invoke model
>>method calls in JAMES. JAMES, during it's initialize() phase, would
>>lookup Catalina internally and pass the URL to a WAR file to it. To do
>>that it needs "the 39" interfaces visible to it's classloader. Those
>>interfaces also need to be visible to Catalina. For both those cases,
>>the classes must be made visible in the same classloader or the JVM will
>>barf claiming they are not the same thing. Therefore separation needed
>>as you clearly don't want implementation visible to possibly
>>hostile/ropey server applications. Yes I know there is a
>>http://localhost based web api for interaction with the machine, but
>>that is definately second class.
>>
>
>We're just talking alternatives and options here -- I'm not trying to
>disagree. However, the JAMES initialization code would not actually need
>any access at all to the Catalina classes in order to deploy it's webapp
>-- it can use HTTP via the Manager webapp for this particular function.
>
Yes, but as I said that is a bit second class (no offence).
>
>
>Now, of course, there are other situations where you really will need toe
>core API classes in your classpath (i.e. if you were embedding Tomcat the
>way that the J2EE RI does, for example).
>
>However, I'm still in dense mode -- OK, so you need the core API classes.
>*Why* does it matter whether the package containing them is named
>"org.apache.catalina" or "org.apache.catalina.api"? Exactly the same
>number of classes ends up getting exposed (modulo some of the refactoring
>that is also being discussed), and (other than import statements), your
>code that utilizes the API is identical. This is the kind of change that
>I would like to avoid unless there are compelling reasons.
>
It's not so much the package name, it's more that the interface(s) are
in a parent package to the implementation. Placing in seperate jars
would interfere with long term needs for sealing (again - sealing is not
my strong point). There is also a minor need to remedy the imperfect
separation of interface and impl (ref Costin : Date: Mon, 15 Oct 2001
19:51:19 -0700 (PDT) )
I'm sure I could do a custom split of the 39 into a different jar and
have them mounted at a higher classloader point now.... and it would all
work. But when you folks play around with sealing, it would/could kill
our wrapping of Catalina. Actually I'm not so sure, due to the
imperfect separation.
There is such *massive* resitance to any API fix, that I think I'll wait
until 4.1 or whatever.
Regards,
- Paul H
Re: Catalina on Avalon
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 16 Oct 2001, Paul Hammant wrote:
> Date: Tue, 16 Oct 2001 09:49:28 +0100
> From: Paul Hammant <Pa...@yahoo.com>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Catalina on Avalon
>
> OK, I've been asked to clarify a few things from various emails.
>
> 1) Separation of interface / impl ----> why?
>
> Well, consider Apache's flagship mail/news server JAMES. It might want
> to provide a web interface for, say, stats. It would be nice if it
> could hand Catalina a war file that contained all necessary to display
> such info. That war file app would use RMI or SOAP to invoke model
> method calls in JAMES. JAMES, during it's initialize() phase, would
> lookup Catalina internally and pass the URL to a WAR file to it. To do
> that it needs "the 39" interfaces visible to it's classloader. Those
> interfaces also need to be visible to Catalina. For both those cases,
> the classes must be made visible in the same classloader or the JVM will
> barf claiming they are not the same thing. Therefore separation needed
> as you clearly don't want implementation visible to possibly
> hostile/ropey server applications. Yes I know there is a
> http://localhost based web api for interaction with the machine, but
> that is definately second class.
>
We're just talking alternatives and options here -- I'm not trying to
disagree. However, the JAMES initialization code would not actually need
any access at all to the Catalina classes in order to deploy it's webapp
-- it can use HTTP via the Manager webapp for this particular function.
Now, of course, there are other situations where you really will need toe
core API classes in your classpath (i.e. if you were embedding Tomcat the
way that the J2EE RI does, for example).
However, I'm still in dense mode -- OK, so you need the core API classes.
*Why* does it matter whether the package containing them is named
"org.apache.catalina" or "org.apache.catalina.api"? Exactly the same
number of classes ends up getting exposed (modulo some of the refactoring
that is also being discussed), and (other than import statements), your
code that utilizes the API is identical. This is the kind of change that
I would like to avoid unless there are compelling reasons.
(Snipping the rest of this thead 'cause this is the only issue I'm
concerned with.)
>
> - Paul H
>
Craig
Re: Catalina on Avalon
Posted by Paul Hammant <Pa...@yahoo.com>.
OK, I've been asked to clarify a few things from various emails.
1) Separation of interface / impl ----> why?
Well, consider Apache's flagship mail/news server JAMES. It might want
to provide a web interface for, say, stats. It would be nice if it
could hand Catalina a war file that contained all necessary to display
such info. That war file app would use RMI or SOAP to invoke model
method calls in JAMES. JAMES, during it's initialize() phase, would
lookup Catalina internally and pass the URL to a WAR file to it. To do
that it needs "the 39" interfaces visible to it's classloader. Those
interfaces also need to be visible to Catalina. For both those cases,
the classes must be made visible in the same classloader or the JVM will
barf claiming they are not the same thing. Therefore separation needed
as you clearly don't want implementation visible to possibly
hostile/ropey server applications. Yes I know there is a
http://localhost based web api for interaction with the machine, but
that is definately second class.
JAMES not enough? Well we have an Avalon dependant FtpServer too, that
might like to interoperate with Catalina too.
2) JBoss used as an positive example of why nothing needs to change.
I dont want to take anything away from JBoss, but it's J2EE server with
some frills. Avalon is a framework (and the JBoss team nearly used it a
year ago, excpet they were GPL then). We intend to have just about
every IETF/RFC based server concept running inside it. Or at least
/possible/ to run inside it. We must allow multiple implementations of
components and an admin or "assembler" person to lace them together as
they see fit.
Imagine a DNS Server that basic and is 10K in size. Imaging a bigger
drop-in replacement that can, via a webapp, illustrate stats or expose
an admin interface. For those we'd need a way to interact with the
Catalina API.
3) Avalon is flawed concept (inferred).
Agree to differ. A subset of us Avaloners want to see it possible for
everyone running every server comp in one machine. Given that J2ME is a
stopgap until limitations of small devices have been overcome, surely it
might be nice to have a resource sharing set of server applications
ready to run on those devices. These would include Tomcat/Catalina,
without Apache Server proxying calls through to it.
A clue to that future :-
- Lutris for Micro Server Architecture :
http://www.lutris.com/company/pressReleases/Press010907.html
- Savaje XE for J2SE in iPAQ :
http://www.savaje.com/products/savajexe.html
- Various Espial products : http://www.espial.com/main/page?view=f-home
Imagine a different thing -> A 1U server appliance that has 64
StrongArm chips for a highly load balanced/clustered server application
and all they are running is Java. Imagine an iPAQ that's network
visible serving things.
If you folks are thinking of Catalina as only running on a current
concept server, and that somehow the JVM will always be flakey so that
an "unstable" assertion is true, then you're really guilty of not
looking ahead ......... "640K is more than enough memory".
4) Package Sealing, 39 interfaces per se.
It seems to me that you should not seal org.apache.catalina in a jar
when sub-packages are in other jars. I'm not sure of that a a hierarchy
is special... it could be that it's exactly equivalent to completely
separate (in terms of namespace) packages.
Costin points out that the 39 interfaces and support classes are not
properly separated from their implementation. Petty of me to raise, but
true to point out that the curent impl is imperfect.
5) Resitance.
Re : Remy's email on "Pauls Dream", and how he does not subscribe *at*
*all* to the Avalon idea.
Is this a common belief amongst committers to Apache? I might remind
you that Avalon is a candidate for Sun's JSR 111 Community API. It
would be a shame if some other Company's API is accepted as the standard
(and dominates a server landscape) if the Apache community is seen to be
divided. Please remember I am not saying that Catalina should only run
inside Avalon, I'm suggesting a single codebase could deliver standalone
and Avalon dependant versions of Catalina.
6) Aims restated.
I'm hoping that ongoing development on Catalina is at least conscious of
Avalon. Maybe 4.0.1 is too late for anything. Maybe it's not as 4.0 is
brand new and real embeddors are few.
7) Exec summary.
*Please* folks, warm up to Avalon.... :-)
Regards,
- Paul H
Re: Catalina on Avalon
Posted by Paul Hammant <Pa...@yahoo.com>.
David & Craig,
Yes I agree, given explanations, that we can't change before a major
release. I like the migration solution expecially as it's to do with
interfaces and multiple inheritance (of sorts) works there. I am not
sure if the classloader might still barf if it can't resolve all hard
wired references though.
We could just seperate into seperate jars at this moment in time, but I
suspect that "package sealing" might be an issue. I'm not experienced
in that..
As it happens I've duplicated the pertinent interfaces to a non-Catalina
place and used refelction (at great pain) to invoke the actual APIs :-(
It works, but exception tracking sucks as reflection is in the way.
Regards,
- Paul H
>Don't -1 it. For each interface in the wrong spot,
>duplicate the interface in the right spot. Have
>existing implementations of old interfaces also
>implement the new interfaces. Deprecate the old
>interfaces, advertising their removal in 4.5, or
>some future ( but definite ) date. This is best-
>practice, if the JDK has anything to say about
>evolving an interface while maintaining backwards
>compatibility.
>
>That is a technical solution that takes away the
>'backward compatability' concern.
>
>Now, there are other concerns, like:
>
> - the effort concern
> - the maintenance concern
>
>that might come into play, but possibly creative
>approaches to these may be found too.
>
>However, I would not like to see:
>
> - the classloader concern
>
>be sidelined. Tomcat 4.0 is a flagship of
>server-side Java, and it, of all products, needs
>to get its stuff right. Tomcat 3.x has, quite
>frankly, an abysmal history with class-loading-related
>issues.
>
>Don't think of it in terms of making Avalon happy ...
>think of it in terms of Avalon having discovered an
>issue generic to all persons who wish to embed
>Catalina.
>
>Don't think of it as a pain in the neck either ...
>this issue is obviously one that needs to be thought
>of 'next time', and as such is deserving of analysis,
>and a quick entry in the 'new project FAQ'.
>
>cheers,
>David.
>
>
>On Sat, 13 Oct 2001, Craig R. McClanahan wrote:
>
>>On Sat, 13 Oct 2001, Paul Hammant wrote:
>>
>>>If those 39 interfaces and classes were moved to a different
>>>package (say org.apache.catalina.api), then a split into two jars would
>>>be possible and our dreams could come true.
>>>
>>>Have I convinced of need?
>>>
>>I can see why you might wish to have the "39 interfaces and support
>>classes" packaged in a separate JAR file. I haven't yet been convinced
>>why they should be moved to a different package, which would break 100% of
>>the applications that rely on the current package names.
>>
>>>Is 4.0.1 beta too touchy a distribution to instigate package migrations
>>>on (however trivial) ?
>>>
>>Definitely. In fact, I would -1 a package name change on *any* release in
>>the 4.0.x family -- backwards-incompatible changes that are this
>>substantial are bad news.
>>
>
>----
>David Bullock - dbullock@lisasoft.com +61 4 0290 1228
>http://www.lisasoft.com/ (Architect) http://www.auug.org.au/ (President, SA)
>http://www.ajug.org.au/sajug/sa.html (Activist) Sun Cert'd Programmer for Java 2
>
>"The key ingredients of success are a crystal-clear goal, a realistic attack plan to achieve that goal, and consistent, daily action to reach that goal."
>Steve Maguire, "Debugging the Development Process".
>
>
>
Re: Catalina on Avalon
Posted by co...@covalent.net.
On Tue, 16 Oct 2001, David Bullock wrote:
> On Mon, 15 Oct 2001, Remy Maucherat wrote:
>
> > > - *should* catalina packages be sealed? If so, why? If not, why not?
> >
> > No, why ?
>
> Well, I would say that sealing is a great and necessary concept
> from a security perspective. I haven't been involved in any
> discussions about the merits or otherwise of sealing, so this is
> a personal conclusion from reading and thinking about classloaders
> and security.
The main benefit of sealing is that it prevent a whole category of
exploits. There are many cases where the compiler generates a
package-protected field ( for sure in internal classes ), and the only way
to protect against it is via sealing.
The only argument against sealing is that it exposes bugs in the class
loaders, but IMHO it's better to fix the bugs than disable sealing.
> I'm not trying to point the finger at Tomcat in particular ... sealing is
> a new idea that is going to affect how we design things, and it's not
> generally well-understood what the impacts are yet.
Sealing has been around since JDK1.2, not quite new idea. The impact is
pretty clear, I think - it prevent mixing versions ( which would create
far bigger problems if undetected ), expose bugs in class loaders and
prevent some security exploits.
Costin
( a big supporter of sealing )
( BTW, the 39 classes and interfaces are a bit more than 39 - as they have
dependencies on the classes that implement them, spaghetti-style, and
moving them might also help cleaning some of the mess. However, with few
changes it is possible to separate them the way you want - at least I was
able to do it. )
Re: Catalina on Avalon
Posted by David Bullock <db...@lisasoft.com>.
On Mon, 15 Oct 2001, Remy Maucherat wrote:
> > - *should* catalina packages be sealed? If so, why? If not, why not?
>
> No, why ?
Well, I would say that sealing is a great and necessary concept
from a security perspective. I haven't been involved in any
discussions about the merits or otherwise of sealing, so this is
a personal conclusion from reading and thinking about classloaders
and security.
More about this below.
> > ( And by the way, I expect nothing but reasonableness from
> > you, based on your longtime conduct on this and other lists,
> > so I wouldn't even think of reading your mail with a snide
> > tone.
> > )
>
> Great, you're not expecting anything from me then ;-)
:-)
> Doing what you suggest would cause us lots of trouble,
Granted. I'm not suggesting you rush it out in 4.0.x ... maybe 4.2
> for no benefit.
> I don't share Paul's "dream" (because I don't really see the point of running
> all deamons in the same process - it may save some memory, but I would think
> it makes everything more crash prone,
Hmm ... this is 'religious', but I must admit that I do find the notion of
a separate JVM for every Java app somewhat offensive. True, it has good
isolation, but that isolation comes at considerable and unnecesary expense.
It *should* be *possible* to run separate apps in a single JVM without any
risk of them stepping on each other's toes. The use of sealed packages is
basically the only reasonable way to effect this intra-VM isolation. The
old 'delegate then look' behaviour of the JDK just does not work. The newer
'check packaging, then look, then delegate' behaviour makes sense, but the
key to doing it securely is the 'check packaging' step. Otherwise, as you
say, it *does* make everything more crash prone.
Now it is possible that there is something wrong with sealing ... that it
doesn't cater to all scenarios. Perhaps the 'sealed' attribute should be
specified in the security policy, rather than in each individual .jar file,
so that the administrator of a system has (more) freedom to allow trusted
code to violate sealing principles for good reasons.
This is a good argument for changing how sealing is achieved. Not a good
argument for avoiding sealing, IMHO.
I'm not trying to point the finger at Tomcat in particular ... sealing is
a new idea that is going to affect how we design things, and it's not
generally well-understood what the impacts are yet.
All I'm saying is that Tomcat should be setting the pace. ;-)
Assuming my reasoning holds thus far, and the utility of sealing is
accepted, we now ask, what is gained by sealing the interfaces of Tomcat in
a separate package, to be loaded by one classloader, and putting the
sealed/unsealed implementations of those interfaces in another
classloader, actually gain?
I think Paul should explain himself more clearly on this.
> and probably less scalable because of
> GC),
Yeah, although as of JDK 1.3.1, the GC is good enough to cope with heaps
of about 1GB without too much trouble, and they are working on asynch GC.
Again, it would be nice if the system administrator, who does have access
to actual hardware config and usage patterns, is free to make this decision.
> Besides, many people have already embedded Tomcat 4.0, like the J2EE RI and
> jBoss.
Fair point. I guess I can only say that they are not trying to do
quite the same thing as Avalon, and so Avalon's case should at least be
properly discussed.
cheers,
David.
----
David Bullock - dbullock@lisasoft.com +61 4 0290 1228
http://www.lisasoft.com/ (Architect) http://www.auug.org.au/ (President, SA)
http://www.ajug.org.au/sajug/sa.html (Activist) Sun Cert'd Programmer for Java 2
"The key ingredients of success are a crystal-clear goal, a realistic attack plan to achieve that goal, and consistent, daily action to reach that goal."
Steve Maguire, "Debugging the Development Process".
Re: Catalina on Avalon
Posted by Remy Maucherat <rm...@home.com>.
> Craig,
>
> I was thinking of the 'which classloader defines this package?'
> (ie. sealing) issue. I agree that if that issue is not there,
> then there is no need for changing the package the interfaces
> belong to.
>
> I guess the two questions now are:
>
> - *should* catalina packages be sealed? If so, why? If not, why not?
No, why ?
> - what other advantages does Paul Hammat see in repackaging?
>
> ( And by the way, I expect nothing but reasonableness from
> you, based on your longtime conduct on this and other lists,
> so I wouldn't even think of reading your mail with a snide
> tone.
> )
Great, you're not expecting anything from me then ;-)
Doing what you suggest would cause us lots of trouble, for no benefit. I
don't share Paul's "dream" (because I don't really see the point of running
all deamons in the same process - it may save some memory, but I would think
it makes everything more crash prone, and probably less scalable because of
GC), but I don't see any problem with the current packaging.
Besides, many people have already embedded Tomcat 4.0, like the J2EE RI and
jBoss.
So -1 for changing the package of the interfaces in 4.x.
Some info on classloading in Tomcat 4.0.1:
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html
Remy
Re: Catalina on Avalon
Posted by cm...@yahoo.com.
On Mon, 15 Oct 2001, Remy Maucherat wrote:
> > Or at least make sure the 39 classes do not depend on the remaining
> > classes, which is the case today.
>
> Great. Now, if you look carefully, you'll see that the only problems:
> - Cluster depends on classes from the cluster package; that is indeed not
> consistent with the design
> - Two depend on DefaultContext; a new DefaultContext interface (as well as a
> standard implementation for it) should have been added; we could do it for
> 4.1
> - Others depend on utility beans from deploy (for the J2EE deployment
> objects), as well as a few util classes; that looks fine to me
>
> These issues were added as the development went on, and I think can be
> considered as minor cleaness issues.
>
> But of course, since you're on a crusade, I guess you're only out there to
> bad mouth TC 4 ...
> Sad sad ...
What's sad is seeing history repeat itself - those beeing on this list for
>2 years may remember tomcat3.0 and its first release and the reaction to
anyone pointing problems.
I do hope we'll find a Sam Ruby around us, and history will continue
to repeat. Well, the crusade to refactor 3.0 and answer the critics by
solving the problems have just finished and I'm pretty proud with the
results and the fact I've been among those who did this.
Going back to technical talk, right now the 39 classes depend on a lot
more, the dependencies go very deep.
However, I found one point where by making 2 small changes ( backward
compatible ) you can cut this and get a core of around 80 classes.
Reducing this number would be very hard, as the dependnecies are in
documented public methods ( i.e. signatures ), however you can still
separate most of the implementation.
Costin
diff -r ./Context.java
/ws/40/catalina/src/share/org/apache/catalina/Context.java
79d78
< import org.apache.catalina.deploy.ResourceParams;
1028,1039d1026
<
< /**
< * Enables or disables naming.
< */
< public void setUseNaming(boolean useNaming);
<
< /**
< * Add resource parameters for this web application.
< *
< * @param resourceParameters New resource parameters
< */
< public void addResourceParams(ResourceParams resourceParameters);
diff -r ./core/DefaultContext.java
/ws/40/catalina/src/share/org/apache/catalina/core/DefaultContext.java
1171,1173c1171,1172
< // if( context instanceof StandardContext )
< // ((StandardContext)context).setUseNaming(isUseNaming());
< context.setUseNaming(isUseNaming());
---
> if( context instanceof StandardContext )
> ((StandardContext)context).setUseNaming(isUseNaming());
1209,1215c1208,1213
< // if( context instanceof StandardContext ) {
< ResourceParams [] resourceParams = findResourceParams();
< for( int i = 0; i < resourceParams.length; i++ ) {
< // ((StandardContext)context).addResourceParams(resourceParams[i]);
< context.addResourceParams(resourceParams[i]);
< // }
< }
---
> if( context instanceof StandardContext ) {
> ResourceParams [] resourceParams = findResourceParams();
> for( int i = 0; i < resourceParams.length; i++ ) {
> ((StandardContext)context).addResourceParams(resourceParams[i]);
> }
> }
Re: Catalina on Avalon
Posted by Remy Maucherat <rm...@home.com>.
> On Mon, 15 Oct 2001, Remy Maucherat wrote:
>
> I think my opinion about the design of TC4 is well known, however I have
> to live with it - like many other people.
>
> What's sad is seeing history repeat itself - those beeing on this list for
> >2 years may remember tomcat3.0 and his first release and the reaction to
> anyone pointing problems.
>
> I do hope we'll find a Sam Ruby around us and I do hope at least
> some people take the critics
I thought I was quite clear that my comments were targetted at this comment:
<quote>
( BTW, the 39 classes and interfaces are a bit more than 39 - as they have
dependencies on the classes that implement them, spaghetti-style, and
moving them might also help cleaning some of the mess. However, with few
changes it is possible to separate them the way you want - at least I was
able to do it. )
</quote>
I may have overreacted, but I am totally fed up by your never ending stream
of comments like this.
I can't figure out what Sam has to do with that (except maybe to advise you
to stop posting stuff like that if you really want to avoid flames).
I think it's perfectly justified to veto an API change which will offer very
little benefits, while causing lots of trouble for a lot of people. So
again, I don't see what is against the Jakarta bylaws here.
> and do fix the problems instead of flaming those
> who point the problems - at least that's what I tried to do refactoring
> 3.0 up to 3.3.
- We can try to fix the problems I mentioned in 4.1, since that will have
little impact:
* Cluster depends on classes from the cluster package; that is indeed not
consistent with the design
* Two depend on DefaultContext; a new DefaultContext interface (as well as
a
standard implementation for it) should have been added
- I consider that API stability is the most important goal; API perfection
is a non-goal
Remy
Re: Catalina on Avalon
Posted by co...@covalent.net.
On Mon, 15 Oct 2001, Remy Maucherat wrote:
> > Or at least make sure the 39 classes do not depend on the remaining
> > classes, which is the case today.
>
> Great. Now, if you look carefully, you'll see that the only problems:
> - Cluster depends on classes from the cluster package; that is indeed not
> consistent with the design
> - Two depend on DefaultContext; a new DefaultContext interface (as well as a
> standard implementation for it) should have been added; we could do it for
> 4.1
> - Others depend on utility beans from deploy (for the J2EE deployment
> objects), as well as a few util classes; that looks fine to me
>
> These issues were added as the development went on, and I think can be
> considered as minor cleaness issues.
>
> But of course, since you're on a crusade, I guess you're only out there to
> bad mouth TC 4 ...
> Sad sad ...
I think my opinion about the design of TC4 is well known, however I have
to live with it - like many other people.
What's sad is seeing history repeat itself - those beeing on this list for
>2 years may remember tomcat3.0 and his first release and the reaction to
anyone pointing problems.
I do hope we'll find a Sam Ruby around us and I do hope at least
some people take the critics and do fix the problems instead of flaming those
who point the problems - at least that's what I tried to do refactoring
3.0 up to 3.3.
Costin
Re: Catalina on Avalon
Posted by Remy Maucherat <rm...@home.com>.
> On Mon, 15 Oct 2001, Craig R. McClanahan wrote:
>
> That's true - the classes in org.apache... are protected by the class
> loader, so it is probably not needed.
>
>
> > In addition, my understanding of sealing says that we could seal
> > "org.apache.catalina" by creating a JAR file that contains only those 39
> > classes and interfaces (and sealing it), without messing with any of the
> > remainder of the implementation classes -- and without changing the
> > package hierarchy at all. (I tend to get pretty focused on backwards
> > compatibility, having been bitten a few times.)
>
> Or at least make sure the 39 classes do not depend on the remaining
> classes, which is the case today.
Great. Now, if you look carefully, you'll see that the only problems:
- Cluster depends on classes from the cluster package; that is indeed not
consistent with the design
- Two depend on DefaultContext; a new DefaultContext interface (as well as a
standard implementation for it) should have been added; we could do it for
4.1
- Others depend on utility beans from deploy (for the J2EE deployment
objects), as well as a few util classes; that looks fine to me
These issues were added as the development went on, and I think can be
considered as minor cleaness issues.
But of course, since you're on a crusade, I guess you're only out there to
bad mouth TC 4 ...
Sad sad ...
Remy
Re: Catalina on Avalon
Posted by Remy Maucherat <rm...@home.com>.
> On Mon, 15 Oct 2001 cmanolache@yahoo.com wrote:
>
> Those dependencies fall into these categories:
>
> * "org.apache.catalina.Cluster" depends on three classes from
> package "org.apadhe.catalina.cluster". Because this is new
> and experimental code, I don't see as big a problem refactoring
> here. Suggestions?
>
> * "org.apache.catalina.Connector" depends on class
> "org.apache.catalina.net.ServerSocketFactory", which could be
> moved into the "org.apache.catalina" package fairly easily.
>
> * "org.apache.catalina.{Context,Engine,Host}" depend on deployment
> configuration classes in package "org.apache.catalina.deploy".
> If the "org.apache.catalina" class were to be copied into a
> separate JAR, this package should be placed there as well.
> Otherwise, it would be confusing to combine them. (None of
> these classes import anything else except RequestUtil, which
> could be examined for factoring/copying whatever the "o.a.c.deploy"
> package needs
I would put all these packages together to solve this, at least for the
immediate future:
- org.apache.catalina
- org.apache.catalina.cluster (some other interfaces depend on cluster at
the moment)
- org.apache.catalina.util
- org.apache.catalina.net
- org.apache.catalina.deploy
> * "org.apache.catalina.{Engine,Host}" depend on class
> "org.apache.catalina.core.DefaultContext" which should have been
> created as an interface in the top-level package, with a corresponding
> implementation in "o.a.c.core". This can be refactored pretty easily.
That one is a mistake and should be fixed.
> I'd still prefer to do things like this on the HEAD branch only.
+1.
Remy
Re: Catalina on Avalon
Posted by co...@covalent.net.
On Tue, 16 Oct 2001, Craig R. McClanahan wrote:
> Those dependencies fall into these categories:
>
> * "org.apache.catalina.Cluster" depends on three classes from
> package "org.apadhe.catalina.cluster". Because this is new
> and experimental code, I don't see as big a problem refactoring
> here. Suggestions?
If Cluster is not used by anything else - move it to catalina.cluster.
Experimental code shouldn't be in the core set of interfaces ( and we go
down to 38 ). When the code is stable and if this is indeed something
that needs to be done in the core, and not in a module, it can be added
back.
> * "org.apache.catalina.Connector" depends on class
> "org.apache.catalina.net.ServerSocketFactory", which could be
> moved into the "org.apache.catalina" package fairly easily.
Or the dependency removed - since not all connectors are based
on a Socket ( for example the jk JNI connector ). Both solutions
are fine, but backward incompatible.
An alternative is to keep net.ServerSocketFactory and include it
in the core set ( like deploy ).
> * "org.apache.catalina.{Context,Engine,Host}" depend on deployment
> configuration classes in package "org.apache.catalina.deploy".
> If the "org.apache.catalina" class were to be copied into a
> separate JAR, this package should be placed there as well.
> Otherwise, it would be confusing to combine them. (None of
> these classes import anything else except RequestUtil, which
> could be examined for factoring/copying whatever the "o.a.c.deploy"
> package needs.
That's my conclusion as well - catalina.deploy can't be easily separated.
> * "org.apache.catalina.{Engine,Host}" depend on class
> "org.apache.catalina.core.DefaultContext" which should have been
> created as an interface in the top-level package, with a corresponding
> implementation in "o.a.c.core". This can be refactored pretty easily.
DefaultContext then depend on few other classes on catalina.core, which in
turn depend to almost everything else.
That's the biggest problem ( from my point of view ), and the solution is
simple ( adding 2 methods in Context interface to eliminate the cast to
StandardContext ).
> I'd still prefer to do things like this on the HEAD branch only.
The last one ( braking the dependency in DefaultContext - which creates
the biggest problem as it goes very deep ) should and can be done in 4.0,
as it is backward compatible ( adding 2 methods and changing impl. doesn't
brake compatibility ).
Removing Cluster could be done as well, if it is experimental. This
should be a module in any case.
The big question is if 4.1 will be backward compatible with 4.0 or not.
If you do start moving around net.SocketFactory and change public methods
in core - it'll clearly not be. That's not necesary a big problem, but
must be clearly decided ( by vote ).
My preference would be to fix what can be fixed in 4.0.x, keeping backward
compatibility. Getting the changes to make load-balancing work ( the JK
route ) and some other fixes on the stable version is pretty important. If
for 4.1 we do deeper fixes and improvements - great, but that's far away
and we haven't even started to discuss it.
Costin
Re: Catalina on Avalon
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 15 Oct 2001 cmanolache@yahoo.com wrote:
> Date: Mon, 15 Oct 2001 21:03:48 -0700 (PDT)
> From: cmanolache@yahoo.com
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Catalina on Avalon
>
> On Mon, 15 Oct 2001, Craig R. McClanahan wrote:
>
> > > I guess the two questions now are:
> > >
> > > - *should* catalina packages be sealed? If so, why? If not, why not?
> > > - what other advantages does Paul Hammat see in repackaging?
> > >
> >
> > Sealing can help in an environment where you cannot control what other
> > code gets loaded by the same class loader. In this particular case (using
> > the standard Tomcat distribution hierarchy), the system administrator of a
> > Tomcat 4 installation is totally in control of what code goes here, by
> > virtue of their control over the /server/{classes,lib} and
> > /common/{classes,lib} directories. It may or may not be different when
> > you package Tomcat under (or over -- can never get the directions right
> > :-) something like Avalon.
>
> That's true - the classes in org.apache... are protected by the class
> loader, so it is probably not needed.
>
>
> > In addition, my understanding of sealing says that we could seal
> > "org.apache.catalina" by creating a JAR file that contains only those 39
> > classes and interfaces (and sealing it), without messing with any of the
> > remainder of the implementation classes -- and without changing the
> > package hierarchy at all. (I tend to get pretty focused on backwards
> > compatibility, having been bitten a few times.)
>
> Or at least make sure the 39 classes do not depend on the remaining
> classes, which is the case today.
>
Those dependencies fall into these categories:
* "org.apache.catalina.Cluster" depends on three classes from
package "org.apadhe.catalina.cluster". Because this is new
and experimental code, I don't see as big a problem refactoring
here. Suggestions?
* "org.apache.catalina.Connector" depends on class
"org.apache.catalina.net.ServerSocketFactory", which could be
moved into the "org.apache.catalina" package fairly easily.
* "org.apache.catalina.{Context,Engine,Host}" depend on deployment
configuration classes in package "org.apache.catalina.deploy".
If the "org.apache.catalina" class were to be copied into a
separate JAR, this package should be placed there as well.
Otherwise, it would be confusing to combine them. (None of
these classes import anything else except RequestUtil, which
could be examined for factoring/copying whatever the "o.a.c.deploy"
package needs.
* "org.apache.catalina.{Engine,Host}" depend on class
"org.apache.catalina.core.DefaultContext" which should have been
created as an interface in the top-level package, with a corresponding
implementation in "o.a.c.core". This can be refactored pretty easily.
I'd still prefer to do things like this on the HEAD branch only.
>
> Costin
>
>
Craig
Re: Catalina on Avalon
Posted by cm...@yahoo.com.
On Mon, 15 Oct 2001, Craig R. McClanahan wrote:
> > I guess the two questions now are:
> >
> > - *should* catalina packages be sealed? If so, why? If not, why not?
> > - what other advantages does Paul Hammat see in repackaging?
> >
>
> Sealing can help in an environment where you cannot control what other
> code gets loaded by the same class loader. In this particular case (using
> the standard Tomcat distribution hierarchy), the system administrator of a
> Tomcat 4 installation is totally in control of what code goes here, by
> virtue of their control over the /server/{classes,lib} and
> /common/{classes,lib} directories. It may or may not be different when
> you package Tomcat under (or over -- can never get the directions right
> :-) something like Avalon.
That's true - the classes in org.apache... are protected by the class
loader, so it is probably not needed.
> In addition, my understanding of sealing says that we could seal
> "org.apache.catalina" by creating a JAR file that contains only those 39
> classes and interfaces (and sealing it), without messing with any of the
> remainder of the implementation classes -- and without changing the
> package hierarchy at all. (I tend to get pretty focused on backwards
> compatibility, having been bitten a few times.)
Or at least make sure the 39 classes do not depend on the remaining
classes, which is the case today.
Costin
Re: Catalina on Avalon
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 16 Oct 2001, David Bullock wrote:
> Date: Tue, 16 Oct 2001 10:00:18 +0930 (CST)
> From: David Bullock <db...@lisasoft.com>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Catalina on Avalon
>
> Craig,
>
> I was thinking of the 'which classloader defines this package?'
> (ie. sealing) issue. I agree that if that issue is not there,
> then there is no need for changing the package the interfaces
> belong to.
>
> I guess the two questions now are:
>
> - *should* catalina packages be sealed? If so, why? If not, why not?
> - what other advantages does Paul Hammat see in repackaging?
>
Sealing can help in an environment where you cannot control what other
code gets loaded by the same class loader. In this particular case (using
the standard Tomcat distribution hierarchy), the system administrator of a
Tomcat 4 installation is totally in control of what code goes here, by
virtue of their control over the /server/{classes,lib} and
/common/{classes,lib} directories. It may or may not be different when
you package Tomcat under (or over -- can never get the directions right
:-) something like Avalon.
Sealing really messes you up when it is entirely possible that a package
might legitimately be defined in more than one place. We've had a case of
that with Tomcat 4 as well -- when the JAXP/1.1 release, which was sealed,
was in "$CATALINA_HOME/lib" and the web app wanted to use Xerces and
placed it in the /WEB-INF/lib subdirectory.
In addition, my understanding of sealing says that we could seal
"org.apache.catalina" by creating a JAR file that contains only those 39
classes and interfaces (and sealing it), without messing with any of the
remainder of the implementation classes -- and without changing the
package hierarchy at all. (I tend to get pretty focused on backwards
compatibility, having been bitten a few times.)
> ( And by the way, I expect nothing but reasonableness from
> you, based on your longtime conduct on this and other lists,
> so I wouldn't even think of reading your mail with a snide
> tone.
> )
Well, I'm glad that you find my general behavior reasonable :-). Due to
the limitations of email as a communications means, I try to reread just
the words of my messages before hitting send -- and it's entirely possible
that my remark could be construed differently than my intent (which was
definitely to seriously ask the question).
>
> regards,
> David.
>
Craig
>
>
> On Mon, 15 Oct 2001, Craig R. McClanahan wrote:
>
> > AFAIK there hasn't been any description of any benefit (even for Avalon)
> > of changing the package names of the interfaces. JAR packaging seems to
> > address the rationale presented in the original message, so why should
> > anything be changed at all?
> >
> > (That's a serious question, not a snide comment.)
> >
> > Craig
> >
> > PS: Sealing violations are only an issue in the following circumstances:
> > * You seal your JARs (currently we don't)
> > * You implement classes of the same package (org.apache.catalina for the
> > purposes of this discussion) in different JAR files.
>
>
>
>
> ----
> David Bullock - dbullock@lisasoft.com +61 4 0290 1228
> http://www.lisasoft.com/ (Architect) http://www.auug.org.au/ (President, SA)
> http://www.ajug.org.au/sajug/sa.html (Activist) Sun Cert'd Programmer for Java 2
>
> "The key ingredients of success are a crystal-clear goal, a realistic attack plan to achieve that goal, and consistent, daily action to reach that goal."
> Steve Maguire, "Debugging the Development Process".
>
>
>
Re: Catalina on Avalon
Posted by David Bullock <db...@lisasoft.com>.
Craig,
I was thinking of the 'which classloader defines this package?'
(ie. sealing) issue. I agree that if that issue is not there,
then there is no need for changing the package the interfaces
belong to.
I guess the two questions now are:
- *should* catalina packages be sealed? If so, why? If not, why not?
- what other advantages does Paul Hammat see in repackaging?
( And by the way, I expect nothing but reasonableness from
you, based on your longtime conduct on this and other lists,
so I wouldn't even think of reading your mail with a snide
tone.
)
regards,
David.
On Mon, 15 Oct 2001, Craig R. McClanahan wrote:
> AFAIK there hasn't been any description of any benefit (even for Avalon)
> of changing the package names of the interfaces. JAR packaging seems to
> address the rationale presented in the original message, so why should
> anything be changed at all?
>
> (That's a serious question, not a snide comment.)
>
> Craig
>
> PS: Sealing violations are only an issue in the following circumstances:
> * You seal your JARs (currently we don't)
> * You implement classes of the same package (org.apache.catalina for the
> purposes of this discussion) in different JAR files.
----
David Bullock - dbullock@lisasoft.com +61 4 0290 1228
http://www.lisasoft.com/ (Architect) http://www.auug.org.au/ (President, SA)
http://www.ajug.org.au/sajug/sa.html (Activist) Sun Cert'd Programmer for Java 2
"The key ingredients of success are a crystal-clear goal, a realistic attack plan to achieve that goal, and consistent, daily action to reach that goal."
Steve Maguire, "Debugging the Development Process".
Re: Catalina on Avalon
Posted by "Craig R. McClanahan" <cr...@apache.org>.
AFAIK there hasn't been any description of any benefit (even for Avalon)
of changing the package names of the interfaces. JAR packaging seems to
address the rationale presented in the original message, so why should
anything be changed at all?
(That's a serious question, not a snide comment.)
Craig
PS: Sealing violations are only an issue in the following circumstances:
* You seal your JARs (currently we don't)
* You implement classes of the same package (org.apache.catalina for the
purposes of this discussion) in different JAR files.
On Sun, 14 Oct 2001, David Bullock wrote:
> Date: Sun, 14 Oct 2001 15:04:13 +0930 (CST)
> From: David Bullock <db...@lisasoft.com>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Catalina on Avalon
>
> Don't -1 it. For each interface in the wrong spot,
> duplicate the interface in the right spot. Have
> existing implementations of old interfaces also
> implement the new interfaces. Deprecate the old
> interfaces, advertising their removal in 4.5, or
> some future ( but definite ) date. This is best-
> practice, if the JDK has anything to say about
> evolving an interface while maintaining backwards
> compatibility.
>
> That is a technical solution that takes away the
> 'backward compatability' concern.
>
> Now, there are other concerns, like:
>
> - the effort concern
> - the maintenance concern
>
> that might come into play, but possibly creative
> approaches to these may be found too.
>
> However, I would not like to see:
>
> - the classloader concern
>
> be sidelined. Tomcat 4.0 is a flagship of
> server-side Java, and it, of all products, needs
> to get its stuff right. Tomcat 3.x has, quite
> frankly, an abysmal history with class-loading-related
> issues.
>
> Don't think of it in terms of making Avalon happy ...
> think of it in terms of Avalon having discovered an
> issue generic to all persons who wish to embed
> Catalina.
>
> Don't think of it as a pain in the neck either ...
> this issue is obviously one that needs to be thought
> of 'next time', and as such is deserving of analysis,
> and a quick entry in the 'new project FAQ'.
>
> cheers,
> David.
>
>
> On Sat, 13 Oct 2001, Craig R. McClanahan wrote:
>
> > On Sat, 13 Oct 2001, Paul Hammant wrote:
> >
> > > If those 39 interfaces and classes were moved to a different
> > > package (say org.apache.catalina.api), then a split into two jars would
> > > be possible and our dreams could come true.
> > >
> > > Have I convinced of need?
> > >
> >
> > I can see why you might wish to have the "39 interfaces and support
> > classes" packaged in a separate JAR file. I haven't yet been convinced
> > why they should be moved to a different package, which would break 100% of
> > the applications that rely on the current package names.
> >
> > > Is 4.0.1 beta too touchy a distribution to instigate package migrations
> > > on (however trivial) ?
> > >
> >
> > Definitely. In fact, I would -1 a package name change on *any* release in
> > the 4.0.x family -- backwards-incompatible changes that are this
> > substantial are bad news.
>
> ----
> David Bullock - dbullock@lisasoft.com +61 4 0290 1228
> http://www.lisasoft.com/ (Architect) http://www.auug.org.au/ (President, SA)
> http://www.ajug.org.au/sajug/sa.html (Activist) Sun Cert'd Programmer for Java 2
>
> "The key ingredients of success are a crystal-clear goal, a realistic attack plan to achieve that goal, and consistent, daily action to reach that goal."
> Steve Maguire, "Debugging the Development Process".
>
>
Re: Catalina on Avalon
Posted by David Bullock <db...@lisasoft.com>.
Don't -1 it. For each interface in the wrong spot,
duplicate the interface in the right spot. Have
existing implementations of old interfaces also
implement the new interfaces. Deprecate the old
interfaces, advertising their removal in 4.5, or
some future ( but definite ) date. This is best-
practice, if the JDK has anything to say about
evolving an interface while maintaining backwards
compatibility.
That is a technical solution that takes away the
'backward compatability' concern.
Now, there are other concerns, like:
- the effort concern
- the maintenance concern
that might come into play, but possibly creative
approaches to these may be found too.
However, I would not like to see:
- the classloader concern
be sidelined. Tomcat 4.0 is a flagship of
server-side Java, and it, of all products, needs
to get its stuff right. Tomcat 3.x has, quite
frankly, an abysmal history with class-loading-related
issues.
Don't think of it in terms of making Avalon happy ...
think of it in terms of Avalon having discovered an
issue generic to all persons who wish to embed
Catalina.
Don't think of it as a pain in the neck either ...
this issue is obviously one that needs to be thought
of 'next time', and as such is deserving of analysis,
and a quick entry in the 'new project FAQ'.
cheers,
David.
On Sat, 13 Oct 2001, Craig R. McClanahan wrote:
> On Sat, 13 Oct 2001, Paul Hammant wrote:
>
> > If those 39 interfaces and classes were moved to a different
> > package (say org.apache.catalina.api), then a split into two jars would
> > be possible and our dreams could come true.
> >
> > Have I convinced of need?
> >
>
> I can see why you might wish to have the "39 interfaces and support
> classes" packaged in a separate JAR file. I haven't yet been convinced
> why they should be moved to a different package, which would break 100% of
> the applications that rely on the current package names.
>
> > Is 4.0.1 beta too touchy a distribution to instigate package migrations
> > on (however trivial) ?
> >
>
> Definitely. In fact, I would -1 a package name change on *any* release in
> the 4.0.x family -- backwards-incompatible changes that are this
> substantial are bad news.
----
David Bullock - dbullock@lisasoft.com +61 4 0290 1228
http://www.lisasoft.com/ (Architect) http://www.auug.org.au/ (President, SA)
http://www.ajug.org.au/sajug/sa.html (Activist) Sun Cert'd Programmer for Java 2
"The key ingredients of success are a crystal-clear goal, a realistic attack plan to achieve that goal, and consistent, daily action to reach that goal."
Steve Maguire, "Debugging the Development Process".
Re: Catalina on Avalon
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 13 Oct 2001, Paul Hammant wrote:
> Date: Sat, 13 Oct 2001 16:40:44 +0100
> From: Paul Hammant <Pa...@yahoo.com>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: Catalina on Avalon
>
> Hi folks,
>
> As mentioned some weeks ago, I have Catalina more or less working inside
> Avalon. In short this means it can run inside the same virtual machine
> as JAMES (mail server) FtpServer (another Avalon app) and other servers.
> See picture at this link : http://jakarta.apache.org/avalon/phoenix/
>
> Request :
>
> Summary : Seperation of interfaces and implementation. Different
> jars in same ditribution.
>
> Detail : There are 39 interfaces & support classes in
> org.apache.catalina. Sub packages of that implement those abstractions.
> It's a very neat design apart from one thing. They are all in the same
> jar file and hence classloader. In Avalon we mount classloaders one or
> two levels deeper than the primordial that would load the core of
> Catalina if launched from a shell. We'd like to be able to mount the
> interfaces at top level for general visibility and sharing, and
> implementation, like other server applications in a branch/leaf class
> loader. If those 39 interfaces and classes were moved to a different
> package (say org.apache.catalina.api), then a split into two jars would
> be possible and our dreams could come true.
>
> Have I convinced of need?
>
I can see why you might wish to have the "39 interfaces and support
classes" packaged in a separate JAR file. I haven't yet been convinced
why they should be moved to a different package, which would break 100% of
the applications that rely on the current package names.
> Is 4.0.1 beta too touchy a distribution to instigate package migrations
> on (however trivial) ?
>
Definitely. In fact, I would -1 a package name change on *any* release in
the 4.0.x family -- backwards-incompatible changes that are this
substantial are bad news.
> Regards,
>
> - Paul H
>
>
Crig