platform and server nodes in navtree
by Charles Crouch
See my replies below...
Cheers
Charles
----- "Ian Springer" <ian.springer(a)redhat.com> 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<Resource> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/embjopr-dev
15 years, 5 months
- 2
- 1
platform and server nodes in navtree
by Ian Springer
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?
15 years, 5 months
- 1
- 0
Re: [embjopr-dev] support for view/update of WAR/EAR files
by Charles Crouch
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&name=jb...>
>
> 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
15 years, 5 months
- 2
- 3
- ← Newer
- 1
- Older →