cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@dff.st>
Subject [RT/BUG] XSP processing
Date Wed, 21 May 2003 20:49:03 GMT
Hi, team!

I encountered what I'd consider a major bug. Since fixing it will
most likely need a some restructuring of the XSP part I wanted to
talk back first and hear some opinions. I also might have gotten
something totally wrong...

                            -o-

At one of our installations I upgraded from an older resin version
to a the latest of the 2.x branch (namely from 2.1.5 to 2.1.9).
Unfortunately this got me a "nice" exception instead of a working
system.
Again it was because of JAXP clashes having Xerces and Xalan that
comes with cocoon (, if you have use jdk 1.4 the versions that come
with the jdk) and the resin implementation in the classpath. *sigh*
(btw: their implementation is supposed to be fast - haven't tested
  this yet though)

I first tried to explicitly set the factories in cocoon to select
the proper version. But got an exception still moaning about some
caucho classes?! Hm.. So I explicitly set the factories as system
properties. Which should truely rule out the other JAXP implementation.
But again I got this d*mn caucho class in the exception trace.

After talking with Scott on the resin list I took a closer look
into the the AbstractMarkupLanguage and I realized that our XSP
part (AFAICS) does *not* use the proper Avalon components to do
the code creation!!! ...instead used the SAX stuff directly. OUTCH!
"XMLReader", "XMLFilter" and a "TransformerChainBuilderFilter"
are being used.

Not sure - this *migt* be fixable (well, let's better call it
"worked around") by specifing some more properties (so the proper
XMLReaderFactory is being used) but...

                            -o-

Besides this is bad from the POV that you might wanna switch the
component implementations (which IMHO is reason enough to tackle
this ASAP) looking at the code also leads me to the question:

Aren't we are building a pipeline in there? For me this asks
for reuse. We are already have something (kinda) like that.

A generator reading the XSP page, n transformers aka logicsheets
and a TextSerializer with the result being written to disc ...and
then being compiled.

Can't we reuse our current pipeline model to achieve exactly this?

Hm - probably not due to the fact that the logicsheets are
specified *inside* the XML :-/ so setting up a static pipeline
wouldn't be that easy not to say imposible but... *sigh*

...or am I here totally off the track?
--
Torsten

BTW:
why is the Logicsheet and NamedLogicsheet deprecated?
what was exactly the plan for the changes announced in the
javadocs?


Mime
View raw message