I am getting below Exception while I try to Update or Delete any item from database using openJPA:
Caused by: java.lang.NullPointerException
at org.apache.openjpa.kernel.StateManagerImpl.replaceObjectField(StateManagerImpl.java:2076)
at org.apache.openjpa.enhance.com$freightliner$viva$dao$VivaSubgroupItems$pcsubclass.pcReplaceField(Unknown Source)
at org.apache.openjpa.kernel.StateManagerImpl.replaceField(StateManagerImpl.java:3041)
at org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2473)
at org.apache.openjpa.kernel.StateManagerImpl.storeObject(StateManagerImpl.java:2463)
at org.apache.openjpa.jdbc.meta.strats.StoreCollectionFieldStrategy.load(StoreCollectionFieldStrategy.java:573)
at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:819)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:692)
at com.ibm.ws.persistence.jdbc.kernel.WsJpaJDBCStoreManager.load(WsJpaJDBCStoreManager.java:125)
at org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:116)
at org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:78)
at org.apache.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:2937)
at org.apache.openjpa.kernel.StateManagerImpl.loadField(StateManagerImpl.java:3015)
at org.apache.openjpa.kernel.StateManagerImpl.fetchObjectField(StateManagerImpl.java:2258)
at org.apache.openjpa.kernel.StateManagerImpl.fetchField(StateManagerImpl.java:778)
at org.apache.openjpa.kernel.StateManagerImpl.fetch(StateManagerImpl.java:740)
at org.apache.openjpa.enhance.RedefinitionHelper$1.invoke(RedefinitionHelper.java:230)
at com.sun.proxy.$Proxy17.isEmpty(Unknown Source)
at org.apache.openjpa.kernel.AttachStrategy.attachField(AttachStrategy.java:213)
at org.apache.openjpa.kernel.VersionAttachStrategy.attach(VersionAttachStrategy.java:153)
at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:241)
at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:101)
at org.apache.openjpa.kernel.BrokerImpl.attach(BrokerImpl.java:3244)
... 6 more
You need to use a different enhancement strategy. You must have set openjpa.RuntimeUnenhancedClasses=supported which is leading you astray. That feature is buggy at best.
You will need to either setup build time enhancement, or configured the -javaagent enhancer.
Related
I spent a whole bunch of time today working out a problem that occurred on migrating from Optaplanner 7.48 to Optaplanner 8.3.0 The problem seems to me to be actually in the 7.50 version of Drools that Optaplanner 8.3 depends on.
rule "applyHomeTeamConstraints"
enabled true
when $f1: ProblemFixture(slot != null, $ht: homeTeam)
$tu: ProblemSoftConstraint(this memberOf $ht.constraints,
matches($f1.slot.dateTime) )
then
scoreHolder.penalize(kcontext, -$tu.getWeight());
end
The rule worked perfectly happily in Optaplanner 7.48/Drools 7.48.
When I use this rule in my Optaplanner 8.3.0/Drools 7.50 project, I get an exceptionally unhelpful message...
java.lang.IllegalStateException: There is an error in a scoreDrl or scoreDrlFile.
at uk.me.selwyn_family.league.scheduler.solver.SolverTest.testBuildSeasonSolver(SolverTest.java:47)
Caused by: java.lang.UnsupportedOperationException
at uk.me.selwyn_family.league.scheduler.solver.SolverTest.testBuildSeasonSolver(SolverTest.java:47)
After many hours of tracing I found that the exception was actually thrown at line 243 in org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper
Expression parentLeft = findLeftLeafOfNameExpr(halfPointFreeExpr.getParentNode().orElseThrow(UnsupportedOperationException::new));
and occurs because the parentNode is null.
I can solve the problem by simply add this. in front of the matches() as follows...
rule "applyHomeTeamConstraints"
enabled true
when $f1: ProblemFixture(slot != null, $ht: homeTeam)
$tu: ProblemSoftConstraint(this memberOf $ht.constraints,
this.matches($f1.slot.dateTime) )
then
scoreHolder.penalize(kcontext, -$tu.getWeight());
end
I am trying to work out whether it was only working by accident in the 7.48 version and actually should never have worked or whether a bug has crept into the Drools 7.50 that should be reported.
Either way a more helpful error message would be good!
Any suggestions gratefully received.
Update: Now I have told Surefire not to trimStackTrace here is the full trace...
java.lang.IllegalStateException: There is an error in a scoreDrl or scoreDrlFile.
at org.optaplanner.core.impl.score.director.ScoreDirectorFactoryFactory.buildDroolsScoreDirectorFactory(ScoreDirectorFactoryFactory.java:280)
at org.optaplanner.core.impl.score.director.ScoreDirectorFactoryFactory.decideMultipleScoreDirectorFactories(ScoreDirectorFactoryFactory.java:103)
at org.optaplanner.core.impl.score.director.ScoreDirectorFactoryFactory.buildScoreDirectorFactory(ScoreDirectorFactoryFactory.java:68)
at org.optaplanner.core.impl.solver.DefaultSolverFactory.buildScoreDirectorFactory(DefaultSolverFactory.java:116)
at org.optaplanner.core.impl.solver.DefaultSolverFactory.getScoreDirectorFactory(DefaultSolverFactory.java:73)
at org.optaplanner.core.api.score.ScoreManager.create(ScoreManager.java:59)
at uk.me.selwyn_family.league.scheduler.solver.SeasonSolver.<init>(SeasonSolver.java:31)
at uk.me.selwyn_family.league.scheduler.solver.SolverTest.testBuildSeasonSolver(SolverTest.java:47)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:696)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:882)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1189)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
at org.testng.SuiteRunner.run(SuiteRunner.java:254)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
at org.testng.TestNG.run(TestNG.java:1057)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:136)
at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:112)
at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:145)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
Caused by: java.lang.UnsupportedOperationException
at java.base/java.util.Optional.orElseThrow(Optional.java:408)
at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.toTypedExpressionRec(ExpressionTyper.java:243)
at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.toTypedExpression(ExpressionTyper.java:153)
at org.drools.modelcompiler.builder.generator.drlxparse.ConstraintParser.getDrlxParseResult(ConstraintParser.java:174)
at org.drools.modelcompiler.builder.generator.drlxparse.ConstraintParser.drlxParse(ConstraintParser.java:104)
at org.drools.modelcompiler.builder.generator.visitor.pattern.PatternDSL.findAllConstraint(PatternDSL.java:139)
at org.drools.modelcompiler.builder.generator.visitor.pattern.PatternDSL.buildPattern(PatternDSL.java:241)
at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:145)
at org.drools.compiler.lang.descr.PatternDescr.accept(PatternDescr.java:303)
at org.drools.modelcompiler.builder.generator.visitor.AndVisitor.visit(AndVisitor.java:50)
at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:86)
at org.drools.modelcompiler.builder.generator.ModelGenerator.processRule(ModelGenerator.java:187)
at org.drools.modelcompiler.builder.generator.ModelGenerator.generateModel(ModelGenerator.java:160)
at org.drools.modelcompiler.builder.ModelBuilderImpl.compileKnowledgePackages(ModelBuilderImpl.java:284)
at org.drools.modelcompiler.builder.ModelBuilderImpl.buildRules(ModelBuilderImpl.java:220)
at org.drools.modelcompiler.builder.ModelBuilderImpl.postBuild(ModelBuilderImpl.java:130)
at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:115)
at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:99)
at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:268)
at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:216)
at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:80)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:277)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:245)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:202)
at org.kie.internal.utils.KieHelper.getKieContainer(KieHelper.java:100)
at org.kie.internal.utils.KieHelper.build(KieHelper.java:82)
at org.optaplanner.core.impl.score.director.ScoreDirectorFactoryFactory.buildDroolsScoreDirectorFactory(ScoreDirectorFactoryFactory.java:272)
... 36 more
(No wonder it took me a long time to trace!!!)
This sounds like a regression in Drools. Yes, that error message isn't helpful - that too is an issue (note that Drools has improved a lot to get better error messages and the new way to write constraints (ConstraintStreams) has far more useful stacktraces).
One thing that doesn't make sense to me is your stacktrace:
java.lang.IllegalStateException: There is an error in a scoreDrl or scoreDrlFile.
at uk.me.selwyn_family.league.scheduler.solver.SolverTest.testBuildSeasonSolver(SolverTest.java:47)
Caused by: java.lang.UnsupportedOperationException
at uk.me.selwyn_family.league.scheduler.solver.SolverTest.testBuildSeasonSolver(SolverTest.java:47)
This stacktrace doesn't mention lines of org.optaplanner or org.drools. Can you please share the code of SolverTest.java:47 too so we can verify it doesn't covert/eat the exception? The message does seem to come from OptaPlanner, but a true OptaPlanner exception would have a chained (= caused by) exception coming from a line in org.drools with hopefully more information for us to diagnose why it doesn't give a proper error message.
I have an application presently running (without issue) on JBoss 6 that I am attempting to upgrade to run on WildFly 10.1. Much of this upgrade is going well. However, the upgrade from Hibernate 3.4 (on JBoss 6) to Hibernate 5.1 (on WildFly 10.1) is causing a few issues.
Specifically, in my persistence.xml, I include the following property.
<property name="hibernate.hbm2ddl.auto" value="update"/>
Please NOTE: I am NOT making any schema or other DB changes as part of the upgrade. Furthermore, I am pointing at the same database instance that has been successfully running under the JBoss 6/Hibernate 3.4 instance. Therefore, I am confident that inclusion of this property should have no actual work/update to do upon first run with the WildFly 10.1/Hibernate 5.1 version.
However, inclusion of this property appears to 1) erroneously determine that it needs to make updates and 2) fail to do so successfully. It results in the following stack trace:
Failed to start service jboss.persistenceunit."app.ear#PU": org.jboss.msc.service.StartException in service jboss.persistenceunit."PU": javax.persistence.PersistenceException: [PersistenceUnit: PU] Unable to build Hibernate SessionFactory
...
Caused by: javax.persistence.PersistenceException: [PersistenceUnit: PU] Unable to build Hibernate SessionFactory
...
Caused by: org.hibernate.tool.schema.spi.SchemaManagementException: Unable to execute schema management to JDBC target [create index company_id_index on APPROVER (COMPANY_ID)]
...
Caused by: org.postgresql.util.PSQLException: ERROR: relation "company_id_index" already exists
Again, the table and index in question already exist (as confirmed by the final error).
Is Hibernate now no longer case sensitive (COMPANY_ID_INDEX being different than company_id_index)?
If so, how can I configure it so that it is case insensitive as it used to be (Postgres defaults all of this to lower....)
TIA!
Doh! Face palm! I recently discovered that similar errors were also occurring related to hbm2ddl index creation with Hibernate 3.4/JBoss 6 as I am now experiencing with Hibernate 5.1/Wildfly 10.1; however, they were NOT preventing successful start up of the persistence module. Essentially, they were being only subtly suppressed. I'm not sure if this is an expected change related to the Hibernate versions or not, as they do prevent it's start up in Hibernate 5.1/Wildfly 10.1?
The underlying issue here turned out to be that index names must be unique across the entire schema in Postgres. So multiple entities each having a FK to a COMPANY_ID column must each have a unique name for the index. Indices are relations in Postgres (driving the unique across schema requirement).
Thank you for the suggestions and apologies for the confusion.
When I looked at Spring Boot, I liked the idea that it:
Gets out of the way quickly if you want to change defaults. - Dave Syer, Spring One 2GX 2013
It wasn't long before practicality hit me. While trying to make Boot work with a 100% Groovy/no-XML pet project, I found 2 issues in 2 days. Here's one of them.
Groovy config file:
beans {
xmlns([ctx:'http://www.springframework.org/schema/context'])
ctx.'component-scan'('base-package':'name.abhijitsarkar.moviedatabase')
}
Exception:
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Failed to read XML document; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: Unable to determine validation mode for [Groovy]: cannot open InputStream. Did you attempt to load directly from a SAX InputSource without specifying the validationMode on your XmlBeanDefinitionReader instance?; nested exception is java.io.FileNotFoundException: Groovy cannot be opened because it does not point to a readable resource
at org.springframework.beans.factory.xml.XmlReaderContext.readDocumentFromString(XmlReaderContext.java:98)
at org.springframework.beans.factory.xml.XmlReaderContext$readDocumentFromString.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at org.springframework.beans.factory.groovy.GroovyDynamicElementReader.invokeMethod(GroovyDynamicElementReader.groovy:96)
Also posted on Spring forum.
Im using XWIKI ENTERPRISE 2.5 and want to upgrade it to 4.4 or 4.3 (stable)
I found this upgrade documentation for XWiki. Following the guide, I backed up the important files in WEB-INF.
After that, I copied all the files from the new .war to my wiki directory (/var/lib/tomcat6/webapps/xwiki). Then, I moved back the important files and overwrote the new files.
I get this error message, when I visit my wiki page:
HTTP Status 404 - type Status report
message description
The requested resource () is not available.
Apache Tomcat/6.0.28
Here is the logfile:
SCHWERWIEGEND: Exception sending context initialized event to listener instance of class org.xwiki.container.servlet.XWikiServletContextListener
java.lang.RuntimeException: Failed to find the Observation Manager component
at org.xwiki.container.servlet.XWikiServletContextListener.contextInitialized(XWikiServletContextListener.java:101)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4135)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4630)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:546)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445)
at org.apache.catalina.core.StandardService.start(StandardService.java:519)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:581)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [org.xwiki.observation.internal.DefaultObservationManager] identifier by [role = [interface org.xwiki.observation.ObservationManager] hint = [default]]
at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:348)
at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:155)
at org.xwiki.container.servlet.XWikiServletContextListener.contextInitialized(XWikiServletContextListener.java:99)
... 24 more
Caused by: org.xwiki.component.phase.InitializationException: Failed to lookup Event Listeners
at org.xwiki.observation.internal.DefaultObservationManager.initialize(DefaultObservationManager.java:139)
at org.xwiki.component.embed.InitializableLifecycleHandler.handle(InitializableLifecycleHandler.java:39)
at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:323)
at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:378)
at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:346)
... 26 more
Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [interface org.xwiki.observation.EventListener] hint = [default]]
at org.xwiki.component.embed.EmbeddableComponentManager.getInstanceMap(EmbeddableComponentManager.java:187)
at org.xwiki.component.embed.EmbeddableComponentManager.getInstanceList(EmbeddableComponentManager.java:169)
at org.xwiki.observation.internal.DefaultObservationManager.initialize(DefaultObservationManager.java:135)
... 30 more
Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [org.xwiki.security.authorization.cache.internal.DefaultSecurityCache] identifier by [role = [interface org.xwiki.security.authorization.cache.SecurityCache] hint = [default]]
at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:348)
at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:161)
at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:312)
at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:378)
at org.xwiki.component.embed.EmbeddableComponentManager.getInstanceMap(EmbeddableComponentManager.java:185)
... 32 more
Caused by: org.xwiki.component.phase.InitializationException: Unable to create the security cache with a capacity of 500
at org.xwiki.security.authorization.cache.internal.DefaultSecurityCache.newCache(DefaultSecurityCache.java:104)
at org.xwiki.security.authorization.cache.internal.DefaultSecurityCache.initialize(DefaultSecurityCache.java:112)
at org.xwiki.component.embed.InitializableLifecycleHandler.handle(InitializableLifecycleHandler.java:39)
at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:323)
at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:378)
at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:346)
... 36 more
Caused by: org.xwiki.cache.CacheException: Failed to get cache factory for role hint [infinispan]
at org.xwiki.cache.internal.DefaultCacheManager.createNewCache(DefaultCacheManager.java:109)
at org.xwiki.cache.internal.DefaultCacheManager.createNewCache(DefaultCacheManager.java:85)
at org.xwiki.security.authorization.cache.internal.DefaultSecurityCache.newCache(DefaultSecurityCache.java:102)
... 41 more
Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [org.xwiki.cache.infinispan.internal.InfinispanCacheFactory] identifier by [role = [interface org.xwiki.cache.CacheFactory] hint = [infinispan]]
at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:348)
at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:161)
at org.xwiki.cache.internal.DefaultCacheManager.createNewCache(DefaultCacheManager.java:107)
... 43 more
Caused by: org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.xwiki.infinispan
at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:73)
at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:92)
at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:86)
at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:46)
at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:62)
at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:720)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:388)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:353)
at org.xwiki.cache.infinispan.internal.InfinispanCacheFactory.initialize(InfinispanCacheFactory.java:104)
at org.xwiki.component.embed.InitializableLifecycleHandler.handle(InitializableLifecycleHandler.java:39)
at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:323)
at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:378)
at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:346)
... 45 more
When you say that
I copied all the files from the new .war to my wiki directory
Did you copy the new files over the existing directory? You're supposed to delete everything from the old version and use only the files from the new version, and only copy from the backup the essential configuration files. Also, note that you're not supposed to just copy the old configuration, but merge your custom settings into the default new configuration.
The root error in the stack trace:
Caused by: org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.xwiki.infinispan
suggest a duplicate jar. The other case when this could occur is when you have more than one instance of XWiki in the same container, in which case you should edit WEB-INF/cache/infinispan/config.xml, and replace the line jmxDomain="org.xwiki.infinispan" with a unique value, like jmxDomain="org.xwiki.infinispan.wiki1" and jmxDomain="org.xwiki.infinispan.wiki2" for the two instances.
I've been having the same problem when upgrading from 4.0-rc-1 to 4.4 or 4.5. I have no duplicate jars nor am I running several instances of XWiki. It may be there is an issue either in infinispan or in XWiki's cache implementation.
A temporary workaround is to allow duplicate domains explicitly in config.xml :
<globalJmxStatistics
[...]
allowDuplicateDomains="true" />
I have an application deployed on Glassfish v3.0.1 which reads events from a table in my database. Once ready it marks them as processed. I am getting a strange error I can't explain when trying to call the method which does the update.
#Override
#TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void markEventAsProcessed(Long eventId) {
try {
AtlasEventQueueUpdateAsProcessedQuery setEventAsProcessed = new AtlasEventQueueUpdateAsProcessedQuery(entityManager, eventId);
int updateCount = setEventAsProcessed.execute();
logger.debug("Mark Event [" + eventId + "] processed");
return updateCount;
} catch (QueryException ex) {
logger.error("Event [" + eventId + "has not been marked as processed", ex);
}
}
When this is called in my application I am getting the following exception (Full trace at the bottom of the post):
Caused by: javax.ejb.AccessLocalException: Client not authorized for this invocation.
Does anyone know what might cause this error I have loked on the Web but didn't find anything useful.
2010-08-27 09:44:37,380 ERROR [Ejb-Timer-Thread-1 :EventProvider ] Unhandled exception in event processing - javax.ejb.EJBAccessException
javax.ejb.EJBAccessException
at com.sun.ejb.containers.BaseContainer.mapLocal3xException(BaseContainer.java:2262)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2053)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1955)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:198)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:84)
at $Proxy190.markEventAsProcessed(Unknown Source)
at com.company.atlas.eventprocessor.provider.EventProvider.processNewEvents(EventProvider.java:170)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1056)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1128)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5292)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:615)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:567)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:157)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:858)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:367)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5264)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5252)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:3965)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1667)
at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:98)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2485)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.ejb.AccessLocalException: Client not authorized for this invocation.
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1850)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:188)
... 34 more
I've deleted the directory domains/domainx/generated/policy/<appname>/
and completly redeployed (not just restarted) the app.. its working now as expected.
The GlassFish documentation has an entry for this error:
javax.ejb.AccessLocalException: Client Not Authorized Error
Description
Role-mapping information is available
in Sun-specific XML (for example,
sun-ejb-jar.xml), and authentication
is okay, but the following error
message is displayed:
[...INFO|sun-appserver-pe8.0|javax.enterprise.system.container.ejb|...|
javax.ejb.AccessLocalException: Client not authorized for this invocation.
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:...
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(...)
Solution
Check whether the EJB module (.jar)
or web module (.war) is packaged in
an application (.ear) and does not
have role-mapping information in
application level, Sun-specific,
sun-application.xml. For any
application (.ear), security
role-mapping information must be
specified in sun-application.xml. It
is acceptable to have both
module-level XML and application-level
XML.
I don't know if it makes sense in your context.
If it doesn't, maybe have a look at the following thread Persisting Entity: javax.ejb.AccessLocalException: Client not authorized for this invocation. One of the poster suggested to set the logging level of the SECURITY Logger to FINE [so that] the Glassfish Policy subsystem will log a detailed message describing the nature of the failed permission check. This might help. And I can't tell you if you're facing the same problem but the OP solved his issue by cleaning the generated policy files:
This exception can also occur, if you try to copy and paste EJB session beans with new methods, as patch files for fixing bugs or incorporating new features. Restarting the server or disabling & enabling the enterprise app will not help, as the EJB Session beans or entities have to be repackaged and redeployed, so that the App server registers the new methods and checks and grants/excludes the access privileges to the new/altered methods in EJB session beans.
I had the same problem here when injecting a Stateless SessionBean (TransactionAttribute.REQUIRES_NEW) into an other Stateless SessionBean. For me restarting the server solved it for me...
Just wanted to let you know ;-)
I had the same issue. I'm not using any kind of access control on the service but on one instance of glassfish everything worked fine, on another, I got this error but only on some methods. I added #PermitAll and redeployed the service and everything started working.
On Glassfish 3.1.2 at least, sometimes a previous iteration of a bean that has changed will choke Glassfish at deployment. The app will run until it gets to whatever bit of code that should be called but can't be because the previously deployed class is still there. I think Glassfish might keep track of each and prevent the new code from calling the old code, but I haven't really been that keen to worry about it as the solution is simple enough:
Stop the server, go to the domain directory and delete all the files and sub-directories in the application directory. Then do the same in the generated and osgi-cache directories. Restart the server and rebuild/redeploy.
I had this same Error but mine was caused from this:
<c:set var="speciesList" value="#{timberSaleController.distinctSaleSpecies}" />
the function:
public List<Species> getDistinctSaleSpecies()
{
return ejbFacade.getDistinctSpeciesForAllSales();
}
when i changed the set tag to this it worked:
<c:set var="speciesList" value="#{timberSaleController.getDistinctSaleSpecies()}" />