Hi, Jeremy
It is by design that we don't generate or delete any files for load and
unload. The file generation and deletion only happens during prepare and
clean phases as part of the deployment and undeployment.
In the case you described, as the cluster was offline when the initial
deployment happens, we could not detect this type of error that time to
roll back. And when the error happens during the cluster starts up
(which is a load for the application), we don't do roll back. So this is
kind of expected behavior with the current design. At that time you
would have to perform an undeploy operation to clean up the application
bits explicitly.
Thanks,
- Hong
On 1/23/2014 6:29 AM, Jeremy Lv wrote:
>
> Hi, Hong, Marina:
>
> Cc: dev:
>
> I have found a strange situationrecentlyin 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
> removedas 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 segmentto 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 : lvsongping_at_cn.fujitsu.com <mailto:lvsongping_at_cn.fujitsu.com>
>
> BLOG : https://www.java.net//author/jeremy-lv
> <https://www.java.net/author/jeremy-lv>
>