[JBoss JIRA] (DROOLS-2781) [Guided Rule] Can't be opened if constraint to bound field present
by Toni Rikkola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2781?page=com.atlassian.jira.plugi... ]
Toni Rikkola reassigned DROOLS-2781:
------------------------------------
Assignee: Toni Rikkola (was: Michael Anstis)
> [Guided Rule] Can't be opened if constraint to bound field present
> ------------------------------------------------------------------
>
> Key: DROOLS-2781
> URL: https://issues.jboss.org/browse/DROOLS-2781
> Project: Drools
> Issue Type: Bug
> Components: Guided Rule Editor
> Affects Versions: 7.9.0.Final
> Reporter: Jozef Marko
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: drools-tools
> Attachments: Screenshot from 2018-07-24 14-32-00.png
>
>
> {code:mvel}
> package com.myspace.repr;
> import java.lang.Number;
> rule "rule"
> dialect "mvel"
> when
> DataObject( $stringField : sFieldOne == "something" )
> DataObjectTwo( sFieldTwo == $stringField )
> then
> end
> {code}
> Assume the rdrl file above where both *sFieldOne* and *sFieldTwo* are both of *String* type. Then if you try open this rdrl file in workbench the unexpected error dialog appears.
> The same can be seen if we assign role EVENT to *DataObject* and have this rule below.
> {code:mvel}
> package com.myspace.repr;
> import java.lang.Number;
> rule "eventRule"
> dialect "mvel"
> when
> e1 : DataObject( this after [1m, 2m] "24-Jul-2018" ) over window:time (10d)
> e2 : DataObject( this before e1 )
> then
> end
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2781) [Guided Rule] Can't be opened if constraint to bound field present
by Toni Rikkola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2781?page=com.atlassian.jira.plugi... ]
Toni Rikkola commented on DROOLS-2781:
--------------------------------------
[~tirelli] Sure I have few days for bug fixing.
> [Guided Rule] Can't be opened if constraint to bound field present
> ------------------------------------------------------------------
>
> Key: DROOLS-2781
> URL: https://issues.jboss.org/browse/DROOLS-2781
> Project: Drools
> Issue Type: Bug
> Components: Guided Rule Editor
> Affects Versions: 7.9.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Attachments: Screenshot from 2018-07-24 14-32-00.png
>
>
> {code:mvel}
> package com.myspace.repr;
> import java.lang.Number;
> rule "rule"
> dialect "mvel"
> when
> DataObject( $stringField : sFieldOne == "something" )
> DataObjectTwo( sFieldTwo == $stringField )
> then
> end
> {code}
> Assume the rdrl file above where both *sFieldOne* and *sFieldTwo* are both of *String* type. Then if you try open this rdrl file in workbench the unexpected error dialog appears.
> The same can be seen if we assign role EVENT to *DataObject* and have this rule below.
> {code:mvel}
> package com.myspace.repr;
> import java.lang.Number;
> rule "eventRule"
> dialect "mvel"
> when
> e1 : DataObject( this after [1m, 2m] "24-Jul-2018" ) over window:time (10d)
> e2 : DataObject( this before e1 )
> then
> end
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10743) Java Agent using JUL causes JBoss LogManager issues
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-10743:
-----------------------------------
Summary: Java Agent using JUL causes JBoss LogManager issues
Key: WFLY-10743
URL: https://issues.jboss.org/browse/WFLY-10743
Project: WildFly
Issue Type: Enhancement
Components: Scripts
Affects Versions: 13.0.0.Final
Reporter: Brad Maxwell
To workaround the issue, these steps are required below. It would be better if we could handle this in the scripts or another way such that the user did not have to directly reference the current jboss-logmanager jar.
{code}
JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
JAVA_OPTS="$JAVA_OPTS -Xbootclasspath/p:$JBOSS_HOME/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-<version>.jar"
{code}
{code}
if [ "x$JBOSS_MODULES_SYSTEM_PKGS" = "x" ]; then
JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,org.jboss.logmanager"
fi
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3977) Changing multicast address in socket binding does not trigger server to set reload-required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3977?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3977:
------------------------------------------
It's not just whether the service is up.
{code}
final SocketBinding binding = controller.getState() == ServiceController.State.UP ? SocketBinding.class.cast(controller.getValue()) : null;
final boolean bound = binding != null && binding.isBound();
{code}
The value of 'bound' controls whether reload-required is set. Whether it reports as bound is controlled by the SocketBindingManager
> Changing multicast address in socket binding does not trigger server to set reload-required
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-3977
> URL: https://issues.jboss.org/browse/WFCORE-3977
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 6.0.0.Alpha3
> Reporter: Richard Achmatowicz
> Assignee: Jeff Mesnil
>
> Found this by accident when debugging a clustering test case.
> If I start a server with profile standalone-full-ha and then modify the multicast address of a clustering related socket-binding, in this case, jgroups-mping, the server is not put into state reload-required.
> This causes a lot of problems in the testsuite which depends on configuring servers after startup and then restarting if necessary to pull in the changes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3978) Management audit logger should support including the timestamp inside the JSON
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3978:
----------------------------------------
Summary: Management audit logger should support including the timestamp inside the JSON
Key: WFCORE-3978
URL: https://issues.jboss.org/browse/WFCORE-3978
Project: WildFly Core
Issue Type: Enhancement
Components: Management
Reporter: Brian Stansberry
Assignee: Jeff Mesnil
The management audit log records have this weird half-JSON structure:
{code}
2018-07-25 14:59:50 - {
"type" : "core",
...
}
{code}
I think that format needs to be 'enhanced' via an additional attribute on core-service=management/access=audit/json-formatter=json-formatter, one that lets the user specify a JSON field name to use for the timestamp, instead having it be separate from the json. It would be an alternative to the existing "date-separator" attribute, which is what puts the " - " in the current log record.
--
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 Gail Badner (JIRA)
[ https://issues.jboss.org/browse/WFWIP-53?page=com.atlassian.jira.plugin.s... ]
Gail Badner commented on WFWIP-53:
----------------------------------
[~simkam], can you point me to your tests and provide info for running them? I think it would really help as we're working through adding support for 5.1 user types using the transformer.
> 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-10607) Fix intermittent failures in RemoteEJBForwardingTestCases
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-10607?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz commented on WFLY-10607:
--------------------------------------------
I have found out why the test was still failing. Upon looking at the test environment setup, it was observed that the two clusters ejb-forwarder = {node-1, node-2} and ejb={node-3, node4} were not forming correctly. Once the cluster setup was fixed, and with the above mentioned change to the synchronization interceptor, the test now passes.
What was the problem with the test case setup and why were the clusters not forming correctly? The test case setup depends on several steps carried out in the testsuite/integration/clustering pom.xml file:
* use a wildfly-maven-plugin execution to adjust the stack of the base distribution used in the test via clustering-all.cli
* use a maven antrun-plugin execution to copy the distribution to the four server distributions wildfly-1, wildfly-2, wildfly-3, wildfly4
* use a maven-surefilre-plugin execution to run the 2 clusters test using the four servers which have been started with the default socket-binding multicast addresses (this by default causes the four nodes to all be members of the same cluster when started)
* use a ServerSetupTask in the test case itself to further configure the four nodes so that they form two sepaate clusters suitable for the test
It was noticed that the two clusters were not forming correctly. Upon further investigation using the management console, it was seen that the multicast addresses were correctly configured in each server's management interface, but that the actual multicast addresses used were not correct.
This was traced to the following issue: https://issues.jboss.org/browse/WFCORE-3977. What was happening was that the ServerSetupTask was correctly making the changes via the management CLI, but because the servers were not put into reload-required, the changes were not taking effect and the clusters were not forming correct. Forcing a reload of the servers causes the servers to configure correctly.
With correctly configured server environment, pluse the changes to the synchronization interceptor mentioned above, the tests now pass.
> Fix intermittent failures in RemoteEJBForwardingTestCases
> ---------------------------------------------------------
>
> Key: WFLY-10607
> URL: https://issues.jboss.org/browse/WFLY-10607
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Test Suite
> Reporter: Petr Kremensky
> Assignee: Richard Achmatowicz
>
> The tests were ignored by https://github.com/wildfly/wildfly/pull/10563/files
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months