Menu
▾
▴
jboss-dev-forums
|
From: vickyk <do-...@jb...> - 2006-07-06 09:07:09
|
Scott,
I have been able to implement this
>>This method should really be removing the war dependency from the service in addition to nulling out all of these variables as the war has been
>>undeployed and should no longer be usable.
The code snippet doing this will look like this
| protected void destroyService()
| {
| try
| {
| ObjectName jmxName = (ObjectName) di.context.get(AbstractWebContainer.WEB_MODULE);
| ServiceControllerMBean serviceController = (ServiceControllerMBean)
| MBeanProxyExt.create(ServiceControllerMBean.class,
| ServiceControllerMBean.OBJECT_NAME, di.getServer());
| serviceController.remove(jmxName);
| }
| catch (Exception e)
| {
| System.out.println("Exception in destroyService"+e);
| }
| this.di = null;
| this.container = null;
| this.deployer = null;
| }
|
>> The redeployment of the properties service
>>would then have no dependent war to start.
Yes this is done when I made the above changes .
The following feature needs to be discusses here .
>>What is really needed is a redeploy notion that
>>would recycle the dependent deployments, but such a notion
>>does not exist.
Now the war which depends on the property service is removed from the nameToServiceMap attribute of the ServiceController. The DeploymentScanner can not figure out that the "WAR" needs to be redeployed as this has not been modified.
So we will have to modify the destroyService() so that it deos
1) Remove the web Deployment From the ServiceController
2) Remove the Deployment From the MainDeployer
3) Recycle the Deployment of the Web application , in case the web is the sub-deployment then we need to recycle the parent deployment .
I propose the changes in the following files
1) org.jboss.web.WebModule
2) org.jboss.deployment.scanner.URLDeploymentScanner
3) org.jboss.deployment.scanner.URLDeploymentScannerMBean
4) org.jboss.deployment.MainDeployerMBean
5) org.jboss.web.AbstractWebContainer
Here goes the changes
org.jboss.web.WebModule
| protected void destroyService()
| {
| try
| {
| ObjectName jmxName = (ObjectName) di.context.get(AbstractWebContainer.WEB_MODULE);
| ServiceControllerMBean serviceController = (ServiceControllerMBean)
| MBeanProxyExt.create(ServiceControllerMBean.class,
| ServiceControllerMBean.OBJECT_NAME, di.getServer());
|
| // Remove the Deployment From the ServiceController
| serviceController.remove(jmxName);
| MainDeployerMBean mainDeployer = (MainDeployerMBean)
| MBeanProxyExt.create(MainDeployerMBean.class,
| MainDeployerMBean.OBJECT_NAME, di.getServer());
|
| // Remove the Deployment From the MainDeployer
| Map deploymentMap = mainDeployer.getDeploymentMap();
| deploymentMap.remove(di.url);
|
| //Recycle the Deployment.
| javax.management.ObjectName OBJECT_NAME=
| org.jboss.mx.util.ObjectNameFactory.create("jboss.deployment:type=DeploymentScanner,flavor=URL");
| URLDeploymentScannerMBean deployerScanner = (URLDeploymentScannerMBean)
| MBeanProxyExt.create(URLDeploymentScannerMBean.class,
| OBJECT_NAME, di.getServer());
| Set deployedSet = deployerScanner.getDeployedSet();
| long timeModifier = System.currentTimeMillis();
| System.out.println("URL is "+di.url);
| deployerScanner.redeployUrl(di,timeModifier);
| }
| catch (Exception e)
| {
| System.out.println("Exception in destroyService"+e);
| }
| this.di = null;
| this.container = null;
| this.deployer = null;
| }
|
org.jboss.deployment.scanner.URLDeploymentScanner
| public Set getDeployedSet()
| {
| return this.deployedSet;
| }
| public void redeployUrl(DeploymentInfo di, long lastModified1)
| {
| //Call Deployer.deploy()
| URL redeployUrl = null;
| DeploymentInfo current = di;
| DeploymentInfo parentDI = di;
| //System.out.println("Before current url ----->"+current.url);
| while(current!=null){
| //System.out.println("After current url ----->"+current.url);
| parentDI = current;
| current = current.parent;
| }
| for (Iterator i = deployedSet.iterator(); i.hasNext();)
| {
| DeployedURL deployedURL = (DeployedURL) i.next();
| URL url = deployedURL.url;
| long deployedLastModified = deployedURL.deployedLastModified;
| long lastModified = deployedURL.getLastModified();
| if(url.equals(parentDI.url))
| {
| System.out.println("Going to Redeploy url ----->"+url);
| //System.out.println("deployedLastModified ----->"+deployedLastModified);
| //System.out.println("lastModified ----->"+lastModified);
| deployedURL.deployedLastModified=lastModified1;
| return;
| //System.out.println("lastModified is set at ----->"+lastModified1);
| }
| }
| }
|
org.jboss.deployment.scanner.URLDeploymentScannerMBean
| java.util.Set getDeployedSet();
| void redeployUrl(DeploymentInfo di,long lastModified);
|
org.jboss.deployment.MainDeployerMBean
| Map getDeploymentMap();
| void setDeploymentMap(Map deploymentMap);
|
org.jboss.web.AbstractWebContainer
| public synchronized void destroy(DeploymentInfo di)
| throws DeploymentException
| {
| ObjectName jmxName = (ObjectName) di.context.get(WEB_MODULE);
| try
| {
| if( jmxName != null )
| {
| serviceController.destroy(jmxName);
| //Changed by Vicky , July 6 2006
| //server.unregisterMBean(jmxName);
| //Changed by Vicky , July 6 2006
| }
| }
| catch (DeploymentException e)
| {
| throw e;
| }
| catch(Exception e)
| {
| throw new DeploymentException("Unable to stop web module", e);
| }
| // Generate an event for the shutdown
| super.destroy(di);
| }
|
Does this make a sense , I have tested these changes seems to be working fix for the JBAS11 and JBAS-1748 .
Please provide your review comments ....
Regards
Vicky
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955763#3955763
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955763
|
|
From: hengels <do-...@jb...> - 2006-07-06 13:10:29
|
Hm, are we solving the class compatibility problems with dependent deployment units, then? Consider two deployment units: A and B, where B depends on A. B holds references to classes from A. Now A gets redeployed -> A2. You'll notice, that B is invalid, cause it still references instances of old A's classloader. You're getting ClassCastExceptions. B has to be redeployed -> B2. B2 will create new instances of A2's new classes. Holger View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955839#3955839 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955839 |
|
From: vickyk <do-...@jb...> - 2006-07-06 14:11:46
|
anonymous wrote : | Consider two deployment units: A and B, where B depends on A. B holds references to classes from A. Now A gets redeployed -> A2. You'll notice, that B is invalid, cause it still references instances of old A's classloader. You're getting ClassCastExceptions. B has to be redeployed -> B2. B2 will create new instances of A2's new classes. | This looks an interesting case, you have the classes in B holding the reference from A . I am not sure if this needs to be considered for fix, as you have a workaround for this. Regards Vicky View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955858#3955858 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955858 |
|
From: <sco...@jb...> - 2006-07-07 17:29:16
|
We can't be redeploying the war from destroy service as this should be causing a redeployment infinite recursion when the war is undeployed. Also, we can't be introducing specific logic into only one deployer. The changes to have dependencies trigger redeployments needs to be handled at the system level with changes to the base ServiceController/SubDeployer logic. This is not much of a priority for 4.x since we are redoing the deployers in the jboss5/mc update. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3956270#3956270 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3956270 |
|
From: vickyk <do-...@jb...> - 2006-07-10 06:28:05
|
>>This is not much of a priority for 4.x since we are redoing the deployers in >>the jboss5/mc update. Is there any place where I can look for the information explaining these design changes ? Are these the major changes in the Deployer Architecture .. >>We can't be redeploying the war from destroy service as this should be >>causing a redeployment infinite recursion when the war is undeployed Let me test this... Are you trying to say that if the web applications are redeployed using this logic it will be causing the infinite recursion ... Regards Vicky View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3956492#3956492 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3956492 |
Thanks for helping keep SourceForge clean.
X