[JBoss JIRA] Created: (JBAS-9193) Tighten up the ServerEnvironment and HostControllerEnvironment contracts
by Brian Stansberry (JIRA)
Tighten up the ServerEnvironment and HostControllerEnvironment contracts
------------------------------------------------------------------------
Key: JBAS-9193
URL: https://issues.jboss.org/browse/JBAS-9193
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 7.0.0.Beta4
Right now the contract/usage of these classes is a bit of a mishmash. The idea was to store state that's read from Main(). But if there's anything in these that can be overridden from standalone.xml, either we should restrict access to that data or make sure that it has the correct value if a change is made via the management API. For example, the server name can come from standalone.xml if the 'name' attribute is set and for sure will come from the HostController in domain mode.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (AS7-3163) FS deployment scanner fails completely after single timeout failure
by Brent Douglas (Created) (JIRA)
FS deployment scanner fails completely after single timeout failure
-------------------------------------------------------------------
Key: AS7-3163
URL: https://issues.jboss.org/browse/AS7-3163
Project: Application Server 7
Issue Type: Bug
Components: Server
Affects Versions: 7.1.0.CR1
Reporter: Brent Douglas
Assignee: Jason Greene
When deploying via the the FS deployment scanner a timeout causes all subsequent deployments to fail with further timeout failures.
The problem appears to be that FileSystemDeploymentService submits the DeployTask for timed execution it acquires a lock it's copy of ContainerStateMonitor (via OperationContextImpl.acquireContainerMonitor()). When a timeout exception is throw by the first failure this lock is never cleaned up which results in all further deployment jobs to hang on ContainerStateMonitor.await (line 161).
Restarting the server clears the monitor and allows the scanner to be reused as normal.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (AS7-1384) Strange state after :reload
by Heiko Rupp (JIRA)
Strange state after :reload
---------------------------
Key: AS7-1384
URL: https://issues.jboss.org/browse/AS7-1384
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Heiko Rupp
Assignee: Brian Stansberry
7.1 snapshot
I did change a socket binding, so reload is needed. Did a /:read-resource
Then :reload
},
"response-headers" => {"process-state" => "reload-required"}
}
[standalone@localhost:9999 /] :reload
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9999 /] :reload
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
I think after the reload (which succeeded) the process-state should no longer be "reload needed".
Also
{"result" => } should be defined and not just null.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (AS7-2274) Top-level directory tidy-up
by Rich Sharples (Created) (JIRA)
Top-level directory tidy-up
---------------------------
Key: AS7-2274
URL: https://issues.jboss.org/browse/AS7-2274
Project: Application Server 7
Issue Type: Enhancement
Components: Server
Affects Versions: 7.1.0.Alpha1
Environment: all
Reporter: Rich Sharples
Assignee: Jason Greene
Fix For: 7.1.0.Beta1
There is a of stuff in the top-leve directory - much of which, most users will never need to see.
0. create a top-level "lib" directory for all static / read-only artifacts - modules, schemas, bundles, welcome-content. It's quite possible that there is a better name than "lib" - but this is consitent with Linux / Unix lib / Library dirs.
1. Rename and move <JBOSS-HOME>/docs
<JBOSS-HOME>/docs contains no docs. it contains schemas and an odd subdirectory with a HornetQ config. I suggest we rename it "schemas" and hide it under "lib". As for examples/configs dir. - is it required by anything ?
2. Move app-client under lib - doesn't need to be in the top-level directory
3. Move jboss-modules.jar under lib
This will leave JBOSS-HOME with just :
README.txt
copyright.txt
License.txt
bin
domain
standalone
Also - any reason README and LICENSE are upper-case but copyright is lower ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBRULES-3358) Fix reload of KnowledgeAgent resources: CSV, XLS, BPMN
by Edson Tirelli (JIRA)
Edson Tirelli created JBRULES-3358:
--------------------------------------
Summary: Fix reload of KnowledgeAgent resources: CSV, XLS, BPMN
Key: JBRULES-3358
URL: https://issues.jboss.org/browse/JBRULES-3358
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler, drools-core, drools-decisiontables
Affects Versions: 5.4.0.Beta1, 5.3.1.Final
Reporter: Edson Tirelli
Assignee: Edson Tirelli
Fix For: 5.3.2.Final, 5.4.0.Beta2
Placeholder JIRA for several BZ issues as linked.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months