Hi Alex, You're right. There is no real reason other than laziness to try to advise container classes. I'm actually trying to log EJB authorization, so instead of advising every EJB method, I was thinking of advising the container's authorization interceptor and checking if the interceptor throws an exception. I guess the non-lazy (proper ?:)) way is to advise all secured EJB methods. I'll have to give that a shot tomorrow. But it just made me think/wonder if there was any way to advise classes that were already loaded.
It also doesn't address my issue when I am trying to LTW classes that are only visible to the child classloader but not the classloader that loaded the apsects. Which means that I still don't know how to access the advised parameters/return values. Any thoughts which flags I should use to get the most info out of the advise process? I have the verbose flag enabled in my aop.xml, but it doesn't seem to give me enough details. I know I get more details out when using CTW with ajc, but I suspect that is because it knows exactly which methods it can match on compile, vs LTW when it never knows if it matches or not until the classes are loaded. So you never get warnings that pointcuts don't match. Thanks! Eric On Sun, Aug 21, 2016 at 5:17 PM, Alexander Kriegisch < [email protected]> wrote: > Hi Eric. > > I do not really want to imagine what makes you think you need/want to > advise container classes. I would assume that there must be a better way to > technically achieve what you want. You said the problem was about the > legacy application, not about the container. > > Anyway, for what it is worth, in principal you can, if you can influence > how the container is started, apply binary weaving to container classes and > put aspectjrt.jar on the JVM boot classpath. As for the third party library > (Struts), it would be interesting to find out what causes the class > visibility problem you mentioned. But even if you do not find out, you can > still apply binary weaving to all JARs in your EAR, repackage the woven > version and also use it in connection with aspectjrt.jar. No LTW means no > LTW-related problems. > > I am pretty sure there also is a way to fix the LTW situation, but I can > only speculate about it because I am not really a container champion. Maybe > if I had the binaries and exact setup to locally reproduce the problem... > Maybe you can find out more by setting the appropriate debug logging > options in your container as well as in AspectJ itself. > > As for retransforming already loaded classes, I once tried but failed > because either it is not possible or just because I do not know enough > about the JVM. In order to manually handle that. > > As I said: if I were you I would try to reduce the situation's complexity > by using binary weaving instead of LTW. Just my two cents. Probably Andy > has a much better answer for you, as usual. :-) > > Regards > -- > Alexander Kriegisch > https://scrum-master.de > > > Am 21.08.2016 um 23:01 schrieb Eric B <[email protected]>: > > Hi Alex, > > Actually, there are some struts classes I want to advise. But I have 2 > issues (related but distinct) with approach #1. > > 1) I an able to advise the struts classes, but cannot use any of the > struts class definitions as they are not exposed to the aspect. That means > if I was to access any arguments that are struts classes (parameters or > return values) as anything more than mere Object, I can't. I get > ClassDefNotFound exceptions. > > 2) I would like to advise some container (JEE) classes, but they aren't > advisable either as they have already been loaded by then time the > container loads my aspect jar. > > I haven't actually tried using call() instead of execution() yet; it only > occurred to me as I was writing my post. But I suspect you are court that > it won't make a significant difference, as the calls are made from within > the framework itself (which are already loaded). > > Is there any way out of this mess? Is there anyway to use something like > cflow()? Is there no way to advise an already loaded class? > > Thanks > > Eric > > On Aug 21, 2016 12:46 PM, "Alexander Kriegisch" <[email protected]> > wrote: > >> Hi Eric. >> >> What is the problem with approach #1? That Struts classes are not loaded >> correctly anymore? Do you even want to advse them? If that is not necessary >> why not just exclude them by !within(org.apache.struts)? >> >> Yes, class-loading sequence is relevant for AspectJ LTW. >> >> Using call() instead of execution() does not solve the root cause of >> your problem, I assume. It only bloats the bytecode because many more >> joinpoints need to be woven. >> Regards >> -- >> Alexander Kriegisch >> https://scrum-master.de >> >> Eric B schrieb am 21.08.2016 15:03: >> >> I have a "fragile" legacy app that is running on JBoss 4. That is to >> say, that any changes to the app require a full manual regression test >> which are long and expensive. I'm trying to add some specific logging to >> the app, so I figured that using AOP to intercept method executions would >> be the simplest way without altering the binaries. >> >> But here is where I am running into classloading problems when I am >> trying to advise classes that are already loaded by the classloader by the >> time my ear gets loaded. >> >> My EAR is structured as the follows: >> >> EAR >> - webapp.war >> \ WEB-INF/lib >> - webstuff.jar >> - WebClasses.jar >> - struts.jar >> - EJB.jar >> - utils.jar >> >> >> JBoss is set to load as parent-first, and modifying the sequence isn't an >> option. >> >> So I have a few problems here: >> 1) If I drop my aspect.jar in my EAR/lib folder, and enable LTW on the >> command line, it is able to successfully advise all my classes in EJB.jar, >> utils.jar and webstuff.jar. I am even able to advise methods in >> struts.jar, but unable to use any struts classes as the classloader for the >> aspect doesn't "see" anything in struts.jar (I get >> ClassDefNotFoundException). >> >> 2) If I move my aspect.jar into my WEB-INF/lib folder, it doesn't >> successfully advise anything in EJB.jar or utils.jar, I suspect b/c they >> are loaded prior to the aspect being loaded by the classloader. >> >> My pointcuts are all "execution" pointcuts. >> >> Similarly if I try to advise container classes with "execution" >> pointcuts, they never seem to trigger. >> >> Is there a simple solution for this? Does one need to take the >> class-loading sequence into account when using LTW? Thinking outloud, >> would changing all my "execution" pointcuts to "call" make a difference? >> >> My aop.xml is fairly basic: >> >> <aspectj> >> <aspects> >> <aspect name="com.security.logger.LoginLogger"/> >> <aspect name="com.security.logger.EJBAccessErrorLogger"/> >> </aspects> >> >> <weaver options="-verbose"> >> </weaver> >> </aspectj> >> >> Do I need to specify <includes> to the aspectj compiler? I thought all >> classes were "included" by default. >> >> Thanks! >> >> Eric >> >> >> _______________________________________________ >> aspectj-users mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> > _______________________________________________ > aspectj-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > _______________________________________________ > aspectj-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/aspectj-users >
_______________________________________________ aspectj-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/aspectj-users
