3:27 p.m.
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(a)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&nam...
>
> Please provide your thoughts along with any additional questions you
> can
> think of.
>
> Thanks,
> Ian
>
>
> _______________________________________________
> embjopr-dev mailing list
> embjopr-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/embjopr-dev
_______________________________________________
embjopr-dev mailing list
embjopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/embjopr-dev