RE: JAXP
The other day, somebody posted a well written document on Java2 class loaders. I wish I had the url to the document, but I can't find it. The gist of the document was this: All class loaders within a jvm form a hierarchy with the boot class loader being at the root. No matter which class loader in this hierarchy is utilized, it's job is to always delegate to it's parent class loader before attempting to load anything on it's own. In this case I belive orion's application class loaders will still be children of orion's class loader, so classes defined at the class path level (using orion.jar's classpath manifest attribute) will be used. Even if you create a lib entry to jaxp in server.xml or orion-application.xml the jxap that ships with orion will be used. Andre -Original Message- From: Conrad Chan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 27, 2001 4:25 PM To: Orion-Interest Subject: RE: JAXP Have you try to package your version of JAXP files inside your application archive (ear, war)? This idea comes from the fact that every class is identified not only its class name but also which class loader it is loaded from. Since Orion supports dynamic loading of application files, it should be using a custom classloader for every application. Hence, by theory, you should be able to use a different JAXP than the one Orion uses. Of course it depends on exactly how Orion implements this. If Orion looks for classes from the default classloader first, it is still not going to work. But I think it does worth a try. Hope this help Conrad -Original Message- From: Richard Doust [mailto:[EMAIL PROTECTED]] Sent: Friday, February 23, 2001 4:31 PM To: Orion-Interest Subject: JAXP I have been working on this problem all day. I have posted once before and no one responded. I will try again. I'm no Java expert and this is just my ignorance, but can anyone tell me if I'm correct in my assumptions on this. I am trying to develop server side code that runs under Orion that uses the JAXP code that Sun has recently released. There are different versions of parser.jar, xalan.jar and jaxp.jar distributed with Orion. Older ones. I have tried replacing the older ones with the newer ones because my code requires the newer ones and I guess that my code will be running in the same image as Orion. Orion fails to start due to an exception while trying to parse its configuration files. Putting the old .jar files back, it works again. So, now it occurs to me that I'm basically stuck running with whatever version of support code the tools I'm using are dependent on. If I'm right, that means I can't use the latest version of JAXP until Orion does? Is that right? Anyone? Thanks, Rich
RE: JAXP
Have you try to package your version of JAXP files inside your application archive (ear, war)? This idea comes from the fact that every class is identified not only its class name but also which class loader it is loaded from. Since Orion supports dynamic loading of application files, it should be using a custom classloader for every application. Hence, by theory, you should be able to use a different JAXP than the one Orion uses. Of course it depends on exactly how Orion implements this. If Orion looks for classes from the default classloader first, it is still not going to work. But I think it does worth a try. Hope this help Conrad -Original Message- From: Richard Doust [mailto:[EMAIL PROTECTED]] Sent: Friday, February 23, 2001 4:31 PM To: Orion-Interest Subject: JAXP I have been working on this problem all day. I have posted once before and no one responded. I will try again. I'm no Java expert and this is just my ignorance, but can anyone tell me if I'm correct in my assumptions on this. I am trying to develop server side code that runs under Orion that uses the JAXP code that Sun has recently released. There are different versions of parser.jar, xalan.jar and jaxp.jar distributed with Orion. Older ones. I have tried replacing the older ones with the newer ones because my code requires the newer ones and I guess that my code will be running in the same image as Orion. Orion fails to start due to an exception while trying to parse its configuration files. Putting the old .jar files back, it works again. So, now it occurs to me that I'm basically stuck running with whatever version of support code the tools I'm using are dependent on. If I'm right, that means I can't use the latest version of JAXP until Orion does? Is that right? Anyone? Thanks, Rich
Re: JAXP
Richard Doust schrieb: have tried replacing the older ones with the newer ones because my code Hi Richard, to me it seems that what You do makes perfect sense and that Orion *must not* impose any restriction on which libraries/versions You are going to use in your EJB code. That Orion uses Xalan etc. internally should be a hidden implementation detail (one may make use of ;-)). Therefore, I guess that your code should work just ok if you package all your additional JAR-files into your ejb-jar file. Just don't replace Orion's own files. You are just not allowed to. If it still does *not* work, file a bug report to bugzilla at orionserver.com. Most application servers I know run a separate class loader for at least each deployed application. If it works it would be nice to see documented an application-local library path so that repacking is not needed every time. Hope I could help. Your problem seems to be of a general nature. Bye, Falk -- Dr. Falk Langhammer Living Pages Research GmbH Holzstr. 19 D-80469 Munich, Germany mailto:[EMAIL PROTECTED] http://www.living-pages.de Phone +49 (89) 260 255 32Fax +49 (89) 260 255 35 Mobil +49 (171) 79 39 667 mailto:[EMAIL PROTECTED] (urgent SMS with subject header)
Re: JAXP
Hi Rich, Could you narrow it down? Specifically which JAR breaks Orion. We have replaced the xalan.jar and xerces.jar files with version 1.2.2 and Orion is happy. Is it just the jaxp.jar file that is the issue? Also, I believe that somewhere in the mailing list archives, you will find posts related to JAXP, but I do not know if they will address your specific question. tim. I have been working on this problem all day. I have posted once before and no one responded. I will try again. I'm no Java expert and this is just my ignorance, but can anyone tell me if I'm correct in my assumptions on this. I am trying to develop server side code that runs under Orion that uses the JAXP code that Sun has recently released. There are different versions of parser.jar, xalan.jar and jaxp.jar distributed with Orion. Older ones. I have tried replacing the older ones with the newer ones because my code requires the newer ones and I guess that my code will be running in the same image as Orion. Orion fails to start due to an exception while trying to parse its configuration files. Putting the old .jar files back, it works again. So, now it occurs to me that I'm basically stuck running with whatever version of support code the tools I'm using are dependent on. If I'm right, that means I can't use the latest version of JAXP until Orion does? Is that right? Anyone? Thanks, Rich
RE: JAXP
Tim, Thanks for trying to help. I'll take a look in the mailing list archives. I looked through the first set and didn't find anything, but I can look at older stuff. In the meantime, I'm replacing the jaxp.jar, parser.jar, and xalan.jar that came with Orion (latest version) with crimson.jar, jaxp.jar and xalan.jar from JAXP 1.1. After a thorough analysis of these jar files, I found that xalan.jar and crimson.jar have most of what jaxp.jar and parser.jar have plus a lot more. One of the problems I have is that ant, jdk1.3, orion, and jaxp1.1 each come with a different version of jaxp.jar. Orion, jdk1.3 and jaxp1.1 each comes with a different version of xalan.jar. Orion and ant come with different versions of parser.jar. (I have all four of these installed.) ant worked okay after replacing its jaxp.jar and parser.jar with jaxp1.1's xalan.jar and crimson.jar. I start Orion with a classpath that includes the crimson.jar and xalan.jar from jaxp 1.1. During the startup, when its trying to parse its config files (I guess) I get a NoSuchMethodError at org.apache.crimson.tree.AttributeSet.init(AttributeSet.java:139). I guess I can't tell from this what method it's trying to call. It would be helpful if I could. Somehow, it sounds internal to JAXP, and not like it's really a problem of Orion. Any more ideas now that I've given all these details? Love to hear from you again! Rich -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres Sent: Friday, February 23, 2001 8:33 PM To: Orion-Interest Subject: Re: JAXP Hi Rich, Could you narrow it down? Specifically which JAR breaks Orion. We have replaced the xalan.jar and xerces.jar files with version 1.2.2 and Orion is happy. Is it just the jaxp.jar file that is the issue? Also, I believe that somewhere in the mailing list archives, you will find posts related to JAXP, but I do not know if they will address your specific question. tim. I have been working on this problem all day. I have posted once before and no one responded. I will try again. I'm no Java expert and this is just my ignorance, but can anyone tell me if I'm correct in my assumptions on this. I am trying to develop server side code that runs under Orion that uses the JAXP code that Sun has recently released. There are different versions of parser.jar, xalan.jar and jaxp.jar distributed with Orion. Older ones. I have tried replacing the older ones with the newer ones because my code requires the newer ones and I guess that my code will be running in the same image as Orion. Orion fails to start due to an exception while trying to parse its configuration files. Putting the old .jar files back, it works again. So, now it occurs to me that I'm basically stuck running with whatever version of support code the tools I'm using are dependent on. If I'm right, that means I can't use the latest version of JAXP until Orion does? Is that right? Anyone? Thanks, Rich
RE: JAXP
Here's some verbose output from java on the attempt to start Orion: [Loaded org.apache.crimson.tree.DomEx] [Loaded org.w3c.dom.DocumentType] [Loaded org.apache.crimson.tree.XmlWriteContext] [Loaded org.apache.crimson.tree.XmlDocument$ExtWriteContext] [Loaded org.w3c.dom.ProcessingInstruction] [Loaded org.apache.crimson.tree.PINode] [Loaded org.w3c.dom.EntityReference] [Loaded org.apache.crimson.tree.XmlDocument$EntityRefNode] [Loaded org.w3c.dom.DocumentFragment] [Loaded org.apache.crimson.tree.XmlDocument$DocFragNode] [Loaded org.w3c.dom.Comment] [Loaded org.apache.crimson.tree.CommentNode] [Loaded org.w3c.dom.CDATASection] [Loaded org.apache.crimson.tree.CDataNode] [Loaded org.w3c.dom.Attr] [Loaded org.apache.crimson.tree.AttributeNode] [Loaded org.apache.crimson.tree.XmlDocument$Catalog] [Loaded org.apache.crimson.tree.DataNode$NodeListImpl] [Loaded org.apache.crimson.util.XmlChars] [Loaded org.w3c.dom.DOMImplementation] [Loaded org.apache.crimson.tree.DOMImplementationImpl] [Loaded org.apache.crimson.tree.Doctype] [Loaded org.w3c.dom.NamedNodeMap] [Loaded org.w3c.dom.Notation] [Loaded org.apache.crimson.tree.Doctype$NotationNode] [Loaded org.w3c.dom.Entity] [Loaded org.apache.crimson.tree.Doctype$EntityNode] [Loaded org.apache.crimson.tree.Doctype$Nodemap] [Loaded org.apache.crimson.tree.AttributeSet] [Loaded java.lang.IncompatibleClassChangeError from C:\Program Files\JavaSoft\JR E\1.3\lib\rt.jar] [Loaded java.lang.NoSuchMethodError from C:\Program Files\JavaSoft\JRE\1.3\lib\r t.jar] java.lang.NoSuchMethodError at org.apache.crimson.tree.AttributeSet.init(AttributeSet.java:139) at org.apache.crimson.tree.XmlDocumentBuilder.startElement(XmlDocumentBu ilder.java:463) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1449) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:499) at org.apache.crimson.parser.Parser2.parse(Parser2.java:304) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:433) at org.apache.crimson.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl .java:179) at com.evermind.xml.e.getJavaxDocument(JAX) at com.evermind.xml.XMLUtils.getDocument(JAX) at com.evermind.xml.XMLConfig.ay(JAX) at com.evermind.xml.XMLConfig.ay(JAX) at com.evermind.server.hg.run(JAX) at java.lang.Thread.run(Unknown Source) at com.evermind.util.f.run(JAX) [Loaded java.lang.Shutdown$Lock from C:\Program Files\JavaSoft\JRE\1.3\lib\rt.ja r] Thanks again, Rich -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres Sent: Friday, February 23, 2001 8:33 PM To: Orion-Interest Subject: Re: JAXP Hi Rich, Could you narrow it down? Specifically which JAR breaks Orion. We have replaced the xalan.jar and xerces.jar files with version 1.2.2 and Orion is happy. Is it just the jaxp.jar file that is the issue? Also, I believe that somewhere in the mailing list archives, you will find posts related to JAXP, but I do not know if they will address your specific question. tim. I have been working on this problem all day. I have posted once before and no one responded. I will try again. I'm no Java expert and this is just my ignorance, but can anyone tell me if I'm correct in my assumptions on this. I am trying to develop server side code that runs under Orion that uses the JAXP code that Sun has recently released. There are different versions of parser.jar, xalan.jar and jaxp.jar distributed with Orion. Older ones. I have tried replacing the older ones with the newer ones because my code requires the newer ones and I guess that my code will be running in the same image as Orion. Orion fails to start due to an exception while trying to parse its configuration files. Putting the old .jar files back, it works again. So, now it occurs to me that I'm basically stuck running with whatever version of support code the tools I'm using are dependent on. If I'm right, that means I can't use the latest version of JAXP until Orion does? Is that right? Anyone? Thanks, Rich
RE: JAXP
[Loaded java.lang.NoSuchMethodError from C:\Program Files\JavaSoft\JRE\1.3\lib\r t.jar] java.lang.NoSuchMethodError at org.apache.crimson.tree.AttributeSet.init(AttributeSet.java:139) Richard, do you have the source code for that line it is croaking on? tim.
