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

[Ian Springer]

Oops, I left off the end of the last sentence in item 2), 3) below. Here 
it is:

I'm planning to make the file path and exploded flag traits, so they can 
be viewed on the summary/metrics tabs. Then we won't need to worry about 
reporting that info via the content APIs.

On 10/31/2008 4:27 PM, Ian Springer wrote:
> 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"<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
>>>
>>>