[JBoss JIRA] (AS7-3196) ERROR [AbstractKernelController] Error installing to Instantiated: name=AttachmentStore state=Described
by Kamal Suriyakumar (Created) (JIRA)
ERROR [AbstractKernelController] Error installing to Instantiated: name=AttachmentStore state=Described
-------------------------------------------------------------------------------------------------------
Key: AS7-3196
URL: https://issues.jboss.org/browse/AS7-3196
Project: Application Server 7
Issue Type: Clarification
Components: Server
Affects Versions: 7.1.0.Final, Open To Community
Environment: Jboss as7 server
Reporter: Kamal Suriyakumar
Assignee: Jason Greene
Priority: Blocker
Fix For: Open To Community
ERROR [AbstractKernelController] Error installing to Instantiated: name=AttachmentStore state=Described
java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[java.net.URI] actual=[java.io.File]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:395)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:153)
at org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(ReflectConstructorInfoImpl.java:106)
at org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:80)
at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.createTarget(AOPConstructorJoinpoint.java:282)
at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:103)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:66)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:319)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:297)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
at org.jboss.bootstrap.microcontainer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:91)
at org.jboss.bootstrap.microcontainer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:161)
at org.jboss.bootstrap.microcontainer.ServerImpl.doStart(ServerImpl.java:138)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:450)
at org.jboss.Main.boot(Main.java:221)
at org.jboss.Main$1.run(Main.java:556)
at java.lang.Thread.run(Thread.java:722)
Failed to boot JBoss:
java.lang.IllegalStateException: Incompletely deployed:
DEPLOYMENTS IN ERROR:
Deployment "AttachmentStore" is in error due to: java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[java.net.URI] actual=[java.io.File]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (AS7-3211) If possible, eliminate the NonTxEmCloser by closing the EM immediately after each EM invocation
by Scott Marlow (Created) (JIRA)
If possible, eliminate the NonTxEmCloser by closing the EM immediately after each EM invocation
-----------------------------------------------------------------------------------------------
Key: AS7-3211
URL: https://issues.jboss.org/browse/AS7-3211
Project: Application Server 7
Issue Type: Task
Reporter: Scott Marlow
Priority: Minor
Fix For: 7.2.0.Alpha1
For Queries, handoff the EntityManager to a Query object wrapper and have the Query object finalizer close the EntityManager.
Make sure that we respect JPA 2.0 section 3.8.6 (detach objects returned from Query object).
1. Methods that return a Query, will hand off the EM to the Query object wrapper.
2. Other methods will close the EM at the end of the EM method invocation.
When making this change, make sure that performance doesn't degrade. The cost of this change, will be that each (transaction scoped non-tx) EM invocation will create a new persistence context, but we can eliminate the NonTxEmCloser which has its own overhead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (JBRULES-3103) "A and not(B after A)" type rules don't fire when session clock has negative values (pre Unix epoch)
by Richard Calmbach (JIRA)
"A and not(B after A)" type rules don't fire when session clock has negative values (pre Unix epoch)
----------------------------------------------------------------------------------------------------
Key: JBRULES-3103
URL: https://issues.jboss.org/browse/JBRULES-3103
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core, drools-core (fusion)
Affects Versions: 5.2.0.Final
Reporter: Richard Calmbach
Assignee: Mark Proctor
See JBRULES-3100 for the gory details. The implementation described there causes two bugs, so THIS IS NOT A DUPLICATE of JBRULES-3100. Rather, the bugs are related, and because it is possible to fix one without the other, it makes sense to track both bugs explicitly, so that the developers can ensure that both bugs get fixed. The summary of this issue also conveys to users that this particular bug has already been reported.
So, *this* bug prevents rules of the form
$a: A()
not(B(this after $a))
or "A and not(B after A)" in pseudocode, from firing when they should if the session clock has a negative value, say during a simulation or if the system clock is turned back pre Unix epoch. This is confirmed for the pseudo clock, and I believe the real-time clock is equally affected. The root of the problem is that "A and not(B after A)" type rules get a duration of Long.MAX_VALUE assigned. When that gets added to a non-positive current time, it results in a very large positive number for the trigger time, which will never be reached by the session clock, preventing the rule from ever firing.
The fix is probably to add the activation for such a rule to the agenda immediately, rather than schedule it for adding. This would yield the same behavior as when you compare the timestamps explicitly. For now, comparing timestamps explicitly instead of using "after" is a workaround for this bug.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months