Re: Yoko and Geronimo
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
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 groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration forkModeonce/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
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
groupIdorg.codehaus.mojo/groupId
artifactIddependency-maven-plugin/artifactId
executions
execution
idunpack-endorsed/id
phasegenerate-test-resources/phase
goals
goalunpack/goal
/goals
configuration
artifactItems
artifactItem
groupIdorg.apache.yoko/groupId
artifactIdyoko/artifactId
version1.0/version
typejar/type
/artifactItem
/artifactItems
outputDirectory${project.build.directory}/
endorsed/outputDirectory
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
forkModeonce/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
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
forkModeonce/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
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
groupIdorg.codehaus.mojo/groupId
artifactIddependency-maven-plugin/artifactId
executions
execution
idunpack-endorsed/id
phasegenerate-test-resources/phase
goals
goalcopy/goal
/goals
configuration
artifactItems
artifactItem
groupIdorg.apache.yoko/groupId
artifactIdyoko/artifactId
version1.0/version
typejar/type
/artifactItem
/artifactItems
outputDirectory${project.build.directory}/
endorsed/outputDirectory
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
forkModeonce/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
groupIdorg.codehaus.mojo/groupId
artifactIddependency-maven-plugin/artifactId
executions
execution
idunpack-endorsed/id
phasegenerate-test-resources/phase
goals
goalunpack/goal
/goals
configuration
artifactItems
artifactItem
groupIdorg.apache.yoko/groupId
artifactIdyoko/artifactId
version1.0/version
typejar/type
/artifactItem
/artifactItems
outputDirectory${project.build.directory}/
endorsed/outputDirectory
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
forkModeonce/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
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
forkModeonce/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
Re: Yoko and Geronimo
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 [EMAIL PROTECTED] 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
On 8/11/06, Rick McGuire [EMAIL PROTECTED] 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
Aaron Mulder wrote: On 8/11/06, Rick McGuire [EMAIL PROTECTED] 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
Hi, The JDK class http://java.sun.com/j2se/1.5.0/docs/api/org/omg/PortableInterceptor/IORI nterceptor_3_0Operations.html#adapter_manager_state_changed(int,%20short ) doesn't correctly implement the corba 3.0 spec... This method should have a string as the manager ID. Anyways, there are 2 ways to handle this... 1) java.endorsed.dirs setting 2) xbootclasspath - Balaji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Friday, August 11, 2006 10:57 AM To: dev@geronimo.apache.org Subject: Re: Yoko and Geronimo On 8/11/06, Rick McGuire [EMAIL PROTECTED] 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
Are you saying that every open source and commercial ORB that wants to run under JDK 1.5.0 requires one of these two approaches? That no one has come up with a workaround that doesn't require user intervention? Thanks, Aaron On 8/11/06, Mosur Ravi, Balaji [EMAIL PROTECTED] wrote: The JDK class http://java.sun.com/j2se/1.5.0/docs/api/org/omg/PortableInterceptor/IORI nterceptor_3_0Operations.html#adapter_manager_state_changed(int,%20short ) doesn't correctly implement the corba 3.0 spec... This method should have a string as the manager ID. Anyways, there are 2 ways to handle this... 1) java.endorsed.dirs setting 2) xbootclasspath - Balaji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Friday, August 11, 2006 10:57 AM To: dev@geronimo.apache.org Subject: Re: Yoko and Geronimo On 8/11/06, Rick McGuire [EMAIL PROTECTED] 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
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
If the ORB wants to be 3.0 compliant, then yes... java.endorsed.dirs is the preferred way that sun wants to follow for these cases... - Balaji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Friday, August 11, 2006 3:08 PM To: dev@geronimo.apache.org Subject: Re: Yoko and Geronimo Are you saying that every open source and commercial ORB that wants to run under JDK 1.5.0 requires one of these two approaches? That no one has come up with a workaround that doesn't require user intervention? Thanks, Aaron On 8/11/06, Mosur Ravi, Balaji [EMAIL PROTECTED] wrote: The JDK class http://java.sun.com/j2se/1.5.0/docs/api/org/omg/PortableInterceptor/IORI nterceptor_3_0Operations.html#adapter_manager_state_changed(int,%20short ) doesn't correctly implement the corba 3.0 spec... This method should have a string as the manager ID. Anyways, there are 2 ways to handle this... 1) java.endorsed.dirs setting 2) xbootclasspath - Balaji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Friday, August 11, 2006 10:57 AM To: dev@geronimo.apache.org Subject: Re: Yoko and Geronimo On 8/11/06, Rick McGuire [EMAIL PROTECTED] 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
That is just to put the jar into a dir, which the system property java.endorsed.dirs points to? --jason On Aug 11, 2006, at 12:51 PM, Mosur Ravi, Balaji wrote: If the ORB wants to be 3.0 compliant, then yes... java.endorsed.dirs is the preferred way that sun wants to follow for these cases... - Balaji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Friday, August 11, 2006 3:08 PM To: dev@geronimo.apache.org Subject: Re: Yoko and Geronimo Are you saying that every open source and commercial ORB that wants to run under JDK 1.5.0 requires one of these two approaches? That no one has come up with a workaround that doesn't require user intervention? Thanks, Aaron On 8/11/06, Mosur Ravi, Balaji [EMAIL PROTECTED] wrote: The JDK class http://java.sun.com/j2se/1.5.0/docs/api/org/omg/PortableInterceptor/ IORI nterceptor_3_0Operations.html#adapter_manager_state_changed(int,% 20short ) doesn't correctly implement the corba 3.0 spec... This method should have a string as the manager ID. Anyways, there are 2 ways to handle this... 1) java.endorsed.dirs setting 2) xbootclasspath - Balaji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Friday, August 11, 2006 10:57 AM To: dev@geronimo.apache.org Subject: Re: Yoko and Geronimo On 8/11/06, Rick McGuire [EMAIL PROTECTED] 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
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
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
Cool, that's a lot nicer than I had thought. Thanks, Aaron On 8/11/06, Dain Sundstrom [EMAIL PROTECTED] 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.
