2007/2/8, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
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:[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
