Re: Fixing java.endorsed.dirs
You can only replace the bootstrap classes with the endorsed mechanism or by changing the bootstrap class path. I don't think that there is anything else available. Heinz On 10/4/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: On Oct 4, 2006, at 1:53 AM, Rick McGuire wrote: > Alan D. Cabrera wrote: >>> On Sep 28, 2006, at 12:25 PM, Dain Sundstrom wrote: >>> >>> Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? >> >> >> OT: in the future, if we used OSGi as a base, we would have a >> clean workaround for this problem, no? > I'm not sure how OSGi would help with this. The functioning of > java.endorsed.dirs is a base function of how the JVM works. > There's not much other option to get around this. IIUC, you can eclipse JVM classes with your own. Do I have it wrong? Regards, Alan
Re: Fixing java.endorsed.dirs
Alan D. Cabrera wrote: On Oct 4, 2006, at 1:53 AM, Rick McGuire wrote: Alan D. Cabrera wrote: On Sep 28, 2006, at 12:25 PM, Dain Sundstrom wrote: Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? OT: in the future, if we used OSGi as a base, we would have a clean workaround for this problem, no? I'm not sure how OSGi would help with this. The functioning of java.endorsed.dirs is a base function of how the JVM works. There's not much other option to get around this. IIUC, you can eclipse JVM classes with your own. Do I have it wrong? Yes, but there are certain fundamental classes where this become problematic because other portions of the JVM also contain references to these classes. This is why java.endorsed.dirs got created in the first place. Regards, Alan
Re: Fixing java.endorsed.dirs
I think this would only work if the JVM was based on OSGI... --jason On Oct 4, 2006, at 12:39 PM, Alan D. Cabrera wrote: On Oct 4, 2006, at 1:53 AM, Rick McGuire wrote: Alan D. Cabrera wrote: On Sep 28, 2006, at 12:25 PM, Dain Sundstrom wrote: Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? OT: in the future, if we used OSGi as a base, we would have a clean workaround for this problem, no? I'm not sure how OSGi would help with this. The functioning of java.endorsed.dirs is a base function of how the JVM works. There's not much other option to get around this. IIUC, you can eclipse JVM classes with your own. Do I have it wrong? Regards, Alan
Re: Fixing java.endorsed.dirs
On Oct 4, 2006, at 1:53 AM, Rick McGuire wrote: Alan D. Cabrera wrote: On Sep 28, 2006, at 12:25 PM, Dain Sundstrom wrote: Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? OT: in the future, if we used OSGi as a base, we would have a clean workaround for this problem, no? I'm not sure how OSGi would help with this. The functioning of java.endorsed.dirs is a base function of how the JVM works. There's not much other option to get around this. IIUC, you can eclipse JVM classes with your own. Do I have it wrong? Regards, Alan
Re: Fixing java.endorsed.dirs
Alan D. Cabrera wrote: On Sep 28, 2006, at 12:25 PM, Dain Sundstrom wrote: Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? OT: in the future, if we used OSGi as a base, we would have a clean workaround for this problem, no? I'm not sure how OSGi would help with this. The functioning of java.endorsed.dirs is a base function of how the JVM works. There's not much other option to get around this. Regards, Alan
Re: Fixing java.endorsed.dirs
On Sep 28, 2006, at 12:25 PM, Dain Sundstrom wrote: Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? OT: in the future, if we used OSGi as a base, we would have a clean workaround for this problem, no? Regards, Alan
Re: Fixing java.endorsed.dirs
Aaron Mulder wrote: On 10/2/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > When it comes to futzing w/ the endorsed dirs I would rather have > it in the up front and in my face via a script than have some cute > code forking and setting things behind the scenes. I couldn't agree more. I dislike Java forking Java more than I dislike using shell scripts to start Java. My biggest potential problem with forking is that the way I usually set up a server process is to launch it into the background and record the process ID to a file. If the original process immediately launches a new process and quits, then I may not know what the actual server process ID is and I may not be able to effectively kill it later. It's less problematic since you can shut down with the console or shutdown JAR, but still annoying. Forking also poses some interesting issues, such as making sure the same set of JVM options (e.g., memory options) get used for the forked JVMor making sure the new JVM gets launched in a cross vendor/release fashion. Rick Thanks, Aaron
Re: Fixing java.endorsed.dirs
On 10/2/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > When it comes to futzing w/ the endorsed dirs I would rather have > it in the up front and in my face via a script than have some cute > code forking and setting things behind the scenes. I couldn't agree more. I dislike Java forking Java more than I dislike using shell scripts to start Java. My biggest potential problem with forking is that the way I usually set up a server process is to launch it into the background and record the process ID to a file. If the original process immediately launches a new process and quits, then I may not know what the actual server process ID is and I may not be able to effectively kill it later. It's less problematic since you can shut down with the console or shutdown JAR, but still annoying. Thanks, Aaron
Re: Fixing java.endorsed.dirs
On Oct 2, 2006, at 7:10 AM, Alan D. Cabrera wrote: On Sep 28, 2006, at 12:25 PM, Dain Sundstrom wrote: Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? When it comes to futzing w/ the endorsed dirs I would rather have it in the up front and in my face via a script than have some cute code forking and setting things behind the scenes. I couldn't agree more. I dislike Java forking Java more than I dislike using shell scripts to start Java. We can add some startup code that looks for the "bad" versions of classes and throw an exception w/ a useful message stating that the endorsed dirs list was probably not setup correctly. I'd prefer we keep such a check to the Corba startup code. In the normally our users will not be starting the corba module so there is no need to force everyone to use the shell scripts. -dain
Re: Fixing java.endorsed.dirs
On Sep 28, 2006, at 12:25 PM, Dain Sundstrom wrote: Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? When it comes to futzing w/ the endorsed dirs I would rather have it in the up front and in my face via a script than have some cute code forking and setting things behind the scenes. We can add some startup code that looks for the "bad" versions of classes and throw an exception w/ a useful message stating that the endorsed dirs list was probably not setup correctly. Let's keep it simple. Regards, Alan
Re: Fixing java.endorsed.dirs
I have opened GERONIMO-2454. The attached patch modifies the pom.xml of several components. I have consolidated to use xml-apis instead of xmlParserAPIs. It was inconsistent between modules. Heinz On 9/30/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: On 9/29/06, Heinz Drews <[EMAIL PROTECTED]> wrote: > I think that upgrading xerces and xml-apis might be more important. > G uses still xerces 2.6.2 which has a file date of feb 2004 in the > historical part of the download area. > > 2.8.1 is the most recent. should I open a jira? Yes, go for it. A patch would be welcome. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Fixing java.endorsed.dirs
On 9/29/06, Heinz Drews <[EMAIL PROTECTED]> wrote: I think that upgrading xerces and xml-apis might be more important. G uses still xerces 2.6.2 which has a file date of feb 2004 in the historical part of the download area. 2.8.1 is the most recent. should I open a jira? Yes, go for it. A patch would be welcome. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Fixing java.endorsed.dirs
Matt Hogstrom wrote: I'm not sure it went away. IIRC this was a few months ago. I'll have to go back to the dark recess of my mind but the experimentation was more around did the VM fall over if we removed the files from endorsed and it did not. Its possible that the reason is it never worked from the beginning. That certainly makes sense. That's exactly what happened when I removed the Xerces jars while trying to figure out why the yoko specs jar classes couldn't be resolved. I was expecting the server to die an ugly death on startup and was shocked when it came up cleanly. I've spent a lot of time googling on java.endorsed.dirs this morning, and I find an LOT of references for different projects (including Tomcat and JBoss) that have a requirement that the java.endorsed.dirs property be set on launch. I found one discussion thread about solutions to get around the problem, and it appears forking a new process is the only alternative. In this application's case, it had to unpack a jar file to create the endorsed directory, then launch a new process to run the main app. Pretty ugly, but doable. The launcher script seems like a good short-term solution. Rick On Sep 28, 2006, at 5:29 PM, Dain Sundstrom wrote: Sorry, but I don't remember. Matt presented the problem to me, I suggested removing the jars from the endorsed dir, and the problem went away. If you are really interested, I'll volunteer Matt to find out the exact class :) -dain On Sep 28, 2006, at 2:13 PM, Heinz Drews wrote: Dain, which class or interface has triggered the problem? Only org.w3c.dom org.xml.sax org.xml.sax.ext org.xml.sax.helpers are part of the endorsed library mechanism. Subpackages of org.w3c.dom are optional. Other classes are part of regular class loading. On 9/28/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: On Sep 28, 2006, at 12:02 PM, Rick McGuire wrote: > Dain Sundstrom wrote: >> On Sep 28, 2006, at 11:19 AM, Heinz Drews wrote: >> >>> There was sometime ago a discussion thread about the requirement to >>> have the jars in endorsed dirs also on the classpath. >>> >>> If endorsed would have been picked up then this would not be >>> necessary. >>> >>> It is still possible to get xerces as the parser because of >>> including >>> it on the classpath. >>> It would not be the default using the factories. >> >> Yep. In Geronimo, we use the default factories. Additionally, >> the J2EE spec requires that the default factories return a newer >> parser version then is included in a 1.4 vm, so you should have a >> fairly high confidence there are tests to for it in the TCK. > > The problem here is not the resolving of the class factory, but > rather the resolution of the org.w3c.dom classes. Those are the > ones that are a potential trouble spot. If the JVM native versions > are not compatible with the Xerces ones, this can manifest as a > NoMethodFoundException. But only if you happen to hit code that > attempts to call one of the missing classes. This is something of > a ticking time bomb. > I had a similar situation with Yoko. I had no problems loading the > Yoko ORB classes. The yoko-core jar file doesn't even need to be > in the endorsed dir to work. However, there was a issue with one > of the org.omg classes. The Sun version wasn't compatible with the > CORBA spec, so if you tried to run the Yoko code using the native > org.omg classes, you got a NoMethodFoundException. Once I > successfully got the JVM to process this jar as part of the > endorsed dirs, I was able to override the native classes and the > Yoko ORB started working. This is weird. I tried to write some demo code to show that you can override after the vm started and failed :( What is particular strange is we had a customer problem exactly as you describe above except backwards. The customer was using java5 and when they loaded a dom they were getting an old version of the dom apis included with Geronimo. We fixed this problem by deleting the xerces jars from the endorsed dir. Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? -dain Matt Hogstrom [EMAIL PROTECTED]
Re: Fixing java.endorsed.dirs
I'm not sure it went away. IIRC this was a few months ago. I'll have to go back to the dark recess of my mind but the experimentation was more around did the VM fall over if we removed the files from endorsed and it did not. Its possible that the reason is it never worked from the beginning. On Sep 28, 2006, at 5:29 PM, Dain Sundstrom wrote: Sorry, but I don't remember. Matt presented the problem to me, I suggested removing the jars from the endorsed dir, and the problem went away. If you are really interested, I'll volunteer Matt to find out the exact class :) -dain On Sep 28, 2006, at 2:13 PM, Heinz Drews wrote: Dain, which class or interface has triggered the problem? Only org.w3c.dom org.xml.sax org.xml.sax.ext org.xml.sax.helpers are part of the endorsed library mechanism. Subpackages of org.w3c.dom are optional. Other classes are part of regular class loading. On 9/28/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: On Sep 28, 2006, at 12:02 PM, Rick McGuire wrote: > Dain Sundstrom wrote: >> On Sep 28, 2006, at 11:19 AM, Heinz Drews wrote: >> >>> There was sometime ago a discussion thread about the requirement to >>> have the jars in endorsed dirs also on the classpath. >>> >>> If endorsed would have been picked up then this would not be >>> necessary. >>> >>> It is still possible to get xerces as the parser because of >>> including >>> it on the classpath. >>> It would not be the default using the factories. >> >> Yep. In Geronimo, we use the default factories. Additionally, >> the J2EE spec requires that the default factories return a newer >> parser version then is included in a 1.4 vm, so you should have a >> fairly high confidence there are tests to for it in the TCK. > > The problem here is not the resolving of the class factory, but > rather the resolution of the org.w3c.dom classes. Those are the > ones that are a potential trouble spot. If the JVM native versions > are not compatible with the Xerces ones, this can manifest as a > NoMethodFoundException. But only if you happen to hit code that > attempts to call one of the missing classes. This is something of > a ticking time bomb. > I had a similar situation with Yoko. I had no problems loading the > Yoko ORB classes. The yoko-core jar file doesn't even need to be > in the endorsed dir to work. However, there was a issue with one > of the org.omg classes. The Sun version wasn't compatible with the > CORBA spec, so if you tried to run the Yoko code using the native > org.omg classes, you got a NoMethodFoundException. Once I > successfully got the JVM to process this jar as part of the > endorsed dirs, I was able to override the native classes and the > Yoko ORB started working. This is weird. I tried to write some demo code to show that you can override after the vm started and failed :( What is particular strange is we had a customer problem exactly as you describe above except backwards. The customer was using java5 and when they loaded a dom they were getting an old version of the dom apis included with Geronimo. We fixed this problem by deleting the xerces jars from the endorsed dir. Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? -dain Matt Hogstrom [EMAIL PROTECTED]
Re: Fixing java.endorsed.dirs
It would be more to cure curiosity :-) I think that upgrading xerces and xml-apis might be more important. G uses still xerces 2.6.2 which has a file date of feb 2004 in the historical part of the download area. 2.8.1 is the most recent. should I open a jira? On 9/28/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Sorry, but I don't remember. Matt presented the problem to me, I suggested removing the jars from the endorsed dir, and the problem went away. If you are really interested, I'll volunteer Matt to find out the exact class :) -dain On Sep 28, 2006, at 2:13 PM, Heinz Drews wrote: > Dain, > which class or interface has triggered the problem? > Only > org.w3c.dom > org.xml.sax > org.xml.sax.ext > org.xml.sax.helpers > are part of the endorsed library mechanism. > Subpackages of org.w3c.dom are optional. > > Other classes are part of regular class loading. > > > On 9/28/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: >> On Sep 28, 2006, at 12:02 PM, Rick McGuire wrote: >> >> > Dain Sundstrom wrote: >> >> On Sep 28, 2006, at 11:19 AM, Heinz Drews wrote: >> >> >> >>> There was sometime ago a discussion thread about the >> requirement to >> >>> have the jars in endorsed dirs also on the classpath. >> >>> >> >>> If endorsed would have been picked up then this would not be >> >>> necessary. >> >>> >> >>> It is still possible to get xerces as the parser because of >> >>> including >> >>> it on the classpath. >> >>> It would not be the default using the factories. >> >> >> >> Yep. In Geronimo, we use the default factories. Additionally, >> >> the J2EE spec requires that the default factories return a newer >> >> parser version then is included in a 1.4 vm, so you should have a >> >> fairly high confidence there are tests to for it in the TCK. >> > >> > The problem here is not the resolving of the class factory, but >> > rather the resolution of the org.w3c.dom classes. Those are the >> > ones that are a potential trouble spot. If the JVM native versions >> > are not compatible with the Xerces ones, this can manifest as a >> > NoMethodFoundException. But only if you happen to hit code that >> > attempts to call one of the missing classes. This is something of >> > a ticking time bomb. >> > I had a similar situation with Yoko. I had no problems loading the >> > Yoko ORB classes. The yoko-core jar file doesn't even need to be >> > in the endorsed dir to work. However, there was a issue with one >> > of the org.omg classes. The Sun version wasn't compatible with the >> > CORBA spec, so if you tried to run the Yoko code using the native >> > org.omg classes, you got a NoMethodFoundException. Once I >> > successfully got the JVM to process this jar as part of the >> > endorsed dirs, I was able to override the native classes and the >> > Yoko ORB started working. >> >> This is weird. I tried to write some demo code to show that you can >> override after the vm started and failed :( What is particular >> strange is we had a customer problem exactly as you describe above >> except backwards. The customer was using java5 and when they loaded >> a dom they were getting an old version of the dom apis included with >> Geronimo. We fixed this problem by deleting the xerces jars from the >> endorsed dir. >> >> Anyway, this sucks, since it requires users to use a shell script to >> launch Geronimo. Is there anyway to detect the corba api version and >> not load the Yoko classes that have the problems? >> >> -dain >>
Re: Fixing java.endorsed.dirs
Sorry, but I don't remember. Matt presented the problem to me, I suggested removing the jars from the endorsed dir, and the problem went away. If you are really interested, I'll volunteer Matt to find out the exact class :) -dain On Sep 28, 2006, at 2:13 PM, Heinz Drews wrote: Dain, which class or interface has triggered the problem? Only org.w3c.dom org.xml.sax org.xml.sax.ext org.xml.sax.helpers are part of the endorsed library mechanism. Subpackages of org.w3c.dom are optional. Other classes are part of regular class loading. On 9/28/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: On Sep 28, 2006, at 12:02 PM, Rick McGuire wrote: > Dain Sundstrom wrote: >> On Sep 28, 2006, at 11:19 AM, Heinz Drews wrote: >> >>> There was sometime ago a discussion thread about the requirement to >>> have the jars in endorsed dirs also on the classpath. >>> >>> If endorsed would have been picked up then this would not be >>> necessary. >>> >>> It is still possible to get xerces as the parser because of >>> including >>> it on the classpath. >>> It would not be the default using the factories. >> >> Yep. In Geronimo, we use the default factories. Additionally, >> the J2EE spec requires that the default factories return a newer >> parser version then is included in a 1.4 vm, so you should have a >> fairly high confidence there are tests to for it in the TCK. > > The problem here is not the resolving of the class factory, but > rather the resolution of the org.w3c.dom classes. Those are the > ones that are a potential trouble spot. If the JVM native versions > are not compatible with the Xerces ones, this can manifest as a > NoMethodFoundException. But only if you happen to hit code that > attempts to call one of the missing classes. This is something of > a ticking time bomb. > I had a similar situation with Yoko. I had no problems loading the > Yoko ORB classes. The yoko-core jar file doesn't even need to be > in the endorsed dir to work. However, there was a issue with one > of the org.omg classes. The Sun version wasn't compatible with the > CORBA spec, so if you tried to run the Yoko code using the native > org.omg classes, you got a NoMethodFoundException. Once I > successfully got the JVM to process this jar as part of the > endorsed dirs, I was able to override the native classes and the > Yoko ORB started working. This is weird. I tried to write some demo code to show that you can override after the vm started and failed :( What is particular strange is we had a customer problem exactly as you describe above except backwards. The customer was using java5 and when they loaded a dom they were getting an old version of the dom apis included with Geronimo. We fixed this problem by deleting the xerces jars from the endorsed dir. Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? -dain
Re: Fixing java.endorsed.dirs
Dain, which class or interface has triggered the problem? Only org.w3c.dom org.xml.sax org.xml.sax.ext org.xml.sax.helpers are part of the endorsed library mechanism. Subpackages of org.w3c.dom are optional. Other classes are part of regular class loading. On 9/28/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: On Sep 28, 2006, at 12:02 PM, Rick McGuire wrote: > Dain Sundstrom wrote: >> On Sep 28, 2006, at 11:19 AM, Heinz Drews wrote: >> >>> There was sometime ago a discussion thread about the requirement to >>> have the jars in endorsed dirs also on the classpath. >>> >>> If endorsed would have been picked up then this would not be >>> necessary. >>> >>> It is still possible to get xerces as the parser because of >>> including >>> it on the classpath. >>> It would not be the default using the factories. >> >> Yep. In Geronimo, we use the default factories. Additionally, >> the J2EE spec requires that the default factories return a newer >> parser version then is included in a 1.4 vm, so you should have a >> fairly high confidence there are tests to for it in the TCK. > > The problem here is not the resolving of the class factory, but > rather the resolution of the org.w3c.dom classes. Those are the > ones that are a potential trouble spot. If the JVM native versions > are not compatible with the Xerces ones, this can manifest as a > NoMethodFoundException. But only if you happen to hit code that > attempts to call one of the missing classes. This is something of > a ticking time bomb. > I had a similar situation with Yoko. I had no problems loading the > Yoko ORB classes. The yoko-core jar file doesn't even need to be > in the endorsed dir to work. However, there was a issue with one > of the org.omg classes. The Sun version wasn't compatible with the > CORBA spec, so if you tried to run the Yoko code using the native > org.omg classes, you got a NoMethodFoundException. Once I > successfully got the JVM to process this jar as part of the > endorsed dirs, I was able to override the native classes and the > Yoko ORB started working. This is weird. I tried to write some demo code to show that you can override after the vm started and failed :( What is particular strange is we had a customer problem exactly as you describe above except backwards. The customer was using java5 and when they loaded a dom they were getting an old version of the dom apis included with Geronimo. We fixed this problem by deleting the xerces jars from the endorsed dir. Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? -dain
Re: Fixing java.endorsed.dirs
Dain Sundstrom wrote: On Sep 28, 2006, at 12:02 PM, Rick McGuire wrote: Dain Sundstrom wrote: On Sep 28, 2006, at 11:19 AM, Heinz Drews wrote: There was sometime ago a discussion thread about the requirement to have the jars in endorsed dirs also on the classpath. If endorsed would have been picked up then this would not be necessary. It is still possible to get xerces as the parser because of including it on the classpath. It would not be the default using the factories. Yep. In Geronimo, we use the default factories. Additionally, the J2EE spec requires that the default factories return a newer parser version then is included in a 1.4 vm, so you should have a fairly high confidence there are tests to for it in the TCK. The problem here is not the resolving of the class factory, but rather the resolution of the org.w3c.dom classes. Those are the ones that are a potential trouble spot. If the JVM native versions are not compatible with the Xerces ones, this can manifest as a NoMethodFoundException. But only if you happen to hit code that attempts to call one of the missing classes. This is something of a ticking time bomb. I had a similar situation with Yoko. I had no problems loading the Yoko ORB classes. The yoko-core jar file doesn't even need to be in the endorsed dir to work. However, there was a issue with one of the org.omg classes. The Sun version wasn't compatible with the CORBA spec, so if you tried to run the Yoko code using the native org.omg classes, you got a NoMethodFoundException. Once I successfully got the JVM to process this jar as part of the endorsed dirs, I was able to override the native classes and the Yoko ORB started working. This is weird. I tried to write some demo code to show that you can override after the vm started and failed :( What is particular strange is we had a customer problem exactly as you describe above except backwards. The customer was using java5 and when they loaded a dom they were getting an old version of the dom apis included with Geronimo. We fixed this problem by deleting the xerces jars from the endorsed dir. As did I. It took me a long time to figure out what was wrong because I was assuming that the Geronimo code I was looking at "had to be working". Once I wrote some simpler test cases, I discovered it wasn't, and experiments I ran inside of Geronimo confirmed this. And based on my understanding of class loading (which is pretty good, considering I used to be responsible for the class loading code in the IBM JVM), I was surprised to see that technique being used. java.endorsed.dirs was a feature that came in after I no longer worked on the JVM, but bootclasspath processing has always been "locked down" very early in JVM startup. Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? The problem is not in loading Yoko classes, but in getting the Yoko classes to load in the first place. The presence of the org.omg classes on the bootclasspath are the source of the problem. java.endorsed.dirs is the established way to push the JVM native versions to one side and replace them with a newer version. Rick -dain
Re: Fixing java.endorsed.dirs
On Sep 28, 2006, at 12:02 PM, Rick McGuire wrote: Dain Sundstrom wrote: On Sep 28, 2006, at 11:19 AM, Heinz Drews wrote: There was sometime ago a discussion thread about the requirement to have the jars in endorsed dirs also on the classpath. If endorsed would have been picked up then this would not be necessary. It is still possible to get xerces as the parser because of including it on the classpath. It would not be the default using the factories. Yep. In Geronimo, we use the default factories. Additionally, the J2EE spec requires that the default factories return a newer parser version then is included in a 1.4 vm, so you should have a fairly high confidence there are tests to for it in the TCK. The problem here is not the resolving of the class factory, but rather the resolution of the org.w3c.dom classes. Those are the ones that are a potential trouble spot. If the JVM native versions are not compatible with the Xerces ones, this can manifest as a NoMethodFoundException. But only if you happen to hit code that attempts to call one of the missing classes. This is something of a ticking time bomb. I had a similar situation with Yoko. I had no problems loading the Yoko ORB classes. The yoko-core jar file doesn't even need to be in the endorsed dir to work. However, there was a issue with one of the org.omg classes. The Sun version wasn't compatible with the CORBA spec, so if you tried to run the Yoko code using the native org.omg classes, you got a NoMethodFoundException. Once I successfully got the JVM to process this jar as part of the endorsed dirs, I was able to override the native classes and the Yoko ORB started working. This is weird. I tried to write some demo code to show that you can override after the vm started and failed :( What is particular strange is we had a customer problem exactly as you describe above except backwards. The customer was using java5 and when they loaded a dom they were getting an old version of the dom apis included with Geronimo. We fixed this problem by deleting the xerces jars from the endorsed dir. Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? -dain
Re: Fixing java.endorsed.dirs
Dain Sundstrom wrote: On Sep 28, 2006, at 11:19 AM, Heinz Drews wrote: There was sometime ago a discussion thread about the requirement to have the jars in endorsed dirs also on the classpath. If endorsed would have been picked up then this would not be necessary. It is still possible to get xerces as the parser because of including it on the classpath. It would not be the default using the factories. Yep. In Geronimo, we use the default factories. Additionally, the J2EE spec requires that the default factories return a newer parser version then is included in a 1.4 vm, so you should have a fairly high confidence there are tests to for it in the TCK. The problem here is not the resolving of the class factory, but rather the resolution of the org.w3c.dom classes. Those are the ones that are a potential trouble spot. If the JVM native versions are not compatible with the Xerces ones, this can manifest as a NoMethodFoundException. But only if you happen to hit code that attempts to call one of the missing classes. This is something of a ticking time bomb. I had a similar situation with Yoko. I had no problems loading the Yoko ORB classes. The yoko-core jar file doesn't even need to be in the endorsed dir to work. However, there was a issue with one of the org.omg classes. The Sun version wasn't compatible with the CORBA spec, so if you tried to run the Yoko code using the native org.omg classes, you got a NoMethodFoundException. Once I successfully got the JVM to process this jar as part of the endorsed dirs, I was able to override the native classes and the Yoko ORB started working. -dain
Re: Fixing java.endorsed.dirs
On Sep 28, 2006, at 11:19 AM, Heinz Drews wrote: There was sometime ago a discussion thread about the requirement to have the jars in endorsed dirs also on the classpath. If endorsed would have been picked up then this would not be necessary. It is still possible to get xerces as the parser because of including it on the classpath. It would not be the default using the factories. Yep. In Geronimo, we use the default factories. Additionally, the J2EE spec requires that the default factories return a newer parser version then is included in a 1.4 vm, so you should have a fairly high confidence there are tests to for it in the TCK. -dain
Re: Fixing java.endorsed.dirs
There was sometime ago a discussion thread about the requirement to have the jars in endorsed dirs also on the classpath. If endorsed would have been picked up then this would not be necessary. It is still possible to get xerces as the parser because of including it on the classpath. It would not be the default using the factories. On 9/28/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Are you absolutely sure? How did you verify this? I am skeptical since we use this switch the xml parser to xerces and this is required to pass the tck. -dain On Sep 28, 2006, at 3:18 AM, Rick McGuire wrote: > As I discovered yesterday, the Geronimo use of java.endorsed.dirs > is completely broken. There's code in > org.apache.geronimo.system.main.Daemon that appends information > from the Geronimo manifest file to the system properties > java.endorsed.dirs and java.ext.dirs, with the expectation that > those directories will get used for class resolution. Well, > unfortunately, those two properties are only used by the JVM during > JVM initialization to set up the initial class loading structure. > Once the code in Daemon is reached, it's too late. > It's fairly simple to modify geronimo.bat and geronimo.sh to set > these properties to hard coded values. For example, this seems an > appropriate value for java.endorsed.dirs > >-Djava.endorsed.dirs="$JRE_HOME/lib/endorsed:$GERONIMO_BASE%/lib/ > endorsed" \ > > using the jre's endorsed directory and adding on the Geronimo > endorsed directory. A similar thing can be done for java.ext.dirs, > although the Geronimo assemblies don't even create the directory > reference in the manifest. These are just hard-coded values. It's > fairly difficult to process the manifest file from a batch file, > but since these directories are hard coded into the build, I > suspect it's ok to hard code them into the launcher scripts. > > I should be possible to accomplish what Daemon is doing by forking > a new process to run the actual server, but I'm not sure that's > really a good idea. > So, that's the basics. Right now, I'm working on fixing up the > scripts and removing the non-function property setting from > Daemon. Does this seem like the correct approach? > > Rick
Re: Fixing java.endorsed.dirs
I think I have written something confusing. The intention of my remark was that somebody might have thought that the new xml spec have been used but that this was not the case. Effectively what you have written in your message. On 9/28/06, Rick McGuire <[EMAIL PROTECTED]> wrote: Heinz Drews wrote: > The endorsed dirs are prepended to the bootclass path. > Correcting the current situation should not cause classloading > problems. It might cause a problem because now the newer of the xml > specs are used instead of the one contained in the JRE. Geronimo was already placing jars in the endorsed dir with the intention that they be picked up that way. It was a bug that it wasn't. > > If we use a mechanism like the one used by Eclipse the spawning of a > new JVM should not be too complicated. Therefore this should be > still considered as an option. > > Heinz > > On 9/28/06, Paul McMahan <[EMAIL PROTECTED]> wrote: >> On 9/28/06, Rick McGuire <[EMAIL PROTECTED]> wrote: >> > I should be possible to accomplish what Daemon is doing by forking >> a new >> > process to run the actual server, but I'm not sure that's really a >> good >> > idea. >> > >> > So, that's the basics. Right now, I'm working on fixing up the >> scripts >> > and removing the non-function property setting from Daemon. Does this >> > seem like the correct approach? >> >> I agree that forking the jvm is probably not a good idea because it >> complicates the startup process. Fixing the script instead seems like >> a cleaner approach. My only concern is that Geronimo's classloader >> may not be implemented in such a way that would give precedence to the >> classes loaded in this way, which seems contrary to my (limited) >> understanding of the JVM spec. I haven't tested to see if that's the >> case. >> >> Paul >> >
Re: Fixing java.endorsed.dirs
Yep...Tomcat too... Dain Sundstrom wrote: > Are you absolutely sure? How did you verify this? > > I am skeptical since we use this switch the xml parser to xerces and > this is required to pass the tck. > > -dain > > On Sep 28, 2006, at 3:18 AM, Rick McGuire wrote: > >> As I discovered yesterday, the Geronimo use of java.endorsed.dirs is >> completely broken. There's code in >> org.apache.geronimo.system.main.Daemon that appends information from >> the Geronimo manifest file to the system properties java.endorsed.dirs >> and java.ext.dirs, with the expectation that those directories will >> get used for class resolution. Well, unfortunately, those two >> properties are only used by the JVM during JVM initialization to set >> up the initial class loading structure. Once the code in Daemon is >> reached, it's too late. >> It's fairly simple to modify geronimo.bat and geronimo.sh to set these >> properties to hard coded values. For example, this seems an >> appropriate value for java.endorsed.dirs >> >> >> -Djava.endorsed.dirs="$JRE_HOME/lib/endorsed:$GERONIMO_BASE%/lib/endorsed" >> \ >> >> using the jre's endorsed directory and adding on the Geronimo endorsed >> directory. A similar thing can be done for java.ext.dirs, although >> the Geronimo assemblies don't even create the directory reference in >> the manifest. These are just hard-coded values. It's fairly >> difficult to process the manifest file from a batch file, but since >> these directories are hard coded into the build, I suspect it's ok to >> hard code them into the launcher scripts. >> >> I should be possible to accomplish what Daemon is doing by forking a >> new process to run the actual server, but I'm not sure that's really a >> good idea. >> So, that's the basics. Right now, I'm working on fixing up the >> scripts and removing the non-function property setting from Daemon. >> Does this seem like the correct approach? >> >> Rick
Re: Fixing java.endorsed.dirs
Are you absolutely sure? How did you verify this? I am skeptical since we use this switch the xml parser to xerces and this is required to pass the tck. -dain On Sep 28, 2006, at 3:18 AM, Rick McGuire wrote: As I discovered yesterday, the Geronimo use of java.endorsed.dirs is completely broken. There's code in org.apache.geronimo.system.main.Daemon that appends information from the Geronimo manifest file to the system properties java.endorsed.dirs and java.ext.dirs, with the expectation that those directories will get used for class resolution. Well, unfortunately, those two properties are only used by the JVM during JVM initialization to set up the initial class loading structure. Once the code in Daemon is reached, it's too late. It's fairly simple to modify geronimo.bat and geronimo.sh to set these properties to hard coded values. For example, this seems an appropriate value for java.endorsed.dirs -Djava.endorsed.dirs="$JRE_HOME/lib/endorsed:$GERONIMO_BASE%/lib/ endorsed" \ using the jre's endorsed directory and adding on the Geronimo endorsed directory. A similar thing can be done for java.ext.dirs, although the Geronimo assemblies don't even create the directory reference in the manifest. These are just hard-coded values. It's fairly difficult to process the manifest file from a batch file, but since these directories are hard coded into the build, I suspect it's ok to hard code them into the launcher scripts. I should be possible to accomplish what Daemon is doing by forking a new process to run the actual server, but I'm not sure that's really a good idea. So, that's the basics. Right now, I'm working on fixing up the scripts and removing the non-function property setting from Daemon. Does this seem like the correct approach? Rick
Re: Fixing java.endorsed.dirs
Heinz Drews wrote: The endorsed dirs are prepended to the bootclass path. Correcting the current situation should not cause classloading problems. It might cause a problem because now the newer of the xml specs are used instead of the one contained in the JRE. Geronimo was already placing jars in the endorsed dir with the intention that they be picked up that way. It was a bug that it wasn't. If we use a mechanism like the one used by Eclipse the spawning of a new JVM should not be too complicated. Therefore this should be still considered as an option. Heinz On 9/28/06, Paul McMahan <[EMAIL PROTECTED]> wrote: On 9/28/06, Rick McGuire <[EMAIL PROTECTED]> wrote: > I should be possible to accomplish what Daemon is doing by forking a new > process to run the actual server, but I'm not sure that's really a good > idea. > > So, that's the basics. Right now, I'm working on fixing up the scripts > and removing the non-function property setting from Daemon. Does this > seem like the correct approach? I agree that forking the jvm is probably not a good idea because it complicates the startup process. Fixing the script instead seems like a cleaner approach. My only concern is that Geronimo's classloader may not be implemented in such a way that would give precedence to the classes loaded in this way, which seems contrary to my (limited) understanding of the JVM spec. I haven't tested to see if that's the case. Paul
Re: Fixing java.endorsed.dirs
The endorsed dirs are prepended to the bootclass path. Correcting the current situation should not cause classloading problems. It might cause a problem because now the newer of the xml specs are used instead of the one contained in the JRE. If we use a mechanism like the one used by Eclipse the spawning of a new JVM should not be too complicated. Therefore this should be still considered as an option. Heinz On 9/28/06, Paul McMahan <[EMAIL PROTECTED]> wrote: On 9/28/06, Rick McGuire <[EMAIL PROTECTED]> wrote: > I should be possible to accomplish what Daemon is doing by forking a new > process to run the actual server, but I'm not sure that's really a good > idea. > > So, that's the basics. Right now, I'm working on fixing up the scripts > and removing the non-function property setting from Daemon. Does this > seem like the correct approach? I agree that forking the jvm is probably not a good idea because it complicates the startup process. Fixing the script instead seems like a cleaner approach. My only concern is that Geronimo's classloader may not be implemented in such a way that would give precedence to the classes loaded in this way, which seems contrary to my (limited) understanding of the JVM spec. I haven't tested to see if that's the case. Paul
Re: Fixing java.endorsed.dirs
I would assume that using a command line parm provides greater flexibility than extracting it from a manifest. Even if we would use the approach to spawn a new JVM. Heinz On 9/28/06, Rick McGuire <[EMAIL PROTECTED]> wrote: As I discovered yesterday, the Geronimo use of java.endorsed.dirs is completely broken. There's code in org.apache.geronimo.system.main.Daemon that appends information from the Geronimo manifest file to the system properties java.endorsed.dirs and java.ext.dirs, with the expectation that those directories will get used for class resolution. Well, unfortunately, those two properties are only used by the JVM during JVM initialization to set up the initial class loading structure. Once the code in Daemon is reached, it's too late. It's fairly simple to modify geronimo.bat and geronimo.sh to set these properties to hard coded values. For example, this seems an appropriate value for java.endorsed.dirs -Djava.endorsed.dirs="$JRE_HOME/lib/endorsed:$GERONIMO_BASE%/lib/endorsed" \ using the jre's endorsed directory and adding on the Geronimo endorsed directory. A similar thing can be done for java.ext.dirs, although the Geronimo assemblies don't even create the directory reference in the manifest. These are just hard-coded values. It's fairly difficult to process the manifest file from a batch file, but since these directories are hard coded into the build, I suspect it's ok to hard code them into the launcher scripts. I should be possible to accomplish what Daemon is doing by forking a new process to run the actual server, but I'm not sure that's really a good idea. So, that's the basics. Right now, I'm working on fixing up the scripts and removing the non-function property setting from Daemon. Does this seem like the correct approach? Rick
Re: Fixing java.endorsed.dirs
On 9/28/06, Rick McGuire <[EMAIL PROTECTED]> wrote: I should be possible to accomplish what Daemon is doing by forking a new process to run the actual server, but I'm not sure that's really a good idea. So, that's the basics. Right now, I'm working on fixing up the scripts and removing the non-function property setting from Daemon. Does this seem like the correct approach? I agree that forking the jvm is probably not a good idea because it complicates the startup process. Fixing the script instead seems like a cleaner approach. My only concern is that Geronimo's classloader may not be implemented in such a way that would give precedence to the classes loaded in this way, which seems contrary to my (limited) understanding of the JVM spec. I haven't tested to see if that's the case. Paul
