[JBoss JIRA] (DROOLS-1169) Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved" due to ECJ
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1169?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1169:
-------------------------------------
Summary: Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved" due to ECJ (was: Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved")
> Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved" due to ECJ
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1169
> URL: https://issues.jboss.org/browse/DROOLS-1169
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> The code below runs perfectly with OpenJDK 8 (and even 6 and 7).
> To reproduce, use JDK 9 ( https://jdk9.java.net/download/ ) and in optaplanner-core, run XStreamXmlSolverFactoryTest [1] (or mostly any other test that builds a DRL file) to get this error:
> {code}
> 15:56:40.229 [main] ERROR o.d.c.k.b.impl.AbstractKieModule - Unable to build KieBaseModel:defaultKieBase
> Rule Compilation error : [Rule name='Conflict']
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (1:0) : The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (1:0) : The type java.io.Serializable cannot be resolved. It is indirectly referenced from required .class files
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (3:337) : Implicit super constructor Object() is undefined for default constructor. Must define an explicit constructor
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (6:569) : java.lang.Exception cannot be resolved to a type
> java.lang.IllegalStateException: There are errors in a score DRL:
> Error Messages:
> Message [id=1, level=ERROR, path=org/optaplanner/core/api/solver/testdataScoreRules.drl, line=31, column=0
> text=Rule Compilation error The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files
> The type java.io.Serializable cannot be resolved. It is indirectly referenced from required .class files
> Implicit super constructor Object() is undefined for default constructor. Must define an explicit constructor
> java.lang.Exception cannot be resolved to a type]
> {code}
> That tests builds this DRL:
> {code}
> package org.optaplanner.core.api.solver;
> dialect "java"
> import org.optaplanner.core.api.score.buildin.simple.SimpleScoreHolder;
> import org.optaplanner.core.impl.testdata.domain.TestdataValue;
> import org.optaplanner.core.impl.testdata.domain.TestdataEntity;
> global SimpleScoreHolder scoreHolder;
> // ############################################################################
> // Constraints
> // ############################################################################
> rule "Conflict"
> when
> TestdataEntity(value != null, $leftValue : value)
> TestdataEntity(value == $leftValue)
> then
> scoreHolder.addConstraintMatch(kcontext, -1);
> end
> {code}
> Not sure where the Object constructor reference comes from... This might be a JDK 9 upstream issue.
> Note: don't build drools with OpenJDK9 as that will fail sooner :)
> [1] https://github.com/droolsjbpm/optaplanner/blob/master/optaplanner-core/sr...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6599) JDBC_PING can't use a JNDI database connection because it is closed on shutdown
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6599?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6599:
---------------------------------
Affects Version/s: 10.0.0.Final
> JDBC_PING can't use a JNDI database connection because it is closed on shutdown
> -------------------------------------------------------------------------------
>
> Key: WFLY-6599
> URL: https://issues.jboss.org/browse/WFLY-6599
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Matthew Casperson
> Assignee: Radoslav Husar
>
> If you configure the JDBC_PING protocol in JGroups to use a datasource provided by WildFly via the *datasource_jndi_name* setting, you'll get the following exception when WildFly is shutdown:
> {code}
> [Server:main-server] 2016-05-10 11:05:45+1000 ERROR [[org.jgroups.protocols.JDBC_PING]] [[MSC service thread 1-4]] Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> [Server:main-server] at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:348)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.delete(JDBC_PING.java:379)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.deleteSelf(JDBC_PING.java:395)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:144)
> [Server:main-server] at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
> [Server:main-server] at org.jgroups.JChannel.stopStack(JChannel.java:1002)
> [Server:main-server] at org.jgroups.JChannel.disconnect(JChannel.java:373)
> [Server:main-server] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.stop(ChannelConnectorBuilder.java:103)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:735)
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> [Server:main-server] ... 14 more
> {code}
> The solution is to configure the database connection directly, but then it seems that you loose the ability to use features like database connection validation, reconnection and the other settings provided by a WildFly datasource the improve the reliability of a database connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6601) Application context specific log handler
by Nicklas Karlsson (JIRA)
Nicklas Karlsson created WFLY-6601:
--------------------------------------
Summary: Application context specific log handler
Key: WFLY-6601
URL: https://issues.jboss.org/browse/WFLY-6601
Project: WildFly
Issue Type: Feature Request
Components: Logging
Affects Versions: 10.0.0.Final
Reporter: Nicklas Karlsson
Assignee: James Perkins
There are many cases where it would be handy to group log events on some application specific information (e.g. placed in the MDC). Examples are
* Collecting all user session interaction loggings into a separate file
* Collecting all log entries related to a specific client machine into a separate file
* Collecting the entire lifecycle of an entity (long-lived order, process etc) into a separate file
This could perhaps be implemented with a LogFilePolicyClass that would return the correct (existing or fresh) file based on the MDC data?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1127) Google App Engine support: Do not call new Thread() by allowing to plug in a custom ThreadFactory
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1127?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1127:
-------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1329093|https://bugzilla.redhat.com/show_bug.cgi?id=1329093] from ASSIGNED to MODIFIED
> Google App Engine support: Do not call new Thread() by allowing to plug in a custom ThreadFactory
> -------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1127
> URL: https://issues.jboss.org/browse/DROOLS-1127
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Fix For: 7.0.0.Beta1
>
>
> Any code that does `new Thread()` on GAE throws an exception, because you can't create new threads yourself.
> Other future cloud platforms might have a similar restriction. It should be possible to plug in a custom way of creating threads.
> *Proposal A)* Add a kieBase configuration property to change the ThreadFactory
> {code}
> drools.threadFactory = com.user.project.GoogleAppEngineThreadFactory
> {code}
> *Proposal B)* Add a kieBase configuration property to change the ExecutorServiceFactory
> {code}
> drools.executorServiceFactory = com.user.project.ExecutorServiceFactory
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1546) Whitespaces in the middle of the value are siletly ignored
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1546?page=com.atlassian.jira.plugi... ]
Chao Wang moved JBEAP-4575 to WFCORE-1546:
------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1546 (was: JBEAP-4575)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 2.2.0.CR2
(was: 7.0.0.CR2)
> Whitespaces in the middle of the value are siletly ignored
> ----------------------------------------------------------
>
> Key: WFCORE-1546
> URL: https://issues.jboss.org/browse/WFCORE-1546
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.2.0.CR2
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> Whitespace in the middle of value (e.g. adding a system property with a value like "my property") is silently ignored.
> Going to the history, this behaviour changed was introduced in EAP 6.0.1
> *6.0.0*
> {noformat}
> /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value= I N F O)
> {
> "outcome" => "failed",
> "failure-description" => "JBAS011539: Log level I N F O is invalid.",
> "rolled-back" => true
> }
> /system-property=test:add(value=ha ha ha)
> /system-property=test:read-attribute(name=value)
> {
> "outcome" => "success",
> "result" => "ha ha ha"
> }
> {noformat}
> *6.0.1* up to *7.0.0*
> {noformat}
> /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value= I N F O)
> /subsystem=logging/console-handler=CONSOLE:read-attribute(name=level)
> {
> "outcome" => "success",
> "result" => "INFO"
> }
> /system-property=test:add(value=ha ha ha)
> /system-property=test:read-attribute(name=value)
> {
> "outcome" => "success",
> "result" => "hahaha"
> }
> {noformat}
> Main concern here is whether it is a correct behaviour to silently ignore the whitespace in the middle.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1169) Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved"
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1169?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on DROOLS-1169:
------------------------------------------
*Workaround*: use the native compiler, that fixes this issue too. Enable it by using this VM option: -Ddrools.dialect.java.compiler=NATIVE
> Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved"
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1169
> URL: https://issues.jboss.org/browse/DROOLS-1169
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> The code below runs perfectly with OpenJDK 8 (and even 6 and 7).
> To reproduce, use JDK 9 ( https://jdk9.java.net/download/ ) and in optaplanner-core, run XStreamXmlSolverFactoryTest [1] (or mostly any other test that builds a DRL file) to get this error:
> {code}
> 15:56:40.229 [main] ERROR o.d.c.k.b.impl.AbstractKieModule - Unable to build KieBaseModel:defaultKieBase
> Rule Compilation error : [Rule name='Conflict']
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (1:0) : The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (1:0) : The type java.io.Serializable cannot be resolved. It is indirectly referenced from required .class files
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (3:337) : Implicit super constructor Object() is undefined for default constructor. Must define an explicit constructor
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (6:569) : java.lang.Exception cannot be resolved to a type
> java.lang.IllegalStateException: There are errors in a score DRL:
> Error Messages:
> Message [id=1, level=ERROR, path=org/optaplanner/core/api/solver/testdataScoreRules.drl, line=31, column=0
> text=Rule Compilation error The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files
> The type java.io.Serializable cannot be resolved. It is indirectly referenced from required .class files
> Implicit super constructor Object() is undefined for default constructor. Must define an explicit constructor
> java.lang.Exception cannot be resolved to a type]
> {code}
> That tests builds this DRL:
> {code}
> package org.optaplanner.core.api.solver;
> dialect "java"
> import org.optaplanner.core.api.score.buildin.simple.SimpleScoreHolder;
> import org.optaplanner.core.impl.testdata.domain.TestdataValue;
> import org.optaplanner.core.impl.testdata.domain.TestdataEntity;
> global SimpleScoreHolder scoreHolder;
> // ############################################################################
> // Constraints
> // ############################################################################
> rule "Conflict"
> when
> TestdataEntity(value != null, $leftValue : value)
> TestdataEntity(value == $leftValue)
> then
> scoreHolder.addConstraintMatch(kcontext, -1);
> end
> {code}
> Not sure where the Object constructor reference comes from... This might be a JDK 9 upstream issue.
> Note: don't build drools with OpenJDK9 as that will fail sooner :)
> [1] https://github.com/droolsjbpm/optaplanner/blob/master/optaplanner-core/sr...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6599) JDBC_PING can't use a JNDI database connection because it is closed on shutdown
by Matthew Casperson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6599?page=com.atlassian.jira.plugin.... ]
Matthew Casperson commented on WFLY-6599:
-----------------------------------------
[~rhusar] - Unfortunately it seems that I can't edit the ticket any more. It is for WildFly 10.0.0.Final.
> JDBC_PING can't use a JNDI database connection because it is closed on shutdown
> -------------------------------------------------------------------------------
>
> Key: WFLY-6599
> URL: https://issues.jboss.org/browse/WFLY-6599
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Reporter: Matthew Casperson
> Assignee: Radoslav Husar
>
> If you configure the JDBC_PING protocol in JGroups to use a datasource provided by WildFly via the *datasource_jndi_name* setting, you'll get the following exception when WildFly is shutdown:
> {code}
> [Server:main-server] 2016-05-10 11:05:45+1000 ERROR [[org.jgroups.protocols.JDBC_PING]] [[MSC service thread 1-4]] Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> [Server:main-server] at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:348)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.delete(JDBC_PING.java:379)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.deleteSelf(JDBC_PING.java:395)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:144)
> [Server:main-server] at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
> [Server:main-server] at org.jgroups.JChannel.stopStack(JChannel.java:1002)
> [Server:main-server] at org.jgroups.JChannel.disconnect(JChannel.java:373)
> [Server:main-server] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.stop(ChannelConnectorBuilder.java:103)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:735)
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> [Server:main-server] ... 14 more
> {code}
> The solution is to configure the database connection directly, but then it seems that you loose the ability to use features like database connection validation, reconnection and the other settings provided by a WildFly datasource the improve the reliability of a database connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6599) JDBC_PING can't use a JNDI database connection because it is closed on shutdown
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6599?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-6599:
--------------------------------------
[~matthew.casperson] For the sake of completeness, please fill in the affected version.
> JDBC_PING can't use a JNDI database connection because it is closed on shutdown
> -------------------------------------------------------------------------------
>
> Key: WFLY-6599
> URL: https://issues.jboss.org/browse/WFLY-6599
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Reporter: Matthew Casperson
> Assignee: Radoslav Husar
>
> If you configure the JDBC_PING protocol in JGroups to use a datasource provided by WildFly via the *datasource_jndi_name* setting, you'll get the following exception when WildFly is shutdown:
> {code}
> [Server:main-server] 2016-05-10 11:05:45+1000 ERROR [[org.jgroups.protocols.JDBC_PING]] [[MSC service thread 1-4]] Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> [Server:main-server] at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:348)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.delete(JDBC_PING.java:379)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.deleteSelf(JDBC_PING.java:395)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:144)
> [Server:main-server] at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
> [Server:main-server] at org.jgroups.JChannel.stopStack(JChannel.java:1002)
> [Server:main-server] at org.jgroups.JChannel.disconnect(JChannel.java:373)
> [Server:main-server] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.stop(ChannelConnectorBuilder.java:103)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:735)
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> [Server:main-server] ... 14 more
> {code}
> The solution is to configure the database connection directly, but then it seems that you loose the ability to use features like database connection validation, reconnection and the other settings provided by a WildFly datasource the improve the reliability of a database connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months