You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2006/09/27 17:11:21 UTC
Is java.endorsed.dirs actually working?
I've been wrestling with a Yoko ORB problem when running under Java 5.
When running on 1.4.2, the Yoko ORB works fine because the native JVM
doesn't include an implementation of
org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no
conflict, the yoko version is getting loaded.
With Sun's Java 5 impl, there is a version of
org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible with
the CORBA standard (and also the Yoko implementation). The Sun version
is getting picked up, cause ORB initialization failures. This is
occurring even though the yoko-spec-corba jar has been copied into
lib/endorsed.
I decided to try an experiment using the jetty-j2ee Geronimo assembly.
I deleted the Xerces jars from the lib/endorsed directory. I did this
to convince myself that the java.endorsed.dirs mechanism was working
correctly and the problem was due to me missing something with the yoko
cofiguration. I expected Geronimo to "fall over" during launch because
of the missing jars. To my surprise, it didn't.
I instrumented one of the yoko classes, and add it load the
IORInterceptor_3_0 class and org.w3c.dom.Element and dump the package
information for these classes. The Package information indicates both
of these classes are resolving to the JVM native versions rather than
the versions in lib/endorsed. The java.endorsed.dirs appears to be set
to the correct value, and the jar files are in the appropriate
directory, but the classes don't appear to be getting picked up.
This was just the last experiment for a problem I've been chasing since
Monday. I'm getting extremely inconsistent results from using
java.endorsed.dirs. Right now, I have 4 situations in front of me:
1) Simple standalone test case using Yoko ORB.
2) Yoko unit tests using surefire plugin.
3) Openejb Yoko unit tests using surefile plugin (setup was copied from
the Yoko unit tests).
4) Full Geronimo assembly using the Yoko ORB.
When running under Java 5, 1) and 2) work ok. 3) fails, even though the
surefile tests (in theory) are running exactly the same way as 2). 4)
also fails. 1), 3), and 4) all work fine under Java 1.4.2, but there's
no conflict with the native IORInterceptor_3_0 class is that scenario.
I spent most of yesterday wrestling with scenario 3), and never getting
it to work. Like scenario 4), the jar files are in the target endorsed
directory and the java.endorsed.dirs is pointing to the correct
location. Right now, I'm completely stumped, and I'm wondering if this
has every really worked in the Geronimo assembly.
Rick
Re: Is java.endorsed.dirs actually working?
Posted by Heinz Drews <he...@gmail.com>.
-Djava.endorsed.dirs is interpreted during the construction of the
bootstrap classpath.
Setting it in a Java class does not have an effect for the current JVM.
Daemon.java would have to spawn a new process and start another JVM
passing the property.
Heinz
On 9/27/06, Rick McGuire <ri...@gmail.com> wrote:
> Ok, I've got it working 4-for-4 now, and I was right, it IS broken in
> Geronimo right now. The missing piece is the -Djava.endorsed.dirs on
> the commandline. It appears that setting this value in Daemon.java
> won't work. It needs to be set on the commandline.
>
> Rick
>
>
> David Jencks wrote:
> >
> > On Sep 27, 2006, at 8:11 AM, Rick McGuire wrote:
> >
> >> I've been wrestling with a Yoko ORB problem when running under Java
> >> 5. When running on 1.4.2, the Yoko ORB works fine because the native
> >> JVM doesn't include an implementation of
> >> org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no
> >> conflict, the yoko version is getting loaded.
> >> With Sun's Java 5 impl, there is a version of
> >> org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible
> >> with the CORBA standard (and also the Yoko implementation). The Sun
> >> version is getting picked up, cause ORB initialization failures.
> >> This is occurring even though the yoko-spec-corba jar has been copied
> >> into lib/endorsed.
> >>
> >> I decided to try an experiment using the jetty-j2ee Geronimo
> >> assembly. I deleted the Xerces jars from the lib/endorsed
> >> directory. I did this to convince myself that the java.endorsed.dirs
> >> mechanism was working correctly and the problem was due to me missing
> >> something with the yoko cofiguration. I expected Geronimo to "fall
> >> over" during launch because of the missing jars. To my surprise, it
> >> didn't.
> >> I instrumented one of the yoko classes, and add it load the
> >> IORInterceptor_3_0 class and org.w3c.dom.Element and dump the package
> >> information for these classes. The Package information indicates
> >> both of these classes are resolving to the JVM native versions rather
> >> than the versions in lib/endorsed. The java.endorsed.dirs appears to
> >> be set to the correct value, and the jar files are in the appropriate
> >> directory, but the classes don't appear to be getting picked up.
> >>
> >> This was just the last experiment for a problem I've been chasing
> >> since Monday. I'm getting extremely inconsistent results from using
> >> java.endorsed.dirs. Right now, I have 4 situations in front of me:
> >>
> >> 1) Simple standalone test case using Yoko ORB.
> >> 2) Yoko unit tests using surefire plugin.
> >> 3) Openejb Yoko unit tests using surefile plugin (setup was copied
> >> from the Yoko unit tests).
> >> 4) Full Geronimo assembly using the Yoko ORB.
> >>
> >> When running under Java 5, 1) and 2) work ok. 3) fails, even though
> >> the surefile tests (in theory) are running exactly the same way as
> >> 2). 4) also fails. 1), 3), and 4) all work fine under Java 1.4.2,
> >> but there's no conflict with the native IORInterceptor_3_0 class is
> >> that scenario. I spent most of yesterday wrestling with scenario 3),
> >> and never getting it to work. Like scenario 4), the jar files are in
> >> the target endorsed directory and the java.endorsed.dirs is pointing
> >> to the correct location. Right now, I'm completely stumped, and I'm
> >> wondering if this has every really worked in the Geronimo assembly.
> >
> > I have often wondered if our endorsed dir actually worked also... it's
> > always seemed somewhat unlikely :-)
> >
> > How is the endorsed dir set for 2) and 3), and how does the yoko jar
> > get onto the classpath?
> >
> > Does 2) involve an actual yoko jar or does it run off of unjarred
> > classes?
> >
> > Is anything different in esp. 4) if you set the endorsed dir on the
> > command line rather than letting geronimo set it after the jvm has
> > started more?
> >
> > thanks
> > david jencks
> >
> >
> >
> >>
> >> Rick
> >>
> >>
> >
> >
>
>
Re: Is java.endorsed.dirs actually working?
Posted by Rick McGuire <ri...@gmail.com>.
Ok, I've got it working 4-for-4 now, and I was right, it IS broken in
Geronimo right now. The missing piece is the -Djava.endorsed.dirs on
the commandline. It appears that setting this value in Daemon.java
won't work. It needs to be set on the commandline.
Rick
David Jencks wrote:
>
> On Sep 27, 2006, at 8:11 AM, Rick McGuire wrote:
>
>> I've been wrestling with a Yoko ORB problem when running under Java
>> 5. When running on 1.4.2, the Yoko ORB works fine because the native
>> JVM doesn't include an implementation of
>> org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no
>> conflict, the yoko version is getting loaded.
>> With Sun's Java 5 impl, there is a version of
>> org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible
>> with the CORBA standard (and also the Yoko implementation). The Sun
>> version is getting picked up, cause ORB initialization failures.
>> This is occurring even though the yoko-spec-corba jar has been copied
>> into lib/endorsed.
>>
>> I decided to try an experiment using the jetty-j2ee Geronimo
>> assembly. I deleted the Xerces jars from the lib/endorsed
>> directory. I did this to convince myself that the java.endorsed.dirs
>> mechanism was working correctly and the problem was due to me missing
>> something with the yoko cofiguration. I expected Geronimo to "fall
>> over" during launch because of the missing jars. To my surprise, it
>> didn't.
>> I instrumented one of the yoko classes, and add it load the
>> IORInterceptor_3_0 class and org.w3c.dom.Element and dump the package
>> information for these classes. The Package information indicates
>> both of these classes are resolving to the JVM native versions rather
>> than the versions in lib/endorsed. The java.endorsed.dirs appears to
>> be set to the correct value, and the jar files are in the appropriate
>> directory, but the classes don't appear to be getting picked up.
>>
>> This was just the last experiment for a problem I've been chasing
>> since Monday. I'm getting extremely inconsistent results from using
>> java.endorsed.dirs. Right now, I have 4 situations in front of me:
>>
>> 1) Simple standalone test case using Yoko ORB.
>> 2) Yoko unit tests using surefire plugin.
>> 3) Openejb Yoko unit tests using surefile plugin (setup was copied
>> from the Yoko unit tests).
>> 4) Full Geronimo assembly using the Yoko ORB.
>>
>> When running under Java 5, 1) and 2) work ok. 3) fails, even though
>> the surefile tests (in theory) are running exactly the same way as
>> 2). 4) also fails. 1), 3), and 4) all work fine under Java 1.4.2,
>> but there's no conflict with the native IORInterceptor_3_0 class is
>> that scenario. I spent most of yesterday wrestling with scenario 3),
>> and never getting it to work. Like scenario 4), the jar files are in
>> the target endorsed directory and the java.endorsed.dirs is pointing
>> to the correct location. Right now, I'm completely stumped, and I'm
>> wondering if this has every really worked in the Geronimo assembly.
>
> I have often wondered if our endorsed dir actually worked also... it's
> always seemed somewhat unlikely :-)
>
> How is the endorsed dir set for 2) and 3), and how does the yoko jar
> get onto the classpath?
>
> Does 2) involve an actual yoko jar or does it run off of unjarred
> classes?
>
> Is anything different in esp. 4) if you set the endorsed dir on the
> command line rather than letting geronimo set it after the jvm has
> started more?
>
> thanks
> david jencks
>
>
>
>>
>> Rick
>>
>>
>
>
Re: Is java.endorsed.dirs actually working?
Posted by Rick McGuire <ri...@gmail.com>.
David Jencks wrote:
>
> On Sep 27, 2006, at 8:11 AM, Rick McGuire wrote:
>
>> I've been wrestling with a Yoko ORB problem when running under Java
>> 5. When running on 1.4.2, the Yoko ORB works fine because the native
>> JVM doesn't include an implementation of
>> org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no
>> conflict, the yoko version is getting loaded.
>> With Sun's Java 5 impl, there is a version of
>> org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible
>> with the CORBA standard (and also the Yoko implementation). The Sun
>> version is getting picked up, cause ORB initialization failures.
>> This is occurring even though the yoko-spec-corba jar has been copied
>> into lib/endorsed.
>>
>> I decided to try an experiment using the jetty-j2ee Geronimo
>> assembly. I deleted the Xerces jars from the lib/endorsed
>> directory. I did this to convince myself that the java.endorsed.dirs
>> mechanism was working correctly and the problem was due to me missing
>> something with the yoko cofiguration. I expected Geronimo to "fall
>> over" during launch because of the missing jars. To my surprise, it
>> didn't.
>> I instrumented one of the yoko classes, and add it load the
>> IORInterceptor_3_0 class and org.w3c.dom.Element and dump the package
>> information for these classes. The Package information indicates
>> both of these classes are resolving to the JVM native versions rather
>> than the versions in lib/endorsed. The java.endorsed.dirs appears to
>> be set to the correct value, and the jar files are in the appropriate
>> directory, but the classes don't appear to be getting picked up.
>>
>> This was just the last experiment for a problem I've been chasing
>> since Monday. I'm getting extremely inconsistent results from using
>> java.endorsed.dirs. Right now, I have 4 situations in front of me:
>>
>> 1) Simple standalone test case using Yoko ORB.
>> 2) Yoko unit tests using surefire plugin.
>> 3) Openejb Yoko unit tests using surefile plugin (setup was copied
>> from the Yoko unit tests).
>> 4) Full Geronimo assembly using the Yoko ORB.
>>
>> When running under Java 5, 1) and 2) work ok. 3) fails, even though
>> the surefile tests (in theory) are running exactly the same way as
>> 2). 4) also fails. 1), 3), and 4) all work fine under Java 1.4.2,
>> but there's no conflict with the native IORInterceptor_3_0 class is
>> that scenario. I spent most of yesterday wrestling with scenario 3),
>> and never getting it to work. Like scenario 4), the jar files are in
>> the target endorsed directory and the java.endorsed.dirs is pointing
>> to the correct location. Right now, I'm completely stumped, and I'm
>> wondering if this has every really worked in the Geronimo assembly.
>
> I have often wondered if our endorsed dir actually worked also... it's
> always seemed somewhat unlikely :-)
>
> How is the endorsed dir set for 2) and 3), and how does the yoko jar
> get onto the classpath?
Let me give you an indirect answer here by first answering the question
for 1). My experiments with the simple test case show that if you set
java.endorsed.jars, then all of the jar files in the reference
directories are automatically part of the classpath (or more
appropriately, the bootclasspath). They function as if you had
prepended the jars to the bootclasspath. The resolved class have the
"null" classloader.
The endorsed dir is set for 2) and 3) by setting the system property in
the surefire plugin definition.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<includes>
<include
implementation="java.lang.String">**/org/apache/yoko/*Test.java</include>
</includes>
<systemProperties>
<property>
<name>java.endorsed.dirs</name>
<value>${basedir}/target/endorsed</value>
</property>
</systemProperties>
</configuration>
</plugin>
The jar files are copied to the endorsed dir using the dependency plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.apache.yoko</groupId>
<artifactId>yoko-spec-corba</artifactId>
<type>jar</type>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/endorsed</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
The jar files also are ending up on the classpath by virtue of the
dependencies, but my experiments with 1) suggest this shouldn't be
necessary, and the classes in the endorsed dir should be picked up instead.
>
> Does 2) involve an actual yoko jar or does it run off of unjarred
> classes?
A 4 of these are using the same version of the yoko jar file.
>
> Is anything different in esp. 4) if you set the endorsed dir on the
> command line rather than letting geronimo set it after the jvm has
> started more?
I haven't tried that experiment yet. I'll try hacking something up.
>
> thanks
> david jencks
>
>
>
>>
>> Rick
>>
>>
>
>
Re: Is java.endorsed.dirs actually working?
Posted by David Jencks <da...@yahoo.com>.
On Sep 27, 2006, at 8:11 AM, Rick McGuire wrote:
> I've been wrestling with a Yoko ORB problem when running under Java
> 5. When running on 1.4.2, the Yoko ORB works fine because the
> native JVM doesn't include an implementation of
> org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no
> conflict, the yoko version is getting loaded.
> With Sun's Java 5 impl, there is a version of
> org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible
> with the CORBA standard (and also the Yoko implementation). The
> Sun version is getting picked up, cause ORB initialization
> failures. This is occurring even though the yoko-spec-corba jar
> has been copied into lib/endorsed.
>
> I decided to try an experiment using the jetty-j2ee Geronimo
> assembly. I deleted the Xerces jars from the lib/endorsed
> directory. I did this to convince myself that the
> java.endorsed.dirs mechanism was working correctly and the problem
> was due to me missing something with the yoko cofiguration. I
> expected Geronimo to "fall over" during launch because of the
> missing jars. To my surprise, it didn't.
> I instrumented one of the yoko classes, and add it load the
> IORInterceptor_3_0 class and org.w3c.dom.Element and dump the
> package information for these classes. The Package information
> indicates both of these classes are resolving to the JVM native
> versions rather than the versions in lib/endorsed. The
> java.endorsed.dirs appears to be set to the correct value, and the
> jar files are in the appropriate directory, but the classes don't
> appear to be getting picked up.
>
> This was just the last experiment for a problem I've been chasing
> since Monday. I'm getting extremely inconsistent results from
> using java.endorsed.dirs. Right now, I have 4 situations in front
> of me:
>
> 1) Simple standalone test case using Yoko ORB.
> 2) Yoko unit tests using surefire plugin.
> 3) Openejb Yoko unit tests using surefile plugin (setup was copied
> from the Yoko unit tests).
> 4) Full Geronimo assembly using the Yoko ORB.
>
> When running under Java 5, 1) and 2) work ok. 3) fails, even
> though the surefile tests (in theory) are running exactly the same
> way as 2). 4) also fails. 1), 3), and 4) all work fine under Java
> 1.4.2, but there's no conflict with the native IORInterceptor_3_0
> class is that scenario. I spent most of yesterday wrestling with
> scenario 3), and never getting it to work. Like scenario 4), the
> jar files are in the target endorsed directory and the
> java.endorsed.dirs is pointing to the correct location. Right now,
> I'm completely stumped, and I'm wondering if this has every really
> worked in the Geronimo assembly.
I have often wondered if our endorsed dir actually worked also...
it's always seemed somewhat unlikely :-)
How is the endorsed dir set for 2) and 3), and how does the yoko jar
get onto the classpath?
Does 2) involve an actual yoko jar or does it run off of unjarred
classes?
Is anything different in esp. 4) if you set the endorsed dir on the
command line rather than letting geronimo set it after the jvm has
started more?
thanks
david jencks
>
> Rick
>
>
Re: Is java.endorsed.dirs actually working?
Posted by Rick McGuire <ri...@gmail.com>.
Dain Sundstrom wrote:
> There is a lot of text here and I'm a bit confused. FWIU, to use the
> trick we used in bootstrap you need the following:
>
> 1) add your endorsed jars to the manifest class path
> 2) no code accessed during the boot process can reference an endorsed
> package
> 3) modify the endorsed system property
> 4) use reflection to load a class that accesses the endorsed class
> (this may have to happen in a child class loader)
That's not the behavior I'm seeing in any of the experiments I've seen.
The directories searched for endorsed appear to be fixed at JVM boot
time, so Geronimo's additions to java.endorsed.dirs in Daemon were
having no effect. I tested this with both the yoko-spec-corba jar and
the Xerces XML specs. In both cases, I was getting the JVM native
classes. In order to get this working correctly, I set GERONIMO_OPTS to
-Djava.endorsed.dirs=C:/..../lib/endorsed. Once that was set, the
correct classes were getting returned. I saw the same behavior from
some simple tests I coded up.
Rick
>
> I have high confidence in this process due to the tck passing.
> Additionally, I received a customer complaint that we were overriding
> the xml processor on Java5 with the older spec version included with
> Geronimo. Now it may turn out that this magic only works with the xml
> specs, but I'd be very surprised.
>
> -dain
>
> On Sep 27, 2006, at 8:11 AM, Rick McGuire wrote:
>
>> I've been wrestling with a Yoko ORB problem when running under Java
>> 5. When running on 1.4.2, the Yoko ORB works fine because the native
>> JVM doesn't include an implementation of
>> org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no
>> conflict, the yoko version is getting loaded.
>> With Sun's Java 5 impl, there is a version of
>> org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible
>> with the CORBA standard (and also the Yoko implementation). The Sun
>> version is getting picked up, cause ORB initialization failures.
>> This is occurring even though the yoko-spec-corba jar has been copied
>> into lib/endorsed.
>>
>> I decided to try an experiment using the jetty-j2ee Geronimo
>> assembly. I deleted the Xerces jars from the lib/endorsed
>> directory. I did this to convince myself that the java.endorsed.dirs
>> mechanism was working correctly and the problem was due to me missing
>> something with the yoko cofiguration. I expected Geronimo to "fall
>> over" during launch because of the missing jars. To my surprise, it
>> didn't.
>> I instrumented one of the yoko classes, and add it load the
>> IORInterceptor_3_0 class and org.w3c.dom.Element and dump the package
>> information for these classes. The Package information indicates
>> both of these classes are resolving to the JVM native versions rather
>> than the versions in lib/endorsed. The java.endorsed.dirs appears to
>> be set to the correct value, and the jar files are in the appropriate
>> directory, but the classes don't appear to be getting picked up.
>>
>> This was just the last experiment for a problem I've been chasing
>> since Monday. I'm getting extremely inconsistent results from using
>> java.endorsed.dirs. Right now, I have 4 situations in front of me:
>>
>> 1) Simple standalone test case using Yoko ORB.
>> 2) Yoko unit tests using surefire plugin.
>> 3) Openejb Yoko unit tests using surefile plugin (setup was copied
>> from the Yoko unit tests).
>> 4) Full Geronimo assembly using the Yoko ORB.
>>
>> When running under Java 5, 1) and 2) work ok. 3) fails, even though
>> the surefile tests (in theory) are running exactly the same way as
>> 2). 4) also fails. 1), 3), and 4) all work fine under Java 1.4.2,
>> but there's no conflict with the native IORInterceptor_3_0 class is
>> that scenario. I spent most of yesterday wrestling with scenario 3),
>> and never getting it to work. Like scenario 4), the jar files are in
>> the target endorsed directory and the java.endorsed.dirs is pointing
>> to the correct location. Right now, I'm completely stumped, and I'm
>> wondering if this has every really worked in the Geronimo assembly.
>>
>> Rick
>>
>
>
Re: Is java.endorsed.dirs actually working?
Posted by Dain Sundstrom <da...@iq80.com>.
There is a lot of text here and I'm a bit confused. FWIU, to use the
trick we used in bootstrap you need the following:
1) add your endorsed jars to the manifest class path
2) no code accessed during the boot process can reference an endorsed
package
3) modify the endorsed system property
4) use reflection to load a class that accesses the endorsed class
(this may have to happen in a child class loader)
I have high confidence in this process due to the tck passing.
Additionally, I received a customer complaint that we were overriding
the xml processor on Java5 with the older spec version included with
Geronimo. Now it may turn out that this magic only works with the
xml specs, but I'd be very surprised.
-dain
On Sep 27, 2006, at 8:11 AM, Rick McGuire wrote:
> I've been wrestling with a Yoko ORB problem when running under Java
> 5. When running on 1.4.2, the Yoko ORB works fine because the
> native JVM doesn't include an implementation of
> org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no
> conflict, the yoko version is getting loaded.
> With Sun's Java 5 impl, there is a version of
> org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible
> with the CORBA standard (and also the Yoko implementation). The
> Sun version is getting picked up, cause ORB initialization
> failures. This is occurring even though the yoko-spec-corba jar
> has been copied into lib/endorsed.
>
> I decided to try an experiment using the jetty-j2ee Geronimo
> assembly. I deleted the Xerces jars from the lib/endorsed
> directory. I did this to convince myself that the
> java.endorsed.dirs mechanism was working correctly and the problem
> was due to me missing something with the yoko cofiguration. I
> expected Geronimo to "fall over" during launch because of the
> missing jars. To my surprise, it didn't.
> I instrumented one of the yoko classes, and add it load the
> IORInterceptor_3_0 class and org.w3c.dom.Element and dump the
> package information for these classes. The Package information
> indicates both of these classes are resolving to the JVM native
> versions rather than the versions in lib/endorsed. The
> java.endorsed.dirs appears to be set to the correct value, and the
> jar files are in the appropriate directory, but the classes don't
> appear to be getting picked up.
>
> This was just the last experiment for a problem I've been chasing
> since Monday. I'm getting extremely inconsistent results from
> using java.endorsed.dirs. Right now, I have 4 situations in front
> of me:
>
> 1) Simple standalone test case using Yoko ORB.
> 2) Yoko unit tests using surefire plugin.
> 3) Openejb Yoko unit tests using surefile plugin (setup was copied
> from the Yoko unit tests).
> 4) Full Geronimo assembly using the Yoko ORB.
>
> When running under Java 5, 1) and 2) work ok. 3) fails, even
> though the surefile tests (in theory) are running exactly the same
> way as 2). 4) also fails. 1), 3), and 4) all work fine under Java
> 1.4.2, but there's no conflict with the native IORInterceptor_3_0
> class is that scenario. I spent most of yesterday wrestling with
> scenario 3), and never getting it to work. Like scenario 4), the
> jar files are in the target endorsed directory and the
> java.endorsed.dirs is pointing to the correct location. Right now,
> I'm completely stumped, and I'm wondering if this has every really
> worked in the Geronimo assembly.
>
> Rick
>
Re: Is java.endorsed.dirs actually working?
Posted by anita kulshreshtha <a_...@yahoo.com>.
Here is the 5th one:
As you said the java.endorsed.dirs property is being set properly.
but we still had to add lib/endorsed to the class path explicitly. It
might be due to the fact that it is checked before the jvm is forked.
Did you try starting the server using -Djava.endorsed.dirs=....? I have
no clues why it does not work, just shooting in the dark..
Thanks
Anita
--- Rick McGuire <ri...@gmail.com> wrote:
> I've been wrestling with a Yoko ORB problem when running under Java
> 5.
> When running on 1.4.2, the Yoko ORB works fine because the native JVM
>
> doesn't include an implementation of
> org.omg.PortableInterceptor.IORInterceptor_3_0. Because there's no
> conflict, the yoko version is getting loaded.
>
> With Sun's Java 5 impl, there is a version of
> org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible
> with
> the CORBA standard (and also the Yoko implementation). The Sun
> version
> is getting picked up, cause ORB initialization failures. This is
> occurring even though the yoko-spec-corba jar has been copied into
> lib/endorsed.
>
> I decided to try an experiment using the jetty-j2ee Geronimo
> assembly.
> I deleted the Xerces jars from the lib/endorsed directory. I did
> this
> to convince myself that the java.endorsed.dirs mechanism was working
> correctly and the problem was due to me missing something with the
> yoko
> cofiguration. I expected Geronimo to "fall over" during launch
> because
> of the missing jars. To my surprise, it didn't.
>
> I instrumented one of the yoko classes, and add it load the
> IORInterceptor_3_0 class and org.w3c.dom.Element and dump the package
>
> information for these classes. The Package information indicates
> both
> of these classes are resolving to the JVM native versions rather than
>
> the versions in lib/endorsed. The java.endorsed.dirs appears to be
> set
> to the correct value, and the jar files are in the appropriate
> directory, but the classes don't appear to be getting picked up.
>
> This was just the last experiment for a problem I've been chasing
> since
> Monday. I'm getting extremely inconsistent results from using
> java.endorsed.dirs. Right now, I have 4 situations in front of me:
>
> 1) Simple standalone test case using Yoko ORB.
> 2) Yoko unit tests using surefire plugin.
> 3) Openejb Yoko unit tests using surefile plugin (setup was copied
> from
> the Yoko unit tests).
> 4) Full Geronimo assembly using the Yoko ORB.
>
> When running under Java 5, 1) and 2) work ok. 3) fails, even though
> the
> surefile tests (in theory) are running exactly the same way as 2).
> 4)
> also fails. 1), 3), and 4) all work fine under Java 1.4.2, but
> there's
> no conflict with the native IORInterceptor_3_0 class is that
> scenario.
> I spent most of yesterday wrestling with scenario 3), and never
> getting
> it to work. Like scenario 4), the jar files are in the target
> endorsed
> directory and the java.endorsed.dirs is pointing to the correct
> location. Right now, I'm completely stumped, and I'm wondering if
> this
> has every really worked in the Geronimo assembly.
>
> Rick
>
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Is java.endorsed.dirs actually working?
Posted by anita kulshreshtha <a_...@yahoo.com>.
--- David Jencks <da...@yahoo.com> wrote:
>
> On Sep 28, 2006, at 8:07 AM, anita kulshreshtha wrote:
>
> >
> >
> > --- Rick McGuire <ri...@gmail.com> wrote:
> >
> >>
> >> I decided to try an experiment using the jetty-j2ee Geronimo
> >> assembly.
> >> I deleted the Xerces jars from the lib/endorsed directory. I did
> >> this
> >> to convince myself that the java.endorsed.dirs mechanism was
> working
> >> correctly and the problem was due to me missing something with the
> >> yoko
> >> cofiguration. I expected Geronimo to "fall over" during launch
> >> because
> >> of the missing jars. To my surprise, it didn't.
> > I deleted xerces dir from the repository and the startup
> failed.
> > You are correct in saying that the jars from lib/endorsed are not
> > being
> > used. Now I am wondering how are the jars from the G repository
> being
> > used. Are they really being used?
>
> Well, the copies of xerces etc in lib/endorsed are in the server.jar
>
> manifest classpath so even if they aren't really "endorsed" they are
>
> at least on the classpath. The exception you see is from us checking
>
> that the jars we claim we want are really available where we say they
>
> are -- something the manifest cp doesn't do. In particular the
> exception you see comes before a configuration classloader that is
> expected to contain the dependency is constructed.
>
> However, it looks to me as if your server startup is starting client-
>
> system. This is a serious problem if true. Have you made any local
>
> modifications to cause this or is it happening with a server built
> straight from svn?
I noticed that too.. This is with rev 449705. I did a full build
yesterday. I looked at the working console, i.e. with xerces. The list
given by 'System Modules' is correct and lists client-system as
stopped.
Thanks
Anita
>
> thanks
> david jencks
>
> >
> > Thanks
> > Anita
> >
> > Booting Geronimo Kernel (in Java 1.4.2_12)...
> > Starting Geronimo Application Server v1.2-SNAPSHOT
> > [********> ] 36% 9s Starting
> > org.apache.geronimo.co...10:47:16,625 INFO [
> > BrokerService] ActiveMQ 4.1-incubator-SNAPSHOT JMS Message Broker
> > (possibly-unique-broker)
> > is starting
> > 10:47:16,625 INFO [BrokerService] For help or more information
> please
> > see: http://incubat
> > or.apache.org/activemq/
> > 10:47:16,687 INFO [ManagementContext] JMX consoles can connect to
> > service:jmx:rmi://your-
> > 4dacd0ea75/jndi/rmi://localhost:1099/jmxrmi
> > [********> ] 36% 9s Starting
> > org.apache.geronimo.co...10:47:16,781 INFO [
> > JDBCPersistenceAdapter] Database driver recognized:
> > [apache_derby_embedded_jdbc_driver]
> > [********> ] 36% 11s Starting
> > org.apache.geronimo.co...10:47:18,015 INFO [
> > DefaultDatabaseLocker] Attempting to acquire the exclusive lock to
> > become the Master broke
> > r
> > 10:47:18,015 INFO [DefaultDatabaseLocker] Becoming the master on
> > dataSource: org.tranql.c
> > onnector.jdbc.DataSource@4ef122
> > 10:47:18,125 INFO [JournalPersistenceAdapter] Journal Recovery
> > Started
> > from: Active Journ
> > al: using 2 x 20.0 Megs at:
> > C:\anita\geronimo\geronimo-tomcat-j2ee-1.2-SNAPSHOT\activemq-d
> > ata\possibly-unique-broker\journal
> > 10:47:18,187 INFO [JournalPersistenceAdapter] Journal Recovered: 0
> > message(s) in transact
> > ions recovered.
> > [********> ] 36% 11s Starting
> > org.apache.geronimo.co...10:47:18,406 INFO [
> > BrokerService] ActiveMQ JMS Message Broker (possibly-unique-broker,
> > ID:your-4dacd0ea75-139
> > 9-1159454836203-1:0) started
> > 10:47:18,468 INFO [TransportConnector] Connector vm://localhost
> > Started
> > 10:47:18,515 INFO [TransportServerThreadSupport] Listening for
> > connections at: stomp://yo
> > ur-4dacd0ea75:61613
> > 10:47:18,515 INFO [TransportConnector] Connector
> > stomp://your-4dacd0ea75:61613 Started
> > 10:47:18,531 INFO [TransportServerThreadSupport] Listening for
> > connections at: tcp://0.0.
> > 0.0:61616
> > 10:47:18,531 INFO [TransportConnector] Connector
> tcp://0.0.0.0:61616
> > Started
> > [***************- ] 62% 18s Loading
> > org.apache.geronimo.co...10:47:25,078 ERROR [
> > GBeanInstanceState] Error while starting; GBean is now in the
> FAILED
> > state: abstractName="
> > org.apache.geronimo.configs/client-system/1.2-SNAPSHOT/car?
> > configurationName=org.apache.ge
> > ronimo.configs/client-system/1.2-SNAPSHOT/car"
> > org.apache.geronimo.kernel.repository.MissingDependencyException:
> > Unable to resolve depend
> > ency xerces/xercesImpl/2.6.2/jar
> > at
> > org.apache.geronimo.kernel.config.ConfigurationResolver.resolve
> > (ConfigurationRe
> > solver.java:112)
> > at
> > org.apache.geronimo.kernel.config.Configuration.buildClassPath
> > (Configuration.ja
> > va:397)
> > at
> >
>
org.apache.geronimo.kernel.config.Configuration.createConfigurationCla
>
> > sssLoader
> > (Configuration.java:322)
> > at
> > org.apache.geronimo.kernel.config.Configuration.<init>
> > (Configuration.java:267)
> > at
> > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> > at
> > sun.reflect.NativeConstructorAccessorImpl.newInstance
> > (NativeConstructorAccessor
> > Impl.java:39)
> > at
> > sun.reflect.DelegatingConstructorAccessorImpl.newInstance
> > (DelegatingConstructor
> > AccessorImpl.java:27)
> > at
> > java.lang.reflect.Constructor.newInstance(Constructor.java:274)
> > at
> > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance
> > (GBeanInstance.ja
> > va:936)
> > at
> >
>
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(
>
> > GBeanInst
> > anceState.java:267)
> > at
> > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start
> > (GBeanInstanceState.j
> > ava:102)
> > at
> > org.apache.geronimo.gbean.runtime.GBeanInstance.start
> > (GBeanInstance.java:529)
> > at
> > org.apache.geronimo.kernel.basic.BasicKernel.startGBean
> > (BasicKernel.java:361)
> > at
> > org.apache.geronimo.kernel.config.KernelConfigurationManager.load
> > (KernelConfigu
> > rationManager.java:161)
> > at
> >
>
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi
>
> > guration(
> > SimpleConfigurationManager.java:307)
> > at
> >
>
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi
>
> > guration(
> > SimpleConfigurationManager.java:275)
> > at
> >
>
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi
>
> > guration(
> > SimpleConfigurationManager.java:250)
> > at
> >
>
org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfi
>
> > guration(
> > KernelConfigurationManager.java:112)
> > at
> > org.apache.geronimo.kernel.config.KernelConfigurationManager$
> > $FastClassByCGLIB$
> > $b117102f.invoke(<generated>)
> > at
> net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Is java.endorsed.dirs actually working?
Posted by David Jencks <da...@yahoo.com>.
On Sep 28, 2006, at 8:07 AM, anita kulshreshtha wrote:
>
>
> --- Rick McGuire <ri...@gmail.com> wrote:
>
>>
>> I decided to try an experiment using the jetty-j2ee Geronimo
>> assembly.
>> I deleted the Xerces jars from the lib/endorsed directory. I did
>> this
>> to convince myself that the java.endorsed.dirs mechanism was working
>> correctly and the problem was due to me missing something with the
>> yoko
>> cofiguration. I expected Geronimo to "fall over" during launch
>> because
>> of the missing jars. To my surprise, it didn't.
> I deleted xerces dir from the repository and the startup failed.
> You are correct in saying that the jars from lib/endorsed are not
> being
> used. Now I am wondering how are the jars from the G repository being
> used. Are they really being used?
Well, the copies of xerces etc in lib/endorsed are in the server.jar
manifest classpath so even if they aren't really "endorsed" they are
at least on the classpath. The exception you see is from us checking
that the jars we claim we want are really available where we say they
are -- something the manifest cp doesn't do. In particular the
exception you see comes before a configuration classloader that is
expected to contain the dependency is constructed.
However, it looks to me as if your server startup is starting client-
system. This is a serious problem if true. Have you made any local
modifications to cause this or is it happening with a server built
straight from svn?
thanks
david jencks
>
> Thanks
> Anita
>
> Booting Geronimo Kernel (in Java 1.4.2_12)...
> Starting Geronimo Application Server v1.2-SNAPSHOT
> [********> ] 36% 9s Starting
> org.apache.geronimo.co...10:47:16,625 INFO [
> BrokerService] ActiveMQ 4.1-incubator-SNAPSHOT JMS Message Broker
> (possibly-unique-broker)
> is starting
> 10:47:16,625 INFO [BrokerService] For help or more information please
> see: http://incubat
> or.apache.org/activemq/
> 10:47:16,687 INFO [ManagementContext] JMX consoles can connect to
> service:jmx:rmi://your-
> 4dacd0ea75/jndi/rmi://localhost:1099/jmxrmi
> [********> ] 36% 9s Starting
> org.apache.geronimo.co...10:47:16,781 INFO [
> JDBCPersistenceAdapter] Database driver recognized:
> [apache_derby_embedded_jdbc_driver]
> [********> ] 36% 11s Starting
> org.apache.geronimo.co...10:47:18,015 INFO [
> DefaultDatabaseLocker] Attempting to acquire the exclusive lock to
> become the Master broke
> r
> 10:47:18,015 INFO [DefaultDatabaseLocker] Becoming the master on
> dataSource: org.tranql.c
> onnector.jdbc.DataSource@4ef122
> 10:47:18,125 INFO [JournalPersistenceAdapter] Journal Recovery
> Started
> from: Active Journ
> al: using 2 x 20.0 Megs at:
> C:\anita\geronimo\geronimo-tomcat-j2ee-1.2-SNAPSHOT\activemq-d
> ata\possibly-unique-broker\journal
> 10:47:18,187 INFO [JournalPersistenceAdapter] Journal Recovered: 0
> message(s) in transact
> ions recovered.
> [********> ] 36% 11s Starting
> org.apache.geronimo.co...10:47:18,406 INFO [
> BrokerService] ActiveMQ JMS Message Broker (possibly-unique-broker,
> ID:your-4dacd0ea75-139
> 9-1159454836203-1:0) started
> 10:47:18,468 INFO [TransportConnector] Connector vm://localhost
> Started
> 10:47:18,515 INFO [TransportServerThreadSupport] Listening for
> connections at: stomp://yo
> ur-4dacd0ea75:61613
> 10:47:18,515 INFO [TransportConnector] Connector
> stomp://your-4dacd0ea75:61613 Started
> 10:47:18,531 INFO [TransportServerThreadSupport] Listening for
> connections at: tcp://0.0.
> 0.0:61616
> 10:47:18,531 INFO [TransportConnector] Connector tcp://0.0.0.0:61616
> Started
> [***************- ] 62% 18s Loading
> org.apache.geronimo.co...10:47:25,078 ERROR [
> GBeanInstanceState] Error while starting; GBean is now in the FAILED
> state: abstractName="
> org.apache.geronimo.configs/client-system/1.2-SNAPSHOT/car?
> configurationName=org.apache.ge
> ronimo.configs/client-system/1.2-SNAPSHOT/car"
> org.apache.geronimo.kernel.repository.MissingDependencyException:
> Unable to resolve depend
> ency xerces/xercesImpl/2.6.2/jar
> at
> org.apache.geronimo.kernel.config.ConfigurationResolver.resolve
> (ConfigurationRe
> solver.java:112)
> at
> org.apache.geronimo.kernel.config.Configuration.buildClassPath
> (Configuration.ja
> va:397)
> at
> org.apache.geronimo.kernel.config.Configuration.createConfigurationCla
> sssLoader
> (Configuration.java:322)
> at
> org.apache.geronimo.kernel.config.Configuration.<init>
> (Configuration.java:267)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessor
> Impl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructor
> AccessorImpl.java:27)
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:274)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance
> (GBeanInstance.ja
> va:936)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(
> GBeanInst
> anceState.java:267)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start
> (GBeanInstanceState.j
> ava:102)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.start
> (GBeanInstance.java:529)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.startGBean
> (BasicKernel.java:361)
> at
> org.apache.geronimo.kernel.config.KernelConfigurationManager.load
> (KernelConfigu
> rationManager.java:161)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi
> guration(
> SimpleConfigurationManager.java:307)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi
> guration(
> SimpleConfigurationManager.java:275)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi
> guration(
> SimpleConfigurationManager.java:250)
> at
> org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfi
> guration(
> KernelConfigurationManager.java:112)
> at
> org.apache.geronimo.kernel.config.KernelConfigurationManager$
> $FastClassByCGLIB$
> $b117102f.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.ja
> va:38)
> at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:122
> )
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:820)
> at
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:
> 57)
> at
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> (RawOperationInvoker
> .java:35)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> (ProxyMethodIn
> terceptor.java:96)
> at
> org.apache.geronimo.kernel.config.EditableConfigurationManager$
> $EnhancerByCGLIB
> $$a79f3d70.loadConfiguration(<generated>)
> at
> org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:294)
> at
> org.apache.geronimo.system.main.Daemon.<init>(Daemon.java:74)
> at org.apache.geronimo.system.main.Daemon.main(Daemon.java:
> 377)
> [***************- ] 62% 18s Startup failed
> org.apache.geronimo.kernel.config.LifecycleException: load of
> org.apache.geronimo.configs/
> client-deployer/1.2-SNAPSHOT/car failed
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi
> guration(
> SimpleConfigurationManager.java:322)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi
> guration(
> SimpleConfigurationManager.java:275)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi
> guration(
> SimpleConfigurationManager.java:250)
> at
> org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfi
> guration(
> KernelConfigurationManager.java:112)
> at
> org.apache.geronimo.kernel.config.KernelConfigurationManager$
> $FastClassByCGLIB$
> $b117102f.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.ja
> va:38)
> at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:122
> )
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:820)
> at
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:
> 57)
> at
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> (RawOperationInvoker
> .java:35)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> (ProxyMethodIn
> terceptor.java:96)
> at
> org.apache.geronimo.kernel.config.EditableConfigurationManager$
> $EnhancerByCGLIB
> $$a79f3d70.loadConfiguration(<generated>)
> at
> org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:294)
> at
> org.apache.geronimo.system.main.Daemon.<init>(Daemon.java:74)
> at org.apache.geronimo.system.main.Daemon.main(Daemon.java:
> 377)
> Caused by: org.apache.geronimo.kernel.config.InvalidConfigException:
> Error starting config
> uration gbean
> org.apache.geronimo.configs/client-system/1.2-SNAPSHOT/car
> at
> org.apache.geronimo.kernel.config.KernelConfigurationManager.load
> (KernelConfigu
> rationManager.java:180)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi
> guration(
> SimpleConfigurationManager.java:307)
> ... 15 more
> Caused by: org.apache.geronimo.gbean.InvalidConfigurationException:
> Configuration gbean fa
> iled to start
> org.apache.geronimo.configs/client-system/1.2-SNAPSHOT/car
> at
> org.apache.geronimo.kernel.config.KernelConfigurationManager.load
> (KernelConfigu
> rationManager.java:163)
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Re: Is java.endorsed.dirs actually working?
Posted by anita kulshreshtha <a_...@yahoo.com>.
--- Rick McGuire <ri...@gmail.com> wrote:
>
> I decided to try an experiment using the jetty-j2ee Geronimo
> assembly.
> I deleted the Xerces jars from the lib/endorsed directory. I did
> this
> to convince myself that the java.endorsed.dirs mechanism was working
> correctly and the problem was due to me missing something with the
> yoko
> cofiguration. I expected Geronimo to "fall over" during launch
> because
> of the missing jars. To my surprise, it didn't.
I deleted xerces dir from the repository and the startup failed.
You are correct in saying that the jars from lib/endorsed are not being
used. Now I am wondering how are the jars from the G repository being
used. Are they really being used?
Thanks
Anita
Booting Geronimo Kernel (in Java 1.4.2_12)...
Starting Geronimo Application Server v1.2-SNAPSHOT
[********> ] 36% 9s Starting
org.apache.geronimo.co...10:47:16,625 INFO [
BrokerService] ActiveMQ 4.1-incubator-SNAPSHOT JMS Message Broker
(possibly-unique-broker)
is starting
10:47:16,625 INFO [BrokerService] For help or more information please
see: http://incubat
or.apache.org/activemq/
10:47:16,687 INFO [ManagementContext] JMX consoles can connect to
service:jmx:rmi://your-
4dacd0ea75/jndi/rmi://localhost:1099/jmxrmi
[********> ] 36% 9s Starting
org.apache.geronimo.co...10:47:16,781 INFO [
JDBCPersistenceAdapter] Database driver recognized:
[apache_derby_embedded_jdbc_driver]
[********> ] 36% 11s Starting
org.apache.geronimo.co...10:47:18,015 INFO [
DefaultDatabaseLocker] Attempting to acquire the exclusive lock to
become the Master broke
r
10:47:18,015 INFO [DefaultDatabaseLocker] Becoming the master on
dataSource: org.tranql.c
onnector.jdbc.DataSource@4ef122
10:47:18,125 INFO [JournalPersistenceAdapter] Journal Recovery Started
from: Active Journ
al: using 2 x 20.0 Megs at:
C:\anita\geronimo\geronimo-tomcat-j2ee-1.2-SNAPSHOT\activemq-d
ata\possibly-unique-broker\journal
10:47:18,187 INFO [JournalPersistenceAdapter] Journal Recovered: 0
message(s) in transact
ions recovered.
[********> ] 36% 11s Starting
org.apache.geronimo.co...10:47:18,406 INFO [
BrokerService] ActiveMQ JMS Message Broker (possibly-unique-broker,
ID:your-4dacd0ea75-139
9-1159454836203-1:0) started
10:47:18,468 INFO [TransportConnector] Connector vm://localhost
Started
10:47:18,515 INFO [TransportServerThreadSupport] Listening for
connections at: stomp://yo
ur-4dacd0ea75:61613
10:47:18,515 INFO [TransportConnector] Connector
stomp://your-4dacd0ea75:61613 Started
10:47:18,531 INFO [TransportServerThreadSupport] Listening for
connections at: tcp://0.0.
0.0:61616
10:47:18,531 INFO [TransportConnector] Connector tcp://0.0.0.0:61616
Started
[***************- ] 62% 18s Loading
org.apache.geronimo.co...10:47:25,078 ERROR [
GBeanInstanceState] Error while starting; GBean is now in the FAILED
state: abstractName="
org.apache.geronimo.configs/client-system/1.2-SNAPSHOT/car?configurationName=org.apache.ge
ronimo.configs/client-system/1.2-SNAPSHOT/car"
org.apache.geronimo.kernel.repository.MissingDependencyException:
Unable to resolve depend
ency xerces/xercesImpl/2.6.2/jar
at
org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationRe
solver.java:112)
at
org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.ja
va:397)
at
org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader
(Configuration.java:322)
at
org.apache.geronimo.kernel.config.Configuration.<init>(Configuration.java:267)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessor
Impl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructor
AccessorImpl.java:27)
at
java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.ja
va:936)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInst
anceState.java:267)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.j
ava:102)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:529)
at
org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigu
rationManager.java:161)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(
SimpleConfigurationManager.java:307)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(
SimpleConfigurationManager.java:275)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(
SimpleConfigurationManager.java:250)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(
KernelConfigurationManager.java:112)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$
$b117102f.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.ja
va:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122
)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker
.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodIn
terceptor.java:96)
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB
$$a79f3d70.loadConfiguration(<generated>)
at
org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:294)
at
org.apache.geronimo.system.main.Daemon.<init>(Daemon.java:74)
at org.apache.geronimo.system.main.Daemon.main(Daemon.java:377)
[***************- ] 62% 18s Startup failed
org.apache.geronimo.kernel.config.LifecycleException: load of
org.apache.geronimo.configs/
client-deployer/1.2-SNAPSHOT/car failed
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(
SimpleConfigurationManager.java:322)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(
SimpleConfigurationManager.java:275)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(
SimpleConfigurationManager.java:250)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(
KernelConfigurationManager.java:112)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$
$b117102f.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.ja
va:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122
)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker
.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodIn
terceptor.java:96)
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB
$$a79f3d70.loadConfiguration(<generated>)
at
org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:294)
at
org.apache.geronimo.system.main.Daemon.<init>(Daemon.java:74)
at org.apache.geronimo.system.main.Daemon.main(Daemon.java:377)
Caused by: org.apache.geronimo.kernel.config.InvalidConfigException:
Error starting config
uration gbean
org.apache.geronimo.configs/client-system/1.2-SNAPSHOT/car
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigu
rationManager.java:180)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(
SimpleConfigurationManager.java:307)
... 15 more
Caused by: org.apache.geronimo.gbean.InvalidConfigurationException:
Configuration gbean fa
iled to start
org.apache.geronimo.configs/client-system/1.2-SNAPSHOT/car
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigu
rationManager.java:163)
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com