A test of building with java 1.5 - yoko, openejb, geronimo
Hello all, As an experiment, I tried to build everything in trunk (and their dependencies) using java 1.5 (I had to compile the sun orb with 1.4). First, I started with a clean .m2 repo. I compiled: - Yoko from svn checkout of trunk - Geronimo-spec from svn checkout of trunk - OpenEJB2 from svn checkout of trunk - Geronimo from svn checkout of trunk (This was after the recent openejb changes to include yoko) I was able to get a successful build, but when I tried to start the server - It failed because the initial config.xml file created for Geronimo was corrupted. Here is the section for the yoko and sun orb's: module name=org.apache.geronimo.configs/j2ee-corba-yoko/1.2-SNAPSHOT/car load=false gbean name=NameServer attribute name=port1050/attribute attribute name=host${PlanCOSNamingHostttribute /gbean /module module name=org.apache.geronimo.configs/j2ee-corba-sun/${pom.version}/car load=false gbean name=NameServer attribute name=port1050/attribute attribute name=host${PlanCOSNamingHostttribute /gbean /module For both, the host attribute got squirrelled. I'm going to retry the build using java 1.4 to see if the same thing happens. Jay
Re: A test of building with java 1.5 - yoko, openejb, geronimo
Hello again, Well, I rebuilt everything using java 1.4 this time. And, I just used the yoko snapshot jars (they were available now, but were not available last time I was building). So starting with a fresh .m2 repo... I compiled: - geronimo-specs from svn checkout of trunk - openejb2 from svn checkout of trunk - geronimo from svn checkout of trunk And I got the same corruption of the var/config/config.xml file: module name=org.apache.geronimo.configs/j2ee-corba-yoko/1.2-SNAPSHOT/car load=false gbean name=NameServer attribute name=port1050/attribute attribute name=host${PlanCOSNamingHostttribute /gbean /module module name=org.apache.geronimo.configs/j2ee-corba-sun/${pom.version}/car load=false gbean name=NameServer attribute name=port1050/attribute attribute name=host${PlanCOSNamingHostttribute /gbean /module Is this a result of the recent yoko changes being patched in? Is anyone else getting this same result? Jay
Re: A test of building with java 1.5 - yoko, openejb, geronimo
I was just told on IRC that this was a problem in the source code for tomcat and is corrected now. Jay
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
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
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.