[jbosstools-dev] Extending the AS Server View

[Rob Cernich]

> cool - pictures!

I've updated the JIRA with additional screenshots of a slightly more polished version. https://issues.jboss.org/browse/JBIDE-10799

> > A preview of the basic structure.  The server content is generated
> > based on read-resource-description and read-resource queries.  As
> > you can see, no localization, and the only action is refresh.
> 
> so this is basically the "raw" output of the management 'tree'
> api/structure in AS7, right?

Yes.  The tree is generated using read-resource-description to determine attribute names and child types for each node.  Then read-resource is used to populate attributes and read-children-names is used to populate the list of resources under each type node (e.g. :read-children-names child-type=subsystem).  That said, if the resource isn't described properly, it won't be displayed properly (e.g. root/subsystems/webservice/endpoint)

> something similar to what jboss-cli --gui -c produces ?
> (btw. the tree in jboss-cli is very weird IMO - its not really
> showing the structure)

I'm not certain.  I've only seen screenshots.  I haven't looked at the actual code.  It did serve as an inspiration though.

> > I'll try to file down the edges and put a patch together.
> 
> I do like we can navigate this tree stuff - but feels more like a
>  raw "debugging" tool
> rather than one to actually show content in a user understandable
> way.
> 
> i.e. instead of having existing deployment's buried under
> root/deployment/* I would
> expect that as a higher level node at a more accessible level.

That root node simply serves to separate this information from other information in the tree.  I don't see any reason why that node couldn't be eliminated from the view.  Regarding my planned work for SwitchYard, I was thinking about modifying the way the "root" is initialized so that another root path could be specified (e.g. /subsystem=switchyard as opposed to "/").

I was also thinking "attributes" might be better displayed in the properties view, since some property types may be more sophisticated than a simple literal.  It also cleans up the tree a bit.

> …not sure how to link the current list of deployments together with
> the actual existing ones..maybe have those
> we  don't have knowledge about being greyed out or something?

It would probably make more sense to grey out the items that are published through the workspace, since they are already visible in the view.

You could do pretty much whatever you want with this.  I was just trying to get something that could serve as a foundation for more tooling.  On that note, I've added a property tester that works well for matching nodes using a management address (e.g. /deployment=.+/subsystem is used to filter the subsystem node under deployments).

Obviously, there's some work that could be done in the area of icons, decorations, etc. to improve the look as well.  The patch attached to the JIRA contains a couple of filters to remove "Extensions" and everything under a deployment artifact (attributes, subsystems and subdeployments).