August 2015 - jboss-jira - Jboss List Archives

[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, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-898) Rename drools-osgi* modules to kie-osgi*

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-898?page=com.atlassian.jira.plugin... ] Petr Široký updated DROOLS-898: ------------------------------- Affects Version/s: 6.3.0.CR2 > Rename drools-osgi* modules to kie-osgi* > ---------------------------------------- > > Key: DROOLS-898 > URL: https://issues.jboss.org/browse/DROOLS-898 > Project: Drools > Issue Type: Task > Affects Versions: 6.3.0.CR2 > 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-363: ------------------------------------ Fix Version/s: 3.0.0.Alpha1 (was: 2.0.0.CR1) > ManagementResourceRegistration.getOverrideModel never returns null > ------------------------------------------------------------------ > > Key: WFCORE-363 > URL: https://issues.jboss.org/browse/WFCORE-363 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha1 > > > ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct. > The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should. > This bug is the cause of the initial failure of my WFLY-2880 fix. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-273: ------------------------------------ Fix Version/s: 3.0.0.Alpha1 (was: 2.0.0.CR1) > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFCORE-273 > URL: https://issues.jboss.org/browse/WFCORE-273 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Ken Wills > Fix For: 3.0.0.Alpha1 > > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-384) Server does wrongly reference a list of socket binding groups

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-384?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-384: ------------------------------------ Fix Version/s: 3.0.0.Beta1 (was: 2.0.0.CR1) > Server does wrongly reference a list of socket binding groups > ------------------------------------------------------------- > > Key: WFCORE-384 > URL: https://issues.jboss.org/browse/WFCORE-384 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Braun > Assignee: Ken Wills > Fix For: 3.0.0.Beta1 > > > hbraun: i see that a server (host=foo/server=bar) can have a list of socket-binding-groups > [10:59am] hbraun: shouldn't that be a a single socket binding instead? > [11:00am] emuckenhuber: oh... yeah > [11:00am] hbraun: maybe it's just the description that's wrong > [11:00am] emuckenhuber: that sounds similar to the jvm thing we had -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-396: ------------------------------------ Fix Version/s: 3.0.0.Beta1 (was: 2.0.0.CR1) > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta1 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-60) Capabilities and requirements in a managed process

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-60?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFCORE-60: ---------------------------------------- I'll resolve it when the misc side issues I want fixed are done. Admittedly, I'm far too lazy to link those to this one. ;) > Capabilities and requirements in a managed process > -------------------------------------------------- > > Key: WFCORE-60 > URL: https://issues.jboss.org/browse/WFCORE-60 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.0.CR1 > > > Implement the aspects discussed under the "Runtime" section of https://community.jboss.org/docs/DOC-52712 > Add an API to the OperationContext for handlers to publish capabilities and for other handlers to register a requirement for those capabilities and to access the API object associated with the capability. > The registry of capabilities and requirements should be maintained with a semantic equivalent to the resource tree. The registry is copied-on-write, making the copy invisible to concurrently executing operations, and then the copy is published on commit of the operation that modified it. If the operation does not commit, the copy is discarded, so handlers have no need to revert changes they make to the registry. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5199) On MariaDB 5.3+ and MySQL 5.6.4+, EJB timers in a JDBC storage don't work correctly due to timestamp rounding

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/WFLY-5199?page=com.atlassian.jira.plugin.... ] Jan Martiska reopened WFLY-5199: -------------------------------- [~swd847] PR #7998 won't fix it, that one is meant for WFLY-5207 and Microsoft SQL Server. This issue is for MySQL + MariaDB. For this issue I wanted to discuss with you which of my suggested options (in the description) you find the best. My suggestion is 3), I included a link to a possible implementation. If you agree with it, I can send a PR. > On MariaDB 5.3+ and MySQL 5.6.4+, EJB timers in a JDBC storage don't work correctly due to timestamp rounding > ------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5199 > URL: https://issues.jboss.org/browse/WFLY-5199 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Beta2 > Environment: MariaDB 5.3+, Mysql 5.6.4+ > Reporter: Jan Martiska > Assignee: Stuart Douglas > Fix For: 10.0.0.CR1 > > > EJB timers don't execute, because the DatabaseTimerPersistence.shouldRun method returns false for them, because it is unable to SELECT them from the database using a java.sql.Timestamp. > On MariaDB 5.3+ and MySQL 5.6.4+, the behavior of the DATETIME type has changed compared to MySQL 5.5 and older. > In previous versions, it was possible to insert into DATETIME columns with JDBC using a java.sql.Timestamp which contained fractional seconds, the fraction was truncated/rounded and a subsequent SELECT statement with the same java.sql.Timestamp returned such rows, because the fraction was truncated/rounded from the queried Timestamp too. > On MySQL 5.6.4+ and MariaDB 5.3+, when a java.sql.Timestamp including a fractional second is inserted into a DATETIME, attempting to SELECT with the same Timestamp doesn't return the row, because the DATETIME type now defaults to DATETIME(0) which truncates/rounds to whole seconds, and the queried Timestamp no longer gets truncated/rounded during the query execution. It would only work if the column was declared as DATETIME(6), which ensures that inserted values don't get truncated/rounded. Documentation: https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html > MySQL rounds the timestamp, MariaDB truncates it (always rounds down). > However, declaring DATETIME(6) is not possible in older versions of MySQL or MariaDB, so to support both new and old versions, we have probably these options: > 1. introduce a new DDL file(s) for MySQL 5.6.4+ and MariaDB 5.3+ and use it depending on the detected version - this DDL would use DATETIME(6) instead of DATETIME > 2. change the DatabaseTimerPersistence implementation so that it will not insert fractional seconds into the database at all (EJB timers don't support timing with higher precision than whole seconds anyway) > 3. same as option 2, but only for MariaDB/MySQL dialects > 4. any other idea? > I personally like number 3 the best, it is the least risky and introduces only minimal changes.. but it's still somewhat ugly. > This seems to resolve it for me (implementation suggestion of option 3): https://github.com/jmartisk/wildfly/commits/mysql-mariadb-timer-suggestion -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2015