From ian.springer at redhat.com Mon Nov 3 10:44:38 2008 From: ian.springer at redhat.com (Ian Springer) Date: Mon, 03 Nov 2008 10:44:38 -0500 Subject: [embjopr-dev] support for view/update of WAR/EAR files In-Reply-To: <490B6A28.5050406@redhat.com> References: <834226233.4856431225319438269.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <490B6A28.5050406@redhat.com> Message-ID: <490F1C66.20207@redhat.com> 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" 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. >>> >>> >>> >>> Please provide your thoughts along with any additional questions you >>> can >>> think of. >>> >>> Thanks, >>> Ian >>> >>> From ccrouch at redhat.com Mon Nov 3 15:20:36 2008 From: ccrouch at redhat.com (Charles Crouch) Date: Mon, 3 Nov 2008 15:20:36 -0500 (EST) Subject: [embjopr-dev] support for view/update of WAR/EAR files In-Reply-To: <490F1C66.20207@redhat.com> Message-ID: <32507084.75351225743636683.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- "Ian Springer" wrote: > > 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). Can't we support what I thought we had in Jopr, I upload any file (with the appropriate extension) and we'll rename it to match the original underlying file. ----- "Ian Springer" wrote: > > We could optionally add an Update History section below the above > that > > would look something like this: If you want to jira this go for it, but lets not spend time implementing it right now. Lets see if people really want it or not. From ian.springer at redhat.com Mon Nov 24 17:58:45 2008 From: ian.springer at redhat.com (Ian Springer) Date: Mon, 24 Nov 2008 17:58:45 -0500 Subject: [embjopr-dev] platform and server nodes in navtree Message-ID: <492B31A5.3040103@redhat.com> It seems that due to the nature of embedded, there will always be a single platform and a single server as a child of that platform. So I think we should get rid of the JBossAS resource type node, which serves no purpose other than to confuse, and have the JBossAS resource node be directly under the platform node. This would also get rid of an entire near-root level of the tree, making it less complex and easier to digest. If we do this, I think we could get rid of PlatformResourceTreeNode and use SingletonResourceTypeTreeNode for both the platform and server nodes. Thoughts? From ccrouch at redhat.com Tue Nov 25 12:23:13 2008 From: ccrouch at redhat.com (Charles Crouch) Date: Tue, 25 Nov 2008 12:23:13 -0500 (EST) Subject: [embjopr-dev] platform and server nodes in navtree In-Reply-To: <2096204674.2045271227630898820.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <1831971456.2067911227633793416.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> See my replies below... Cheers Charles ----- "Ian Springer" wrote: > It seems that due to the nature of embedded, there will always be a > single platform and a single server as a child of that platform. Right now this is correct but it probably won't stay that way. Once we start supporting clusters of JBAS instances there could be multiple servers here. > So I think we should get rid of the JBossAS resource type node, which > serves > no purpose other than to confuse, and have the JBossAS resource node > be > directly under the platform node. This would also get rid of an entire > > near-root level of the tree, making it less complex and easier to > digest. I agree it would be easier to navigate without this extra resourcetype node given there is currently only going to be one server under there. Maybe we could optimize this so the resource type node only appears if there is at least one resource of that type in the hierarchy, or you can manually add more resources. Looking at PlatformResourceTreeNode it definitely looks wrong currently... // Server resources, e.g. JBAS, hang directly off the platform without // an intervening resource type. In order to present these in a "nice way" // in the nav, we add nodes for the resource types of each of the child // resources underneath the platform, rather than just the resources themselves. // The resources in turn will show up under their corresponding resource type nodes Set childResources = getResource().getChildResources(); for (Resource childResource : childResources) { addChildResourceTypeNode(childResource.getResourceType(), getResource()); } But this will create a new resourcetype node for each resource *instance*, so when we start supporting clusters this will not do what we want. How about for childResources where there is only one instance *and* type.isSingleton()==true, then output it straight under the platform. This should cover the case we have today of a single JBAS instance. Otherwise put the childResources under the resourceType (e.g. addChildResourceTypeNode(childResource.getResourceType(), getResource()). That way if you have multiple JBAS instances in the future we can group them together plus if isSingleton()!=true we can use the resourceType node as a holder for add/delete operations as we do for other resource types. > If we do this, I think we could get rid of > PlatformResourceTreeNode and use SingletonResourceTypeTreeNode for > both > the platform and server nodes. > > Thoughts? > > _______________________________________________ > embjopr-dev mailing list > embjopr-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/embjopr-dev From ian.springer at redhat.com Tue Nov 25 14:19:53 2008 From: ian.springer at redhat.com (Ian Springer) Date: Tue, 25 Nov 2008 14:19:53 -0500 Subject: [embjopr-dev] platform and server nodes in navtree In-Reply-To: <1831971456.2067911227633793416.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <1831971456.2067911227633793416.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <492C4FD9.6070502@redhat.com> >> It seems that due to the nature of embedded, there will always be a >> single platform and a single server as a child of that platform. >> > > Right now this is correct but it probably won't stay that way. Once we start supporting clusters of JBAS instances there could be multiple servers here. > > Yeah, I guess it depends how we implemented it. Not having any notion of groups in Embedded, it would be difficult to model clusters. In order to discover JBossAS Resources for other members of the cluster, it would also mean either adding support for remote discovery or for talking to Agents running on other machines. Cluster management might be something we just point people at Jopr for. >> So I think we should get rid of the JBossAS resource type node, which >> serves >> no purpose other than to confuse, and have the JBossAS resource node >> be >> directly under the platform node. This would also get rid of an entire >> >> near-root level of the tree, making it less complex and easier to >> digest. >> > > I agree it would be easier to navigate without this extra resourcetype node given there is currently only going to be one server under there. Maybe we could optimize this so the resource type node only appears if there is at least one resource of that type in the hierarchy, or you can manually add more resources. > > Looking at PlatformResourceTreeNode it definitely looks wrong currently... > > // Server resources, e.g. JBAS, hang directly off the platform without > // an intervening resource type. In order to present these in a "nice way" > // in the nav, we add nodes for the resource types of each of the child > // resources underneath the platform, rather than just the resources themselves. > // The resources in turn will show up under their corresponding resource type nodes > Set childResources = getResource().getChildResources(); > for (Resource childResource : childResources) > { > addChildResourceTypeNode(childResource.getResourceType(), getResource()); > } > > But this will create a new resourcetype node for each resource *instance*, so when we start supporting clusters this will not do what we want. > > How about for childResources where there is only one instance *and* type.isSingleton()==true, then output it straight under the platform. This should cover the case we have today of a single JBAS instance. > Otherwise put the childResources under the resourceType (e.g. addChildResourceTypeNode(childResource.getResourceType(), getResource()). That way if you have multiple JBAS instances in the future we can group them together plus if isSingleton()!=true we can use the resourceType node as a holder for add/delete operations as we do for other resource types. > > > This sounds fine, except did you mean *or* rather than *and*? The JBossAS Resource type isn't a singleton. The other way to go would be to just switch to using SingletonResourceTypeTreeNode for both the platform and the server node for now, and if we need to support multiple server nodes in the future, deal with it at that point. >> If we do this, I think we could get rid of >> PlatformResourceTreeNode and use SingletonResourceTypeTreeNode for >> both >> the platform and server nodes. >> >> Thoughts? >> >> _______________________________________________ >> embjopr-dev mailing list >> embjopr-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/embjopr-dev >> > _______________________________________________ > embjopr-dev mailing list > embjopr-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/embjopr-dev >