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 <ebenza...@gmail.com>: > > 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" <alexan...@kriegisch.name> >> 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 >> aspectj-users@eclipse.org >> 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 > aspectj-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/aspectj-users
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/aspectj-users
