Hmm ok. When I inspected the classloader when loading the class for the attribute type, I remember seeing that the parent classloader contained XMLObject. Do you know why the other gbean's loaded successfully? Would setting the context classloader help the situation?On Nov 3, 2006, at 4:18 AM, David Jencks wrote: I think either removing geronimo-deployment from the manifest cp or adding xmlbeans jar will solve this problem. I don't think the former will work and I really don't like the latter. Maybe we can split up geronimo-deployment jar into a remote piece and a local piece? This may take some more investigation.... meanwhile temporarily adding xmlbeans to lib and the cp might get this going for now.
thanks david jencks On Nov 2, 2006, at 4:58 PM, Sachin Patel wrote: So after being able to bootstrap the j2ee-system configuration, we are running into a NoClassDef exception on XMLObject when attempting to start the gbean-deployer configuration.
Comparing the gbean-deployer config to 1.1.1, it looks like a GBeanBuilder bean was introduced in the plan, and this happens to be the gbean that fails to load and causes the exception. The Deployer and ServiceConfigBuilder gbeans prior to it seem to load successfully (which is strange since ServiceConfigBuilder imports XMLObject as well). So on GBeanBuilder when attempting to construct the GBeanInstance and the GBeanAttribute for GBeanInfo
for (Iterator iterator = gbeanInfo.getAttributes().iterator(); iterator.hasNext();) { GAttributeInfo attributeInfo = (GAttributeInfo) iterator.next(); attributesMap.put(attributeInfo.getName(), new GBeanAttribute(this, attributeInfo, constructorArgs.contains(attributeInfo.getName()))); }
The exception is thrown on line 249 in the constructor of GBeanAttribute
getInvoker = new FastMethodInvoker(getterMethod);
But I seem to be at a dead end here. :(
Any ideas why this is failing? On Nov 1, 2006, at 7:04 PM, David Jencks wrote: I came up with a proposed solution and put it in GERONIMO-2539. I think I'm about to need this facility also :-)
Take a look, see if it can be improved, see if it works :-)
jdillon, does this look OK to you?
thanks david jencks On Nov 1, 2006, at 11:15 AM, Sachin Patel wrote: I'm trying to get the offline deployer back working in trunk, the problem is when starting the kernel with the using j2ee-system as the bootstrap configuration, when locating "META-INF"/config.ser" resources only deployer.jar is located having this resource and thus the j2ee-system config cannot be found and the bootstrap fails. When debugging through 1.1.1, both server.jar and deployer.jar were found.
So comparing the online-deployer configuration in trunk against 1.1.1, the culprit seems to be that server.jar is missing in the configuration's manifest as a classpath entry. This was specified in the project.properties in 1.1.1. Since it looks as if in trunk we are relying purely on the car-maven-plugin to build the manifest's classpath, since server.jar is not technically an artifact, if failed to add as an entry.
Is there a way I don't know about to add this? Or do we need to update the car-maven-plugin to allow it?
thx |
