Home.... | log in.... | Pub my question! | Sign-up....
Java-index >> Application & Integration Servers >> Application Servers

Cocoon and Sun Java System Application Server 8.x

Just wondering if anybody has successfully got Cocoon 2.1.x and SJSAS to work.

While I can deploy it, and access most functions, I cannot get XSP transforms to work due to library problems with Cocoon and SJSAS.

It seems that the problem is with xalan/xerces.

Cocoon comes with xercesImpl 2.8 and xalan 2.7, bundled, and Application Server comes with it's own com.sun prefixed versions of these libraries (ie com.sun.org.apache.* instead of org.apache).

What's more, Application Server starts its Java VM with the switches

-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SA XParserFactoryImpl

-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xslt c.trax.TransformerFactoryImpl

which force all apps (Cocoon included) to use the Sun-provided versions of these two jar files.

Trouble is, Cocoon wants to use its version of xerces/xalan, and encounters various null pointer exceptions, if used on SJSAS:

java.lang.NullPointerException

at com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.makeInstance(Parser.java:970)

at com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.startElement(Parser.java:1231)

at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesHandlerImpl.startElement(TemplatesHandlerImpl.java:280)

at org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)

at org.apache.cocoon.components.language.markup.xsp.XSPExpressionFilter.startElement(XSPExpressionFilter.java:145)

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:485)

at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:326)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1563)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:341)

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:828)

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:758)

at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1178)

at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315)

at org.apache.excalibur.xmlizer.DefaultXMLizer.toSAX(DefaultXMLizer.java:128)

at org.apache.cocoon.components.xslt.TraxProcessor.sourceToSAX(TraxProcessor.java:301)

at org.apache.cocoon.components.xslt.TraxProcessor.getTransformerHandlerAndValidity(TraxProcessor.java:239)

at org.apache.cocoon.components.xslt.TraxProcessor.getTransformerHandler(TraxProcessor.java:182)

at org.apache.cocoon.components.language.markup.Logicsheet.getTransformerHandler(Logicsheet.java:164)

at org.apache.cocoon.components.language.markup.Logicsheet.getNamespaceURIs(Logicsheet.java:141)

at org.apache.cocoon.components.language.markup.AbstractMarkupLanguage.addLogicsheetToList(AbstractMarkupLanguage.java:475)

at org.apache.cocoon.components.language.markup.CocoonMarkupLanguage.addLogicsheetToList(CocoonMarkupLanguage.java:122)

at org.apache.cocoon.components.language.markup.CocoonMarkupLanguage$CocoonTransformerChainBuilderFilter.startElement(CocoonMarkupLanguage.java:382)

at org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)

at org.apache.cocoon.components.language.markup.xsp.XSPExpressionFilter.startElement(XSPExpressionFilter.java:145)

at org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94)

at org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94)

at org.apache.cocoon.components.language.markup.CocoonMarkupLanguage$PreProcessFilter.startElement(CocoonMarkupLanguage.java:257)

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:485)

at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:220)

at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:318)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1563)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:341)

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:828)

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:758)

at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1178)

at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315)

at org.apache.excalibur.xmlizer.DefaultXMLizer.toSAX(DefaultXMLizer.java:128)

at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:190)

at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:139)

at org.apache.cocoon.components.language.markup.LogicsheetCodeGenerator.generateCode(LogicsheetCodeGenerator.java:139)

at org.apache.cocoon.components.language.markup.AbstractMarkupLanguage.generateCode(AbstractMarkupLanguage.java:392)

at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateSourcecode(ProgramGeneratorImpl.java:446)

at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:284)

at org.apache.cocoon.generation.ServerPagesGenerator.setup(ServerPagesGenerator.java:170)

at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:384)

at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:720)

at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:500)

at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:452)

at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120)

at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)

at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)

at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)

at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142)

at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)

at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)

at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)

at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)

at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:252)

at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117)

at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)

at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)

at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)

at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142)

at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)

at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)

at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)

at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)

