[JBoss JIRA] (DROOLS-2835) NPE While using incremental compilation
by Luca Molteni (JIRA)
Luca Molteni created DROOLS-2835:
------------------------------------
Summary: NPE While using incremental compilation
Key: DROOLS-2835
URL: https://issues.jboss.org/browse/DROOLS-2835
Project: Drools
Issue Type: Bug
Reporter: Luca Molteni
Assignee: Mario Fusco
IncrementalCompilationCepTest.testUpdateWithDeclarationPresent:312 » NullPointer
IncrementalCompilationTest.testDeclaredTypeInDifferentPackage:3262->doFire:3307 » NullPointer
IncrementalCompilationTest.testDeletedFile:306 » NullPointer
IncrementalCompilationTest.testKJarUpgradeWithNewRuleAndStatelessSession:3905 » NullPointer
IncrementalCompilationTest.testKJarUpgradeWithNewRule:3849 » NullPointer
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2834) Wrong number of fired rules while using Incremental Compilation
by Luca Molteni (JIRA)
Luca Molteni created DROOLS-2834:
------------------------------------
Summary: Wrong number of fired rules while using Incremental Compilation
Key: DROOLS-2834
URL: https://issues.jboss.org/browse/DROOLS-2834
Project: Drools
Issue Type: Bug
Reporter: Luca Molteni
Assignee: Mario Fusco
IncrementalCompilationTest.testPropertyReactivityOfAKnownClass:3158 expected:<1> but was:<0>
IncrementalCompilationTest.testKJarUpgradeWithDSL:1257 expected:<1> but was:<0>
IncrementalCompilationTest.testKJarUpgradeSameSession:269 expected:<3> but was:<2>
IncrementalCompilationCepTest.testChangeWindowTime:378 expected:<3> but was:<1>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2823) FEEL Parser: `not` breaks with `list contains`
by Kirill Gaevskii (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2823?page=com.atlassian.jira.plugi... ]
Kirill Gaevskii reassigned DROOLS-2823:
---------------------------------------
Assignee: Kirill Gaevskii (was: Edoardo Vacchi)
> FEEL Parser: `not` breaks with `list contains`
> -----------------------------------------------
>
> Key: DROOLS-2823
> URL: https://issues.jboss.org/browse/DROOLS-2823
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Edoardo Vacchi
> Assignee: Kirill Gaevskii
> Labels: Stunner
>
> *list contains([1,2,3,4,5,6], 3)* returns true
> *not(list contains([1,2,3,4,5,6], 3))* returns “list contains([1,2,3,4,5,6], 3)”, it should return false
> Most likely related to an issue with the parse tree branches
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2823) FEEL Parser: `not` breaks with `list contains`
by Kirill Gaevskii (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2823?page=com.atlassian.jira.plugi... ]
Kirill Gaevskii reassigned DROOLS-2823:
---------------------------------------
Assignee: Edoardo Vacchi (was: Kirill Gaevskii)
> FEEL Parser: `not` breaks with `list contains`
> -----------------------------------------------
>
> Key: DROOLS-2823
> URL: https://issues.jboss.org/browse/DROOLS-2823
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Edoardo Vacchi
> Assignee: Edoardo Vacchi
> Labels: Stunner
>
> *list contains([1,2,3,4,5,6], 3)* returns true
> *not(list contains([1,2,3,4,5,6], 3))* returns “list contains([1,2,3,4,5,6], 3)”, it should return false
> Most likely related to an issue with the parse tree branches
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-51) java.lang.AbstractMethodError: org.hibernate.test.cut.MonetoryAmountUserType.nullSafeSet(Ljava/sql/PreparedStatement; Ljava/lang/Object; ILorg/hibernate/engine/spi/SharedSessionContractImplementor; )V
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFWIP-51?page=com.atlassian.jira.plugin.s... ]
Martin Simka resolved WFWIP-51.
-------------------------------
Resolution: Done
resolving, fixed by combination of https://hibernate.atlassian.net/browse/HHH-12730 (Hibernate ORM 5.3.4) and compatibility transformer WFLY-10520
> java.lang.AbstractMethodError: org.hibernate.test.cut.MonetoryAmountUserType.nullSafeSet(Ljava/sql/PreparedStatement;Ljava/lang/Object;ILorg/hibernate/engine/spi/SharedSessionContractImplementor;)V
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-51
> URL: https://issues.jboss.org/browse/WFWIP-51
> Project: WildFly WIP
> Issue Type: Bug
> Components: JPA
> Reporter: Martin Simka
> Assignee: Gail Badner
> Priority: Blocker
> Attachments: App.java
>
>
> Test from Hibernate test suite CompositeUserTypeTest.testCompositeUserType(compiled with 5.1.x and run 5.3.2-SNAPSHOT) throws
> {noformat}
> java.lang.AbstractMethodError: org.hibernate.test.cut.MonetoryAmountUserType.nullSafeSet(Ljava/sql/PreparedStatement;Ljava/lang/Object;ILorg/hibernate/engine/spi/SharedSessionContractImplementor;)V
> at org.hibernate.type.CompositeCustomType.nullSafeSet(CompositeCustomType.java:236)
> at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:2833)
> at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:2808)
> at org.hibernate.persister.entity.AbstractEntityPersister$4.bindValues(AbstractEntityPersister.java:3029)
> at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:41)
> at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3037)
> at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3628)
> at org.hibernate.action.internal.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:81)
> at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:645)
> at org.hibernate.engine.spi.ActionQueue.addResolvedEntityInsertAction(ActionQueue.java:282)
> at org.hibernate.engine.spi.ActionQueue.addInsertAction(ActionQueue.java:263)
> at org.hibernate.engine.spi.ActionQueue.addAction(ActionQueue.java:317)
> at org.hibernate.event.internal.AbstractSaveEventListener.addInsertAction(AbstractSaveEventListener.java:359)
> at org.hibernate.event.internal.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:292)
> at org.hibernate.event.internal.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:200)
> at org.hibernate.event.internal.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:131)
> at org.hibernate.event.internal.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:192)
> at org.hibernate.event.internal.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:135)
> at org.hibernate.event.internal.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:62)
> at org.hibernate.internal.SessionImpl.firePersist(SessionImpl.java:800)
> at org.hibernate.internal.SessionImpl.persist(SessionImpl.java:785)
> at org.hibernate.test.cut.CompositeUserTypeTest.testCompositeUserType(CompositeUserTypeTest.java:47)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:45)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
> {noformat}
> Scenario is something like:
> {code:java}
> CompositeUserType t = new CompositeUserType(){ ...};
> CompositeCustomType cct = new CompositeCustomType(t);
> cct.nullSafeSet(preparedStatement, "value", 1, sessionImplementor);
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-53) Differences in ORM exception handling in 5.1 vs 5.3
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFWIP-53?page=com.atlassian.jira.plugin.s... ]
Martin Simka resolved WFWIP-53.
-------------------------------
Resolution: Done
resolving, fixed by https://hibernate.atlassian.net/browse/HHH-12666 in Hibernate ORM 5.3.3. Old behavior can be enabled with system property {{hibernate.native_exception_handling_51_compliance}}
> Differences in ORM exception handling in 5.1 vs 5.3
> ---------------------------------------------------
>
> Key: WFWIP-53
> URL: https://issues.jboss.org/browse/WFWIP-53
> Project: WildFly WIP
> Issue Type: Bug
> Components: JPA
> Reporter: Martin Simka
> Assignee: Gail Badner
> Priority: Blocker
>
> I see tests failing because {{org.hibernate.hql.internal.ast.QuerySyntaxException}} is wrapped by {{java.lang.IllegalArgumentException}}. I know this has been discussed on hibernate-dev mailing list but without any outcome.
> http://lists.jboss.org/pipermail/hibernate-dev/2018-May/017654.html
> {quote}
> I've been looking at differences in Hibernate exception handling for
> applications that uses "native" (non-JPA) Hibernate when moving from 5.1 to
> 5.3.
> As you know, exception handling changed in 5.2 when hibernate-entitymanager
> was merged into hibernate-core. This change is documented in the 5.2
> migration guide. [1]
> Here is the relevant text:
> "org.hibernate.HibernateException now extends
> javax.persistence.PersistenceExceptions.
> Hibernate methods that "override" methods from their JPA counterparts now
> will also throw various JDK defined RuntimeExceptions (such as
> IllegalArgumentException, IllegalStateException, etc) as required by the
> JPA contract."
> While digging into this, I see that a HibernateException thrown when using
> 5.1 may, in 5.3, be unwrapped, or may be wrapped by a PersistenceException
> (or a subclass), IllegalArgumentException, or IllegalStateException,
> depending on the particular operation being performed when the
> HibernateException is thrown.
> The reason why the exceptions may be wrapped or unwrapped is because
> Hibernate converts exceptions (via
> AbstractSharedSessionContract#exceptionConverter)
> for JPA operations which may wrap the HibernateException or throw a
> different exception. Hibernate does not convert exceptions from strictly
> "native" operations, so those exceptions remain unwrapped.
> Here are a couple of examples to illustrate:
> 1) A HibernateException (org.hibernate.TransientObjectException) was thrown
> in 5.1. In 5.3, the same condition can result in
> org.hibernate.TransientObjectException
> that is either unwrapped, or wrapped by IllegalStateException. I've pushed
> a test to my fork to illustrate. [2]
> Thrown during Session#save, #saveOrUpdate
> In 5.1: org.hibernate.TransientObjectException (unwrapped)
> In 5.3: org.hibernate.TransientObjectException (unwrapped)
> Thrown during Session#persist, #merge, #flush
> In 5.1, org.hibernate.TransientObjectException (unwrapped)
> In 5.3, org.hibernate.TransientObjectException wrapped by
> IllegalStateException
> 2) A HibernateException thrown when using 5.1 may be wrapped by a
> PersistenceException, even though HibernateException already extends
> PersistenceException.
> For example, see TransactionTimeoutTest#testTransactionTimeoutFailure:
> https://github.com/hibernate/hibernate-orm/blob/master/
> hibernate-core/src/test/java/org/hibernate/test/tm/
> TransactionTimeoutTest.java#L60-L82
> The exception thrown by the test indicates that the transaction timed out.
> This exception is important enough that an application might retry the
> operation, or at least log for future investigation.
> Thrown during Session#persist (or when changed to use Session#merge or
> Session#flush):
> In 5.1: org.hibernate.TransactionException (unwrapped)
> In 5.3: org.hibernate.TransactionException wrapped by javax.persistence.
> PersistenceException
> Thrown if the test is changed to use Session#save or #saveOrUpdate instead:
> In 5.1: org.hibernate.TransactionException (unwrapped)
> In 5.3: org.hibernate.TransactionException (unwrapped)
> Similarly, by adding some logging, I see that HibernateException objects
> can be wrapped by PersistenceException when running the 5.3 hibernate-core
> unit tests. Depending on the context, I see that some of the following
> exceptions can be wrapped or unwrapped.
> org.hibernate.exception.ConstraintViolationException
> org.hibernate.exception.DataException
> org.hibernate.exception.GenericJDBCException
> org.hibernate.exception.SQLGrammarException
> org.hibernate.id.IdentifierGenerationException
> org.hibernate.loader.custom.NonUniqueDiscoveredSqlAliasException
> org.hibernate.PersistentObjectException
> org.hibernate.PropertyAccessException
> org.hibernate.PropertyValueException
> org.hibernate.TransactionException
> You can see an example using
> org.hibernate.exception.ConstraintViolationException
> at [3].
> In order to deal with these differences, an application could change the
> following (which was appropriate for 5.1):
> try {
> ...
> }
> catch (HibernateException ex) {
> procressHibernateException( ex );
> }
> to the following for 5.3:
> try {
> ...
> }
> catch (PersistenceException | IllegalStateException |
> IllegalArgumentException ex) {
> if ( HibernateException.class.isInstance( ex ) ) {
> handleHibernateException( (HibernateException) ex );
> }
> else if ( HibernateException.class.isInstance( ex.getCause() ) ) {
> handleHibernateException( (HibernateException) ex.getCause() );
> }
> }
> IMO, it's a little clumsy having to deal with both wrapped and unwrapped
> exceptions. It would be better if exceptions were consistently wrapped, or
> consistently unwrapped.
> I haven't had much of a chance to think about how we can deal with this,
> but one thing that comes to mind is to allow an application to choose a
> particular ExceptionConverter implementation. Hibernate would need to be
> changed to always convert exceptions (including for strictly native
> operations) before returning to the application.
> For example, a property, hibernate.exception_converter could be added with
> the following values:
> jpa - default for JPA applications (org.hibernate.internal.
> ExceptionConverterImpl)
> native (or legacy?) - default for native applications that does not wrap
> HibernateException
> fully-qualified class name that implements ExceptionConverter
> If users have to make changes to exception handling for 5.3, do you think
> they would be willing to change their application to use JPA exceptions
> (i.e., hibernate.exception_converter=jpa)?
> Comments?
> Regards,
> Gail
> [1] https://github.com/hibernate/hibernate-orm/blob/5.2/migration-guide.adoc
> [2] https://github.com/gbadner/hibernate-core/blob/exception-
> compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
> ORMTransientObjectExceptionUnitTestCase.java
> [3] https://github.com/gbadner/hibernate-core/blob/exception-
> compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
> ORMConstraintViolationExceptionUnitTestCase.java
> {quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10800) [EAT] : Addition of exclusion library list.
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-10800?page=com.atlassian.jira.plugin... ]
Panagiotis Sotiropoulos moved JBEAP-15200 to WFLY-10800:
--------------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-10800 (was: JBEAP-15200)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
> [EAT] : Addition of exclusion library list.
> -------------------------------------------
>
> Key: WFLY-10800
> URL: https://issues.jboss.org/browse/WFLY-10800
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
>
> Addition of an exclusion library list with the first parts of packages that we know that are not provided by the server program dependency or product artifacts.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months