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/Cl
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.c
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
> 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
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
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
> 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 applic
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?). Whe
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
> Thanks for the sample, I could reproduce this now, and will get back to
> you in th
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
> 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)
>
>
> http
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 successfull
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
> 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
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-classloa
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 runt
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*>javassist
Hope it helps.
2013/8/5 dkateros
> Hello,
>
> I stumbled on this issue while testing an applic
13 matches
Mail list logo