December 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2451) Allow basic WS subsystem updates without requiring reload

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-2451?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on WFLY-2451: --------------------------------------- Work completed and on hold at https://github.com/asoldano/wildfly/commits/update-attributes . Waiting for next WFLY version development to be started. > Allow basic WS subsystem updates without requiring reload > --------------------------------------------------------- > > Key: WFLY-2451 > URL: https://issues.jboss.org/browse/WFLY-2451 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web Services > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 9.0.0.CR1 > > > Currently any change to the WS subsystem model requires reload for being applied to the runtime. > It should be possible to actually perform some runtime updates without reload in some situations, basically when there's no WS deployment active yet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2451) Allow basic WS subsystem updates without requiring reload

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-2451?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-2451: ---------------------------------- Fix Version/s: 9.0.0.CR1 > Allow basic WS subsystem updates without requiring reload > --------------------------------------------------------- > > Key: WFLY-2451 > URL: https://issues.jboss.org/browse/WFLY-2451 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web Services > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 9.0.0.CR1 > > > Currently any change to the WS subsystem model requires reload for being applied to the runtime. > It should be possible to actually perform some runtime updates without reload in some situations, basically when there's no WS deployment active yet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2608) MDB not receiving messages from JMS queue.

by Corey Puffalt (JIRA)

