You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sebastien Sahuc <ss...@imediation.com> on 2000/10/20 12:05:58 UTC
[C2][XSP] Question for the implementor
Ricardo,
Time has come for questioning you on the XSP engine implementation.
The question mainly deals with the namespace preservation mechanism
performed at the transformation stage. Indeed in the original XSP engine
(understand the DOM based XSP engine), we keep all declared namespace
declared in all XSL stylesheet (e.g. request.xsl, response.xsl and xsp.xsl)
inside a collection object. Then when the XSP page go throught the different
tranformation stages, at each transformation step we have to keep somehow
the original namespace declared in the source DOM document before the
transformation, then we perform the transformation itself and finally we
restore back to the result DOM document the original namespace and all the
stylesheet namespaces.
The comment you added to javadoc to explain this was that the Stylesheet
transformation would drop the namespace declarations. So was it because of
the Xalan version you were working with at the time of coding, or is it
still true with the lastest version of Xalan2 ?
Do you have any test case that you used to rely on when you developed the
XSP engine ? If so, is there one that hightlight the namespace dropping ?
Thanks Ricardo for any comment you would provide,
Sebastien
-----Original Message-----
From: Sebastien Sahuc [mailto:ssahuc@imediation.com]
Sent: Friday, October 13, 2000 4:54 PM
To: cocoon-dev@xml.apache.org
Subject: RE: [C2] Moving to Xalan2.
Davanum Srinivas wrote :
> Sent: Thursday, October 12, 2000 6:05 PM
> To: Sebastien Sahuc; Giacomo Pati
> Cc: Stefano Mazzocchi; Scott Boag/CAM/Lotus; STimm@mailgo.com
> Subject: RE: [C2] Moving to Xalan2.
>
>
> Sebastien,
>
> We don't really need to copy the namespaces in
> LogicSheet.java. See enclosed LogicSheet.java which
> works for me.
Thanks dims for having a look at it and correcting what should be corrected.
My objective at first was to blindly transpose the DOM XSP engine into a SAX
driven engine so we don't lose ANY functionality required by the XSP spec.
Therefore there might be some tricky part in the code -and the one dealing
with namespace preserving falls into this category- and I would love to hear
Ricardo's comments and suggestions on these points since he is the XSP's
implementator and must have had some reasons to have implemented the engine
the way he did.
This brings into light a more general issue that, IMHO, should be solved as
we're moving forward with Cocoon2. Indeed I don't know how you guy are
coding, but concerning me, I'm totally addicted to test cases when it comes
to writing code. Unfortunately we -at cocoon2- don't have a test suite
against which to test our code. And it's not because simple.xsp works that
means that the XSP engine works for any XSP pages. Therefore I believe we
need a test case framework and a test suite that would allow us to :
* Make sure a build pass all the test suite
* develop faster and easier
* Make regression test
* Build some performance suite
I'm going to comment all the points one by one.
* A build must pass the test suite : every time you download a CVS snapshot,
you launch the full build script that compiles, jar the project and finally
calls a ant's task that run the test suite against the previously built
project. Any error and failing would be reported. In case the test suite
successfully passed, then you know the jar is at least usable.
* Develop faster and easier : I will transcript my -short- experience with
the XSP engine refactoring. If some test cases -say a couple of simple XSP
pages- that make use of every aspect of the XSP engine were available I
would have trusted the test suite to build the refactored engine. An example
of a test case could be a 'logicsheet_in_pi.xsp' page which purpose is to
test if the XSP engine correctly takes into account logicsheets declared in
Processing instruction nodes. So instead of that, I had to look at -every-
piece of code ( fortunately it was a pleasure to read Ricardo's code) and
understand for what purpose they were written for. That why I ended up by
writing some XMLFilter that preserve namespace -as the DOM version did-.
This is the part Dims proposed to remove in his patch. So although I don't
really know if this part of code is necessary, I'm also sure that Ricardo
have not done that for his simple pleasure, so there might be so rational
reason we don't know yet...
So test cases will allow us to trust any change and addition we do in the
code as long as they successfully pass the test suite. No more 'hope it will
work with other XSP pages', or 'Damn, can't change it as I do not know what
impact it would have on other parts'.
*make regression test : Every time a bug is submitted, we should write a
simple testcase that show the bug, and then correct the bug in the main code
until the test is passed. Then if we run the test suite with an older
version of the project, automatically it will fail, highlighting the bug.
Moreover that would let people write simple testcase for bug they find, and
give us more reactivity to correct them.
* Build some performance suite : A test case can easily become a bench
program that will stress your code in multithreaded context and simulate
dozens and dozens of user requests to check how your server side application
would behave when deployed in production. I believe that a framework like
cocoon has different distinct layers, and that each layer should be stressed
independently for performance tuning. Indeed running a servlet engine +
cocoon and JMeter would not be enough IMHO.
At least this is how I made the simple bench report I sent in previous post
(see forwarded section below), and also this is how I detected a memory leak
before I sent the final patch to the list. Without this I would not have
seen the problem and would have been ashamed of such a mistake :-)
Finally let's come back to real reason of this post. Should we patch the
correction Dims is proposing ? Well I don't really know as we don't know the
reason Ricardo had in mind when he did the code for preserving namespace
between transformations. Anyone else has an opinion on this ?
All the best,
Sebastien
>
> Thanks,
> dims
>
> --- Sebastien Sahuc <ss...@imediation.com> wrote:
> > OK,
> >
> > attached you'll find the full patch for :
> > * Xalan2 integration on cocoon2 (patch from Davanum, which
> also corrects
> > some sitemap issues)
> > * SAX based XSP engine (from myself)
> >
> > Steps to follow :
> > * get a fresh CVS snapshot of Cocoon2
> > * integrate the attached patch
> > * get the lastest version of XalanJ2 from CVS, build it and
> copy the jar to
> > lib
> > * delete the xalan_1_2_D01.jar from the lib
> > * build cocoon2, drag and drop the war to your favorite Tomcat 4
> > * and run :-)
> >
> > It should be working fine. You won't see any difference in
> term of page
> > content, but you might notice some performance gain at the
> XSP compilation
> > stage, and at the sitemap generation (though still way too long).
> >
> > I reran my performance tests but I couldn't get the Xalan2J
> working with DOM
> > (cannont use the same transformer instance more than once),
> so I made the
> > test against the current implementation : XalanJ1 + DOM.
> >
> > Here are the results :
> >
> >
> ---------------------------------------------------------------------
> > ms/loop | very_simple.xsp | simple.xsp |
> sitemap.map |
> >
> ---------------------------------------------------------------------
> > DOM/XalanJ1 | 120 ms/loop | 250 ms/loop | 12000
> ms/loop |
> >
> ---------------------------------------------------------------------
> > SAX/XalanJ2 | 80 ms/loop | 350 ms/loop | 3000
> ms/loop |
> >
> ---------------------------------------------------------------------
> >
> > What can we say from the report ?
> > * As source documents are getting more and more verbose,
> SAX will definitely
> > be of big help over DOM. For the sitemap example, we fall
> from 12s to 3s
> > /loop !
> >
> > * for very small source document, the difference isn't that
> high. But SAX
> > still behaves faster.
> >
> > * For simple.xsp, Xalan1/DOM generates a 3kb java file, whereas the
> > SAX/Xalanj2 ends up with a 19Kb file. Indeed in the former
> case, namespace
> > informations are simply 'forgotten', whereas on the later I
> found the
> > generated source code way too verbose (a lot of
> startPrefixMapping() is
> > generated... ). Who is right ? I don't really know. Need
> your eyes on this
> > point.
> >
> >
> > Well,so basically I'm quite happy of the result, even
> though the code is a
> > little more complex (not any more sequential programming, but rather
> > incremental, which brings more complexity by nature... at
> least it's more
> > complex to debug :-( )
> >
> > I still need to write/update Ricardo's documentation. I
> hope that Ricardo is
> > coming back soon, as I have lot of questions for him (and
> also would like to
> > congratulate him for his marvelous job and nice coding.)
> >
> > Well that's all,
> >
> > Sebastien
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Davanum Srinivas [mailto:dims@yahoo.com]
> > > Sent: Wednesday, October 11, 2000 9:23 PM
> > > To: dims@yahoo.com; Giacomo Pati; Sebastien Sahuc
> > > Cc: dims@yahoo.com; Stefano Mazzocchi; Scott Boag/CAM/Lotus;
> > > STimm@mailgo.com
> > > Subject: Re: [C2] Moving to Xalan2.
> > >
> > >
> > > Sebastien,
> > >
> > > Have not heard from you yet. Hope the integration is going on
> > > smoothly. Please let us know.
> > >
> > > Thanks,
> > > dims
> > >
> > > --- Davanum Srinivas <di...@yahoo.com> wrote:
> > > > Sebastien,
> > > >
> > > > The enclosed Zip file has c2x2diff.txt which has the cvs
> > > diff's for each of the files. It also
> > > > has
> > > > the modified files in case you need them.
> > > >
> > > > #1: Had problems with ComponentHolderFactory. Enclosed is a
> > > patch for this. This might or might
> > > > not be needed by tomorrow.
> > > >
> > > > #2: XPathAPI.java changes are not really needed if you can
> > > exclude it from the build. Fixed
> > > > XIncludeTransformer to point to the XPathAPI in Xalan2.
> > > >
> > > > If you don't hear from me, please go ahead with this
> > > version. (But you probably will though :-)
> > > >
> > > > Thanks,
> > > > dims
> > > >
> > > > --- Giacomo Pati <Gi...@pwr.ch> wrote:
> > > > > Sebastien Sahuc wrote:
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Giacomo Pati [mailto:pati_giacomo@yahoo.com]
> > > > > > > Sent: Tuesday, October 10, 2000 9:15 PM
> > > > > > > To: Sebastien Sahuc; dims@yahoo.com; Stefano
> Mazzocchi; Scott
> > > > > > > Boag/CAM/Lotus
> > > > > > > Cc: pati_giacomo@yahoo.com; ssahuc@imediation.com;
> > > STimm@mailgo.com
> > > > > > > Subject: RE: [C2] Moving to Xalan2.
> > > > > > >
> > > > > > >
> > > > > > > Hi all
> > > > > > >
> > > > > > > So here is my suggestion how to proceed:
> > > > > > >
> > > > > > > Sebastien, can you apply the patch from Davanum
> to your tree
> > > > > > > and get it
> > > > > > > working with the latest CVS and send me a zipped
> patch (cvs
> > > > > > > -u diff) of
> > > > > > > your tree.
> > > > > >
> > > > > > I can do it, but not before tomorrow night (European
> > > time). Is that OK ?
> > > > >
> > > > > Yes, sure. In the meantime I'll fix the CVS. There seems
> > > to bee some
> > > > > problems with the sitemap.
> > > > >
> > > > > Giacomo
> > > > >
> > > > > --
> > > > > PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1
> > > 856 2202
> > > > > Giacomo Pati, CTO/CEO Fax: +41 (0)1
> > > 856 2201
> > > > > Hintereichenstrasse 7 Mobil: +41
> > > (0)78 759 7703
> > > > > CH-8166 Niederweningen
> > Mailto:Giacomo.Pati@pwr.ch
> > > > Web:
http://www.pwr.ch
> >
> >
> > =====
> > Davanum Srinivas, JNI-FAQ Manager
> > http://www.jGuru.com/faq/JNI
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get Yahoo! Mail - Free email you can access from anywhere!
> > http://mail.yahoo.com/
>
> > ATTACHMENT part 2 application/x-zip-compressed name=c2x2.zip
>
>
>
> =====
> Davanum Srinivas, JNI-FAQ Manager
> http://www.jGuru.com/faq/JNI
>
> __________________________________________________
> Do You Yahoo!?
> Get Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
>
>
> ATTACHMENT part 2 application/octet-stream name=diffs_saxxsp.zip
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/