Community
Participate
Working Groups
Build Identifier: AspectJ 1.6.12.M1 / AJDT 2.1.3 / http://download.eclipse.org/tools/ajdt/36/update We cannot load an ear application under GlassFish 3.1.2 Open source, Weld 1.1.4, Eclispe Indigo, because a final method related to the Around advice. We got the following exception: {code} GRAVE: Exception while loading the app : Exception List with 2 exceptions: Exception 0 : org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437 Normal scoped bean class com.nested.web.controller.PanelTwoController is not proxyable because the type is final or it contains a final method static final boolean com.nested.web.controller.PanelTwoController.validate_aroundBody0(com.nested.web.controller.PanelTwoController,org.aspectj.lang.JoinPoint) - Managed Bean [class com.nested.web.controller.PanelTwoController] with qualifiers [@Any @Default @Named]. at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:225) at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:178) at org.jboss.weld.util.Proxies.getUnproxyableTypesExceptionInt(Proxies.java:193) at org.jboss.weld.util.Proxies.getUnproxyableTypesException(Proxies.java:167) at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:110) {code} The bug has been also reported in Weld bug tracker under: ID: WELD-1123 Title : WELD-000075 error message with AspectJ URL: https://issues.jboss.org/browse/WELD-1123 You can download the demo/workbench also from the site. However the demo is running with the native aspectJ. The message we got now is more accurate because we use aspectJ annotation but the error is the same. Let me know if we you want the demo. Reproducible: Always Steps to Reproduce: 1.Please read the readme.txt file under NestedWeb directory 2.Under eclipse Indigo 2.1 make an empty NestedEar project (ear) 2.2 make an empty NestedWeb project (war) 2.3 Copy paste the source file into NestedWeb project. 2.4 Build and deploy the project 3. Launch the workbench : http://localhost:8080/NestedWeb/index.html 4. You should see the home page "Integration Bug Hunter" with a tab panel
Created attachment 214991 [details] Here is the workbench - Please read the readme.txt file. We remove from web-inf/lib the library - The readme.txt file will inform you which libraries are necessary. Do not hesitate to request any information you need.
Please, do not forget to test the fix also for other CDI like OWB (Open Web Bean) because we have already reported a such bug to IBM which use OWB 1.0. It seems that the bug is also related to aspectJ but we do not have more info. IBM has fix le bug by given us a patch and the fix will be available for 8.0.0.1, fix pack 3 or 8.0.0.3 You can use easily the workbench for that, make it yours and thank you for your work.
I've seen a situation like this a long time ago but can't recall the specifics. The act of weaving introduces a final method and then that type cannot be proxied due to the final method. You could try to compile with the option -XnoInline - this will adjust the weaving process to use closures rather than inlining around advice. That may affect the existence of the final methods. Specify the flag in the compiler options field in AspectJ project properties. I can add a new option to support creation of non-final methods (it would be a compile time flag), that would be a straightforward way to address this. Wish I could recall the conclusion of this issue when it came up before. I don't suppose their proxy support has a way to ignore certain methods does it? By name/annotation or something? or some option to 'ignore final' ?
Hello Andrew, If my understanding is good, just specify noinline should work. So I can do the test on RAD because there is an option of noinline. But from my point of view it is a workaround because you have "inline" for performance, isn't it? CDI container does not allow final method. However, we have seen by the past that CDI container have also some bugs related to final method. "private final" method should be authorize... See : https://issues.jboss.org/browse/SOLDER-99 So, the first question is : It is a bug from CDI or from AspectJ?. You can probably talk to WELD debugging team to clarify the issue. It will probably good to have a such flag, also good to have a message that tell us that there is an option we can activate to avoid final especially for CDI container. Best regards, :)
Created attachment 215177 [details] No-Inline compiler option from Eclipse Indigo.
Hello, As shown the screen shot, if we talk to the same no-inline (see screen shot), setting the flag does not work in our case. We still have the same issue. {code} WELD-001437 Normal scoped bean class com.nested.web.converter.NameConverter is not proxyable because the type is final or it contains a final method static final java.lang.Object com.nested.web.converter.NameConverter.getAsObject_aroundBody0(com.nested.web.converter.NameConverter,javax.faces.context.FacesContext,javax.faces.component.UIComponent,java.lang.String,org.aspectj.lang.JoinPoint) - Managed Bean [class com.nested.web.converter.NameConverter] with qualifiers [@Named @Any @Default]. {code}
> If my understanding is good, just specify noinline should work. So I can do the > test on RAD because there is an option of noinline. But from my point of view > it is a workaround because you have "inline" for performance, isn't it? Yep, if it had worked it would just have been a workaround for you. I wasn't 100% confident as I don't immediately recall which infrastructure methods are generated regardless of whether the advice is being inlined or not. > So, the first question is : It is a bug from CDI or from AspectJ?. You can > probably talk to WELD debugging team to clarify the issue. It is unfortunate that AspectJ (for performance reasons) is creating a final method that the CDI cannot be told to ignore. I'm not sure I can call it a bug on either side as separately neither tool is doing anything wrong, they just aren't working together. it is a feature request for AspectJ to optionally make these things non-final so they can be proxied, or could be a feature request for CDI to enable final methods to be ignored/skipped for proxy generation. > It will probably good to have a such flag, also good to have a message that > tell us that there is an option we can activate to avoid final especially for > CDI container. The option is fine, but telling you about the option would be tricky as AspectJ doesn't know you are going to use it with proxy generation. I think reporting on every weave of around advice that you might want to use this flag would be a bit messy as it doesn't matter for most cases.
I'm just playing around with around weaving right now. I observer that in my case the methods are 'private static'. Are you confident the CDI you are using has that fix in that you referenced? (https://issues.jboss.org/browse/CDI-159) Could be worth checking the woven code has the around method as private, can you check? Just use 'javap -verbose' on the woven type (PanelTwoController). I only ask to confirm as the visibility isn't shown in the original exception you attached to the bug report.
finally got the project building after tracking down the dependencies from the interweb. Not sure I have exactly the same version jars as you, but it is compiling. Running javap on PanelTwoController (to confirm visibility) I see: private static final boolean validate_aroundBody0(com.nested.web.controller.PanelTwoController, org.aspectj.lang.JoinPoint); private static final boolean validate_aroundBody1$advice(com.nested.web.controller.PanelTwoController, org.aspectj.lang.JoinPoint, com.nested.aspects.LoggingBehavior, org.aspectj.lang.ProceedingJoinPoint, org.aspectj.lang.JoinPoint, org.aspectj.lang.JoinPoint$StaticPart, com.nested.aspects.LoggingBehavior$Loggable); so that does point to 'private static' failing to be ignored by the proxy generation. I probably wouldn't put the switch into AspectJ unless we can confirm CDI isn't to blame here.
Thank you very much for the feed back Yes about the CDI "private final", I was aware but in my case, I use WELD 1.1.4... then it should be solved. Unfortunately, I did know how to update the CDI container of GlassFish, Weld is now at the version 1.1.6 (March 2012)... For the version of libraries used by the workbench, you should have a readme.txt file at the root of NestedWebx folder. The file gives the instructions how to install the workbench in different platforms. What the implementation and version of CDI did you use? I'm going to talk to Weld bug Team - Thank you.
> Yes about the CDI "private final", I was aware but in my case, I use WELD > 1.1.4... then it should be solved. Unfortunately, I did know how to update the > CDI container of GlassFish, Weld is now at the version 1.1.6 (March 2012)... > What the implementation and version of CDI did you use? I'm going to talk to > Weld bug Team - Thank you. Oh, my apologies, I'm not an expert on this CDI business. I didn't actually run anything, I was just looking at the woven code to check the around infrastructure methods hadn't accidentally been made public. Depending on what the Weld team say, maybe I can still add this option if you really need it - I'd only need a couple of hours to add support for it. > For the version of libraries used by the workbench, you should have a > readme.txt file at the root of NestedWebx folder. The file gives the > instructions how to install the workbench in different platforms. I did use the readme but I didn't find that it listed all the jars I needed and for some of those listed I just couldn't track down the download locations. But, in the end, I got something that builds so that's ok.