at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:252)

at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117)

at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)

at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)

at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)

at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142)

at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)

at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)

at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)

at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)

at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:252)

at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117)

at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)

at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)

at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)

at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142)

at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)

at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)

at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)

at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)

at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:252)

at org.apache.cocoon.Cocoon.process(Cocoon.java:686)

at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1153)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)

at java.security.AccessController.doPrivileged(Native Method)

at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)

at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)

at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)

at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)

at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)

at java.security.AccessController.doPrivileged(Native Method)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)

at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)

at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:189)

at com.sun.enterprise.web.connector.grizzly.ProcessorTask.doProcess(ProcessorTask.java:604)

at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:475)

at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:371)

at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:264)

at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:281)

at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:83)

I don't think SJSAS should be required to change the -D flags, as obviously Sun requires that itself internally for the Application Server. However, I can't see how Cocoon can work without using its own xerces/xalan libraries, as it seems unnaturally tied to these.

Any suggestions would be appreciated if anybody's been able to get this duo working.

[14406 byte] By [tourtech] at [2007-11-26 8:58:36]
«« Webserver SP6 - 116648-18?
»» Service with master process that itself has capability of restarting childs
# 1
This indeed is a trouble.Can you please deploy cocoon with a sun-web.xml that has "delegate=false"and retry?Hope it helps. http://docs.sun.com/app/docs/doc/819-2642/6n4tspp6k?a=view#beagbKedar
kedarmhaswade at 2007-7-6 23:00:37 > top of Java-index,Application & Integration Servers,Application Servers...
# 2

Kedar,

I've actually already set "delegate=false" in the sun-web file; it doesn't help.

The trouble isn't with the classloader, its the fact that the JVM must use Xerces and Xalan com.sun.org.apache.* classes because of the -D options on the jvm.

ie: the org.apache.* classes aren't being used because of the -D directives explicitly tell apps wanting a SAXParser or TransformerFactory to use the Sun-provided classes.

As the Sun classes are older, I suspect that the null pointers are occuring because the objects are slightly different.

tourtech at 2007-7-6 23:00:37 > top of Java-index,Application & Integration Servers,Application Servers...
# 3

This is a *big* problem as I realize it.

Can you please file it as such, at bugs.sun.com? I'll really appreciate it. Using VM wide -D's is always troublesome.

One hack that you could do is:

- copy the classes to some folder as:

com

sun

org

apache...

- jar them up as say overrides.jar and copy it to lib folder.

- modify relevant server's classpath-prefix to have this jar in it which will

make your jar override other classes.

Like I said, this is only a hack. We might have a better solution in App server 9.x.

Please file the bug.

Regards,

Kedar

kedarmhaswade at 2007-7-6 23:00:37 > top of Java-index,Application & Integration Servers,Application Servers...
# 4

G'day Kedar

Agreed - the -D JVM options are bad voodoo, and appear to have gone in version 9.0. We're rolling out 8.1EE, so I'm trying to get Cocoon deployed on it, not version 9, for now.

I'm not sure how the workaround you provide will help as the -D options will still be on the JVM, and will still force Cocoon to use the com.sun implementation, even though the org.apache classes are included.

tourtech at 2007-7-6 23:00:37 > top of Java-index,Application & Integration Servers,Application Servers...
# 5

> G'day Kedar

>

> Agreed - the -D JVM options are bad voodoo, and

> appear to have gone in version 9.0. We're rolling out

> 8.1EE, so I'm trying to get Cocoon deployed on it,

> not version 9, for now.

OK. Understood. I will still request you to file a bug, please.

>

> I'm not sure how the workaround you provide will help

> as the -D options will still be on the JVM, and will

> still force Cocoon to use the com.sun implementation,

> even though the org.apache classes are included.

No. Maybe I misspoke. Here is why I think this hack might work:

- Since your classes (latest) are going to be "renamed" to

com.sun.org.apache. foo.Bar from "org.apache.foo.Bar", and

