On 2/27/06, Joe Bohn <[EMAIL PROTECTED]> wrote:
Hi Joe,
While I'm thinking about it -- thanks for the config-parent diagram. I've already used it several times...
I'm not exactly sure what's causing your specific problem. However, as Dain recently pointed out to me, given our current ClassLoader structure, we're going to run into lots of problems if the spec classes are not defined in a single, common, parent config. Just look at your config diagram and think of the multiple classloaders that would be loading unique instances of the spec classes.
rmi-naming includes all spec classes by declaring a dependency on geronimo-j2ee_1.4_spec.jar. If the current minimal is including both the spec jar and the consituent jars, then seems like we can cut it down to <only> the uber-jar or <all> of the constituent spec jars, not <both>. However, I don't think you'll be able to reasonably reduce things further...
--kevan
Regarding Kevan's comment on the config dependencies on j2ee_1.4_spec:
I had started to look at removing the dependencies in configs on
geronimo-j2ee_1.4_spec as a way to make the minimal assembly still
smaller. Everybody has indicated that this should not be needed in the
runtime. However, it's currently included pretty high up in the
class-loader parentage (in rmi-naming) and apparently for good reason.
When I attempted to remove it I immediately hit problems building the
config for j2ee-server. It's failing because it is missing the class
def for javax.resource.ResourceException. I continue to hit this same
error even if I add the dependency directly into the j2ee-server config
or in the parent of all deployers (geronimo-gbean-deployer).
With similar errors I have been able to fix things by adding the
appropriate dependency to either the configuration itself, or the
deployer that is involved deploying that configuration depending on the
error. This doesn't seem to be true of the spec implementation. I know
the specs are special but I'm not exactly sure what's going on here.
Any suggestions?
Hi Joe,
While I'm thinking about it -- thanks for the config-parent diagram. I've already used it several times...
I'm not exactly sure what's causing your specific problem. However, as Dain recently pointed out to me, given our current ClassLoader structure, we're going to run into lots of problems if the spec classes are not defined in a single, common, parent config. Just look at your config diagram and think of the multiple classloaders that would be loading unique instances of the spec classes.
rmi-naming includes all spec classes by declaring a dependency on geronimo-j2ee_1.4_spec.jar. If the current minimal is including both the spec jar and the consituent jars, then seems like we can cut it down to <only> the uber-jar or <all> of the constituent spec jars, not <both>. However, I don't think you'll be able to reasonably reduce things further...
--kevan
Here's the stacktrace:
16:30:42,697 ERROR [Deployer] Deployment failed due to
java.lang.NoClassDefFoundError: javax/resource/ResourceException
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods (Class.java:1655)
at java.lang.Class.privateGetPublicMethods(Class.java:1778)
at java.lang.Class.getMethods(Class.java:832)
at
org.apache.geronimo.gbean.GBeanInfoBuilder.addInterface (GBeanInfoBuilder.java:223)
at
org.apache.geronimo.gbean.GBeanInfoBuilder.addInterface(GBeanInfoBuilder.java:218)
at
org.apache.geronimo.gbean.GBeanInfoBuilder.addInterface(GBeanInfoBuilder.java :212)
at
org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinatorGBean.<clinit>(ConnectionTrackingCoordinatorGBean.java:35)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:65)
at
org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData (ServiceConfigBuilder.java:316)
at
org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:311)
at
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration (ServiceConfigBuilder.java:207)
at
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:167)
at
org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke (<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$2ea63e01.buildConfiguration(<generated>)
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:279)
at
org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at
org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer(PackageBuilder.java:389)
at
org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:294)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.geronimo.plugin.packaging.PackageBuilderShell.execute(PackageBuilderShell.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:180)
at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:102)
at
org.apache.commons.jelly.impl.ScriptBlock.run (ScriptBlock.java:95)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:78)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java :109)
at org.apache.maven.werkz.Goal.fire(Goal.java:656)
at org.apache.maven.werkz.Goal.attain(Goal.java:592)
at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505)
at org.apache.maven.werkz.Goal.attain(Goal.java:590)
at
org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:210)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java :114)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag (MavenGoalTag.java:78)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:109)
at org.apache.maven.werkz.Goal.fire(Goal.java:656)
at org.apache.maven.werkz.Goal.attain (Goal.java:592)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:693)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain (App.java:511)
at org.apache.maven.cli.App.main(App.java:1258)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run( Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
Kevan Miller (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/GERONIMO-1639?page=comments#action_12367776 ]
>
> Kevan Miller commented on GERONIMO-1639:
> ----------------------------------------
>
> As mentioned in my previous note, the NPE's weren't fixed. The problem was the uber-jar still contained the bad corba spec classes. This overrides any children with dependencies on the corba jar which you just created.
>
> I've worked around by adding your corba jar as a dependency in specs/rmi-naming. I think the following need to occur:
>
> 1) the bad corba spec jars/classes should be removed from specs 1.1. Probably best to create a specs/branches/1_1. That way 1.1 will be clean. You can start using specs/trunk (1.2) for the new corba spec classes.
> 2) we should consider cleaning up the geronimo-j2ee_1.4_spec dependencies in our configs. I was surprised to find them there... I'd need a little feedback from others, before starting on that, however...
>
>
>>Setup old version of CORBA specs
>>--------------------------------
>>
>> Key: GERONIMO-1639
>> URL: http://issues.apache.org/jira/browse/GERONIMO-1639
>> Project: Geronimo
>> Type: Bug
>> Components: CORBA
>> Versions: 1.0, 1.0.1, 1.1, 1.x
>> Reporter: Alan Cabrera
>> Assignee: Kevan Miller
>> Fix For: 1.1, 1.x
>
>
>>Setup old version of CORBA specs for temporary use until the new CORBA specs can pass the TCK.
>
>
--
Joe Bohn
joe.bohn at earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
