February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3013) Cannot add exploded deployments through CLI on Windows

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/WFLY-3013?page=com.atlassian.jira.plugin.... ] Jan Martiska closed WFLY-3013. ------------------------------ Resolution: Won't Fix Whoa, indeed, my stupid mistake. Thanks for explanation and sorry for confusion. > Cannot add exploded deployments through CLI on Windows > ------------------------------------------------------ > > Key: WFLY-3013 > URL: https://issues.jboss.org/browse/WFLY-3013 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Jan Martiska > Priority: Minor > > Try to deploy a directory (exploded deployment) in Windows like this: > {noformat} > /deployment=eardeployment1.ear:add(content=[{"path"=>"C:\QA\jmartisk\exploded_deployments\eardeployment1.ear","archive"=>false}],enabled=true) > {noformat} > it fails with an error like this: > {noformat} > "failure-description" => {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"eardeployment1.ear\".STRUCTURE" > => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"eardeployment1.ear\".STRUCTURE: JBAS018733: > Failed to process phase STRUCTURE of deployment \"eardeployment1.ear\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Failed to mount deployment > content > Caused by: java.io.FileNotFoundException: C:\\QA\\jmartisk\\wildfly-8.0.1.Final-SNAPSHOT\\QAjmartiskexploded_deploymentseardeployment1.ear (The filename, directory name, or volume label synt > ax is incorrect)"}}, > {noformat} > The same command works in Linux. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3025) Taking thread dumps via HC

by James Livingston (JIRA)

