August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3702) RetryInvoker is useless within the context of a transaction.

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-3702: ---------------------------------- Summary: RetryInvoker is useless within the context of a transaction. Key: WFLY-3702 URL: https://issues.jboss.org/browse/WFLY-3702 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 8.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 8.2.0.CR1, 9.0.0.Beta1 RetryInvoker should not retry if a given operation is transactional. If the operation fails - the status of the current transaction will be rollback-only, which will fail due to invalid transaction status if retried. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBSER-132) Broken Links on JBoss.org

by Daniel Coughlin (JIRA)

Daniel Coughlin created JBSER-132: ------------------------------------- Summary: Broken Links on JBoss.org Key: JBSER-132 URL: https://issues.jboss.org/browse/JBSER-132 Project: JBoss Serialization Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Daniel Coughlin Assignee: Clebert Suconic The following broken link is currently listed against this project on www.jboss.org/projects. http://www.jboss.org/feeds/view/serialization - Blog Link If you maintain a project.properties file that you have told the jboss.org team about, then you just need to fix it in there and the change will be reflected on the site. Otherwise, you need to update the data on this project's Magnolia page. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-37) Batching logging profile creation CLI commands can cause errors

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-37?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFCORE-37: ------------------------------------- The easiest workaround for this is to just add the handler in the {{add}} operation. The issue is how the operations are processed. The model is first updated which because the the {{add-handler}} operation adds the handler to the model. Then the runtime is updated and during the add of the logger, the handler is assigned to the logger because it's in the model. This results in the {{add-handler}} failing as the {{add}} operation for the {{root-logger=ROOT}} resource already added the runtime change for the handler. > Batching logging profile creation CLI commands can cause errors > --------------------------------------------------------------- > > Key: WFCORE-37 > URL: https://issues.jboss.org/browse/WFCORE-37 > Project: WildFly Core > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: Kyle Lape > Assignee: James Perkins > > Given these set of commands: > {noformat} > /subsystem=logging/logging-profile=myLoggingProfile:add > /subsystem=logging/logging-profile=myLoggingProfile/file-handler=myHandler:add(level=ALL,file={"relative-to" => "jboss.server.log.dir","path" => "myapp.log"}) > /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add > /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add-handler(name=myHandler) > /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:change-root-log-level(level=INFO) > {noformat} > If I run those in a batch, I get an error: > {noformat}13:32:52,478 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("add-handler") failed - address: ([ > ("subsystem" => "logging"), > ("logging-profile" => "myLoggingProfile"), > ("root-logger" => "ROOT") > ]) - failure description: "JBAS011536: Handler myHandler is already assigned." > {noformat} > If I run each one individually, I get no error. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBBUILD-737) Broken Link on JBoss.org

by Daniel Coughlin (JIRA)

Daniel Coughlin created JBBUILD-737: --------------------------------------- Summary: Broken Link on JBoss.org Key: JBBUILD-737 URL: https://issues.jboss.org/browse/JBBUILD-737 Project: JBoss Build System Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Daniel Coughlin Assignee: Paul Gier The following broken link is currently listed against this project on www.jboss.org/projects. http://fisheye.jboss.org/repos/jbossbuild/trunk - Fisheye Link If you maintain a project.properties file that you have told the jboss.org team about, then you just need to fix it in there and the change will be reflected on the site. Otherwise, you need to update the data on this project's Magnolia page. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3670) Flag modules to be loaded in a distinct classloader context

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3670?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-3670: ----------------------------------- Oh, well in that case, I'd say you're simply doing it wrong: the shared stuff should not be in a module at all, just in a filesystem JAR. Then, you add the filesystem JAR in to each deployment as a resource root. > Flag modules to be loaded in a distinct classloader context > ----------------------------------------------------------- > > Key: WFLY-3670 > URL: https://issues.jboss.org/browse/WFLY-3670 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > For some use-cases it will be helpful to have a module in a separate classloader (as copy) if it is used from different applications. > An example is if the module includes classes which follow the singleton pattern but the singleton should be per application instead of instance wide. > There are two possiblities to flag that > - within the module.xml > - within the module reference MAIFEST or jboss-deployment-structure.xml -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-38) Add additional password algorithms to WildFlyElytronPasswordProvider

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-38: ----------------------------------- Summary: Add additional password algorithms to WildFlyElytronPasswordProvider Key: ELY-38 URL: https://issues.jboss.org/browse/ELY-38 Project: WildFly Elytron Issue Type: Task Security Level: Public (Everyone can see) Components: API / SPI, Password Types Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Beta1 A number of algorithms are now supported, update 'WildFlyElytronPasswordProvider' so that these are also registered. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3701) Investigate HTTPSManagementInterfaceTestCase.testHTTPS and HTTPSWebConnectorTestCase.testVerifyingConnector failures

by Emmanuel Hugonnet (JIRA)

Emmanuel Hugonnet created WFLY-3701: --------------------------------------- Summary: Investigate HTTPSManagementInterfaceTestCase.testHTTPS and HTTPSWebConnectorTestCase.testVerifyingConnector failures Key: WFLY-3701 URL: https://issues.jboss.org/browse/WFLY-3701 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Web (Undertow) Affects Versions: 9.0.0.Beta1 Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet Those tests are failing on Brontes: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=19132&tab=buil... Need to investigate -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-748) HTTP management API section in the Admin Guide

by Emmanuel Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFLY-748?page=com.atlassian.jira.plugin.s... ] Emmanuel Hugonnet commented on WFLY-748: ---------------------------------------- https://docs.jboss.org/author/display/WFLY9/The+HTTP+management+API has been created > HTTP management API section in the Admin Guide > ---------------------------------------------- > > Key: WFLY-748 > URL: https://issues.jboss.org/browse/WFLY-748 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: No Release > > > We need a technical guide to the HTTP management API. > The "Management clients" section gives a basic overview. But it should reference a separate section that documents the usage of GET and POST, the URL patterns, the JSON representation of DMR etc. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3670) Flag modules to be loaded in a distinct classloader context

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/WFLY-3670?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink commented on WFLY-3670: ---------------------------------------- I did not meant to have absolute path for resources here. The issue is that if a module is referenced from different applications the module itself is loaded with a unique classloader. So all applications which depends on this module are using the same instance of static members. In case of having a module implementation with such static objects and the application need to have these objects unique for each application the only approach at the moment is to copy the module. The request is to have a flag like "separateClassLoaderPerDependency" - at module.xml level to have a copy for all dependency references - in the application (jboss-deployment-structure or MANIFEST) to have a separate in-memory copy for this application > Flag modules to be loaded in a distinct classloader context > ----------------------------------------------------------- > > Key: WFLY-3670 > URL: https://issues.jboss.org/browse/WFLY-3670 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > For some use-cases it will be helpful to have a module in a separate classloader (as copy) if it is used from different applications. > An example is if the module includes classes which follow the singleton pattern but the singleton should be per application instead of instance wide. > There are two possiblities to flag that > - within the module.xml > - within the module reference MAIFEST or jboss-deployment-structure.xml -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3700) Optional Module for Camel

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3700?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-3700: ------------------------------ Fix Version/s: Awaiting Volunteers Assignee: (was: David Lloyd) Component/s: (was: Class Loading) > Optional Module for Camel > ------------------------- > > Key: WFLY-3700 > URL: https://issues.jboss.org/browse/WFLY-3700 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Environment: Any > Reporter: Jeremy Davis > Labels: modules > Fix For: Awaiting Volunteers > > > It would be nice to have an optional module with the necessary jars to run Camel -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2014