I am currently developing an EJB 3.0 based application on the JBoss AS 5.0.0.GA and just recently the following warning showed up in the server log:
09:50:19,735 WARN [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
09:50:19,735 WARN [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
09:50:19,735 WARN [InterceptorRegistry] applicable interceptors is non-existent for ...
...
The warnings are generated as soon as an EJB (a stateless session bean) is injected into a backing bean of my JSF web-application. The beans do work without problems though, but I still would like to know where that warning comes from and what I can do to avoid it.
I have already searched a bit around, but haven't found a good answer (some say, bean developers do not have to worry, but its a warning, so I'd like to have a better solution):
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=147292
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180366
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140136
JBoss JIRA Issue about the warning (Not that helpful in my opinion)
So has anyone an explanation what causes the warning (in terms of a bean developer, not application server developer) and what to do to avoid it?
Update: I've just upgraded JBoss to 5.0.1.GA (Download, Release-Notes) but unfortunatly the warning still appears.
As far as I understand all the available sources on this warning, it is nothing a user of JBoss 5 can do anything about and is essentially just a reminder for the developers of JBoss that they use their own classes wrong.
Following the advice from the developers, I am now ignoring it by changing my logging configuration in conf/jboss-log4j.xml. I've just added:
<category name="org.jboss.ejb3.interceptors">
<priority value="ERROR" />
</category>
Even the JBoss EJB3 tutorial/documentation says you can safely ignore these warnings. Well if everyone can ignore these don't log them! It's frustrating to see this issue isn't being fixed.
I had the same problem, modify the ejb3-interceptors-aop.xml, and now works ok.
I've tried this modification in ejb3-interceptors-aop.xml
I've comment these lines :
<aspect name="InterceptorsFactory" factory="org.jboss.ejb3.interceptors.aop.InterceptorsFactory" scope="PER_INSTANCE"/>
<advice name="invoke" aspect="InterceptorsFactory"/>
and it Works
The warnings no longer appear in JBoss 5.1.0, but adding the category as Simon posted eliminates the logging of the warnings in 5.0.x
Just follow the steps
Stop JBoss and right click on the server instance and select clean
right click on the project and select run -> run configurations
select classpath -> add jars
Add Jars from JBoss ASHOME/client - jbossall-client.jar,JBoss ASHome/common/lib - all jars.
Apply and run.
Related
I'm using the "org.springframework.boot:spring-boot-devtools" dependency in my Grails application for the live reload of the application on code change. The problem is, it seems that this dependency is causing some conflict with drools.
On kieSession.setGlobal(name, value) in my code, I get the following error:
java.lang.RuntimeException: Illegal class for global. Expected [com.user.PersonAccount], found [com.user.PersonAccount]
Removing the "spring-boot-devtools" dependency fixes the issue but I need this dependency for the live reload, it's important in development.
Anyone knows why this dependency is causing this conflict? and what I can do to fix it or as a workaround?
Thanks in advance!
To whoever might have the same issue in future, the issue is already reported and described before: https://issues.redhat.com/browse/DROOLS-1540 and a fix has been included in drools starting from version 7.26.0.Final (https://github.com/kiegroup/drools/commit/85c5308031a84a0ac4086c1df363bb1b4b3c6af9)
If you don't want to upgrade to the latest version of drools, there's still a workaround to fix the issue which is already mentioned on the devtools page of spring-boot (https://docs.spring.io/spring-boot/docs/current/reference/html/using.html#using.devtools.restart.customizing-the-classload).
I added META-INF/spring-devtools.properties with the jars that I want to include in the restart classloader (mainly the drools + kie jars) & the issue is fixed.
When the devtools recompile the class, the byte code no longer matches the byte code from your rules. It's not doing a very good job of warning you, but what it's trying to say is "you are trying to give me a com.user.PersonAccount instance, but it doesn't look like what I know a com.user.PersonAccount instance should look like."
Therefore if you insist on using this tool which will recompile things on the fly, you'll need to also recompile and reload the rules on the fly. Or not use spring-boot-devtools.
When I go to the "Boot Dashboard" (Update: actually I see similar messages on each Spring view) view I see the message
Could not create the view: org.springframework.ide.eclipse.boot.dash.views.BootDashView
There is an icon to see the error logs beside it, so I deleted them, reopened STS, and I did not see any error.
Any guidance on how to resolve this or further debug it?
More info
After following Martin's advice and opening the Host OSGi Console and typing ss to get the short status and doing diag <id> on a few different things all I was ever able to get was similar to this,
org.springframework.ide.eclipse.boot.dash [962]
No resolution report for the bundle.
Martin mentioned looking for INSTALLED, but all I saw were ACTIVE, RESOLVED, STARTING, and <<LAZY>>. I ran diag on at least one bundle of each state, but got nothing any different than above (of course the names and IDs were different).
I was facing the similar issue with Spring Boot Dash view and using -clean option and restart STS worked for me.
Just faced the same issue upgrading to latest STS 3.8.3 based on Neon.2 (4.6.2). Starting with the -clean option did nothing for me, neither did uninstalling / reinstalling the Groovy Eclipse feature as discussed.
What resolved it for me was switching to a new clean workspace - the boot dashboard then started working again. Oddly, it also works if I now switch back to the old workspace. Before this, the module was showing as LAZY in the Host OSGi console, now it's ACTIVE:
966 ACTIVE org.springframework.ide.eclipse.boot.dash_3.8.3.201612191259-RELEASE
The problem was one of my Groovy Eclipse compiler plugins (it was 1.8, 1.9, 2.0, 2.1, or 2.2, not sure which). After uninstalling it the Boot Dashboard no longer has an error.
Since part of my question was wondering about how to get better insight into the problem (more than checking the error log, which was empty) I will not mark this answer as accepted.
I'm using WAS Liberty 8.5.5.5 under Java 7 (tried under Oracle java 7-8 and IBM java 7 as well).
When I create one NamedQuery, the code compiles, deployes, and runs fine.
However, If I try to use the NamedQueries annotation I get the following excpetion:
java.lang.ArrayStoreException: com.sun.proxy.$Proxy29
at sun.reflect.annotation.AnnotationParser.parseAnnotationArray(AnnotationParser.java:765)
at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:537)
at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:355)
at sun.reflect.annotation.AnnotationParser.parseAnnotation2(AnnotationParser.java:286)
at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:120)
at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:72)
at java.lang.Class.createAnnotationData(Class.java:3521)
at java.lang.Class.annotationData(Class.java:3510)
at java.lang.Class.getAnnotation(Class.java:3415)
After some investigation, I found the following two bugs:
ArrayStoreException in Jboss: https://issues.jboss.org/browse/JBAS-9392
ArrayStoreException when annotation declaring class missing: http://bugs.java.com/view_bug.do?bug_id=7183985
It seems that the javax.persistence.NamedQueries inteface is missing in the enviroment (stangely the javax.persinstence.NameQuery is present ...)
I use Eclipse Kepler for development, the deployment is also handled by the IDE.
On more thing; other developers using the same code base can successfully deploy and run the application with the afformentioned settings - so I suspect the deployment might be responsible for this issue.
Is there a way to "tell" the WAS to include the missing class runtime?
It took some time, but I found the solution.
We are using Ecliselink as a JPA provider, and load it accordingly:
<classloader commonLibraryRef="EclipseLinkLib" delegation="parentLast"/>
It seems that Eclipselink (version 2.5.2) contains the javax.persistence.NamedQuery interface, but not the javax.persistence.NamedQueries interface - this way WAS does not load the missing interface.
By changing delegation="parentFirst" the app works fine.
Hie all,
I indeed underline to points.
I have been trying jboss 7 + jboss tools (3.3).
When I tried to deploy an ejb project on jboss6. Nothing happend. I thus added an ejb-jar.xml file to my project and deployment occured. Strange, as the deployment descriptor is supposed to be optional since ejb3.0 (and is optional with helios+ jbosstools 3.2).
More problematic and unsolved until now, when I create a project and try to deploy on jboss 7, the project name, for instance, "testejb" is deployed as "testejbnull" (even with the ejb-jar.xml file set) :
java:global/testejbnull/TestBean!test.ejb.TestBeanLocal
java:app/testejbnull/TestBean!test.ejb.TestBeanLocal
java:module/TestBean!test.ejb.TestBeanLocal
java:global/testejbnull/TestBean
java:app/testejbnull/TestBean
java:module/TestBean
Well, weird, but when I try to lookup from my Servlet (by the mean of a good old InitialContext + lookup), I got :
10:14:07,681 ERROR [stderr] (http--127.0.0.1-8080-2) javax.naming.NameNotFoundException: Name 'TestBean!test.ejb.TestBeanLocal' not found in context ''
..Whatever the name I look up for (i.e. TestBean, TestBean!...., java:app/...).
I work on ubuntu, one of my colleagues tried on windows 7 and had the same result.
Is this a classical problem? How may we solve it?
For the moment I decided to keep Jboss6 + helios.
I ran into the "null" issues too, it's been fixed in milestone 4
https://issues.jboss.org/browse/JBIDE-10106
https://issues.jboss.org/browse/JBIDE-9711
You obviously bumped into a bug witht he "null" in the naming.
May I suggest you visit http://community.jboss.org/en/tools?view=discussions and speak up there and we can help figure out what problem you got with the milestone tools.
I just spent a half hour debugging some new code that's not broken because I forgot to check (again!) my logs for this dreaded message:
WARN openjpa.Enhance - Creating subclass for ...
I'm running OpenJPA 2.1.0 inside an OpenEJB 3.2 snapshot build, Java 1.6.0_25, and Eclipse Helios. My entities are enhanced using the ant PCEnhancerTask.
My META-INF/openjpa.xml contains
<property name="openjpa.RuntimeUnenhancedClasses" value="unsupported" />
<property name="openjpa.DynamicEnhancementAgent" value="false" />
Is there anyway with this EE configuration to have OpenJPA enforce the RuntimeUnenhancedClasses option as it does in an SE configuration?
I suspect my 'real' problem stems from an Eclipse svn update that sometimes touches my JPA entity source, causing a build that overwrites my enhanced classes.
It's frustrating how often I run a unit test from the IDE that fails in some weird way, and I go digging through my code looking for a problem when all I need to do is run the enhancer.
Put the <property name="openjpa.RuntimeUnenhancedClasses" value="unsupported" /> META-INF/persistence.xml.
Looks like we're logging this action on debug level (maybe it should be info level), but OpenEJB will set that property to the default as it was in OpenJPA 1.x so that apps that worked with OpenEJB 3.1.x/OpenJPA 1.x will still work without modification in 3.2.x. If the property is already set in the persistence.xml it will never be overridden, so setting it there will have the effect you want.
Open to suggestions on how to save others in the same boat some time in the future. Seems either looking in the openjpa.xml file and seeing the property set already or issuing the log message on info would do it -- or both.
It sounds like for whatever reason your properties aren't being picked up when running in the container.
I have a number of possible solutions:
Try setting your properties in META-INF/persistence.xml. I assume you have these properties in the openjpa.xml file for a reason, but it might help us figure out where the real problem is.
Set -Dopenjpa.RuntimeUnenhancedClasses=false as a JVM property. This will apply to all PUs for a given JVM.
Move to a version of OpenJPA that is >= 2.0.0. RuntimeUnenhancedClasses was turned off as the default behavior in that release.