[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)
7 years, 5 months
[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)
7 years, 5 months
[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)
7 years, 5 months
[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)
7 years, 5 months
[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)
7 years, 5 months
[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)
7 years, 5 months