It does look like it is aop$classAdvisor$aop. Static initialization should always
happen, not sure why it isn't in this case.
would it be possible to put together a small test case we can reproduce the problem
with?
Apologies,
Bill
View the original post :
http://www.jboss.org/index.html?mo
Another question:
Are you using the precompiler? Or load time? or both?
Bill
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3853950#3853950
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3853950
Bill,
As I mentioned above, I am using the precompiler.
Let me see what I can do about stripping out a significant amount of code and come up
with a reproducable test case.
Want me to send it via email?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3853952#
Yes, send it via email: [EMAIL PROTECTED]
FYI: hot deployment is a bitch.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3853954#3853954
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3853954
--
I am working on it now...just as an FYI that might be the cause...I am doing scooped
classloading inside the 'standard' config of JBoss 4.0.
Here is the contents of jboss-web.xml from the war:
|
|
|
| My.war:loader= My.war
|
java2ParentDelegation=false
|
|
FYI, I have done ZERO testing with scoped classloading and JBoss AOP.
FYI2:
If you figure out this bug, and you want CVS access, you got it! I STILL have a hard
time debugging hot deployment bugs whenever they come up.
Bill
View the original post :
http://www.jboss.org/index.html?module=bb&o
I will take a look at today.
I do want to give you an update on what I have found. It is definetly a classloading
issue.
If in my scoped WAR File, I incldue the jboss-aop*.jar's, the issue does not happen. I
can redeploy all day long. THat makes sense, because at that point I am using my
scope
I take that backincluding the aop jar files does not solve the problem.
When incuding the jar files, the intercepted code is, for all purposes ignored.
It looks like when using your own scoped version of those jar files, either the
aop$classAdvisor$aop or the _instanceAdvisor returns that th
Just wanted to respond back to this thread what the problem is and potential
resolutions, so it is useful to other people.
This problem with redeployment stems from the fact the the AspectManger inside
of the AOP framework in certain cases can be loaded inside a different
ClassLoader than the a