[
https://jira.jboss.org/jira/browse/JBAS-5284?page=com.atlassian.jira.plug...
]
Brian Stansberry commented on JBAS-5284:
----------------------------------------
LOL. I was going to change this to Fix Version Backlog, since it's a solvable problem
but wasn't anywhere on my radar screen. But just rejecting it seems more honest.
In AS 5, deploy-hasingleton content is presented individually to the ProfileService, so
this shouldn't be an issue (although I haven't tested it.)
I don't believe undeploying a URLDeploymentScanner causes an undeployment of
previously deployed content. This could be added to a subclass by overriding stopService,
clearing the urlList and doing one more scan.
Cannot use a scoped loader repository in deploy-hasingleton
deployments
-----------------------------------------------------------------------
Key: JBAS-5284
URL:
https://jira.jboss.org/jira/browse/JBAS-5284
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Clustering
Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.2.GA
Reporter: Brian Stansberry
Assignee: Brian Stansberry
If you try to add a loader-repository element to a deploy-hasingleton deployment, you get
something like this:
Only the root deployment can set the loader repository, ignoring
config=LoaderRepositoryConfig(repositoryName:
jboss.dataintegration:sar=dataintegration.sar, repositoryClassName:
org.jboss.mx.loading.HeirarchicalLoaderRepository3, configParserClassName:
org.jboss.mx.loading.HeirarchicalLoaderRepository3ConfigParser, repositoryConfig:
java2ParentDelegation=false)
I suspect this is because the deploy-hasingleton dir itself is being treated as the root
deployment.
--
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