Hello, I try to run Geronimo-1.2-beta (tomcat and jetty version) on Harmony classlib + DRLVM. If commons-logging jar is added into the bootclasspath the exception "java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory" doesn't occur.
However the problem of the keystore types appears. It is described in JIRA: GERONIMO-2015 and GERONIMO-2342. If we replace the keystore type with PKCS12 by adding the parameter to config.xml: 1) Geronimo-1.2-beta (tomcat version) startup stops at 83% (webconsole-tomcat fails); 2) Geronimo-1.1-tomcat starts successfully. Regards, Nellya. -----Original Message----- From: Sean Qiu [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 5:18 AM To: [email protected] Subject: Re: [apps] Problem starting Geronimo 1.2 beta When i run the Geronimo 2.0M2, I encountered the same problem. 2007/2/7, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > > > On Feb 7, 2007, at 7:41 AM, Mikhail Markov wrote: > > > On 2/7/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> > >> > >> On Feb 7, 2007, at 7:23 AM, Mikhail Markov wrote: > >> > >> >> Why? This code runs perfectly fine on the RI. At best, you might > >> >> argue it's not good design on G's part, but they hard-coded > >> clogging > >> >> for a reason. > >> > RI does not have MX4J in bootclasspath. If you put it there - > >> > Geronimo will > >> > fail as well. > >> > >> I know. But the fact that we are using mx4j as our jmx > >> implementation shouldn't affect applications. So we have to make it > >> appear that mx4j isn't there > > > >> > >> >> Note that when I do drop clogging into the boootclasspath, > >> Geronimo > >> >> still doesn't start :) > >> > Well, there are some other open issues against Geronimo which could > >> > prevents it from starting on non-RI JDKs :-) > >> > See, for example, http://issues.apache.org/jira/browse/ > >> GERONIMO-2015, > >> > http://issues.apache.org/jira/browse/GERONIMO-1804, > >> > >> The first shouldn't stop it from coming up. The second seems to, but > >> we can solve that w/ an addition to our suncompat package, right? > > > > > > We could workaround everything :-) but as Geronimo is an Apache > > project it > > seems more natural to me to influence them fixing this issue, moreover > > hadcoding name of JNDI provider is not a good thing anyway. > > I agree in principle, but it's not up to us to enforce as a VM. > We're going to encounter lots of people that do things like this. > > geir > > > > > > Regards, > > Mikhail > > > > geir > >> > >> > > >> > Regards, > >> > Mikhail > >> > > >> > On 2/7/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> >> > >> >> > >> >> On Feb 7, 2007, at 6:39 AM, Mikhail Markov wrote: > >> >> > >> >> > Yes, sure this is classloader problem, but MX4J has a nice > >> >> > mechanizm of > >> >> > choosing loggers: > >> >> > it either use the default java.util.logging, or, if > >> >> > 'mx4j.log.prototype' > >> >> > property is set, the logger specified in this property. > >> >> > Geronimo just hard-coded commons-logging and does not allow > >> users > >> >> > to specify > >> >> > another logging facilities. > >> >> > If we could use j.u.l then Geronimo will probably start without > >> >> > problems. > >> >> > So, IMHO, partially this is also a Geronimo bug. > >> >> > >> >> Why? This code runs perfectly fine on the RI. At best, you might > >> >> argue it's not good design on G's part, but they hard-coded > >> clogging > >> >> for a reason. > >> >> > >> >> Note that when I do drop clogging into the boootclasspath, > >> Geronimo > >> >> still doesn't start :) > >> >> > >> >> geir > >> >> > >> >> > >> >> > > >> >> > Regards, > >> >> > Mikhail > >> >> > > >> >> > > >> >> > On 2/7/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> >> >> > >> >> >> > >> >> >> On Feb 7, 2007, at 5:46 AM, Mikhail Markov wrote: > >> >> >> > >> >> >> > JFYI: there is also a specific JIRA in Geronimo describing > >> the > >> >> >> > hardcoded > >> >> >> > commons-logging logger: http://issues.apache.org/jira/ > >> browse/ > >> >> >> > GERONIMO-2595. > >> >> >> > >> >> >> THanks - I linked that to HARMONY-1259. I don't think this > >> is a > >> >> >> logging problem per se, but a classloader issue. > >> >> >> > > >> >> >> > Regards, > >> >> >> > Mikhail > >> >> >> > > >> >> >> > On 2/7/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> >> >> >> > >> >> >> >> Ok - this is the old problem of hiding things on our > >> >> bootclasspath > >> >> >> >> like mx4j from apps. G uses mx4j, and it looks for commons- > >> >> >> logging. > >> >> >> >> > >> >> >> >> I'm going to start a new thread, because this is a > >> >> problem... :/ > >> >> >> >> > >> >> >> >> On Feb 6, 2007, at 9:22 PM, Geir Magnusson Jr. wrote: > >> >> >> >> > >> >> >> >> > Yah, this is the same thing in > >> >> >> >> > > >> >> >> >> > http://issues.apache.org/jira/browse/HARMONY-1259 > >> >> >> >> > > >> >> >> >> > (and we can't seem to start JBoss either... :) > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > On Feb 6, 2007, at 9:00 PM, Geir Magnusson Jr wrote: > >> >> >> >> > > >> >> >> >> >> I remember we had a similar looking problem a while ago, > >> >> but I > >> >> >> >> >> thought it was solved. Building DRLVM+Classlib from SVN > >> >> >> head, and > >> >> >> >> >> trying simply to start Geronimo 1.2 beta (tomcat > >> version), I > >> >> >> get > >> >> >> >> >> this : > >> >> >> >> >> > >> >> >> >> >> 01:53:58,407 ERROR [GBeanInstanceState] Error while > >> >> starting; > >> >> >> >> >> GBean is now in the FAILED state: > >> >> >> >> >> abstractName="org.apache.geronimo.configs/rmi-naming/1.2- > >> >> >> beta/car? > >> >> >> >> >> ServiceModule=org.apache.geronimo.configs/rmi-naming/1.2- > >> >> beta/ > >> >> >> >> >> car,j2eeType=GBean,name=MBeanServerReference" > >> >> >> >> >> java.lang.NoClassDefFoundError: org/apache/commons/ > >> logging/ > >> >> >> >> LogFactory > >> >> >> >> >> at mx4j.log.Log.createLogger(Log.java:209) > >> >> >> >> >> at mx4j.log.Log.getLogger(Log.java:178) > >> >> >> >> >> at javax.management.MBeanServerFactory.getLogger > >> >> >> >> >> (MBeanServerFactory.java:34) > >> >> >> >> >> at > >> >> javax.management.MBeanServerFactory.findMBeanServer > >> >> >> >> >> (MBeanServerFactory.java) > >> >> >> >> >> at > >> >> >> >> >> > >> >> org.apache.geronimo.system.jmx.RealMBeanServerReference.<init> > >> >> >> >> >> (RealMBeanServerReference.java:33) > >> >> >> >> >> at > >> java.lang.reflect.VMReflection.newClassInstance > >> >> >> >> >> (VMReflection.java) > >> >> >> >> >> at java.lang.reflect.Constructor.newInstance > >> >> >> >> >> (Constructor.java:298) > >> >> >> >> >> at > >> >> >> >> >> > >> >> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance > >> >> >> >> >> (GBeanInstance.java:921) > >> >> >> >> >> at > >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart > >> >> >> >> >> (GBeanInstanceState.java:263) > >> >> >> >> >> at > >> >> >> >> >> > >> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start > >> >> >> >> >> (GBeanInstanceState.java:99) > >> >> >> >> >> at > >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive > >> >> >> >> >> (GBeanInstanceState.java:120) > >> >> >> >> >> at > >> >> >> >> >> > >> >> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive > >> >> >> >> >> (GBeanInstance.java:542) > >> >> >> >> >> at > >> >> >> >> >> > >> >> >> > >> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean > >> >> >> >> >> (BasicKernel.java:378) > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> I'll start digging through JIRAs, but I thought we had > >> this > >> >> >> >> solved. > >> >> >> >> >> > >> >> >> >> >> geir > >> >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > > -- Sean Qiu
