[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
[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
[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
[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
[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
[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
[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
[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