June 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-207) Add start/stop operations to hornetq-server resource

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-207?page=com.atlassian.jira.plugin.s... ] Jeff Mesnil commented on WFLY-207: ---------------------------------- HornetQServerControl does not expose start/stop methods > Add start/stop operations to hornetq-server resource > ---------------------------------------------------- > > Key: WFLY-207 > URL: https://issues.jboss.org/browse/WFLY-207 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.CR1 > > > Currently it is not possible to start/stop a hornetq-server resource without removing or adding it. > For HornetQ replicated nodes, it'd be useful to be able to start/stop the node (runtime operations) without changing its configuration. That'd be necessary to restart replicated backup servers that have fallen back -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-207) Add start/stop operations to hornetq-server resource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-207?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated WFLY-207: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1099730 > Add start/stop operations to hornetq-server resource > ---------------------------------------------------- > > Key: WFLY-207 > URL: https://issues.jboss.org/browse/WFLY-207 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.CR1 > > > Currently it is not possible to start/stop a hornetq-server resource without removing or adding it. > For HornetQ replicated nodes, it'd be useful to be able to start/stop the node (runtime operations) without changing its configuration. That'd be necessary to restart replicated backup servers that have fallen back -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3426) Add MBean server support to Management console

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3426?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3426: ------------------------------ Affects Version/s: (was: 8.2.0.CR1) > Add MBean server support to Management console > ---------------------------------------------- > > Key: WFLY-3426 > URL: https://issues.jboss.org/browse/WFLY-3426 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Sebastian Łaskawiec > Assignee: Jason Greene > Priority: Minor > > In JBoss 5.x server there was a web based tool for managing JMX Beans. Currently this functionality is supported via bundled JConsole. It would be convenient to have such functionality based on HTTP Web Management panel. > As discussed on email thread (subject: "JMX Console over Web Admin Console") it should be placed a part of standard management resource tree or in context of HTTP management interface. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3426) Add MBean server support to Management console

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created WFLY-3426: ----------------------------------------- Summary: Add MBean server support to Management console Key: WFLY-3426 URL: https://issues.jboss.org/browse/WFLY-3426 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 8.2.0.CR1 Reporter: Sebastian Łaskawiec Assignee: Jason Greene Priority: Minor In JBoss 5.x server there was a web based tool for managing JMX Beans. Currently this functionality is supported via bundled JConsole. It would be convenient to have such functionality based on HTTP Web Management panel. As discussed on email thread (subject: "JMX Console over Web Admin Console") it should be placed a part of standard management resource tree or in context of HTTP management interface. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1197) Port the legacy jmx-console to AS7

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/WFLY-1197?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on WFLY-1197: ------------------------------------------- Rebased Darren's code and detached from parent: https://github.com/altanis/wildfly/commits/jmx-console-ported > Port the legacy jmx-console to AS7 > ---------------------------------- > > Key: WFLY-1197 > URL: https://issues.jboss.org/browse/WFLY-1197 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMX > Reporter: Dimitris Andreadis > Assignee: Darran Lofthouse > Labels: JMX, as7, jmx-console, management_security,, management_sso > Attachments: jmx-console.war, jmx-console.war > > > I've seen a few people asking for a port of the old jmx-console to AS7, for monitoring purposes, until equivalent functionality is available through the new GWT-based console. > I've ported the old console in this branch: > https://github.com/dandreadis/jboss-as/commits/jmx-console > It only includes a new top-level directory 'jmx-console'. The directory is not build by default, and when you build it manually it does not alter the server configuration in any way, you need to manually copy the resulting target/jboss-as-jmx-console-VERSION.war to the server deployment directory (and rename it to jmx-console.war) > If there is interest, it could be included in the AS7 distro in some top level 'legacy' directory so it is not deployed by default? > The resulting .war is attached on this JIRA, in case someone wants to use it. It work just as well on AS 7.0.2 and the latest AS 7.1.x development branch. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-510) Traiting a non-natively traitable bean breaks the assert behavior

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-510?page=com.atlassian.jira.plugin... ] Davide Sottara updated DROOLS-510: ---------------------------------- Git Pull Request: https://github.com/droolsjbpm/drools/pull/340 > Traiting a non-natively traitable bean breaks the assert behavior > ----------------------------------------------------------------- > > Key: DROOLS-510 > URL: https://issues.jboss.org/browse/DROOLS-510 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.6.0.Final, 6.1.0.Beta4 > Reporter: Davide Sottara > Assignee: Davide Sottara > > Only beans implementing the TraitableBean interface can be used with "don" and "shed". If a non-traitable object is processed, the engine creates a proxy to add the required behavior. In versions up to 6.1.B4, this proxy appears EQUAL but not the SAME as the original fact. This will break the lookup of the handle if the user keeps a reference to the original object and tries to use it (e.g. to re-insert or delete the object) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-510) Traiting a non-natively traitable bean breaks the assert behavior

