Re: [embjopr-dev] platform and server nodes in navtree
> 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<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.
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(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