[jira] [Updated] (ARTEMIS-1674) Dependency Conflict : Conflicting classes existing in two libraries

2018-02-09 Thread PandaMonkey (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

PandaMonkey updated ARTEMIS-1674:
-
Description: 
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
 The following duplicate class pairs having the same names but their internal 
implementations are different in different JARs:
 "org.jboss.logging.Log4j2LoggerProvider", 
 "org.jboss.logging.MDC", 
 "org.jboss.logging.JBossLogManagerProvider",
 "org.jboss.logging.Slf4jLoggerProvider", 
 "org.jboss.logging.Log4j2Logger", 
 "org.jboss.logging.JBossLogManagerLogger", 

.

Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem. As the JVM only load the classes present first on 
the classpath and shadow the other duplicate ones with the same name. So it 
brings high risks of classpath issues during the truck evolution process, which 
may throw the *java.lang.NoSuchMethodException* at runtime.

The conflicting features' details are shown in the attachment. Hope this report 
can help you, thanks!

  was:
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
 The following duplicate class pairs having the same names but their internal 
implementations are different in different JARs:
 "org.jboss.logging.Log4j2LoggerProvider", 
 "org.jboss.logging.MDC", 
 "org.jboss.logging.JBossLogManagerProvider",
 "org.jboss.logging.Slf4jLoggerProvider", 
 "org.jboss.logging.Log4j2Logger", 
 "org.jboss.logging.JBossLogManagerLogger", 

.

Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
truck evolution process, which may throw the java.lang.NoSuchMethodException at 
runtime.

The conflicting features' details are shown in the attachment. Hope this report 
can help you, thanks!


> Dependency Conflict : Conflicting classes existing in two libraries
> ---
>
> Key: ARTEMIS-1674
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1674
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: [^Conflicting libs.TXT]
>Reporter: PandaMonkey
>Priority: Major
>  Labels: features
> Fix For: 2.5.0
>
> Attachments: Conflicting libs.TXT
>
>
> Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT 
> "artemis-cdi-client\pom.xml" and its bytecodes, we found libraries 
> "org.jboss.weld.se:weld-se:2.4.0.Final" and 
> "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
>  The following duplicate class pairs having the same names but their internal 
> implementations are different in different JARs:
>  "org.jboss.logging.Log4j2LoggerProvider", 
>  "org.jboss.logging.MDC", 
>  "org.jboss.logging.JBossLogManagerProvider",
>  "org.jboss.logging.Slf4jLoggerProvider", 
>  "org.jboss.logging.Log4j2Logger", 
>  "org.jboss.logging.JBossLogManagerLogger", 
> .
> Some methods only exist in one class version:
>  org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
>  org.jboss.logging.Log4jLoggerProvider: void clearMdc()
>  org.jboss.logging.MDC: void clear()
>  ..
> Please notice this problem. As the JVM only load the classes present first on 
> the classpath and shadow the other duplicate ones with the same name. So it 
> brings high risks of classpath issues during the truck evolution process, 
> which may throw the *java.lang.NoSuchMethodException* at runtime.
> The conflicting features' details are shown in the attachment. Hope this 
> report can help you, thanks!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1605) RBAC back compatibility Issue in upgrading broker from 2.3

2018-02-09 Thread Michael Andre Pearce (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358894#comment-16358894
 ] 

Michael Andre Pearce commented on ARTEMIS-1605:
---

[~andytaylor] did you get a chance to look at this?

> RBAC back compatibility Issue in upgrading broker from 2.3
> --
>
> Key: ARTEMIS-1605
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1605
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Michael Andre Pearce
>Priority: Blocker
>
> On taking an older 2.3 broker and taking master i have noticed a simply 
> upgrade by repointing the artemis home, the server won't start.
>  ./bin/artemis run
> Invalid configuration URI, can't find file: management.xml
> Configuration should be specified as 'scheme:location'. Default configuration 
> is 'xml:${ARTEMIS_INSTANCE}/etc/bootstrap.xml'
> This seems due to changes in ARTEMIS-1463 that create a new management.xml 
> and expect this but unfortunately is not back compatible, e.g. no handling if 
> not present.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1662) Reduce log of "INFO [org.apache.activemq.artemis.core.client] (Thread-27 (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector version unknown to

2018-02-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358885#comment-16358885
 ] 

ASF GitHub Bot commented on ARTEMIS-1662:
-

Github user michaelandrepearce commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1852#discussion_r167332364
  
--- Diff: 
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/ActiveMQClientLogger.java
 ---
@@ -64,7 +64,7 @@
@Message(id = 211001, value = "session created", format = 
Message.Format.MESSAGE_FORMAT)
void dumpingSessionStack(@Cause Exception e);
 
-   @LogMessage(level = Logger.Level.INFO)
+   @LogMessage(level = Logger.Level.DEBUG)
--- End diff --

disagree still but as its 2 v 1 and its logging at the end of the day 
(bigger issues to really worry on) ill make it a -0. Ive merged the PR as is.


> Reduce log of "INFO [org.apache.activemq.artemis.core.client] (Thread-27 
> (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector 
> version unknown to ..." to DEBUG
> 
>
> Key: ARTEMIS-1662
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1662
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Dmitrii Tikhomirov
>Priority: Major
>
> Information of starting connector is now logged on INFO level which 
> over-floods server logs:
> {code}
> 05:46:05,073 INFO [org.apache.activemq.artemis.core.client] (Thread-27 
> (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector 
> version unknown to rhel7-large-461:8080
> {code}
> It should be decresed to DEBUG level.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1662) Reduce log of "INFO [org.apache.activemq.artemis.core.client] (Thread-27 (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector version unknown to

2018-02-09 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358882#comment-16358882
 ] 

ASF subversion and git services commented on ARTEMIS-1662:
--

Commit 90b656477887fb454fd03e85748bf64de9422b52 in activemq-artemis's branch 
refs/heads/master from [~ch...@me.com]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=90b6564 ]

[ARTEMIS-1662] Reduce log of "INFO [org.apache.activemq.artemis.core.client] 
(Thread-27 (ActiveMQ-client-global-threads))


> Reduce log of "INFO [org.apache.activemq.artemis.core.client] (Thread-27 
> (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector 
> version unknown to ..." to DEBUG
> 
>
> Key: ARTEMIS-1662
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1662
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Dmitrii Tikhomirov
>Priority: Major
>
> Information of starting connector is now logged on INFO level which 
> over-floods server logs:
> {code}
> 05:46:05,073 INFO [org.apache.activemq.artemis.core.client] (Thread-27 
> (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector 
> version unknown to rhel7-large-461:8080
> {code}
> It should be decresed to DEBUG level.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1662) Reduce log of "INFO [org.apache.activemq.artemis.core.client] (Thread-27 (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector version unknown to

2018-02-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358883#comment-16358883
 ] 

ASF GitHub Bot commented on ARTEMIS-1662:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1852


> Reduce log of "INFO [org.apache.activemq.artemis.core.client] (Thread-27 
> (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector 
> version unknown to ..." to DEBUG
> 
>
> Key: ARTEMIS-1662
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1662
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Dmitrii Tikhomirov
>Priority: Major
>
> Information of starting connector is now logged on INFO level which 
> over-floods server logs:
> {code}
> 05:46:05,073 INFO [org.apache.activemq.artemis.core.client] (Thread-27 
> (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector 
> version unknown to rhel7-large-461:8080
> {code}
> It should be decresed to DEBUG level.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1650) Improve paged message acknowledge

2018-02-09 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358709#comment-16358709
 ] 

ASF subversion and git services commented on ARTEMIS-1650:
--

Commit 63e0c0d310850fb59f800d2cc5cf9c5cfc0060ec in activemq-artemis's branch 
refs/heads/master from Clebert Suconic
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=63e0c0d ]

ARTEMIS-1650 Fixing Testsuite on PageReference

Transactions may initialize a PagedReference without a valid message yet
during load of prepared transactions.

Caching has to be lazy on this case and it should load on demand.


> Improve paged message acknowledge
> -
>
> Key: ARTEMIS-1650
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1650
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Reporter: shoukun huai
>Priority: Minor
> Attachments: jstack.txt
>
>
> PagedMessage may be GCed before it was acknowledged. In this case, server has 
> to reload the page and hold the page cache lock, then block other consumers 
> of the same queue.
> When do acknowledge, we need at least message id, transaction id, and is 
> large message.
> We believe the three property can be added to PagedReference, so we do not 
> rely on PagedMessage when acknowledge except LargeMessage.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1676) Allow users to override JAVA_ARGS via environment variables

2018-02-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358631#comment-16358631
 ] 

ASF GitHub Bot commented on ARTEMIS-1676:
-

Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1862#discussion_r167280403
  
--- Diff: 
artemis-cli/src/main/resources/org/apache/activemq/artemis/cli/commands/etc/artemis.profile
 ---
@@ -21,14 +21,20 @@ ARTEMIS_INSTANCE='${artemis.instance}'
 # The logging config will need an URI
 # this will be encoded in case you use spaces or special characters
 # on your directory structure
-ARTEMIS_INSTANCE_URI='${artemis.instance.uri}'
 
-# Cluster Properties: Used to pass arguments to ActiveMQ Artemis which can 
be referenced in broker.xml
-#ARTEMIS_CLUSTER_PROPS="-Dactivemq.remoting.default.port=61617 
-Dactivemq.remoting.amqp.port=5673 -Dactivemq.remoting.stomp.port=61614 
-Dactivemq.remoting.hornetq.port=5446"
+if [ -z "$ARTEMIS_INSTANCE_URI" ]; then
+ARTEMIS_INSTANCE_URI='${artemis.instance.uri}'
+fi
 
+# Cluster Properties: Used to pass arguments to ActiveMQ Artemis which can 
be referenced in broker.xml
+if [ -z "$ARTEMIS_CLUSTER_PROPS" ]; then
+#ARTEMIS_CLUSTER_PROPS="-Dactivemq.remoting.default.port=61617 
-Dactivemq.remoting.amqp.port=5673 -Dactivemq.remoting.stomp.port=61614 
-Dactivemq.remoting.hornetq.port=5446"
--- End diff --

what's the point of adding this commented out? the user would have to add 
it anyways?


> Allow users to override JAVA_ARGS via environment variables
> ---
>
> Key: ARTEMIS-1676
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1676
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Martyn Taylor
>Priority: Major
>
> We currently require users to update the artemis.profile file to change 
> JAVA_ARGS options.   However, it's often useful to be able to override 
> certain properties via environment variables.  Typical example is when 
> running in a cloud environment, where customisation is often injected via 
> environment variables.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1676) Allow users to override JAVA_ARGS via environment variables

