[JBoss JIRA] (DROOLS-1217) OpenJDK 9: prove that drools-core and drools-compiler works in a 100% module-info.java environment (take them out of the "special" module)
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1217?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1217:
-------------------------------------
Description:
So far all our OpenJDK 9 tests put drools-core and drools-core in the "special" module. That's basically the anti-module for backwards compatibility. As soon as users start using module-info.java files themselves, there will be a big pressure for us to be a proper module, so to have our own module-info.java's. Because of our extended used of reflection, we need to validate this works long before OpenJDK 9 goes final, so we can still feed it back.
Reqs:
Add module-info.java to core and examples jar. Compile and run with both jars on the modulepath (instead of in the special classpath module).
was:
o far all our OpenJDK 9 tests put drools-core and drools-core in the "special" module. That's basically the anti-module for backwards compatibility. As soon as users start using module-info.java files themselves, there will be a big pressure for us to be a proper module, so to have our own module-info.java's. Because of our extended used of reflection, we need to validate this works long before OpenJDK 9 goes final, so we can still feed it back.
Reqs:
Add module-info.java to core and examples jar. Compile and run with both jars on the modulepath (instead of in the special classpath module).
> OpenJDK 9: prove that drools-core and drools-compiler works in a 100% module-info.java environment (take them out of the "special" module)
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1217
> URL: https://issues.jboss.org/browse/DROOLS-1217
> Project: Drools
> Issue Type: Task
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Priority: Critical
>
> So far all our OpenJDK 9 tests put drools-core and drools-core in the "special" module. That's basically the anti-module for backwards compatibility. As soon as users start using module-info.java files themselves, there will be a big pressure for us to be a proper module, so to have our own module-info.java's. Because of our extended used of reflection, we need to validate this works long before OpenJDK 9 goes final, so we can still feed it back.
> Reqs:
> Add module-info.java to core and examples jar. Compile and run with both jars on the modulepath (instead of in the special classpath module).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1611) CLI could stuck if SIGINT is send during authentication dialogue
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1611?page=com.atlassian.jira.plugi... ]
Chao Wang updated WFCORE-1611:
------------------------------
Labels: downstream_dependency (was: )
> CLI could stuck if SIGINT is send during authentication dialogue
> ----------------------------------------------------------------
>
> Key: WFCORE-1611
> URL: https://issues.jboss.org/browse/WFCORE-1611
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha2
> Reporter: Chao Wang
> Assignee: Chao Wang
> Labels: downstream_dependency
>
> Interruption a CLI session with Ctrl+C during authentication dialogue could get CLI into unresponsive state.
> *reproduce*
> Either use a remote server, --no-local-auth cli script arg or remove a local element from ManagementRealm configuration
> {code:diff}
> <security-realms>
> <security-realm name="ManagementRealm">
> <authentication>
> - <local default-user="$local" skip-group-loading="true"/>
> {code}
> start a standalone server and launch a CLI
> {noformat}
> [pkremens@localhost] $ ./standalone.sh &
> [pkremens@localhost] $ ./jboss-cli.sh
> [disconnected /] connect
> Authenticating against security realm: ManagementRealm
> Username: <Press Ctrl+C here>
> {noformat}
> Could not connect message is printed, but process is not terminated and stuck at this point.
> {noformat}
> The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to http-remoting://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to http-remoting://localhost:9990. The connection timed out
> {noformat}
> Only way to recover the terminal is to SIGKILL the CLI process.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1217) OpenJDK 9: prove that drools-core and drools-compiler works in a 100% module-info.java environment (take them out of the "special" module)
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-1217:
----------------------------------------
Summary: OpenJDK 9: prove that drools-core and drools-compiler works in a 100% module-info.java environment (take them out of the "special" module)
Key: DROOLS-1217
URL: https://issues.jboss.org/browse/DROOLS-1217
Project: Drools
Issue Type: Task
Components: core engine
Reporter: Geoffrey De Smet
Assignee: Mario Fusco
Priority: Critical
o far all our OpenJDK 9 tests put drools-core and drools-core in the "special" module. That's basically the anti-module for backwards compatibility. As soon as users start using module-info.java files themselves, there will be a big pressure for us to be a proper module, so to have our own module-info.java's. Because of our extended used of reflection, we need to validate this works long before OpenJDK 9 goes final, so we can still feed it back.
Reqs:
Add module-info.java to core and examples jar. Compile and run with both jars on the modulepath (instead of in the special classpath module).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6761) Wrong XAException return code when broker timeout is hit
by Chen Maoqian (JIRA)
[ https://issues.jboss.org/browse/WFLY-6761?page=com.atlassian.jira.plugin.... ]
Chen Maoqian moved JBEAP-5105 to WFLY-6761:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6761 (was: JBEAP-5105)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: ActiveMQ)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.GA)
> Wrong XAException return code when broker timeout is hit
> --------------------------------------------------------
>
> Key: WFLY-6761
> URL: https://issues.jboss.org/browse/WFLY-6761
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Chen Maoqian
> Assignee: Chen Maoqian
> Priority: Minor
>
> By creating testcases for checking behavior of transaction timeout I've hit an issue of wrong error code being returned when broker transaction timeout is hit before TM transaction timeout expires.
> It uses {{XAER_PROTO}} instead of {{RBTIMEOUT}}.
> This issue does not cause data inconsistency.
> Scenario:
> * ejb sends a message to a queue
> * processing inside of the ejb takes long time
> ** TM transaction timeout is set big enough to not hit the timeout
> ** jms broker internal transaction timeout is smaller than time needed for processing ejb method
> * jms broker txn timeout occurs - broker local txn is rolled back
> ** txn is removed from list of broker's local in-process transactions
> * TM calls XAResource.end
> ** the call returns {{XAException.XAER_PROTO}}
> That's current implementation returns {{XAER_PROTO}} in this scenario but {{RBTIMEOUT}} would be more appropriate.
> From discussion with Narayana developers, RM should return the most specific error return code as possible. In this scenario it's {{RBTIMEOUT}}.
> Other notes from TM dev point of view:
> {code}
> "[XA_RBTIMEOUT]
> The work represented by this transaction branch took too long."
> {code}
> _per XA spec page 39._
> The more complex question is, at what point can the resource manager forget about that branch (and therefore return NOTA to subsequent calls)?
> The XA spec says "After the transaction manager calls xa_end(), it should no longer consider the calling thread associated with that resource manager (although it must consider the resource manager part of the transaction branch when it prepares the branch.)"
> which implies the branch is still considered live at that point, a view corroborated by:
> {code}
> "[XA_RB∗]
> The resource manager has dissociated the transaction branch from the thread of control and has marked rollback-only the work performed on behalf of ∗xid."
> {code}
> Exception being thrown
> {code}
> WARN [com.arjuna.ats.jta] (Thread-0
> (ActiveMQ-client-global-threads-1468293951)) ARJUNA016056:
> TransactionImple.delistResource - caught exception during delist :
> XAException.XAER_PROTO: javax.transaction.xa.XAException
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.xaEnd(ActiveMQSessionContext.java:346)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.end(ClientSessionImpl.java:1115)
> at
> org.apache.activemq.artemis.ra.ActiveMQRAXAResource.end(ActiveMQRAXAResource.java:112)
> at
> org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.end(ActiveMQXAResourceWrapperImpl.java:81)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(TransactionImple.java:897)
> at
> org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.beforeCompletion(TxConnectionListener.java:1063)
> at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.invokeBefore(TransactionSynchronizer.java:438)
> at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.beforeCompletion(TransactionSynchronizer.java:376)
> at
> org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:130)
> at
> com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371)
> at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at
> com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at
> org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.afterDelivery(MessageEndpointInvocationHandler.java:71)
> 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.jboss.as.ejb3.inflow.AbstractInvocationHandler.handle(AbstractInvocationHandler.java:60)
> at
> org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:135)
> at
> org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
> at
> org.jboss.as.test.jbossts.crashrec.jms.mdb.JMSCrashMessageDrivenBean$$$endpoint1.afterDelivery(Unknown
> Source)
> at
> org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:321)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:932)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:47)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1045)
> at
> org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:100)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Henryk Konsek (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Henryk Konsek commented on DROOLS-355:
--------------------------------------
Hi,
I'm Henry from Red Hat IoT engineering team. We are working on putting Drools on IoT gateway devices.
I'd like to use kie-server-client and install it into Eclipse Kura server (which is really OSGi container based on Eclipse Equinox). I'm running into the same problem as drools-core is a dependency of kie-server-client.
Do you have an estimate of when this issue could be resolved?
Cheers!
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Marco Rietveld
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6759) Enable HTTP/2 by default
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-6759:
------------------------------------
Summary: Enable HTTP/2 by default
Key: WFLY-6759
URL: https://issues.jboss.org/browse/WFLY-6759
Project: WildFly
Issue Type: Feature Request
Reporter: Stuart Douglas
Assignee: Jason Greene
Now we have better ALPN support we can enable HTTP/2 by default
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6749) Cluster failover doesn't work on windows when network is disabled on a node
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6749?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6749:
----------------------------------------
Thanks a lot Paul for responding with the info.
It was one of our customers that tried the failover simulation this way - by disabling the network.
As per link that you have provided, jgroups protocols (FD, and FD_ALL) are involved in Failover detection (Every member periodically multicasts a heartbeat).
We have Cache replication in Wildfly cluster which also uses jgroups and we do it the Multicast way. So when we disable the network on a node since the services on the node is not stopped, perhaps the multicasting is still happening and hence the failover detection doesn’t work. I still need to go through the link in detail.
Thanks,
Preeta
Cisco Systems.
> Cluster failover doesn't work on windows when network is disabled on a node
> ---------------------------------------------------------------------------
>
> Key: WFLY-6749
> URL: https://issues.jboss.org/browse/WFLY-6749
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Paul Ferraro
> Priority: Critical
>
> This is about a two VM Wildfly cluster on windows environment. In order to test the failover, the team has disabled the network on one node. However the failover is not happening and the application functionality on the cluster is hampered as a result.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months