[jira] Commented: (GERONIMO-1931) Deployers and the deploying classes are in separate class loader hierarchies
[ http://issues.apache.org/jira/browse/GERONIMO-1931?page=comments#action_12377097 ] Aaron Mulder commented on GERONIMO-1931: This hits OpenEJB MdbBuilder in that it tries to instantiate an ActivationSpec and then call validate() on it. However, the deployer has a different ActivationSpec class than the configuration ClassLoader that it uses to load the ActivationSpec implementation. As a result, it has to use reflection to call validate and to deal with the exception class (same problem there) that indicates validation failures. When this is fixed, MdbBuilder should be fixed as well. Just a note, there's a new class o.a.g.kernel.util.ClassLoaderDumper that prints out the CL hierarchy and then the JARs in each CL in the path, to help with debugging. Deployers and the deploying classes are in separate class loader hierarchies Key: GERONIMO-1931 URL: http://issues.apache.org/jira/browse/GERONIMO-1931 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Dain Sundstrom Fix For: 1.2 The deployers are loaded from the main KernelConfiguraitonManager, where as when we deploy the new deployments are loaded from a private SimpleConfigurationManager. This means two classloaders are completely separate and deployers see different versions of the spec classes. Therefor, the deployers can't make use of instanceof and can use code like this: TimedObject.class.inAssignable(beanClass) This makes deployers unnecessarily complex and error prone. This can easily be addressed by having the private SimpleConfigurationManager in the DeploymentContext first check main KernelConfigurationManager to see if the configuration exists before reloading it from disk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1931) Deployers and the deploying classes are in separate class loader hierarchies
[ http://issues.apache.org/jira/browse/GERONIMO-1931?page=comments#action_12377065 ] Dain Sundstrom commented on GERONIMO-1931: -- The deployment context creates a private SimpleConfigurationManager. I believe that we need a sub-class of SimpleConfigurationManager that gets the main geronimo ConfiguationManager as an argument. Then any time we are checkin if a configuration exists, we first check the main geronimo ConfigurationManager. This will cause the new private configuration manager to see all currently loaded configurations in the server, and since the deployer is clearly already loaded it will see the same classes as the deployer. Deployers and the deploying classes are in separate class loader hierarchies Key: GERONIMO-1931 URL: http://issues.apache.org/jira/browse/GERONIMO-1931 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Dain Sundstrom Fix For: 1.2 The deployers are loaded from the main KernelConfiguraitonManager, where as when we deploy the new deployments are loaded from a private SimpleConfigurationManager. This means two classloaders are completely separate and deployers see different versions of the spec classes. Therefor, the deployers can't make use of instanceof and can use code like this: TimedObject.class.inAssignable(beanClass) This makes deployers unnecessarily complex and error prone. This can easily be addressed by having the private SimpleConfigurationManager in the DeploymentContext first check main KernelConfigurationManager to see if the configuration exists before reloading it from disk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