2018-02-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358620#comment-16358620
 ] 

ASF GitHub Bot commented on ARTEMIS-1676:
-

GitHub user mtaylor opened a pull request:

https://github.com/apache/activemq-artemis/pull/1862

ARTEMIS-1676 Support overriding of JAVA_ARGS via env variable



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mtaylor/activemq-artemis ARTEMIS-1676

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1862.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1862


commit 62d904f47979afae105981144053f30430ecd310
Author: Martyn Taylor 
Date:   2018-02-09T16:29:44Z

ARTEMIS-1676 Support overriding of JAVA_ARGS via env variable




> Allow users to override JAVA_ARGS via environment variables
> ---
>
> Key: ARTEMIS-1676
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1676
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Martyn Taylor
>Priority: Major
>
> We currently require users to update the artemis.profile file to change 
> JAVA_ARGS options.   However, it's often useful to be able to override 
> certain properties via environment variables.  Typical example is when 
> running in a cloud environment, where customisation is often injected via 
> environment variables.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (ARTEMIS-1676) Allow users to override JAVA_ARGS via environment variables

2018-02-09 Thread Martyn Taylor (JIRA)
Martyn Taylor created ARTEMIS-1676:
--

 Summary: Allow users to override JAVA_ARGS via environment 
variables
 Key: ARTEMIS-1676
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1676
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Reporter: Martyn Taylor


We currently require users to update the artemis.profile file to change 
JAVA_ARGS options.   However, it's often useful to be able to override certain 
properties via environment variables.  Typical example is when running in a 
cloud environment, where customisation is often injected via environment 
variables.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1675) Adding --safe option on print-data

2018-02-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358603#comment-16358603
 ] 

ASF GitHub Bot commented on ARTEMIS-1675:
-

GitHub user clebertsuconic opened a pull request:

https://github.com/apache/activemq-artemis/pull/1861

ARTEMIS-1675 Adding --safe option on print-data

This is good when you are a customer and an artemis engineer (e.g. me) asks 
your journal print-data but you can't do it because that would expose your 
user's data. If you do artemis data print --safe, that will only expose the 
journal structure without exposing user's data and eliminate any liability 
between the engineer and users.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/clebertsuconic/activemq-artemis ARTEMIS-1675

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1861.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1861


commit 5c61420c6964924a64d68bdcbf8ce9c8480f0163
Author: Clebert Suconic 
Date:   2018-02-09T16:09:57Z

ARTEMIS-1675 Adding --safe option on print-data

This is good when you are a customer and an artemis engineer (e.g. me) asks 
your journal print-data but you can't do it because that would expose your 
user's data. If you do artemis data print --safe, that will only expose the 
journal structure without exposing user's data and eliminate any liability 
between the engineer and users.




> Adding --safe option on print-data
> --
>
> Key: ARTEMIS-1675
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1675
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: clebert suconic
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.0
>
>
> This will avoid user's data from being exposed on print-data
>  
> This is good when you are a customer and an artemis engineer (e.g. me) asks 
> your journal print-data but you can't do it because that would expose your 
> user's data.
>  
> if you do artemis data print --safe, that will only expose the journal 
> structure without exposing user's data and eliminate any liability between 
> the engineer and users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1675) Adding --safe option on print-data

2018-02-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358604#comment-16358604
 ] 

ASF GitHub Bot commented on ARTEMIS-1675:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1861
  
@michaelandrepearce I think you would like this one. I talked to you in 
person about it.


> Adding --safe option on print-data
> --
>
> Key: ARTEMIS-1675
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1675
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: clebert suconic
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.0
>
>
> This will avoid user's data from being exposed on print-data
>  
> This is good when you are a customer and an artemis engineer (e.g. me) asks 
> your journal print-data but you can't do it because that would expose your 
> user's data.
>  
> if you do artemis data print --safe, that will only expose the journal 
> structure without exposing user's data and eliminate any liability between 
> the engineer and users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (ARTEMIS-1675) Adding --safe option on print-data

2018-02-09 Thread clebert suconic (JIRA)
clebert suconic created ARTEMIS-1675:


 Summary: Adding --safe option on print-data
 Key: ARTEMIS-1675
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1675
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Reporter: clebert suconic
Assignee: clebert suconic
 Fix For: 2.5.0


This will avoid user's data from being exposed on print-data

 

This is good when you are a customer and an artemis engineer (e.g. me) asks 
your journal print-data but you can't do it because that would expose your 
user's data.

 

if you do artemis data print --safe, that will only expose the journal 
structure without exposing user's data and eliminate any liability between the 
engineer and users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1662) Reduce log of "INFO [org.apache.activemq.artemis.core.client] (Thread-27 (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector version unknown to

2018-02-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358595#comment-16358595
 ] 

ASF GitHub Bot commented on ARTEMIS-1662:
-

Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1852#discussion_r167269720
  
--- Diff: 
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/ActiveMQClientLogger.java
 ---
@@ -64,7 +64,7 @@
@Message(id = 211001, value = "session created", format = 
Message.Format.MESSAGE_FORMAT)
void dumpingSessionStack(@Cause Exception e);
 
-   @LogMessage(level = Logger.Level.INFO)
+   @LogMessage(level = Logger.Level.DEBUG)
--- End diff --

@michaelandrepearce actually this is getting too verbose on clients.
We can use log.debug on the client... and you can increase logger if you 
really want it.

Some users will complain the opposite.


