[embjopr-dev] support for view/update of WAR/EAR files

[Charles Crouch]

Please see my replies below.

----- "Ian Springer" <ian.springer at redhat.com> wrote:

> Support has been adding in trunk for deploying new WARs and EARs (from
> 
> the parent Resource type's summary page). The next step is adding the
> 
> ability to view and update the backing file for an existing WAR or EAR
> 
> (from the WAR/EAR resource's Content tab). There are a few questions 
> that need to be answered before this can be implemented:
> 
> 1) Do we want to provide an option to download the existing WAR or EAR
> file?

We're not going to be able to do this in cases where the .WAR/.EAR is exploded.
If we can do it conditionally, I guess we could do it for the zipped case.

> 2) Do we want to provide the option to change a zipped deployment to
> an exploded deployment, and vice-verse?

I don't see much benefit of this, people typically want to deploy all the time unzipped (e.g. dev), or all the time zipped (e.g. prod)

> 3) Do we want to provide the option to change the deploy directory
> (e.g. 
> from deploy/ to farm/)?

They should be able to specify where the .WAR/.EAR gets initially deployed, as you can in Jopr. 
After initial deployment if you want to move it you can: download it (using 1 above), undeploy it, then deploy again.

> 4) Do we want to provide the option to change the deployment
> filename?

I know people have asked for something similar before because their .WAR,.EAR contains a version number.
So they would like to deploy myapp-1.0.0.war and then update the file with myapp-1.0.1.war and not have it discovered
as an entirely new resource. I'm not sure this is going to be possible though for the reasons you've outlined regarding the resource key. But maybe this just means we're using the wrong resource key? 
Having an entirely new resource discovered isn't too much of a problem with embedded, except that you would lose any operation history for example, but it would be good to avoid in Jopr.

> 
> My initial thoughts:
> 
> 1) not essential but could be a useful feature
> 2) on the fence here but leaning towards yes
> 3) on the fence here but leaning towards yes
> 4) I'm pretty sure we don't want this, since the filename is part of
> the 
> underlying MBean's ObjectName (e.g. 
> jboss.management.local:J2EEApplication=null,J2EEServer=Local,j2eeType=WebModule,name=jmx-console.war),
> 
> which serves as the resource's key, and we generally try to avoid 
> mutating resource keys. 
> <http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.management.local%3Aj2eeType%3DWebModule%2CJ2EEServer%3DLocal%2CJ2EEApplication%3Dnull%2Cname%3Djmx-console.war>
> 
> Please provide your thoughts along with any additional questions you
> can 
> think of.
> 
> Thanks,
> Ian
> 
> 
> _______________________________________________
> embjopr-dev mailing list
> embjopr-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/embjopr-dev