August 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7027) MBeans with ObjectName attributes throw ClassNotFoundException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7027?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-7027: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1372096 Bugzilla Update: Perform > MBeans with ObjectName attributes throw ClassNotFoundException > -------------------------------------------------------------- > > Key: WFLY-7027 > URL: https://issues.jboss.org/browse/WFLY-7027 > Project: WildFly > Issue Type: Bug > Components: JMX > Affects Versions: 10.0.0.Final > Reporter: Dennis Reed > Assignee: Kabir Khan > > An MBean with: > public void setObj(javax.management.ObjectName someObject) > <mbean ...> > <attribute name="Obj" /> > causes "java.lang.ClassNotFoundException: javax.management.MalformedObjectNameException from [Module \"org.jboss.common-beans:main\" > org.jboss.common.beans.property.ObjectNameEditor in that module is used to convert to ObjectName objects, and requires MalformedObjectNameException but it is not on the classpath of that module. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7027) MBeans with ObjectName attributes throw ClassNotFoundException

by Dennis Reed (JIRA)

Dennis Reed created WFLY-7027: --------------------------------- Summary: MBeans with ObjectName attributes throw ClassNotFoundException Key: WFLY-7027 URL: https://issues.jboss.org/browse/WFLY-7027 Project: WildFly Issue Type: Bug Components: JMX Affects Versions: 10.0.0.Final Reporter: Dennis Reed Assignee: Kabir Khan An MBean with: public void setObj(javax.management.ObjectName someObject) <mbean ...> <attribute name="Obj" /> causes "java.lang.ClassNotFoundException: javax.management.MalformedObjectNameException from [Module \"org.jboss.common-beans:main\" org.jboss.common.beans.property.ObjectNameEditor in that module is used to convert to ObjectName objects, and requires MalformedObjectNameException but it is not on the classpath of that module. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6803) Add multi-server support to mod_cluster

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6803?page=com.atlassian.jira.plugin.... ] Radoslav Husar reassigned WFLY-6803: ------------------------------------ Assignee: Radoslav Husar (was: Paul Ferraro) > Add multi-server support to mod_cluster > --------------------------------------- > > Key: WFLY-6803 > URL: https://issues.jboss.org/browse/WFLY-6803 > Project: WildFly > Issue Type: Enhancement > Components: mod_cluster > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > > Currently, mod_cluster subsystem supports only a single configuration, which references the default undertow server. However, Undertow supports multiple servers, and exposes a distinct route capability per server (see WFLY-6778). > mod_cluster should therefore support multiple "profiles", where each profile references a specific undertow server. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7026) Remove test workaround for WFLY-5794

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-7026: ------------------------------------ Summary: Remove test workaround for WFLY-5794 Key: WFLY-7026 URL: https://issues.jboss.org/browse/WFLY-7026 Project: WildFly Issue Type: Task Components: Clustering Affects Versions: 10.1.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Priority: Minor Fix For: 11.0.0.Alpha1 This reverts commit 553957d3c48e054c5286a7d6f8d30e557918e7d9. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4416) Cannot obtain DOMImplementationRegistry instance

by Mathieu Lachance (JIRA)

