You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/03/27 10:42:40 UTC
Making Xalan XSLTC work with Cocoon
One day I decided to see what could be done to address the fact that
server-side XSLT transformations might become a serious performance
bottleneck for massive use of cocoon.
So I went ahead and did some tests on my machine, these were not
extensive enough for a published paper, but they were ok to get the
figures and estimate where the hotspots are.
I discovered, with much surprise, that Xalan XSLTC is 600% faster than
regular Xalan and 200% faster than MSXML 3.0 which is a native XSLT
implementation (the tests were run on win2k).
It looks clear that Cocoon would practially solve many of its current
performance problems simply by making it possible to use Xalan XSLTC
instead of regular Xalan.
-- o --
My intention is to work with the Xalan community to get those issues
solved. I'm not interested in working on forked versions which
opensource faith is not decided.
I fully believe in the power of communities and I strongly believe that
no single person, no matter how smart and brilliant, can match the power
of the distributed IQ of a sane and focused open development community.
For this reason, I decided to place my effort in making sure that the
Cocoon and the Xalan community work together, even if this requires
changes in both sides.
-- o --
XSLT is used in three different places in Cocoon:
1) generation of sitemap source code our of XML descriptor
2) generation of XSP source code our of XSP pages
3) transformation of generated XML content
1) and 2) are *not* used at runtime, or, if so, their runtime execution
is done once for page change, which is *very* unfrequent in production
environments.
3) is our main runtime concern and source of performance problems so
here is where we should target the use of XSLTC.
In the future, the use of interpreted versions of both sitemap and XSP
might remove the need to have an XSLT processor in these stages, but for
now, this is not our main concern.
-- o --
Cocoon implements runtime pipeline transformations using a
TrAXTransformer. This transformer accepts the following parameters:
use-request-parameters
use-browser-capabilities-db
use-session-info
xslt-processor-role
while the first three are used to indicate the behavior of XSLT param
expansion, the fourth one is used to identifiy the 'ROLE' of the Avalon
component that is used to implement the required functionality.
At first, this sounds like a cool thing, but closer inspection finds
this usage of Avalon patterns *totally* broken.... let's look at the
code of TrAXTransformer:
child = conf.getChild("xslt-processor-role");
String xsltRole = child.getValue(XSLTProcessor.ROLE);
try {
this.xsltProcessor = (XSLTProcessor)
this.manager.lookup(xsltRole);
} catch (ComponentException e) {
throw new ConfigurationException("Cannot load XSLT processor", e);
}
Now, there is *absolutely* not sense in making the ROLE to be looked up
configurable, because an Avalon ROLE is a behavioral identification, not
an instance identification.
In fact, if we implement a different ROLE and try to load it from there,
it doesn't work because you get a ClassCastException.
What we want here, is *NOT* the ability to define our own ROLE, but a
way to define the HINT for that ROLE (that is, translated in regular
java terms: we want to be able to choose the implementing class, not to
choose a different interface).
So, in short, the above code prevents us from having two different
implementations of the XSLTProcessor component running in the same
system and used by the TrAXTransformer.
-- o --
Note that, thanks to TrAX, we don't need to implement more than one
XSLTProcessor implementation, we just have to specify which TrAX factory
implementation the component must use.
So, our need is:
1) TrAXTransformer must have a way to access a specific instance of a
component, not its role.
2) The component manager should be able of associating different
identifiers to components which have the same ROLE, the same
implementation class, but have different configurations (which are used
to indicate what TrAX factory to use).
If the above two things are implemented, it could be entirely possible
to have many different XSLT implementation running inside Cocoon and
handling different parts of the URI space.
Ok, now: I think I need some Avalon advice here, Berin? is the Excalibur
Component Manager already able to do the above? (sorry, i don't have the
code at hand right now).
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: Making Xalan XSLTC work with Cocoon
Posted by Davanum Srinivas <di...@yahoo.com>.
Jacek,
Am sure you know this from your experience in the Software industry....I just want to voice my 2
cents.
A lot of companies (including mine) when they decide to develop Software based on Cocoon or to
deploy a Application based on Cocoon will use code from third-party vendors *ONLY* under the
following circumstances:
- Binaries from Third-parties where we are sure we will get Tech Support when/if necessary (AND
are sure that the Third-party is going to be in the business for the Product/Application
Lifecycle).
- Source code is available either in some open source fashion (Apache/GNU LGPL etc...)
For example the ONLY libraries we will ever ship in our product will be those in
xml-cocoon2\lib\core directory and cocoon itself. So how ever fast,lean and mean your "new XSLT
Compiler" is/will-be....It is of not much use to me personally.
Thanks,
dims
--- "Jacek R. Ambroziak" <ja...@yahoo.com> wrote:
> On Wednesday 27 March 2002 03:11 pm, Stefano Mazzocchi wrote:
> > and your
> > fork is perceived as harmful more than useful to us, at this point and
> > I'm very sad about this.
>
> I wouldn't call it a fork anymore; I am building a new XSLT Compiler.
>
> > I dislike the fact that two
> > projects are now sharing the same name.
> >
> > Sun was the original owner of the XSLTC acronym
>
> Full synergy here: I don't want the confusion either.
>
> --Jacek
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas - http://xml.apache.org/~dims/
__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards�
http://movies.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Making Xalan XSLTC work with Cocoon
Posted by "Jacek R. Ambroziak" <ja...@yahoo.com>.
On Wednesday 27 March 2002 03:11 pm, Stefano Mazzocchi wrote:
> and your
> fork is perceived as harmful more than useful to us, at this point and
> I'm very sad about this.
I wouldn't call it a fork anymore; I am building a new XSLT Compiler.
> I dislike the fact that two
> projects are now sharing the same name.
>
> Sun was the original owner of the XSLTC acronym
Full synergy here: I don't want the confusion either.
--Jacek
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Making Xalan XSLTC work with Cocoon
Posted by "Jacek R. Ambroziak" <ja...@yahoo.com>.
On Wednesday 27 March 2002 03:11 pm, Stefano Mazzocchi wrote:
> and your
> fork is perceived as harmful more than useful to us, at this point and
> I'm very sad about this.
I wouldn't call it a fork anymore; I am building a new XSLT Compiler.
> I dislike the fact that two
> projects are now sharing the same name.
>
> Sun was the original owner of the XSLTC acronym
Full synergy here: I don't want the confusion either.
--Jacek
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: Making Xalan XSLTC work with Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
"Jacek R. Ambroziak" wrote:
>
> On Wednesday 27 March 2002 04:42 am, Stefano Mazzocchi wrote:
> > I fully believe in the power of communities and I strongly believe that
> > no single person, no matter how smart and brilliant, can match the power
> > of the distributed IQ of a sane and focused open development community.
>
> How about Mike Kay? :-)
Mike Kay is for sure a very talented engineer and there are many other
examples of talented individuals around, but how the outbreak of the
open source development model shows pretty clearly, the effort invested
in communities pay off much more than those invested in individual
projects that die out once the man behind the show gets tired of it (see
JClark's XT, for example).
I'm pretty sure that a single individual can create an entire XSLT
processor and do a good job at it (it's not rocket science after all),
but in the longer term the picture changes drasticly.
This is why I try not to base my long term efforts on something that is
individually-based.
You might not care at all, but from this side of the fence, as very
heavy users of XSLT technology, we must be *extremely* cautious and your
fork is perceived as harmful more than useful to us, at this point and
I'm very sad about this.
Ah, one point which might be worth noting: I dislike the fact that two
projects are now sharing the same name.
Sun was the original owner of the XSLTC acronym but that was donated
along with the code to the ASF which decided to cover it with the Apache
License, which protects the use of those terms.
Xalan team: you forgot to update your license to include "XSLTC" in the
terms that redistributors aren't allowed to use. I strongly suggest you
to do so. This will prevent future abuses of the term (but
unfortunately, it won't cover past ones)
Jacek: I would suggest you to change the name of your project so to
avoid confusion (this will also serve you as a purpose of increasing
visibility for your personal effort).
Thanks.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Making Xalan XSLTC work with Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
"Jacek R. Ambroziak" wrote:
>
> On Wednesday 27 March 2002 04:42 am, Stefano Mazzocchi wrote:
> > I fully believe in the power of communities and I strongly believe that
> > no single person, no matter how smart and brilliant, can match the power
> > of the distributed IQ of a sane and focused open development community.
>
> How about Mike Kay? :-)
Mike Kay is for sure a very talented engineer and there are many other
examples of talented individuals around, but how the outbreak of the
open source development model shows pretty clearly, the effort invested
in communities pay off much more than those invested in individual
projects that die out once the man behind the show gets tired of it (see
JClark's XT, for example).
I'm pretty sure that a single individual can create an entire XSLT
processor and do a good job at it (it's not rocket science after all),
but in the longer term the picture changes drasticly.
This is why I try not to base my long term efforts on something that is
individually-based.
You might not care at all, but from this side of the fence, as very
heavy users of XSLT technology, we must be *extremely* cautious and your
fork is perceived as harmful more than useful to us, at this point and
I'm very sad about this.
Ah, one point which might be worth noting: I dislike the fact that two
projects are now sharing the same name.
Sun was the original owner of the XSLTC acronym but that was donated
along with the code to the ASF which decided to cover it with the Apache
License, which protects the use of those terms.
Xalan team: you forgot to update your license to include "XSLTC" in the
terms that redistributors aren't allowed to use. I strongly suggest you
to do so. This will prevent future abuses of the term (but
unfortunately, it won't cover past ones)
Jacek: I would suggest you to change the name of your project so to
avoid confusion (this will also serve you as a purpose of increasing
visibility for your personal effort).
Thanks.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: Making Xalan XSLTC work with Cocoon
Posted by "Jacek R. Ambroziak" <ja...@yahoo.com>.
On Wednesday 27 March 2002 04:42 am, Stefano Mazzocchi wrote:
> I fully believe in the power of communities and I strongly believe that
> no single person, no matter how smart and brilliant, can match the power
> of the distributed IQ of a sane and focused open development community.
How about Mike Kay? :-)
--Jacek
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Making Xalan XSLTC work with Cocoon
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>From: "Sylvain Wallez" <sy...@anyware-tech.com>
>
>>There was a proposal some time ago on avalon-dev for a new
>>ComponentManager that would hide Selectors. AFAIR (Berin, correct me if
>>I'm wrong), this can allow to transparently switch a single component to
>>a selector : if no hint is given, a default instance is selected (just
>>as for sitemap components).
>>
>
>I have a version that creates a Component facade that Selects the
>appropriate one.
>It's auto-compiled, and increases security by makin it impossible to cast
>the Component to an interface different from the one specified.
>
>Are you interested?
>
Sure ;)
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Making Xalan XSLTC work with Cocoon
Posted by Berin Loritsch <bl...@apache.org>.
Yes there was. It hasn't gotten any farther though...
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Wednesday, March 27, 2002 10:08 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Making Xalan XSLTC work with Cocoon
>
>
> From: "Sylvain Wallez" <sy...@anyware-tech.com>
>
> > There was a proposal some time ago on avalon-dev for a new
> > ComponentManager that would hide Selectors. AFAIR (Berin,
> correct me
> > if I'm wrong), this can allow to transparently switch a single
> > component to a selector : if no hint is given, a default
> instance is
> > selected (just as for sitemap components).
>
> I have a version that creates a Component facade that Selects
> the appropriate one. It's auto-compiled, and increases
> security by makin it impossible to cast the Component to an
> interface different from the one specified.
>
> Are you interested?
Definitely.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Making Xalan XSLTC work with Cocoon
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Sylvain Wallez" <sy...@anyware-tech.com>
> There was a proposal some time ago on avalon-dev for a new
> ComponentManager that would hide Selectors. AFAIR (Berin, correct me if
> I'm wrong), this can allow to transparently switch a single component to
> a selector : if no hint is given, a default instance is selected (just
> as for sitemap components).
I have a version that creates a Component facade that Selects the
appropriate one.
It's auto-compiled, and increases security by makin it impossible to cast
the Component to an interface different from the one specified.
Are you interested?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Making Xalan XSLTC work with Cocoon
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>One day I decided to see what could be done to address the fact that
>server-side XSLT transformations might become a serious performance
>bottleneck for massive use of cocoon.
>
>So I went ahead and did some tests on my machine, these were not
>extensive enough for a published paper, but they were ok to get the
>figures and estimate where the hotspots are.
>
>I discovered, with much surprise, that Xalan XSLTC is 600% faster than
>regular Xalan and 200% faster than MSXML 3.0 which is a native XSLT
>implementation (the tests were run on win2k).
>
>It looks clear that Cocoon would practially solve many of its current
>performance problems simply by making it possible to use Xalan XSLTC
>instead of regular Xalan.
>
> -- o --
>
>My intention is to work with the Xalan community to get those issues
>solved. I'm not interested in working on forked versions which
>opensource faith is not decided.
>
I fully agree with this point of view.
>I fully believe in the power of communities and I strongly believe that
>no single person, no matter how smart and brilliant, can match the power
>of the distributed IQ of a sane and focused open development community.
>
>For this reason, I decided to place my effort in making sure that the
>Cocoon and the Xalan community work together, even if this requires
>changes in both sides.
>
Can you elaborate more on these changes ? Is there any obstacle for
Xalan and Cocoon to collaborate ?
>
>
> -- o --
>
>XSLT is used in three different places in Cocoon:
>
> 1) generation of sitemap source code our of XML descriptor
> 2) generation of XSP source code our of XSP pages
> 3) transformation of generated XML content
>
>1) and 2) are *not* used at runtime, or, if so, their runtime execution
>is done once for page change, which is *very* unfrequent in production
>environments.
>
>3) is our main runtime concern and source of performance problems so
>here is where we should target the use of XSLTC.
>
>In the future, the use of interpreted versions of both sitemap and XSP
>might remove the need to have an XSLT processor in these stages, but for
>now, this is not our main concern.
>
> -- o --
>
>Cocoon implements runtime pipeline transformations using a
>TrAXTransformer. This transformer accepts the following parameters:
>
> use-request-parameters
> use-browser-capabilities-db
> use-session-info
> xslt-processor-role
>
>while the first three are used to indicate the behavior of XSLT param
>expansion, the fourth one is used to identifiy the 'ROLE' of the Avalon
>component that is used to implement the required functionality.
>
>At first, this sounds like a cool thing, but closer inspection finds
>this usage of Avalon patterns *totally* broken.... let's look at the
>code of TrAXTransformer:
>
> child = conf.getChild("xslt-processor-role");
> String xsltRole = child.getValue(XSLTProcessor.ROLE);
>
> try {
> this.xsltProcessor = (XSLTProcessor)
>this.manager.lookup(xsltRole);
> } catch (ComponentException e) {
> throw new ConfigurationException("Cannot load XSLT processor", e);
> }
>
>Now, there is *absolutely* not sense in making the ROLE to be looked up
>configurable, because an Avalon ROLE is a behavioral identification, not
>an instance identification.
>
>In fact, if we implement a different ROLE and try to load it from there,
>it doesn't work because you get a ClassCastException.
>
>What we want here, is *NOT* the ability to define our own ROLE, but a
>way to define the HINT for that ROLE (that is, translated in regular
>java terms: we want to be able to choose the implementing class, not to
>choose a different interface).
>
>So, in short, the above code prevents us from having two different
>implementations of the XSLTProcessor component running in the same
>system and used by the TrAXTransformer.
>
This *was made* to allow several processors simultaneously ! As the
author of this, let me explain why I did it, and how I use it :)
In the developments made in my company, Saxon was chosen a long time ago
as the XSLT processor of choice, mainly because of its better
performance compared to Xalan. So people used Saxon, and also used its
cool-but-proprietaty extensions. At that time we were using Cocoon 1,
and we used Saxon as the default and only XSLT processor.
Then came Cocoon 2. And we had some problems when using Saxon for
sitemap compilation because of some Xalan extensions used in the sitemap
engine (don't remember exactly what).
So I used a pattern I heard of in Avalon-land and that's described by
Berin in the "Choosing the Role's name" paragraph at
http://jakarta.apache.org/avalon/developing/framework.html : if there
are several variations of a same work interface, append "/variant" to
the work interface role.
So here's an extract of our cocoon.xonf :
<xslt-processor logger="root.xslt-processor">
<parameter name="use-store" value="true"/>
<parameter name="transformer-factory"
value="org.apache.xalan.processor.TransformerFactoryImpl"/>
</xslt-processor>
<component role="org.apache.cocoon.components.xslt.XSLTProcessor/SAXON"
class="org.apache.cocoon.components.xslt.XSLTProcessorImpl"
logger="root.saxon">
<parameter name="use-store" value="true"/>
<parameter name="transformer-factory"
value="com.icl.saxon.TransformerFactoryImpl"/>
</component>
Note that the TrAX factory class is specified, allowing a deterministic
choice when service manifest files of several engines are conflicting in
the classpath.
And here's an extract of our sitemap.xmap :
<map:transformer name="xslt"
src="org.apache.cocoon.transformation.TraxTransformer"
pool-max="32" pool-min="16" pool-grow="4"
logger="sitemap.transformer.xslt">
<use-request-parameters>false</use-request-parameters>
<use-browser-capabilities-db>false</use-browser-capabilities-db>
<xslt-processor-role>org.apache.cocoon.components.xslt.XSLTProcessor/SAXON</xslt-processor-role>
</map:transformer>
With the above, Xalan (associated to the "standard" role) is used by the
sitemap engine, and Saxon is used everywhere in the sitemap. We didn't
want to use Xalan in the sitemap, but had we wanted that, we would have
declared another transfomer using the same TraxTransfomer class but with
a different xslt-processor-role, thus being able to use *both* XSLT
engines in the sitemap.
Maybe a better solution would have been to replace the xslt-processor
role by a Selector. But I found this overkill for what seemed to me a
marginal use (most people use Cocoon + Xalan out of the box).
>
> -- o --
>
>Note that, thanks to TrAX, we don't need to implement more than one
>XSLTProcessor implementation, we just have to specify which TrAX factory
>implementation the component must use.
>
>So, our need is:
>
> 1) TrAXTransformer must have a way to access a specific instance of a
>component, not its role.
>
By "instance", do you mean "hint" in a Selector ?
>
> 2) The component manager should be able of associating different
>identifiers to components which have the same ROLE, the same
>implementation class, but have different configurations (which are used
>to indicate what TrAX factory to use).
>
A ComponentSelector allows this.
>If the above two things are implemented, it could be entirely possible
>to have many different XSLT implementation running inside Cocoon and
>handling different parts of the URI space.
>
We already can *today* : I've been using it for many months.
>Ok, now: I think I need some Avalon advice here, Berin? is the Excalibur
>Component Manager already able to do the above? (sorry, i don't have the
>code at hand right now).
>
There was a proposal some time ago on avalon-dev for a new
ComponentManager that would hide Selectors. AFAIR (Berin, correct me if
I'm wrong), this can allow to transparently switch a single component to
a selector : if no hint is given, a default instance is selected (just
as for sitemap components).
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Making Xalan XSLTC work with Cocoon
Posted by "Jacek R. Ambroziak" <ja...@yahoo.com>.
On Wednesday 27 March 2002 04:42 am, Stefano Mazzocchi wrote:
> I fully believe in the power of communities and I strongly believe that
> no single person, no matter how smart and brilliant, can match the power
> of the distributed IQ of a sane and focused open development community.
How about Mike Kay? :-)
--Jacek
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: Making Xalan XSLTC work with Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
>
> > -----Original Message-----
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> > Sylvain Wallez wrote:
> >
> > > So what about a new VersatileTrAXTransformer that would be
> > the "old"
> > > one (i.e. doesn't use XSLTProcessor) with a configurable
> > > TransformerFactory ? This would then avoid a new CS used
> > only by the
> > > TrAXTransformer and the need for "hacky" subroles.
> >
> > Yeah, makes perfect sense.
> >
> > In fact, the use of XSLT 'internally' is way different than
> > the use of XSLT 'externally' (that is, at the application
> > level rather than at core level).
> >
> > I would go even further: I would change the *existing*
> > TrAXTransformer to use TrAX directly and not add yet another
> > transformer that behaviorally does the exact same thing.
>
> :) In that case we should also decide whether we will officially
> support the XT package. It has not been maintained since 1999,
> and is behind the times in both SAX conformance (it is level 1 and
> Cocoon2 is level 2), and in XSLT spec conformance.
>
> If we get rid of it, we can get rid of the cruft that we have to
> wrap SAX1 XMLParsers with SAX2 XMLReaders. Which also means that
> we can say we require all SAX2 compliant components. We can get
> rid of some deprecation messages, and simplify the cocoon.xml
> package.
Ok, I vote to remove the support for XT since it's dead meat.
Anybody against this?
> > So, let's see, here are the proposed changes now:
> >
> > 1) decouple TrAXTransformer from the internal Cocoon
> > components and make it use TrAX directly.
>
> +1
>
> Actually I would like to see a complete rewrite of the compiled
> XSP/Sitemap section, but since I can't put in the cycles, I can't
> force it to happen.
Yeah, same here :/
> > 2) remove the <xslt-processor-role> parameter
>
> +100
no kidding :)
> > 3) add a <trax-factory> parameter to indicate which class
> > should be used as a TrAX factory.
>
> +1
>
> > That's it. It is *slightly* back compatible, but I'm sure
> > that cocoon users care *only* for the ability to have their
> > own XSLT implementation only at user level (in fact, changing
> > the xslt-processor component implementation just creates
> > problems since we are basing our behavior on xalan-only
> > features so far).
>
> The people it affects most are ones who used the <xslt-processor-role>
> which are few in number.
Exactly, probably Sylvain is the only one that uses it :)
> >
> > If I don't receive any -1, I'll go ahead and patch it.
>
> Sounds good!
Great, consider it coming.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Making Xalan XSLTC work with Cocoon
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Sylvain Wallez wrote:
>
> > So what about a new VersatileTrAXTransformer that would be
> the "old"
> > one (i.e. doesn't use XSLTProcessor) with a configurable
> > TransformerFactory ? This would then avoid a new CS used
> only by the
> > TrAXTransformer and the need for "hacky" subroles.
>
> Yeah, makes perfect sense.
>
> In fact, the use of XSLT 'internally' is way different than
> the use of XSLT 'externally' (that is, at the application
> level rather than at core level).
>
> I would go even further: I would change the *existing*
> TrAXTransformer to use TrAX directly and not add yet another
> transformer that behaviorally does the exact same thing.
:) In that case we should also decide whether we will officially
support the XT package. It has not been maintained since 1999,
and is behind the times in both SAX conformance (it is level 1 and
Cocoon2 is level 2), and in XSLT spec conformance.
If we get rid of it, we can get rid of the cruft that we have to
wrap SAX1 XMLParsers with SAX2 XMLReaders. Which also means that
we can say we require all SAX2 compliant components. We can get
rid of some deprecation messages, and simplify the cocoon.xml
package.
> So, let's see, here are the proposed changes now:
>
> 1) decouple TrAXTransformer from the internal Cocoon
> components and make it use TrAX directly.
+1
Actually I would like to see a complete rewrite of the compiled
XSP/Sitemap section, but since I can't put in the cycles, I can't
force it to happen.
> 2) remove the <xslt-processor-role> parameter
+100
> 3) add a <trax-factory> parameter to indicate which class
> should be used as a TrAX factory.
+1
> That's it. It is *slightly* back compatible, but I'm sure
> that cocoon users care *only* for the ability to have their
> own XSLT implementation only at user level (in fact, changing
> the xslt-processor component implementation just creates
> problems since we are basing our behavior on xalan-only
> features so far).
The people it affects most are ones who used the <xslt-processor-role>
which are few in number.
>
> If I don't receive any -1, I'll go ahead and patch it.
Sounds good!
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Making Xalan XSLTC work with Cocoon
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>Sylvain Wallez wrote:
>
>>So what about a new VersatileTrAXTransformer that would be the "old" one
>>(i.e. doesn't use XSLTProcessor) with a configurable TransformerFactory
>>? This would then avoid a new CS used only by the TrAXTransformer and
>>the need for "hacky" subroles.
>>
>
>Yeah, makes perfect sense.
>
>In fact, the use of XSLT 'internally' is way different than the use of
>XSLT 'externally' (that is, at the application level rather than at core
>level).
>
Agree.
>I would go even further: I would change the *existing* TrAXTransformer
>to use TrAX directly and not add yet another transformer that
>behaviorally does the exact same thing.
>
Agree also. Keeping the old one only for back compatibility would
confuse users ("Why is there 2 TrAXTransformer ?")
>So, let's see, here are the proposed changes now:
>
> 1) decouple TrAXTransformer from the internal Cocoon components and
>make it use TrAX directly.
>
> 2) remove the <xslt-processor-role> parameter
>
> 3) add a <trax-factory> parameter to indicate which class should be
>used as a TrAX factory.
>
>That's it. It is *slightly* back compatible, but I'm sure that cocoon
>users care *only* for the ability to have their own XSLT implementation
>only at user level (in fact, changing the xslt-processor component
>implementation just creates problems since we are basing our behavior on
>xalan-only features so far).
>
>If I don't receive any -1, I'll go ahead and patch it.
>
+10 ;-)
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Making Xalan XSLTC work with Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> So what about a new VersatileTrAXTransformer that would be the "old" one
> (i.e. doesn't use XSLTProcessor) with a configurable TransformerFactory
> ? This would then avoid a new CS used only by the TrAXTransformer and
> the need for "hacky" subroles.
Yeah, makes perfect sense.
In fact, the use of XSLT 'internally' is way different than the use of
XSLT 'externally' (that is, at the application level rather than at core
level).
I would go even further: I would change the *existing* TrAXTransformer
to use TrAX directly and not add yet another transformer that
behaviorally does the exact same thing.
So, let's see, here are the proposed changes now:
1) decouple TrAXTransformer from the internal Cocoon components and
make it use TrAX directly.
2) remove the <xslt-processor-role> parameter
3) add a <trax-factory> parameter to indicate which class should be
used as a TrAX factory.
That's it. It is *slightly* back compatible, but I'm sure that cocoon
users care *only* for the ability to have their own XSLT implementation
only at user level (in fact, changing the xslt-processor component
implementation just creates problems since we are basing our behavior on
xalan-only features so far).
If I don't receive any -1, I'll go ahead and patch it.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Making Xalan XSLTC work with Cocoon
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>Berin and Sylvain wrote:
>
><snipped bunch of useful stuff/>
>
>Ok, we can do it today, but I think that we *must* patch the
>TrAXTransformer in order to avoid users from being able to configure a
>ROLE (which is pretty bad thing).
>
>Unfortunately, the patches will make the system back incompatible for
>those of you that use external XSLT implementations, but we are aiming
>for 2.1 so I think this would be fair.
>
>So, the plan is to change to provide a hint for the CS and not a role
>for the CM.
>
>Does anybody disagree on this action?
>
>Berin, as far for cleaner implementation I agree that it's not that
>perfect, but anyway, it works and we are not extending this anymore in
>the future since TrAX already provides us with great abstraction from
>the implementations.
>
In the "ancient times" of Cocoon 2, there was no XSLTProcessor :
TrAXTransformer used directly the TrAX API, and some other components
(mainly the markup language engine) used it directly also. Then came the
XSLTProcessor to factorize things and make the "grand unification" of
XSLT processing in Cocoon.
Now we see that the TrAXTransformer needs to deal with various engines.
However, I still have the impression that other uses of the
XSLTProcessor are more "core" to Cocoon (that's mainly logicsheets), and
that using there a single engine would be ok.
So what about a new VersatileTrAXTransformer that would be the "old" one
(i.e. doesn't use XSLTProcessor) with a configurable TransformerFactory
? This would then avoid a new CS used only by the TrAXTransformer and
the need for "hacky" subroles.
Thoughts ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Making Xalan XSLTC work with Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin and Sylvain wrote:
<snipped bunch of useful stuff/>
Ok, we can do it today, but I think that we *must* patch the
TrAXTransformer in order to avoid users from being able to configure a
ROLE (which is pretty bad thing).
Unfortunately, the patches will make the system back incompatible for
those of you that use external XSLT implementations, but we are aiming
for 2.1 so I think this would be fair.
So, the plan is to change to provide a hint for the CS and not a role
for the CM.
Does anybody disagree on this action?
Berin, as far for cleaner implementation I agree that it's not that
perfect, but anyway, it works and we are not extending this anymore in
the future since TrAX already provides us with great abstraction from
the implementations.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Making Xalan XSLTC work with Cocoon
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Maciek Kaminski [mailto:maciejka@tiger.com.pl]
>
> On 27 Mar 2002 at 10:42, Stefano Mazzocchi wrote:
>
> > 1) TrAXTransformer must have a way to access a specific
> instance of a
> > component, not its role.
> >
> > 2) The component manager should be able of associating different
> > identifiers to components which have the same ROLE, the same
> > implementation class, but have different configurations (which are
> > used to indicate what TrAX factory to use).
> >
> > ...
> >
> > Ok, now: I think I need some Avalon advice here, Berin? is the
> > Excalibur Component Manager already able to do the above? (sorry, i
> > don't have the code at hand right now).
> >
>
> Avalon ComponentSelectors let one to hint ComponentManager
> which implementation
> of role to create.
>
> See: http://jakarta.apache.org/avalon/developing/implementing.html
> Subchapter: Getting Components from a ComponentSelector.
Do keep in mind that the ComponentSelector pattern is available, but
it is generally preferred for you to roll your own. For instance, the
Transformer would be rewritten to return an instance of an XMLFilter
or something similar.
I agree with your point that it does not make any sense at all to make
the role configurable. IT IS NOT A CONFIGURABLE ITEM. For any system
to work, certain contracts like what is an XSLTProcessor *must* remain
constant. It is up to the container (ExcaliburCM/CS in this case) to
determine the implementation.
In short the ComponentSelector pattern would be something like this:
child = conf.getChild("xslt-processor-hint");
String xsltHint = child.getValue("default"); // It is always good to
provide a default
try
{
ComponentSelector selector = (ComponentSelector)
this.manager.lookup( XSLTProcessor.ROLE + "Selector" );
this.xsltProcessor = (XSLTProcessor) selector.select( xsltHint );
}
catch (ComponentException e)
{
throw new ConfigurationException( "Cannot load XSLT processor", e );
}
However, by changing the transformer interface, you can directly manage
the relationships
and transformer instances--always returning a valid XMLFilter
(org.apache.cocoon.xml).
The usage would change to:
try
{
this.transformer = (Transformer) this.manager.lookup(
Transformer.ROLE );
}
catch (ComponentException e)
{
//log
throw e;
}
// ... new part of the sitemap
pipeline.addFilter( this.transformer.findFilter( environment, hint ) );
I think Cocoon is nearing a place where it needs to refine its contracts
and redefine
its components. There are some components that are only used by one
other component.
The symbiosis should be encapsulated into a subcontainer that manages
that relationship.
That way the two can exist in the system, but be easier to remove all
associated components
later.
Cocoon needs to do the following to keep from imploding:
1) Reassert the core and supported roles.
a) this includes refining the interfaces so that they are simpler
b) differentiate between data/information and real components
2) Provide a logically scalable way of adding supporting components.
a) They should be grouped with the components that rely on them
b) Provide pressure to drive out objects that are only semantically
components
3) Refine the story.
a) Roles are like roles in a play--make sure the cast fits the play
b) Make sure that the plot is not lost in the details (there are too
many plot twists in cocoon)
c) Incorporate the Source resolver into the story--it is integral
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Making Xalan XSLTC work with Cocoon
Posted by Maciek Kaminski <ma...@tiger.com.pl>.
On 27 Mar 2002 at 10:42, Stefano Mazzocchi wrote:
> 1) TrAXTransformer must have a way to access a specific instance of a
> component, not its role.
>
> 2) The component manager should be able of associating different
> identifiers to components which have the same ROLE, the same
> implementation class, but have different configurations (which are used
> to indicate what TrAX factory to use).
>
> ...
>
> Ok, now: I think I need some Avalon advice here, Berin? is the Excalibur
> Component Manager already able to do the above? (sorry, i don't have the
> code at hand right now).
>
Avalon ComponentSelectors let one to hint ComponentManager which implementation
of role to create.
See: http://jakarta.apache.org/avalon/developing/implementing.html
Subchapter: Getting Components from a ComponentSelector.
Maciek Kaminski
maciejka@tiger.com.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org