[JBoss JIRA] (AS7-6419) Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-6419?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri commented on AS7-6419:
--------------------------------------
Could you please include your module.xml. At a first look it seems to me you are missing a dependency there.
> Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception
> -----------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6419
> URL: https://issues.jboss.org/browse/AS7-6419
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.2.0.Alpha1
> Environment: Configuration:
> JDK-Version: 1.6.0_33
> Operating System: Windows 7 (32 Bit)
> JBoss Application Server jboss-as-7.2.0.Alpha1-SNAPSHOT (build Dec. 19th 2012)
> JDK-Version: 1.6.0_33
> Resource Adapter: BeanConnect 3.0 developed by our Company (Fujitsu)
> Reporter: Martin Keller
> Assignee: Stefano Maestri
>
> Tbis Problem was reported before see https://issues.jboss.org/browse/AS7-6384, but now the components to reproduce it is included.
> Starting an application using our JCA 1.6 resource adapter fails with
> java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
> It works ok in the JBoss JCA 1.5 environment and on other application servers with JCA1.6 environment:
> GlassFish OS Edition 3, IBM WebSphere 8.0 and WebLogic 12.
> Questions:
> What could be the cause for this exception?
> Can we switch off the validation?
> What is missing to run the validation successful?
> Details:
> The full stack is:
> 15:04:02,128 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool – 64) MSC00001: Failed to start service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:177)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> ... 7 more
> Caused by: javax.resource.ResourceException: IJ000852: Validation exception
> at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:147)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:175)
> ... 8 more
> Caused by: javax.validation.ValidationException: Unable to find a default provider
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:264) [validation-api-1.0.0.GA.jar:]
> at org.jboss.jca.core.bv.BeanValidationUtil.createValidatorFactory(BeanValidationUtil.java:51)
> at org.jboss.jca.core.bv.BeanValidationUtil.createValidator(BeanValidationUtil.java:63)
> at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:135)
> ... 9 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (DROOLS-18) [Error: incompatible types in statement: boolean (compared from: class be.axi.planner.domain.Task)]
by Michiel Vermandel (JIRA)
[ https://issues.jboss.org/browse/DROOLS-18?page=com.atlassian.jira.plugin.... ]
Michiel Vermandel commented on DROOLS-18:
-----------------------------------------
Hi, Mario, I think I found the problem.
My PlanningEntity has both a "getLead()" method and a "isLead()" method.
getLead() returns the lead task of this task and isLead() checks if this task is the lead.
I think that if I use "... task == lead ..." in a rule LHS condition, the (mvel?)parser sometimes maps lead to getLead() - which is OK - and sometimes maps lead to isLead() - which is not OK => Task.class <==> Boolean.class
> [Error: incompatible types in statement: boolean (compared from: class be.axi.planner.domain.Task)]
> ---------------------------------------------------------------------------------------------------
>
> Key: DROOLS-18
> URL: https://issues.jboss.org/browse/DROOLS-18
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Windows 7 64Bit
> Java 1.7.0
> Drools-core 5.5.0.Final
> Drools-compiler 5.5.0.Final
> Mvel2 2.1.3.Final
> Reporter: Michiel Vermandel
> Assignee: Mario Fusco
> Priority: Critical
>
> In about one out of ten JUnit runs, I get a crash with stack trace.
> The process terminates immediately.
> Unit test output is 100% the same on successful runs.
> Stack trace:
> [Error: incompatible types in statement: boolean (compared from: class be.axi.planner.domain.Task)]
> [Near : {... this == lead ....}]
> ^
> [Line: 1, Column: 1]
> at org.mvel2.ast.BinaryOperation.<init>(BinaryOperation.java:84)
> at org.mvel2.util.CompilerTools.finalizePayload(CompilerTools.java:118)
> at org.mvel2.compiler.ExpressionCompiler._compile(ExpressionCompiler.java:287)
> at org.mvel2.compiler.ExpressionCompiler.compile(ExpressionCompiler.java:62)
> at org.mvel2.MVEL.compileExpression(MVEL.java:810)
> at org.drools.base.mvel.MVELCompilationUnit.compile(MVELCompilationUnit.java:435)
> at org.drools.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
> at org.drools.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:206)
> at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:190)
> at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
> at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
> at org.drools.planner.core.score.director.drools.DroolsScoreDirector.afterEntityAdded(DroolsScoreDirector.java:103)
> at org.drools.planner.core.heuristic.selector.variable.PlanningVariableWalker.moveIterator(PlanningVariableWalker.java:145)
> at org.drools.planner.core.constructionheuristic.greedyFit.decider.DefaultGreedyDecider.decideNextStep(DefaultGreedyDecider.java:74)
> at org.drools.planner.core.constructionheuristic.greedyFit.DefaultGreedyFitSolverPhase.solve(DefaultGreedyFitSolverPhase.java:65)
> at org.drools.planner.core.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190)
> at org.drools.planner.core.solver.DefaultSolver.solve(DefaultSolver.java:155)
> at be.axi.planner.app.InspectionSchedule.solve(InspectionSchedule.java:192)
> at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:288)
> at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:298)
> at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:315)
> at be.axi.planner.TaskGroupingTest.communitySuccess02(TaskGroupingTest.java:289)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (DROOLS-18) [Error: incompatible types in statement: boolean (compared from: class be.axi.planner.domain.Task)]
by Michiel Vermandel (JIRA)
[ https://issues.jboss.org/browse/DROOLS-18?page=com.atlassian.jira.plugin.... ]
Michiel Vermandel edited comment on DROOLS-18 at 1/30/13 8:48 AM:
------------------------------------------------------------------
Hi, Mario, I think I found the problem.
My PlanningEntity has both a "getLead()" method and a "isLead()" method.
getLead() returns the lead task of this task and isLead() checks if this task is the lead.
I think that if I use "... task == lead ..." in a rule LHS condition, the (mvel?)parser sometimes maps lead to getLead() - which is OK - and sometimes maps lead to isLead() - which is not OK => Task.class <==> Boolean.class
I changed the isLead() method to isLeader() and I did not get the crash anymore.
was (Author: mvermand):
Hi, Mario, I think I found the problem.
My PlanningEntity has both a "getLead()" method and a "isLead()" method.
getLead() returns the lead task of this task and isLead() checks if this task is the lead.
I think that if I use "... task == lead ..." in a rule LHS condition, the (mvel?)parser sometimes maps lead to getLead() - which is OK - and sometimes maps lead to isLead() - which is not OK => Task.class <==> Boolean.class
> [Error: incompatible types in statement: boolean (compared from: class be.axi.planner.domain.Task)]
> ---------------------------------------------------------------------------------------------------
>
> Key: DROOLS-18
> URL: https://issues.jboss.org/browse/DROOLS-18
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Windows 7 64Bit
> Java 1.7.0
> Drools-core 5.5.0.Final
> Drools-compiler 5.5.0.Final
> Mvel2 2.1.3.Final
> Reporter: Michiel Vermandel
> Assignee: Mario Fusco
> Priority: Critical
>
> In about one out of ten JUnit runs, I get a crash with stack trace.
> The process terminates immediately.
> Unit test output is 100% the same on successful runs.
> Stack trace:
> [Error: incompatible types in statement: boolean (compared from: class be.axi.planner.domain.Task)]
> [Near : {... this == lead ....}]
> ^
> [Line: 1, Column: 1]
> at org.mvel2.ast.BinaryOperation.<init>(BinaryOperation.java:84)
> at org.mvel2.util.CompilerTools.finalizePayload(CompilerTools.java:118)
> at org.mvel2.compiler.ExpressionCompiler._compile(ExpressionCompiler.java:287)
> at org.mvel2.compiler.ExpressionCompiler.compile(ExpressionCompiler.java:62)
> at org.mvel2.MVEL.compileExpression(MVEL.java:810)
> at org.drools.base.mvel.MVELCompilationUnit.compile(MVELCompilationUnit.java:435)
> at org.drools.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
> at org.drools.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:206)
> at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:190)
> at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
> at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
> at org.drools.planner.core.score.director.drools.DroolsScoreDirector.afterEntityAdded(DroolsScoreDirector.java:103)
> at org.drools.planner.core.heuristic.selector.variable.PlanningVariableWalker.moveIterator(PlanningVariableWalker.java:145)
> at org.drools.planner.core.constructionheuristic.greedyFit.decider.DefaultGreedyDecider.decideNextStep(DefaultGreedyDecider.java:74)
> at org.drools.planner.core.constructionheuristic.greedyFit.DefaultGreedyFitSolverPhase.solve(DefaultGreedyFitSolverPhase.java:65)
> at org.drools.planner.core.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190)
> at org.drools.planner.core.solver.DefaultSolver.solve(DefaultSolver.java:155)
> at be.axi.planner.app.InspectionSchedule.solve(InspectionSchedule.java:192)
> at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:288)
> at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:298)
> at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:315)
> at be.axi.planner.TaskGroupingTest.communitySuccess02(TaskGroupingTest.java:289)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (JGRP-1410) globalThreadGroup not destroyed creates a classloader memory leak
by Mattias Jiderhamn (JIRA)
[ https://issues.jboss.org/browse/JGRP-1410?page=com.atlassian.jira.plugin.... ]
Mattias Jiderhamn commented on JGRP-1410:
-----------------------------------------
There seems to be another one of these, see JGRP-1576
> globalThreadGroup not destroyed creates a classloader memory leak
> -----------------------------------------------------------------
>
> Key: JGRP-1410
> URL: https://issues.jboss.org/browse/JGRP-1410
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.0.1
> Environment: linux w/ java 1.6
> Reporter: Jean-Philippe Gariepy
> Assignee: Bela Ban
> Fix For: 3.2.2, 3.3
>
>
> When all channels are closed, the globalThreadGroup is not destroyed. For a normal (i.e. non-web) application, this is not a problem since the process will exit anyway. However, for a Java Enterprise web application, this causes a classloader memory leak since the ThreadGroup object has strong references to JGroups instances having strong references to their class object having strong reference to their class loader. Since the class loader is pointed by strong references, the it cannot be garbage collected and hence a leak is created each time the web application is stopped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (JGRP-1576) org.jgroups.protocols.TP.ChannelThreadGroup leaks classloaders / PermGen memory
by Mattias Jiderhamn (JIRA)
Mattias Jiderhamn created JGRP-1576:
---------------------------------------
Summary: org.jgroups.protocols.TP.ChannelThreadGroup leaks classloaders / PermGen memory
Key: JGRP-1576
URL: https://issues.jboss.org/browse/JGRP-1576
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.2.5
Reporter: Mattias Jiderhamn
Assignee: Bela Ban
Just like JGRP-1410 there is a custom ThreadGroup org.jgroups.protocols.TP.ChannelThreadGroup which is not destroyed so the parent thread group will keep a reference and keep the classloader from being garbage collected. There is actually code for destroying the thread groups (line 1026-1030) but for some reason it is commented out.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-6419) Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/AS7-6419?page=com.atlassian.jira.plugin.s... ]
Jesper Pedersen reassigned AS7-6419:
------------------------------------
Assignee: Stefano Maestri (was: Jesper Pedersen)
> Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception
> -----------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6419
> URL: https://issues.jboss.org/browse/AS7-6419
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.2.0.Alpha1
> Environment: Configuration:
> JDK-Version: 1.6.0_33
> Operating System: Windows 7 (32 Bit)
> JBoss Application Server jboss-as-7.2.0.Alpha1-SNAPSHOT (build Dec. 19th 2012)
> JDK-Version: 1.6.0_33
> Resource Adapter: BeanConnect 3.0 developed by our Company (Fujitsu)
> Reporter: Martin Keller
> Assignee: Stefano Maestri
>
> Tbis Problem was reported before see https://issues.jboss.org/browse/AS7-6384, but now the components to reproduce it is included.
> Starting an application using our JCA 1.6 resource adapter fails with
> java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
> It works ok in the JBoss JCA 1.5 environment and on other application servers with JCA1.6 environment:
> GlassFish OS Edition 3, IBM WebSphere 8.0 and WebLogic 12.
> Questions:
> What could be the cause for this exception?
> Can we switch off the validation?
> What is missing to run the validation successful?
> Details:
> The full stack is:
> 15:04:02,128 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool – 64) MSC00001: Failed to start service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:177)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> ... 7 more
> Caused by: javax.resource.ResourceException: IJ000852: Validation exception
> at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:147)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:175)
> ... 8 more
> Caused by: javax.validation.ValidationException: Unable to find a default provider
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:264) [validation-api-1.0.0.GA.jar:]
> at org.jboss.jca.core.bv.BeanValidationUtil.createValidatorFactory(BeanValidationUtil.java:51)
> at org.jboss.jca.core.bv.BeanValidationUtil.createValidator(BeanValidationUtil.java:63)
> at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:135)
> ... 9 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (JGRP-1564) TP: passing messages up in batches
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1564?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1564:
---------------------------
Summary: TP: passing messages up in batches (was: TP: message batches)
> TP: passing messages up in batches
> ----------------------------------
>
> Key: JGRP-1564
> URL: https://issues.jboss.org/browse/JGRP-1564
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages).
> It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go.
> The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message (fewer lock acquisitions).
> We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up.
> The unmarshalling shouldn't take long, so TP.receive() should return quickly.
> This approach would allow us to send OOB messages in message batches, too (currently not allowed).
> The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST/2 and NAKACK/2, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal.
> The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT, SIZE, FRAG(2) (if placed under UNICAST/NAKACK), COMPRESS etc. However, we could add another up(Batch) method, which by default (in Protocol):
> - removes all messages for a given protocol P (by P.ID)
> and calls up(Event.MSG, msg) for all messages in the batch
> - calls up_prot.up(batch) if the batch is not empty
> This would allow for all current protocols to continue working and only the protocols which don't check for headers and/or need special processing (such as UNICAST and NAKACK) would have to implement up(Batch).
> This solution would be better than introducing another event type MSG_BATCH, as not every protocol overriding up(Event) calls super.up(Event).
> However, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-6419) Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception
by Martin Keller (JIRA)
Martin Keller created AS7-6419:
----------------------------------
Summary: Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception
Key: AS7-6419
URL: https://issues.jboss.org/browse/AS7-6419
Project: Application Server 7
Issue Type: Bug
Components: JCA
Affects Versions: 7.2.0.Alpha1
Environment: Configuration:
JDK-Version: 1.6.0_33
Operating System: Windows 7 (32 Bit)
JBoss Application Server jboss-as-7.2.0.Alpha1-SNAPSHOT (build Dec. 19th 2012)
JDK-Version: 1.6.0_33
Resource Adapter: BeanConnect 3.0 developed by our Company (Fujitsu)
Reporter: Martin Keller
Assignee: Jesper Pedersen
Tbis Problem was reported before see https://issues.jboss.org/browse/AS7-6384, but now the components to reproduce it is included.
Starting an application using our JCA 1.6 resource adapter fails with
java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
It works ok in the JBoss JCA 1.5 environment and on other application servers with JCA1.6 environment:
GlassFish OS Edition 3, IBM WebSphere 8.0 and WebLogic 12.
Questions:
What could be the cause for this exception?
Can we switch off the validation?
What is missing to run the validation successful?
Details:
The full stack is:
15:04:02,128 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool – 64) MSC00001: Failed to start service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_33]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_33]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_33]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:177)
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
... 7 more
Caused by: javax.resource.ResourceException: IJ000852: Validation exception
at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:147)
at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:175)
... 8 more
Caused by: javax.validation.ValidationException: Unable to find a default provider
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:264) [validation-api-1.0.0.GA.jar:]
at org.jboss.jca.core.bv.BeanValidationUtil.createValidatorFactory(BeanValidationUtil.java:51)
at org.jboss.jca.core.bv.BeanValidationUtil.createValidator(BeanValidationUtil.java:63)
at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:135)
... 9 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-6408) Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
by Bernd Koecke (JIRA)
[ https://issues.jboss.org/browse/AS7-6408?page=com.atlassian.jira.plugin.s... ]
Bernd Koecke commented on AS7-6408:
-----------------------------------
Hello Tomaz,
I changed my script and now also the new way is working perfectly.
Thanks a lot,
Bernd
> Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
> ---------------------------------------------------------------------------
>
> Key: AS7-6408
> URL: https://issues.jboss.org/browse/AS7-6408
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.2.0.Alpha1
> Environment: Git checkout of JBossAS 7.2.0.ALPHA1 from today (28/Jan/2013)
> Reporter: Bernd Koecke
> Assignee: Tomaz Cerar
> Fix For: 7.2.0.Alpha1
>
> Attachments: standalone-ha-jgroups.cli, standalone-jgroups-fragment.xml
>
>
> When I try to configure extension and subsystem JGroups with a CLI script, the attribute "protocols" of the stack=tcp- or stack=udp-node contains the list of configured protocols twice. The result is that the list of protocols is doubled in the standalone.xml. But having a protocol twice in one stack results in an error at next server startup. I will attach the CLI script and the resulting XML fragment.
> When I shutdown the server, remove the doubled second part of each protocol list, the server comes up and all is working fine. But I can't configure it only with a CLI script.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-6408) Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
by Bernd Koecke (JIRA)
[ https://issues.jboss.org/browse/AS7-6408?page=com.atlassian.jira.plugin.s... ]
Bernd Koecke closed AS7-6408.
-----------------------------
All is working fine :).
> Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
> ---------------------------------------------------------------------------
>
> Key: AS7-6408
> URL: https://issues.jboss.org/browse/AS7-6408
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.2.0.Alpha1
> Environment: Git checkout of JBossAS 7.2.0.ALPHA1 from today (28/Jan/2013)
> Reporter: Bernd Koecke
> Assignee: Tomaz Cerar
> Fix For: 7.2.0.Alpha1
>
> Attachments: standalone-ha-jgroups.cli, standalone-jgroups-fragment.xml
>
>
> When I try to configure extension and subsystem JGroups with a CLI script, the attribute "protocols" of the stack=tcp- or stack=udp-node contains the list of configured protocols twice. The result is that the list of protocols is doubled in the standalone.xml. But having a protocol twice in one stack results in an error at next server startup. I will attach the CLI script and the resulting XML fragment.
> When I shutdown the server, remove the doubled second part of each protocol list, the server comes up and all is working fine. But I can't configure it only with a CLI script.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months