3:32 a.m.
> 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