by Davide Sottara (JIRA)

Davide Sottara created DROOLS-510: ------------------------------------- Summary: Traiting a non-natively traitable bean breaks the assert behavior Key: DROOLS-510 URL: https://issues.jboss.org/browse/DROOLS-510 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.1.0.Beta4, 5.6.0.Final Reporter: Davide Sottara Assignee: Davide Sottara Only beans implementing the TraitableBean interface can be used with "don" and "shed". If a non-traitable object is processed, the engine creates a proxy to add the required behavior. In versions up to 6.1.B4, this proxy appears EQUAL but not the SAME as the original fact. This will break the lookup of the handle if the user keeps a reference to the original object and tries to use it (e.g. to re-insert or delete the object) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3197) ExternalContextFactory cuts context from deployment context/requires dependency on module

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3197?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3197: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.1.0.Final) > ExternalContextFactory cuts context from deployment context/requires dependency on module > ----------------------------------------------------------------------------------------- > > Key: WFLY-3197 > URL: https://issues.jboss.org/browse/WFLY-3197 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.Final, 8.1.0.CR1 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 8.2.0.CR1 > > > WFLY-2777 changed CCL for context creation(if module is set in external context factory). This essentially cuts context from deployment classes during creation time. This can cause problems when external-context-factory.module classes (ObjectFactories, etc) require deployment classes to be visible from classloader which created context( external-context.module ) and are not found. > Steps to reproduce: > 1. define isolated module IM ( with classloader IM_CL ) > 2. create external-context-factory with module set to IM > 3. create some deployment with interface, for which proxies should be looked up via external-context ( with classloader D_CL ) - deployment has no dependency on IM, since it may contain legacy classes or unwanted dependencies > 4. lookup and invoke proxy > Now what will happen is during deployment external-context will be spawned just fine. However, the runtime outcome wont be pleasing. > Case 1: application and custom context dont do CCL magic > - invocation happen in deployment CCL, hence IM_CL classes are not visible and no classes required for deserialization can be loaded, this will fail ( return javax.naming.Reference instance, since ObjectFactory from IM_CL cant be found ) > Case 2: application or custom context switch CCL to IM_CL for lookup > - CCL is set to IM_CL, ObjectFactory can be found, but D_CL classes cant, hence some naming error probably > Neither of above will work, unless IM_CL and D_CL have some sort of dependency on each other, which just makes module CL configured in external-context-factory irrelevant, since D_CL will require dependency on IM_CL. > Workaround: > yes, store IM_CL in context wrapper and upon first invocation obtain CCL( hopefuly D_CL), create agregating CL and set it as CCL for each context invocation. > Possible fix: > 1. pass D_CL and IM_CL as part of env to factory, to allow context/context-wrapper to do some magic > 2. alter ExternalContextFactory and create agregating/delegating CL, which will just iterate over IM_CL and D_CL if present to load proper classes -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3256) IronJacamar 1.1.6.Final

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3256?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3256: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.1.0.Final) > IronJacamar 1.1.6.Final > ----------------------- > > Key: WFLY-3256 > URL: https://issues.jboss.org/browse/WFLY-3256 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Final, 8.1.0.CR1, 8.1.0.CR2 > Reporter: Tomaz Cerar > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 8.2.0.CR1 > > > When idle-timeout is configured idle remover thread can consume 100% of cpu. > See forum thread for more details. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3292) EE Resource Definition Code Rework

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3292?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3292: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.1.0.Final) > EE Resource Definition Code Rework > ---------------------------------- > > Key: WFLY-3292 > URL: https://issues.jboss.org/browse/WFLY-3292 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: EE, JCA, JMS, Mail, Naming > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Blocker > Fix For: 8.2.0.CR1 > > > This enhancement task provides a refresh/cleanup of all code related with EE resource definitions (as defined by EE.5.18). > A major goal is to sync the logic that works out the deployment of all resource definitions (datasource, connection factory, administered objects, mail session, jms destination and jms connection factory), introducing specific abstract processors for both descriptors and annotations. These processors should continue to use the same functionality under the hood, i.e. feed BindingConfigurations to the same collections as any resource, but may allow in the future an easy split of deployment phase to install the related bindings, which should help the logic of dependent services. > Another goal is to fix or provide missing functionality, such as support for <connection-factory /> and <administired-object />. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2014