cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Huttar <lars_hut...@sil.org>
Subject Re: cinclude doesn't cinclude, only garbles its input
Date Tue, 26 Jul 2005 20:06:01 GMT
Lars Huttar wrote:

> Dear Geert,
> Thanks for your reply.
>
> Geert Josten wrote:
>
>> Hi Lars,
>>
>> I have the impression that something is going wrong.
>
>
> :-) Me too!
>
>> Have you checked the log files for errors?
>
>
> Yes. There's nothing in the error.log corresponding to this problem. 
> The only hint there is that the count-rows.xsp is not compiled until I 
> call the count-rows URL 
> (http://localhost/mount/ethnologue/checks/count-rows?table=Development_Status) 
> directly... in other words, the cinclude transformer is not calling 
> the count-rows URL even though it is instructed to do so.
>
>> And what happens if you place the cincludes behind each other in 
>> stead of inside each other?
>
>
> In the input to the cinclude transformer (cocoon-view=raw), i.e. the 
> part that I can control, they are one-behind-the-other. It's only 
> after the cinclude transformer that they come out one-inside-the-other.
>
>>
>> If you want us to look at your url, please supply a correct dns or ip 
>> number and not just localhost.. ;-)
>>
> It would be nice if I could let everybody try it themselves, but our 
> project is on an intranet.
> I gave the URL just to illustrate how the URL is formed.
>
> Regards,
> Lars
>
>> Cheers,
>> Geert
>>
>> Lars Huttar wrote:
>>
>>> Dear Cocoonists,
>>>
>>> We're getting strange results from cinclude. It's all the more 
>>> baffling because cinclude works fine in many cases.
>>> FYI we've tried this with Tomcat 4.1, Tomcat 5.5, and Jetty, and 
>>> Cocoon 2.1.2, 2.1.5.1, and 2.1.7. All give the same results.
>>>
>>> When I run the troubled URL, 
>>> "http://localhost:8888/mount/ethnologue/checks/list-tables", the 
>>> browser gives an XML parsing error because the output from cinclude 
>>> is not well-formed XML: most elements have no close tags!
>>>
>>> If I do a view-source on the output of the cinclud transform, it 
>>> looks like this:
>>> <table xmlns:cinclude="http://apache.org/cocoon/include/1.0">
>>>  <cinclude:include 
>>> src="cocoon:/checks/count-rows?table=Development_Status">
>>>    <cinclude:include 
>>> src="cocoon:/checks/count-rows?table=Development_Type">
>>>      ...
>>>        <cinclude:include 
>>> src="cocoon:/checks/count-rows?table=Writing_System"/>
>>> (That's really the end!)
>>> Note that only the last element is closed.
>>>    The pipeline in the sitemap:
>>>      <map:match pattern="checks/list-tables">
>>>        <map:generate src="sources/ethnologue-schema.xml"/>
>>>        <!-- Generate cinclude statements for checks/count-rows from 
>>> <table> elements. -->
>>>        <map:transform src="transforms/list-tables-cinclude.xsl" 
>>> label="raw"/>
>>>        <!-- Process cinclude statements. -->
>>>        <map:transform type="cinclude" label="raw2"/>
>>>        <map:serialize type="xml"/>
>>>      </map:match>
>>>
>>> The data in the pipeline before the cinclude transformer 
>>> (check/list-tables?cocoon-view=raw) looks like this:
>>> <tables xmlns:cinclude="http://apache.org/cocoon/include/1.0">
>>>  <cinclude:include 
>>> src="cocoon:/checks/count-rows?table=Development_Status"/>
>>>  <cinclude:include 
>>> src="cocoon:/checks/count-rows?table=Development_Type"/>
>>>  ...
>>>  <cinclude:include 
>>> src="cocoon:/checks/count-rows?table=Writing_System"/>
>>> </tables>
>>>
>>> In other words, the output of the cinclude transformer is the same 
>>> as its input, except that each <cinclude:include> element becomes a 
>>> child of the previous one. Or to put it another way, all the 
>>> endElement events except one are dropped. There is no processing of 
>>> the src URLs.
>>> Incidentally, if you run the src URLs on their own, e.g. 
>>> http://localhost/mount/ethnologue/checks/count-rows?table=Development_Status,

>>>
>>> they run successfully and produce well-formed XML output:
>>>
>>> <table [namespace declarations for xsp, xspdoc, esql, xsp-request]>
>>>  <name>Development Status</name>
>>>  <count>11875</count>
>>> </table>
>>>
>>> As I mentioned at the top, cinclude works fine for us in other 
>>> applications.
>>>
>>> Any ideas?
>>>
>>> One interesting thing is that if we follow the cinclude transformer 
>>> with an XSLT transformer that simply copies its input, that the XSLT 
>>> transformer's output is
>>> <table xmlns:cinclude="http://apache.org/cocoon/include/1.0">
>>>  <cinclude:include 
>>> src="cocoon:/checks/count-rows?table=Development_Status">
>>>    <cinclude:include 
>>> src="cocoon:/checks/count-rows?table=Development_Type">
>>>      ...
>>>        <cinclude:include 
>>> src="cocoon:/checks/count-rows?table=Writing_System"/>
>>>      ...
>>>   </cinclude:include>
>>>  </cinclude:include>
>>> </table>
>>>
>>> In other words, all the unclosed elements get closed. But still no 
>>> indication of why they became children of each other, nor why the 
>>> <cinclude:include> elements didn't get replaced with the output of 
>>> their respective src pipelines.
>>>
>>> Any help would be appreciated...
>>> Lars
>>
>>
More data:

The above weird behavior with cinclude seems to be tied to Java 1.5.

In the following environments, the weird behavior occurs:
======================================
- Tomcat 5.5.9 and Cocoon 2.1.7 on Win2K or WinXP with JDK 1.5 - 
cinclude fails, weird behavior
- Tomcat 4.1 and Cocoon 2.1.2 on WinXP with JDK 1.5 - cinclude fails, 
weird behavior
- Jetty and Cocoon 2.1.7 on WinXP with JDK 1.5 - cinclude fails, weird 
behavior
- Tomcat 5.5.9 and Cocoon 2.1.7 on WinXP with JDK 1.4.2 and JRE 1.5 (JDK 
1.5 removed; JVM shown in Tomcat Monitor is  JRE 1.5) - cinclude fails, 
weird behavior
- Jetty in cocoon-2.1.7 with JAVA_HOME=JDK 1.4.2 (JDK1.5 gone, JRE 1.5 
is installed): - cinclude fails, weird behavior

In the following environment, cinclude works as expected (no weird 
behavior):
=====================================================
- Tomcat 4.1 and Cocoon 2.1.7 on WinXP with JDK 1.4.2 and JRE 1.5 
(JAVA_HOME is JDK 1.4.2; JDK 1.5 removed but JRE 1.5 still around) - had 
to rebuild Cocoon for JDK 1.4.2, but then it works fine!
- Tomcat 4.1 and cocoon 2.1.2 on WinXP with JDK 1.4.2 and JRE 1.5 
(JAVA_HOME is JDK 1.4.2; JDK 1.5 removed but JRE 1.5 still around) - 
works fine.
- Tomcat 5.0.27 and Cocoon 2.1.2 on Win2K with JDK 1.4.2 - cinclude 
works fine!

The exception to the above pattern is on Mac OSX, for which Java 1.5 is 
not yet available:
=============================================================
- Tomcat 5.5.9 (with compatibility pack for JDK 1.4.2) and Cocoon 2.1.7 
on Mac OS X, with JDK 1.4.2, JAVA_HOME is pointing to JRE - cinclude 
fails with weird behavior

So... anybody know why cinclude would misbehave under Java 1.5?
If I were to run Cocoon in a Java debugger (say, in Eclipse or JDB), any 
hints for finding the problem?

Again, very similar cincludes are working fine in the same environments 
where the weird behavior shows up for the cincludes mentioned in my OP. 
But the behavior is very reproducible.
So barring any better ideas, I'll probably try writing a working minimal 
cinclude and then gradually transform it into what I want and see at 
what point it starts to malfunction.

Thanks for any help.
Lars


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message