cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@infoplanning.com>
Subject Re: What are the XSP design goals?
Date Fri, 02 Jun 2000 18:35:16 GMT


Stefano Mazzocchi wrote:

> Ok, the main constraint is Java 1.1, if we remove that, all classloading
> problems are instantly removed and we can have our own beautiful
> classloader with all fancy strings attached.
>
> If not, there is no way out: you have to modify your classpaht.

Aha!  This is the first time I've seen anything reasonable proposed in that
regard.

> > I am
> > trying, as best I can to help C2 blow the socks off of everybody who
> > has used C1.  Those of you who spend a fair amount of time in the
> > Cocoon-users list *know* that one of the sticky points is setting up
> > C1 correctly with XYZ servlet engine.  There is always the problem
> > of where to stick the jars and which classpath to set, and the inevitable
> > issues with classpath ordering and the multiple XML parsers out there.
>
> The installation procedure should be improved, I'm totally with you on
> that. "how" is the real issue.
>
> > We have the potential to be able to aleviate 9 out of 10 questions by
> > making C2 behave as a servlet.  I want to be able to upgrade from
> > C2.0 to C2.1 without restarting my web server.
>
> Oh, shit, that's a nasty one :)

*Technically, if the servlet is auto-loadable, by overwriting the old jar
in WEB-INF/lib, the old servlet will finish handling whatever requests
it has, and new requests will be handled by the new servlet.

My understanding is based on the O'Reilly Java Servlets book--exact
location is fuzzy 'cause its been a few months since I read it (and it's
already out of date--based on Servlet 2.0 spec)--that the auto-reloading
functionality that I just described is one of the core design principles
behind the technology.

> Here are my reasoning:
>
> 1) this project voted to keep C2's core Java 1.1 compatible and allow
> components to require Java 1.2. So, it's XSP a core component?

Maybe we could propose to make XSP an add-on?  Separate out the XSP
specific classes in an xsp.jar file (along with whatever else is necessary
to make it compile correctly).

> 2) C2 core would greatly benefit from requiring Java 1.2 (to be entirely
> honest, I love Java 1.3 Proxies, but we can go along without them)

BTW, I've been playing with Java 1.3--it's faster and and has some real
niceties in the API.  Interestingly, IBM has a preview release of the 1.3
virtual machine for Linux--but I never saw anything for 1.2.

Anyhoo, I'm +1 for (at *least*) Java 1.2

> 3) Tomcat-next will require Java 1.2 since Servlet 2.3 will require it
> directly from the spec.

Further proof we should upgrade the minimum supported JVM.

> 4) The only reason for being Java 1.1 compatible is lack of a good BSD
> JVM (which is also recognized as most voted Java bug on the bugparade)

Hmmm...
I know this will sound callous, but maybe they could use C1.7.x and C2
upgrades so it can be even more killer.  Having done Java 1.1 to 1.2
migration, I can definately help in this regard.

I don't want to exclude them, but maybe they should grab the blackdown
code, and work on their JVM so they can catch up with the rest of the
Java world.

> If we aim for Java 1.2 and Servlet 2.2 everything becomes incredibly
> simple and all stupid hacks go away.
>
> So, what the hell, I propose we take this direction.

+2000 on that !)

> Note for the *BSD folks: lowering the fever doesn't automatically cure
> the disease.

+1 on that.


Mime
View raw message