> Reduce log of "INFO [org.apache.activemq.artemis.core.client] (Thread-27 
> (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector 
> version unknown to ..." to DEBUG
> 
>
> Key: ARTEMIS-1662
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1662
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Dmitrii Tikhomirov
>Priority: Major
>
> Information of starting connector is now logged on INFO level which 
> over-floods server logs:
> {code}
> 05:46:05,073 INFO [org.apache.activemq.artemis.core.client] (Thread-27 
> (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector 
> version unknown to rhel7-large-461:8080
> {code}
> It should be decresed to DEBUG level.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1662) Reduce log of "INFO [org.apache.activemq.artemis.core.client] (Thread-27 (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector version unknown to

2018-02-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358568#comment-16358568
 ] 

ASF GitHub Bot commented on ARTEMIS-1662:
-

Github user michaelandrepearce commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1852#discussion_r167261076
  
--- Diff: 
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/ActiveMQClientLogger.java
 ---
@@ -64,7 +64,7 @@
@Message(id = 211001, value = "session created", format = 
Message.Format.MESSAGE_FORMAT)
void dumpingSessionStack(@Cause Exception e);
 
-   @LogMessage(level = Logger.Level.INFO)
+   @LogMessage(level = Logger.Level.DEBUG)
--- End diff --

Agreed server side, but client side this is far too useful to lose. 



> Reduce log of "INFO [org.apache.activemq.artemis.core.client] (Thread-27 
> (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector 
> version unknown to ..." to DEBUG
> 
>
> Key: ARTEMIS-1662
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1662
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Dmitrii Tikhomirov
>Priority: Major
>
> Information of starting connector is now logged on INFO level which 
> over-floods server logs:
> {code}
> 05:46:05,073 INFO [org.apache.activemq.artemis.core.client] (Thread-27 
> (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector 
> version unknown to rhel7-large-461:8080
> {code}
> It should be decresed to DEBUG level.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1662) Reduce log of "INFO [org.apache.activemq.artemis.core.client] (Thread-27 (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector version unknown to

2018-02-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358469#comment-16358469
 ] 

ASF GitHub Bot commented on ARTEMIS-1662:
-

Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1852#discussion_r167242748
  
--- Diff: 
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/ActiveMQClientLogger.java
 ---
@@ -64,7 +64,7 @@
@Message(id = 211001, value = "session created", format = 
Message.Format.MESSAGE_FORMAT)
void dumpingSessionStack(@Cause Exception e);
 
-   @LogMessage(level = Logger.Level.INFO)
+   @LogMessage(level = Logger.Level.DEBUG)
--- End diff --

@michaelandrepearce I was actually considering doing this myself... the 
clients are too verbose.. some users will open and create connections all the 
time.. this becomes too verbose.


> Reduce log of "INFO [org.apache.activemq.artemis.core.client] (Thread-27 
> (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector 
> version unknown to ..." to DEBUG
> 
>
> Key: ARTEMIS-1662
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1662
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Dmitrii Tikhomirov
>Priority: Major
>
> Information of starting connector is now logged on INFO level which 
> over-floods server logs:
> {code}
> 05:46:05,073 INFO [org.apache.activemq.artemis.core.client] (Thread-27 
> (ActiveMQ-client-global-threads)) AMQ211002: Started EPOLL Netty Connector 
> version unknown to rhel7-large-461:8080
> {code}
> It should be decresed to DEBUG level.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1670) NPE was found in when dropping durable subscriptions from a topic

2018-02-09 Thread clebert suconic (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358442#comment-16358442
 ] 

clebert suconic commented on ARTEMIS-1670:
--

This only applies to 1.x... I will be merging it.

> NPE was found in when dropping durable subscriptions from a topic
> -
>
> Key: ARTEMIS-1670
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1670
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.5
>Reporter: Lin Gao
>Priority: Major
> Fix For: 1.5.6
>
>
> In WildFly, set up a topic by executing following CLI:
> {code:java}
> /subsystem=messaging-activemq/server=default:write-attribute(name=security-enabled,value=false)
> :reload
> /subsystem=messaging-activemq/server=default/jms-topic=testTopic:add(entries=[java:/jms/topic/testTopic,
>  java:jboss/exported/jms/topic/testTopic])
> {code}
> Then create a durable subscriber on it using the following test code:
>   
> {code:java}
> public static void main(String[] args) throws Exception {
>   Connection connection = null;
> Context namingContext = null;
> try {
> final Properties env = new Properties();
> env.put(Context.INITIAL_CONTEXT_FACTORY, 
> "org.wildfly.naming.client.WildFlyInitialContextFactory");
> env.put(Context.PROVIDER_URL, 
> System.getProperty(Context.PROVIDER_URL, "http-remoting://127.0.0.1:8080"));
> namingContext = new InitialContext(env);
> Topic topic = (Topic) 
> namingContext.lookup("/jms/topic/testTopic");
> ConnectionFactory connectionFactory = (ConnectionFactory) 
> namingContext.lookup("jms/RemoteConnectionFactory");
> connection = connectionFactory.createConnection();
> connection.setClientID("durable-client");
> connection.start();
> Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
> MessageProducer messageProducer = session.createProducer(topic);
> TopicSubscriber subscriber = 
> session.createDurableSubscriber(topic, "subscriber-1");
> TextMessage message1 = session.createTextMessage("This is a text 
> message 1");
> messageProducer.send(message1);
> System.out.println("Sent message: " + message1.getText());
> TextMessage messageReceived = (TextMessage) subscriber.receive();
> System.out.println("Received message: " + 
> messageReceived.getText());
> try {
>   Thread.sleep(2); // wait 20 seconds before 
> un-subscribe
>   } catch (InterruptedException e) {
>   e.printStackTrace();
>   }
> subscriber.close();
> session.unsubscribe("subscriber-1");
> } finally {
>   if (connection != null) {
>   connection.close();
>   }
> if (namingContext != null) {
>   namingContext.close();
> }
> }
> }
> {code}
>  
>  The code above will sleep 20 seconds before un-subscribe, try to execute the 
> following WildFly CLI within 20 seconds:
> {code:java}
> /subsystem=messaging-activemq/server=default/jms-topic=testTopic:drop-durable-subscription(client-id=durable-client,
>  subscription-name=subscriber-1)
> {code}
>  
>  The WildFly CLI succeeded, but there is a NPE in the server log:
> {code:java}
> 09:10:42,340 ERROR [org.apache.activemq.artemis.core.server] (Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@7ba46694))
>  AMQ224065: Failed to remove auto-created queue 
> testSubscriberClientIdjmsTopicOperations.testSubscriber: 
> java.lang.NullPointerException
>   at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$JMSQueueDeleter.delete(JMSServerManagerImpl.java:1669)
>  [artemis-jms-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.core.server.impl.AutoCreatedQueueManagerImpl$1.run(AutoCreatedQueueManagerImpl.java:36)
>  [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.utils.ReferenceCounterUtil.decrement(ReferenceCounterUtil.java:54)
>  [artemis-commons-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.core.server.impl.AutoCreatedQueueManagerImpl.decrement(AutoCreatedQueueManagerImpl.java:58)
>  [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.removeConsumer(QueueImpl.java:786)
>  [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>  

[jira] [Commented] (ARTEMIS-1670) NPE was found in when dropping durable subscriptions from a topic

2018-02-09 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358443#comment-16358443
 ] 

ASF subversion and git services commented on ARTEMIS-1670:
--

Commit 3e212c09db04e22c76d443bede5ac00a2c86ba6a in activemq-artemis's branch 
refs/heads/1.x from Lin Gao
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=3e212c0 ]

[ARTEMIS-1670] NPE was found in when dropping durable subscriptions from a topic


> NPE was found in when dropping durable subscriptions from a topic
> -
>
> Key: ARTEMIS-1670
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1670
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.5
>Reporter: Lin Gao
>Priority: Major
> Fix For: 1.5.6
>
>
> In WildFly, set up a topic by executing following CLI:
> {code:java}
> /subsystem=messaging-activemq/server=default:write-attribute(name=security-enabled,value=false)
> :reload
> /subsystem=messaging-activemq/server=default/jms-topic=testTopic:add(entries=[java:/jms/topic/testTopic,
>  java:jboss/exported/jms/topic/testTopic])
> {code}
> Then create a durable subscriber on it using the following test code:
>   
> {code:java}
> public static void main(String[] args) throws Exception {
>   Connection connection = null;
> Context namingContext = null;
> try {
> final Properties env = new Properties();
> env.put(Context.INITIAL_CONTEXT_FACTORY, 
> "org.wildfly.naming.client.WildFlyInitialContextFactory");
> env.put(Context.PROVIDER_URL, 
> System.getProperty(Context.PROVIDER_URL, "http-remoting://127.0.0.1:8080"));
> namingContext = new InitialContext(env);
> Topic topic = (Topic) 
> namingContext.lookup("/jms/topic/testTopic");
> ConnectionFactory connectionFactory = (ConnectionFactory) 
> namingContext.lookup("jms/RemoteConnectionFactory");
> connection = connectionFactory.createConnection();
> connection.setClientID("durable-client");
> connection.start();
> Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
> MessageProducer messageProducer = session.createProducer(topic);
> TopicSubscriber subscriber = 
> session.createDurableSubscriber(topic, "subscriber-1");
> TextMessage message1 = session.createTextMessage("This is a text 
> message 1");
> messageProducer.send(message1);
> System.out.println("Sent message: " + message1.getText());
> TextMessage messageReceived = (TextMessage) subscriber.receive();
> System.out.println("Received message: " + 
> messageReceived.getText());
> try {
>   Thread.sleep(2); // wait 20 seconds before 
> un-subscribe
>   } catch (InterruptedException e) {
>   e.printStackTrace();
>   }
> subscriber.close();
> session.unsubscribe("subscriber-1");
> } finally {
>   if (connection != null) {
>   connection.close();
>   }
> if (namingContext != null) {
>   namingContext.close();
> }
> }
> }
> {code}
>  
>  The code above will sleep 20 seconds before un-subscribe, try to execute the 
> following WildFly CLI within 20 seconds:
> {code:java}
> /subsystem=messaging-activemq/server=default/jms-topic=testTopic:drop-durable-subscription(client-id=durable-client,
>  subscription-name=subscriber-1)
> {code}
>  
>  The WildFly CLI succeeded, but there is a NPE in the server log:
> {code:java}
> 09:10:42,340 ERROR [org.apache.activemq.artemis.core.server] (Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@7ba46694))
>  AMQ224065: Failed to remove auto-created queue 
> testSubscriberClientIdjmsTopicOperations.testSubscriber: 
> java.lang.NullPointerException
>   at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$JMSQueueDeleter.delete(JMSServerManagerImpl.java:1669)
>  [artemis-jms-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.core.server.impl.AutoCreatedQueueManagerImpl$1.run(AutoCreatedQueueManagerImpl.java:36)
>  [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.utils.ReferenceCounterUtil.decrement(ReferenceCounterUtil.java:54)
>  [artemis-commons-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.core.server.impl.AutoCreatedQueueManagerImpl.decrement(AutoCreatedQueueManagerI

[jira] [Commented] (ARTEMIS-1670) NPE was found in when dropping durable subscriptions from a topic

2018-02-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358444#comment-16358444
 ] 

ASF GitHub Bot commented on ARTEMIS-1670:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1860


> NPE was found in when dropping durable subscriptions from a topic
> -
>
> Key: ARTEMIS-1670
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1670
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.5
>Reporter: Lin Gao
>Priority: Major
> Fix For: 1.5.6
>
>
> In WildFly, set up a topic by executing following CLI:
> {code:java}
> /subsystem=messaging-activemq/server=default:write-attribute(name=security-enabled,value=false)
> :reload
> /subsystem=messaging-activemq/server=default/jms-topic=testTopic:add(entries=[java:/jms/topic/testTopic,
>  java:jboss/exported/jms/topic/testTopic])
> {code}
> Then create a durable subscriber on it using the following test code:
>   
> {code:java}
> public static void main(String[] args) throws Exception {
>   Connection connection = null;
> Context namingContext = null;
> try {
> final Properties env = new Properties();
> env.put(Context.INITIAL_CONTEXT_FACTORY, 
> "org.wildfly.naming.client.WildFlyInitialContextFactory");
> env.put(Context.PROVIDER_URL, 
> System.getProperty(Context.PROVIDER_URL, "http-remoting://127.0.0.1:8080"));
> namingContext = new InitialContext(env);
> Topic topic = (Topic) 
> namingContext.lookup("/jms/topic/testTopic");
> ConnectionFactory connectionFactory = (ConnectionFactory) 
> namingContext.lookup("jms/RemoteConnectionFactory");
> connection = connectionFactory.createConnection();
> connection.setClientID("durable-client");
> connection.start();
> Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
> MessageProducer messageProducer = session.createProducer(topic);
> TopicSubscriber subscriber = 
> session.createDurableSubscriber(topic, "subscriber-1");
> TextMessage message1 = session.createTextMessage("This is a text 
> message 1");
> messageProducer.send(message1);
> System.out.println("Sent message: " + message1.getText());
> TextMessage messageReceived = (TextMessage) subscriber.receive();
> System.out.println("Received message: " + 
> messageReceived.getText());
> try {
>   Thread.sleep(2); // wait 20 seconds before 
> un-subscribe
>   } catch (InterruptedException e) {
>   e.printStackTrace();
>   }
> subscriber.close();
> session.unsubscribe("subscriber-1");
> } finally {
>   if (connection != null) {
>   connection.close();
>   }
> if (namingContext != null) {
>   namingContext.close();
> }
> }
> }
> {code}
>  
>  The code above will sleep 20 seconds before un-subscribe, try to execute the 
> following WildFly CLI within 20 seconds:
> {code:java}
> /subsystem=messaging-activemq/server=default/jms-topic=testTopic:drop-durable-subscription(client-id=durable-client,
>  subscription-name=subscriber-1)
> {code}
>  
>  The WildFly CLI succeeded, but there is a NPE in the server log:
> {code:java}
> 09:10:42,340 ERROR [org.apache.activemq.artemis.core.server] (Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@7ba46694))
>  AMQ224065: Failed to remove auto-created queue 
> testSubscriberClientIdjmsTopicOperations.testSubscriber: 
> java.lang.NullPointerException
>   at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$JMSQueueDeleter.delete(JMSServerManagerImpl.java:1669)
>  [artemis-jms-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.core.server.impl.AutoCreatedQueueManagerImpl$1.run(AutoCreatedQueueManagerImpl.java:36)
>  [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.utils.ReferenceCounterUtil.decrement(ReferenceCounterUtil.java:54)
>  [artemis-commons-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.core.server.impl.AutoCreatedQueueManagerImpl.decrement(AutoCreatedQueueManagerImpl.java:58)
>  [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.removeConsumer(QueueImpl.java:786)
>  [artemis-ser

[jira] [Updated] (ARTEMIS-1670) NPE was found in when dropping durable subscriptions from a topic

2018-02-09 Thread clebert suconic (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

clebert suconic updated ARTEMIS-1670:
-
Fix Version/s: 1.5.6

> NPE was found in when dropping durable subscriptions from a topic
> -
>
> Key: ARTEMIS-1670
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1670
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.5
>Reporter: Lin Gao
>Priority: Major
> Fix For: 1.5.6
>
>
> In WildFly, set up a topic by executing following CLI:
> {code:java}
> /subsystem=messaging-activemq/server=default:write-attribute(name=security-enabled,value=false)
> :reload
> /subsystem=messaging-activemq/server=default/jms-topic=testTopic:add(entries=[java:/jms/topic/testTopic,
>  java:jboss/exported/jms/topic/testTopic])
> {code}
> Then create a durable subscriber on it using the following test code:
>   
> {code:java}
> public static void main(String[] args) throws Exception {
>   Connection connection = null;
> Context namingContext = null;
> try {
> final Properties env = new Properties();
> env.put(Context.INITIAL_CONTEXT_FACTORY, 
> "org.wildfly.naming.client.WildFlyInitialContextFactory");
> env.put(Context.PROVIDER_URL, 
> System.getProperty(Context.PROVIDER_URL, "http-remoting://127.0.0.1:8080"));
> namingContext = new InitialContext(env);
> Topic topic = (Topic) 
> namingContext.lookup("/jms/topic/testTopic");
> ConnectionFactory connectionFactory = (ConnectionFactory) 
> namingContext.lookup("jms/RemoteConnectionFactory");
> connection = connectionFactory.createConnection();
> connection.setClientID("durable-client");
> connection.start();
> Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
> MessageProducer messageProducer = session.createProducer(topic);
> TopicSubscriber subscriber = 
> session.createDurableSubscriber(topic, "subscriber-1");
> TextMessage message1 = session.createTextMessage("This is a text 
> message 1");
> messageProducer.send(message1);
> System.out.println("Sent message: " + message1.getText());
> TextMessage messageReceived = (TextMessage) subscriber.receive();
> System.out.println("Received message: " + 
> messageReceived.getText());
> try {
>   Thread.sleep(2); // wait 20 seconds before 
> un-subscribe
>   } catch (InterruptedException e) {
>   e.printStackTrace();
>   }
> subscriber.close();
> session.unsubscribe("subscriber-1");
> } finally {
>   if (connection != null) {
>   connection.close();
>   }
> if (namingContext != null) {
>   namingContext.close();
> }
> }
> }
> {code}
>  
>  The code above will sleep 20 seconds before un-subscribe, try to execute the 
> following WildFly CLI within 20 seconds:
> {code:java}
> /subsystem=messaging-activemq/server=default/jms-topic=testTopic:drop-durable-subscription(client-id=durable-client,
>  subscription-name=subscriber-1)
> {code}
>  
>  The WildFly CLI succeeded, but there is a NPE in the server log:
> {code:java}
> 09:10:42,340 ERROR [org.apache.activemq.artemis.core.server] (Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@7ba46694))
>  AMQ224065: Failed to remove auto-created queue 
> testSubscriberClientIdjmsTopicOperations.testSubscriber: 
> java.lang.NullPointerException
>   at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$JMSQueueDeleter.delete(JMSServerManagerImpl.java:1669)
>  [artemis-jms-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.core.server.impl.AutoCreatedQueueManagerImpl$1.run(AutoCreatedQueueManagerImpl.java:36)
>  [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.utils.ReferenceCounterUtil.decrement(ReferenceCounterUtil.java:54)
>  [artemis-commons-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.core.server.impl.AutoCreatedQueueManagerImpl.decrement(AutoCreatedQueueManagerImpl.java:58)
>  [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.removeConsumer(QueueImpl.java:786)
>  [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]
>   at 
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.removeItself

[jira] [Commented] (ARTEMIS-1659) AMQ224000: Failure in initialisation: java.lang.IllegalStateException: java.lang.IllegalStateException: Cursor 28 had already been created

2018-02-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358433#comment-16358433
 ] 

ASF GitHub Bot commented on ARTEMIS-1659:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1859


>  AMQ224000: Failure in initialisation: java.lang.IllegalStateException: 
> java.lang.IllegalStateException: Cursor 28 had already been created
> ---
>
> Key: ARTEMIS-1659
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1659
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.0.0
> Environment:  Artemis 2
>Reporter: Tom Ross
>Priority: Major
>
> The following exception can be seen in the amq log file 
> {noformat}
> 08:07:04,658 ERROR [org.apache.activemq.artemis.core.server] AMQ224000: 
> Failure in initialisation: java.lang.IllegalStateException: 
> java.lang.IllegalStateException: Cursor 28 had already been created
> at 
> org.apache.activemq.artemis.core.server.QueueConfig$Builder.build(QueueConfig.java:151)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.PostOfficeJournalLoader.initQueues(PostOfficeJournalLoader.java:154)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:2481)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2258)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:342)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2866)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> Caused by: java.lang.IllegalStateException: Cursor 28 had already been created
> at 
> org.apache.activemq.artemis.core.paging.cursor.impl.PageCursorProviderImpl.createSubscription(PageCursorProviderImpl.java:100)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.QueueConfig$Builder.build(QueueConfig.java:149)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> ... 5 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1659) AMQ224000: Failure in initialisation: java.lang.IllegalStateException: java.lang.IllegalStateException: Cursor 28 had already been created

2018-02-09 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358431#comment-16358431
 ] 

ASF subversion and git services commented on ARTEMIS-1659:
--

Commit 70406bf21c9b65664ed1f011b3d7cebffda88593 in activemq-artemis's branch 
refs/heads/master from [~michael.andre.pearce]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=70406bf ]

ARTEMIS-1659 - Only reload configuration if the node is Active.



>  AMQ224000: Failure in initialisation: java.lang.IllegalStateException: 
> java.lang.IllegalStateException: Cursor 28 had already been created
> ---
>
> Key: ARTEMIS-1659
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1659
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.0.0
> Environment:  Artemis 2
>Reporter: Tom Ross
>Priority: Major
>
> The following exception can be seen in the amq log file 
> {noformat}
> 08:07:04,658 ERROR [org.apache.activemq.artemis.core.server] AMQ224000: 
> Failure in initialisation: java.lang.IllegalStateException: 
> java.lang.IllegalStateException: Cursor 28 had already been created
> at 
> org.apache.activemq.artemis.core.server.QueueConfig$Builder.build(QueueConfig.java:151)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.PostOfficeJournalLoader.initQueues(PostOfficeJournalLoader.java:154)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:2481)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2258)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:342)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2866)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> Caused by: java.lang.IllegalStateException: Cursor 28 had already been created
> at 
> org.apache.activemq.artemis.core.paging.cursor.impl.PageCursorProviderImpl.createSubscription(PageCursorProviderImpl.java:100)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.QueueConfig$Builder.build(QueueConfig.java:149)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> ... 5 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (ARTEMIS-1674) Dependency Conflict : Conflicting classes existing in two libraries

2018-02-09 Thread PandaMonkey (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

PandaMonkey updated ARTEMIS-1674:
-
Description: 
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
 The following duplicate class pairs having the same names but their internal 
implementations are different in different JARs:
 "org.jboss.logging.Log4j2LoggerProvider", 
 "org.jboss.logging.MDC", 
 "org.jboss.logging.JBossLogManagerProvider",
 "org.jboss.logging.Slf4jLoggerProvider", 
 "org.jboss.logging.Log4j2Logger", 
 "org.jboss.logging.JBossLogManagerLogger", 

.

Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
truck evolution process, which may throw the java.lang.NoSuchMethodException at 
runtime.

The conflicting features' details are shown in the attachment. Hope this report 
can help you, thanks!

  was:
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
 The following duplicate class pairs having the same names but their internal 
implementations are different in different JARs:
 "org.jboss.logging.Log4j2LoggerProvider", 
 "org.jboss.logging.MDC", 
 "org.jboss.logging.JBossLogManagerProvider",
 "org.jboss.logging.Slf4jLoggerProvider", 
 "org.jboss.logging.Log4j2Logger", 
 "org.jboss.logging.JBossLogManagerLogger", 

.

Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
truck evolution process, which may throw the java.lang.NoSuchMethodException at 
runtime.

The conflicting features' details are shown in the attachment.

Hope this report can help you, thanks!


> Dependency Conflict : Conflicting classes existing in two libraries
> ---
>
> Key: ARTEMIS-1674
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1674
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: [^Conflicting libs.TXT]
>Reporter: PandaMonkey
>Priority: Major
>  Labels: features
> Fix For: 2.5.0
>
> Attachments: Conflicting libs.TXT
>
>
> Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT 
> "artemis-cdi-client\pom.xml" and its bytecodes, we found libraries 
> "org.jboss.weld.se:weld-se:2.4.0.Final" and 
> "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
>  The following duplicate class pairs having the same names but their internal 
> implementations are different in different JARs:
>  "org.jboss.logging.Log4j2LoggerProvider", 
>  "org.jboss.logging.MDC", 
>  "org.jboss.logging.JBossLogManagerProvider",
>  "org.jboss.logging.Slf4jLoggerProvider", 
>  "org.jboss.logging.Log4j2Logger", 
>  "org.jboss.logging.JBossLogManagerLogger", 
> .
> Some methods only exist in one class version:
>  org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
>  org.jboss.logging.Log4jLoggerProvider: void clearMdc()
>  org.jboss.logging.MDC: void clear()
>  ..
> Please notice this problem, it brings high risks of classpath issues during 
> the truck evolution process, which may throw the 
> java.lang.NoSuchMethodException at runtime.
> The conflicting features' details are shown in the attachment. Hope this 
> report can help you, thanks!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (ARTEMIS-1674) Dependency Conflict : Conflicting classes existing in two libraries

2018-02-09 Thread PandaMonkey (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

PandaMonkey updated ARTEMIS-1674:
-
Description: 
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
 The following duplicate class pairs having the same names but their internal 
implementations are different in different JARs:
 "org.jboss.logging.Log4j2LoggerProvider", 
 "org.jboss.logging.MDC", 
 "org.jboss.logging.JBossLogManagerProvider",
 "org.jboss.logging.Slf4jLoggerProvider", 
 "org.jboss.logging.Log4j2Logger", 
 "org.jboss.logging.JBossLogManagerLogger", 

.

Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
truck evolution process, which may throw the java.lang.NoSuchMethodException at 
runtime.

The conflicting features' details are shown in the attachment.

Hope this report can help you, thanks!

  was:
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
 The following duplicate class pairs having the same names but their internal 
implementations are different in different JARs:
 "org.jboss.logging.Log4j2LoggerProvider", 
 "org.jboss.logging.MDC", 
 "org.jboss.logging.JBossLogManagerProvider",
 "org.jboss.logging.Slf4jLoggerProvider", 
 "org.jboss.logging.Log4j2Logger", 
 "org.jboss.logging.JBossLogManagerLogger", 

.

Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
truck evolution process, which may throw the java.lang.NoSuchMethodException at 
runtime.

The conflicting features' details are shown in the attachment.


> Dependency Conflict : Conflicting classes existing in two libraries
> ---
>
> Key: ARTEMIS-1674
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1674
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: [^Conflicting libs.TXT]
>Reporter: PandaMonkey
>Priority: Major
>  Labels: features
> Fix For: 2.5.0
>
> Attachments: Conflicting libs.TXT
>
>
> Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT 
> "artemis-cdi-client\pom.xml" and its bytecodes, we found libraries 
> "org.jboss.weld.se:weld-se:2.4.0.Final" and 
> "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
>  The following duplicate class pairs having the same names but their internal 
> implementations are different in different JARs:
>  "org.jboss.logging.Log4j2LoggerProvider", 
>  "org.jboss.logging.MDC", 
>  "org.jboss.logging.JBossLogManagerProvider",
>  "org.jboss.logging.Slf4jLoggerProvider", 
>  "org.jboss.logging.Log4j2Logger", 
>  "org.jboss.logging.JBossLogManagerLogger", 
> .
> Some methods only exist in one class version:
>  org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
>  org.jboss.logging.Log4jLoggerProvider: void clearMdc()
>  org.jboss.logging.MDC: void clear()
>  ..
> Please notice this problem, it brings high risks of classpath issues during 
> the truck evolution process, which may throw the 
> java.lang.NoSuchMethodException at runtime.
> The conflicting features' details are shown in the attachment.
> Hope this report can help you, thanks!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (ARTEMIS-1674) Dependency Conflict : Conflicting classes existing in two libraries

2018-02-09 Thread PandaMonkey (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

PandaMonkey updated ARTEMIS-1674:
-
Description: 
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
 The following duplicate class pairs having the same names but their internal 
implementations are different in different JARs:
 "org.jboss.logging.Log4j2LoggerProvider", 
 "org.jboss.logging.MDC", 
 "org.jboss.logging.JBossLogManagerProvider",
 "org.jboss.logging.Slf4jLoggerProvider", 
 "org.jboss.logging.Log4j2Logger", 
 "org.jboss.logging.JBossLogManagerLogger", 

.

Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
truck evolution process, which may throw the java.lang.NoSuchMethodException at 
runtime.

The conflicting features' details are shown in the attachment.

  was:
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
 The following duplicate class pairs having the same names but their internal 
implementations are different in different JARs:
 "org.jboss.logging.Log4j2LoggerProvider", 
 "org.jboss.logging.MDC", 
 "org.jboss.logging.JBossLogManagerProvider",
 "org.jboss.logging.Slf4jLoggerProvider", 
 "org.jboss.logging.Log4j2Logger", 
 "org.jboss.logging.JBossLogManagerLogger", 

.

Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
truck evolution process, which may throw the nosuchmehtodException at runtime.

The conflicting features' details are shown in the attachment.


> Dependency Conflict : Conflicting classes existing in two libraries
> ---
>
> Key: ARTEMIS-1674
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1674
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: [^Conflicting libs.TXT]
>Reporter: PandaMonkey
>Priority: Major
>  Labels: features
> Fix For: 2.5.0
>
> Attachments: Conflicting libs.TXT
>
>
> Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT 
> "artemis-cdi-client\pom.xml" and its bytecodes, we found libraries 
> "org.jboss.weld.se:weld-se:2.4.0.Final" and 
> "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
>  The following duplicate class pairs having the same names but their internal 
> implementations are different in different JARs:
>  "org.jboss.logging.Log4j2LoggerProvider", 
>  "org.jboss.logging.MDC", 
>  "org.jboss.logging.JBossLogManagerProvider",
>  "org.jboss.logging.Slf4jLoggerProvider", 
>  "org.jboss.logging.Log4j2Logger", 
>  "org.jboss.logging.JBossLogManagerLogger", 
> .
> Some methods only exist in one class version:
>  org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
>  org.jboss.logging.Log4jLoggerProvider: void clearMdc()
>  org.jboss.logging.MDC: void clear()
>  ..
> Please notice this problem, it brings high risks of classpath issues during 
> the truck evolution process, which may throw the 
> java.lang.NoSuchMethodException at runtime.
> The conflicting features' details are shown in the attachment.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (ARTEMIS-1674) Dependency Conflict : Conflicting classes existing in two libraries

2018-02-09 Thread PandaMonkey (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

PandaMonkey updated ARTEMIS-1674:
-
Description: 
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
 The following duplicate class pairs having the same names but their internal 
implementations are different in different JARs:
 "org.jboss.logging.Log4j2LoggerProvider", 
 "org.jboss.logging.MDC", 
 "org.jboss.logging.JBossLogManagerProvider",
 "org.jboss.logging.Slf4jLoggerProvider", 
 "org.jboss.logging.Log4j2Logger", 
 "org.jboss.logging.JBossLogManagerLogger", 

.

Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
evolution process, which may throw the nosuchmehtodException at runtime.

The conflicting features' details are shown in the attachment.

  was:
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
 The following duplicate class pairs having the same names but their internal 
implementations are different in different JARs:
 "org.jboss.logging.Log4j2LoggerProvider", 
 "org.jboss.logging.MDC", 
 "org.jboss.logging.JBossLogManagerProvider",
 "org.jboss.logging.Slf4jLoggerProvider", 
 "org.jboss.logging.Log4j2Logger", 
 "org.jboss.logging.JBossLogManagerLogger", 
 "org.jboss.logging.JDKLogger".

Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
evolution process, which may throw the nosuchmehtodException at runtime.

The conflicting features' details are shown in the attachment.


> Dependency Conflict : Conflicting classes existing in two libraries
> ---
>
> Key: ARTEMIS-1674
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1674
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: [^Conflicting libs.TXT]
>Reporter: PandaMonkey
>Priority: Major
>  Labels: features
> Fix For: 2.5.0
>
> Attachments: Conflicting libs.TXT
>
>
> Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT 
> "artemis-cdi-client\pom.xml" and its bytecodes, we found libraries 
> "org.jboss.weld.se:weld-se:2.4.0.Final" and 
> "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
>  The following duplicate class pairs having the same names but their internal 
> implementations are different in different JARs:
>  "org.jboss.logging.Log4j2LoggerProvider", 
>  "org.jboss.logging.MDC", 
>  "org.jboss.logging.JBossLogManagerProvider",
>  "org.jboss.logging.Slf4jLoggerProvider", 
>  "org.jboss.logging.Log4j2Logger", 
>  "org.jboss.logging.JBossLogManagerLogger", 
> .
> Some methods only exist in one class version:
>  org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
>  org.jboss.logging.Log4jLoggerProvider: void clearMdc()
>  org.jboss.logging.MDC: void clear()
>  ..
> Please notice this problem, it brings high risks of classpath issues during 
> the evolution process, which may throw the nosuchmehtodException at runtime.
> The conflicting features' details are shown in the attachment.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (ARTEMIS-1674) Dependency Conflict : Conflicting classes existing in two libraries

2018-02-09 Thread PandaMonkey (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

PandaMonkey updated ARTEMIS-1674:
-
Description: 
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
 The following duplicate class pairs having the same names but their internal 
implementations are different in different JARs:
 "org.jboss.logging.Log4j2LoggerProvider", 
 "org.jboss.logging.MDC", 
 "org.jboss.logging.JBossLogManagerProvider",
 "org.jboss.logging.Slf4jLoggerProvider", 
 "org.jboss.logging.Log4j2Logger", 
 "org.jboss.logging.JBossLogManagerLogger", 

.

Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
truck evolution process, which may throw the nosuchmehtodException at runtime.

The conflicting features' details are shown in the attachment.

  was:
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
 The following duplicate class pairs having the same names but their internal 
implementations are different in different JARs:
 "org.jboss.logging.Log4j2LoggerProvider", 
 "org.jboss.logging.MDC", 
 "org.jboss.logging.JBossLogManagerProvider",
 "org.jboss.logging.Slf4jLoggerProvider", 
 "org.jboss.logging.Log4j2Logger", 
 "org.jboss.logging.JBossLogManagerLogger", 

.

Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
evolution process, which may throw the nosuchmehtodException at runtime.

The conflicting features' details are shown in the attachment.


> Dependency Conflict : Conflicting classes existing in two libraries
> ---
>
> Key: ARTEMIS-1674
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1674
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: [^Conflicting libs.TXT]
>Reporter: PandaMonkey
>Priority: Major
>  Labels: features
> Fix For: 2.5.0
>
> Attachments: Conflicting libs.TXT
>
>
> Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT 
> "artemis-cdi-client\pom.xml" and its bytecodes, we found libraries 
> "org.jboss.weld.se:weld-se:2.4.0.Final" and 
> "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
>  The following duplicate class pairs having the same names but their internal 
> implementations are different in different JARs:
>  "org.jboss.logging.Log4j2LoggerProvider", 
>  "org.jboss.logging.MDC", 
>  "org.jboss.logging.JBossLogManagerProvider",
>  "org.jboss.logging.Slf4jLoggerProvider", 
>  "org.jboss.logging.Log4j2Logger", 
>  "org.jboss.logging.JBossLogManagerLogger", 
> .
> Some methods only exist in one class version:
>  org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
>  org.jboss.logging.Log4jLoggerProvider: void clearMdc()
>  org.jboss.logging.MDC: void clear()
>  ..
> Please notice this problem, it brings high risks of classpath issues during 
> the truck evolution process, which may throw the nosuchmehtodException at 
> runtime.
> The conflicting features' details are shown in the attachment.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (ARTEMIS-1674) Dependency Conflict : Conflicting classes existing in two libraries

2018-02-09 Thread PandaMonkey (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

PandaMonkey updated ARTEMIS-1674:
-
Description: 
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
 The following duplicate class pairs having the same names but their internal 
implementations are different in different JARs:
 "org.jboss.logging.Log4j2LoggerProvider", 
 "org.jboss.logging.MDC", 
 "org.jboss.logging.JBossLogManagerProvider",
 "org.jboss.logging.Slf4jLoggerProvider", 
 "org.jboss.logging.Log4j2Logger", 
 "org.jboss.logging.JBossLogManagerLogger", 
 "org.jboss.logging.JDKLogger".

Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
evolution process, which may throw the nosuchmehtodException at runtime.

The conflicting features' details are shown in the attachment.

  was:
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
The following duplicate class pairs having the same names but their internal 
implementations are different:
"org.jboss.logging.Log4j2LoggerProvider", 
"org.jboss.logging.MDC", 
"org.jboss.logging.JBossLogManagerProvider",
"org.jboss.logging.Slf4jLoggerProvider", 
"org.jboss.logging.Log4j2Logger", 
"org.jboss.logging.JBossLogManagerLogger", 
"org.jboss.logging.JDKLogger".
 
Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
evolution process, which may throw the nosuchmehtodException at runtime.
 
The conflicting features' details are shown in the attachment.


> Dependency Conflict : Conflicting classes existing in two libraries
> ---
>
> Key: ARTEMIS-1674
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1674
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: [^Conflicting libs.TXT]
>Reporter: PandaMonkey
>Priority: Major
>  Labels: features
> Fix For: 2.5.0
>
> Attachments: Conflicting libs.TXT
>
>
> Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT 
> "artemis-cdi-client\pom.xml" and its bytecodes, we found libraries 
> "org.jboss.weld.se:weld-se:2.4.0.Final" and 
> "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
>  The following duplicate class pairs having the same names but their internal 
> implementations are different in different JARs:
>  "org.jboss.logging.Log4j2LoggerProvider", 
>  "org.jboss.logging.MDC", 
>  "org.jboss.logging.JBossLogManagerProvider",
>  "org.jboss.logging.Slf4jLoggerProvider", 
>  "org.jboss.logging.Log4j2Logger", 
>  "org.jboss.logging.JBossLogManagerLogger", 
>  "org.jboss.logging.JDKLogger".
> Some methods only exist in one class version:
>  org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
>  org.jboss.logging.Log4jLoggerProvider: void clearMdc()
>  org.jboss.logging.MDC: void clear()
>  ..
> Please notice this problem, it brings high risks of classpath issues during 
> the evolution process, which may throw the nosuchmehtodException at runtime.
> The conflicting features' details are shown in the attachment.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (ARTEMIS-1674) Dependency Conflict : Conflicting classes existing in two libraries

2018-02-09 Thread PandaMonkey (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

PandaMonkey updated ARTEMIS-1674:
-
Description: 
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes, we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
The following duplicate class pairs having the same names but their internal 
implementations are different:
"org.jboss.logging.Log4j2LoggerProvider", 
"org.jboss.logging.MDC", 
"org.jboss.logging.JBossLogManagerProvider",
"org.jboss.logging.Slf4jLoggerProvider", 
"org.jboss.logging.Log4j2Logger", 
"org.jboss.logging.JBossLogManagerLogger", 
"org.jboss.logging.JDKLogger".
 
Some methods only exist in one class version:
 org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
 org.jboss.logging.Log4jLoggerProvider: void clearMdc()
 org.jboss.logging.MDC: void clear()
 ..

Please notice this problem, it brings high risks of classpath issues during the 
evolution process, which may throw the nosuchmehtodException at runtime.
 
The conflicting features' details are shown in the attachment.

  was:
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes as 
follows:

" org.jboss.logging.LogMessage 
 org.jboss.logging.Log4j2LoggerProvider 
 org.jboss.logging.MessageLogger 
 org.jboss.logging.DelegatingBasicLogger 
 org.jboss.logging.Slf4jLocationAwareLogger$1 
 org.jboss.logging.Logger 
 org.jboss.logging.Log4jLoggerProvider 
 org.jboss.logging.MDC 
 org.jboss.logging.JBossLogManagerProvider 
 org.jboss.logging.NDC 
 org.jboss.logging.LoggingClass 
 org.jboss.logging.LoggerProvider 
 org.jboss.logging.AbstractLoggerProvider$Entry 
org.jboss.logging.Slf4jLoggerProvider 
 org.jboss.logging.Message$Format 
 org.jboss.logging.JBossLogRecord
 org.jboss.logging.Messages 
 org.jboss.logging.Logger$1
 org.jboss.logging.LoggerProviders$1 
 org.jboss.logging.SerializedLogger 
 org.jboss.logging.Param 
 org.jboss.logging.Messages$1 
 org.jboss.logging.Log4jLogger 
 org.jboss.logging.JBossLogManagerProvider$1 
 org.jboss.logging.Log4j2Logger
 org.jboss.logging.LoggerProviders
 org.jboss.logging.BasicLogger
 org.jboss.logging.MessageBundle 
 org.jboss.logging.FormatWith 
 org.jboss.logging.Field 
 org.jboss.logging.Message 
 org.jboss.logging.Logger$Level 
 org.jboss.logging.ParameterConverter 
 org.jboss.logging.AbstractLoggerProvider 
 org.jboss.logging.Slf4jLogger 
 org.jboss.logging.JDKLogger 
 org.jboss.logging.Slf4jLocationAwareLogger e
 org.jboss.logging.Cause 
 org.jboss.logging.AbstractMdcLoggerProvider
 org.jboss.logging.JDKLevel
 org.jboss.logging.Property 
 org.jboss.logging.JBossLogManagerLogger 
 org.jboss.logging.JDKLoggerProvider"

Of them, two versions of classes "org.jboss.logging.Log4j2LoggerProvider", 
"org.jboss.logging.MDC", "org.jboss.logging.JBossLogManagerProvider", 
"org.jboss.logging.Slf4jLoggerProvider", "org.jboss.logging.Log4j2Logger", 
"org.jboss.logging.JBossLogManagerLogger", "org.jboss.logging.JDKLogger" in 
these two libraries, have different features. The conflicting features' details 
are shown in the attachment. Please notice this problem, it brings high risks 
of classpath issues during the evolution.


> Dependency Conflict : Conflicting classes existing in two libraries
> ---
>
> Key: ARTEMIS-1674
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1674
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: [^Conflicting libs.TXT]
>Reporter: PandaMonkey
>Priority: Major
>  Labels: features
> Fix For: 2.5.0
>
> Attachments: Conflicting libs.TXT
>
>
> Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT 
> "artemis-cdi-client\pom.xml" and its bytecodes, we found libraries 
> "org.jboss.weld.se:weld-se:2.4.0.Final" and 
> "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes.
> The following duplicate class pairs having the same names but their internal 
> implementations are different:
> "org.jboss.logging.Log4j2LoggerProvider", 
> "org.jboss.logging.MDC", 
> "org.jboss.logging.JBossLogManagerProvider",
> "org.jboss.logging.Slf4jLoggerProvider", 
> "org.jboss.logging.Log4j2Logger", 
> "org.jboss.logging.JBossLogManagerLogger", 
> "org.jboss.logging.JDKLogger".
>  
> Some methods only exist in one class version:
>  org.jboss.logging.Log4j2LoggerProvider: void clearMdc()
>  org.jboss.logging.Log4jLoggerProvider: void clearMdc()
>  org.jboss.logging.MDC: void clear()
>  ..
> Please notice this problem, it brings high risks of clas

[jira] [Updated] (ARTEMIS-1674) Dependency Conflict : Conflicting classes existing in two libraries

2018-02-09 Thread PandaMonkey (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

PandaMonkey updated ARTEMIS-1674:
-
Description: 
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes as 
follows:

" org.jboss.logging.LogMessage 
 org.jboss.logging.Log4j2LoggerProvider 
 org.jboss.logging.MessageLogger 
 org.jboss.logging.DelegatingBasicLogger 
 org.jboss.logging.Slf4jLocationAwareLogger$1 
 org.jboss.logging.Logger 
 org.jboss.logging.Log4jLoggerProvider 
 org.jboss.logging.MDC 
 org.jboss.logging.JBossLogManagerProvider 
 org.jboss.logging.NDC 
 org.jboss.logging.LoggingClass 
 org.jboss.logging.LoggerProvider 
 org.jboss.logging.AbstractLoggerProvider$Entry 
org.jboss.logging.Slf4jLoggerProvider 
 org.jboss.logging.Message$Format 
 org.jboss.logging.JBossLogRecord
 org.jboss.logging.Messages 
 org.jboss.logging.Logger$1
 org.jboss.logging.LoggerProviders$1 
 org.jboss.logging.SerializedLogger 
 org.jboss.logging.Param 
 org.jboss.logging.Messages$1 
 org.jboss.logging.Log4jLogger 
 org.jboss.logging.JBossLogManagerProvider$1 
 org.jboss.logging.Log4j2Logger
 org.jboss.logging.LoggerProviders
 org.jboss.logging.BasicLogger
 org.jboss.logging.MessageBundle 
 org.jboss.logging.FormatWith 
 org.jboss.logging.Field 
 org.jboss.logging.Message 
 org.jboss.logging.Logger$Level 
 org.jboss.logging.ParameterConverter 
 org.jboss.logging.AbstractLoggerProvider 
 org.jboss.logging.Slf4jLogger 
 org.jboss.logging.JDKLogger 
 org.jboss.logging.Slf4jLocationAwareLogger e
 org.jboss.logging.Cause 
 org.jboss.logging.AbstractMdcLoggerProvider
 org.jboss.logging.JDKLevel
 org.jboss.logging.Property 
 org.jboss.logging.JBossLogManagerLogger 
 org.jboss.logging.JDKLoggerProvider"

Of them, two versions of classes "org.jboss.logging.Log4j2LoggerProvider", 
"org.jboss.logging.MDC", "org.jboss.logging.JBossLogManagerProvider", 
"org.jboss.logging.Slf4jLoggerProvider", "org.jboss.logging.Log4j2Logger", 
"org.jboss.logging.JBossLogManagerLogger", "org.jboss.logging.JDKLogger" in 
these two libraries, have different features. The conflicting features' details 
are shown in the attachment. Please notice this problem, it brings high risks 
of classpath issues during the evolution.

  was:
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes as 
follows:

" org.jboss.logging.LogMessage 
 org.jboss.logging.Log4j2LoggerProvider 
 org.jboss.logging.MessageLogger 
 org.jboss.logging.DelegatingBasicLogger 
 org.jboss.logging.Slf4jLocationAwareLogger$1 
 org.jboss.logging.Logger 
 org.jboss.logging.Log4jLoggerProvider 
 org.jboss.logging.MDC 
 org.jboss.logging.JBossLogManagerProvider 
 org.jboss.logging.NDC 
 org.jboss.logging.LoggingClass 
 org.jboss.logging.LoggerProvider 
 org.jboss.logging.AbstractLoggerProvider$Entry 
org.jboss.logging.Slf4jLoggerProvider 
 org.jboss.logging.Message$Format 
 org.jboss.logging.JBossLogRecord
 org.jboss.logging.Messages 
 org.jboss.logging.Logger$1
 org.jboss.logging.LoggerProviders$1 
 org.jboss.logging.SerializedLogger 
 org.jboss.logging.Param 
 org.jboss.logging.Messages$1 
 org.jboss.logging.Log4jLogger 
 org.jboss.logging.JBossLogManagerProvider$1 
 org.jboss.logging.Log4j2Logger
 org.jboss.logging.LoggerProviders
 org.jboss.logging.BasicLogger
 org.jboss.logging.MessageBundle 
 org.jboss.logging.FormatWith 
 org.jboss.logging.Field 
 org.jboss.logging.Message 
 org.jboss.logging.Logger$Level 
 org.jboss.logging.ParameterConverter 
 org.jboss.logging.AbstractLoggerProvider 
 org.jboss.logging.Slf4jLogger 
 org.jboss.logging.JDKLogger 
 org.jboss.logging.Slf4jLocationAwareLogger e
 org.jboss.logging.Cause 
 org.jboss.logging.AbstractMdcLoggerProvider
 org.jboss.logging.JDKLevel
 org.jboss.logging.Property 
 org.jboss.logging.JBossLogManagerLogger 
 org.jboss.logging.JDKLoggerProvider"

Of them, two versions of classes "org.jboss.logging.Log4j2LoggerProvider", 
"org.jboss.logging.MDC", "org.jboss.logging.JBossLogManagerProvider", 
"org.jboss.logging.Slf4jLoggerProvider", "org.jboss.logging.Log4j2Logger", 
"org.jboss.logging.JBossLogManagerLogger", "org.jboss.logging.JDKLogger" in 
these two libraries, have different features. The conflicting feature's details 
are shown in the attachment. Please notice this problem, it brings high risks 
of classpath issues during the evolution.


> Dependency Conflict : Conflicting classes existing in two libraries
> ---
>
> Key: ARTEMIS-1674
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1674
> Project: Ac

[jira] [Updated] (ARTEMIS-1674) Dependency Conflict : Conflicting classes existing in two libraries

2018-02-09 Thread PandaMonkey (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

PandaMonkey updated ARTEMIS-1674:
-
Summary: Dependency Conflict : Conflicting classes existing in two 
libraries  (was: Dependency Conflict : Conclicting classes existing in two 
libraries)

> Dependency Conflict : Conflicting classes existing in two libraries
> ---
>
> Key: ARTEMIS-1674
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1674
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: [^Conflicting libs.TXT]
>Reporter: PandaMonkey
>Priority: Major
>  Labels: features
> Fix For: 2.5.0
>
> Attachments: Conflicting libs.TXT
>
>
> Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT 
> "artemis-cdi-client\pom.xml" and its bytecodes we found libraries 
> "org.jboss.weld.se:weld-se:2.4.0.Final" and 
> "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes as 
> follows:
> " org.jboss.logging.LogMessage 
>  org.jboss.logging.Log4j2LoggerProvider 
>  org.jboss.logging.MessageLogger 
>  org.jboss.logging.DelegatingBasicLogger 
>  org.jboss.logging.Slf4jLocationAwareLogger$1 
>  org.jboss.logging.Logger 
>  org.jboss.logging.Log4jLoggerProvider 
>  org.jboss.logging.MDC 
>  org.jboss.logging.JBossLogManagerProvider 
>  org.jboss.logging.NDC 
>  org.jboss.logging.LoggingClass 
>  org.jboss.logging.LoggerProvider 
>  org.jboss.logging.AbstractLoggerProvider$Entry 
> org.jboss.logging.Slf4jLoggerProvider 
>  org.jboss.logging.Message$Format 
>  org.jboss.logging.JBossLogRecord
>  org.jboss.logging.Messages 
>  org.jboss.logging.Logger$1
>  org.jboss.logging.LoggerProviders$1 
>  org.jboss.logging.SerializedLogger 
>  org.jboss.logging.Param 
>  org.jboss.logging.Messages$1 
>  org.jboss.logging.Log4jLogger 
>  org.jboss.logging.JBossLogManagerProvider$1 
>  org.jboss.logging.Log4j2Logger
>  org.jboss.logging.LoggerProviders
>  org.jboss.logging.BasicLogger
>  org.jboss.logging.MessageBundle 
>  org.jboss.logging.FormatWith 
>  org.jboss.logging.Field 
>  org.jboss.logging.Message 
>  org.jboss.logging.Logger$Level 
>  org.jboss.logging.ParameterConverter 
>  org.jboss.logging.AbstractLoggerProvider 
>  org.jboss.logging.Slf4jLogger 
>  org.jboss.logging.JDKLogger 
>  org.jboss.logging.Slf4jLocationAwareLogger e
>  org.jboss.logging.Cause 
>  org.jboss.logging.AbstractMdcLoggerProvider
>  org.jboss.logging.JDKLevel
>  org.jboss.logging.Property 
>  org.jboss.logging.JBossLogManagerLogger 
>  org.jboss.logging.JDKLoggerProvider"
> Of them, two versions of classes "org.jboss.logging.Log4j2LoggerProvider", 
> "org.jboss.logging.MDC", "org.jboss.logging.JBossLogManagerProvider", 
> "org.jboss.logging.Slf4jLoggerProvider", "org.jboss.logging.Log4j2Logger", 
> "org.jboss.logging.JBossLogManagerLogger", "org.jboss.logging.JDKLogger" in 
> these two libraries, have different features. The conflicting feature's 
> details are shown in the attachment. Please notice this problem, it brings 
> high risks of classpath issues during the evolution.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (ARTEMIS-1674) Dependency Conflict : Conclicting classes existing in two libraries

2018-02-09 Thread PandaMonkey (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

PandaMonkey updated ARTEMIS-1674:
-
Description: 
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and its bytecodes we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes as 
follows:

" org.jboss.logging.LogMessage 
 org.jboss.logging.Log4j2LoggerProvider 
 org.jboss.logging.MessageLogger 
 org.jboss.logging.DelegatingBasicLogger 
 org.jboss.logging.Slf4jLocationAwareLogger$1 
 org.jboss.logging.Logger 
 org.jboss.logging.Log4jLoggerProvider 
 org.jboss.logging.MDC 
 org.jboss.logging.JBossLogManagerProvider 
 org.jboss.logging.NDC 
 org.jboss.logging.LoggingClass 
 org.jboss.logging.LoggerProvider 
 org.jboss.logging.AbstractLoggerProvider$Entry 
org.jboss.logging.Slf4jLoggerProvider 
 org.jboss.logging.Message$Format 
 org.jboss.logging.JBossLogRecord
 org.jboss.logging.Messages 
 org.jboss.logging.Logger$1
 org.jboss.logging.LoggerProviders$1 
 org.jboss.logging.SerializedLogger 
 org.jboss.logging.Param 
 org.jboss.logging.Messages$1 
 org.jboss.logging.Log4jLogger 
 org.jboss.logging.JBossLogManagerProvider$1 
 org.jboss.logging.Log4j2Logger
 org.jboss.logging.LoggerProviders
 org.jboss.logging.BasicLogger
 org.jboss.logging.MessageBundle 
 org.jboss.logging.FormatWith 
 org.jboss.logging.Field 
 org.jboss.logging.Message 
 org.jboss.logging.Logger$Level 
 org.jboss.logging.ParameterConverter 
 org.jboss.logging.AbstractLoggerProvider 
 org.jboss.logging.Slf4jLogger 
 org.jboss.logging.JDKLogger 
 org.jboss.logging.Slf4jLocationAwareLogger e
 org.jboss.logging.Cause 
 org.jboss.logging.AbstractMdcLoggerProvider
 org.jboss.logging.JDKLevel
 org.jboss.logging.Property 
 org.jboss.logging.JBossLogManagerLogger 
 org.jboss.logging.JDKLoggerProvider"

Of them, two versions of classes "org.jboss.logging.Log4j2LoggerProvider", 
"org.jboss.logging.MDC", "org.jboss.logging.JBossLogManagerProvider", 
"org.jboss.logging.Slf4jLoggerProvider", "org.jboss.logging.Log4j2Logger", 
"org.jboss.logging.JBossLogManagerLogger", "org.jboss.logging.JDKLogger" in 
these two libraries, have different features. The conflicting feature's details 
are shown in the attachment. Please notice this problem, it brings high risks 
of classpath issues during the evolution.

  was:
Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and the bytecodes we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes as 
follows:

" org.jboss.logging.LogMessage 
org.jboss.logging.Log4j2LoggerProvider 
org.jboss.logging.MessageLogger 
org.jboss.logging.DelegatingBasicLogger 
org.jboss.logging.Slf4jLocationAwareLogger$1 
org.jboss.logging.Logger 
org.jboss.logging.Log4jLoggerProvider 
org.jboss.logging.MDC 
org.jboss.logging.JBossLogManagerProvider 
org.jboss.logging.NDC 
org.jboss.logging.LoggingClass 
org.jboss.logging.LoggerProvider 
org.jboss.logging.AbstractLoggerProvider$Entry 
org.jboss.logging.Slf4jLoggerProvider 
org.jboss.logging.Message$Format 
org.jboss.logging.JBossLogRecord
org.jboss.logging.Messages 
org.jboss.logging.Logger$1
org.jboss.logging.LoggerProviders$1 
org.jboss.logging.SerializedLogger 
org.jboss.logging.Param 
org.jboss.logging.Messages$1 
org.jboss.logging.Log4jLogger 
org.jboss.logging.JBossLogManagerProvider$1 
org.jboss.logging.Log4j2Logger
org.jboss.logging.LoggerProviders
org.jboss.logging.BasicLogger
org.jboss.logging.MessageBundle 
org.jboss.logging.FormatWith 
org.jboss.logging.Field 
org.jboss.logging.Message 
org.jboss.logging.Logger$Level 
org.jboss.logging.ParameterConverter 
org.jboss.logging.AbstractLoggerProvider 
org.jboss.logging.Slf4jLogger 
org.jboss.logging.JDKLogger 
org.jboss.logging.Slf4jLocationAwareLogger e
org.jboss.logging.Cause 
org.jboss.logging.AbstractMdcLoggerProvider
org.jboss.logging.JDKLevel
org.jboss.logging.Property 
org.jboss.logging.JBossLogManagerLogger 
org.jboss.logging.JDKLoggerProvider"

Of them, two versions of classes "org.jboss.logging.Log4j2LoggerProvider", 
"org.jboss.logging.MDC", "org.jboss.logging.JBossLogManagerProvider", 
"org.jboss.logging.Slf4jLoggerProvider", "org.jboss.logging.Log4j2Logger", 
"org.jboss.logging.JBossLogManagerLogger", "org.jboss.logging.JDKLogger" in 
these two libraries, have different features. The conflicting feature's details 
are shown in the attachment. Please notice this problem, it brings high risks 
of classpath issues during the evolution.


> Dependency Conflict : Conclicting classes existing in two libraries
> ---
>
> Key: ARTEMIS-1674
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1674
> Project: ActiveMQ Artemis
>  Issue Type: Bug

[jira] [Created] (ARTEMIS-1674) Dependency Conflict : Conclicting classes existing in two libraries

2018-02-09 Thread PandaMonkey (JIRA)
PandaMonkey created ARTEMIS-1674:


 Summary: Dependency Conflict : Conclicting classes existing in two 
libraries
 Key: ARTEMIS-1674
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1674
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 2.4.0
 Environment: [^Conflicting libs.TXT]
Reporter: PandaMonkey
 Fix For: 2.5.0
 Attachments: Conflicting libs.TXT

Hi, by analyzing artemis-cdi-client:2.5.0-SNAPSHOT "artemis-cdi-client\pom.xml" 
and the bytecodes we found libraries "org.jboss.weld.se:weld-se:2.4.0.Final" 
and "org.jboss.logging:jboss-logging:3.3.1.Final" contains duplicate classes as 
follows:

" org.jboss.logging.LogMessage 
org.jboss.logging.Log4j2LoggerProvider 
org.jboss.logging.MessageLogger 
org.jboss.logging.DelegatingBasicLogger 
org.jboss.logging.Slf4jLocationAwareLogger$1 
org.jboss.logging.Logger 
org.jboss.logging.Log4jLoggerProvider 
org.jboss.logging.MDC 
org.jboss.logging.JBossLogManagerProvider 
org.jboss.logging.NDC 
org.jboss.logging.LoggingClass 
org.jboss.logging.LoggerProvider 
org.jboss.logging.AbstractLoggerProvider$Entry 
org.jboss.logging.Slf4jLoggerProvider 
org.jboss.logging.Message$Format 
org.jboss.logging.JBossLogRecord
org.jboss.logging.Messages 
org.jboss.logging.Logger$1
org.jboss.logging.LoggerProviders$1 
org.jboss.logging.SerializedLogger 
org.jboss.logging.Param 
org.jboss.logging.Messages$1 
org.jboss.logging.Log4jLogger 
org.jboss.logging.JBossLogManagerProvider$1 
org.jboss.logging.Log4j2Logger
org.jboss.logging.LoggerProviders
org.jboss.logging.BasicLogger
org.jboss.logging.MessageBundle 
org.jboss.logging.FormatWith 
org.jboss.logging.Field 
org.jboss.logging.Message 
org.jboss.logging.Logger$Level 
org.jboss.logging.ParameterConverter 
org.jboss.logging.AbstractLoggerProvider 
org.jboss.logging.Slf4jLogger 
org.jboss.logging.JDKLogger 
org.jboss.logging.Slf4jLocationAwareLogger e
org.jboss.logging.Cause 
org.jboss.logging.AbstractMdcLoggerProvider
org.jboss.logging.JDKLevel
org.jboss.logging.Property 
org.jboss.logging.JBossLogManagerLogger 
org.jboss.logging.JDKLoggerProvider"

Of them, two versions of classes "org.jboss.logging.Log4j2LoggerProvider", 
"org.jboss.logging.MDC", "org.jboss.logging.JBossLogManagerProvider", 
"org.jboss.logging.Slf4jLoggerProvider", "org.jboss.logging.Log4j2Logger", 
"org.jboss.logging.JBossLogManagerLogger", "org.jboss.logging.JDKLogger" in 
these two libraries, have different features. The conflicting feature's details 
are shown in the attachment. Please notice this problem, it brings high risks 
of classpath issues during the evolution.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (ARTEMIS-1400) FindBugs warnings

2018-02-09 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358142#comment-16358142
 ] 

ASF GitHub Bot commented on ARTEMIS-1400:
-

Github user jdanekrh commented on the pull request:


https://github.com/apache/activemq-artemis/commit/dc41f3ca491e96e199290a225fdaa07ac05d66df#commitcomment-27446263
  
Issues created and linked onto 
https://issues.apache.org/jira/browse/ARTEMIS-1400.


> FindBugs warnings
> -
>
> Key: ARTEMIS-1400
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1400
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Jiri Daněk
>Priority: Minor
> Fix For: 2.4.0
>
> Attachments: 
> findbugs-3.0.1_apache-artemis-2.4.0-20170906.150547-13-bin.html
>
>
> Inspired by PROTON-1572, I am raising similar Jira for FindBugs issues in 
> Artemis. The best way to get at an up-to-date list is probably either just 
> run FindBugs (there are IDE plugins for ease of use) or look into Coverity 
> Scan results. As far as I know, anybody who requests access to Artemis 
> Coverity issues will promptly get it.
> I noticed these two issues there, which prompted me to raise this Jira, but 
> there is more. Probably not serious, the dead code certainly, the other one 
> probably, but something that should be eventually fixed.
> NetworkHealthCheck.java
> https://scan7.coverity.com/reports.htm#v10043/p14213/fileInstanceId=33820734&defectInstanceId=7426786&mergedDefectId=1455416
> {noformat}
> 375   private void readStream(InputStream stream, boolean error) throws 
> IOException {
>   CID 1418794: Dm: Dubious method used (FB.DM_DEFAULT_ENCODING) [select 
> issue]
> 376  BufferedReader reader = new BufferedReader(new 
> InputStreamReader(stream));
> 377
> 378  String inputLine;
>   cond_notnull: Condition (inputLine = reader.readLine()) != null, taking 
> true branch. Now the value of inputLine is not null.
> 379  while ((inputLine = reader.readLine()) != null) {
> 380 if (error) {
>   notnull: At condition inputLine == null, the value of inputLine cannot 
> be null.
>   dead_error_condition: The condition inputLine == null cannot be true.
>   
> CID 1455416: Logically dead code (DEADCODE)
> dead_error_line: Execution cannot reach the expression " " inside this 
> statement: org.apache.activemq.artemis
> 381ActiveMQUtilLogger.LOGGER.failedToReadFromStream(inputLine == 
> null ? " " : inputLine);
> 382 } else {
> 383logger.trace(inputLine);
> 384 }
> 385  }
> 386
> 387  reader.close();
> 388   }
> {noformat}
> ActiveMQFilterPredicate.java
> https://scan7.coverity.com/reports.htm#v10043/p14213/fileInstanceId=33820887&defectInstanceId=7427212&mergedDefectId=1455392
> {noformat}
> 100   private boolean contains(Object field, Object value) {
> 101  if (field == null) {
>   deref: Directly dereferencing value.
>   
> CID 1455401: Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking value suggests that it may be null, but it 
> has already been dereferenced on all paths leading to the check.
> 102 return (value.equals("") || value == null);
> 103  }
> 104  return field.toString().contains(value.toString());
> 105   }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (ARTEMIS-1673) Coverity: Null pointer dereferences (NULL_RETURNS) in PageSubscriptionImpl.java

2018-02-09 Thread JIRA
Jiri Daněk created ARTEMIS-1673:
---

 Summary: Coverity: Null pointer dereferences  (NULL_RETURNS) in 
PageSubscriptionImpl.java
 Key: ARTEMIS-1673
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1673
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 2.5.0
Reporter: Jiri Daněk


{noformat}

*** CID 1465012:  Null pointer dereferences  (NULL_RETURNS)
/activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/cursor/impl/PageSubscriptionImpl.java:
 366 in 
org.apache.activemq.artemis.core.paging.cursor.impl.PageSubscriptionImpl.getReference(org.apache.activemq.artemis.core.paging.cursor.PagePosition)()
360@Override
361public String toString() {
362   return "PageSubscriptionImpl [cursorId=" + cursorId + ", queue=" 
+ queue + ", filter = " + filter + "]";
363}
364
365private PagedReference getReference(PagePosition pos) {
>>> CID 1465012:  Null pointer dereferences  (NULL_RETURNS)
>>> Dereferencing a pointer that might be null 
>>> "cursorProvider.getMessage(pos)" when calling "newReference". (The virtual 
>>> call resolves to 
>>> "org.apache.activemq.artemis.core.paging.cursor.impl.PageCursorProviderImpl.newReference".)
366   return cursorProvider.newReference(pos, 
cursorProvider.getMessage(pos), this);
367}
368
369@Override
370public PageIterator iterator() {
371   return new CursorIterator();
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (ARTEMIS-1672) Coverity: Null pointer dereferences (REVERSE_INULL) in ActiveMQServerImpl.java

2018-02-09 Thread JIRA
Jiri Daněk created ARTEMIS-1672:
---

 Summary: Coverity: Null pointer dereferences  (REVERSE_INULL) in 
ActiveMQServerImpl.java
 Key: ARTEMIS-1672
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1672
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 2.5.0
Reporter: Jiri Daněk


{noformat}

*** CID 1465014:  Null pointer dereferences  (REVERSE_INULL)
/activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java:
 2795 in 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(org.apache.activemq.artemis.core.server.impl.AddressInfo,
 org.apache.activemq.artemis.api.core.SimpleString, 
org.apache.activemq.artemis.api.core.SimpleString, 
org.apache.activemq.artemis.api.core.SimpleString, boolean, boolean, boolean, 
boolean, boolean, int, boolean, boolean, boolean, boolean)()
2789  } catch (Throwable ignored) {
2790 logger.debug(ignored.getMessage(), ignored);
2791  }
2792  throw e;
2793   }
2794
>>> CID 1465014:  Null pointer dereferences  (REVERSE_INULL)
>>> Null-checking "addrInfo" suggests that it may be null, but it has 
>>> already been dereferenced on all paths leading to the check.
2795   if (addrInfo == null || !addrInfo.isInternal()) {
2796  managementService.registerQueue(queue, queue.getAddress(), 
storageManager);
2797   }
2798
2799   callBrokerPlugins(hasBrokerPlugins() ? plugin -> 
plugin.afterCreateQueue(queue) : null);
2800
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (ARTEMIS-1671) FindBugs: Null pointer dereferences (FORWARD_NULL) in AbstractJournalStorageManager.java

2018-02-09 Thread JIRA
Jiri Daněk created ARTEMIS-1671:
---

 Summary: FindBugs: Null pointer dereferences  (FORWARD_NULL) in 
AbstractJournalStorageManager.java
 Key: ARTEMIS-1671
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1671
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 2.5.0
Reporter: Jiri Daněk


{noformat}

*** CID 1465016:  Null pointer dereferences  (FORWARD_NULL)
/activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/AbstractJournalStorageManager.java:
 1775 in 
org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadPreparedTransactions(org.apache.activemq.artemis.core.postoffice.PostOffice,
 org.apache.activemq.artemis.core.paging.PagingManager, 
org.apache.activemq.artemis.core.transaction.ResourceManager, java.util.Map, 
java.util.List, java.util.Map, java.util.Map, java.util.Set, 
org.apache.activemq.artemis.core.server.impl.JournalLoader)()
1769   encoding.position.setRecordID(record.id);
1770
1771   PageSubscription sub = 
locateSubscription(encoding.queueID, pageSubscriptions, queueInfos, 
pagingManager);
1772
1773   if (sub != null) {
1774  sub.reloadPreparedACK(tx, encoding.position);
>>> CID 1465016:  Null pointer dereferences  (FORWARD_NULL)
>>> Passing "null" to "PagedReferenceImpl", which dereferences it.
1775  referencesToAck.add(new 
PagedReferenceImpl(encoding.position, null, sub));
1776   } else {
1777  
ActiveMQServerLogger.LOGGER.journalCannotFindQueueReloadingACK(encoding.queueID);
1778   }
1779   break;
1780}
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)