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:
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
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
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
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?).
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
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:
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
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
