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/08/11 16:41:21 UTC
Yoko and Geronimo
I've run into an interesting snag with getting Geronimo to run with the
Yoko ORB. Because there in an inherent conflict with some of the class
files that ship with the JVM, it is necessary to prepend the yoko jar
file to the bootclasspath when launching the server. This sort of lies
outside of the realm of normal execution dependencies. I suppose it can
added to the startup batch file, but this means Geronimo can no longer
be started by just doing "java server.jar".
Additionally, if the Yoko jar is on the bootclasspath, then the Sun
version of the ORB adaptor will not function. This is an either/or
situation, and the choice, unfortunately, must be made before the JVM is
launched. This even comes into play during the build, because there are
unit tests for the SunNameService (and also the YokoNameService).
Any thoughts on how we should handle this particularly awkward situation?
Rick
Re: Yoko and Geronimo
Posted by Rick McGuire <ri...@gmail.com>.
Aaron Mulder wrote:
> On 8/11/06, Rick McGuire <ri...@gmail.com> wrote:
>> ...
>> Any thoughts on how we should handle this particularly awkward
>> situation?
>
> I vote "we" (e.g. Yoko) do whatever it takes to avoid the class
> conflict, and then Geronimo can forget about the JVM ORB forever.
Probably a question best asked on the yoko dev list. The best people to
answer this are the ones who dealt with the problem originally. I just
discovered the issue today...I might have avoided a lot of hair pulling
had I been more aware of it.
Rick
>
> Do "we" know how other open source ORBs handle the conflict?
>
> Thanks,
> Aaron
>
Re: Yoko and Geronimo
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 8/11/06, Rick McGuire <ri...@gmail.com> wrote:
> ...
> Any thoughts on how we should handle this particularly awkward situation?
I vote "we" (e.g. Yoko) do whatever it takes to avoid the class
conflict, and then Geronimo can forget about the JVM ORB forever.
Do "we" know how other open source ORBs handle the conflict?
Thanks,
Aaron
Re: Yoko and Geronimo
Posted by Paul McMahan <pa...@gmail.com>.
Rick, I'm curious about the inherent conflict with the classes that
ship with the JVM. Can you explain a little more about what that
means (which classes, when and how are they loaded, etc)?
thanks,
Paul
On 8/11/06, Rick McGuire <ri...@gmail.com> wrote:
> I've run into an interesting snag with getting Geronimo to run with the
> Yoko ORB. Because there in an inherent conflict with some of the class
> files that ship with the JVM, it is necessary to prepend the yoko jar
> file to the bootclasspath when launching the server. This sort of lies
> outside of the realm of normal execution dependencies. I suppose it can
> added to the startup batch file, but this means Geronimo can no longer
> be started by just doing "java server.jar".
>
> Additionally, if the Yoko jar is on the bootclasspath, then the Sun
> version of the ORB adaptor will not function. This is an either/or
> situation, and the choice, unfortunately, must be made before the JVM is
> launched. This even comes into play during the build, because there are
> unit tests for the SunNameService (and also the YokoNameService).
>
> Any thoughts on how we should handle this particularly awkward situation?
>
> Rick
>
Re: Yoko and Geronimo
Posted by Jason Dillon <ja...@planet57.com>.
FYI, in 1.2, the lib/ and lib/endorsed/* bits are now configured in
geronimo-boilerplate-minimal/pom.xml... which is picked up by all of
the assemblies.
--jason
On Aug 11, 2006, at 12:40 PM, Dain Sundstrom wrote:
> Rick,
>
> I believe what you really want to do is to use the endorsed
> directory. This allows you to override the vm implementation of
> endorsed specification such as corba (https://java.sun.com/j2se/
> 1.5.0/docs/guide/standards/index.html). In general, you should try
> to keep the stuff in the endorsed jar to a minimum as not to
> pollute the class path. In geronimo, to add something to the
> endorsed dir, you need to add it to our endorsed manifest entry
> "Endorsed-Dirs" (I have no idea where this is set in the build) and
> you need to modify the build to put the jar into lib/endorsed by
> modifying the bin.xml.
>
> -dain
>
>
> On Aug 11, 2006, at 7:41 AM, Rick McGuire wrote:
>
>> I've run into an interesting snag with getting Geronimo to run
>> with the Yoko ORB. Because there in an inherent conflict with
>> some of the class files that ship with the JVM, it is necessary to
>> prepend the yoko jar file to the bootclasspath when launching the
>> server. This sort of lies outside of the realm of normal
>> execution dependencies. I suppose it can added to the startup
>> batch file, but this means Geronimo can no longer be started by
>> just doing "java server.jar".
>> Additionally, if the Yoko jar is on the bootclasspath, then the
>> Sun version of the ORB adaptor will not function. This is an
>> either/or situation, and the choice, unfortunately, must be made
>> before the JVM is launched. This even comes into play during the
>> build, because there are unit tests for the SunNameService (and
>> also the YokoNameService).
>> Any thoughts on how we should handle this particularly awkward
>> situation?
>>
>> Rick
>
Re: Yoko and Geronimo
Posted by Jason Dillon <ja...@planet57.com>.
Dain pointed out that we don't want to "unpack" the dependencies...
so the goal should be "copy", not "unpack", as in:
{code:xml}
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>dependency-maven-plugin</artifactId>
<executions>
<execution>
<id>unpack-endorsed</id>
<phase>generate-test-resources</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.apache.yoko</groupId>
<artifactId>yoko</artifactId>
<version>1.0</version>
<type>jar</type>
</artifactItem>
</artifactItems>
<outputDirectory>${project.build.directory}/
endorsed</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>once</forkMode>
<workingDirectory>${project.build.directory}</
workingDirectory>
<argLine>-Djava.endorsed.dirs=${project.build.directory}/
endorsed</argLine>
</configuration>
</plugin>
{code}
--jason
On Aug 23, 2006, at 1:45 PM, Jason Dillon wrote:
> Looks like the bits to configure surefire are fine, except you'd
> want to change the value of "somedir".
>
> I recommend that you use the dependency plugin in your module's pom
> to download and install the needed jars to be placed into the
> "endorsed" dir (which will end up in the modules target/endorsed or
> something similar). Then configure the java.endorsed.dirs to point
> at that directory.
>
> Here is an example... not the right dependencies but I think it
> will give you the idea:
>
> {code:xml}
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>dependency-maven-plugin</artifactId>
> <executions>
> <execution>
> <id>unpack-endorsed</id>
> <phase>generate-test-resources</phase>
> <goals>
> <goal>unpack</goal>
> </goals>
> <configuration>
> <artifactItems>
> <artifactItem>
> <groupId>org.apache.yoko</groupId>
> <artifactId>yoko</artifactId>
> <version>1.0</version>
> <type>jar</type>
> </artifactItem>
> </artifactItems>
> <outputDirectory>${project.build.directory}/
> endorsed</outputDirectory>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-surefire-plugin</artifactId>
> <configuration>
> <forkMode>once</forkMode>
> <workingDirectory>${project.build.directory}</
> workingDirectory>
> <argLine>-Djava.endorsed.dirs=$
> {project.build.directory}/endorsed</argLine>
> </configuration>
> </plugin>
> {code}
>
> Lemme know if you need anything else.
>
> --jason
>
>
> On Aug 23, 2006, at 10:13 AM, Dain Sundstrom wrote:
>
>> You will need to configure the surefire (testing) plugin to fork
>> your tests into a new vm and set the endorsed dir for that new
>> vm. The first is easy but the second will be difficult. First
>> off the docs for the sure fire plugin can be found here
>>
>> http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html
>>
>> Here is an example setting
>> <project>
>> ...
>> <build>
>> ...
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-surefire-plugin</artifactId>
>> <configuration>
>> <forkMode>once</forkMode >
>> <argLine>-Djava.endorsed.dirs=somedir</argLine>
>> </configuration>
>> </plugin>
>> ...
>> </build>
>> ...
>> </project>
>>
>> The problem will be selecting a dir on the filesystem that will
>> include the endorsed API. BTW you could also set the boot class
>> path in the argLine above, but testing endorsed dir will be more
>> representative of the runtime environment.
>>
>> Jason, you have any ideas on how to configure this?
>>
>> -dain
>>
>> On Aug 23, 2006, at 3:10 AM, Rick McGuire wrote:
>>
>>> Dain Sundstrom wrote:
>>>> On Aug 11, 2006, at 12:40 PM, Dain Sundstrom wrote:
>>>>
>>>>> Rick,
>>>>>
>>>>> I believe what you really want to do is to use the endorsed
>>>>> directory. This allows you to override the vm implementation
>>>>> of endorsed specification such as corba (https://java.sun.com/
>>>>> j2se/1.5.0/docs/guide/standards/index.html). In general, you
>>>>> should try to keep the stuff in the endorsed jar to a minimum
>>>>> as not to pollute the class path. In geronimo, to add
>>>>> something to the endorsed dir, you need to add it to our
>>>>> endorsed manifest entry "Endorsed-Dirs" (I have no idea where
>>>>> this is set in the build) and you need to modify the build to
>>>>> put the jar into lib/endorsed by modifying the bin.xml.
>>>>
>>>> I'm dumb. You simply need to add the jar to lib/endorsed jar in
>>>> the boilerplate config (thanks Jason), and add it to the
>>>> manifest class path of the j2ee-system configuration (see the
>>>> pom file in that dir). It will be added to the system class
>>>> path and marked as endorsed so it can override the corba specs
>>>> just like we override the xml specs using xerces.
>>> Ok, this looks pretty simple, but, unfortunately, it only
>>> addresses the issues when running/building Geronimo. I'm running
>>> into a problem trying to get the unit tests to run while building
>>> openejb2. I've been trying to find the equivalent touch points
>>> in the openejb2 build, and have not had much success. I'm
>>> definitely skating on thin ice (not good for a person of my
>>> size :-) ) when it comes to the m2 stuff, so I'd appreciate any
>>> help/pointers I can get on this.
>>> Rick
>>>
>>>
>>>>
>>>> -dain
>>>>
>>
>
Re: Yoko and Geronimo
Posted by Jason Dillon <ja...@planet57.com>.
Looks like the bits to configure surefire are fine, except you'd want
to change the value of "somedir".
I recommend that you use the dependency plugin in your module's pom
to download and install the needed jars to be placed into the
"endorsed" dir (which will end up in the modules target/endorsed or
something similar). Then configure the java.endorsed.dirs to point
at that directory.
Here is an example... not the right dependencies but I think it will
give you the idea:
{code:xml}
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>dependency-maven-plugin</artifactId>
<executions>
<execution>
<id>unpack-endorsed</id>
<phase>generate-test-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.apache.yoko</groupId>
<artifactId>yoko</artifactId>
<version>1.0</version>
<type>jar</type>
</artifactItem>
</artifactItems>
<outputDirectory>${project.build.directory}/
endorsed</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>once</forkMode>
<workingDirectory>${project.build.directory}</
workingDirectory>
<argLine>-Djava.endorsed.dirs=${project.build.directory}/
endorsed</argLine>
</configuration>
</plugin>
{code}
Lemme know if you need anything else.
--jason
On Aug 23, 2006, at 10:13 AM, Dain Sundstrom wrote:
> You will need to configure the surefire (testing) plugin to fork
> your tests into a new vm and set the endorsed dir for that new vm.
> The first is easy but the second will be difficult. First off the
> docs for the sure fire plugin can be found here
>
> http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html
>
> Here is an example setting
> <project>
> ...
> <build>
> ...
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-surefire-plugin</artifactId>
> <configuration>
> <forkMode>once</forkMode >
> <argLine>-Djava.endorsed.dirs=somedir</argLine>
> </configuration>
> </plugin>
> ...
> </build>
> ...
> </project>
>
> The problem will be selecting a dir on the filesystem that will
> include the endorsed API. BTW you could also set the boot class
> path in the argLine above, but testing endorsed dir will be more
> representative of the runtime environment.
>
> Jason, you have any ideas on how to configure this?
>
> -dain
>
> On Aug 23, 2006, at 3:10 AM, Rick McGuire wrote:
>
>> Dain Sundstrom wrote:
>>> On Aug 11, 2006, at 12:40 PM, Dain Sundstrom wrote:
>>>
>>>> Rick,
>>>>
>>>> I believe what you really want to do is to use the endorsed
>>>> directory. This allows you to override the vm implementation of
>>>> endorsed specification such as corba (https://java.sun.com/j2se/
>>>> 1.5.0/docs/guide/standards/index.html). In general, you should
>>>> try to keep the stuff in the endorsed jar to a minimum as not to
>>>> pollute the class path. In geronimo, to add something to the
>>>> endorsed dir, you need to add it to our endorsed manifest entry
>>>> "Endorsed-Dirs" (I have no idea where this is set in the build)
>>>> and you need to modify the build to put the jar into lib/
>>>> endorsed by modifying the bin.xml.
>>>
>>> I'm dumb. You simply need to add the jar to lib/endorsed jar in
>>> the boilerplate config (thanks Jason), and add it to the manifest
>>> class path of the j2ee-system configuration (see the pom file in
>>> that dir). It will be added to the system class path and marked
>>> as endorsed so it can override the corba specs just like we
>>> override the xml specs using xerces.
>> Ok, this looks pretty simple, but, unfortunately, it only
>> addresses the issues when running/building Geronimo. I'm running
>> into a problem trying to get the unit tests to run while building
>> openejb2. I've been trying to find the equivalent touch points in
>> the openejb2 build, and have not had much success. I'm definitely
>> skating on thin ice (not good for a person of my size :-) ) when
>> it comes to the m2 stuff, so I'd appreciate any help/pointers I
>> can get on this.
>> Rick
>>
>>
>>>
>>> -dain
>>>
>
Re: Yoko and Geronimo
Posted by Dain Sundstrom <da...@iq80.com>.
You will need to configure the surefire (testing) plugin to fork your
tests into a new vm and set the endorsed dir for that new vm. The
first is easy but the second will be difficult. First off the docs
for the sure fire plugin can be found here
http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html
Here is an example setting
<project>
...
<build>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>once</forkMode >
<argLine>-Djava.endorsed.dirs=somedir</argLine>
</configuration>
</plugin>
...
</build>
...
</project>
The problem will be selecting a dir on the filesystem that will
include the endorsed API. BTW you could also set the boot class path
in the argLine above, but testing endorsed dir will be more
representative of the runtime environment.
Jason, you have any ideas on how to configure this?
-dain
On Aug 23, 2006, at 3:10 AM, Rick McGuire wrote:
> Dain Sundstrom wrote:
>> On Aug 11, 2006, at 12:40 PM, Dain Sundstrom wrote:
>>
>>> Rick,
>>>
>>> I believe what you really want to do is to use the endorsed
>>> directory. This allows you to override the vm implementation of
>>> endorsed specification such as corba (https://java.sun.com/j2se/
>>> 1.5.0/docs/guide/standards/index.html). In general, you should
>>> try to keep the stuff in the endorsed jar to a minimum as not to
>>> pollute the class path. In geronimo, to add something to the
>>> endorsed dir, you need to add it to our endorsed manifest entry
>>> "Endorsed-Dirs" (I have no idea where this is set in the build)
>>> and you need to modify the build to put the jar into lib/endorsed
>>> by modifying the bin.xml.
>>
>> I'm dumb. You simply need to add the jar to lib/endorsed jar in
>> the boilerplate config (thanks Jason), and add it to the manifest
>> class path of the j2ee-system configuration (see the pom file in
>> that dir). It will be added to the system class path and marked
>> as endorsed so it can override the corba specs just like we
>> override the xml specs using xerces.
> Ok, this looks pretty simple, but, unfortunately, it only addresses
> the issues when running/building Geronimo. I'm running into a
> problem trying to get the unit tests to run while building
> openejb2. I've been trying to find the equivalent touch points in
> the openejb2 build, and have not had much success. I'm definitely
> skating on thin ice (not good for a person of my size :-) ) when it
> comes to the m2 stuff, so I'd appreciate any help/pointers I can
> get on this.
> Rick
>
>
>>
>> -dain
>>
Re: Yoko and Geronimo
Posted by Rick McGuire <ri...@gmail.com>.
Dain Sundstrom wrote:
> On Aug 11, 2006, at 12:40 PM, Dain Sundstrom wrote:
>
>> Rick,
>>
>> I believe what you really want to do is to use the endorsed
>> directory. This allows you to override the vm implementation of
>> endorsed specification such as corba
>> (https://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html).
>> In general, you should try to keep the stuff in the endorsed jar to a
>> minimum as not to pollute the class path. In geronimo, to add
>> something to the endorsed dir, you need to add it to our endorsed
>> manifest entry "Endorsed-Dirs" (I have no idea where this is set in
>> the build) and you need to modify the build to put the jar into
>> lib/endorsed by modifying the bin.xml.
>
> I'm dumb. You simply need to add the jar to lib/endorsed jar in the
> boilerplate config (thanks Jason), and add it to the manifest class
> path of the j2ee-system configuration (see the pom file in that dir).
> It will be added to the system class path and marked as endorsed so it
> can override the corba specs just like we override the xml specs using
> xerces.
Ok, this looks pretty simple, but, unfortunately, it only addresses the
issues when running/building Geronimo. I'm running into a problem
trying to get the unit tests to run while building openejb2. I've been
trying to find the equivalent touch points in the openejb2 build, and
have not had much success. I'm definitely skating on thin ice (not good
for a person of my size :-) ) when it comes to the m2 stuff, so I'd
appreciate any help/pointers I can get on this.
Rick
>
> -dain
>
Re: Yoko and Geronimo
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Cool, that's a lot nicer than I had thought.
Thanks,
Aaron
On 8/11/06, Dain Sundstrom <da...@iq80.com> wrote:
> I'm dumb. You simply need to add the jar to lib/endorsed jar in the
> boilerplate config (thanks Jason), and add it to the manifest class
> path of the j2ee-system configuration (see the pom file in that
> dir). It will be added to the system class path and marked as
> endorsed so it can override the corba specs just like we override the
> xml specs using xerces.
Re: Yoko and Geronimo
Posted by Dain Sundstrom <da...@iq80.com>.
On Aug 11, 2006, at 12:40 PM, Dain Sundstrom wrote:
> Rick,
>
> I believe what you really want to do is to use the endorsed
> directory. This allows you to override the vm implementation of
> endorsed specification such as corba (https://java.sun.com/j2se/
> 1.5.0/docs/guide/standards/index.html). In general, you should try
> to keep the stuff in the endorsed jar to a minimum as not to
> pollute the class path. In geronimo, to add something to the
> endorsed dir, you need to add it to our endorsed manifest entry
> "Endorsed-Dirs" (I have no idea where this is set in the build) and
> you need to modify the build to put the jar into lib/endorsed by
> modifying the bin.xml.
I'm dumb. You simply need to add the jar to lib/endorsed jar in the
boilerplate config (thanks Jason), and add it to the manifest class
path of the j2ee-system configuration (see the pom file in that
dir). It will be added to the system class path and marked as
endorsed so it can override the corba specs just like we override the
xml specs using xerces.
-dain
Re: Yoko and Geronimo
Posted by Dain Sundstrom <da...@iq80.com>.
Rick,
I believe what you really want to do is to use the endorsed
directory. This allows you to override the vm implementation of
endorsed specification such as corba (https://java.sun.com/j2se/1.5.0/
docs/guide/standards/index.html). In general, you should try to keep
the stuff in the endorsed jar to a minimum as not to pollute the
class path. In geronimo, to add something to the endorsed dir, you
need to add it to our endorsed manifest entry "Endorsed-Dirs" (I have
no idea where this is set in the build) and you need to modify the
build to put the jar into lib/endorsed by modifying the bin.xml.
-dain
On Aug 11, 2006, at 7:41 AM, Rick McGuire wrote:
> I've run into an interesting snag with getting Geronimo to run with
> the Yoko ORB. Because there in an inherent conflict with some of
> the class files that ship with the JVM, it is necessary to prepend
> the yoko jar file to the bootclasspath when launching the server.
> This sort of lies outside of the realm of normal execution
> dependencies. I suppose it can added to the startup batch file,
> but this means Geronimo can no longer be started by just doing
> "java server.jar".
> Additionally, if the Yoko jar is on the bootclasspath, then the Sun
> version of the ORB adaptor will not function. This is an either/or
> situation, and the choice, unfortunately, must be made before the
> JVM is launched. This even comes into play during the build,
> because there are unit tests for the SunNameService (and also the
> YokoNameService).
> Any thoughts on how we should handle this particularly awkward
> situation?
>
> Rick