Community
Participate
Working Groups
Created attachment 284415 [details] zip containing very small app that illustrates the issue when running under JBoss EAP 7.2 I have a very small app that runs in JBoss EAP 7.2 which uses an AspectJ aspect advices execution around HttpServletResponse.sendRedirect(String) as follows: @Around("execution(* javax.servlet.http.HttpServletResponse.sendRedirect(String))") However this advice only works when I wrap the response object (passed in directly from JSP) with a class extending from javax.servlet.http.HttpServletResponseWrapper with an override to the implementation of sendRedirect(String). To reproduce, please read README.txt on smallapp root folder in attached zip. My goal is to have the advice work with no wrapping at all.
I was able to resolve the issue by overriding JBOSS's base io.undertow.servlet module in a custom layer as follows: a) Create a copy of $JBOSS_HOME/modules/system/layers/base/io/undertow/servlet/main in new custom 'cgi' layer $JBOSS_HOME/modules/system/layers/cgi/io/undertow/servlet/main b) Add the following dependency to module test.aspect inside $JBOSS_HOME/modules/system/layers/cgi/io/undertow/servlet/main/module.xml c) Insert META-INF/aop.xml declaring aspect test.aspects.SmallAppAspect inside $JBOSS_HOME/modules/system/layers/cgi/io/undertow/servlet/main/undertow-servlet-2.0.15.Final-redhat-00001.jar d) Copy layers.conf file onto $JBOSS_HOME/modules with the following content: layers=cgi,base This tells JBOSS that modules in the cgi layer take precedence in load order over modules defined in base layer
The issue with overriding JBOSS module base jar by inserting my custom META-INF/aop.xml file is that it complicates processing of JBOSS upgrades/patches that may include changes to the jar. It also prevents signed jars from being modified in this fashion - i.e. I would not be able to advice classes from JBOSS base layer that are signed. To solve that issue I was able to successfully modify the AspectJ Agent to use an alternate weavingContext class that overrides org.aspectj.weaver.loadtime.DefaultWeavingContext.getResources(String) and looks for META-INF/aop.xml optionally from a different location (outside of the current Module Class Loader). This allowed me to keep my custom aop.xml file in a separate directory keeping the jar in my custom layer identical to the one in the base layer. However, it required quite a lot of work and copy/paste overrides JUST to have AspectJ agent use a different org.aspectj.weaver.loadtime.IWeavingContext implementation so I will be opening a new feature request to allow the implementation of this interface to be easily configured via a new aspectj system property.
