Re: Classes generated on runtime (javassist) classloader issue
12 something months later, I revisited this. Turns out that it is possible, after all, to have javassist load the generated class to the classloader of the abstract class that the generated class extends. Oh, well. -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/Classes-generated-on-runtime-javassist-classloader-issue-tp3987097p3988284.html Sent from the Users mailing list archive at Nabble.com.
Re: DeploymentException: POJO web service not configured by any web service builder
This thread seems to be the only useful google result for this error message, so I will resurrect it. I got the same error on geronimo 3.0.1 deployment (while geronimo 2.2 does not produce the problem) POJO web service: SimpleInstallmentsCalculatorService not configured by any web service builder org.apache.geronimo.common.DeploymentException: POJO web service: SimpleInstallmentsCalculatorService not configured by any web service builder at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:636) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:174) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:764) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:281) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:145) 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:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:877) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:662) The problem was a transitive maven dependency of jaxws-api was not declared with provided scope and these jars ended up in the war. [INFO] \- javax.xml.ws:jaxws-api:jar:2.2.6:provided [INFO]+- javax.xml.bind:jaxb-api:jar:2.2.4:provided [INFO]| +- javax.xml.stream:stax-api:jar:1.0-2:provided [INFO]| \- javax.activation:activation:jar:1.1:provided [INFO]+- javax.xml.soap:saaj-api:jar:1.3.4:provided [INFO]+- org.glassfish:javax.annotation:jar:3.1.1:provided [INFO]\- javax.jws:jsr181-api:jar:1.0-MR1:provided I am not sure if this demonstrates an underlying geronimo 3.0.1 problem, as no hidden classes were declared on geronimo-web.xml. Anyway, hope this helps. -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/DeploymentException-POJO-web-service-not-configured-by-any-web-service-builder-tp2677348p3987180.html Sent from the Users mailing list archive at Nabble.com.
Re: Classes generated on runtime (javassist) classloader issue
That one did the trick. Everything seems to be OK now. Thank you for your assistance. -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/Classes-generated-on-runtime-javassist-classloader-issue-tp3987097p3987143.html Sent from the Users mailing list archive at Nabble.com.
Re: Classes generated on runtime (javassist) classloader issue
Back to the work PC (the server is geronimo-tomcat7-javaee6-3.0.1 with a couple test datasources set up). The server boots up fine with the vanilla jar. With the patched jar a Main not found message is printed in geronimo.out after a minute or so (saw the other jira). In the latter case I see an ERROR message in geronimo.log that is not printed during normal start/stop with the vanilla jar. 2013-08-23 11:52:13,383 DEBUG [j2ee-system] FrameworkEvent ERROR org.osgi.framework.BundleException: Exception in org.apache.geronimo.system.osgi.BootActivator.start() of bundle org.apache.geronimo.framework.j2ee-system. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:734) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1131) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243) at org.eclipse.osgi.framework.internal.core.EquinoxLauncher.internalStart(EquinoxLauncher.java:271) at org.eclipse.osgi.framework.internal.core.EquinoxLauncher.start(EquinoxLauncher.java:241) at org.eclipse.osgi.launch.Equinox.start(Equinox.java:258) at org.apache.geronimo.main.FrameworkLauncher.launchOSGiFramework(FrameworkLauncher.java:195) at org.apache.geronimo.main.FrameworkLauncher.launch(FrameworkLauncher.java:175) at org.apache.geronimo.main.Bootstrapper.start(Bootstrapper.java:70) at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:61) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:33) Caused by: java.lang.NoClassDefFoundError: org/osgi/framework/wiring/BundleWiring at org.apache.geronimo.gbean.runtime.GBeanInstance.init(GBeanInstance.java:252) at org.apache.geronimo.kernel.basic.BasicKernel.loadGBean(BasicKernel.java:361) at org.apache.geronimo.kernel.basic.BasicKernel.boot(BasicKernel.java:613) at org.apache.geronimo.system.osgi.BootActivator.start(BootActivator.java:58) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702) ... 17 more Caused by: java.lang.ClassNotFoundException: org.osgi.framework.wiring.BundleWiring at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:513) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417) at org.apache.geronimo.hook.equinox.GeronimoClassLoader.loadClass(GeronimoClassLoader.java:85) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 24 more In case this is not the culprit (looks like it), I can post the entire startup log. Also, if you think that it has to do with the specific server installation, I will happily unpack a fresh one, but I thought you might want to take a peek. -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/Classes-generated-on-runtime-javassist-classloader-issue-tp3987097p3987140.html Sent from the Users mailing list archive at Nabble.com.
Re: Classes generated on runtime (javassist) classloader issue
Thank you very much Ivan, much appreciated. I just tried the test case on my home setup, looks OK. I will confirm with the actual application on work tomorrow (I actually got a weird error on the work PC when I tried the patch earlier today, did you by any chance update the patched jar file?). When I confirm everything is OK I will post here to let you know that you can close the jira issue. Once again, thank you. Regards // Dimitris -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/Classes-generated-on-runtime-javassist-classloader-issue-tp3987097p3987138.html Sent from the Users mailing list archive at Nabble.com.
Re: Classes generated on runtime (javassist) classloader issue
I created a standalone test case (depends only on java, servlet api and javassist 3.9.0.GA. You can download the war on the following URL (google drive) https://docs.google.com/file/d/0BxXbVMAMFEYOWHJ3a09YRnE4N1U/edit?usp=sharing On geronimo 2.2 the servlet GET method can be executed successfully as many times as you like. On geronimo 3.0.1 the first execution of the GET method throws the error I have mentioned. I think it would be interesting to see what the second execution does. Regards // Dimitris -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/Classes-generated-on-runtime-javassist-classloader-issue-tp3987097p3987116.html Sent from the Users mailing list archive at Nabble.com.
Re: Classes generated on runtime (javassist) classloader issue
I tried Ivan's suggestion but the problem persists. Any other suggestion would be most welcome at this point (even if it is to submit a problem report). TIA // Dimitris -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/Classes-generated-on-runtime-javassist-classloader-issue-tp3987097p3987110.html Sent from the Users mailing list archive at Nabble.com.
Re: Classes generated on runtime (javassist) classloader issue
Thank you for your reply Ivan. When we migrated the app to WAS 8.5, we faced a problem that was caused by this exact situation you describe: javassist was already loaded by the parent classloader. We did not change that, instead we scoped the javassist classpool singleton we use to create the runtime classes to our code (we were using the default classpool before). Long story short the app runs now on WAS 8.5 with the default parent first classloading policy. However, your idea is quite good. I will try to hide the javassist.* namespace from our app's classloader using the geronimo-web.xml configuration you suggest and I will post my findings here. It will take a few days (currently on vacation). Regards // Dimitris -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/Classes-generated-on-runtime-javassist-classloader-issue-tp3987097p3987102.html Sent from the Users mailing list archive at Nabble.com.
Classes generated on runtime (javassist) classloader issue
Hello,
I stumbled on this issue while testing an application with the geronimo 3.01
release (currently runs on geronimo 2.2 for development and Websphere 8.5
for production).
This application creates concrete classes on runtime based on abstract
classes that exist on compile time.
Imagine the following scenario (extremely naive, but demonstrates the
issue).
public abstract class Foo { //exists on compile time
SetString strings; //package visible
}
public class FooConcreteEnhanced extends Foo { //generated on runtime
public FooConcreteEnhanced() { strings = new HashSetString(); }
}
When the app attempts to instantiate FooConcreteEnhanced, the following
error is thrown:
java.lang.IllegalAccessError: tried to access field pkg.Foo.strings from
class pkg.FooConcreteEnhanced
This might be caused if the runtime package of the classes is different,
which happens if the two classes are loaded by two different classloaders.
Changing the access modifier of strings to protected circumvents the
problem, but is not desirable, since a lot of the app's unit tests rely on
package visibility of fields.
Is there any configuration available that I might use to force the generated
classes to be loaded by the same class loader of the apps build time
classes?
PS: Note that the javassist.ClassPool instance that hosts the generated
classes is scoped on the jars of my application (as opposed to being scoped
on the default javassist ClassPool that might be loaded by a parent
classloader in case the application server loads the javassist library for
other reasons - like WebSphere 8.5 does).
--
View this message in context:
http://apache-geronimo.328035.n3.nabble.com/Classes-generated-on-runtime-javassist-classloader-issue-tp3987097.html
Sent from the Users mailing list archive at Nabble.com.