Corey Puffalt created WFLY-2608: ----------------------------------- Summary: MDB not receiving messages from JMS queue. Key: WFLY-2608 URL: https://issues.jboss.org/browse/WFLY-2608 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS Affects Versions: 8.0.0.Beta1 Reporter: Corey Puffalt Assignee: Jeff Mesnil Priority: Blocker We've run into a situation where MDBs stopped receiving messages from a JMS queue although the JMS queue itself was continuing to receive new messages from an EJB. The forum thread referenced below has more background information but basically at some point we see the following in our server logs: {code} 00:50:28,915 WARN [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (hornetq-failure-check-thread) Connection failure has been detected: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=3] 00:50:29,208 WARN [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Client connection failed, clearing up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653 00:50:29,235 WARN [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Cleared up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653 [the above two messages are repeated a number of times in rapid succession...and then finally we get...] 00:50:30,187 WARN [org.hornetq.jms.server.recovery.RecoveryDiscovery] (Thread-18647 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa discovery, we will retry on the next recovery: HornetQException[errorCode=2 message=Channel disconnected] at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07] 00:50:29,240 WARN [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Thread-18651 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa recovery connectionFactory for provider ClientSessionFactoryImpl [serverLocator=ServerLocatorImpl [initialConnectors=[org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryGroupConfiguration=null], connectorConfig=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0, backupConfig=null] will attempt reconnect on next pass: HornetQException[errorCode=2 message=Channel disconnected] at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07] 00:50:38,633 INFO [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) Starting RecoveryDiscovery on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null] 00:50:38,636 INFO [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) RecoveryDiscovery started fine on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null] {code} After this our MDB never receives any further messages until a server restart. HornetQ should be recovering from this situation (whatever the cause). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2595) Logging DUP leaking class loaders

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2595?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2595: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1038305 > Logging DUP leaking class loaders > --------------------------------- > > Key: WFLY-2595 > URL: https://issues.jboss.org/browse/WFLY-2595 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Fix For: 8.0.0.CR1 > > > When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL. > The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1123) ManagedConnectionPoolStatistics not correctly enabled at init

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-1123: -------------------------------------- Summary: ManagedConnectionPoolStatistics not correctly enabled at init Key: JBJCA-1123 URL: https://issues.jboss.org/browse/JBJCA-1123 Project: IronJacamar Issue Type: Bug Components: Core Affects Versions: 1.1.2.Final, 1.0.23.Final Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.24.Final, 1.1.3.Final ManagedConnectionPoolStatistics needs to be initialized with PoolStatistics' enabled status -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1118) Add a system property to disable enlistment traces

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1118?page=com.atlassian.jira.plugin... ] Jesper Pedersen updated JBJCA-1118: ----------------------------------- Fix Version/s: 1.0.24.Final > Add a system property to disable enlistment traces > -------------------------------------------------- > > Key: JBJCA-1118 > URL: https://issues.jboss.org/browse/JBJCA-1118 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.24.Final, 1.1.2.Final > > > Add a system property 'ironjacamar.disable_enlistment_trace' to disable the enlistment trace. > Default is false, which means record. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1118) Add a system property to disable enlistment traces

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1118?page=com.atlassian.jira.plugin... ] Jesper Pedersen closed JBJCA-1118. ---------------------------------- Resolution: Done > Add a system property to disable enlistment traces > -------------------------------------------------- > > Key: JBJCA-1118 > URL: https://issues.jboss.org/browse/JBJCA-1118 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.24.Final, 1.1.2.Final > > > Add a system property 'ironjacamar.disable_enlistment_trace' to disable the enlistment trace. > Default is false, which means record. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1118) Add a system property to disable enlistment traces

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1118?page=com.atlassian.jira.plugin... ] Jesper Pedersen reopened JBJCA-1118: ------------------------------------ > Add a system property to disable enlistment traces > -------------------------------------------------- > > Key: JBJCA-1118 > URL: https://issues.jboss.org/browse/JBJCA-1118 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.1.2.Final > > > Add a system property 'ironjacamar.disable_enlistment_trace' to disable the enlistment trace. > Default is false, which means record. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-81) Log Tool generates class names that violate FindBugs standard rules

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-81?page=com.atlassian.jira.plugin... ] Tom Cunningham updated LOGTOOL-81: ---------------------------------- Description: Log Tool generates class names like : ./api/target/generated-sources/annotations/org/switchyard/APILogger_$logger.java ./validate/target/generated-sources/annotations/org/switchyard/validate/ValidateMessages_$bundle.java When I run findbugs, my project isn't clean anymore because of these generated classes - findbugs complains that these classes do not start with a capital letter. It looks like this violates the NM_CLASS_NAMING_CONVENTION rule. >From Findbugs website : Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML). http://findbugs.sourceforge.net/bugDescriptions.html I can probably work around this by providing FindBugs exceptions for "_$logger" and "_$bundle", but it might be good practice if the first letter were upper cased in the generated class (i.e. "_$Logger" and "_$Bundle" . was: Log Tool generates class names like : ./api/target/generated-sources/annotations/org/switchyard/APILogger_$logger.java ./validate/target/generated-sources/annotations/org/switchyard/validate/ValidateMessages_$bundle.java When I run findbugs, my project isn't clean anymore because of these generated classes - findbugs complains that these classes do not start with a capital letter. It looks like this violates the NM_CLASS_NAMING_CONVENTION rule. >From Findbugs website : Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML). http://findbugs.sourceforge.net/bugDescriptions.html I can probably work around this by providing FindBugs exceptions for "_$logger" and "_$bundle", but it might be good practice if the first letter were upper cased in the generated class. > Log Tool generates class names that violate FindBugs standard rules > ------------------------------------------------------------------- > > Key: LOGTOOL-81 > URL: https://issues.jboss.org/browse/LOGTOOL-81 > Project: Log Tool > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: OS X Mavericks, Java 1.7 > Reporter: Tom Cunningham > Assignee: James Perkins > > Log Tool generates class names like : > ./api/target/generated-sources/annotations/org/switchyard/APILogger_$logger.java > ./validate/target/generated-sources/annotations/org/switchyard/validate/ValidateMessages_$bundle.java > When I run findbugs, my project isn't clean anymore because of these generated classes - findbugs complains that these classes do not start with a capital letter. It looks like this violates the NM_CLASS_NAMING_CONVENTION rule. > From Findbugs website : > Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML). > http://findbugs.sourceforge.net/bugDescriptions.html > I can probably work around this by providing FindBugs exceptions for "_$logger" and "_$bundle", but it might be good practice if the first letter were upper cased in the generated class (i.e. "_$Logger" and "_$Bundle" . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-81) Log Tool generates class names that violate FindBugs standard rules

by Tom Cunningham (JIRA)

Tom Cunningham created LOGTOOL-81: ------------------------------------- Summary: Log Tool generates class names that violate FindBugs standard rules Key: LOGTOOL-81 URL: https://issues.jboss.org/browse/LOGTOOL-81 Project: Log Tool Issue Type: Bug Security Level: Public (Everyone can see) Environment: OS X Mavericks, Java 1.7 Reporter: Tom Cunningham Assignee: James Perkins Log Tool generates class names like : ./api/target/generated-sources/annotations/org/switchyard/APILogger_$logger.java ./validate/target/generated-sources/annotations/org/switchyard/validate/ValidateMessages_$bundle.java When I run findbugs, my project isn't clean anymore because of these generated classes - findbugs complains that these classes do not start with a capital letter. It looks like this violates the NM_CLASS_NAMING_CONVENTION rule. >From Findbugs website : Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML). http://findbugs.sourceforge.net/bugDescriptions.html I can probably work around this by providing FindBugs exceptions for "_$logger" and "_$bundle", but it might be good practice if the first letter were upper cased in the generated class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2013