Hi, Hong, Marina:
Cc: dev:
I have found a strange situation recently in failing deploy the ejb
application:
Here’s my reproduced steps to reproduce this phenomenon:
1) asadmin start-domain
2) asadmin create-cluster clu1
3) asadmin create-instance -cluster clu1 ins1
4) asadmin deploy --target clu1 compositeweb-ejb.jar
5) Confirm whether there’s no file called compositeweb-ejb exist under the
directory of GF_HOME\nodes\localhost-domain1\ins1\generated\policy
6) asadmin start-cluster clu1
7) The file called compositeweb-ejb has been generated under the directory
of GF_HOME\nodes\localhost-domain1\ins1\generated\policy but hasn’t been
removed even it is failed in loading the ejb application
On the other hand, if you failed in deploying the ejb application after the
cluster has been started, the file called compositeweb-ejb under the
directory of GF_HOME\nodes\localhost-domain1\ins1\generated\policy will be
removed as expected:
1) asadmin start-domain
2) asadmin create-cluster clu1
3) asadmin create-instance -cluster clu1 ins1
4) asadmin start-cluster clu1
5) Confirm whether there’s no file called compositeweb-ejb exist under the
directory of GF_HOME\nodes\localhost-domain1\ins1\generated\policy
6) asadmin deploy --target clu1 compositeweb-ejb.jar
7) The file called compositeweb-ejb has been generated under the directory
of GF_HOME\nodes\localhost-domain1\ins1\generated\policy when loading the
application and it will be removed because of the failure of deploying the
ejb applications
【Conclusion】
After Looking into the method of EjbDeployer.clean(DeploymentContext), you
will found the following related code segment to illustrate the reason why
the scenario is different:
//Security related cleanup is to be done for the undeploy event
◆ if( params.origin.isUndeploy()|| params.origin.isDeploy()) {
//Removing EjbSecurityManager for undeploy case
String appName = params.name();
String[] contextIds =
ejbSecManagerFactory.getContextsForApp(appName, false);
if (contextIds != null) {
for (String contextId : contextIds) {
try {
//TODO:appName is not correct, we need the module
name
//from the descriptor.
probeProvider.policyDestructionStartedEvent(contextId);
◆ SecurityUtil.removePolicy(contextId);
// It will remove the policy file it this code has been executed.
probeProvider.policyDestructionEndedEvent(contextId);
probeProvider.policyDestructionEvent(contextId);
} catch (IASSecurityException ex) {
_logger.log(Level.WARNING, "Error removing the
policy file " +
"for application " + appName + " " + ex);
}
ArrayList<EJBSecurityManager> managers =
ejbSecManagerFactory.getManagers(contextId,
false);
if (managers != null) {
for (EJBSecurityManager m : managers) {
m.destroy();
}
}
}
}
//Removing the RoleMapper
SecurityUtil.removeRoleMapper(dc);
}
(1). If you start the cluster after the ejb and web application had been
deployed, the value of params.origin will be “load” and it will return
false when execute “if( params.origin.isUndeploy()||
params.origin.isDeploy())”. The SecurityUtil.removePolicy(contextId) won’t
be executed, this is the reason why the policy can’t be removed when
execute the rollback action.
(2). I have also confirmed that if you deploy the web or ejb application
after the cluster is started, the value of params.origin will be
“deploy_instance” and it will return true when execute “if(
params.origin.isUndeploy()|| params.origin.isDeploy())”. Then it will
execute the SecurityUtil.removePolicy(contextId) to remove the related
policy file.
【The Key point question】
Why the scenario in rollback action is different between load and deploy the
ejb application, why remove the policy file when failed in deploying the ejb
application after cluster has been started but still keep the policy while
starting the cluster after the ejb application has been deployed.
【Conclusion】
I don’t know whether it is the right scenario or it is a bug, In my human
option, I think it is a bug,The policy file should be removed during the
rollback action both in failing loading the application and deploying the
application to consist these two different scenario.
Please also let me know if it is a right scenario.
Thanks a lot!
Best regards
Jeremy Lv
--------------------------------------------------
Lv Songping
Software Division II
Development Department I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
ADDR.: No.6 Wenzhu Road, Software Avenue,
Nanjing, 210012, China
TEL : +86+25-86630566-9327
COINS: 7998-9327
FAX : +86+25-83317685
MAIL : <mailto:lvsongping_at_cn.fujitsu.com> lvsongping_at_cn.fujitsu.com
BLOG : <
https://www.java.net/author/jeremy-lv>
https://www.java.net//author/jeremy-lv