o:[EMAIL PROTECTED]
> Sent: Saturday, June 14, 2003 6:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: xalan
>
>
> I f I compile the latest 2.1 as it is the web app does not work. If I
> remove the xalan.2.5.1.jar file it all works fine. I'm using java 1.4.1.
>
>
I f I compile the latest 2.1 as it is the web app does not work. If I
remove the xalan.2.5.1.jar file it all works fine. I'm using java 1.4.1.
On Saturday, Jun 14, 2003, at 12:16 Europe/Dublin, Geoff Howard wrote:
Not sure what you mean. Where does it say to remove xalan?
Geoff H
Not sure what you mean. Where does it say to remove xalan?
Geoff Howard
> -Original Message-
> From: Mark Miller [mailto:[EMAIL PROTECTED]
> Sent: Saturday, June 14, 2003 6:37 AM
> To: [EMAIL PROTECTED]
> Subject: xalan
>
>
> How come I have to remove the xal
Mark Miller wrote:
How come I have to remove the xalan jar file from the 2.1 cocoon lib
directory if the build is setup for java 1.4.1?
Hello Mark,
I know there are many problems with the Xalan integration in JDK 1.4.x,
but why want you to remove it completely? Maybe reading this helps:
http
How come I have to remove the xalan jar file from the 2.1 cocoon lib
directory if the build is setup for java 1.4.1?
I think we should at least in 2.0.x have a fully working
xslt processor as default.
Knowing the problems many users have was the reason for my question. I
will at least add XSLTC to cocoon.xconf and sitemap to make it easily
usable.
Seems OK to me. Not only does XSLTC _still_ have some issues,
Carsten Ziegeler wrote:
But there is another reason for this mail: Now with the current XSLTC we
can switch to it as default processor in 2.0 too, can't we?
I'm currently -1 on this because imho xsltc has not proven to be 100%
working and I think we should at least in 2.0.x have a fully working
xs
Joerg Heinicke wrote:
Isn't it already the default ? The TreeProcessor has now been around
for more than a year...
Yep. I checked and the TreeProcessor _is_ the default engine.
searched for "tree" in 2.0 cocoon.xconf and didn't find it. after a
closer look I found it.
The TreeProcessor is
Isn't it already the default ? The TreeProcessor has now been around
for more than a year...
Yep. I checked and the TreeProcessor _is_ the default engine.
searched for "tree" in 2.0 cocoon.xconf and didn't find it. after a
closer look I found it.
Joerg
Sylvain Wallez wrote:
Actually, ParanoidCocoonServlet can be used to run *any* servlet. So
I'll commit the changes in the 2.0 CVS also, so that we can point users
to this page.
Nice to hear ...
But there is another reason for this mail: Now with the current XSLTC
we can switch to it as default
Sylvain Wallez wrote:
Joerg Heinicke wrote:
Though we will get again "endorsed lib problem" questions on the
users list, I updated the XML lib jars to their latest releases as in
Cocoon 2.1. I hope nobody has something against this. At least we
have a good explanation and solution for these is
Joerg Heinicke wrote:
Though we will get again "endorsed lib problem" questions on the users
list, I updated the XML lib jars to their latest releases as in Cocoon
2.1. I hope nobody has something against this. At least we have a good
explanation and solution for these issues now
(http://wiki.
Joerg Heinicke wrote:
>
> But there is another reason for this mail: Now with the current XSLTC we
> can switch to it as default processor in 2.0 too, can't we?
>
I'm currently -1 on this because imho xsltc has not proven to be 100%
working and I think we should at least in 2.0.x have a fully wo
Joerg Heinicke wrote:
Though we will get again "endorsed lib problem" questions on the users
list, I updated the XML lib jars to their latest releases as in Cocoon
2.1. I hope nobody has something against this. At least we have a good
explanation and solution for these issues now
(http://wiki.
xml-apis.jar
Added: lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jar
Removed: lib/core xalan-2.3.1.jar xercesImpl-2.0.0.jar
Log:
updating to latest Xalan 2.5.1 and Xerces 2.4.0 releases
joerg 2003/06/04 13:50:51
Modified:lib jars.xml
lib/core xml-apis.jar
Added: lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jar
Removed: lib/core xalan-2.3.1.jar xercesImpl-2.0.0.jar
Log:
updating to latest Xalan 2.5.1 and Xerces 2.4.0 releases
recall it was related to namespace issues and
the default namespace. Also I had never put the cocoon distribution of
xalan in my jdk lib/endorsed directory as described in the installation
documentation (note to self: probably should do this)
Charles
Jeremy Quinn wrote:
Hi Guys
I am moving
Hi Guys
I am moving a project :
<http://kiss-ccr.dyndns.org> (temp URL)
from a very old Cocoon2.x to Cocoon 2.1-dev and have an XSLT StyleSheet
that works with Xalan but not with XSLTC (no useful error reports).
I can't find now, who these problems should be reported to.
Anyo
pier2003/02/26 11:27:02
xml-cocoon2/src/resources/javadoc/xalan - New directory
gzilla/show_bug.cgi?id=17378
Xalan DOM to SAX namespace "bug" alternative fix.
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
gzilla/show_bug.cgi?id=17378
Xalan DOM to SAX namespace "bug" alternative fix.
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED
gzilla/show_bug.cgi?id=17378
Xalan DOM to SAX namespace "bug" alternative fix.
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |ASSIGNED
gzilla/show_bug.cgi?id=17378
Xalan DOM to SAX namespace "bug" alternative fix.
--- Additional Comments From [EMAIL PROTECTED] 2003-02-26 14:15 ---
Created an attachment (id=5039)
this replaces the two previous attachments, contains patches to
AbstractTextSerializer, XMLUtils and DOMStreamer
Bruno Dumon wrote:
> >
> > Now, what do you think of not creating an own streamer but
> > integrating it into the usual DOMStreamer - this would be
> > a little bit less performant but avoid any problems.
> > Because if you stream a DOM you might not know which streamer
> > you have to use, so yo
On Wed, 2003-02-26 at 08:07, Carsten Ziegeler wrote:
> Great, Bruno!
>
> This was exactly what I was thinking about after your comments
> from monday - but you beat me :)
:-P
>
> Now, what do you think of not creating an own streamer but
> integrating it into the usual DOMStreamer - this would
OST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17378>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1
gzilla/show_bug.cgi?id=17378
Xalan DOM to SAX namespace "bug" alternative fix.
--- Additional Comments From [EMAIL PROTECTED] 2003-02-25 16:34 ---
Created an attachment (id=5008)
the new DOMStreamer
gzilla/show_bug.cgi?id=17378
Xalan DOM to SAX namespace "bug" alternative fix.
--- Additional Comments From [EMAIL PROTECTED] 2003-02-25 16:33 ---
Created an attachment (id=5007)
fixes to AbstractTextSerializer, XmlUtils and SourceWritingTransformer
gzilla/show_bug.cgi?id=17378
Xalan DOM to SAX namespace "bug" alternative fix.
Summary: Xalan DOM to SAX namespace "bug" alternative fix.
Product: Cocoon 2
Version: Current CVS
Platform: All
OS/Version: All
Stat
gzilla/show_bug.cgi?id=4007
corrupt xalan-2.2.0-dev.jar
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|
Chris,
The problem you have is a well-known problem of Cocoon or more precicly of
Xalan. There are many mails in the archives about this topic (e.g.:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101994024218728&w=2).
If you want to use Saxon have a look at
http://outerthought.
nicolaken2002/12/02 16:05:15
Removed: lib/core xalan-2.4.1.jar xercesImpl-2.1.0.jar xml-apis.jar
xsltc.jar
Log:
Moved endorsed libs in ./lib/endorsed, so that they can be added in the build
file
easily as java jvm args, or in the future copied
nicolaken2002/12/02 16:04:30
Added: lib/endorsed xalan-2.4.1.jar
Log:
Moved endorsed libs in ./lib/endorsed, so that they can be added in the build
file
easily as java jvm args, or in the future copied to the webserver or Java
endorsed dir.
Currently it
> -Original Message-
> From: Bernhard Huber [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 20, 2002 6:06 PM
> To: [EMAIL PROTECTED]
> Cc: Gittings, Paul (Australia)
> Subject: Re: Xalan Serializer content-handler was: Re: Current CVS
> broken !
>
>
hello,
does anybody have XALAN serializer problems?
i don't want just to patch XMLSerializer, HTMLSerializer, and
TextSerializer, and LogicsheetCodeGenerator as i 'm not 100% aware of
the total impact of these changes.
Perhaps the problems only occur in Xalan settings, not for
igurationException {
super.configure( conf );
this.format.put(OutputKeys.METHOD,"html");
this.format.put( "{http://xml.apache.org/xslt}indent-amount";, "2" );
this.format.put( "{http://xml.apache.org/xslt}content-handler";,
"org.apache.
cziegeler2002/11/14 07:47:02
Modified:lib jars.xml
Added: lib/core xalan-2.4.1.jar
Removed: lib/core xalan.jar
Log:
At least setting version info for xalan
Revision ChangesPath
1.46 +1 -1 xml-cocoon2/lib/jars.xml
Index: jars.xml
On Tuesday, October 22, 2002, at 05:52 PM, Stephen Ng wrote:
Has this been reported to Xalan developers? I'd really like to move to
Xalan 2.4 because that version of XSLTC appears to have many bug fixes.
I had opened this bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7776
but
No, I didn't. But I only tried it once, without looking into the documentation.
Maybe the interface changed or something else.
Before reporting to xalan developers I would ask you Steve (or others too)
to verify that this error is reproducable.
Regards,
Michael
Stephen Ng wrote:
>
&g
Has this been reported to Xalan developers? I'd really like to move to
Xalan 2.4 because that version of XSLTC appears to have many bug fixes.
Steve
> -Original Message-
> From: Enke, Michael [mailto:michael.enke@;wincor-nixdorf.com]
> Sent: Friday, October 11, 200
gt; > Just a question. Why Cocoon still use Xalan 2.3.1 and not 2.4.0?
> >
> > Antonio Gallardo
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROT
I don't know the reason so I tried xalan2.4.1:
XSLTExtension:escape (required for xsp.xsl) was not working.
Michael
Antonio Gallardo Rivera wrote:
>
> Just a question. Why Cocoon still use Xalan 2.3.1 and not 2.4.0?
>
>
Just a question. Why Cocoon still use Xalan 2.3.1 and not 2.4.0?
Antonio Gallardo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Frank Taffelt wrote:
>
> Hi,
>
> it seems that the Xalan-Bug
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5779 doesn't affect
> current cocoon codebase.
>
> The current AbstractTextSerializer has a workarround for this which uses a
> simple identity tra
Hi,
it seems that the Xalan-Bug
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5779 doesn't affect
current cocoon codebase.
The current AbstractTextSerializer has a workarround for this which uses a
simple identity transform Stylesheet. This Solution seems to work fine for
the XML Seria
vgritsenko2002/08/03 18:50:27
Modified:lib jars.xml
Added: lib/core xalan-2.3.1.jar xercesImpl-2.0.0.jar xml-apis.jar
Removed: lib/core xalan2-20020723.jar xerces2-20020723.jar
xml-apis-20020723.jar
Log:
Rollback xalan/xerces/xml-apis to
Ugo Cei wrote:
> I have a stylesheet that stoppend working when I upgraded to the latest
> HEAD. Maybe it's due to the latest Xalan that is included. The relevant
> snippet from the logs follows. I've also attached the stylesheet.
It works if I substitute the current
I have a stylesheet that stoppend working when I upgraded to the latest
HEAD. Maybe it's due to the latest Xalan that is included. The relevant
snippet from the logs follows. I've also attached the stylesheet.
- Root Cause -
java.lang.NoSuchMethodError
tcurdt 2002/07/22 17:37:46
Removed: lib/core xalan-2.3.1.jar xercesImpl-2.0.0.jar xml-apis.jar
xsltc.jar
Log:
remove the old jars
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To
> -Original Message-
> From: Peter Royal [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 06, 2002 11:22 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Sitemap problem with newest xalan
>
>
> On Friday 03 May 2002 02:34 pm, Vadim Gritsenko wrote:
> > > On F
On Friday 03 May 2002 02:34 pm, Vadim Gritsenko wrote:
> > On Friday 03 May 2002 12:13 pm, Artur Bialecki wrote:
> > > Well, new xalan is not out yet but because of some
> > > major bugs in 2.3.1 I'm forced to use the head
> > > of xml-xalan. However, when
Hi Vadim,
> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 03, 2002 8:35 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Sitemap problem with newest xalan
>
>
> > From: Peter Royal [mailto:[EMAIL PROTECTED]]
> >
&
> From: Peter Royal [mailto:[EMAIL PROTECTED]]
>
> On Friday 03 May 2002 12:13 pm, Artur Bialecki wrote:
> > Well, new xalan is not out yet but because of some
> > major bugs in 2.3.1 I'm forced to use the head
> > of xml-xalan. However, when I use t
Joseph Kesselman/CAM/Lotus wrote:
>
> >If incremental processing is off, Xalan should not be creating any
> threads.
>
> Agreed. But it's likely that Java's network support _is_ creating threads.
>
> "Connection aborted by peer" means the server de
On Friday 03 May 2002 12:13 pm, Artur Bialecki wrote:
> Well, new xalan is not out yet but because of some
> major bugs in 2.3.1 I'm forced to use the head
> of xml-xalan. However, when I use the head version
> of xalan the sitemap_xmap.java is not generated
> correctly, but
Well, new xalan is not out yet but because of some
major bugs in 2.3.1 I'm forced to use the head
of xml-xalan. However, when I use the head version
of xalan the sitemap_xmap.java is not generated
correctly, but only in the context of cocoon.
What happens is that patterns and some
>If incremental processing is off, Xalan should not be creating any
threads.
Agreed. But it's likely that Java's network support _is_ creating threads.
"Connection aborted by peer" means the server decided to stop talking to
you. Find out why. It may be malfunctioning,
> 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 goi
Xalan does spawn a thread when you request that it be run in incremental
mode. I don't know whether Cocoon is using that feature or not. Other than
that, we don't spawn any threads that I know of...
The error you're getting is reported as a socket _write_ error. That means
it
On Saturday 27 April 2002 04:45 pm, Stefano Mazzocchi wrote:
> Now, the interesting thing is that it seems that Xalan is running it's
> own thread. I don't recall seeing thread-forking code for Xalan spin-off
> in Cocoon, so I wonder: is this a Xalan thing?
yes.
> But th
E: running Cocoon 2.1-dev out of CVS HEAD of last week, which
includes Xalan 2.3.1]
HttpProcessor[8080][4]/TraxErrorHandler: Error in TraxTransformer:
javax.xml.transform.TransformerException: java.net.SocketException:
Connection aborted by peer: socket write error
javax.xml.transform.Transforme
Since many bugs that I find in xsltc aren't simply reproducible by
running the scripts from command line, I prepared a WAR file with a
prebuild Cocoon that uses Xalan XSLTC as the XSLT processor for some
parts of it.
1) the /status page
2) the /documentation/* pages
You can find the WAR pa
gzilla/show_bug.cgi?id=4007
corrupt xalan-2.2.0-dev.jar
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Reso
On Friday 05 April 2002 02:41 pm, [EMAIL PROTECTED] wrote:
> 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 exp
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
>
27;name'
> the compiled class and therefore falls back on the standard name which
> creates collisions if more than one stylesheet is called.
Gotcha. All of our pipelines have multiple trax transformations, so that
kinda kills my hopes of xsltc for now at least.
> > BUT the latest
Peter Royal wrote:
>
> I downloaded the 04-04 CVS snapshot of Xalan-J and tried the XSLTC support,
> but gave me some error about finding a class Gomer... (that's not the exact
> error, but i stopped after that)..
It seems there is a problem in *our* TrAX usage that doesn&#
I downloaded the 04-04 CVS snapshot of Xalan-J and tried the XSLTC support,
but gave me some error about finding a class Gomer... (that's not the exact
error, but i stopped after that)..
BUT the latest Xalan is *MUCH* faster in interpreted mode (3x for the
stylesheet i was trying to opt
parameter
>
> +100
no kidding :)
> > 3) add a 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
a 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
t;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
icate 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
gzilla/show_bug.cgi?id=4007
corrupt xalan-2.2.0-dev.jar
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|CLOSED |REOPENED
Resolution|I
Stefano Mazzocchi wrote:
>Berin and Sylvain wrote:
>
>
>
>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 fo
Jacek,
Am sure you know this from your experience in the Software industryI 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*
unde
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 shar
Berin and Sylvain wrote:
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 XS
ted
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. Thi
Nicola Ken Barozzi wrote:
>From: "Sylvain Wallez" <[EMAIL PROTECTED]>
>
>>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 :
Yes there was. It hasn't gotten any farther though...
> -Original Message-
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 27, 2002 10:08 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Making Xalan XSLTC work with Cocoon
>
>
> F
From: "Sylvain Wallez" <[EMAIL PROTECTED]>
> 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 defaul
> -Original Message-
> From: Maciek Kaminski [mailto:[EMAIL PROTECTED]]
>
> 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 o
nsive 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
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]
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
> implementat
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 Mi
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
> From: root [mailto:root] On Behalf Of Christian Zoffoli
>
>
> I have found a problem using Xalan 2.3.1 in conjunction with cocoon
> 2.0.2-dev. The processor seems to meet the exception illustrated in
the
> following link (
> http://nagoya.apache.org/bugzilla/show_bug.cg
I have found a problem using Xalan 2.3.1 in conjunction with cocoon
2.0.2-dev. The processor seems to meet the exception illustrated in the
following link (
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6956) when I try to
process some documents. As illustrustrated at the end of the previous
problem.
Michael
Sylvain Wallez wrote:
>
> Hi team,
>
> I found a showstopper in the current CVS : calling
> http://localhost:8080/cocoon/sub/generror hangs. Disabling Xalan
> incremental-processing solves the problem.
>
> A quick thread analys
Hi team,
I found a showstopper in the current CVS : calling
http://localhost:8080/cocoon/sub/generror hangs. Disabling Xalan
incremental-processing solves the problem.
A quick thread analysis with JSwat shows that
org.apache.xalan.transformer.TransformerImpl.transformNode() is
suspended at
commons-httpclient-20011012.LICENSE.txt
jakarta-regexp-1.2.LICENSE.txt
logkit-1.0.1.LICENSE.txt
xalan-2.2.0.jar.LICENSE.txt
xerces-1.4.4.LICENSE.txt xml-apis.LICENSE.txt
Log:
add license file for ASF
gzilla/show_bug.cgi?id=4007
corrupt xalan-2.2.0-dev.jar
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|
gzilla/show_bug.cgi?id=2437
XSLT broken? Different behaviour from within cocoon as opposed to running xalan from
the command line
[EMAIL PROTECTED] changed:
What|Removed |Added
gzilla/show_bug.cgi?id=3138
Improper sitemap.java generated if using Saxon instead of xalan
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|
cziegeler02/01/29 00:39:13
Removed: lib/core xalan-2.2.0-D14.jar
Log:
Removed it for the second time...
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
cziegeler02/01/28 06:19:35
Modified:lib/core xml-apis.jar
Added: lib/core xalan-2.2.0.jar
Log:
Updated to latest official xalan
Revision ChangesPath
1.2 +339 -371 xml-cocoon2/lib/core/xml-apis.jar
<>
1.1 xml-cocoo
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 22 January 2002 1:11 pm
> To: [EMAIL PROTECTED]
> Subject: Xalan 2.2 final
>
>
> Should we upgrade to Xalan 2.2 final?
Have you tested Cocoon with it?
Should we upgrade to Xalan 2.2 final?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
ovidiu 02/01/02 15:25:21
Removed: scratchpad/schecoon/lib xalan-2.2.0-D13.jar
Log:
Removed. Build and copy the necessary jars in the webapp/ directory at build time
instead.
--
In case of troubles, e-mail
1 - 100 of 167 matches
Mail list logo
