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:
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
Could you try to add the --clean option while starting the Geronimo server
? It looks like that the issue was caused by OSGi framework cache.
2013/8/23 dkateros dkate...@gmail.com
Back to the work PC (the server is geronimo-tomcat7-javaee6-3.0.1 with a
couple test datasources set up).
The
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
Hi,
Sorry for the later response, was busy with other stuffs. Just create a
JIRA and attach a patched jar file, you may want to try that.
[1] https://issues.apache.org/jira/browse/GERONIMO-6488
2013/8/16 Ivan xhh...@gmail.com
Thanks for the sample, I could reproduce this now, and will get
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?).
Glad it works, I may come up some other following changes, mostly for jar
URL style while invoking getResources, will do that soon.
2013/8/23 dkateros dkate...@gmail.com
Thank you very much Ivan, much appreciated.
I just tried the test case on my home setup, looks OK. I will confirm with
Thanks for the sample, I could reproduce this now, and will get back to you
in the next one or two days.
2013/8/14 dkateros dkate...@gmail.com
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
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
Hmm, if you could provide a sample to reproduce this, I could take a look
at that in my local environment.
2013/8/12 dkateros dkate...@gmail.com
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
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:
It is possible that javassist from the server side was used. Could you try
to use hidden-class in your geronimo-web.xml to prevent using javassist
from Geronimo server.
*hidden*-*classes*filterjavassist/filter/*hidden*-*classes*
Hope it helps.
2013/8/5 dkateros dkate...@gmail.com
Hello,
I
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
13 matches
Mail list logo
