You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Olivier Billard <ob...@rennes.jouve.fr> on 2003/07/08 11:15:03 UTC
ChartTransformer, endorsed libs, Tomcat
Hi all !
I'm trying to port my project based on Cocoon M3 from
Window/JDK1.4.1/Embedded Jetty to Linux/JDK 1.4.1/Apache 2.0.46/Tomcat
4.1.24
I'm having some problems I didn't have with Jetty, concerning the
ChartTransformer. All seems to work fine.
I'm using the default xsltc transformer. Tomcat has the following libs
in common/endorsed :
xalan-2.4.1.jar xercesImpl-2.1.0.jar xml-apis.jar xsltc-20030211.jar
The new libs from M3 don't seem to works, neither with no libs...
Is there still some problems with the endorsed libs with this version of
tomcat ?
Must I copy the endorsed libs in an endorsed folder of the JDK ?
Thanks in advance !
--
Olivier BILLARD
Société Jouve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
[Solved] ChartTransformer, endorsed libs, Tomcat
Posted by Olivier Billard <ob...@rennes.jouve.fr>.
Thanks for all to answer this thread :) !
This pb came from 2 buggy components :
1 ) The jfreechart library uses some display features linked to the OS :
jar compiled in windows doesn't work in Unix OSes, but jar compiled in
Unix works in Windows.
this solved the graphic generation.
2) But I got a second issue : stats generated didn't care about
population in each category : if I have 4 resources in state "pending"
and just 1 in state "published", a pie chart by state displayed 50% for
each category. Once again, I changed the default "xslt" transformer to
"xalan" when generating the xml feeding the chart transformer, it worked...
I hope this will help users.
In the future, I think I will always try to change to xalan transformer
to see if it works...
--
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ChartTransformer, endorsed libs, Tomcat
Posted by Geoff Howard <co...@leverageweb.com>.
Yury Mikhienko wrote:
>>2. Be sure, that in TOMCAT_HOME/common/endorsed are *exactly the same*
>>libraries as in COCOON_HOME/WEB-INF/lib. And this does only work if you
>>use the default startup scripts delivered with TOMCAT. If you don't use
>>them you have to add
>>-Djava.endorsed.dirs=/your/path/to/the/endorsed/libs when starting the
>>Java process. This is the option TOMCAT sets in its start scripts to
>>TOMCAT_HOME/common/endorsed.
>>If you switch between Xalan/Xerces versions you must exchange the
>>libraries both in TOMCAT_HOME/common/endorsed and COCOON_HOME/WEB-INF/lib.
>>
>
> Why I must do it? I use Tomcat as servlet container for all servlets, not for Cocoon only.
> And all works fine, if I set in web.xml CocoonParanoidServlet instead of the CocoonServlet, but after this
> I can not make interaction between the Cocoon (in Paranoid mode) and other servlets in Tomcat.
>
...
>>6. The stacktrace is typical for endorsed libs problem - and often seen.
>
> I think, Cocoon2.1 is still crude :(((
> In my opinion the Cocoon2.0.4 at most stable version of Cocoon for this time.
This is a misguided statement and needs to be corrected:
This problem exists with Cocoon 2.0.x the same as 2.1 because it has
nothing to do with Cocoon. The "problem" is entirely related to two
things:
- the servlet container's classloading (in this case, tomcat)
- the outdated xml libraries shipped with JDK 1.4
Note that because it is implemented differently, Jetty does not have
this problem.
- Does updating the JDK's endorsed libs cause problems in your other
webapps? I doubt it, but if so, they need attention anyway. At some
point we can assume that the JDK will ship with updated xml libs.
- What specific problems are you encountering with ParanoidServlet and
other servlets in Tomcat?
Geoff Howard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ChartTransformer, endorsed libs, Tomcat
Posted by Yury Mikhienko <Yu...@mobicomk.ru>.
Many thanks for you answering.
I agree, but
> You both seem to have strange problems with those XML libraries which I
> don't have in general.
>
> 1. JDK 1.3 can't cause any problems in theory because it does not
> provide any XML library. If you have problems, something else must be
> the reason.
>
You are right.
> 2. Be sure, that in TOMCAT_HOME/common/endorsed are *exactly the same*
> libraries as in COCOON_HOME/WEB-INF/lib. And this does only work if you
> use the default startup scripts delivered with TOMCAT. If you don't use
> them you have to add
> -Djava.endorsed.dirs=/your/path/to/the/endorsed/libs when starting the
> Java process. This is the option TOMCAT sets in its start scripts to
> TOMCAT_HOME/common/endorsed.
> If you switch between Xalan/Xerces versions you must exchange the
> libraries both in TOMCAT_HOME/common/endorsed and COCOON_HOME/WEB-INF/lib.
>
Why I must do it? I use Tomcat as servlet container for all servlets, not for Cocoon only.
And all works fine, if I set in web.xml CocoonParanoidServlet instead of the CocoonServlet, but after this
I can not make interaction between the Cocoon (in Paranoid mode) and other servlets in Tomcat.
> 3. Test if you really use the XML libraries you think, use Xalan's
> environment check for it:
> http://xml.apache.org/xalan-j/faq.html#faq-N1005C. Try the stylesheet,
> it's easier. Of course you must use Xalan for it, not XSLTC. XSLTC does
> not support Xalan extension function which is used for the environment
> check.
>
for additional, XSLTC does not support XPath perfectly (in my opinion).
> 4. The hardest test for XSLT processors I know are the DocBook
> stylesheets. If a Xalan version works with those stylesheets it's
> /approved/. ;-) I don't see a difference between both (using Xalan, not
> XSLTC), both have a bug with the auto index generation. But of course if
> you use any specific thing that has changed between both versions, it's
> possible that 2.5.1 has problems that 2.4.1 does not have. But for most
> use cases it works, so Cocoon uses the most recent ones. If you have a
> specific problem, then you must switch back to the old version in your
> installation; we can't force all users to switch back. Furthermore this
> helps the Xalan team to fix recent bugs. If you think you know of one,
> post it at bugzilla.
>
Old version of Xalan and Xerces make the works of Cocoon-2.1m3 is very very hard and time of time I get the strange exceptions (OutOfMemory error, for example)
> 5. More stuff to read:
> http://wiki.cocoondev.org/Wiki.jsp?page=NoMoreDtmIdError
> http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem (including
> an alternative for never having any endorsed libs problem anymore :-) )
>
> 6. The stacktrace is typical for endorsed libs problem - and often seen.
>
I think, Cocoon2.1 is still crude :(((
In my opinion the Cocoon2.0.4 at most stable version of Cocoon for this time.
> Regards,
>
> Joerg
>
> Olivier Billard wrote:
> > I think it may come from the JDK that was installed (1.3.1), that may
> > cause problems with xalan-xsltc. Classic xalan works well
> > With a JDK 1.4, all works well
> >
> > Yury Mikhienko wrote:
> >
> >> May be xalan-2.5.1 is not quite up yet?
> >>
> >>
> >>
> >>> My pb seemed to come from Apache and its class-loader.
> >>> Tomcat in standalone mode seem to work...
> >>> For the exception you mentioned, I met this error today and it worked
> >>> when I changed back default Transformer to "xalan"...
> >>>
> >>> Yury Mikhienko wrote:
> >>>
> >>>
> >>>
> >>>> In additional: if I remove the xalan-2.4.1.jar
> >>>> xercesImpl-2.1.0.jar xml-apis.jar from Tomcat endorsed directory
> >>>> (like after the pure Tomcat installation)
> >>>> I get the following error:
> >>>>
> >>>> 2003-07-24 16:56:07 StandardWrapperValve[Cocoon]: Servlet.service()
> >>>> for servlet Cocoon threw exception
> >>>> javax.servlet.ServletException: Servlet execution threw an exception
> >>>> at
> >>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
> >>>>
> >>>> at
> >>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
> >>>>
> >>>> at
> >>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> >>>>
> >>>> at
> >>>> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
> >>>>
> >>>> at
> >>>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> >>>>
> >>>> at
> >>>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> >>>> ...
> >>>> ----- Root Cause -----
> >>>> java.lang.IllegalAccessError: class
> >>>> org.apache.xml.dtm.ref.sax2dtm.SAX2DTM2$AncestorIterator cannot
> >>>> access its superclass
> >>>> org.apache.xml.dtm.ref.DTMDefaultBaseIterators$InternalAxisIteratorBase
> >>>> at java.lang.ClassLoader.defineClass0(Native Method)
> >>>> at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
> >>>> at
> >>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
> >>>> at
> >>>> org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1679)
> >>>>
> >>>> at
> >>>> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:968)
> >>>>
> >>>> at
> >>>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1409)
> >>>>
> >>>> at
> >>>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1289)
> >>>>
> >>>> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
> >>>> at
> >>>> org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:291)
> >>>>
> >>>> at
> >>>> org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:174)
> >>>>
> >>>> at
> >>>> org.apache.xalan.xsltc.trax.TransformerHandlerImpl.startDocument(TransformerHandlerImpl.java:232)
> >>>>
> >>>> at
> >>>> org.apache.cocoon.xml.AbstractXMLPipe.startDocument(AbstractXMLPipe.java:83)
> >>>>
> >>>> ...
> >>>> It is VERY strange behavior :(((
> >>>>
> >>>> but all works fine if I copy into the Tomcat endorsed directory the
> >>>> xalan xercesImpl and xml-apis libs from cocoon/lib
> >>>> But xindice with some XPath expressions do not work correctly with
> >>>> xalan-2.5.1 & xercesImpl-2.4.0 lib's (with xalan-2.4.1.jar
> >>>> xercesImpl-2.1.0.jar all works fine)
> >>>> May be still to early to include the xalan-2.5.1 & xercesImpl-2.4.0
> >>>> lib's into the cocoon project?
> >>>>
> >>>> Can anyone say me where I'm wrong?
> >>>> Thanks for all.
>
--
Best regards,
Yury Mikhienko.
IT engineer, ZAO "Mobicom-Kavkaz"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ChartTransformer, endorsed libs, Tomcat
Posted by Olivier Billard <ob...@rennes.jouve.fr>.
Hi Joerg,
Thanks for the tips, but I think problems could come from a lot of
reasons with this pb.
In fact, with a Window2000, minimal Cocoon M3 build, and J2SDK 1.3.1,
the welcome page of Cocoon didn't appear with default xsltc transformer,
and it worked with "xalan" transformer...
I didn't read the welcome.xsl stylesheet, but I'm not sure it uses
advanced XSL features ;) ....
We used standard Tomcat run scripts and copied endorsed libs in
common/endorsed of Tomcat...
But we didn't had time to investigate more on the issue, so we let it
run with the "xalan" transformer.
Anyway, thanks very much for answering !
--
Olivier
Joerg Heinicke wrote:
> You both seem to have strange problems with those XML libraries which
> I don't have in general.
>
> 1. JDK 1.3 can't cause any problems in theory because it does not
> provide any XML library. If you have problems, something else must be
> the reason.
>
> 2. Be sure, that in TOMCAT_HOME/common/endorsed are *exactly the same*
> libraries as in COCOON_HOME/WEB-INF/lib. And this does only work if
> you use the default startup scripts delivered with TOMCAT. If you
> don't use them you have to add
> -Djava.endorsed.dirs=/your/path/to/the/endorsed/libs when starting the
> Java process. This is the option TOMCAT sets in its start scripts to
> TOMCAT_HOME/common/endorsed.
> If you switch between Xalan/Xerces versions you must exchange the
> libraries both in TOMCAT_HOME/common/endorsed and
> COCOON_HOME/WEB-INF/lib.
>
> 3. Test if you really use the XML libraries you think, use Xalan's
> environment check for it:
> http://xml.apache.org/xalan-j/faq.html#faq-N1005C. Try the stylesheet,
> it's easier. Of course you must use Xalan for it, not XSLTC. XSLTC
> does not support Xalan extension function which is used for the
> environment check.
>
> 4. The hardest test for XSLT processors I know are the DocBook
> stylesheets. If a Xalan version works with those stylesheets it's
> /approved/. ;-) I don't see a difference between both (using Xalan,
> not XSLTC), both have a bug with the auto index generation. But of
> course if you use any specific thing that has changed between both
> versions, it's possible that 2.5.1 has problems that 2.4.1 does not
> have. But for most use cases it works, so Cocoon uses the most recent
> ones. If you have a specific problem, then you must switch back to the
> old version in your installation; we can't force all users to switch
> back. Furthermore this helps the Xalan team to fix recent bugs. If you
> think you know of one, post it at bugzilla.
>
> 5. More stuff to read:
> http://wiki.cocoondev.org/Wiki.jsp?page=NoMoreDtmIdError
> http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem (including
> an alternative for never having any endorsed libs problem anymore :-) )
>
> 6. The stacktrace is typical for endorsed libs problem - and often seen.
>
> Regards,
>
> Joerg
>
> Olivier Billard wrote:
>
>> I think it may come from the JDK that was installed (1.3.1), that may
>> cause problems with xalan-xsltc. Classic xalan works well
>> With a JDK 1.4, all works well
>>
>> Yury Mikhienko wrote:
>>
>>> May be xalan-2.5.1 is not quite up yet?
>>>
>>>
>>>
>>>> My pb seemed to come from Apache and its class-loader.
>>>> Tomcat in standalone mode seem to work...
>>>> For the exception you mentioned, I met this error today and it
>>>> worked when I changed back default Transformer to "xalan"...
>>>>
>>>> Yury Mikhienko wrote:
>>>>
>>>>
>>>>
>>>>> In additional: if I remove the xalan-2.4.1.jar
>>>>> xercesImpl-2.1.0.jar xml-apis.jar from Tomcat endorsed directory
>>>>> (like after the pure Tomcat installation)
>>>>> I get the following error:
>>>>>
>>>>> 2003-07-24 16:56:07 StandardWrapperValve[Cocoon]:
>>>>> Servlet.service() for servlet Cocoon threw exception
>>>>> javax.servlet.ServletException: Servlet execution threw an exception
>>>>> at
>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>>>>>
>>>>> at
>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
>>>>>
>>>>> at
>>>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
>>>>>
>>>>> at
>>>>> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
>>>>>
>>>>> at
>>>>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>>>>>
>>>>> at
>>>>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>>>>> ...
>>>>> ----- Root Cause -----
>>>>> java.lang.IllegalAccessError: class
>>>>> org.apache.xml.dtm.ref.sax2dtm.SAX2DTM2$AncestorIterator cannot
>>>>> access its superclass
>>>>> org.apache.xml.dtm.ref.DTMDefaultBaseIterators$InternalAxisIteratorBase
>>>>>
>>>>> at java.lang.ClassLoader.defineClass0(Native Method)
>>>>> at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
>>>>> at
>>>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
>>>>>
>>>>> at
>>>>> org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1679)
>>>>>
>>>>> at
>>>>> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:968)
>>>>>
>>>>> at
>>>>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1409)
>>>>>
>>>>> at
>>>>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1289)
>>>>>
>>>>> at
>>>>> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
>>>>> at
>>>>> org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:291)
>>>>>
>>>>> at
>>>>> org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:174)
>>>>>
>>>>> at
>>>>> org.apache.xalan.xsltc.trax.TransformerHandlerImpl.startDocument(TransformerHandlerImpl.java:232)
>>>>>
>>>>> at
>>>>> org.apache.cocoon.xml.AbstractXMLPipe.startDocument(AbstractXMLPipe.java:83)
>>>>>
>>>>> ...
>>>>> It is VERY strange behavior :(((
>>>>>
>>>>> but all works fine if I copy into the Tomcat endorsed directory
>>>>> the xalan xercesImpl and xml-apis libs from cocoon/lib
>>>>> But xindice with some XPath expressions do not work correctly with
>>>>> xalan-2.5.1 & xercesImpl-2.4.0 lib's (with xalan-2.4.1.jar
>>>>> xercesImpl-2.1.0.jar all works fine)
>>>>> May be still to early to include the xalan-2.5.1 &
>>>>> xercesImpl-2.4.0 lib's into the cocoon project?
>>>>>
>>>>> Can anyone say me where I'm wrong?
>>>>> Thanks for all.
>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
AW: Using internal reader pipeline to generate stream
Posted by Marco Rolappe <m_...@web.de>.
hi mathias,
see below
> -----Ursprungliche Nachricht-----
> Von: users-return-53441-m_rolappe=web.de@cocoon.apache.org
> [mailto:users-return-53441-m_rolappe=web.de@cocoon.apache.org]Im Auftrag
> von Mathias Wiegard
> Gesendet: Freitag, 25. Juli 2003 17:47
> An: users@cocoon.apache.org
> Betreff: Using internal reader pipeline to generate stream
>
>
> Hi
> I have the following problem:
> I constructed a cocoon application with this structure:
> /
> /ts
> /ts/content
> /om
> /om/content
>
> Now, I wanna use a xml file of /om/content to use it in the subsitemap of
> /ts.
> What I've done is that i defined a pipeline i the sitemap of /ts that if
> someone is trying to reach ist subfolder /ts/om/ to get an xml
> file, it will
> be redirected to the sitemap of om, where a pipeline uses a reader to get
> the file:
>
> <map:match pattern="om/**.xml">
> <map:redirect-to uri="cocoon://om/{1}.xml"/>
>
try the following instead:
<map:match pattern="om/**.xml">
<map:generate src="cocoon://{0}"/>
<map:serialize type="xml"/>
</map:match
>
> No, I'm trying to use this on a pipeline like this:
> <map:match pattern="index.html">
> <map:generate src="cocoon:/om/index.xml"/>
> <map:transform src="style/blog2html.xsl"/>
> <map:serialize/>
> </map:match>
>
> I'm getting following error:
> Streaming of an internal pipeline is not possible with a reader.
>
> Any hints or suggestions to solve this problem without copying om into ts?
> Best regards, Mat
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Using internal reader pipeline to generate stream
Posted by Mathias Wiegard <Ma...@student.uni-ulm.de>.
Hi
I have the following problem:
I constructed a cocoon application with this structure:
/
/ts
/ts/content
/om
/om/content
Now, I wanna use a xml file of /om/content to use it in the subsitemap of
/ts.
What I've done is that i defined a pipeline i the sitemap of /ts that if
someone is trying to reach ist subfolder /ts/om/ to get an xml file, it will
be redirected to the sitemap of om, where a pipeline uses a reader to get
the file:
<map:match pattern="om/**.xml">
<map:redirect-to uri="cocoon://om/{1}.xml"/>
No, I'm trying to use this on a pipeline like this:
<map:match pattern="index.html">
<map:generate src="cocoon:/om/index.xml"/>
<map:transform src="style/blog2html.xsl"/>
<map:serialize/>
</map:match>
I'm getting following error:
Streaming of an internal pipeline is not possible with a reader.
Any hints or suggestions to solve this problem without copying om into ts?
Best regards, Mat
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ChartTransformer, endorsed libs, Tomcat
Posted by Joerg Heinicke <jo...@gmx.de>.
You both seem to have strange problems with those XML libraries which I
don't have in general.
1. JDK 1.3 can't cause any problems in theory because it does not
provide any XML library. If you have problems, something else must be
the reason.
2. Be sure, that in TOMCAT_HOME/common/endorsed are *exactly the same*
libraries as in COCOON_HOME/WEB-INF/lib. And this does only work if you
use the default startup scripts delivered with TOMCAT. If you don't use
them you have to add
-Djava.endorsed.dirs=/your/path/to/the/endorsed/libs when starting the
Java process. This is the option TOMCAT sets in its start scripts to
TOMCAT_HOME/common/endorsed.
If you switch between Xalan/Xerces versions you must exchange the
libraries both in TOMCAT_HOME/common/endorsed and COCOON_HOME/WEB-INF/lib.
3. Test if you really use the XML libraries you think, use Xalan's
environment check for it:
http://xml.apache.org/xalan-j/faq.html#faq-N1005C. Try the stylesheet,
it's easier. Of course you must use Xalan for it, not XSLTC. XSLTC does
not support Xalan extension function which is used for the environment
check.
4. The hardest test for XSLT processors I know are the DocBook
stylesheets. If a Xalan version works with those stylesheets it's
/approved/. ;-) I don't see a difference between both (using Xalan, not
XSLTC), both have a bug with the auto index generation. But of course if
you use any specific thing that has changed between both versions, it's
possible that 2.5.1 has problems that 2.4.1 does not have. But for most
use cases it works, so Cocoon uses the most recent ones. If you have a
specific problem, then you must switch back to the old version in your
installation; we can't force all users to switch back. Furthermore this
helps the Xalan team to fix recent bugs. If you think you know of one,
post it at bugzilla.
5. More stuff to read:
http://wiki.cocoondev.org/Wiki.jsp?page=NoMoreDtmIdError
http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem (including
an alternative for never having any endorsed libs problem anymore :-) )
6. The stacktrace is typical for endorsed libs problem - and often seen.
Regards,
Joerg
Olivier Billard wrote:
> I think it may come from the JDK that was installed (1.3.1), that may
> cause problems with xalan-xsltc. Classic xalan works well
> With a JDK 1.4, all works well
>
> Yury Mikhienko wrote:
>
>> May be xalan-2.5.1 is not quite up yet?
>>
>>
>>
>>> My pb seemed to come from Apache and its class-loader.
>>> Tomcat in standalone mode seem to work...
>>> For the exception you mentioned, I met this error today and it worked
>>> when I changed back default Transformer to "xalan"...
>>>
>>> Yury Mikhienko wrote:
>>>
>>>
>>>
>>>> In additional: if I remove the xalan-2.4.1.jar
>>>> xercesImpl-2.1.0.jar xml-apis.jar from Tomcat endorsed directory
>>>> (like after the pure Tomcat installation)
>>>> I get the following error:
>>>>
>>>> 2003-07-24 16:56:07 StandardWrapperValve[Cocoon]: Servlet.service()
>>>> for servlet Cocoon threw exception
>>>> javax.servlet.ServletException: Servlet execution threw an exception
>>>> at
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>>>>
>>>> at
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
>>>>
>>>> at
>>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
>>>>
>>>> at
>>>> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
>>>>
>>>> at
>>>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>>>>
>>>> at
>>>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>>>> ...
>>>> ----- Root Cause -----
>>>> java.lang.IllegalAccessError: class
>>>> org.apache.xml.dtm.ref.sax2dtm.SAX2DTM2$AncestorIterator cannot
>>>> access its superclass
>>>> org.apache.xml.dtm.ref.DTMDefaultBaseIterators$InternalAxisIteratorBase
>>>> at java.lang.ClassLoader.defineClass0(Native Method)
>>>> at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
>>>> at
>>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
>>>> at
>>>> org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1679)
>>>>
>>>> at
>>>> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:968)
>>>>
>>>> at
>>>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1409)
>>>>
>>>> at
>>>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1289)
>>>>
>>>> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
>>>> at
>>>> org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:291)
>>>>
>>>> at
>>>> org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:174)
>>>>
>>>> at
>>>> org.apache.xalan.xsltc.trax.TransformerHandlerImpl.startDocument(TransformerHandlerImpl.java:232)
>>>>
>>>> at
>>>> org.apache.cocoon.xml.AbstractXMLPipe.startDocument(AbstractXMLPipe.java:83)
>>>>
>>>> ...
>>>> It is VERY strange behavior :(((
>>>>
>>>> but all works fine if I copy into the Tomcat endorsed directory the
>>>> xalan xercesImpl and xml-apis libs from cocoon/lib
>>>> But xindice with some XPath expressions do not work correctly with
>>>> xalan-2.5.1 & xercesImpl-2.4.0 lib's (with xalan-2.4.1.jar
>>>> xercesImpl-2.1.0.jar all works fine)
>>>> May be still to early to include the xalan-2.5.1 & xercesImpl-2.4.0
>>>> lib's into the cocoon project?
>>>>
>>>> Can anyone say me where I'm wrong?
>>>> Thanks for all.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ChartTransformer, endorsed libs, Tomcat
Posted by Olivier Billard <ob...@rennes.jouve.fr>.
I think it may come from the JDK that was installed (1.3.1), that may
cause problems with xalan-xsltc. Classic xalan works well
With a JDK 1.4, all works well
Yury Mikhienko wrote:
>May be xalan-2.5.1 is not quite up yet?
>
>
>
>>My pb seemed to come from Apache and its class-loader.
>>Tomcat in standalone mode seem to work...
>>For the exception you mentioned, I met this error today and it worked
>>when I changed back default Transformer to "xalan"...
>>
>>Yury Mikhienko wrote:
>>
>>
>>
>>>In additional: if I remove the xalan-2.4.1.jar xercesImpl-2.1.0.jar xml-apis.jar from Tomcat endorsed directory (like after the pure Tomcat installation)
>>>I get the following error:
>>>
>>>2003-07-24 16:56:07 StandardWrapperValve[Cocoon]: Servlet.service() for servlet Cocoon threw exception
>>>javax.servlet.ServletException: Servlet execution threw an exception
>>> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>>> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
>>> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
>>> at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
>>> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>>> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>>>...
>>>----- Root Cause -----
>>>java.lang.IllegalAccessError: class org.apache.xml.dtm.ref.sax2dtm.SAX2DTM2$AncestorIterator cannot access its superclass org.apache.xml.dtm.ref.DTMDefaultBaseIterators$InternalAxisIteratorBase
>>> at java.lang.ClassLoader.defineClass0(Native Method)
>>> at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
>>> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
>>> at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1679)
>>> at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:968)
>>> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1409)
>>> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1289)
>>> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
>>> at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:291)
>>> at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:174)
>>> at org.apache.xalan.xsltc.trax.TransformerHandlerImpl.startDocument(TransformerHandlerImpl.java:232)
>>> at org.apache.cocoon.xml.AbstractXMLPipe.startDocument(AbstractXMLPipe.java:83)
>>>...
>>>It is VERY strange behavior :(((
>>>
>>>but all works fine if I copy into the Tomcat endorsed directory the xalan xercesImpl and xml-apis libs from cocoon/lib
>>>But xindice with some XPath expressions do not work correctly with xalan-2.5.1 & xercesImpl-2.4.0 lib's (with xalan-2.4.1.jar xercesImpl-2.1.0.jar all works fine)
>>>May be still to early to include the xalan-2.5.1 & xercesImpl-2.4.0 lib's into the cocoon project?
>>>
>>>Can anyone say me where I'm wrong?
>>>Thanks for all.
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Joerg Heinicke wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Is this problem still an issue? Or are all your problems solved with
>>>>>the other thread?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Unfortunately not...
>>>>When I copy endorsed libs to tomcat from those shipped with Cocoon M3,
>>>>my page is blank... Some pipelines are working, but other aren't...
>>>>Especially a pipeline taking
>>>>a session parameter. But this one is working with my local tomcat, with
>>>>the same libs in the endorsed folder.
>>>>
>>>>The webapps are strictly the sames in the 2 PCs.
>>>>Am I going crazy ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Olivier Billard wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi all !
>>>>>>
>>>>>>I'm trying to port my project based on Cocoon M3 from
>>>>>>Window/JDK1.4.1/Embedded Jetty to Linux/JDK 1.4.1/Apache
>>>>>>2.0.46/Tomcat 4.1.24
>>>>>>I'm having some problems I didn't have with Jetty, concerning the
>>>>>>ChartTransformer. All seems to work fine.
>>>>>>
>>>>>>I'm using the default xsltc transformer. Tomcat has the following
>>>>>>libs in common/endorsed :
>>>>>>xalan-2.4.1.jar xercesImpl-2.1.0.jar xml-apis.jar xsltc-20030211.jar
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>If you put those to Tomcat you should use the same libs in Cocoon. The
>>>>>endorsed libs and the libs used in Cocoon should always be the same.
>>>>>Otherwise there is the risk of getting ClassCastExceptions or strange
>>>>>messages.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I didn't take this into account. Thanks. But it seem to work, and only
>>>>in this case...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>The new libs from M3 don't seem to works, neither with no libs...
>>>>>>
>>>>>>Is there still some problems with the endorsed libs with this version
>>>>>>of tomcat ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>This problem will remain until the XML libs are removed from JDK - and
>>>>>I guess this will never happen. And not only with Tomcat but all
>>>>>environments processing XML.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Gasp...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>Must I copy the endorsed libs in an endorsed folder of the JDK ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>No. Setting the java.endorsed.dirs property is enough. And exactly
>>>>>this Tomcat is doing in its start scripts.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Ok.
>>>>The app on the server is going to be tested, so I'll try to investigate
>>>>on this issue after tests.
>>>>
>>>>Thanks anyway, Joerg !
>>>>
>>>>--
>>>>Olivier
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>>>For additional commands, e-mail: users-help@cocoon.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>--
>>Olivier BILLARD
>>SociИtИ Jouve
>>Tel : 33 2 99 86 93 55
>>Mail : obillard@rennes.jouve.fr
>>
>>Le prИsent mail ainsi que toutes les informations qu'il contient ne peuvent en aucun cas Йtre considИrИs comme un engagement juridique de quelque nature que ce soit de JOUVE. Tout accord devra Йtre formulИ par Иcrit papier ultИrieur signИ par un reprИsentant lИgal de JOUVE. Par ailleurs, si vous recevez ce mail par erreur, merci de nous le signaler et de le dИtruire ainsi que l'intИgralitИ du document qui pourrait y Йtre joint.
>>
>>The present email and all information included therein do not constitute a legal agreement accorded by Jouve. All legal agreements must be formulated in writing on paper by a legal representative of JOUVE. If you have received this email by mistake, please inform us of that fact and destroy the email and any documents it might contain. Thank you for your cooperation.
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>
>
>
>
--
Olivier BILLARD
Socie'te' Jouve
Tel : 33 2 99 86 93 55
Mail : obillard@rennes.jouve.fr
Le pre'sent mail ainsi que toutes les informations qu'il contient ne peuvent en aucun cas e^tre conside're's comme un engagement juridique de quelque nature que ce soit de JOUVE. Tout accord devra e^tre formule' par e'crit papier ulte'rieur signe' par un repre'sentant le'gal de JOUVE. Par ailleurs, si vous recevez ce mail par erreur, merci de nous le signaler et de le de'truire ainsi que l'inte'gralite' du document qui pourrait y e^tre joint.
The present email and all information included therein do not constitute a legal agreement accorded by Jouve. All legal agreements must be formulated in writing on paper by a legal representative of JOUVE. If you have received this email by mistake, please inform us of that fact and destroy the email and any documents it might contain. Thank you for your cooperation.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ChartTransformer, endorsed libs, Tomcat
Posted by Yury Mikhienko <Yu...@mobicomk.ru>.
May be xalan-2.5.1 is not quite up yet?
> My pb seemed to come from Apache and its class-loader.
> Tomcat in standalone mode seem to work...
> For the exception you mentioned, I met this error today and it worked
> when I changed back default Transformer to "xalan"...
>
> Yury Mikhienko wrote:
>
> >In additional: if I remove the xalan-2.4.1.jar xercesImpl-2.1.0.jar xml-apis.jar from Tomcat endorsed directory (like after the pure Tomcat installation)
> >I get the following error:
> >
> >2003-07-24 16:56:07 StandardWrapperValve[Cocoon]: Servlet.service() for servlet Cocoon threw exception
> >javax.servlet.ServletException: Servlet execution threw an exception
> > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
> > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
> > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> > at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
> > at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> > at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> >...
> >----- Root Cause -----
> >java.lang.IllegalAccessError: class org.apache.xml.dtm.ref.sax2dtm.SAX2DTM2$AncestorIterator cannot access its superclass org.apache.xml.dtm.ref.DTMDefaultBaseIterators$InternalAxisIteratorBase
> > at java.lang.ClassLoader.defineClass0(Native Method)
> > at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
> > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
> > at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1679)
> > at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:968)
> > at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1409)
> > at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1289)
> > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
> > at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:291)
> > at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:174)
> > at org.apache.xalan.xsltc.trax.TransformerHandlerImpl.startDocument(TransformerHandlerImpl.java:232)
> > at org.apache.cocoon.xml.AbstractXMLPipe.startDocument(AbstractXMLPipe.java:83)
> >...
> >It is VERY strange behavior :(((
> >
> >but all works fine if I copy into the Tomcat endorsed directory the xalan xercesImpl and xml-apis libs from cocoon/lib
> >But xindice with some XPath expressions do not work correctly with xalan-2.5.1 & xercesImpl-2.4.0 lib's (with xalan-2.4.1.jar xercesImpl-2.1.0.jar all works fine)
> >May be still to early to include the xalan-2.5.1 & xercesImpl-2.4.0 lib's into the cocoon project?
> >
> >Can anyone say me where I'm wrong?
> >Thanks for all.
> >
> >
> >
> >
> >>Joerg Heinicke wrote:
> >>
> >>
> >>
> >>>Is this problem still an issue? Or are all your problems solved with
> >>>the other thread?
> >>>
> >>>
> >>Unfortunately not...
> >>When I copy endorsed libs to tomcat from those shipped with Cocoon M3,
> >>my page is blank... Some pipelines are working, but other aren't...
> >>Especially a pipeline taking
> >>a session parameter. But this one is working with my local tomcat, with
> >>the same libs in the endorsed folder.
> >>
> >>The webapps are strictly the sames in the 2 PCs.
> >>Am I going crazy ?
> >>
> >>
> >>
> >>>Olivier Billard wrote:
> >>>
> >>>
> >>>
> >>>>Hi all !
> >>>>
> >>>>I'm trying to port my project based on Cocoon M3 from
> >>>>Window/JDK1.4.1/Embedded Jetty to Linux/JDK 1.4.1/Apache
> >>>>2.0.46/Tomcat 4.1.24
> >>>>I'm having some problems I didn't have with Jetty, concerning the
> >>>>ChartTransformer. All seems to work fine.
> >>>>
> >>>>I'm using the default xsltc transformer. Tomcat has the following
> >>>>libs in common/endorsed :
> >>>>xalan-2.4.1.jar xercesImpl-2.1.0.jar xml-apis.jar xsltc-20030211.jar
> >>>>
> >>>>
> >>>If you put those to Tomcat you should use the same libs in Cocoon. The
> >>>endorsed libs and the libs used in Cocoon should always be the same.
> >>>Otherwise there is the risk of getting ClassCastExceptions or strange
> >>>messages.
> >>>
> >>>
> >>I didn't take this into account. Thanks. But it seem to work, and only
> >>in this case...
> >>
> >>
> >>
> >>>>The new libs from M3 don't seem to works, neither with no libs...
> >>>>
> >>>>Is there still some problems with the endorsed libs with this version
> >>>>of tomcat ?
> >>>>
> >>>>
> >>>This problem will remain until the XML libs are removed from JDK - and
> >>>I guess this will never happen. And not only with Tomcat but all
> >>>environments processing XML.
> >>>
> >>>
> >>Gasp...
> >>
> >>
> >>
> >>>>Must I copy the endorsed libs in an endorsed folder of the JDK ?
> >>>>
> >>>>
> >>>No. Setting the java.endorsed.dirs property is enough. And exactly
> >>>this Tomcat is doing in its start scripts.
> >>>
> >>>
> >>Ok.
> >>The app on the server is going to be tested, so I'll try to investigate
> >>on this issue after tests.
> >>
> >>Thanks anyway, Joerg !
> >>
> >>--
> >>Olivier
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> >>For additional commands, e-mail: users-help@cocoon.apache.org
> >>
> >>
> >
> >
> >
> >
>
> --
> Olivier BILLARD
> SociИtИ Jouve
> Tel : 33 2 99 86 93 55
> Mail : obillard@rennes.jouve.fr
>
> Le prИsent mail ainsi que toutes les informations qu'il contient ne peuvent en aucun cas Йtre considИrИs comme un engagement juridique de quelque nature que ce soit de JOUVE. Tout accord devra Йtre formulИ par Иcrit papier ultИrieur signИ par un reprИsentant lИgal de JOUVE. Par ailleurs, si vous recevez ce mail par erreur, merci de nous le signaler et de le dИtruire ainsi que l'intИgralitИ du document qui pourrait y Йtre joint.
>
> The present email and all information included therein do not constitute a legal agreement accorded by Jouve. All legal agreements must be formulated in writing on paper by a legal representative of JOUVE. If you have received this email by mistake, please inform us of that fact and destroy the email and any documents it might contain. Thank you for your cooperation.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
--
Best regards,
Yury Mikhienko.
IT engineer, ZAO "Mobicom-Kavkaz"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ChartTransformer, endorsed libs, Tomcat
Posted by Olivier Billard <ob...@rennes.jouve.fr>.
My pb seemed to come from Apache and its class-loader.
Tomcat in standalone mode seem to work...
For the exception you mentioned, I met this error today and it worked
when I changed back default Transformer to "xalan"...
Yury Mikhienko wrote:
>In additional: if I remove the xalan-2.4.1.jar xercesImpl-2.1.0.jar xml-apis.jar from Tomcat endorsed directory (like after the pure Tomcat installation)
>I get the following error:
>
>2003-07-24 16:56:07 StandardWrapperValve[Cocoon]: Servlet.service() for servlet Cocoon threw exception
>javax.servlet.ServletException: Servlet execution threw an exception
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>...
>----- Root Cause -----
>java.lang.IllegalAccessError: class org.apache.xml.dtm.ref.sax2dtm.SAX2DTM2$AncestorIterator cannot access its superclass org.apache.xml.dtm.ref.DTMDefaultBaseIterators$InternalAxisIteratorBase
> at java.lang.ClassLoader.defineClass0(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
> at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1679)
> at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:968)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1409)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1289)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
> at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:291)
> at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:174)
> at org.apache.xalan.xsltc.trax.TransformerHandlerImpl.startDocument(TransformerHandlerImpl.java:232)
> at org.apache.cocoon.xml.AbstractXMLPipe.startDocument(AbstractXMLPipe.java:83)
>...
>It is VERY strange behavior :(((
>
>but all works fine if I copy into the Tomcat endorsed directory the xalan xercesImpl and xml-apis libs from cocoon/lib
>But xindice with some XPath expressions do not work correctly with xalan-2.5.1 & xercesImpl-2.4.0 lib's (with xalan-2.4.1.jar xercesImpl-2.1.0.jar all works fine)
>May be still to early to include the xalan-2.5.1 & xercesImpl-2.4.0 lib's into the cocoon project?
>
>Can anyone say me where I'm wrong?
>Thanks for all.
>
>
>
>
>>Joerg Heinicke wrote:
>>
>>
>>
>>>Is this problem still an issue? Or are all your problems solved with
>>>the other thread?
>>>
>>>
>>Unfortunately not...
>>When I copy endorsed libs to tomcat from those shipped with Cocoon M3,
>>my page is blank... Some pipelines are working, but other aren't...
>>Especially a pipeline taking
>>a session parameter. But this one is working with my local tomcat, with
>>the same libs in the endorsed folder.
>>
>>The webapps are strictly the sames in the 2 PCs.
>>Am I going crazy ?
>>
>>
>>
>>>Olivier Billard wrote:
>>>
>>>
>>>
>>>>Hi all !
>>>>
>>>>I'm trying to port my project based on Cocoon M3 from
>>>>Window/JDK1.4.1/Embedded Jetty to Linux/JDK 1.4.1/Apache
>>>>2.0.46/Tomcat 4.1.24
>>>>I'm having some problems I didn't have with Jetty, concerning the
>>>>ChartTransformer. All seems to work fine.
>>>>
>>>>I'm using the default xsltc transformer. Tomcat has the following
>>>>libs in common/endorsed :
>>>>xalan-2.4.1.jar xercesImpl-2.1.0.jar xml-apis.jar xsltc-20030211.jar
>>>>
>>>>
>>>If you put those to Tomcat you should use the same libs in Cocoon. The
>>>endorsed libs and the libs used in Cocoon should always be the same.
>>>Otherwise there is the risk of getting ClassCastExceptions or strange
>>>messages.
>>>
>>>
>>I didn't take this into account. Thanks. But it seem to work, and only
>>in this case...
>>
>>
>>
>>>>The new libs from M3 don't seem to works, neither with no libs...
>>>>
>>>>Is there still some problems with the endorsed libs with this version
>>>>of tomcat ?
>>>>
>>>>
>>>This problem will remain until the XML libs are removed from JDK - and
>>>I guess this will never happen. And not only with Tomcat but all
>>>environments processing XML.
>>>
>>>
>>Gasp...
>>
>>
>>
>>>>Must I copy the endorsed libs in an endorsed folder of the JDK ?
>>>>
>>>>
>>>No. Setting the java.endorsed.dirs property is enough. And exactly
>>>this Tomcat is doing in its start scripts.
>>>
>>>
>>Ok.
>>The app on the server is going to be tested, so I'll try to investigate
>>on this issue after tests.
>>
>>Thanks anyway, Joerg !
>>
>>--
>>Olivier
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>
>
>
>
--
Olivier BILLARD
Société Jouve
Tel : 33 2 99 86 93 55
Mail : obillard@rennes.jouve.fr
Le présent mail ainsi que toutes les informations qu'il contient ne peuvent en aucun cas être considérés comme un engagement juridique de quelque nature que ce soit de JOUVE. Tout accord devra être formulé par écrit papier ultérieur signé par un représentant légal de JOUVE. Par ailleurs, si vous recevez ce mail par erreur, merci de nous le signaler et de le détruire ainsi que l'intégralité du document qui pourrait y être joint.
The present email and all information included therein do not constitute a legal agreement accorded by Jouve. All legal agreements must be formulated in writing on paper by a legal representative of JOUVE. If you have received this email by mistake, please inform us of that fact and destroy the email and any documents it might contain. Thank you for your cooperation.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ChartTransformer, endorsed libs, Tomcat
Posted by Yury Mikhienko <Yu...@mobicomk.ru>.
In additional: if I remove the xalan-2.4.1.jar xercesImpl-2.1.0.jar xml-apis.jar from Tomcat endorsed directory (like after the pure Tomcat installation)
I get the following error:
2003-07-24 16:56:07 StandardWrapperValve[Cocoon]: Servlet.service() for servlet Cocoon threw exception
javax.servlet.ServletException: Servlet execution threw an exception
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
...
----- Root Cause -----
java.lang.IllegalAccessError: class org.apache.xml.dtm.ref.sax2dtm.SAX2DTM2$AncestorIterator cannot access its superclass org.apache.xml.dtm.ref.DTMDefaultBaseIterators$InternalAxisIteratorBase
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1679)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:968)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1409)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1289)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:291)
at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:174)
at org.apache.xalan.xsltc.trax.TransformerHandlerImpl.startDocument(TransformerHandlerImpl.java:232)
at org.apache.cocoon.xml.AbstractXMLPipe.startDocument(AbstractXMLPipe.java:83)
...
It is VERY strange behavior :(((
but all works fine if I copy into the Tomcat endorsed directory the xalan xercesImpl and xml-apis libs from cocoon/lib
But xindice with some XPath expressions do not work correctly with xalan-2.5.1 & xercesImpl-2.4.0 lib's (with xalan-2.4.1.jar xercesImpl-2.1.0.jar all works fine)
May be still to early to include the xalan-2.5.1 & xercesImpl-2.4.0 lib's into the cocoon project?
Can anyone say me where I'm wrong?
Thanks for all.
> Joerg Heinicke wrote:
>
> > Is this problem still an issue? Or are all your problems solved with
> > the other thread?
>
> Unfortunately not...
> When I copy endorsed libs to tomcat from those shipped with Cocoon M3,
> my page is blank... Some pipelines are working, but other aren't...
> Especially a pipeline taking
> a session parameter. But this one is working with my local tomcat, with
> the same libs in the endorsed folder.
>
> The webapps are strictly the sames in the 2 PCs.
> Am I going crazy ?
>
> > Olivier Billard wrote:
> >
> >> Hi all !
> >>
> >> I'm trying to port my project based on Cocoon M3 from
> >> Window/JDK1.4.1/Embedded Jetty to Linux/JDK 1.4.1/Apache
> >> 2.0.46/Tomcat 4.1.24
> >> I'm having some problems I didn't have with Jetty, concerning the
> >> ChartTransformer. All seems to work fine.
> >>
> >> I'm using the default xsltc transformer. Tomcat has the following
> >> libs in common/endorsed :
> >> xalan-2.4.1.jar xercesImpl-2.1.0.jar xml-apis.jar xsltc-20030211.jar
> >
> >
> > If you put those to Tomcat you should use the same libs in Cocoon. The
> > endorsed libs and the libs used in Cocoon should always be the same.
> > Otherwise there is the risk of getting ClassCastExceptions or strange
> > messages.
>
>
> I didn't take this into account. Thanks. But it seem to work, and only
> in this case...
>
> >> The new libs from M3 don't seem to works, neither with no libs...
> >>
> >> Is there still some problems with the endorsed libs with this version
> >> of tomcat ?
> >
> >
> > This problem will remain until the XML libs are removed from JDK - and
> > I guess this will never happen. And not only with Tomcat but all
> > environments processing XML.
>
> Gasp...
>
> >> Must I copy the endorsed libs in an endorsed folder of the JDK ?
> >
> > No. Setting the java.endorsed.dirs property is enough. And exactly
> > this Tomcat is doing in its start scripts.
>
> Ok.
> The app on the server is going to be tested, so I'll try to investigate
> on this issue after tests.
>
> Thanks anyway, Joerg !
>
> --
> Olivier
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
--
Best regards,
Yury Mikhienko.
IT engineer, ZAO "Mobicom-Kavkaz"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ChartTransformer, endorsed libs, Tomcat
Posted by Olivier Billard <ob...@rennes.jouve.fr>.
Joerg Heinicke wrote:
> Is this problem still an issue? Or are all your problems solved with
> the other thread?
Unfortunately not...
When I copy endorsed libs to tomcat from those shipped with Cocoon M3,
my page is blank... Some pipelines are working, but other aren't...
Especially a pipeline taking
a session parameter. But this one is working with my local tomcat, with
the same libs in the endorsed folder.
The webapps are strictly the sames in the 2 PCs.
Am I going crazy ?
> Olivier Billard wrote:
>
>> Hi all !
>>
>> I'm trying to port my project based on Cocoon M3 from
>> Window/JDK1.4.1/Embedded Jetty to Linux/JDK 1.4.1/Apache
>> 2.0.46/Tomcat 4.1.24
>> I'm having some problems I didn't have with Jetty, concerning the
>> ChartTransformer. All seems to work fine.
>>
>> I'm using the default xsltc transformer. Tomcat has the following
>> libs in common/endorsed :
>> xalan-2.4.1.jar xercesImpl-2.1.0.jar xml-apis.jar xsltc-20030211.jar
>
>
> If you put those to Tomcat you should use the same libs in Cocoon. The
> endorsed libs and the libs used in Cocoon should always be the same.
> Otherwise there is the risk of getting ClassCastExceptions or strange
> messages.
I didn't take this into account. Thanks. But it seem to work, and only
in this case...
>> The new libs from M3 don't seem to works, neither with no libs...
>>
>> Is there still some problems with the endorsed libs with this version
>> of tomcat ?
>
>
> This problem will remain until the XML libs are removed from JDK - and
> I guess this will never happen. And not only with Tomcat but all
> environments processing XML.
Gasp...
>> Must I copy the endorsed libs in an endorsed folder of the JDK ?
>
> No. Setting the java.endorsed.dirs property is enough. And exactly
> this Tomcat is doing in its start scripts.
Ok.
The app on the server is going to be tested, so I'll try to investigate
on this issue after tests.
Thanks anyway, Joerg !
--
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ChartTransformer, endorsed libs, Tomcat
Posted by Joerg Heinicke <jo...@gmx.de>.
Is this problem still an issue? Or are all your problems solved with the
other thread?
Olivier Billard wrote:
> Hi all !
>
> I'm trying to port my project based on Cocoon M3 from
> Window/JDK1.4.1/Embedded Jetty to Linux/JDK 1.4.1/Apache 2.0.46/Tomcat
> 4.1.24
> I'm having some problems I didn't have with Jetty, concerning the
> ChartTransformer. All seems to work fine.
>
> I'm using the default xsltc transformer. Tomcat has the following libs
> in common/endorsed :
> xalan-2.4.1.jar xercesImpl-2.1.0.jar xml-apis.jar xsltc-20030211.jar
If you put those to Tomcat you should use the same libs in Cocoon. The
endorsed libs and the libs used in Cocoon should always be the same.
Otherwise there is the risk of getting ClassCastExceptions or strange
messages.
> The new libs from M3 don't seem to works, neither with no libs...
>
> Is there still some problems with the endorsed libs with this version of
> tomcat ?
This problem will remain until the XML libs are removed from JDK - and I
guess this will never happen. And not only with Tomcat but all
environments processing XML.
> Must I copy the endorsed libs in an endorsed folder of the JDK ?
No. Setting the java.endorsed.dirs property is enough. And exactly this
Tomcat is doing in its start scripts.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org