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:[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
