[JBoss JIRA] Created: (JBAS-9229) hibernate fails to bind session factory name to jndi
by George Sapountzis (JIRA)
hibernate fails to bind session factory name to jndi
----------------------------------------------------
Key: JBAS-9229
URL: https://issues.jboss.org/browse/JBAS-9229
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JPA / Hibernate
Affects Versions: 7.0.0.Beta2
Reporter: George Sapountzis
Assignee: Scott Marlow
Put the following line in persistence.xml:
<property name="hibernate.session_factory_name" value="modelSessionFactory" />
Hibernate fails to bind modelSessionFactory.
Remove the following two lines from HibernatePersistenceProviderAdaptor.java
- properties.put("hibernate.jndi.java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
- properties.put("hibernate.jndi.java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
Then the bindind succeeds.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBRULES-3100) Long.MAX_VALUE duration for "A and not(B after A)" type rules causes invalid session clock time in rule RHS when running with pseudo clock
by Richard Calmbach (JIRA)
Long.MAX_VALUE duration for "A and not(B after A)" type rules causes invalid session clock time in rule RHS when running with pseudo clock
------------------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-3100
URL: https://issues.jboss.org/browse/JBRULES-3100
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
Ok, this is a subtle one. How did I run into this one? I need dynamic timers that are started in the RHS because Drools LHS syntax does not support dynamic timers. In order to be able to unit test my rules even with dynamic timers, I rely on the session clock (aka TimerService) to schedule and execute these manually defined jobs. Works beautifully with the real-time clock for all my rules, and also works with the pseudo clock for rules that don't have a negated unbounded "after" clause. However, the pseudo clock breaks the timers that are scheduled in the RHS of rules that have a LHS of type "A and not(B after A)". The reason is extremely subtle, and understanding it required an excursion into the inner workings of the rule engine, in particular its mechanism for scheduling activations of rules with non-zero duration. (Good thing that javadoc and sources are now available via Maven repositories for all Drools artifacts. Thank you, Drools team and the m2eclipse "Download Artifact Sources" checkbox!)
In PseudoClockScheduler.runCallBacks(), the pseudo clock checks whether any scheduled jobs need to be executed by comparing their trigger times to the current time (this.timer). For every job that is due, e.g., a scheduled rule activation, the pseudo clock saves this.timer to a local variable (savedTimer) and sets this.timer temporarily to the trigger time of the job (keeping this.timer at that value for the duration of the job execution, e.g., the firing of the scheduled activation). Now, for rules with a bounded duration (e.g., "A and not(B after[0s, 10s] A"), this trigger time is a reasonable value (current time + duration), and everything works out. However, rules of type "A and not(B after A)" (i.e., with negated unbounded after) have a duration value of Long.MAX_VALUE. When DurationTimer.createTrigger() constructs a new PointInTimeTrigger object, it sets the trigger time to "current time + duration", and with a post-epoch current time (i.e., greater than zero) and duration == Long.MAX_VALUE, this causes wrap-around and sets the trigger time to a very large negative number. Up to this point, I think the behavior of the code is intentional (albeit hacky), to ensure that "negated unbounded after" type rules get activated right away (as they should). However, this approach has unintended, buggy consequences as we shall see. When such a scheduled rule fires, then for the duration of its RHS execution, the session clock has an invalid value (very large negative number). The only way how you would know that is if you queried the session clock, say because you're trying to schedule a dynamic timer because Drools LHS syntax only supports static timers. The upshot is that the dynamic timer job is scheduled with "very large negative number + my trigger delay" as the trigger time, which PseudoClockScheduler.runCallBacks() promptly interprets as a job that is due for execution, causing premature and therefore incorrect triggering of my dynamic timer, thereby breaking my unit tests, while the real-time clock does not exhibit this problem. And that's how I spent my Friday.
I can work around this bug by rewriting the "A and not(B after A)" construct so that I'm explicitly comparing the timestamp fields instead of using "after". However, the current Drools implementation is broken in more than one way: Say, you're simulating the events at the original Woodstock (or any other events pre-dating the Unix epoch), and you're setting the pseudo clock to a negative value so that Date.toString() gives you the actual dates of the simulated events. As long as current time is a non-positive value, adding duration == Long.MAX_VALUE will yield a time much, much later than current time. This means that "A and not(B after A)" type rules will not fire when they should because their trigger time is in a future far, far away that will never be reached during the simulation. If I interpret this correctly, this also affects rule activation with the real-time clock if it is set to a negative value (there goes your time traveler market share...).
I'm not sure what the best fix for these bugs is. A real fix probably has to rework how "negated unbounded after" type rule activations get scheduled. The duration == Long.MAX_VALUE hack isn't going to cut it. Maybe these rules don't need scheduling at all since their activations should be created right away? Anyway, tricky stuff.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 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
14 years, 4 months
[JBoss JIRA] Created: (JBAS-8845) JEE 6 application give errors when deploying
by Viggo Navarsete (JIRA)
JEE 6 application give errors when deploying
--------------------------------------------
Key: JBAS-8845
URL: https://issues.jboss.org/browse/JBAS-8845
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss 6.0.0.Final
Reporter: Viggo Navarsete
I've bundled an EAR with maven-ear-plugin (version 2.5-SNAPSHOT, with Java EE 6 features), where I've set the applicationName to tell how the JNDI tree should give names to my application.
Stacktrace:
21:14:29,954 WARN [org.jboss.profileservice.deployment.hotdeploy.HDScanner] Scan failed: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
DEPLOYMENTS MISSING DEPENDENCIES:
Deployment "jboss-switchboard:appName=mds,module=mds-console-web-1.1.9-SNAPSHOT" is missing the following dependencies:
Dependency "jboss.j2ee:ear=mds-ear-1.1.9-SNAPSHOT.ear,jar=mds-biz-ejb-1.1.9-SNAPSHOT.jar,name=MasterDataBean,service=EJB3" (should be in state "Installed", but is actually in state "Instantiated")
Deployment "jboss.ejb3:application=mds-ear-1.1.9-SNAPSHOT,module=mds-biz-ejb-1.1.9-SNAPSHOT,component=MDDValidatorBean,service=EjbEncFactory" is missing the following dependencies:
Dependency "jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=MDDValidatorBean,module=mds-biz-ejb-1.1.9-SNAPSHOT" (should be in state "Installed", but is actually in state "** NOT FOUND Depends on 'jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=MDDValidatorBean,module=mds-biz-ejb-1.1.9-SNAPSHOT' **")
Deployment "jboss.ejb3:application=mds-ear-1.1.9-SNAPSHOT,module=mds-biz-ejb-1.1.9-SNAPSHOT,component=MasterDataBean,service=EjbEncFactory" is missing the following dependencies:
Dependency "jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=MasterDataBean,module=mds-biz-ejb-1.1.9-SNAPSHOT" (should be in state "Installed", but is actually in state "** NOT FOUND Depends on 'jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=MasterDataBean,module=mds-biz-ejb-1.1.9-SNAPSHOT' **")
Deployment "jboss.ejb3:application=mds-ear-1.1.9-SNAPSHOT,module=mds-biz-ejb-1.1.9-SNAPSHOT,component=MasterDataXMLValidatorBean,service=EjbEncFactory" is missing the following dependencies:
Dependency "jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=MasterDataXMLValidatorBean,module=mds-biz-ejb-1.1.9-SNAPSHOT" (should be in state "Installed", but is actually in state "** NOT FOUND Depends on 'jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=MasterDataXMLValidatorBean,module=mds-biz-ejb-1.1.9-SNAPSHOT' **")
Deployment "jboss.ejb3:application=mds-ear-1.1.9-SNAPSHOT,module=mds-biz-ejb-1.1.9-SNAPSHOT,component=RbacBean,service=EjbEncFactory" is missing the following dependencies:
Dependency "jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=RbacBean,module=mds-biz-ejb-1.1.9-SNAPSHOT" (should be in state "Installed", but is actually in state "** NOT FOUND Depends on 'jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=RbacBean,module=mds-biz-ejb-1.1.9-SNAPSHOT' **")
Deployment "jboss.j2ee:ear=mds-ear-1.1.9-SNAPSHOT.ear,jar=mds-biz-ejb-1.1.9-SNAPSHOT.jar,name=MDDValidatorBean,service=EJB3" is missing the following dependencies:
Dependency "jboss.ejb3:application=mds-ear-1.1.9-SNAPSHOT,component=MDDValidatorBean,module=mds-biz-ejb-1.1.9-SNAPSHOT,service=EjbEncFactory" (should be in state "Installed", but is actually in state "Described")
Dependency "org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/MDDValidatorBean" (should be in state "Installed", but is actually in state "** NOT FOUND Depends on 'org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/MDDValidatorBean' **")
Deployment "jboss.j2ee:ear=mds-ear-1.1.9-SNAPSHOT.ear,jar=mds-biz-ejb-1.1.9-SNAPSHOT.jar,name=MDDValidatorBean,service=EJB3_endpoint" is missing the following dependencies:
Dependency "jboss.j2ee:ear=mds-ear-1.1.9-SNAPSHOT.ear,jar=mds-biz-ejb-1.1.9-SNAPSHOT.jar,name=MDDValidatorBean,service=EJB3" (should be in state "Installed", but is actually in state "Instantiated")
Deployment "jboss.j2ee:ear=mds-ear-1.1.9-SNAPSHOT.ear,jar=mds-biz-ejb-1.1.9-SNAPSHOT.jar,name=MasterDataBean,service=EJB3" is missing the following dependencies:
Dependency "org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/MasterDataBean" (should be in state "Installed", but is actually in state "** NOT FOUND Depends on 'org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/MasterDataBean' **")
Dependency "jboss.ejb3:application=mds-ear-1.1.9-SNAPSHOT,component=MasterDataBean,module=mds-biz-ejb-1.1.9-SNAPSHOT,service=EjbEncFactory" (should be in state "Installed", but is actually in state "Described")
Deployment "jboss.j2ee:ear=mds-ear-1.1.9-SNAPSHOT.ear,jar=mds-biz-ejb-1.1.9-SNAPSHOT.jar,name=MasterDataBean,service=EJB3_endpoint" is missing the following dependencies:
Dependency "jboss.j2ee:ear=mds-ear-1.1.9-SNAPSHOT.ear,jar=mds-biz-ejb-1.1.9-SNAPSHOT.jar,name=MasterDataBean,service=EJB3" (should be in state "Installed", but is actually in state "Instantiated")
Deployment "jboss.j2ee:ear=mds-ear-1.1.9-SNAPSHOT.ear,jar=mds-biz-ejb-1.1.9-SNAPSHOT.jar,name=MasterDataXMLValidatorBean,service=EJB3" is missing the following dependencies:
Dependency "jboss.ejb3:application=mds-ear-1.1.9-SNAPSHOT,component=MasterDataXMLValidatorBean,module=mds-biz-ejb-1.1.9-SNAPSHOT,service=EjbEncFactory" (should be in state "Installed", but is actually in state "Described")
Dependency "org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/MasterDataXMLValidatorBean" (should be in state "Installed", but is actually in state "** NOT FOUND Depends on 'org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/MasterDataXMLValidatorBean' **")
Deployment "jboss.j2ee:ear=mds-ear-1.1.9-SNAPSHOT.ear,jar=mds-biz-ejb-1.1.9-SNAPSHOT.jar,name=MasterDataXMLValidatorBean,service=EJB3_endpoint" is missing the following dependencies:
Dependency "jboss.j2ee:ear=mds-ear-1.1.9-SNAPSHOT.ear,jar=mds-biz-ejb-1.1.9-SNAPSHOT.jar,name=MasterDataXMLValidatorBean,service=EJB3" (should be in state "Installed", but is actually in state "Instantiated")
Deployment "jboss.j2ee:ear=mds-ear-1.1.9-SNAPSHOT.ear,jar=mds-biz-ejb-1.1.9-SNAPSHOT.jar,name=RbacBean,service=EJB3" is missing the following dependencies:
Dependency "org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/RbacBean" (should be in state "Installed", but is actually in state "** NOT FOUND Depends on 'org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/RbacBean' **")
Dependency "jboss.ejb3:application=mds-ear-1.1.9-SNAPSHOT,component=RbacBean,module=mds-biz-ejb-1.1.9-SNAPSHOT,service=EjbEncFactory" (should be in state "Installed", but is actually in state "Described")
Deployment "jboss.j2ee:ear=mds-ear-1.1.9-SNAPSHOT.ear,jar=mds-biz-ejb-1.1.9-SNAPSHOT.jar,name=RbacBean,service=EJB3_endpoint" is missing the following dependencies:
Dependency "jboss.j2ee:ear=mds-ear-1.1.9-SNAPSHOT.ear,jar=mds-biz-ejb-1.1.9-SNAPSHOT.jar,name=RbacBean,service=EJB3" (should be in state "Installed", but is actually in state "Instantiated")
Deployment "jboss.web.deployment:war=/mds-console-web" is missing the following dependencies:
Dependency "jboss-switchboard:appName=mds,module=mds-console-web-1.1.9-SNAPSHOT" (should be in state "Installed", but is actually in state "Deploy")
DEPLOYMENTS IN ERROR:
Deployment "org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/RbacBean" is in error due to the following reason(s): ** NOT FOUND Depends on 'org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/RbacBean' **
Deployment "jboss.ejb3:application=mds-ear-1.1.9-SNAPSHOT,component=MDDValidatorBean,module=mds-biz-ejb-1.1.9-SNAPSHOT,service=EjbEncFactory" is in error due to the following reason(s): Described
Deployment "org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/MasterDataXMLValidatorBean" is in error due to the following reason(s): ** NOT FOUND Depends on 'org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/MasterDataXMLValidatorBean' **
Deployment "jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=MDDValidatorBean,module=mds-biz-ejb-1.1.9-SNAPSHOT" is in error due to the following reason(s): ** NOT FOUND Depends on 'jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=MDDValidatorBean,module=mds-biz-ejb-1.1.9-SNAPSHOT' **
Deployment "jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=MasterDataXMLValidatorBean,module=mds-biz-ejb-1.1.9-SNAPSHOT" is in error due to the following reason(s): ** NOT FOUND Depends on 'jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=MasterDataXMLValidatorBean,module=mds-biz-ejb-1.1.9-SNAPSHOT' **
Deployment "org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/MasterDataBean" is in error due to the following reason(s): ** NOT FOUND Depends on 'org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/MasterDataBean' **
Deployment "org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/MDDValidatorBean" is in error due to the following reason(s): ** NOT FOUND Depends on 'org.jboss.ejb.bean.instantiator/mds-ear-1.1.9-SNAPSHOT/mds-biz-ejb-1.1.9-SNAPSHOT/MDDValidatorBean' **
Deployment "jboss.ejb3:application=mds-ear-1.1.9-SNAPSHOT,component=MasterDataBean,module=mds-biz-ejb-1.1.9-SNAPSHOT,service=EjbEncFactory" is in error due to the following reason(s): Described
Deployment "jboss.ejb3:application=mds-ear-1.1.9-SNAPSHOT,component=MasterDataXMLValidatorBean,module=mds-biz-ejb-1.1.9-SNAPSHOT,service=EjbEncFactory" is in error due to the following reason(s): Described
Deployment "jboss.ejb3:application=mds-ear-1.1.9-SNAPSHOT,component=RbacBean,module=mds-biz-ejb-1.1.9-SNAPSHOT,service=EjbEncFactory" is in error due to the following reason(s): Described
Deployment "jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=RbacBean,module=mds-biz-ejb-1.1.9-SNAPSHOT" is in error due to the following reason(s): ** NOT FOUND Depends on 'jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=RbacBean,module=mds-biz-ejb-1.1.9-SNAPSHOT' **
Deployment "jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=MasterDataBean,module=mds-biz-ejb-1.1.9-SNAPSHOT" is in error due to the following reason(s): ** NOT FOUND Depends on 'jboss.naming:application=mds-ear-1.1.9-SNAPSHOT,component=MasterDataBean,module=mds-biz-ejb-1.1.9-SNAPSHOT' **
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1370) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1316) [:2.2.0.GA]
at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:968) [:2.2.0.GA]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.checkComplete(MainDeployerPlugin.java:82) [:6.0.0.Final]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.checkComplete(ProfileControllerContext.java:138) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:246) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2]
at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2]
at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_22]
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_22]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]
When I remove the applicationName it deploys correctly.
The maven-ear-plugin setup is like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<configuration>
<defaultLibBundleDir>lib</defaultLibBundleDir>
<generateApplicationXml>true</generateApplicationXml>
<version>6</version> <!-- Only applicable when generateApplicationXml is true! (JEE version?!)-->
<applicationName>mds</applicationName>
<jboss>
<version>5</version> <!-- JBoss AS version -->
<library-directory>/lib</library-directory>
<loader-repository>com.tracetracker:loader=${project.build.finalName}.ear</loader-repository>
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</jboss>
</configuration>
</plugin>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBRULES-3161) CEP - event both in and out of time window at the same time
by Radai Rosenblatt (JIRA)
CEP - event both in and out of time window at the same time
-----------------------------------------------------------
Key: JBRULES-3161
URL: https://issues.jboss.org/browse/JBRULES-3161
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.2.0.Final
Environment: jre 6u24, windows 7 x64
Reporter: Radai Rosenblatt
Assignee: Mark Proctor
Priority: Critical
given this object:
public class Event {
private Date started;
private Date finished;
private long duration;
//getters and setters
}
the following drools code:
declare Event
@role( event )
@duration ( duration )
@timestamp( started )
end
rule "Event Exists In Window"
when
$eventOne : Event() over window:time( 1h ) from entry-point "Event Stream"
then
//nothing
end
rule "No Event Exists In Window"
when
not ( Event() over window:time( 1h ) from entry-point "Event Stream" )
then
//nothing
end
and the following scenario:
now-1.5h the event now+1h
|---------------------------------------|
the window
|------------------|
---------------------------------|-------------> T
now
(an event at time T that start at T-1.5h and ends at T+1h)
both of the above rules fire. im not sure which of them _should_ fire for this scenario, but im pretty sure its either one or the other (to my understanding the conditions are logically exclusive - there either exists an event in the window or there doesnt)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months