> > I've been investigating
> > http://marc.theaimsgroup.com/?l=xalan-cvs&s=xsltc a bit and it seems
> > like there are some people actively working on it. Only Sun-people
> > however
>
> yes and, admittedly, this sucks from a diversity of community
perspective. But
> should I remind you that
> Try turning on "incremetal processing", you'll get those wrapped in
> RuntimeException's instead :)
If incremental processing is off, Xalan should not be creating any threads.
I'm a bit confused as to what could be going on. Joe, any ideas?
-scott
Peter Royal <[EMAIL PROTECTED]> wrote:
> BUT the latest Xalan is *MUCH* faster in interpreted mode (3x for the
> stylesheet i was trying to optimize),
I suspect that's mainly the redundant expression elimination I checked in.
> *BUT* the extension function we use in
> xsp.xsl wasn't working cor
If it's a bug, post it to Bugzilla. If it's a question, comment, or flame
about XSLTC, Xalan, or javax.xml.transform, post it to the xalan list. If
it's an issue with Cocoon's configuration of XSLTC or Xalan, post it to the
Cocoon list and CC the xalan. If you don't feel you're getting appropr
It sounds like you guys have the ball right now. Let us know if there's
something we can do, beyond the usual.
-scott
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
> There's an engineer in my company that knows well both XSLT and java
> bytecode, and I asked him today to see how we could help the development
> of the Apache version of XSLTC : the java opensource community *needs* a
> high-performance compact XSLT engine.
And it's there, in Apache Xalan's X
Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> I would personally love to work with the Xalan people to address all the
> issues that XSLTC has with Cocoon, but their interest in making this
> happening has been, in my eyes, cold.
>
> But anyway, if my impressions were wrong, or something changed
Just lurking... but I think I have a lead for an XForms
(http://www.w3.org/MarkUp/Forms/) implementation that might be
donation-to-apache material. Are people interested?
Also, XForms just went into last call, so people should review in any case.
-scott
Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> 1) any Apache committer has the right to propose the creation of an
> 'internal fork', stating a codename for it.
I back what Stefano said 100%. Anyone is always welcome to come into a
project and try to start a revolution, small or large. I was
Jacek, good luck to you. We'll leave your committer status open for a
while in case you change your mind.
-scott
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
> If you would like TO CONTINUE to be notified about updates to my
> experimental version,
Jacek, you have full committer status (as of early last week), so it would
be nice to focus on the Apache source base and distribution mechanism.
-scott
Jacek already got it early last week. Whether he's actually got SSH to
work, etc., is another question.
How many +1 votes did Santiago get? Provided it was more than me and you,
I can send in the request to Brian later today.
-scott
"Robert Koberg" <[EMAIL PROTECTED]> wrote:
> Are you saying we can write something like:
>
>
>
> and it will be as fast as:
>
>
I'm saying, yes, that's what should happen. To be clear, it does not
happen currently in Xalan interpretive, or, to my knowledge, with XSLTC.
-scott
Good suggestion. Thanks.
-scott
"Lewis, Andrew J"
> IMO, the best think would be to have an XSLT interpreter for your
> development cycles (where compliance and low latency are most important)
> and an XSLT compiler for production release (where runtime performance
> and scalability are the issues and low latency is not).
Yep. It may be that t
> But one thing is for sure, XSLTC is way faster than Xalan and, given
> choice, I would use the first for performance-critical applications.
>
> No offense, of course, just the plain facts.
Please, Stefano. No offense taken, and I was not trying to be defensive.
I agree 100% that XSLTC is an i
Yes, I agree with Berin on this, though I also agree with Jacek that
there's little reason that it should not scale well.
Another factor is "incremental" output, which Xalan interpretive does a lot
of work to do well (and tends to take penalty for), and XSLTC may have a
much harder time at. On
(cross posted to xalan-dev)
> But can you use XSLTC with SAX Events?
Yes.
Some quick responses to Stefano's note...
> 5) i haven't tested Xalan Translets, which, along with compiled XML
> might be *the* way to go for Cocoon production environments
Yes, I think so. I'm surprised that people
Yes, it is a general Xalan issue, for both serializers and for input SAX
events for the source tree.
There has been some discussion about reworking the namespace handling in
the serializers (see
http://marc.theaimsgroup.com/?t=9974111761&w=2&r=1). And note the long
outstanding bug in bugzil
Berin Loritsch <[EMAIL PROTECTED]> wrote:
>
>
>
etc...
Note that this is not valid XML, as the template namespace is not declared.
So I wonder if this is not a bit over simplified?
Here is a valid XSLT stylesheet:
http://www.w3.org/1999/XSL/Transform";
template:version="1.0">
I'm going to reply to this in
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2445.
-scott
Donald Ball
> I'm not 100% sure, but it looks like the current
> SAX2DTM code expects to be passed both, and I can imagine that Cocoon
might
> be trying to take the shortcut...
The code should work fine if passed only startPrefixMapping and
endPrefixMapping events. I just wrote a small test for this, and
e
hings, the test seems to return the correct results.
-scott
"Carsten
Ziegeler
> the problem does _not_ occur from the command line.
The command line allows different "flavors" for processing. -flavor th
should replicate the TransformerHandler setup of Cocoon. Or, at least, I
was hoping this was the case.
-scott
> "Carsten
>
> Ziegeler"To:
> <[EMAIL PROTECTED]>, "Scott_Boag@lotus. com"
>
>
> ndn.de> cc:
>
>
this...it is a DocumentFragment.
> Please try again to see if the problem is fixed yet.
No, it is still the same exception.
Regards
Carsten
>
> -scott
>
>
>
>
>
>
> "Carsten
>
> Ziegeler"To:
&g
Don, I certainly can't replicate this on the command line, with any of the
different flavors. Some questions:
1) When did you get your last CVS refresh? Did you try it with the latest?
(A nasty bug was discovered with TransformerHandler the other day that was
effecting the Cocoon environment).
I haven't forgotten it. It was on my list for today.
-scott
Donald Ball
scott
"Carsten
Ziegeler"To: <[EMAIL PROTECTED]>,
&
Would any of you kind Cocoon souls mind trying the Xalan from the latest
CVS code? I think I fixed a major problem tonight that I am hoping will
clear up some of the problems with Cocoon.
Also, incremental two-threaded mode is now off by default. You need to
call transformerFactory.setAttribute
Great! Please keep me and the xalan-dev list as informed as possible for
any potential Xalan problems. We are trying to GA by the beginning of next
week, and my biggest concern right now is the sax-to-sax incremental
handling in Cocoon, as well as some worries with extensions.
Feel free to ema
Unfortunately I can't tell much from the stack dump... it looks like a
nested exception that is not being unrolled properly. Can you work with
me on this on a fairly fine-grained basis? I really don't want to try and
reproduce the problem on my machine right now. I'll have to send you some
ja
Is there a Bugzilla bug posted on the xalan bug? Which bug number?
What did you update the xalan.jar with. Last release or latest CVS?
-scott
Donald Bal
33 matches
Mail list logo
