cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: The latest code (1.6-dev 1999-12-10 5:??pm EST)
Date Sat, 11 Dec 1999 13:59:11 GMT
Donald Ball wrote:
> 
> On Fri, 10 Dec 1999, Kevin Sonney wrote:
> 
> > > Any help, comment, suggestion, fix, is _as always_ welcome.
> >
> > Close. Very, very close. Too bad JSDK 2.0 doesn't include the
> > RequestDispatcher class. For that you need servlet-2.2.0.jar from
> > jakarta-tools. Which means you *HAVE* to have servlet-2.2.0.jar in your
> > classpath. The 2.0 JSDK alone isn't good enough. Easy enough to fix, but
> > worth documenting.
> 
> Oh my, this is sort of my bad. The patches that Brett sent in for JSDK 2.2
> actually do have a method that won't work with JSDK 2.0. Here's why -
> 
> EngineWrapper, which is used for command line cocoon operation, includes
> an implementation of HttpServletRequest so that we can fake requests to
> cocoon. The JSDK 2.2 version of HttpServletRequest relies on a new class
> in JSDK 2.2, RequestDispatcher. EngineWrapper won't compile with JSDK 2.0
> with the reference to RequestDispatcher, but won't compile with JSK 2.2
> without it. Our options, as I see them:
> 
> 1. Force users to upgrade to 2.2. This is bad for Apache-JServ users.

Yes
 
> 2. Force users to stay with 2.0. This is bad for tomcat users.

Yes
 
> 3. Force users to compile with jsdk-2.2 in their classpath, but to run
> Apache-JServ with jsdk-2.0 in their classpath. This just requires some
> care with classpath settings (if they run cocoon from the command line,
> they will have to have jsdk-2.2 in their classpath).

Messy.
 
> 4. Remove the HttpServletImplementation from EngineWrapper and come up
> with a different method of doing command line invokation

Already planned but at a lower priority. Sounds like I should spend more
cycles there.

> 5. Lose the cocoon command line invokation entirely

Ok, let's face it: Cocoon command line invocation doesn't make sense
anymore since the only thing it provides is a complex way of doing XSLT
piping.

Also, calling Cocoon from a servlet is the worst of the hacks, and you
guys seem to understand this (I'm very happy about it)

Now, Stylebook is what Cocoon from the command line should be. They
share the same design patterns, they share the same ideas. Integration
is the way to go since Stylebook has a sitemap (yes, Donald, it has it)
but no cache, Cocoon has a cache but no sitemap.

So, we need to create an engine that both Cocoon and Stylebook can call,
but for doing that we need to have a Request/Response abstraction that
Ricardo and I have been planning for XSP.

As you see, many pieces in this puzzle, it's not that easy.
 
> I think option 4 would be the cleanest long term solution if the JSDK
> disparity were expected to continue for a while, but since the
> Apache-JServ users will probably migrate to tomcat and JSDK-2.2 before too
> long (6 months?), maybe option 3 would be better. Anyone?

Do not expect JServ users to migrate to Tomcat soon. JServ users will do
it when they will need RequestDispatching or getResource(), otherwise
will stick there (jserv is rock solid)

The best thing is to 

 - create a Request/Response abstraction
 - create an Engine that works on these abstracted req/res
 - create a servlet hook and a command line hook
 - create a sitemap that can work on both cases

the best thing is to have a sitemap that controls both dynamically and
statically generated files, so that Cocoon can be "crond"-ed or manually
invoked and still let the dynamic part work seemlessly with the static
part.

What do you think?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche



Mime
View raw message