You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2007/02/07 03:00:14 UTC
[apps] Problem starting Geronimo 1.2 beta
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
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Feb 12, 2007, at 12:19 PM, Mikhail Loenko wrote:
> 2007/2/12, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>> On Feb 12, 2007, at 2:13 AM, Mikhail Loenko wrote:
>>
>> > 2007/2/8, Geir Magnusson Jr. <ge...@pobox.com>:
>> >>
>> >> On Feb 8, 2007, at 10:56 AM, Udovichenko, Nellya wrote:
>> >>
>> >> > 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.
>> >>
>> >> Yep - I'm working on a real fix for this and it's almost there.
>> >>
>> >> >
>> >> > 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.
>> >>
>> >> can we simply find a workaround, like implementing JKS?
>> >
>> > I'm afraid we can't. JKS is a Sun's proprietary standard [1]
>>
>> It can't be both proprietary and standard :)
>>
>> Once OpenJDK is open source, we can just reverse engineer it.
>>
>> But since you are the expert - it's a format, right? Is there a
>> common access API? Can we put enough code in place to wrap our
>> implementation?
>
> Sorry, I did not understand the last question
Never mind - I understand. We can't do anything until we can read
the JKS format, or convince Geronimo to do both JKS and PKCS12,
figuring out what works on the JVM they are running on and using
that. Sounds like a pain though.
Grrr.
geir
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by Mikhail Loenko <ml...@gmail.com>.
2007/2/12, Geir Magnusson Jr. <ge...@pobox.com>:
>
> On Feb 12, 2007, at 2:13 AM, Mikhail Loenko wrote:
>
> > 2007/2/8, Geir Magnusson Jr. <ge...@pobox.com>:
> >>
> >> On Feb 8, 2007, at 10:56 AM, Udovichenko, Nellya wrote:
> >>
> >> > 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.
> >>
> >> Yep - I'm working on a real fix for this and it's almost there.
> >>
> >> >
> >> > 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.
> >>
> >> can we simply find a workaround, like implementing JKS?
> >
> > I'm afraid we can't. JKS is a Sun's proprietary standard [1]
>
> It can't be both proprietary and standard :)
>
> Once OpenJDK is open source, we can just reverse engineer it.
>
> But since you are the expert - it's a format, right? Is there a
> common access API? Can we put enough code in place to wrap our
> implementation?
Sorry, I did not understand the last question
Thanks,
Mikhail
>
> geir
>
>
>
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Feb 12, 2007, at 2:13 AM, Mikhail Loenko wrote:
> 2007/2/8, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>> On Feb 8, 2007, at 10:56 AM, Udovichenko, Nellya wrote:
>>
>> > 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.
>>
>> Yep - I'm working on a real fix for this and it's almost there.
>>
>> >
>> > 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.
>>
>> can we simply find a workaround, like implementing JKS?
>
> I'm afraid we can't. JKS is a Sun's proprietary standard [1]
It can't be both proprietary and standard :)
Once OpenJDK is open source, we can just reverse engineer it.
But since you are the expert - it's a format, right? Is there a
common access API? Can we put enough code in place to wrap our
implementation?
geir
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by Mikhail Loenko <ml...@gmail.com>.
2007/2/8, Geir Magnusson Jr. <ge...@pobox.com>:
>
> On Feb 8, 2007, at 10:56 AM, Udovichenko, Nellya wrote:
>
> > 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.
>
> Yep - I'm working on a real fix for this and it's almost there.
>
> >
> > 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.
>
> can we simply find a workaround, like implementing JKS?
I'm afraid we can't. JKS is a Sun's proprietary standard [1]
Thanks,
Mikhail
[1] http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html#KeyManagement
I'm not
> holding my breath here that Geronimo will fix it, and we do want
> older versions of G to run if possible. Also, other code might do
> the same thing.
>
> geir
>
> >
> >
> > Regards,
> > Nellya.
> >
> > -----Original Message-----
> > From: Sean Qiu [mailto:sean.xx.qiu@gmail.com]
> > Sent: Thursday, February 08, 2007 5:18 AM
> > To: dev@harmony.apache.org
> > 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. <ge...@pobox.com>:
> >>
> >>
> >> On Feb 7, 2007, at 7:41 AM, Mikhail Markov wrote:
> >>
> >>> On 2/7/07, Geir Magnusson Jr. <ge...@pobox.com> 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. <ge...@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. <ge...@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. <ge...@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
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
> >
> >
> > --
> > Sean Qiu
>
>
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Feb 8, 2007, at 10:56 AM, Udovichenko, Nellya wrote:
> 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.
Yep - I'm working on a real fix for this and it's almost there.
>
> 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.
can we simply find a workaround, like implementing JKS? I'm not
holding my breath here that Geronimo will fix it, and we do want
older versions of G to run if possible. Also, other code might do
the same thing.
geir
>
>
> Regards,
> Nellya.
>
> -----Original Message-----
> From: Sean Qiu [mailto:sean.xx.qiu@gmail.com]
> Sent: Thursday, February 08, 2007 5:18 AM
> To: dev@harmony.apache.org
> 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. <ge...@pobox.com>:
>>
>>
>> On Feb 7, 2007, at 7:41 AM, Mikhail Markov wrote:
>>
>>> On 2/7/07, Geir Magnusson Jr. <ge...@pobox.com> 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. <ge...@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. <ge...@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. <ge...@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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
>
> --
> Sean Qiu
RE: [apps] Problem starting Geronimo 1.2 beta
Posted by "Udovichenko, Nellya" <ne...@intel.com>.
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:sean.xx.qiu@gmail.com]
Sent: Thursday, February 08, 2007 5:18 AM
To: dev@harmony.apache.org
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. <ge...@pobox.com>:
>
>
> On Feb 7, 2007, at 7:41 AM, Mikhail Markov wrote:
>
> > On 2/7/07, Geir Magnusson Jr. <ge...@pobox.com> 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. <ge...@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. <ge...@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. <ge...@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
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
>
>
--
Sean Qiu
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by Sean Qiu <se...@gmail.com>.
When i run the Geronimo 2.0M2, I encountered the same problem.
2007/2/7, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> On Feb 7, 2007, at 7:41 AM, Mikhail Markov wrote:
>
> > On 2/7/07, Geir Magnusson Jr. <ge...@pobox.com> 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. <ge...@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. <ge...@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. <ge...@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
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
>
>
--
Sean Qiu
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Feb 7, 2007, at 7:41 AM, Mikhail Markov wrote:
> On 2/7/07, Geir Magnusson Jr. <ge...@pobox.com> 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. <ge...@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. <ge...@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. <ge...@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
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by Mikhail Markov <mi...@gmail.com>.
On 2/7/07, Geir Magnusson Jr. <ge...@pobox.com> 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. <ge...@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. <ge...@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. <ge...@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
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
>
>
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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. <ge...@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. <ge...@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. <ge...@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
>> >> >> >
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by Mikhail Markov <mi...@gmail.com>.
> 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.
> 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,
Regards,
Mikhail
On 2/7/07, Geir Magnusson Jr. <ge...@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. <ge...@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. <ge...@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
> >> >> >
> >> >>
> >> >>
> >>
> >>
>
>
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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. <ge...@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. <ge...@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
>> >> >
>> >>
>> >>
>>
>>
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by Mikhail Markov <mi...@gmail.com>.
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.
Regards,
Mikhail
On 2/7/07, Geir Magnusson Jr. <ge...@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. <ge...@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
> >> >
> >>
> >>
>
>
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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. <ge...@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
>> >
>>
>>
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by Mikhail Markov <mi...@gmail.com>.
JFYI: there is also a specific JIRA in Geronimo describing the hardcoded
commons-logging logger: http://issues.apache.org/jira/browse/GERONIMO-2595.
Regards,
Mikhail
On 2/7/07, Geir Magnusson Jr. <ge...@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
> >
>
>
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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
>
Re: [apps] Problem starting Geronimo 1.2 beta
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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