Re: Is java.endorsed.dirs actually working?
I have updated to rev 452025 and openejb2 to rev 452035. I am still seeing that the server is trying to start client-system configIs anyone else seeing this problem? If yes what could possibly be the cause?ThanksAnita- Original Message From: anita kulshreshtha <[EMAIL PROTECTED]>To: [email protected]: Thursday, September 28, 2006 3:13:03 PMSubject: Re: Is java.endorsed.dirs actually working?--- David Jencks <[EMAIL PROTECTED]> wrote:> > On Sep 28, 2006, at 8:07 AM, anita kulshreshtha wrote:> > >> >> > --- Rick McGuire <[EMAIL PROTECTED]> wrote:> >> >>> >> I decided to try an experiment using the jetty-j2ee Geronimo> >> assembly.> >> I deleted the Xerces jars from the lib/endorsed directory. I did> >> this> >> to convince myself that the java.endorsed.dirs mechanism was> working> >> correctly and the problem was due to me missing something with the> >> yoko> >> cofiguration. I expected Geronimo to "fall over" during launch> >> because> >> of the missing jars. To my surprise, it didn't.> > I deleted xerces dir from the repository and the startup> failed.> > You are correct in saying that the jars from lib/endorsed are not > > being> > used. Now I am wondering how are the jars from the G repository> being> > used. Are they really being used?> > Well, the copies of xerces etc in lib/endorsed are in the server.jar > > manifest classpath so even if they aren't really "endorsed" they are > > at least on the classpath. The exception you see is from us checking> > that the jars we claim we want are really available where we say they> > are -- something the manifest cp doesn't do. In particular the > exception you see comes before a configuration classloader that is > expected to contain the dependency is constructed.> > However, it looks to me as if your server startup is starting client-> > system. This is a serious problem if true. Have you made any local > > modifications to cause this or is it happening with a server built > straight from svn? I noticed that too.. This is with rev 449705. I did a full buildyesterday. I looked at the working console, i.e. with xerces. The listgiven by 'System Modules' is correct and lists client-system asstopped.ThanksAnita> > thanks> david jencks> > >> > Thanks> > Anita> >> > Booting Geronimo Kernel (in Java 1.4.2_12)...> > Starting Geronimo Application Server v1.2-SNAPSHOT> > [> ] 36% 9s Starting> > org.apache.geronimo.co...10:47:16,625 INFO [> > BrokerService] ActiveMQ 4.1-incubator-SNAPSHOT JMS Message Broker> > (possibly-unique-broker)> > is starting> > 10:47:16,625 INFO [BrokerService] For help or more information> please> > see: http://incubat> > or.apache.org/activemq/> > 10:47:16,687 INFO [ManagementContext] JMX consoles can connect to> > service:jmx:rmi://your-> > 4dacd0ea75/jndi/rmi://localhost:1099/jmxrmi> > [> ] 36% 9s Starting> > org.apache.geronimo.co...10:47:16,781 INFO [> > JDBCPersistenceAdapter] Database driver recognized:> > [apache_derby_embedded_jdbc_driver]> > [> ] 36% 11s Starting> > org.apache.geronimo.co...10:47:18,015 INFO [> > DefaultDatabaseLocker] Attempting to acquire the exclusive lock to> > become the Master broke> > r> > 10:47:18,015 INFO [DefaultDatabaseLocker] Becoming the master on> > dataSource: org.tranql.c> > [EMAIL PROTECTED]> > 10:47:18,125 INFO [JournalPersistenceAdapter] Journal Recovery > > Started> > from: Active Journ> > al: using 2 x 20.0 Megs at:> > C:\anita\geronimo\geronimo-tomcat-j2ee-1.2-SNAPSHOT\activemq-d> > ata\possibly-unique-broker\journal> > 10:47:18,187 INFO [JournalPersistenceAdapter] Journal Recovered: 0> > message(s) in transact> > ions recovered.> > [> ] 36% 11s Starting> > org.apache.geronimo.co...10:47:18,406 INFO [> > BrokerService] ActiveMQ JMS Message Broker (possibly-unique-broker,> > ID:your-4dacd0ea75-139> > 9-1159454836203-1:0) started> > 10:47:18,468 INFO [TransportConnector] Connector vm://localhost> > Started> > 10:47:18,515 INFO [TransportServerThreadSupport] Listening for> > connections at: stomp://yo> > ur-4dacd0ea75:61613> > 10:47:18,515 INFO [TransportConnector] Connector> > stomp://your-4dacd0ea75:61613 Started> > 10:47:18,531 INFO [TransportServerThreadSupport] Listening
Re: Is java.endorsed.dirs actually working?
--- David Jencks <[EMAIL PROTECTED]> wrote: > > On Sep 28, 2006, at 8:07 AM, anita kulshreshtha wrote: > > > > > > > --- Rick McGuire <[EMAIL PROTECTED]> wrote: > > > >> > >> I decided to try an experiment using the jetty-j2ee Geronimo > >> assembly. > >> I deleted the Xerces jars from the lib/endorsed directory. I did > >> this > >> to convince myself that the java.endorsed.dirs mechanism was > working > >> correctly and the problem was due to me missing something with the > >> yoko > >> cofiguration. I expected Geronimo to "fall over" during launch > >> because > >> of the missing jars. To my surprise, it didn't. > > I deleted xerces dir from the repository and the startup > failed. > > You are correct in saying that the jars from lib/endorsed are not > > being > > used. Now I am wondering how are the jars from the G repository > being > > used. Are they really being used? > > Well, the copies of xerces etc in lib/endorsed are in the server.jar > > manifest classpath so even if they aren't really "endorsed" they are > > at least on the classpath. The exception you see is from us checking > > that the jars we claim we want are really available where we say they > > are -- something the manifest cp doesn't do. In particular the > exception you see comes before a configuration classloader that is > expected to contain the dependency is constructed. > > However, it looks to me as if your server startup is starting client- > > system. This is a serious problem if true. Have you made any local > > modifications to cause this or is it happening with a server built > straight from svn? I noticed that too.. This is with rev 449705. I did a full build yesterday. I looked at the working console, i.e. with xerces. The list given by 'System Modules' is correct and lists client-system as stopped. Thanks Anita > > thanks > david jencks > > > > > Thanks > > Anita > > > > Booting Geronimo Kernel (in Java 1.4.2_12)... > > Starting Geronimo Application Server v1.2-SNAPSHOT > > [> ] 36% 9s Starting > > org.apache.geronimo.co...10:47:16,625 INFO [ > > BrokerService] ActiveMQ 4.1-incubator-SNAPSHOT JMS Message Broker > > (possibly-unique-broker) > > is starting > > 10:47:16,625 INFO [BrokerService] For help or more information > please > > see: http://incubat > > or.apache.org/activemq/ > > 10:47:16,687 INFO [ManagementContext] JMX consoles can connect to > > service:jmx:rmi://your- > > 4dacd0ea75/jndi/rmi://localhost:1099/jmxrmi > > [> ] 36% 9s Starting > > org.apache.geronimo.co...10:47:16,781 INFO [ > > JDBCPersistenceAdapter] Database driver recognized: > > [apache_derby_embedded_jdbc_driver] > > [> ] 36% 11s Starting > > org.apache.geronimo.co...10:47:18,015 INFO [ > > DefaultDatabaseLocker] Attempting to acquire the exclusive lock to > > become the Master broke > > r > > 10:47:18,015 INFO [DefaultDatabaseLocker] Becoming the master on > > dataSource: org.tranql.c > > [EMAIL PROTECTED] > > 10:47:18,125 INFO [JournalPersistenceAdapter] Journal Recovery > > Started > > from: Active Journ > > al: using 2 x 20.0 Megs at: > > C:\anita\geronimo\geronimo-tomcat-j2ee-1.2-SNAPSHOT\activemq-d > > ata\possibly-unique-broker\journal > > 10:47:18,187 INFO [JournalPersistenceAdapter] Journal Recovered: 0 > > message(s) in transact > > ions recovered. > > [> ] 36% 11s Starting > > org.apache.geronimo.co...10:47:18,406 INFO [ > > BrokerService] ActiveMQ JMS Message Broker (possibly-unique-broker, > > ID:your-4dacd0ea75-139 > > 9-1159454836203-1:0) started > > 10:47:18,468 INFO [TransportConnector] Connector vm://localhost > > Started > > 10:47:18,515 INFO [TransportServerThreadSupport] Listening for > > connections at: stomp://yo > > ur-4dacd0ea75:61613 > > 10:47:18,515 INFO [TransportConnector] Connector > > stomp://your-4dacd0ea75:61613 Started > > 10:47:18,531 INFO [TransportServerThreadSupport] Listening for > > connections at: tcp://0.0. > > 0.0:61616 > > 10:47:18,531 INFO [TransportConnector] Connector > tcp://0.0.0.0:61616 > > Started > > [***-] 62% 18s Loading > > org.apache.geronimo.co...10:47:25,078 ERROR [ > > GBeanInstanceState] Error while starting; GBean is now in the > FAILED > > state: abstractName=" > > org.apache.geronimo.configs/client-system/1.2-SNAPSHOT/car? > > configurationName=org.apache.ge > > ronimo.configs/client-system/1.2-SNAPSHOT/car" > > org.apache.geronimo.kernel.repository.MissingDependencyException: > > Unable to resolve depend > > ency xerces/xercesImpl/2.6.2/jar > > at > > org.apache.geronimo.kernel.config.ConfigurationResolver.resolve > > (ConfigurationRe > > solver.java:112) > > at > > org.apache.geronimo.kernel.config.Configuration.buildClassPath > > (Configuration.ja > > va:397) > > at > > > org.apache.geronimo.kernel.config.Configuration.createConfigurationCla > > > sssLoader > >
Re: Is java.endorsed.dirs actually working?
Dain Sundstrom wrote: There is a lot of text here and I'm a bit confused. FWIU, to use the trick we used in bootstrap you need the following: 1) add your endorsed jars to the manifest class path 2) no code accessed during the boot process can reference an endorsed package 3) modify the endorsed system property 4) use reflection to load a class that accesses the endorsed class (this may have to happen in a child class loader) That's not the behavior I'm seeing in any of the experiments I've seen. The directories searched for endorsed appear to be fixed at JVM boot time, so Geronimo's additions to java.endorsed.dirs in Daemon were having no effect. I tested this with both the yoko-spec-corba jar and the Xerces XML specs. In both cases, I was getting the JVM native classes. In order to get this working correctly, I set GERONIMO_OPTS to -Djava.endorsed.dirs=C://lib/endorsed. Once that was set, the correct classes were getting returned. I saw the same behavior from some simple tests I coded up. Rick I have high confidence in this process due to the tck passing. Additionally, I received a customer complaint that we were overriding the xml processor on Java5 with the older spec version included with Geronimo. Now it may turn out that this magic only works with the xml specs, but I'd be very surprised. -dain On Sep 27, 2006, at 8:11 AM, Rick McGuire wrote: I've been wrestling with a Yoko ORB problem when running under Java 5. When running on 1.4.2, the Yoko ORB works fine because the native JVM doesn't include an implementation of org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no conflict, the yoko version is getting loaded. With Sun's Java 5 impl, there is a version of org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible with the CORBA standard (and also the Yoko implementation). The Sun version is getting picked up, cause ORB initialization failures. This is occurring even though the yoko-spec-corba jar has been copied into lib/endorsed. I decided to try an experiment using the jetty-j2ee Geronimo assembly. I deleted the Xerces jars from the lib/endorsed directory. I did this to convince myself that the java.endorsed.dirs mechanism was working correctly and the problem was due to me missing something with the yoko cofiguration. I expected Geronimo to "fall over" during launch because of the missing jars. To my surprise, it didn't. I instrumented one of the yoko classes, and add it load the IORInterceptor_3_0 class and org.w3c.dom.Element and dump the package information for these classes. The Package information indicates both of these classes are resolving to the JVM native versions rather than the versions in lib/endorsed. The java.endorsed.dirs appears to be set to the correct value, and the jar files are in the appropriate directory, but the classes don't appear to be getting picked up. This was just the last experiment for a problem I've been chasing since Monday. I'm getting extremely inconsistent results from using java.endorsed.dirs. Right now, I have 4 situations in front of me: 1) Simple standalone test case using Yoko ORB. 2) Yoko unit tests using surefire plugin. 3) Openejb Yoko unit tests using surefile plugin (setup was copied from the Yoko unit tests). 4) Full Geronimo assembly using the Yoko ORB. When running under Java 5, 1) and 2) work ok. 3) fails, even though the surefile tests (in theory) are running exactly the same way as 2). 4) also fails. 1), 3), and 4) all work fine under Java 1.4.2, but there's no conflict with the native IORInterceptor_3_0 class is that scenario. I spent most of yesterday wrestling with scenario 3), and never getting it to work. Like scenario 4), the jar files are in the target endorsed directory and the java.endorsed.dirs is pointing to the correct location. Right now, I'm completely stumped, and I'm wondering if this has every really worked in the Geronimo assembly. Rick
Re: Is java.endorsed.dirs actually working?
There is a lot of text here and I'm a bit confused. FWIU, to use the trick we used in bootstrap you need the following: 1) add your endorsed jars to the manifest class path 2) no code accessed during the boot process can reference an endorsed package 3) modify the endorsed system property 4) use reflection to load a class that accesses the endorsed class (this may have to happen in a child class loader) I have high confidence in this process due to the tck passing. Additionally, I received a customer complaint that we were overriding the xml processor on Java5 with the older spec version included with Geronimo. Now it may turn out that this magic only works with the xml specs, but I'd be very surprised. -dain On Sep 27, 2006, at 8:11 AM, Rick McGuire wrote: I've been wrestling with a Yoko ORB problem when running under Java 5. When running on 1.4.2, the Yoko ORB works fine because the native JVM doesn't include an implementation of org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no conflict, the yoko version is getting loaded. With Sun's Java 5 impl, there is a version of org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible with the CORBA standard (and also the Yoko implementation). The Sun version is getting picked up, cause ORB initialization failures. This is occurring even though the yoko-spec-corba jar has been copied into lib/endorsed. I decided to try an experiment using the jetty-j2ee Geronimo assembly. I deleted the Xerces jars from the lib/endorsed directory. I did this to convince myself that the java.endorsed.dirs mechanism was working correctly and the problem was due to me missing something with the yoko cofiguration. I expected Geronimo to "fall over" during launch because of the missing jars. To my surprise, it didn't. I instrumented one of the yoko classes, and add it load the IORInterceptor_3_0 class and org.w3c.dom.Element and dump the package information for these classes. The Package information indicates both of these classes are resolving to the JVM native versions rather than the versions in lib/endorsed. The java.endorsed.dirs appears to be set to the correct value, and the jar files are in the appropriate directory, but the classes don't appear to be getting picked up. This was just the last experiment for a problem I've been chasing since Monday. I'm getting extremely inconsistent results from using java.endorsed.dirs. Right now, I have 4 situations in front of me: 1) Simple standalone test case using Yoko ORB. 2) Yoko unit tests using surefire plugin. 3) Openejb Yoko unit tests using surefile plugin (setup was copied from the Yoko unit tests). 4) Full Geronimo assembly using the Yoko ORB. When running under Java 5, 1) and 2) work ok. 3) fails, even though the surefile tests (in theory) are running exactly the same way as 2). 4) also fails. 1), 3), and 4) all work fine under Java 1.4.2, but there's no conflict with the native IORInterceptor_3_0 class is that scenario. I spent most of yesterday wrestling with scenario 3), and never getting it to work. Like scenario 4), the jar files are in the target endorsed directory and the java.endorsed.dirs is pointing to the correct location. Right now, I'm completely stumped, and I'm wondering if this has every really worked in the Geronimo assembly. Rick
Re: Is java.endorsed.dirs actually working?
On Sep 28, 2006, at 8:07 AM, anita kulshreshtha wrote: --- Rick McGuire <[EMAIL PROTECTED]> wrote: I decided to try an experiment using the jetty-j2ee Geronimo assembly. I deleted the Xerces jars from the lib/endorsed directory. I did this to convince myself that the java.endorsed.dirs mechanism was working correctly and the problem was due to me missing something with the yoko cofiguration. I expected Geronimo to "fall over" during launch because of the missing jars. To my surprise, it didn't. I deleted xerces dir from the repository and the startup failed. You are correct in saying that the jars from lib/endorsed are not being used. Now I am wondering how are the jars from the G repository being used. Are they really being used? Well, the copies of xerces etc in lib/endorsed are in the server.jar manifest classpath so even if they aren't really "endorsed" they are at least on the classpath. The exception you see is from us checking that the jars we claim we want are really available where we say they are -- something the manifest cp doesn't do. In particular the exception you see comes before a configuration classloader that is expected to contain the dependency is constructed. However, it looks to me as if your server startup is starting client- system. This is a serious problem if true. Have you made any local modifications to cause this or is it happening with a server built straight from svn? thanks david jencks Thanks Anita Booting Geronimo Kernel (in Java 1.4.2_12)... Starting Geronimo Application Server v1.2-SNAPSHOT [> ] 36% 9s Starting org.apache.geronimo.co...10:47:16,625 INFO [ BrokerService] ActiveMQ 4.1-incubator-SNAPSHOT JMS Message Broker (possibly-unique-broker) is starting 10:47:16,625 INFO [BrokerService] For help or more information please see: http://incubat or.apache.org/activemq/ 10:47:16,687 INFO [ManagementContext] JMX consoles can connect to service:jmx:rmi://your- 4dacd0ea75/jndi/rmi://localhost:1099/jmxrmi [> ] 36% 9s Starting org.apache.geronimo.co...10:47:16,781 INFO [ JDBCPersistenceAdapter] Database driver recognized: [apache_derby_embedded_jdbc_driver] [> ] 36% 11s Starting org.apache.geronimo.co...10:47:18,015 INFO [ DefaultDatabaseLocker] Attempting to acquire the exclusive lock to become the Master broke r 10:47:18,015 INFO [DefaultDatabaseLocker] Becoming the master on dataSource: org.tranql.c [EMAIL PROTECTED] 10:47:18,125 INFO [JournalPersistenceAdapter] Journal Recovery Started from: Active Journ al: using 2 x 20.0 Megs at: C:\anita\geronimo\geronimo-tomcat-j2ee-1.2-SNAPSHOT\activemq-d ata\possibly-unique-broker\journal 10:47:18,187 INFO [JournalPersistenceAdapter] Journal Recovered: 0 message(s) in transact ions recovered. [> ] 36% 11s Starting org.apache.geronimo.co...10:47:18,406 INFO [ BrokerService] ActiveMQ JMS Message Broker (possibly-unique-broker, ID:your-4dacd0ea75-139 9-1159454836203-1:0) started 10:47:18,468 INFO [TransportConnector] Connector vm://localhost Started 10:47:18,515 INFO [TransportServerThreadSupport] Listening for connections at: stomp://yo ur-4dacd0ea75:61613 10:47:18,515 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Started 10:47:18,531 INFO [TransportServerThreadSupport] Listening for connections at: tcp://0.0. 0.0:61616 10:47:18,531 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Started [***-] 62% 18s Loading org.apache.geronimo.co...10:47:25,078 ERROR [ GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=" org.apache.geronimo.configs/client-system/1.2-SNAPSHOT/car? configurationName=org.apache.ge ronimo.configs/client-system/1.2-SNAPSHOT/car" org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to resolve depend ency xerces/xercesImpl/2.6.2/jar at org.apache.geronimo.kernel.config.ConfigurationResolver.resolve (ConfigurationRe solver.java:112) at org.apache.geronimo.kernel.config.Configuration.buildClassPath (Configuration.ja va:397) at org.apache.geronimo.kernel.config.Configuration.createConfigurationCla sssLoader (Configuration.java:322) at org.apache.geronimo.kernel.config.Configuration. (Configuration.java:267) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessor Impl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance (DelegatingConstructor AccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance (GBeanInstance.ja va:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( GBeanInst anceState.java:267) at
Re: Is java.endorsed.dirs actually working?
--- Rick McGuire <[EMAIL PROTECTED]> wrote: > > I decided to try an experiment using the jetty-j2ee Geronimo > assembly. > I deleted the Xerces jars from the lib/endorsed directory. I did > this > to convince myself that the java.endorsed.dirs mechanism was working > correctly and the problem was due to me missing something with the > yoko > cofiguration. I expected Geronimo to "fall over" during launch > because > of the missing jars. To my surprise, it didn't. I deleted xerces dir from the repository and the startup failed. You are correct in saying that the jars from lib/endorsed are not being used. Now I am wondering how are the jars from the G repository being used. Are they really being used? Thanks Anita Booting Geronimo Kernel (in Java 1.4.2_12)... Starting Geronimo Application Server v1.2-SNAPSHOT [> ] 36% 9s Starting org.apache.geronimo.co...10:47:16,625 INFO [ BrokerService] ActiveMQ 4.1-incubator-SNAPSHOT JMS Message Broker (possibly-unique-broker) is starting 10:47:16,625 INFO [BrokerService] For help or more information please see: http://incubat or.apache.org/activemq/ 10:47:16,687 INFO [ManagementContext] JMX consoles can connect to service:jmx:rmi://your- 4dacd0ea75/jndi/rmi://localhost:1099/jmxrmi [> ] 36% 9s Starting org.apache.geronimo.co...10:47:16,781 INFO [ JDBCPersistenceAdapter] Database driver recognized: [apache_derby_embedded_jdbc_driver] [> ] 36% 11s Starting org.apache.geronimo.co...10:47:18,015 INFO [ DefaultDatabaseLocker] Attempting to acquire the exclusive lock to become the Master broke r 10:47:18,015 INFO [DefaultDatabaseLocker] Becoming the master on dataSource: org.tranql.c [EMAIL PROTECTED] 10:47:18,125 INFO [JournalPersistenceAdapter] Journal Recovery Started from: Active Journ al: using 2 x 20.0 Megs at: C:\anita\geronimo\geronimo-tomcat-j2ee-1.2-SNAPSHOT\activemq-d ata\possibly-unique-broker\journal 10:47:18,187 INFO [JournalPersistenceAdapter] Journal Recovered: 0 message(s) in transact ions recovered. [> ] 36% 11s Starting org.apache.geronimo.co...10:47:18,406 INFO [ BrokerService] ActiveMQ JMS Message Broker (possibly-unique-broker, ID:your-4dacd0ea75-139 9-1159454836203-1:0) started 10:47:18,468 INFO [TransportConnector] Connector vm://localhost Started 10:47:18,515 INFO [TransportServerThreadSupport] Listening for connections at: stomp://yo ur-4dacd0ea75:61613 10:47:18,515 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Started 10:47:18,531 INFO [TransportServerThreadSupport] Listening for connections at: tcp://0.0. 0.0:61616 10:47:18,531 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Started [***-] 62% 18s Loading org.apache.geronimo.co...10:47:25,078 ERROR [ GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=" org.apache.geronimo.configs/client-system/1.2-SNAPSHOT/car?configurationName=org.apache.ge ronimo.configs/client-system/1.2-SNAPSHOT/car" org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to resolve depend ency xerces/xercesImpl/2.6.2/jar at org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationRe solver.java:112) at org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.ja va:397) at org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader (Configuration.java:322) at org.apache.geronimo.kernel.config.Configuration.(Configuration.java:267) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessor Impl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructor AccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.ja va:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInst anceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.j ava:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:529) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361) at org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigu rationManager.java:161) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration( SimpleConfigurationManager.java:307) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration( SimpleConfigurationManager.java:275) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration( SimpleConfigurationManager.java:250) at
Re: Is java.endorsed.dirs actually working?
-Djava.endorsed.dirs is interpreted during the construction of the bootstrap classpath. Setting it in a Java class does not have an effect for the current JVM. Daemon.java would have to spawn a new process and start another JVM passing the property. Heinz On 9/27/06, Rick McGuire <[EMAIL PROTECTED]> wrote: Ok, I've got it working 4-for-4 now, and I was right, it IS broken in Geronimo right now. The missing piece is the -Djava.endorsed.dirs on the commandline. It appears that setting this value in Daemon.java won't work. It needs to be set on the commandline. Rick David Jencks wrote: > > On Sep 27, 2006, at 8:11 AM, Rick McGuire wrote: > >> I've been wrestling with a Yoko ORB problem when running under Java >> 5. When running on 1.4.2, the Yoko ORB works fine because the native >> JVM doesn't include an implementation of >> org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no >> conflict, the yoko version is getting loaded. >> With Sun's Java 5 impl, there is a version of >> org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible >> with the CORBA standard (and also the Yoko implementation). The Sun >> version is getting picked up, cause ORB initialization failures. >> This is occurring even though the yoko-spec-corba jar has been copied >> into lib/endorsed. >> >> I decided to try an experiment using the jetty-j2ee Geronimo >> assembly. I deleted the Xerces jars from the lib/endorsed >> directory. I did this to convince myself that the java.endorsed.dirs >> mechanism was working correctly and the problem was due to me missing >> something with the yoko cofiguration. I expected Geronimo to "fall >> over" during launch because of the missing jars. To my surprise, it >> didn't. >> I instrumented one of the yoko classes, and add it load the >> IORInterceptor_3_0 class and org.w3c.dom.Element and dump the package >> information for these classes. The Package information indicates >> both of these classes are resolving to the JVM native versions rather >> than the versions in lib/endorsed. The java.endorsed.dirs appears to >> be set to the correct value, and the jar files are in the appropriate >> directory, but the classes don't appear to be getting picked up. >> >> This was just the last experiment for a problem I've been chasing >> since Monday. I'm getting extremely inconsistent results from using >> java.endorsed.dirs. Right now, I have 4 situations in front of me: >> >> 1) Simple standalone test case using Yoko ORB. >> 2) Yoko unit tests using surefire plugin. >> 3) Openejb Yoko unit tests using surefile plugin (setup was copied >> from the Yoko unit tests). >> 4) Full Geronimo assembly using the Yoko ORB. >> >> When running under Java 5, 1) and 2) work ok. 3) fails, even though >> the surefile tests (in theory) are running exactly the same way as >> 2). 4) also fails. 1), 3), and 4) all work fine under Java 1.4.2, >> but there's no conflict with the native IORInterceptor_3_0 class is >> that scenario. I spent most of yesterday wrestling with scenario 3), >> and never getting it to work. Like scenario 4), the jar files are in >> the target endorsed directory and the java.endorsed.dirs is pointing >> to the correct location. Right now, I'm completely stumped, and I'm >> wondering if this has every really worked in the Geronimo assembly. > > I have often wondered if our endorsed dir actually worked also... it's > always seemed somewhat unlikely :-) > > How is the endorsed dir set for 2) and 3), and how does the yoko jar > get onto the classpath? > > Does 2) involve an actual yoko jar or does it run off of unjarred > classes? > > Is anything different in esp. 4) if you set the endorsed dir on the > command line rather than letting geronimo set it after the jvm has > started more? > > thanks > david jencks > > > >> >> Rick >> >> > >
Re: Is java.endorsed.dirs actually working?
Ok, I've got it working 4-for-4 now, and I was right, it IS broken in Geronimo right now. The missing piece is the -Djava.endorsed.dirs on the commandline. It appears that setting this value in Daemon.java won't work. It needs to be set on the commandline. Rick David Jencks wrote: On Sep 27, 2006, at 8:11 AM, Rick McGuire wrote: I've been wrestling with a Yoko ORB problem when running under Java 5. When running on 1.4.2, the Yoko ORB works fine because the native JVM doesn't include an implementation of org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no conflict, the yoko version is getting loaded. With Sun's Java 5 impl, there is a version of org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible with the CORBA standard (and also the Yoko implementation). The Sun version is getting picked up, cause ORB initialization failures. This is occurring even though the yoko-spec-corba jar has been copied into lib/endorsed. I decided to try an experiment using the jetty-j2ee Geronimo assembly. I deleted the Xerces jars from the lib/endorsed directory. I did this to convince myself that the java.endorsed.dirs mechanism was working correctly and the problem was due to me missing something with the yoko cofiguration. I expected Geronimo to "fall over" during launch because of the missing jars. To my surprise, it didn't. I instrumented one of the yoko classes, and add it load the IORInterceptor_3_0 class and org.w3c.dom.Element and dump the package information for these classes. The Package information indicates both of these classes are resolving to the JVM native versions rather than the versions in lib/endorsed. The java.endorsed.dirs appears to be set to the correct value, and the jar files are in the appropriate directory, but the classes don't appear to be getting picked up. This was just the last experiment for a problem I've been chasing since Monday. I'm getting extremely inconsistent results from using java.endorsed.dirs. Right now, I have 4 situations in front of me: 1) Simple standalone test case using Yoko ORB. 2) Yoko unit tests using surefire plugin. 3) Openejb Yoko unit tests using surefile plugin (setup was copied from the Yoko unit tests). 4) Full Geronimo assembly using the Yoko ORB. When running under Java 5, 1) and 2) work ok. 3) fails, even though the surefile tests (in theory) are running exactly the same way as 2). 4) also fails. 1), 3), and 4) all work fine under Java 1.4.2, but there's no conflict with the native IORInterceptor_3_0 class is that scenario. I spent most of yesterday wrestling with scenario 3), and never getting it to work. Like scenario 4), the jar files are in the target endorsed directory and the java.endorsed.dirs is pointing to the correct location. Right now, I'm completely stumped, and I'm wondering if this has every really worked in the Geronimo assembly. I have often wondered if our endorsed dir actually worked also... it's always seemed somewhat unlikely :-) How is the endorsed dir set for 2) and 3), and how does the yoko jar get onto the classpath? Does 2) involve an actual yoko jar or does it run off of unjarred classes? Is anything different in esp. 4) if you set the endorsed dir on the command line rather than letting geronimo set it after the jvm has started more? thanks david jencks Rick
Re: Is java.endorsed.dirs actually working?
Here is the 5th one: As you said the java.endorsed.dirs property is being set properly. but we still had to add lib/endorsed to the class path explicitly. It might be due to the fact that it is checked before the jvm is forked. Did you try starting the server using -Djava.endorsed.dirs=? I have no clues why it does not work, just shooting in the dark.. Thanks Anita --- Rick McGuire <[EMAIL PROTECTED]> wrote: > I've been wrestling with a Yoko ORB problem when running under Java > 5. > When running on 1.4.2, the Yoko ORB works fine because the native JVM > > doesn't include an implementation of > org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no > conflict, the yoko version is getting loaded. > > With Sun's Java 5 impl, there is a version of > org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible > with > the CORBA standard (and also the Yoko implementation). The Sun > version > is getting picked up, cause ORB initialization failures. This is > occurring even though the yoko-spec-corba jar has been copied into > lib/endorsed. > > I decided to try an experiment using the jetty-j2ee Geronimo > assembly. > I deleted the Xerces jars from the lib/endorsed directory. I did > this > to convince myself that the java.endorsed.dirs mechanism was working > correctly and the problem was due to me missing something with the > yoko > cofiguration. I expected Geronimo to "fall over" during launch > because > of the missing jars. To my surprise, it didn't. > > I instrumented one of the yoko classes, and add it load the > IORInterceptor_3_0 class and org.w3c.dom.Element and dump the package > > information for these classes. The Package information indicates > both > of these classes are resolving to the JVM native versions rather than > > the versions in lib/endorsed. The java.endorsed.dirs appears to be > set > to the correct value, and the jar files are in the appropriate > directory, but the classes don't appear to be getting picked up. > > This was just the last experiment for a problem I've been chasing > since > Monday. I'm getting extremely inconsistent results from using > java.endorsed.dirs. Right now, I have 4 situations in front of me: > > 1) Simple standalone test case using Yoko ORB. > 2) Yoko unit tests using surefire plugin. > 3) Openejb Yoko unit tests using surefile plugin (setup was copied > from > the Yoko unit tests). > 4) Full Geronimo assembly using the Yoko ORB. > > When running under Java 5, 1) and 2) work ok. 3) fails, even though > the > surefile tests (in theory) are running exactly the same way as 2). > 4) > also fails. 1), 3), and 4) all work fine under Java 1.4.2, but > there's > no conflict with the native IORInterceptor_3_0 class is that > scenario. > I spent most of yesterday wrestling with scenario 3), and never > getting > it to work. Like scenario 4), the jar files are in the target > endorsed > directory and the java.endorsed.dirs is pointing to the correct > location. Right now, I'm completely stumped, and I'm wondering if > this > has every really worked in the Geronimo assembly. > > Rick > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Is java.endorsed.dirs actually working?
David Jencks wrote:
On Sep 27, 2006, at 8:11 AM, Rick McGuire wrote:
I've been wrestling with a Yoko ORB problem when running under Java
5. When running on 1.4.2, the Yoko ORB works fine because the native
JVM doesn't include an implementation of
org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no
conflict, the yoko version is getting loaded.
With Sun's Java 5 impl, there is a version of
org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible
with the CORBA standard (and also the Yoko implementation). The Sun
version is getting picked up, cause ORB initialization failures.
This is occurring even though the yoko-spec-corba jar has been copied
into lib/endorsed.
I decided to try an experiment using the jetty-j2ee Geronimo
assembly. I deleted the Xerces jars from the lib/endorsed
directory. I did this to convince myself that the java.endorsed.dirs
mechanism was working correctly and the problem was due to me missing
something with the yoko cofiguration. I expected Geronimo to "fall
over" during launch because of the missing jars. To my surprise, it
didn't.
I instrumented one of the yoko classes, and add it load the
IORInterceptor_3_0 class and org.w3c.dom.Element and dump the package
information for these classes. The Package information indicates
both of these classes are resolving to the JVM native versions rather
than the versions in lib/endorsed. The java.endorsed.dirs appears to
be set to the correct value, and the jar files are in the appropriate
directory, but the classes don't appear to be getting picked up.
This was just the last experiment for a problem I've been chasing
since Monday. I'm getting extremely inconsistent results from using
java.endorsed.dirs. Right now, I have 4 situations in front of me:
1) Simple standalone test case using Yoko ORB.
2) Yoko unit tests using surefire plugin.
3) Openejb Yoko unit tests using surefile plugin (setup was copied
from the Yoko unit tests).
4) Full Geronimo assembly using the Yoko ORB.
When running under Java 5, 1) and 2) work ok. 3) fails, even though
the surefile tests (in theory) are running exactly the same way as
2). 4) also fails. 1), 3), and 4) all work fine under Java 1.4.2,
but there's no conflict with the native IORInterceptor_3_0 class is
that scenario. I spent most of yesterday wrestling with scenario 3),
and never getting it to work. Like scenario 4), the jar files are in
the target endorsed directory and the java.endorsed.dirs is pointing
to the correct location. Right now, I'm completely stumped, and I'm
wondering if this has every really worked in the Geronimo assembly.
I have often wondered if our endorsed dir actually worked also... it's
always seemed somewhat unlikely :-)
How is the endorsed dir set for 2) and 3), and how does the yoko jar
get onto the classpath?
Let me give you an indirect answer here by first answering the question
for 1). My experiments with the simple test case show that if you set
java.endorsed.jars, then all of the jar files in the reference
directories are automatically part of the classpath (or more
appropriately, the bootclasspath). They function as if you had
prepended the jars to the bootclasspath. The resolved class have the
"null" classloader.
The endorsed dir is set for 2) and 3) by setting the system property in
the surefire plugin definition.
org.apache.maven.plugins
maven-surefire-plugin
implementation="java.lang.String">**/org/apache/yoko/*Test.java
java.endorsed.dirs
${basedir}/target/endorsed
The jar files are copied to the endorsed dir using the dependency plugin:
org.apache.maven.plugins
maven-dependency-plugin
generate-sources
copy
org.apache.yoko
yoko-spec-corba
jar
true
${project.build.directory}/endorsed
The jar files also are ending up on the classpath by virtue of the
dependencies, but my experiments with 1) suggest this shouldn't be
necessary, and the classes in the endorsed dir should be picked up instead.
Does 2) involve an actual yoko jar or does it run off of unjarred
classes?
A 4 of these are using the same version of the yoko jar file.
Is anything different in esp. 4) if you set the endorsed dir on the
command line rather than letting geronimo set it after the jvm has
started more?
I haven't tried that experiment yet. I'll try hacking something up.
thanks
david jencks
Rick
Re: Is java.endorsed.dirs actually working?
On Sep 27, 2006, at 8:11 AM, Rick McGuire wrote: I've been wrestling with a Yoko ORB problem when running under Java 5. When running on 1.4.2, the Yoko ORB works fine because the native JVM doesn't include an implementation of org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no conflict, the yoko version is getting loaded. With Sun's Java 5 impl, there is a version of org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible with the CORBA standard (and also the Yoko implementation). The Sun version is getting picked up, cause ORB initialization failures. This is occurring even though the yoko-spec-corba jar has been copied into lib/endorsed. I decided to try an experiment using the jetty-j2ee Geronimo assembly. I deleted the Xerces jars from the lib/endorsed directory. I did this to convince myself that the java.endorsed.dirs mechanism was working correctly and the problem was due to me missing something with the yoko cofiguration. I expected Geronimo to "fall over" during launch because of the missing jars. To my surprise, it didn't. I instrumented one of the yoko classes, and add it load the IORInterceptor_3_0 class and org.w3c.dom.Element and dump the package information for these classes. The Package information indicates both of these classes are resolving to the JVM native versions rather than the versions in lib/endorsed. The java.endorsed.dirs appears to be set to the correct value, and the jar files are in the appropriate directory, but the classes don't appear to be getting picked up. This was just the last experiment for a problem I've been chasing since Monday. I'm getting extremely inconsistent results from using java.endorsed.dirs. Right now, I have 4 situations in front of me: 1) Simple standalone test case using Yoko ORB. 2) Yoko unit tests using surefire plugin. 3) Openejb Yoko unit tests using surefile plugin (setup was copied from the Yoko unit tests). 4) Full Geronimo assembly using the Yoko ORB. When running under Java 5, 1) and 2) work ok. 3) fails, even though the surefile tests (in theory) are running exactly the same way as 2). 4) also fails. 1), 3), and 4) all work fine under Java 1.4.2, but there's no conflict with the native IORInterceptor_3_0 class is that scenario. I spent most of yesterday wrestling with scenario 3), and never getting it to work. Like scenario 4), the jar files are in the target endorsed directory and the java.endorsed.dirs is pointing to the correct location. Right now, I'm completely stumped, and I'm wondering if this has every really worked in the Geronimo assembly. I have often wondered if our endorsed dir actually worked also... it's always seemed somewhat unlikely :-) How is the endorsed dir set for 2) and 3), and how does the yoko jar get onto the classpath? Does 2) involve an actual yoko jar or does it run off of unjarred classes? Is anything different in esp. 4) if you set the endorsed dir on the command line rather than letting geronimo set it after the jvm has started more? thanks david jencks Rick
