[jbosstools-dev] Extending the AS Server View

[Max Rydahl Andersen]

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

cool.

>>> 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)

Yeah, same "problem" exist in cli/cli-gui.

To be clear, I definitely think its relevant to have a "raw-management" view under the AS7 servers.

>> 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.

ok.

>>> 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.

well then we would expose this "raw" view top nodes fully into the server view - it would be very noisy IMO.

Don't you think having the root node is a good thing for the "full raw" stuff ?

>  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 "/").

sure - except that still will expose things 'raw' …. but sure, it could be a nice to have.

> 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.

Yes, fully agreed.

>> …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.

Well the items visible now doesn't really have a natural link to them …. besides their file name.

> 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).

yeah I like the idea.

> 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 sub deployments).

Yeah since you already done this "raw view" I really like to include it for beta.

The biggest issue we still got is the isolation of dmr.jar - as far as I can see you are putting dmr.jar into the core plugin.

Doesn't this mean that when the core plugin actually calls into our as7 services that this dmr.jar content overshadows the dmr.jar found in as7 plugin ? (this becomes important/critical when we get into the situation we were in during as71 dev time - as70 jars didn't work with as71 jars…this specific issue is solved now but once as8 comes we can't be sure).

Because of this we (Rob and I) was discussing if it would make more sense to repackage/rename dmr (i.e. with something like jarjar) and provide that as the way to create non-conflicting model node strings  ?

That for sure eliminates any problem of client jars overshadowing - but of course leaves a problem if as8 changes their dmr syntax….but I think that is unlikely. What can change is the actual operation/subsystem names in as8 but that is possible to abstract out in code much easier than abstracting out client jars.

Another less "intrusive" approach was to put the dmr.jar into an org.jboss.tools.as.dmr bundle that exports the dmr.jar api directly - but I guess if having dmr.jar in .core overshadows then having it in an external plugin that clients uses will result in same problem ? (damn I hate java and osgi class loading rules :)

WDYT? is the problem of overshadowing jars overrated?
 
/max
http://about.me/maxandersen