[JBoss JIRA] Created: (JBAS-9186) DC allows for registration of multiple hosts with same name
by Heiko Rupp (JIRA)
DC allows for registration of multiple hosts with same name
-----------------------------------------------------------
Key: JBAS-9186
URL: https://issues.jboss.org/browse/JBAS-9186
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 7.0.0.Beta1
Reporter: Heiko Rupp
Have a domain with two hosts, where you basically clone the one configuration to the other host and then have the DC property point to the first one. Do not modify the <host name="local" > settings in host.xml (most users will just forget this).
Then start this "slave".
DC will print:
[Host Controller] 14:21:33,442 INFO [org.jboss.domain] (pool-1-thread-18) register host local
navigate to http://domain-controller:9990/domain-api/?json.pretty=true
This hangs and the DC logs shows exceptions about "network unreachable".
So allowing to register two hosts with the same name should not be allowed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JBAS-9196) In domain mode, ObjectStore and PutObjectStoreDirHere directory structures are created at root level of the dist
by Brian Stansberry (JIRA)
In domain mode, ObjectStore and PutObjectStoreDirHere directory structures are created at root level of the dist
----------------------------------------------------------------------------------------------------------------
Key: JBAS-9196
URL: https://issues.jboss.org/browse/JBAS-9196
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transaction Manager Integration (Arjuna)
Affects Versions: 7.0.0.Alpha1
Reporter: Brian Stansberry
Assignee: Stefano Maestri
If you start using domain.sh, "ObjectStore" and "PutObjectStoreDirHere" directories appear at the same level as bin, domain, standalone. They should be in domain/servers/XXXX/data where XXXX is the name of the server.
I don't see any jbossts related directories if standalone.sh is used.
I did some tracing of the path string being injected into o.j.as.tx.ArjunaTransactionManagerService's pathInjector, and it's the expected /pathToJBoss/domain/servers/XXXX/data/tx-object-store. Beyond that I don't know what happens.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JBAS-9134) Flatten out the structure of the "jvm" resource
by Brian Stansberry (JIRA)
Flatten out the structure of the "jvm" resource
-----------------------------------------------
Key: JBAS-9134
URL: https://issues.jboss.org/browse/JBAS-9134
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 7.0.0.Beta3
The managment model resource representing a JVM has complex attribute types where they aren't required. For example the "heap" attribute is a map with 2 keys "size" and "max-size". Better to use 2 top level attributes "heap-size" and "max-heap-size". This makes the values easily accessible via a "read-attribute" and "write-attribute".
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JBAS-8501) Support for file system hot deployment of exploded archives
by Brian Stansberry (JIRA)
Support for file system hot deployment of exploded archives
-----------------------------------------------------------
Key: JBAS-8501
URL: https://jira.jboss.org/browse/JBAS-8501
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Deployers
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.0.0.M2
Basic JBAS-8357 solution deals with zipped archives. We also want to support exploded archives.
My thought is the scanner will inform the deployment repo of the new content. The repo instead of persisting a a1/b2c3xxxx/content file will persist a a1/b2c3xxxxx/url file that includes the URL of the exploded content in the hot deploy dir. When the repo is asked for the deployment, it will find the "url" file and use it to find the actual deployment content in the hot deploy dir. (It can actually keep this information in memory; the "url" file is to allow the connection to survive restart).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months