[JBoss JIRA] (WFLY-5238) [Migration operation] [Web to Undertow] Unable to migrate any valve to handler
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5238?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka updated WFLY-5238:
-----------------------------------
Affects Version/s: 10.0.0.Beta2
> [Migration operation] [Web to Undertow] Unable to migrate any valve to handler
> ------------------------------------------------------------------------------
>
> Key: WFLY-5238
> URL: https://issues.jboss.org/browse/WFLY-5238
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Beta2
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
>
> In Undertow there are Handlers which can be used similarly as Valves. Some valves have corresponding handler in Undertow. Such valves could be migrated.
> E.g. as part of [EAP7-428] there is added {{io.undertow.server.handlers.RequestDumpingHandler}}.
> This could be thereby migrated from
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false">
> <valve name="request-dumper" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RequestDumperValve"/>
> <virtual-server name="default-host" enable-welcome-root="false">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> ...
> </subsystem>
> {code}
> to something like:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:undertow:3.0">
> <buffer-cache name="default"/>
> <server name="default-server" default-host="default-host">
> <host name="default-host" alias="localhost, example.com">
> <filter-ref name="request-dumper"/>
> </host>
> </server>
> <servlet-container name="default">
> <jsp-config/>
> </servlet-container>
> <filter name="request-dumper" module="io.undertow.core" class-name="io.undertow.server.handlers.RequestDumpingHandler"/>
> ...
> </subsystem>
> {code}
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (WFCORE-934) IPv6ScopeIdMatchUnitTestCase fails on some machines
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-934?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-934:
-----------------------------------------
Looks like a JVM problem then. InetAddress.getByName("fe80:0:0:0:8:20ff:fe6d:eab0%net0:2") is not behaving in accordance with javadoc. It is throwing UnknownHostException when it should not. For a literal IPv6 address string that represents a link-local or site-local it should only check the validity of the address format. The format is valid, as described at https://docs.oracle.com/javase/8/docs/api/java/net/Inet6Address.html#scoped which is linked in the InetAddress.getByName javadoc.
For an IPv6 literal address string with a scope_id appended, UnknownHostException should only be thrown if the address isn't a site-local or link-local address.
This test passes in the community CI runs: http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WildFlyCore&...
There have been failures in the past. I haven't examined them all, but it looks like the failures were due to incorrectly testing global IPv6 addresses, which my patch fixed.
What's happening here is for an InetAddress 'address' obtained from inspecting the addresses available on the system, InetAddress.getByName(address.getHostAddress()) is throwing an UnknownHostException. That's clearly wrong.
> IPv6ScopeIdMatchUnitTestCase fails on some machines
> ---------------------------------------------------
>
> Key: WFCORE-934
> URL: https://issues.jboss.org/browse/WFCORE-934
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.0.Beta4
> Reporter: Marek Kopecký
> Assignee: Brian Stansberry
>
> *Description of problem:*
> org.jboss.as.controller.interfaces.IPv6ScopeIdMatchUnitTestCase#testNonLoopback in WildFly Core TS fails on Solaris11 SPARC.
> *How reproducible:*
> Always with this configuration on Solaris11 SPARC:
> {noformat}
> $ /usr/sbin/ifconfig -a
> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
> inet 127.0.0.1 netmask ff000000
> net0: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.91.211 netmask fffff800 broadcast 10.16.95.255
> net0:1: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.24 netmask fffff800 broadcast 10.16.183.255
> net0:2: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.25 netmask fffff800 broadcast 10.16.183.255
> net0:3: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.26 netmask fffff800 broadcast 10.16.183.255
> net0:4: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.27 netmask fffff800 broadcast 10.16.183.255
> lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
> inet6 ::1/128
> net0: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab1/10
> net0:1: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab2/10
> net0:2: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab0/10
> net0:3: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:164/64
> net0:4: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:165/64
> net0:5: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:166/64
> net0:6: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:167/64
> net0:7: flags=120002080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f:8:20ff:fe6d:eab0/64
> $
> {noformat}
> *Steps to Reproduce:*
> # cd controller
> # mvn test -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dtest=IPv6ScopeIdMatchUnitTestCase
> *Actual results:*
> * StackTrace:
> {noformat}
> java.lang.AssertionError: expected:</fe80:0:0:0:8:20ff:fe6d:eab0%net0:2> but was:<null>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.jboss.as.controller.interfaces.IPv6ScopeIdMatchUnitTestCase.testNonLoopback(IPv6ScopeIdMatchUnitTestCase.java:129)
> {noformat}
> * Test output:
> {noformat}
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab2%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:8:20ff:fe6d:eab0%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab1%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:167%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:166%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:165%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:164%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab0%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab0%net0:2, so cannot match it to any InetAddress
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (DROOLS-890) Thread deadlock issue in class ProjectClassLoader.java
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-890?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-890.
--------------------------------
Fix Version/s: 6.3.0.Final
Resolution: Done
I can see how the InternalClassLoader can be accessed without having acquired a lock on the enclosing ProjectClassLoader first and this is indeed wrong.
I fixed it with this commit https://github.com/droolsjbpm/drools/commit/183518527
> Thread deadlock issue in class ProjectClassLoader.java
> -------------------------------------------------------
>
> Key: DROOLS-890
> URL: https://issues.jboss.org/browse/DROOLS-890
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.1.0.Final
> Reporter: Vivek Hingorani
> Assignee: Mario Fusco
> Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (WFLY-5049) AMQ Artemis does not support slash character used in activation property of MDB
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5049?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on WFLY-5049:
----------------------------------------
Hi Jeff,
yeap, sorry, it was typo, there are two different queues. MDB consumes from MDBTriggerQueue.
Remote server uses default configuration where connection factory {{RemoteConnectionFactory}} is defined and which I expect the MDB server connects through.
I'm adding the example of configuration files for you can check. These configuration work perfectly until you use instead of queue name {{MDBTriggerQueue}} name like {{queue/MDBTriggerQueue}}.
> AMQ Artemis does not support slash character used in activation property of MDB
> -------------------------------------------------------------------------------
>
> Key: WFLY-5049
> URL: https://issues.jboss.org/browse/WFLY-5049
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Alpha6
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Attachments: ejb-jar.xml, mdb-deployed-standalone-full.xml, remote-activemq-broker-standalone-full.xml
>
>
> When using slash character {{/}} in configuration of artemis messaging subsystem as jms queue name then MDB fails to connect to remote messaging server.
> My settings is following - I have a remote messaging server where queue is defined like
> {code}
> <jms-queue name="queue/crashRecoveryQueue" entries="java:jboss/queue/crashRecoveryQueue"/>
> {code}
> Then there is a server where MDB is deployed. That server configures connection factory
> {code}
> <pooled-connection-factory name="messaging-broker-remote" transaction="xa" entries="java:/RemoteJmsXA" connectors="messaging-broker-http-remote"/>
> {code}
> http connector
> {code}
> <http-connector name="messaging-broker-http-remote" socket-binding="remote-messaging">
> <param name="http-upgrade-endpoint" value="http-acceptor"/>
> </http-connector>
> {code}
> outbound socket binding
> {code}
> <outbound-socket-binding name="remote-messaging">
> <remote-destination host="127.0.0.1" port="8280"/>
> </outbound-socket-binding>
> {code}
> and resource reference for ejb subsystem
> {code}
> <mdb>
> <resource-adapter-ref resource-adapter-name="messaging-broker-remote"/>
> <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
> </mdb>
> {code}
> The MDB uses ejb-jar with activation properties
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <ejb-jar id="EJBJar_1060639024453" version="3.0"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
> metadata-complete="false">
> <enterprise-beans>
> <message-driven>
> <ejb-name>JMSCrashMessageDrivenBean</ejb-name>
> <ejb-class>org.jboss.as.test.jbossts.crashrec.jms.mdb.JMSCrashMessageDrivenBean</ejb-class>
> <activation-config>
> <activation-config-property>
> <activation-config-property-name>destination</activation-config-property-name>
> <activation-config-property-value>queue/MDBTriggerQueue</activation-config-property-value>
> </activation-config-property>
> <activation-config-property>
> <activation-config-property-name>destinationType</activation-config-property-name>
> <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
> </activation-config-property>
> </activation-config>
> </message-driven>
> </enterprise-beans>
> </ejb-jar>
> {code}
> The server does not show any warning that the connection was not found, just MDB does not receive any message from the queue.
> If I use {{MDBTriggerQueue}} instead of {{queue/MDBTriggerQueue}} the same setup starts working perfectly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (WFCORE-939) Embedded host controller should set launch type attribute to EMBEDDED
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-939?page=com.atlassian.jira.plugin... ]
Ken Wills updated WFCORE-939:
-----------------------------
Summary: Embedded host controller should set launch type attribute to EMBEDDED (was: Embedded host controller should set lunch type attribute to EMBEDDED)
> Embedded host controller should set launch type attribute to EMBEDDED
> ---------------------------------------------------------------------
>
> Key: WFCORE-939
> URL: https://issues.jboss.org/browse/WFCORE-939
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: Ken Wills
>
> *DomainRootDefinition.java* always set launch type to {noformat}new LaunchTypeHandler(ServerEnvironment.LaunchType.DOMAIN){noformat} even if the host controller process is embedded.
> Looking into the LaunchType class, I believe that EMBEDDED value should be used.
> {noformat}
> /** The manner in which a server can be launched */
> public static enum LaunchType {
> /** Launched by a Host Controller in a managed domain */
> DOMAIN(ProcessType.DOMAIN_SERVER),
> /** Launched from the command line */
> STANDALONE(ProcessType.STANDALONE_SERVER),
> /** Launched by another process in which the server is embedded */
> EMBEDDED(ProcessType.EMBEDDED_SERVER),
> ...
> {noformat}
> \\
> *Additional info:*
> {noformat}./standalone.sh
> launch-type STANDALONE
> {noformat}
> {noformat}./domain.sh
> launch-type DOMAIN
> {noformat}
> {noformat}[disconnected /] embed-server
> launch-type EMBEDDED
> {noformat}
> {noformat}[disconnected /] embed-host-controller
> launch-type DOMAIN
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (WFLY-5049) AMQ Artemis does not support slash character used in activation property of MDB
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5049?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka updated WFLY-5049:
-----------------------------------
Attachment: ejb-jar.xml
Settings of activation properties for ejb where MDB resides
> AMQ Artemis does not support slash character used in activation property of MDB
> -------------------------------------------------------------------------------
>
> Key: WFLY-5049
> URL: https://issues.jboss.org/browse/WFLY-5049
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Alpha6
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Attachments: ejb-jar.xml, mdb-deployed-standalone-full.xml, remote-activemq-broker-standalone-full.xml
>
>
> When using slash character {{/}} in configuration of artemis messaging subsystem as jms queue name then MDB fails to connect to remote messaging server.
> My settings is following - I have a remote messaging server where queue is defined like
> {code}
> <jms-queue name="queue/crashRecoveryQueue" entries="java:jboss/queue/crashRecoveryQueue"/>
> {code}
> Then there is a server where MDB is deployed. That server configures connection factory
> {code}
> <pooled-connection-factory name="messaging-broker-remote" transaction="xa" entries="java:/RemoteJmsXA" connectors="messaging-broker-http-remote"/>
> {code}
> http connector
> {code}
> <http-connector name="messaging-broker-http-remote" socket-binding="remote-messaging">
> <param name="http-upgrade-endpoint" value="http-acceptor"/>
> </http-connector>
> {code}
> outbound socket binding
> {code}
> <outbound-socket-binding name="remote-messaging">
> <remote-destination host="127.0.0.1" port="8280"/>
> </outbound-socket-binding>
> {code}
> and resource reference for ejb subsystem
> {code}
> <mdb>
> <resource-adapter-ref resource-adapter-name="messaging-broker-remote"/>
> <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
> </mdb>
> {code}
> The MDB uses ejb-jar with activation properties
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <ejb-jar id="EJBJar_1060639024453" version="3.0"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
> metadata-complete="false">
> <enterprise-beans>
> <message-driven>
> <ejb-name>JMSCrashMessageDrivenBean</ejb-name>
> <ejb-class>org.jboss.as.test.jbossts.crashrec.jms.mdb.JMSCrashMessageDrivenBean</ejb-class>
> <activation-config>
> <activation-config-property>
> <activation-config-property-name>destination</activation-config-property-name>
> <activation-config-property-value>queue/MDBTriggerQueue</activation-config-property-value>
> </activation-config-property>
> <activation-config-property>
> <activation-config-property-name>destinationType</activation-config-property-name>
> <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
> </activation-config-property>
> </activation-config>
> </message-driven>
> </enterprise-beans>
> </ejb-jar>
> {code}
> The server does not show any warning that the connection was not found, just MDB does not receive any message from the queue.
> If I use {{MDBTriggerQueue}} instead of {{queue/MDBTriggerQueue}} the same setup starts working perfectly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (WFLY-5049) AMQ Artemis does not support slash character used in activation property of MDB
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5049?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka updated WFLY-5049:
-----------------------------------
Attachment: mdb-deployed-standalone-full.xml
remote-activemq-broker-standalone-full.xml
Adding server configuration files where {{mdb-deployed-standalone-full.xml}} presents the test server where MDB runs. There is no queues configured but there is defined connection factory which points to remote eap server which is configured by {{remote-activemq-broker-standalone-full.xml}} and where queues are deployed.
> AMQ Artemis does not support slash character used in activation property of MDB
> -------------------------------------------------------------------------------
>
> Key: WFLY-5049
> URL: https://issues.jboss.org/browse/WFLY-5049
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Alpha6
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Attachments: mdb-deployed-standalone-full.xml, remote-activemq-broker-standalone-full.xml
>
>
> When using slash character {{/}} in configuration of artemis messaging subsystem as jms queue name then MDB fails to connect to remote messaging server.
> My settings is following - I have a remote messaging server where queue is defined like
> {code}
> <jms-queue name="queue/crashRecoveryQueue" entries="java:jboss/queue/crashRecoveryQueue"/>
> {code}
> Then there is a server where MDB is deployed. That server configures connection factory
> {code}
> <pooled-connection-factory name="messaging-broker-remote" transaction="xa" entries="java:/RemoteJmsXA" connectors="messaging-broker-http-remote"/>
> {code}
> http connector
> {code}
> <http-connector name="messaging-broker-http-remote" socket-binding="remote-messaging">
> <param name="http-upgrade-endpoint" value="http-acceptor"/>
> </http-connector>
> {code}
> outbound socket binding
> {code}
> <outbound-socket-binding name="remote-messaging">
> <remote-destination host="127.0.0.1" port="8280"/>
> </outbound-socket-binding>
> {code}
> and resource reference for ejb subsystem
> {code}
> <mdb>
> <resource-adapter-ref resource-adapter-name="messaging-broker-remote"/>
> <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
> </mdb>
> {code}
> The MDB uses ejb-jar with activation properties
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <ejb-jar id="EJBJar_1060639024453" version="3.0"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
> metadata-complete="false">
> <enterprise-beans>
> <message-driven>
> <ejb-name>JMSCrashMessageDrivenBean</ejb-name>
> <ejb-class>org.jboss.as.test.jbossts.crashrec.jms.mdb.JMSCrashMessageDrivenBean</ejb-class>
> <activation-config>
> <activation-config-property>
> <activation-config-property-name>destination</activation-config-property-name>
> <activation-config-property-value>queue/MDBTriggerQueue</activation-config-property-value>
> </activation-config-property>
> <activation-config-property>
> <activation-config-property-name>destinationType</activation-config-property-name>
> <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
> </activation-config-property>
> </activation-config>
> </message-driven>
> </enterprise-beans>
> </ejb-jar>
> {code}
> The server does not show any warning that the connection was not found, just MDB does not receive any message from the queue.
> If I use {{MDBTriggerQueue}} instead of {{queue/MDBTriggerQueue}} the same setup starts working perfectly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (DROOLS-898) Rename drools-osgi* modules to kie-osgi*
by Petr Široký (JIRA)
Petr Široký created DROOLS-898:
----------------------------------
Summary: Rename drools-osgi* modules to kie-osgi*
Key: DROOLS-898
URL: https://issues.jboss.org/browse/DROOLS-898
Project: Drools
Issue Type: Task
Reporter: Petr Široký
Assignee: Petr Široký
The {{drools-osgi}} module no longer contains only Drools specific integration. For quite some time there is also jBPM related code and recently also OptaPlanner. We should rename the module to {{kie-osgi}} to be consistent with the other components (e.g. {{kie-maven-plugin}}, {{kie-server}}, etc)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month