James Livingston created WFLY-3025: -------------------------------------- Summary: Taking thread dumps via HC Key: WFLY-3025 URL: https://issues.jboss.org/browse/WFLY-3025 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 8.0.0.Final Reporter: James Livingston Assignee: James Livingston It would be useful to be able to gather low-level per-server information such as Java thread dumps. This would best be gathered from the Host Controllers, and be available via the management model. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3024) Remove OperationContext.readModelForUpdate() or fix impl to not create resources

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-3024: -------------------------------------- Summary: Remove OperationContext.readModelForUpdate() or fix impl to not create resources Key: WFLY-3024 URL: https://issues.jboss.org/browse/WFLY-3024 Project: WildFly Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 9.0.0.CR1 OperationContextImpl.readModelForUpdate() creates the target resource if it is not found. That's not good; createResource or addResource are for that and readResourceForUpdate does not do this. No code in WF itself actually calls this method. Either: 1) Remove the method (it's been deprecated since June 2011) 2) Change the impl to a simple readResourceForUpdate(address).getModel() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3017) OperationContextImpl.readResourceForUpdate assumes all resources represent persistent config

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3017?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-3017: ---------------------------------------- Same for removeResource and addResource. The latter probably doesn't matter much, since runtime-only resources are typically not added via mgmt ops. But I'll fix it anyway. > OperationContextImpl.readResourceForUpdate assumes all resources represent persistent config > -------------------------------------------------------------------------------------------- > > Key: WFLY-3017 > URL: https://issues.jboss.org/browse/WFLY-3017 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.1.Final > > > The readResourceForUpdate impl makes a few assumptions regarding the fact that a given Resource represents persistent config (i.e. Resource.isRuntime() == true): > 1) It calls rejectUserDomainServerUpdates() which means an OSH running on a server could not call this. > 2) It calls authorize(false, READ_WRITE_CONFIG) which means an OSH for an op available to the RBAC Operator role could not call this. > Places this impacts include LogStoreProbeHandler and LogStoreTransactionDeleteHandler which should be calling readResourceForUpdate but aren't -- and can't because of this bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3019) Shutdown on startup error

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3019?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-3019: ---------------------------------------- Anyone who looks at this, search the code for uses of "jboss.unsupported.fail-boot-on-runtime-failure" which the testsuite uses to trigger this kind of behavior. Implementing this might just involve exposing a proper configuration mechanism for this. Having different behavior based on whether the failure occurred in subsystems or deployments would require something more (and may have unacceptable boot speed costs; or maybe not.) > Shutdown on startup error > ------------------------- > > Key: WFLY-3019 > URL: https://issues.jboss.org/browse/WFLY-3019 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Takayoshi Kimura > > Currently WildFly starts and up running although it got critical errors during boot. > For example, 8080 port is being used by the other process and undertow subsystem was not functioning, transaction manager and logging subsystems are failed to boot due to file permission error, or someone started the instance twice by mistake. > It would be nice if we can have an option to trigger shutdown the non-healthy instance in these boot error situations, for subsystem level errors and for deployment errors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-95) Log4j Logger.getParent() inconsistent

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-95?page=com.atlassian.jira.plugin.... ] David Lloyd commented on LOGMGR-95: ----------------------------------- OK. It should be pretty simple to duplicate the log4j behavior; it will simply cause the intermediate node to come into existence, which is fine. > Log4j Logger.getParent() inconsistent > ------------------------------------- > > Key: LOGMGR-95 > URL: https://issues.jboss.org/browse/LOGMGR-95 > Project: JBoss Log Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: James Livingston > Assignee: David Lloyd > > Log4j Loggers have a getParent() method, whose return value is set up by JBossLogManagerFacade.updateParents(). The method locates the closest parent node which has an existing Log4J logger created *at the time*. This results in the parent being different depending on the order Log4j loggers are used in. > Consider: > Logger.getLogger("a"); > Logger.getLogger("a.b.c"); > Logger.getLogger("a.b"); > When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has already created the intermediate "a.b" node. That does not yet have a Log4j Logger created, so the Logger for "a" is returned. Original log4j would have returned "a.b" due to it using the parent structure in the implementation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-95) Log4j Logger.getParent() inconsistent

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-95?page=com.atlassian.jira.plugin.... ] James Livingston commented on LOGMGR-95: ---------------------------------------- Logger a = Logger.getLogger("a"); Logger abc = Logger.getLogger("a.b.c"); Logger ab = Logger.getLogger("a.b"); With the log4j bridge, abc.getParent().getName() == "a" but with original log4j it is "a.b". An alternative would be to have Logger.getParent() get the parent node and then convert that back to a Logger (so dropping updateParents() altogether), but I believe that would require Logger to have changes from upstream which it doesn't currently have. Logger.getParent() isn't particularly well documented as to what it is supposed to do, but the bridge's current behaviour is not identical to Log4J's. > Log4j Logger.getParent() inconsistent > ------------------------------------- > > Key: LOGMGR-95 > URL: https://issues.jboss.org/browse/LOGMGR-95 > Project: JBoss Log Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: James Livingston > Assignee: David Lloyd > > Log4j Loggers have a getParent() method, whose return value is set up by JBossLogManagerFacade.updateParents(). The method locates the closest parent node which has an existing Log4J logger created *at the time*. This results in the parent being different depending on the order Log4j loggers are used in. > Consider: > Logger.getLogger("a"); > Logger.getLogger("a.b.c"); > Logger.getLogger("a.b"); > When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has already created the intermediate "a.b" node. That does not yet have a Log4j Logger created, so the Logger for "a" is returned. Original log4j would have returned "a.b" due to it using the parent structure in the implementation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3023) JDR CommandLineMain defaults to port 9999

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-3023: -------------------------------------- Summary: JDR CommandLineMain defaults to port 9999 Key: WFLY-3023 URL: https://issues.jboss.org/browse/WFLY-3023 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: JDR Affects Versions: 8.0.0.Final Reporter: Brian Stansberry Assignee: Jesse Jaggars If the user doesn't provide a port, CommandLineMain defaults to 9999, but with protocol http-remoting. That combo won't work. It should use 9990 since that will be the default management port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3022) Make LogStoreResource's 'type' attribute read-only

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-3022: -------------------------------------- Summary: Make LogStoreResource's 'type' attribute read-only Key: WFLY-3022 URL: https://issues.jboss.org/browse/WFLY-3022 Project: WildFly Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Transactions Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 9.0.0.CR1 See parent issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3021) LogStoreDefinition exposes a bogus write-attribute handler for its 'type' attribute

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-3021: -------------------------------------- Summary: LogStoreDefinition exposes a bogus write-attribute handler for its 'type' attribute Key: WFLY-3021 URL: https://issues.jboss.org/browse/WFLY-3021 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Transactions Affects Versions: 8.0.0.Final Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 8.0.1.Final The 'type' attribute of LogStoreResource isn't really read-write. Its value is determined by attributes of the parent resource. The OSH for write-attribute is ReloadRequiredWriteAttributeHandler, and when the reload happens whatever value is set will be lost. For 8.0.1 I'll have the OSH just log a WARN. The attribute should be made read-only for 9. I could make it read-only for 8.0.1 but I don't want to do a management API bump, introduce transformation etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 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 February 2014