harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [apps] Problem starting Geronimo 1.2 beta
Date Wed, 07 Feb 2007 12:34:54 GMT

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?

geir

>
> Regards,
> Mikhail
>
> On 2/7/07, Geir Magnusson Jr. <geir@pobox.com> 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. <geir@pobox.com> 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. <geir@pobox.com> 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
>> >> >> >
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>


Mime
View raw message