possible bug in current cocoon.xconf
I get a lot of error messages about failures to find various deli-related config files when running the current cvs cocoon. This change seems to have fixed the problem: --- /home/miles/work/cocoon.xconf 2003-02-24 10:21:27.0 -0800 +++ ../cocoon.xconf 2003-02-24 03:23:23.0 -0800 @@ -942,7 +942,7 @@ | device that runs on. +-- deli class=org.apache.cocoon.components.deli.DeliImpl -parameter name=deli-config-file value=resources/deli/config/deliConfig.xml/ +parameter name=deli-config-file value=WEB-INF/deli/config/deliConfig.xml/ /deli miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cocoon-2.0.4 possible bug in Sql transformer
Cocoon-2.0.4 seems to repeat namespace declaration in the sql:rowset
element resulting from a sql transformation launching a stored procedure.
I have cocoon 2.0.3 and cocoon 2.0.4 side by side on the same machine.
I call an Oracle stored procedure with SQL transformer
With this code:
execute-query xmlns=http://apache.org/cocoon/SQL/2.0;
query lang=1 isstoredprocedure=true
begin dbchem.scheda_xml('1',?,'30060','1',''); end;
/query
out-parameter sql:nr=1 sql:name=resultset2
sql:type=java.sql.Types.CHAR/
/execute-query
And I obtain this
?xml version=1.0 encoding=UTF-8?
content
sql:rowset xmlns:sql=http://apache.org/cocoon/SQL/2.0;
sql:resultset2:
content of the out parameter
/sql:resultset2
/sql:rowset
/content
If I use the same invocation on cocoon 2.0.4
I get this error from the same browser (MSIE):
Duplicate attribute. Line 10, Position 52
rowset xmlns=http://apache.org/cocoon/SQL/2.0;
xmlns=http://apache.org/cocoon/SQL/2.0;resultset2:
---^
My system
- jre
version 1.4.1
java-vendor Sun Microsystems Inc.
- operating-system
name Windows 2000
architecture x86
version 5.0
If you confirm I could compile a bug even if It would be my first.
--
Gabriele Domenichini
[EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
possible bug in pipeline/transformer?
I'm seeing some strange behaviour when I use an XSLT stylesheet
generated on the fly by cocoon. Unless I reference the generated xsl in
the pipeline before using it as a transformer src I get a null pointer
exception on the transformer (the one labelled DEBUG below). Hence the
pointless map:part hack below.
map:match pattern=bind-*.xsl
map:generate src=model/{1}.xml/
map:transform src=model/makebinder.xsl/
map:serialize type=xml/
/map:match
map:match pattern=*.html
map:aggregate element=doc
!-- HACK: I don't want this here but it makes the transform work!--
map:part src=cocoon:/bind-staff_model.xsl/
map:part src=model/staff_model.xml/
map:part src=xforms/{1}.xml/
/map:aggregate
map:transform src=model/selectmodels.xsl/
map:transform src=cocoon:/bind-staff_model.xsl label=DEBUG/
Is this a bug? I can't find anything about it in bugzilla or on the
list. Thoughts/suggestions welcomed.
There's nothing wrong with the stylesheet itself - if I save the xml it
produces as a file and then use that as the transform src it all works
fine without the hack.
VERSION INFO:
cocoon 2.1 (HEAD of about 2 weeks ago), jdk1.3.1, tomcat 4.0.1
Cheers
Simon
---
Simon Price
Institute for Learning and Research Technology
University of Bristol
8-10 Berkeley Square
Bristol BS8 1HH
United Kingdom
Direct: +44 (0)7071 226 720
Office: +44 (0)117 928 7193
Fax: +44 (0)117 928 7112
[EMAIL PROTECTED]
http://www.ilrt.bristol.ac.uk
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
possible bug in 2.1 map:mount src attribute?
I'm moving an app from 2.03 to 2.1-dev (cvs head, 21 Aug 02) and the sitemap engine no longer seems to support alternative names for the .xmap file. The following fragment used to work fine in 2.03 but only works if I rename sitemap_tal.xmap as sitemap.xmap. (ie. the engine appears to always look for a file called sitemap.xmap irrespective of what the src attribute says - although it does look in the right directory). map:match pattern=tal/** map:mount check-reload=yes reload-method=synchron src=tal/sitemap_tal.xmap uri-prefix=tal// /map:match Is this a deliberate feature change or a bug? Simon --- Simon Price Institute for Learning and Research Technology University of Bristol 8-10 Berkeley Square Bristol BS8 1HH United Kingdom Direct: +44 (0)7071 226 720 Office: +44 (0)117 928 7193 Fax: +44 (0)117 928 7112 [EMAIL PROTECTED] http://www.ilrt.bristol.ac.uk - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible bug in 2.1 map:mount src attribute?
I'm using tomcat 4.0.1 with java 1.3.1 Simon Price wrote: I'm moving an app from 2.03 to 2.1-dev (cvs head, 21 Aug 02) and the sitemap engine no longer seems to support alternative names for the .xmap file. The following fragment used to work fine in 2.03 but only works if I rename sitemap_tal.xmap as sitemap.xmap. (ie. the engine appears to always look for a file called sitemap.xmap irrespective of what the src attribute says - although it does look in the right directory). map:match pattern=tal/** map:mount check-reload=yes reload-method=synchron src=tal/sitemap_tal.xmap uri-prefix=tal// /map:match Is this a deliberate feature change or a bug? Simon --- Simon Price Institute for Learning and Research Technology University of Bristol 8-10 Berkeley Square Bristol BS8 1HH United Kingdom Direct: +44 (0)7071 226 720 Office: +44 (0)117 928 7193 Fax: +44 (0)117 928 7112 [EMAIL PROTECTED] http://www.ilrt.bristol.ac.uk - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- Simon Price Institute for Learning and Research Technology University of Bristol 8-10 Berkeley Square Bristol BS8 1HH United Kingdom Direct: +44 (0)7071 226 720 Office: +44 (0)117 928 7193 Fax: +44 (0)117 928 7112 [EMAIL PROTECTED] http://www.ilrt.bristol.ac.uk - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible bug in 2.1 map:mount src attribute?
Simon Price wrote: I'm using tomcat 4.0.1 with java 1.3.1 Simon Price wrote: I'm moving an app from 2.03 to 2.1-dev (cvs head, 21 Aug 02) and the sitemap engine no longer seems to support alternative names for the .xmap file. The following fragment used to work fine in 2.03 but only works if I rename sitemap_tal.xmap as sitemap.xmap. (ie. the engine appears to always look for a file called sitemap.xmap irrespective of what the src attribute says - although it does look in the right directory). map:match pattern=tal/** map:mount check-reload=yes reload-method=synchron src=tal/sitemap_tal.xmap uri-prefix=tal// /map:match Is this a deliberate feature change or a bug? It's a bug. Vadim Simon - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible bug in 2.1 map:mount src attribute?
Thanks Vadim. In case anyone wonders why on earth I changed the name of the xmap files: its so I can tell them apart at a glance in my text editor :-) Vadim Gritsenko wrote: Simon Price wrote: I'm using tomcat 4.0.1 with java 1.3.1 Simon Price wrote: I'm moving an app from 2.03 to 2.1-dev (cvs head, 21 Aug 02) and the sitemap engine no longer seems to support alternative names for the .xmap file. The following fragment used to work fine in 2.03 but only works if I rename sitemap_tal.xmap as sitemap.xmap. (ie. the engine appears to always look for a file called sitemap.xmap irrespective of what the src attribute says - although it does look in the right directory). map:match pattern=tal/** map:mount check-reload=yes reload-method=synchron src=tal/sitemap_tal.xmap uri-prefix=tal// /map:match Is this a deliberate feature change or a bug? It's a bug. Vadim Simon - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- Simon Price Institute for Learning and Research Technology University of Bristol 8-10 Berkeley Square Bristol BS8 1HH United Kingdom Direct: +44 (0)7071 226 720 Office: +44 (0)117 928 7193 Fax: +44 (0)117 928 7112 [EMAIL PROTECTED] http://www.ilrt.bristol.ac.uk - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Possible bug
I've realised that this matcher doesn't give the error but doesn't copy the nodes either: xsl:template match=@*|text() xsl:copy xsl:apply-templates/ /xsl:copy /xsl:template As soon as a you introduce a node() or * in the match attribute the error appears...I've also noticed that a matcher like i18n:* lets it work ok and copies the i18n nodes but not the other ones.. xsl:copy-of select=/ doesn't work. If this template is added every thing works (but once again not as I'd like) xsl:template match=* xsl:apply-templates/ /xsl:template So it seems it is not able to copy the nodes from the original stylesheet but a match like xsl:* it's been useless. Any suggestions? i don't see where you describe the bug. Sorry, the thread was 'Could not read resource file'. The thing is that the files and configuration of sitemap.xmap give an error where I think shouldn't be... The error is given by the file generator while if you erase the stylesheet matcher in fac-db.xsl or the sql transform in the pipe the error disappears I can't describe much more of the bug... it's just that we believe it should work but it does not :-( -Original Message- From: Albert Cervera Areny [mailto:[EMAIL PROTECTED]] Sent: Monday, August 12, 2002 6:56 PM To: [EMAIL PROTECTED] Subject: Possible bug I have tried to bring the configuration to the minimum to reproduce the errors.. it is really small now... do you think this could be a bug? Luca Morandini (under windows 2000) and I (under Linux) have been looking at this for hours and haven't found a reason for the error. This is for the sitemap.xmap file: map:match pattern=dins-facturacio map:generate src=docs/fac.xml/ map:transform src=stylesheets/fac.xsl/ map:transform src=stylesheets/fac-db.xsl/ map:transform type=sql map:parameter name=use-connection value=cocoon/ /map:transform map:serialize type=xml/ /map:match The other files are attached... A sql connection is also needed. Nothing else this should give the error. The error should go away by erasing the sql transform or erasing the stylesheet matcher in fac-db.xsl If it is really a bug... to whom should I report it? -- Albert Cervera Areny Dept. Informàtica Sedifa, S.L. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Albert Cervera Areny Dept. Informàtica Sedifa, S.L. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Albert Cervera Areny Dept. Informàtica Sedifa, S.L. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Possible bug
I have tried to bring the configuration to the minimum to reproduce the errors.. it is really small now... do you think this could be a bug? Luca Morandini (under windows 2000) and I (under Linux) have been looking at this for hours and haven't found a reason for the error. This is for the sitemap.xmap file: map:match pattern=dins-facturacio map:generate src=docs/fac.xml/ map:transform src=stylesheets/fac.xsl/ map:transform src=stylesheets/fac-db.xsl/ map:transform type=sql map:parameter name=use-connection value=cocoon/ /map:transform map:serialize type=xml/ /map:match The other files are attached... A sql connection is also needed. Nothing else this should give the error. The error should go away by erasing the sql transform or erasing the stylesheet matcher in fac-db.xsl If it is really a bug... to whom should I report it? -- Albert Cervera Areny Dept. Informàtica Sedifa, S.L. fac-db.xsl Description: Binary data ?xml version=1.0 encoding=iso-8859-1? plantilla/--=_20020813005625_74760 Content-Type: application/octet-stream; name=fac.xsl Content-Disposition: attachment; filename=fac.xsl Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iaXNvLTg4NTktMSI/PgoKPHhzbDpzdHlsZXNo ZWV0IHZlcnNpb249IjEuMCIKCXhtbG5zOnhzbD0iaHR0cDovL3d3dy53My5vcmcvMTk5OS9YU0wv VHJhbnNmb3JtIj4KCjx4c2w6dGVtcGxhdGUgbWF0Y2g9InBsYW50aWxsYSI+CjxodG1sPgo8aGVh ZD4KPHRpdGxlPlQgSSBUIEwgRTwvdGl0bGU+CjwvaGVhZD4KPGJvZHk+CjwvYm9keT4KPC9odG1s Pgo8L3hzbDp0ZW1wbGF0ZT4KCjwveHNsOnN0eWxlc2hlZXQ+Cg== ?xml version=1.0 encoding=iso-8859-1? facturacio/ - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Possible bug]
I've zipped it to see if it could get through the anti-virus... if it can't how should I send the files?? PS: It would be ironic that if it is really a bug It is also a bug of the anti-virus ;) Missatge original Assumpte: Possible bug De: Albert Cervera Areny [EMAIL PROTECTED] Data: Tue, August 13, 2002 0:56 A: [EMAIL PROTECTED] I have tried to bring the configuration to the minimum to reproduce the errors.. it is really small now... do you think this could be a bug? Luca Morandini (under windows 2000) and I (under Linux) have been looking at this for hours and haven't found a reason for the error. This is for the sitemap.xmap file: map:match pattern=dins-facturacio map:generate src=docs/fac.xml/ map:transform src=stylesheets/fac.xsl/ map:transform src=stylesheets/fac-db.xsl/ map:transform type=sql map:parameter name=use-connection value=cocoon/ /map:transform map:serialize type=xml/ /map:match The other files are attached... A sql connection is also needed. Nothing else this should give the error. The error should go away by erasing the sql transform or erasing the stylesheet matcher in fac-db.xsl If it is really a bug... to whom should I report it? -- Albert Cervera Areny Dept. Informàtica Sedifa, S.L. -- Albert Cervera Areny Dept. Informàtica Sedifa, S.L. files.zip Description: Zip archive - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Possible bug
i don't see where you describe the bug. -Original Message- From: Albert Cervera Areny [mailto:[EMAIL PROTECTED]] Sent: Monday, August 12, 2002 6:56 PM To: [EMAIL PROTECTED] Subject: Possible bug I have tried to bring the configuration to the minimum to reproduce the errors.. it is really small now... do you think this could be a bug? Luca Morandini (under windows 2000) and I (under Linux) have been looking at this for hours and haven't found a reason for the error. This is for the sitemap.xmap file: map:match pattern=dins-facturacio map:generate src=docs/fac.xml/ map:transform src=stylesheets/fac.xsl/ map:transform src=stylesheets/fac-db.xsl/ map:transform type=sql map:parameter name=use-connection value=cocoon/ /map:transform map:serialize type=xml/ /map:match The other files are attached... A sql connection is also needed. Nothing else this should give the error. The error should go away by erasing the sql transform or erasing the stylesheet matcher in fac-db.xsl If it is really a bug... to whom should I report it? -- Albert Cervera Areny Dept. Informàtica Sedifa, S.L. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Possible Bug] TextSerializer loses characters with ASCII encoding?
Hi all, So I _think_ I've fixed this bug. In the AbstractTextSerializer, the setOutputStream method wraps the incoming output stream in a BufferedOutputStream. However, no class reference is kept to this BOS, so it never gets flushed at the end of the document. I made the BOS a class variable (instead of a local method variable), and added an endDocument() implementation that flushes the BOS and sets it to null (and then invokes the superclass's endDocument() method). This seems to fix the problem. What I still don't understand, though, is why this only occurred when I used the ASCII encoding. I'm guessing this is because I don't fully understand how the serializers handle encoding, but if anyone can provide some insights, that would be great. Thanks! Harry -Original Message- From: Lai, Harry [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 02, 2002 2:30 PM To: '[EMAIL PROTECTED]' Subject: RE: [Possible Bug] TextSerializer loses characters with ASCII enc odin g? I should also mention that I'm using Saxon 6.5 as my XSLT engine. Harry -Original Message- From: Lai, Harry [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 02, 2002 2:19 PM To: 'Cocoon Users' Subject: [Possible Bug] TextSerializer loses characters with ASCII encodin g? Hi folks, I'm seeing some really odd behavior with serializers, and wanted to see if anyone had seen this before (or better yet) knows what's causing this. =) PROBLEM: If I set an XML, HTML, or Text serializer's encoding to ASCII, I end up losing the tail end of my output (roughly 1-1000 characters). I think it has to do with the buffered output stream not being properly closed/flushed, but I'm not sure. ENVIRONMENT: Cocoon 2.0.2 running on JBoss 2.4.5 with Tomcat 4.0.3. Win2k. WORKAROUNDS: I can make this problem go away by doing either of the following: 1. Change the encoding to UTF-8 or ISO-8859-1. 2. Change the buffer-size to 1 (tried with values from 1-2048; was still seeing the problem with values as low as 10). REPRODUCING THE BUG: From what I'm seeing, you can reproduce this bug by having a reasonably large buffer (larger than 10 bytes) and switching any TextSerializer-based serializer's encoding to ASCII. Here's a sample from my sitemap: map:serializer name=css mime-type=text/css logger=sitemap.serializer.css src=org.apache.cocoon.serialization.TextSerializer pool-max=64 pool-min=16 pool-grow=4 buffer-size2048/buffer-size encodingASCII/encoding /map:serializer Any thoughts, suggestions, ideas, etc. would be greatly appreciated. Thanks! Harry PS The main reason this comes up is for a dynamic css pipeline, which I'd like to be character set agnostic (hence, the ASCII encoding). I only tested it with the HTML and XML serializer to make sure it wasn't something specific to my css pipeline. -- Harry Lai [EMAIL PROTECTED] 512.682.1101 x2170 - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Possible Bug] TextSerializer loses characters with ASCII encoding?
Hi folks, I'm seeing some really odd behavior with serializers, and wanted to see if anyone had seen this before (or better yet) knows what's causing this. =) PROBLEM: If I set an XML, HTML, or Text serializer's encoding to ASCII, I end up losing the tail end of my output (roughly 1-1000 characters). I think it has to do with the buffered output stream not being properly closed/flushed, but I'm not sure. ENVIRONMENT: Cocoon 2.0.2 running on JBoss 2.4.5 with Tomcat 4.0.3. Win2k. WORKAROUNDS: I can make this problem go away by doing either of the following: 1. Change the encoding to UTF-8 or ISO-8859-1. 2. Change the buffer-size to 1 (tried with values from 1-2048; was still seeing the problem with values as low as 10). REPRODUCING THE BUG: From what I'm seeing, you can reproduce this bug by having a reasonably large buffer (larger than 10 bytes) and switching any TextSerializer-based serializer's encoding to ASCII. Here's a sample from my sitemap: map:serializer name=css mime-type=text/css logger=sitemap.serializer.css src=org.apache.cocoon.serialization.TextSerializer pool-max=64 pool-min=16 pool-grow=4 buffer-size2048/buffer-size encodingASCII/encoding /map:serializer Any thoughts, suggestions, ideas, etc. would be greatly appreciated. Thanks! Harry PS The main reason this comes up is for a dynamic css pipeline, which I'd like to be character set agnostic (hence, the ASCII encoding). I only tested it with the HTML and XML serializer to make sure it wasn't something specific to my css pipeline. -- Harry Lai [EMAIL PROTECTED] 512.682.1101 x2170 - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Possible BUG] builtin-logicsheet problems
When trying to add my own logicsheet with the builtin-logicsheet directive in cocoon.xconf I discovered strange behaviour. In order to narrow down the cause, I then changed only one line in cocoon.xconf: --- builtin-logicsheet parameter name=prefix value=xsp-request/ parameter name=uri value=http://apache.org/xsp/request/2.0/ parameter name=href value=resource://request.xsl/ !--CHANGED -- /builtin-logicsheet --- request.xsl is now located in $COCOON_HOME/WEB-INF/classes. Utilizing xsp-request tags in test.xsp works without any problems now. But when I move request.xsl in a subdirectory ($COCOON_HOME/WEB-INF/classes/subdir), a processing exception is thrown: org.apache.cocoon.ProcessingException: Exception in creating Transform Handler --- builtin-logicsheet parameter name=prefix value=xsp-request/ parameter name=uri value=http://apache.org/xsp/request/2.0/ parameter name=href value=resource://subdir/request.xsl/ !--CHANGED -- /builtin-logicsheet --- Why is this (in Cocoon 2.0.1, this worked)? BTW, replacing the resource-URI with a file-URI causes the same error message. Tested on: Cocoon 2.0.2, Tomcat 4.0.4, Sun JDK 1.3.1, Linux Stack trace of test.xsp utilizing the request logicsheet: org.apache.cocoon.ProcessingException: Exception in creating Transform Handler at org.apache.cocoon.components.xslt.XSLTProcessorImpl.getTransformerHandler(XSLTProcessorImpl.java:271) at org.apache.cocoon.components.language.markup.Logicsheet.getTransformerHandler(Logicsheet.java:160) at org.apache.cocoon.components.language.markup.Logicsheet.getNamespaceURIs(Logicsheet.java:142) at org.apache.cocoon.components.language.markup.AbstractMarkupLanguage.addLogicsheetToList(AbstractMarkupLanguage.java:466) at org.apache.cocoon.components.language.markup.CocoonMarkupLanguage.addLogicsheetToList(CocoonMarkupLanguage.java:164) at org.apache.cocoon.components.language.markup.AbstractMarkupLanguage$TransformerChainBuilderFilter.startElement(AbstractMarkupLanguage.java:623) at org.apache.cocoon.components.language.markup.CocoonMarkupLanguage$CocoonTransformerChainBuilderFilter.startElement(CocoonMarkupLanguage.java:437) at org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:575) at org.apache.cocoon.components.language.markup.CocoonMarkupLanguage$PreProcessFilter.startElement(CocoonMarkupLanguage.java:286) at org.apache.cocoon.components.language.markup.xsp.XSPMarkupLanguage$PreProcessFilter.characters(XSPMarkupLanguage.java:162) at org.apache.xerces.parsers.SAXParser.characters(SAXParser.java:1579) at org.apache.xerces.validators.common.XMLValidator.processWhitespace(XMLValidator.java:998) at org.apache.xerces.readers.AbstractCharReader.callCharDataHandler(AbstractCharReader.java:1320) at org.apache.xerces.readers.AbstractCharReader.scanContent(AbstractCharReader.java:961) at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1094) at org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381) at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1098) at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371) at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371) at org.apache.cocoon.components.language.markup.LogicsheetCodeGenerator.generateCode(LogicsheetCodeGenerator.java:175) at org.apache.cocoon.components.language.markup.AbstractMarkupLanguage.generateCode(AbstractMarkupLanguage.java:390) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:365) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.createResource(ProgramGeneratorImpl.java:328) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:291) at org.apache.cocoon.generation.ServerPagesGenerator.setup(ServerPagesGenerator.java:203) at org.apache.cocoon.components.pipeline.AbstractEventPipeline.setupPipeline(AbstractEventPipeline.java:202) at org.apache.cocoon.components.pipeline.CachingEventPipeline.setup(CachingEventPipeline.java:279) at org.apache.cocoon.components.pipeline.CachingEventPipeline.generateKey(CachingEventPipeline.java:142) at org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingStreamPipeline.java:320) at org.apache.cocoon.www.mount.xindice.sitemap_xmap.matchN10069(/home/mb/daten/nobak/builds/tomcat/work/Standalone/localhost/cocoon/cocoon-files/org/apache/cocoon/www/mount/xindice/sitemap_xmap.java:873) at org.apache.cocoon.www.mount.xindice.sitemap_xmap.process(/home/mb/daten/nobak/builds/tomcat/work/Standalone/localhost/cocoon/cocoon-files/org/apache/cocoon/www/mount/xindice/sitemap_xmap.java:522) at
RE: [Possible Bug] TextSerializer loses characters with ASCII encodin g?
I should also mention that I'm using Saxon 6.5 as my XSLT engine. Harry -Original Message- From: Lai, Harry [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 02, 2002 2:19 PM To: 'Cocoon Users' Subject: [Possible Bug] TextSerializer loses characters with ASCII encodin g? Hi folks, I'm seeing some really odd behavior with serializers, and wanted to see if anyone had seen this before (or better yet) knows what's causing this. =) PROBLEM: If I set an XML, HTML, or Text serializer's encoding to ASCII, I end up losing the tail end of my output (roughly 1-1000 characters). I think it has to do with the buffered output stream not being properly closed/flushed, but I'm not sure. ENVIRONMENT: Cocoon 2.0.2 running on JBoss 2.4.5 with Tomcat 4.0.3. Win2k. WORKAROUNDS: I can make this problem go away by doing either of the following: 1. Change the encoding to UTF-8 or ISO-8859-1. 2. Change the buffer-size to 1 (tried with values from 1-2048; was still seeing the problem with values as low as 10). REPRODUCING THE BUG: From what I'm seeing, you can reproduce this bug by having a reasonably large buffer (larger than 10 bytes) and switching any TextSerializer-based serializer's encoding to ASCII. Here's a sample from my sitemap: map:serializer name=css mime-type=text/css logger=sitemap.serializer.css src=org.apache.cocoon.serialization.TextSerializer pool-max=64 pool-min=16 pool-grow=4 buffer-size2048/buffer-size encodingASCII/encoding /map:serializer Any thoughts, suggestions, ideas, etc. would be greatly appreciated. Thanks! Harry PS The main reason this comes up is for a dynamic css pipeline, which I'd like to be character set agnostic (hence, the ASCII encoding). I only tested it with the HTML and XML serializer to make sure it wasn't something specific to my css pipeline. -- Harry Lai [EMAIL PROTECTED] 512.682.1101 x2170 - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Possible bug ?
Just to follow up with this, it appears this a bit of a bug with C2. I don't know why the normal Cocoon sitemap wasn't working, but for my sitemap it was a case of a little too much cutting when I cut and pasted the sitemap: I was missing the pipeline tags. The questionable behavior is that Cocoon happily parsed the sitemap giving no errors and also ran the matchers reporting everything as normal in the logs... - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Possible bug?
Using: Jdk 1.4, Tomcat 2.0.3, Cocoon 2.0.2 I notice during creation of first XSP page I always get an error. The page is partially created, and after first image it errors. Refreshing the request results in a smooth operation. My hunch is that there might be a flaw during initialization? Response wasn't reset??? An extract from log: DEBUG (2002-04-04) 13:34.06:624 [access](/cocoon/somesite/images/downloads.jpg) HttpProcessor[80][5]/AbstractEnvironment: Changing Cocoon contextDEBUG (2002-04-04) 13:34.06:624 [access](/cocoon/somesite/images/downloads.jpg) HttpProcessor[80][5]/AbstractEnvironment: from context(file:/G:/Tomcat/webapps/cocoon/) and prefix()DEBUG (2002-04-04) 13:34.06:624 [access](/cocoon/somesite/images/downloads.jpg) HttpProcessor[80][5]/AbstractEnvironment: to context(sitemap.xmap) and prefix()DEBUG (2002-04-04) 13:34.06:624 [access](/cocoon/somesite/images/downloads.jpg) HttpProcessor[80][5]/AbstractEnvironment: at URI somesite/images/downloads.jpgDEBUG (2002-04-04) 13:34.06:624 [access](/cocoon/somesite/images/downloads.jpg) HttpProcessor[80][5]/AbstractEnvironment: New context is file:/G:/Tomcat/webapps/cocoon/DEBUG (2002-04-04) 13:34.06:624 [access](/cocoon/somesite/images/downloads.jpg) HttpProcessor[80][5]/AbstractEnvironment: Changing Cocoon contextDEBUG (2002-04-04) 13:34.06:624 [access](/cocoon/somesite/images/downloads.jpg) HttpProcessor[80][5]/AbstractEnvironment: from context(file:/G:/Tomcat/webapps/cocoon/) and prefix()DEBUG (2002-04-04) 13:34.06:624 [access](/cocoon/somesite/images/downloads.jpg) HttpProcessor[80][5]/AbstractEnvironment: to context(somesite/sitemap.xmap) and prefix(somesite)DEBUG (2002-04-04) 13:34.06:624 [access](/cocoon/somesite/images/downloads.jpg) HttpProcessor[80][5]/AbstractEnvironment: at URI somesite/images/downloads.jpgDEBUG (2002-04-04) 13:34.06:624 [access](/cocoon/somesite/images/downloads.jpg) HttpProcessor[80][5]/AbstractEnvironment: New context is file:/G:/Tomcat/webapps/cocoon/somesite/DEBUG (2002-04-04) 13:34.06:624 [access](/cocoon/somesite/images/login.jpg) HttpProcessor[80][6]/AbstractEnvironment: Set the URI Prefix (OLD=somesite/, NEW=)DEBUG (2002-04-04) 13:34.06:624 [access](/cocoon/somesite/images/login.jpg) HttpProcessor[80][6]/AbstractEnvironment: Reset context to file:/G:/Tomcat/webapps/cocoon/DEBUG (2002-04-04) 13:34.06:624 [access](/cocoon/somesite/images/login.jpg) HttpProcessor[80][6]/HttpEnvironment: Response wasn't resetDEBUG (2002-04-04) 13:34.06:634 [access](/cocoon/somesite/images/login.jpg) HttpProcessor[80][6]/AbstractEnvironment: Resolving 'stylesheets/system/error2html.xsl' in context 'file:/G:/Tomcat/webapps/cocoon/'DEBUG (2002-04-04) 13:34.06:634 [access](/cocoon/somesite/images/login.jpg) HttpProcessor[80][6]/AbstractEnvironment: Resolved to 'file:/G:/Tomcat/webapps/cocoon/stylesheets/system/error2html.xsl' snip DEBUG (2002-04-04) 13:34.06:714 [access](/cocoon/somesite/images/login.jpg) HttpProcessor[80][6]/AbstractEnvironment: Set the URI Prefix (OLD=, NEW=)DEBUG (2002-04-04) 13:34.06:714 [access](/cocoon/somesite/images/login.jpg) HttpProcessor[80][6]/AbstractEnvironment: Reset context to file:/G:/Tomcat/webapps/cocoon/ERROR (2002-04-04) 13:34.06:714 [access](/cocoon/somesite/images/login.jpg) HttpProcessor[80][6]/CocoonServlet: Problem with servletjava.lang.IllegalStateExceptionat org.apache.catalina.connector.HttpResponseFacade.sendError(HttpResponseFacade.java:159)at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1003)at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193 Reagrds, Mike Ahlers
Possible bug? (addendum)
Make that Tomcat 4.0.3 Oops Mike
Possible Bug ? Using cmp in directory name causes error in sitemap
To Cocoon-Users, See below: map:pipeline map:match pattern=mysubsite/** map:mount uri-prefix=mysubsite src=mysubsite/cmp/ check-reload=yes/ /map:match /map:pipeline When using cmp as a folder name I get the error message detailed at the end of this email. When I change this folder name to, say, fred, it works fine. Is cmp a reserved word in LDAP ??!?!??! Jason Uithol Data Technologist DatacodeX Pty Ltd [EMAIL PROTECTED] http://www.datacodex.com - THE ERROR MESSAGE - Cocoon 2 - Internal server error type internal-server-error message Error in sitemap configuration : org.apache.cocoon.transformation.LDAPTransformer description org.apache.avalon.framework.configuration.ConfigurationException: Error in sitemap configuration : org.apache.cocoon.transformation.LDAPTransformer sender org.apache.cocoon.servlet.CocoonServlet source Cocoon servlet request-uri /cocoon/ejbgen/asdasdad exception org.apache.avalon.framework.configuration.ConfigurationException: Error in sitemap configuration : org.apache.cocoon.transformation.LDAPTransformer path-info ejbgen/asdasdad stacktrace org.apache.avalon.framework.configuration.ConfigurationException: Error in sitemap configuration : org.apache.cocoon.transformation.LDAPTransformer at org.apache.cocoon.www.ejbgenerator.cmp.sitemap_xmap.configure(sitemap_xmap.j ava:188) at org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(Un known Source) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize( Unknown Source) at org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerat or(GeneratorSelector.java:135) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.addComp iledComponent(ProgramGeneratorImpl.java:345) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generat eResource(ProgramGeneratorImpl.java:323) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.createR esource(ProgramGeneratorImpl.java:271) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(Pr ogramGeneratorImpl.java:188) at org.apache.cocoon.sitemap.Handler.run(Handler.java:208) at java.lang.Thread.run(Thread.java:484) original exception Original exception : java.lang.ClassNotFoundException: org.apache.cocoon.transformation.LDAPTransformer at org.apache.tomcat.loader.AdaptiveClassLoader.loadClass(AdaptiveClassLoader.j ava:524) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at org.apache.cocoon.util.ClassUtils.loadClass(ClassUtils.java:46) at org.apache.cocoon.sitemap.AbstractSitemap.load_component(AbstractSitemap.jav a:219) at org.apache.cocoon.www.ejbgenerator.cmp.sitemap_xmap$Configurer.configTransfo rmers(sitemap_xmap.java:549) at org.apache.cocoon.www.ejbgenerator.cmp.sitemap_xmap.configure(sitemap_xmap.j ava:167) at org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(Un known Source) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize( Unknown Source) at org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerat or(GeneratorSelector.java:135) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.addComp iledComponent(ProgramGeneratorImpl.java:345) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generat eResource(ProgramGeneratorImpl.java:323) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.createR esource(ProgramGeneratorImpl.java:271) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(Pr ogramGeneratorImpl.java:188) at org.apache.cocoon.sitemap.Handler.run(Handler.java:208) at java.lang.Thread.run(Thread.java:484) - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
