7:01 a.m.
Fix explicit ClassLoadingMetaData in sub-deployment handling
------------------------------------------------------------
Key: JBDEPLOY-222
URL: https://jira.jboss.org/jira/browse/JBDEPLOY-222
Project: JBoss Deployers
Issue Type: Bug
Components: classloading
Affects Versions: JBDEPLOY-2.0.8.SP1
Reporter: Ales Justin
Assignee: Adrian Brock
Fix For: JBDEPLOY-2.1.0.Alpha1
In AbstractClassLoaderDescribeDeployer::deploy
// We only look at non top level deployments that have classloading metadata
if (unit.isTopLevel() == false)
{
if (deployment == null)
return;
// For non top level classloaders, we need to control the domain
// since the parent is the deployment classloader
String unitName = unit.getName();
if (deployment.getParentDomain() == null)
{
deployment.setDomain(unitName);
log.debug("Will use synthetic domain for classloader of subdeployment:
" + unitName);
}
else
{
log.debug("Will create top level classloader for subdeployment: " +
unitName);
}
}
and out wiki post:
* http://www.jboss.org/community/wiki/useJBossWebClassLoaderinJBoss5
<classloading xmlns="urn:jboss:classloading:1.0"
name="mywar.war"
domain="DefaultDomain"
export-all="NON_EMPTY"
import-all="true">
</classloading>
AbstractClassLoaderDescribeDeployer overrides domain name for this sub-deployment's
ClassLoadingMD, as it has no parent domain specified.
Hence this sub-deployment is always isolated, although it should be part of
DefaultDomain.
--
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
7:03 a.m.
New subject: [JBoss JIRA] Updated: (JBDEPLOY-222) Fix explicit ClassLoadingMetaData in sub-deployment handling
[
https://jira.jboss.org/jira/browse/JBDEPLOY-222?page=com.atlassian.jira.p...
]
Ales Justin updated JBDEPLOY-222:
---------------------------------
Description:
In AbstractClassLoaderDescribeDeployer::deploy
// We only look at non top level deployments that have classloading metadata
if (unit.isTopLevel() == false)
{
if (deployment == null)
return;
// For non top level classloaders, we need to control the domain
// since the parent is the deployment classloader
String unitName = unit.getName();
if (deployment.getParentDomain() == null)
{
deployment.setDomain(unitName);
log.debug("Will use synthetic domain for classloader of subdeployment:
" + unitName);
}
else
{
log.debug("Will create top level classloader for subdeployment: " +
unitName);
}
}
and our wiki post:
* http://www.jboss.org/community/wiki/useJBossWebClassLoaderinJBoss5
<classloading xmlns="urn:jboss:classloading:1.0"
name="mywar.war"
domain="DefaultDomain"
export-all="NON_EMPTY"
import-all="true">
</classloading>
AbstractClassLoaderDescribeDeployer overrides domain name for this sub-deployment's
ClassLoadingMD, as it has no parent domain specified.
Hence this sub-deployment is always isolated, although it should be part of
DefaultDomain.
was:
In AbstractClassLoaderDescribeDeployer::deploy
// We only look at non top level deployments that have classloading metadata
if (unit.isTopLevel() == false)
{
if (deployment == null)
return;
// For non top level classloaders, we need to control the domain
// since the parent is the deployment classloader
String unitName = unit.getName();
if (deployment.getParentDomain() == null)
{
deployment.setDomain(unitName);
log.debug("Will use synthetic domain for classloader of subdeployment:
" + unitName);
}
else
{
log.debug("Will create top level classloader for subdeployment: " +
unitName);
}
}
and out wiki post:
* http://www.jboss.org/community/wiki/useJBossWebClassLoaderinJBoss5
<classloading xmlns="urn:jboss:classloading:1.0"
name="mywar.war"
domain="DefaultDomain"
export-all="NON_EMPTY"
import-all="true">
</classloading>
AbstractClassLoaderDescribeDeployer overrides domain name for this sub-deployment's
ClassLoadingMD, as it has no parent domain specified.
Hence this sub-deployment is always isolated, although it should be part of
DefaultDomain.
Fix explicit ClassLoadingMetaData in sub-deployment handling
------------------------------------------------------------
Key: JBDEPLOY-222
URL: https://jira.jboss.org/jira/browse/JBDEPLOY-222
Project: JBoss Deployers
Issue Type: Bug
Components: classloading
Affects Versions: JBDEPLOY-2.0.8.SP1
Reporter: Ales Justin
Assignee: Adrian Brock
Fix For: JBDEPLOY-2.1.0.Alpha1
In AbstractClassLoaderDescribeDeployer::deploy
// We only look at non top level deployments that have classloading metadata
if (unit.isTopLevel() == false)
{
if (deployment == null)
return;
// For non top level classloaders, we need to control the domain
// since the parent is the deployment classloader
String unitName = unit.getName();
if (deployment.getParentDomain() == null)
{
deployment.setDomain(unitName);
log.debug("Will use synthetic domain for classloader of subdeployment:
" + unitName);
}
else
{
log.debug("Will create top level classloader for subdeployment: " +
unitName);
}
}
and our wiki post:
* http://www.jboss.org/community/wiki/useJBossWebClassLoaderinJBoss5
<classloading xmlns="urn:jboss:classloading:1.0"
name="mywar.war"
domain="DefaultDomain"
export-all="NON_EMPTY"
import-all="true">
</classloading>
AbstractClassLoaderDescribeDeployer overrides domain name for this sub-deployment's
ClassLoadingMD, as it has no parent domain specified.
Hence this sub-deployment is always isolated, although it should be part of
DefaultDomain.
--
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
10:28 a.m.
New subject: [JBoss JIRA] Closed: (JBDEPLOY-222) Fix explicit ClassLoadingMetaData in sub-deployment handling
[
https://jira.jboss.org/jira/browse/JBDEPLOY-222?page=com.atlassian.jira.p...
]
Adrian Brock closed JBDEPLOY-222.
---------------------------------
Fix Version/s: JBDEPLOY-2.2.x
Resolution: Done
You can now explicitly configure a subdeployment to have a top level classloader like
this:
<classloading xmlns="urn:jboss:classloading:1.0"
name="mywar.war"
domain="DefaultDomain"
top-level-classloader="true"
export-all="NON_EMPTY"
import-all="true">
</classloading>
Fix explicit ClassLoadingMetaData in sub-deployment handling
------------------------------------------------------------
Key: JBDEPLOY-222
URL: https://jira.jboss.org/jira/browse/JBDEPLOY-222
Project: JBoss Deployers
Issue Type: Bug
Components: classloading
Affects Versions: JBDEPLOY-2.0.8.SP1
Reporter: Ales Justin
Assignee: Adrian Brock
Fix For: JBDEPLOY-2.1.0.Alpha1, JBDEPLOY-2.2.x
In AbstractClassLoaderDescribeDeployer::deploy
// We only look at non top level deployments that have classloading metadata
if (unit.isTopLevel() == false)
{
if (deployment == null)
return;
// For non top level classloaders, we need to control the domain
// since the parent is the deployment classloader
String unitName = unit.getName();
if (deployment.getParentDomain() == null)
{
deployment.setDomain(unitName);
log.debug("Will use synthetic domain for classloader of subdeployment:
" + unitName);
}
else
{
log.debug("Will create top level classloader for subdeployment: " +
unitName);
}
}
and our wiki post:
* http://www.jboss.org/community/wiki/useJBossWebClassLoaderinJBoss5
<classloading xmlns="urn:jboss:classloading:1.0"
name="mywar.war"
domain="DefaultDomain"
export-all="NON_EMPTY"
import-all="true">
</classloading>
AbstractClassLoaderDescribeDeployer overrides domain name for this sub-deployment's
ClassLoadingMD, as it has no parent domain specified.
Hence this sub-deployment is always isolated, although it should be part of
DefaultDomain.
--
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
6058
days inactive
6061
days old
2 comments
2 participants
participants (2)
-
Adrian Brock (JIRA) -
Ales Justin (JIRA)