I don't see why the class loader must be Translatable. IMO, AspectManager
shouldn't enforce this.
I'm investigating why this is the way it is, and I'll come back with an answer
after that:
http://www.jboss.com/index.html?module=bbop=viewtopicp=4161165#4161165
View the original post :
The bug is fixed:
http://jira.jboss.com/jira/browse/JBAOP-606
You will find a jar with the fix attached to the Jira issue. Please, try it on
and let us know if this solves the problem.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4161273#4161273
Reply to
I'll try this fix when I arrive home.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4161282#4161282
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4161282
___
jboss-user mailing
Hi again!
anonymous wrote : The above piece of code is, at least for me, the cause of my
problems. since the ClassLoader that loaded JointPointGenerator cannot see
JPF's ClassLoader.
Actually, that piece of code gets the class loader that loaded a generated
class advisor (in the case,
anonymous wrote : unless org.drftpd.vfs.index.lucene.SimpleInterceptor is not
visible to org.drftpd.vfs.InodeHandle?
I am starting to think that this is the case. Look at a simplified view of what
JBoss AOP does to your code:
| class InodeHandle
| {
|private static transient
After some careful debuggin I managed to trace what's probably causing my
issues:
That's the execution Stack of my thread.
| Thread [FtpConn thread 20 from iphidden - pool-3-thread-1] (Suspended)
| AspectManager.registerClassLoader(ClassLoader) line: 762
|
Ok, Flavia, I tried what you suggested and it seemed to work, but turns out
that developing with eclipse (and using it's compiler) together with AopC isn't
a good idea, because everytime I change a single char using eclipse it
recompiles the class so it will loose all code that was once
From this piece of log:
[aopc] [aop-debug] org.jboss.aop.instrument.Instrumentor was
org.drftpd.vfs.index.lucene.LuceneEngine converted: true
I can see that aopc is intercepting your class. Probably, you're forgetting to
make your aop.xml file accessible to JBoss AOP at runtime. If JBoss AOP
Any clue?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4159800#4159800
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4159800
___
jboss-user mailing list
Doing some investigation I found out that JPF's ClassLoader have URLClassLoader
as their superclass, don't know if that's relevant though.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4156278#4156278
Reply to the post :
I just noticed that your -Djboss.aop.path is wrong it should point to the full
name of the jboss-aop.xml file, e.g.:
| -Djboss.aop.path=conf/aop/jboss-aop.xml
|
If that doesn't work, try specifying the whole path
| -Djboss.aop.path=/some/where/conf/aop/jboss-aop.xml
|
See if that
I saw this in the documentation:
anonymous wrote :
| You tell JBoss AOP where the XML files are. Set the jboss.aop.path system
property. (You can specify multiple files or directories separated by ':'
(*nix) or ';' (Windows), i.e. -Djboss.aop.path=jboss-aop.xml;metadata-aop.xml)
If you
You're right, a directory works as well - forgot.
Does it work for you if you use compile-time weaving? YOu would need to unjar
the jar containing org.drftpd.vfs.index.lucene.LuceneEngine. Then run aopc then
re-jar
View the original post :
Gonna try to use compile-time weaving but I really would like to use load-time
weaving.
Like I said before, I can't test it right now, cuz I'm at work but as soon as I
arrive home i'll give more feedback.
View the original post :
14 matches
Mail list logo
