October 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 commented on WFLY-7027: ----------------------------------------------- Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1372096|https://bugzilla.redhat.com/show_bug.cgi?id=1372096] from POST to MODIFIED > 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: Bartosz Baranowski > Fix For: 11.0.0.Alpha1 > > > 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 (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7430) Typo in thread-pool resource description

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-7430?page=com.atlassian.jira.plugin.... ] James Perkins moved JBEAP-6746 to WFLY-7430: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7430 (was: JBEAP-6746) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Batch (was: Batch) (was: User Experience) Affects Version/s: (was: 7.1.0.DR7) > Typo in thread-pool resource description > ---------------------------------------- > > Key: WFLY-7430 > URL: https://issues.jboss.org/browse/WFLY-7430 > Project: WildFly > Issue Type: Bug > Components: Batch > Reporter: James Perkins > Assignee: James Perkins > Priority: Trivial > > /subsystem=batch-jberet/thread-pool=batch:read-resource-description() > returns > "description" => "... be greaterthan 3..." > Please split 'greaterthan' to 'greater than' -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1913) Update management realm readiness checks to be backed by a function rather than a SecurityRealm

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1913: ---------------------------------------- Summary: Update management realm readiness checks to be backed by a function rather than a SecurityRealm Key: WFCORE-1913 URL: https://issues.jboss.org/browse/WFCORE-1913 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha12 -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-695) Is impossible remove whole Elytron subsystem when Elytron resource depends on another Elytron resource.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/ELY-695?page=com.atlassian.jira.plugin.sy... ] Brian Stansberry commented on ELY-695: -------------------------------------- I don't know if this is relevant, but please see description of WFCORE-1106 in case it is. > Is impossible remove whole Elytron subsystem when Elytron resource depends on another Elytron resource. > ------------------------------------------------------------------------------------------------------- > > Key: ELY-695 > URL: https://issues.jboss.org/browse/ELY-695 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store, KeyStores > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > > Is impossible remove whole Elytron subsystem by one command when Elytron resource depends on another Elytron resource. > *Scenario:* > * I have KeyStore in Elytron subsystem with CredentialStoreReference set to CredentialStore > * I want to delete whole Elytron subsystem > * I execute this CLI command */subsystem=elytron:remove()* and get error > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service org.wildfly.security.credential-store-client.credStore was depended upon by service org.wildfly.security.key-store.firefly", > "rolled-back" => true > } > {code} > *NOTES:* > * When I perform CLI command */subsystem=elytron:remove()* again as it passes. > * When I use for remove {allow-resource-service-restart=true} as /subsystem=elytron:remove(){allow-resource-service-restart=true} then result is successful. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1902) Error messages from CLI batch should be more informative

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1902?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1902: ------------------------------------------ Trying to figure out what line in a script sounds like more trouble than it is worth. If it's possible to report the batch step number and the operation invoked by that step, I think that would provide most of the value. Seeing that :readAttribute(name=nonsence) failed should provide enough insight to let people figure out what line in a script was at fault. Side note: be cautious about using DMR syntax to report high level failures that aren't simply showing the output of the low level failure. AFAIK we don't do that elsewhere and it's probably not something we should do on a case by case basis without an overall strategy. > Error messages from CLI batch should be more informative > -------------------------------------------------------- > > Key: WFCORE-1902 > URL: https://issues.jboss.org/browse/WFCORE-1902 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Affects Versions: 3.0.0.Alpha10 > Reporter: Marek Kopecký > Assignee: Jean-Francois Denise > > *Description of problem:* > Error messages from CLI batch should be more informative > *Steps to Reproduce:* > {noformat} > cat <<EOF >a > batch > :read-attribute(name=product-version) > :read-attribute(name=product-name) > :read-attribute(name=nonsence) > :read-attribute(name=product-name) > run-batch > EOF > ./jboss-cli.sh -c --file=a > {noformat} > *Actual results:* > {noformat} > The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}} > {noformat} > *Expected results:* > I can imagine content like following could be helpful for troubleshooting: > {noformat} > { > "WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => { > "Operation step-3" => { > "line number" => 4 > "operation" => ":read-attribute(name=nonsence)" > "response" => "WFLYCTL0201: Unknown attribute 'nonsence'" > } > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1407) Test coverage for syslog reconnection

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1407?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1407: ------------------------------------------------- Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1311440|https://bugzilla.redhat.com/show_bug.cgi?id=1311440] from POST to MODIFIED > Test coverage for syslog reconnection > ------------------------------------- > > Key: WFCORE-1407 > URL: https://issues.jboss.org/browse/WFCORE-1407 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.1.0.CR2 > Reporter: Ondrej Lukas > Assignee: Ondrej Lukas > Fix For: 3.0.0.Alpha1 > > > Added test coverage for syslog reconnection issues - https://issues.jboss.org/browse/LOGMGR-123. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4133) Hanging EJB threads because of a persistent timer and failed deployment

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4133?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4133: ----------------------------------------------- Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1147948|https://bugzilla.redhat.com/show_bug.cgi?id=1147948] from POST to MODIFIED > Hanging EJB threads because of a persistent timer and failed deployment > ------------------------------------------------------------------------ > > Key: WFLY-4133 > URL: https://issues.jboss.org/browse/WFLY-4133 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Enrique González Martínez > Assignee: Enrique González Martínez > Fix For: 9.0.0.Beta1 > > > When there is a time service with pending timeouts a bad redeploy can hang worker threads in the server. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1912) Redeploy deployment if all missing dependencies for deployment are corrected

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1912?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1912: ------------------------------------------ Doesn't this already work if the rollback-on-runtime-failure=false operation header is used when the deployment is initially deployed? > Redeploy deployment if all missing dependencies for deployment are corrected > ----------------------------------------------------------------------------- > > Key: WFCORE-1912 > URL: https://issues.jboss.org/browse/WFCORE-1912 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Miroslav Novak > Assignee: Jason Greene > > If deployment failed to deploy and later all missing dependencies for deployment are corrected then deployment would redeploy automatically. This behavior could be configurable. > For example if you deploy EJB which injects queue like: > {code} > @Resource(mappedName = "java:/jms/queue/OutQueue") > private Queue outQueue; > {code} > and administrator deploys queue later then EJB would automatically get redeployed. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1912) Redeploy deployment if all missing dependencies for deployment are corrected

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1912?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-7394 to WFCORE-1912: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1912 (was: WFLY-7394) Component/s: Server (was: Server) Affects Version/s: (was: 10.1.0.Final) > Redeploy deployment if all missing dependencies for deployment are corrected > ----------------------------------------------------------------------------- > > Key: WFCORE-1912 > URL: https://issues.jboss.org/browse/WFCORE-1912 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Miroslav Novak > Assignee: Jason Greene > > If deployment failed to deploy and later all missing dependencies for deployment are corrected then deployment would redeploy automatically. This behavior could be configurable. > For example if you deploy EJB which injects queue like: > {code} > @Resource(mappedName = "java:/jms/queue/OutQueue") > private Queue outQueue; > {code} > and administrator deploys queue later then EJB would automatically get redeployed. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1911) Port DeploymentScannerTestCase to upstream

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1911?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1911: ------------------------------------------ Yes. The initial test design shouldn't drive the structure of our test suite. Everything it does using Arquillian can be done using similar non-arquillian mechanisms available in core, e.g. WildFlyTestRunner. That's true for any @RunAsClient arquilian test. > Port DeploymentScannerTestCase to upstream > ------------------------------------------ > > Key: WFCORE-1911 > URL: https://issues.jboss.org/browse/WFCORE-1911 > Project: WildFly Core > Issue Type: Task > Components: Deployment Scanner, Test Suite > Reporter: Peter Palaga > Assignee: Tomas Hofman > > The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream, thus not fulfilling the "Upstream First" requirement. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 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 October 2016