1) I'll create a separate JIRA for the file download capability. After I implement the core functionality, we can decide whether we want to scope this for 1.1. 2), 3) Ok, I am good with not providing the ability to switch between zipped and exploded or to change the deploy directory. As you said, users will typically not need to make either of these changes, and if they do want to do them via the admin console, they can delete the WAR/EAR and then recreate it. Since these are part of the deploy time configuration, which is currently not persisted anywhere, I'm planning to make the 4) Let's not support changing the filename for now, due to the resource key issues. So here's the layout I'm thinking for the Content tab: ----------------------------------------------------------------------------------------------------- foo.war Full Path: C:\opt\jboss-4.2.3.GA\server\default\deploy\foo.war To update the WAR file, select a file path then click Update. Note the specified file must have the same name as the existing WAR file (foo.war). ___________________ [Browse] [Update] ----------------------------------------------------------------------------------------------------- We could optionally add an Update History section below the above that would look something like this: ----------------------------------------------------------------------------------------------------- Update History Update Time Status User =============================================================== Fri, Oct 31, 4:19pm EST Success admin Fri, Oct 31, 10:37am EST Failure admin ----------------------------------------------------------------------------------------------------- I really don't see this providing too much value. It doesn't allow you to revert to the previous versions or even download them, and it is lost when the app server is stopped. It would also require a decent amount of additional work to implement (maybe 4 hours). Let me know your thoughts. For now, I've begun working on the top section of the page as proposed. -Ian On 10/29/2008 6:30 PM, Charles Crouch wrote: > Please see my replies below. > > ----- "Ian Springer&quot;&lt;ian.springer(a)redhat.com&gt; 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&nam... >> >> >> Please provide your thoughts along with any additional questions you >> can >> think of. >> >> Thanks, >> Ian >> >>