[ https://issues.jboss.org/browse/WFLY-4416?page=com.atlassian.jira.plugin.... ] Mathieu Lachance commented on WFLY-4416: ---------------------------------------- [~ctomc], what do you mean by it must be done manually? Is there's any way for the application (either by modifing com/sun modules.xml / jboss-deployment-structure.xml?) to do 'this' manually? > Cannot obtain DOMImplementationRegistry instance > ------------------------------------------------ > > Key: WFLY-4416 > URL: https://issues.jboss.org/browse/WFLY-4416 > Project: WildFly > Issue Type: Bug > Components: XML Frameworks > Affects Versions: 8.2.0.Final > Reporter: Thomas Diesler > Assignee: Jason Greene > > {code} > testDOMImplementationRegistry(org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase) Time elapsed: 0.09 sec <<< ERROR! > java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.dom.DOMXSImplementationSourceImpl from [Module "deployment.dom-registry-test:main" from Service Module Loader] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) > at org.w3c.dom.bootstrap.DOMImplementationRegistry.newInstance(DOMImplementationRegistry.java:182) > at org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase.testDOMImplementationRegistry(DOMImplementationRegistryTestCase.java:52) > {code} > CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/391 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1756) Adding content to an exploded deployment with overwrite to false should fail if file already exists

by ehsavoie Hugonnet (JIRA)

ehsavoie Hugonnet created WFCORE-1756: ----------------------------------------- Summary: Adding content to an exploded deployment with overwrite to false should fail if file already exists Key: WFCORE-1756 URL: https://issues.jboss.org/browse/WFCORE-1756 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Alpha5 Reporter: ehsavoie Hugonnet Assignee: ehsavoie Hugonnet If overwrite is set to false then adding the file should fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1752) The deployment-overlay command fails to redeploy affected deployments

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1752?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1752: ------------------------------------------ Is coupling to the runtime-name really the intended behavior? Or is that a bug? Or perhaps a design flaw? I can see arguments both ways, so I'm curious what [~swd847] had in mind at the beginning. Certainly the runtime-name needs to come into the picture in order to get the content into the running app; I'm asking here about the meaning of the "name" attribute in the deployment-overlay/deployment element. > The deployment-overlay command fails to redeploy affected deployments > --------------------------------------------------------------------- > > Key: WFCORE-1752 > URL: https://issues.jboss.org/browse/WFCORE-1752 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha5 > Reporter: ehsavoie Hugonnet > Assignee: Alexey Loubyansky > > The deployment-overlay command fails to redeploy affected deployments if the runtime-name isn't the same as the deployment name. Since affected deployment to be redeployed should be running the couple runtime-name + enabled == true should be used to define which deployments are affected instead of using the deployment name since the name used in overlay is the runtime-name -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1755) Wrong cursor position after deleting all characters in second line

by Tomas Hofman (JIRA)

Tomas Hofman created WFCORE-1755: ------------------------------------ Summary: Wrong cursor position after deleting all characters in second line Key: WFCORE-1755 URL: https://issues.jboss.org/browse/WFCORE-1755 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 3.0.0.Alpha3 Environment: Fedora 24 Gnome Terminal 3.20 Bash 4.3.42 Reporter: Tomas Hofman Assignee: Tomas Hofman In CLI, when typing expression that stretches more then one line, and then deleting all characters in the last line (using backspace), cursor appears on wrong position on the previous line (should be on last column, but is on column before the last). Further editing messes up the displayed expression, which doesn't reflect the real content of the buffer. *Reproducing:* * Terminal width is 80 characters. * [] marks a cursor position. Step 1. - I have expression spreading over two lines like this: {code} [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection- factory[] {code} Step 2. - Delete "factory" word using backspace: {code} [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection- [] {code} Step 3. - Another backspace: {code} [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connectio[n] {code} while expected is: {code} [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection[] {code} Step 4. - Another backspace: {code} [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connecti[]n {code} while expected is: {code} [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connectio[] {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1754) Wrong cursor position after deleting all characters in second line

by Tomas Hofman (JIRA)

Tomas Hofman created WFCORE-1754: ------------------------------------ Summary: Wrong cursor position after deleting all characters in second line Key: WFCORE-1754 URL: https://issues.jboss.org/browse/WFCORE-1754 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 3.0.0.Alpha3 Environment: Fedora 24 Gnome Terminal 3.20 Bash 4.3.42 Reporter: Tomas Hofman Assignee: Tomas Hofman In CLI, when typing expression that stretches more then one line, and then deleting all characters in the last line (using backspace), cursor appears on wrong position on the previous line (should be on last column, but is on column before the last). Further editing messes up the displayed expression, which doesn't reflect the real content of the buffer. *Reproducing:* * Terminal width is 80 characters. * [] marks a cursor position. Step 1. - I have expression spreading over two lines like this: {code} [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection- factory[] {code} Step 2. - Delete "factory" word using backspace: {code} [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection- [] {code} Step 3. - Another backspace: {code} [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connectio[n] {code} while expected is: {code} [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connection[] {code} Step 4. - Another backspace: {code} [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connecti[]n {code} while expected is: {code} [standalone@embedded /] /subsystem=datasources/data-source=ExampleDS/connectio[] {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1221) Add fail-safe and scalability functionality to the Drools (CEP) rules engine

by Youcef HILEM (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1221?page=com.atlassian.jira.plugi... ] Youcef HILEM commented on DROOLS-1221: -------------------------------------- Hi Tom, Infinispan does not implement Off-heap in the current version (http://infinispan.org/roadmap/). > Add fail-safe and scalability functionality to the Drools (CEP) rules engine > ---------------------------------------------------------------------------- > > Key: DROOLS-1221 > URL: https://issues.jboss.org/browse/DROOLS-1221 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 6.4.0.Final > Environment: Drools (CEP) Rule engine 6.4.0.Final > Reporter: Tom Pijl > Assignee: Mario Fusco > > The Drools Rule engine is currently not fail-safe and scalable which is a requirement for Cloud deployment. > Add a possibility to persist the state of the working memory after each state change (perhaps linked to the fireAllRules()?) and related to that the possibility to restore the state in case of a crash (fail-safe requirement). > This persistent state store can also be used to synchronize multiple engine instances (scalability requirement). > Of course this has major impact on the performance of the engine, but it is the only way to make the engine useful in a multi-tenant Cloud environment -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2016