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. 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 >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >>
