[JBoss JIRA] (JBRULES-3715) when using BigDecimal Comparing to 0 only works for a certain number of time
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3715?page=com.atlassian.jira.plug... ]
Mario Fusco commented on JBRULES-3715:
--------------------------------------
Considering that in Java:
new BigDecimal("0").equals(new BigDecimal("0.0"))
is false I'd actually say that it starts working only after a certain number of times.
To be more precise the constraints are evaluated in an interpreted mode (using mvel) for that "certain number of times" and after that they get jitted via ASM and run in compiled mode. The problem is that, while the jitted constraint applies the Java semantic above and correctly returns false, the interpreted (mvel) one does something slightly different and actually evaluates
new BigDecimal("0").compareTo(new BigDecimal("0.0")) == 0
that evaluates to true.
We are still discussing which of these 2 semantics fits better the drools needs but in the meanwhile I strongly suggest to stick with the Java semantic and consider 0.0B and 0B as 2 different numbers.
> when using BigDecimal Comparing to 0 only works for a certain number of time
> ----------------------------------------------------------------------------
>
> Key: JBRULES-3715
> URL: https://issues.jboss.org/browse/JBRULES-3715
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: All
> Affects Versions: 5.4.0.Final
> Environment: Jdk1.6; Drools 5.5
> Reporter: Nicolas Heron
> Assignee: Mario Fusco
> Attachments: BugBigDecimalDrools.zip
>
>
> in a rule like this :
> rule "Hello World"
> dialect "mvel"
> no-loop
> when
> $c : Contract( aValue == 0.0B )
> then
> $c.setDone("OK");
> update($c);
> end
> when called a certain number of times, the comparaison does not work
--
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, 6 months
[JBoss JIRA] (JBJCA-962) Support AllIdleConnections and AllConnections for flush strategy
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-962?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen resolved JBJCA-962.
-----------------------------------
Resolution: Done
> Support AllIdleConnections and AllConnections for flush strategy
> ----------------------------------------------------------------
>
> Key: JBJCA-962
> URL: https://issues.jboss.org/browse/JBJCA-962
> Project: IronJacamar
> Issue Type: Task
> Components: Common, Core
> Reporter: Jesper Pedersen
> Assignee: Jesper Pedersen
> Fix For: 1.1.0.Beta4
>
>
> Add the flush strategy of 'AllIdleConnections' which will remove all idle connection from the entire pool, and 'AllConnections' which will remove all connections from the entire pool.
> The existing 'IdleConnections' will now only remove idle connections in the active sub pool, and 'EntirePool' will now remove all connections in the active sub pool. The sub pool is based on the credential separation.
--
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, 6 months
[JBoss JIRA] (JBJCA-962) Support AllIdleConnections and AllConnections for flush strategy
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-962:
-------------------------------------
Summary: Support AllIdleConnections and AllConnections for flush strategy
Key: JBJCA-962
URL: https://issues.jboss.org/browse/JBJCA-962
Project: IronJacamar
Issue Type: Task
Components: Common, Core
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.1.0.Beta4
Add the flush strategy of 'AllIdleConnections' which will remove all idle connection from the entire pool, and 'AllConnections' which will remove all connections from the entire pool.
The existing 'IdleConnections' will now only remove idle connections in the active sub pool, and 'EntirePool' will now remove all connections in the active sub pool. The sub pool is based on the credential separation.
--
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, 6 months
[JBoss JIRA] (JBRULES-3675) java.lang.LinkageError, but only sometimes (multithreading issue)
by Simon Raess (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3675?page=com.atlassian.jira.plug... ]
Simon Raess commented on JBRULES-3675:
--------------------------------------
What is the status of this issue? It is hitting us from time to time. Fix for 6.0.0 seems a bit late for such a major bug!
> java.lang.LinkageError, but only sometimes (multithreading issue)
> -----------------------------------------------------------------
>
> Key: JBRULES-3675
> URL: https://issues.jboss.org/browse/JBRULES-3675
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 5.4.0.Final
> Environment: - JBoss 7.1.1
> - drools 5.4.0.Final
> - jdk 1.6u30
> - Windows 7 64 bit
> Reporter: kenneth westelinck
> Assignee: Mario Fusco
> Fix For: 6.0.0.Alpha1
>
>
> See mail on mailinglist:
> {noformat}
> We have an application (A) deployed on JBoss 7.1.1 accepting commands (CQRS,
> but only C and Q :) ). A console application (B) is sending a large volume
> of commands to create entities in A. Entities in A are validated by Drools
> (plain drl files, configured in spring using drools-spring). Most of the
> time this works just fine. But sometimes, we get the following exception:
> java.lang.LinkageError: loader (instance of
> org/drools/rule/JavaDialectRuntimeData$PackageClassLoader): attempted
> duplicate class definition for name:
> "a/b/c/Rule_person_unique___name_656ee3db19d34e689d95e2d6b2be67b6"
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_30]
> at org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:615) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:254) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:237) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:88) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:295) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [rt.jar:1.6.0_30]
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0InvokerGenerated.evaluate(Unknown Source)
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0Invoker.evaluate(Unknown Source)
> at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> Any idea where this is coming from or what's causing this.
> {noformat}
> And the answer:
> {noformat}
> I have never experienced this myself, but after having a quick look at the code I believe this could be a multi-threading problem.
> In the abstract class java.lang.ClassLoader the method loadClass(String, boolean) is synchronized, but both org.drools.util.CompositeClassLoader
> and org.drools.rule.JavaDialectRuntimeData$PackageClassLoader override this method without the use of "synchronized".
> I would suggest you create a JIRA issue for this.
> {noformat}
> We are now trying 5.5.0.CR1 and so far, we have not encountered this issue. I'll keep you posted should the same issue appear on 5.5.0.CR1
--
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, 6 months
[JBoss JIRA] (AS7-6327) Create JPA service callback for invoking database migration
by Anil Arora (JIRA)
[ https://issues.jboss.org/browse/AS7-6327?page=com.atlassian.jira.plugin.s... ]
Anil Arora commented on AS7-6327:
---------------------------------
I would definitely like something that allows me to do whatever. In particular, I'm trying to use flyway (http://flywaydb.org) to bring the database up to speed. As far as I can tell, there's nothing really out there that exists to support this case, except if you use Seam or Spring and manage the EntityManagerFactory, whose creation is what triggers the validation of the schema.
I believe something is happening in future releases of the JPA, but having this support for earlier versions of the JPA would be extremely helpful.
> Create JPA service callback for invoking database migration
> -----------------------------------------------------------
>
> Key: AS7-6327
> URL: https://issues.jboss.org/browse/AS7-6327
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Anil Arora
> Assignee: Scott Marlow
>
> Looking for a simple callback/listener mechanism so that we can invoke a database migration script before JPA persistent unit starts up and runs the Hibernate schema validation mechanism.
> Ideally, there would be a property within the persistence.xml that indicates which class to call. It would also pass in/inject the datasource that is being used for the persistence unit.
> Essentially, this would solve the lack of migration support in Hibernate itself.
--
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, 6 months
[JBoss JIRA] (AS7-6257) AttributeDefinition validateOperation should convert all expression strings to ModelType.EXPRESSION
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6257?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6257:
---------------------------------------
An IRC discussion of pros and cons of this, confirming the decision to defer to 7.3:
bstansberry: maeste, kkhan, ctomc: re the general problem of expression strings not getting converted to ModelType.EXPRESSION...
[09:14am] bstansberry: AS7-6257
[09:14am] jbossbot: jira [AS7-6257] AttributeDefinition validateOperation should convert all expression strings to ModelType.EXPRESSION [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/AS7-6257
[09:14am] bstansberry: I'm tempted to fix that in 7.2
[09:14am] bstansberry: I scheduled it for 7.3 partly due to time constraints
[09:15am] bstansberry: now somewhat loosened
[09:15am] kkhan: bstansberry: Isn't that really a job for the parser? Then again I know CLI handles this somehow, but not sure about the console
[09:15am] ctomc: i dont think it would break that much if at all
[09:15am] bstansberry: and partly due to really vageue compatibilty concerns
[09:15am] bstansberry: kkhan: the parser is inadequate
[09:15am] bstansberry: since mgmt ops can come from arbitrary clients
[09:15am] bstansberry: CLI is inadequate as well for the same reason
[09:16am] bstansberry: this is why we convert in validateOperation as well
[09:16am] kkhan: It makes sense, but what about the corner case where someone **wants** a string of the form ${blah} for who knows what reason
[09:17am] bstansberry: kkhan: yeah, that's my vague concern
[09:17am] ctomc: if attribute support expression than this string would be threated as one
[09:17am] ctomc: otherwise it would be plain string
[09:17am] bstansberry: ctomc: right but that JIRA suggests changing that
[09:17am] bstansberry: the current behavior is what you describe
[09:18am] kkhan: ${thing:${x}}
[09:18am] kkhan: Sorry, I'm probably not being helpful
[09:19am] ctomc: hmm bstansberry what would we gain if we convert always?
[09:19am] ctomc: given that current impl works properly and convets only strings that are on attributes supporting expressions
[09:19am] bstansberry: ctomc: basically if people put expressions in string attributes that don't support it, we'll give a proper failure instead of some random failure at runtime
[09:20am] ctomc: ok, that does not mean we need to convert everything to expression
[09:20am] ctomc: we just convert for validation purposes not neccesary also store that in the model
[09:22am] bstansberry: ctomc: it won't validate though, so the end result is the same
[09:23am] ctomc: why wouldn't it validate?
[09:23am] ctomc: validateOperation would throw operationFailedException
[09:23am] bstansberry: right, that's what i mean -- it won't pass
[09:24am] ctomc: in case that value passed in looks like expression but shouldnt be
[09:24am] ctomc: is that not the outcome you would want?
[09:24am] ctomc: to report problem early?
[09:24am] bstansberry: I'm talking about:
[09:24am] bstansberry: ctomc: we just convert for validation purposes not neccesary also store that in the model
[09:25am] bstansberry: it won't pass validation so whether we store STRING or EXPRESSION in the model won't matter, because we won't store at all
[09:27am] kkhan: bstansberry: In light of what you are talking about, do you want: https://github.com/jbossas/jboss-as/pull/3876? I'm asking because if you do, perhaps it should be included in maeste's
[09:27am] jbossbot: git pull req [jboss-as] (open) kabir Scan for expressions in string model nodes https://github.com/jbossas/jboss-as/pull/3876
[09:27am] bstansberry: kkhan: yes, we definitely want that
[09:28am] kkhan: I'll ask maeste to include that then
[09:28am] bstansberry: I can't imagine we'll have tests where we *want* a STRING with ${} syntax
[09:29am] bstansberry: maybe some wild end-user use case would want it, but our testsuite doesn't test those
[09:29am] kkhan: bstansberry: If we do, we can add a way to turn it off for a particular test
[09:29am] bstansberry: kkhan: exactly
[09:30am] ctomc: for cases like that more elegant solution is to have expression pointing to sys prop and that sys prop has ${} in it
[09:31am] bstansberry: re AS7-6257, we've talked about it; that was my goal. I'll paste ^^^ in the JIRA. Won't do for 7.2 unless one of you guys starts to think it's a great idea
[09:31am] jbossbot: jira [AS7-6257] AttributeDefinition validateOperation should convert all expression strings to ModelType.EXPRESSION [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/AS7-6257
[09:32am] ctomc: bstansberry: i have mixed feelings about this now, before we talked about it it sounded great
> AttributeDefinition validateOperation should convert all expression strings to ModelType.EXPRESSION
> ---------------------------------------------------------------------------------------------------
>
> Key: AS7-6257
> URL: https://issues.jboss.org/browse/AS7-6257
> Project: Application Server 7
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 7.3.0.Alpha1
>
>
> AttributeDefinition.validateOperation currently only converts a string to an expression if the attribute supports expressions. It should convert any time it sees the syntax. This way if a STRING attribute that doesn't support expressions finds one, it will reject it instead of accepting it as a raw string.
> Scheduling for 7.3 out of concern this may break things in 7.2 without time to notice/adapt.
--
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, 6 months