- classpath-prefix will have your classes loaded *before* app server

classes

even though the evil -D is taking reign of the VM, your classes will be loaded.

And finally, this is a hack. But I think there is a nonzero possibility that this

will work :)

Kedar

kedarmhaswade at 2007-7-6 23:00:37 > top of Java-index,Application & Integration Servers,Application Servers...
# 6

Okies - I now understand what you were getting at.

It does sound like a plausible fix (hack ;)

Even nicer if Sun did it for me ;)

I have created a bug ticket. Internal review ID 759653

I've also realized that the reason that SJSAS 8 includes xalan.jar and xerces Imple.jar is because it is meant to work on JDK1.4 which doesn't provide xerces.

However since JDK1.5 (which I'm using with SJSAS) includes xerces, maybe Sun will (or already have in a more recent release) included newer com.sun.org.apache xerces/xalan variants to what Appserver8 has. If that is the case, or when it happens, maybe I can just remove the xercesImpl.jar and xalan.jar libs from Appserver's lib directory.

tourtech at 2007-7-6 23:00:37 > top of Java-index,Application & Integration Servers,Application Servers...
# 7

Not sure I understand.

Yes, app server has a requirement to run with JDK 1.4. App server also

depends on certain classes.

That does not mean applications can't use different versions of the classes that

are loaded by app server.

With more and more stuff going into the Java platform, if there is no way to

override users would be vastly inconvenienced (like yourself).

This is why we have provided --libraries option in deploying an app, for AS 9.0.

Sorry, I understand your plight.

I will definitely make sure your ticket is paid attention to.

Can you let me know if hack worked?

Kedar

kedarmhaswade at 2007-7-6 23:00:37 > top of Java-index,Application & Integration Servers,Application Servers...
# 8

No worries.

All I meant was that since JDK1.5 provides com.sun.org.apache xerces and xalan classes as part of rt.jar, maybe if Appserver 8 is run with JDK1.5, then it's copy of xercesImpl.jar and xalan.jar could be deleted iff the JDK's version of these same libraries was upgraded to match the later (standard) ones provided by Apache.

Of course, this is not the case if Appserver was used with JDK1.4, so maybe that's why it provides these libraries in it's lib directory (so ppl can still use JDK1.4).

(And when I said "Even nicer if Sun did it for me ;)", all I meant was it would be nice if Appserver 8.2's xercesImpl.jar and xalan.jar libs were upgraded to be up to date with the current Apache versions)

Thanks heaps for all of your help!

Onward I progress in the plight to migrate from JBoss to SJSAS!

cheers

tourtech at 2007-7-6 23:00:37 > top of Java-index,Application & Integration Servers,Application Servers...
# 9

> All I meant was that since JDK1.5 provides

> com.sun.org.apache xerces and xalan classes as part

> of rt.jar, maybe if Appserver 8 is run with JDK1.5,

> then it's copy of xercesImpl.jar and xalan.jar could

> be deleted iff the JDK's version of these same

> libraries was upgraded to match the later (standard)

> ones provided by Apache.

That's correct and that is how AS9 [that runs on Java SE 5] works. Xerces and xalan are no more bundled and nor is the "-D" invocation added, so we fall back to the platform-default by default.

>

> Of course, this is not the case if Appserver was used

> with JDK1.4, so maybe that's why it provides these

> libraries in it's lib directory (so ppl can still use

> JDK1.4).

>

Exactly.

Thanks

--Siva.

sivakumart at 2007-7-6 23:00:37 > top of Java-index,Application & Integration Servers,Application Servers...
# 10
We seem to be running with similar issue deploying our app on sun server 8.2 Can somebody confirm that this is still a valid unresolved issue with Sun Server 8.2 thanksKishore
kishoremk at 2007-7-6 23:00:37 > top of Java-index,Application & Integration Servers,Application Servers...
Application & Integration Servers
Application Servers

Application & Integration Servers New Topic

Application & Integration Servers Hot Topic

Application & Integration Servers

All Classified