[JBoss JIRA] Created: (JBAS-8135) By default use a common identifier anywhere a server "id" notion is exposed in the configuration
by Brian Stansberry (JIRA)
By default use a common identifier anywhere a server "id" notion is exposed in the configuration
------------------------------------------------------------------------------------------------
Key: JBAS-8135
URL: https://jira.jboss.org/browse/JBAS-8135
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.0.0.M1
This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
>> * JBoss Transactions, jvm-route, jboss messaging all require a
>> unique identifier for them to behave properly in a clustered
>> environment. I would like one unique identifier for each server
>> configuration and for all services that need a unique identifier
>> to reference it by default. Then I don't have to worry about
>> unique identifiers when creating new servers.
(The jboss messaging bit is out of date with respect to AS 7, which will use HornetQ and thus has no ServerPeerId configuration required. But the basic point is spot-on.)
--
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
12 years, 5 months
[JBoss JIRA] Created: (JBRULES-2293) Classpath resources being scanned by ResourceChangeScanner could cause improper resource removal
by Steve Ronderos (JIRA)
Classpath resources being scanned by ResourceChangeScanner could cause improper resource removal
------------------------------------------------------------------------------------------------
Key: JBRULES-2293
URL: https://jira.jboss.org/jira/browse/JBRULES-2293
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.0.1.FINAL
Environment: Windows XP
Java 5
Running in Oracle OC4J 10.1.3.2
Reporter: Steve Ronderos
Assignee: Mark Proctor
I encountered an issue today with my KnowledgeAgent removing resources from its RuleBase shortly after creating it. I have the ResourceChangeScanner running in my application.
I tracked the issue back to the scan() method in ResourceChangeScannerImpl. It appears that the method is trying to identify resources that are no longer available and remove them from both the RuleBase and future scans. To do this it is checking lastModified on the resource and on a result of 0 removing the resource. The resources that I configured in my change-set definitely still exist, but due to URL handler implementation provided by my classloader, getLastModified always returns 0. (The resource I'm retrieving is coming from a jar that is in my application's classpath and the URL handler implementation is oracle.classloader.SharedCodeSourceURL)
Full Email Group trail: http://www.nabble.com/Issue-with-ResourceChangeScanner-td25792358.html
Michael recommends to never scan classpath resources.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (JBAS-8337) handling of deployment failed at batch resolve time
by Alexey Loubyansky (JIRA)
handling of deployment failed at batch resolve time
---------------------------------------------------
Key: JBAS-8337
URL: https://jira.jboss.org/browse/JBAS-8337
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Fix For: 7.0.0.M1
Types of failures here include: duplicate service definition (i.e. a service was defined that already exists in the container), missing required dependency (i.e. a service was defined that depends on something that isn't there), circular dependency (i.e. two or more service definitions represent circularity in terms of their dependency links). Right now this erases the entire batch, which means that the server cannot start if any of these errors occur. The correct behavior is, in my opinion, to log each error and continue, possibly yielding a report of problem services after the batch is resolved (it is likely, however, that one failure will lead to others).
--
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
12 years, 5 months