On 1/12/2012 11:39 AM, Alexey Loubyansky wrote:
> I could suggest two ways to workaround this:
>
> - node type as a 'folder', currently the unit is node-type=node-name,
> instead node-type could be a folder that contained node-names and you
> could click on the node-type to add new nodes.
Early on I was going to do it this way, but it became clear that it
would be overly complicated and would break with the directory notion in
the CLI where a directory is /subsystem=jca/, not /subsystem/jca/. Once
you replace = with / you lose sight of the underlying address scheme.
Could the
structure perhaps be
subsystem/
subsystem=jca
subsystem=jmx
Or is that too weird?
> - add node-type=? and use it for add and non-instance specific
> operations. 'add' will still be listed if you right-click on a specific
> instance, though (the same true about the command line actually). We
> could filter those, although that would be covering the weirdness of the
> management model.
I like that idea. I'll give it a try. But I'm thinking the folder will
be "node-type=*" instead of "node-type=?".
WDYT?
That sounds fine although that should only really be done for things with the
add on a wildcard. Also, we haven't solved the problem of things that have expected
children, e.g. the
/subsystem=jmx/connector=jmx where jmx is the ONLY name allowed for the connector. There
are a few other places in the model that have this same setup as well.
> Alexey
>
> On 01/12/2012 04:33 PM, Kabir Khan wrote:
>> Alexey,
>>
>> Can you provide a bit more input on the discussion on
https://github.com/jbossas/jboss-as/pull/1081 but on this thread?
>> On 11 Jan 2012, at 18:08, ssilvert(a)redhat.com wrote:
>>
>>> I believe that add operations are now done correctly as far as the tool
>>> is concerned.
>>>
https://github.com/jbossas/jboss-as/pull/1081
>>>
>>> We needed to prompt for a resource name that gets filled into the
>>> address path. So for:
>>> /subsystem=logging/logger=foo/:add
>>>
>>> The gui asks the user to fill in the resource name "foo". The add
>>> operation should not have "name" as one of its declared parameters
>>> because that would be redundant. (The logging subsystem is doing this
>>> correctly, btw)
>>>
>>> Stan
>>>
>>> On 1/10/2012 3:56 PM, Kabir Khan wrote:
>>>> On 10 Jan 2012, at 20:51, Kabir Khan wrote:
>>>>
>>>>> On 10 Jan 2012, at 18:29, ssilvert(a)redhat.com wrote:
>>>>>
>>>>>> On 1/10/2012 11:30 AM, Kabir Khan wrote:
>>>>>>> That worked for me so I pushed that change. It looks great!
>>>>>>>
>>>>>>> The one thing which is a bit strange is the ability to add a
child resource. e.g. the add operation should really by on the parent of the resource
being targeted. For example, the ee extension has the add operation in its list, which
gives the op: "/extension=org.jboss.as.ee/:add(module=sasasa)". Which is a bit
pointless since it already exists, and there is no way to add a new extension. I had
similar issues when writing the management jmx facade, see ChildAddOperationFinder and its
callers.
>>>>>> Yea, I agree that it's a bit strange. But I'm not sure
if this is a
>>>>>> problem that can be solved by the tool. What I have seen is that
often
>>>>>> you need to give an address that doesn't exist yet, and
append :add to
>>>>>> it. For instance, to add a new logger you say
>>>>>>
>>>>>> /subsystem=logging/logger=foo/:add
>>>>>>
>>>>>> But if you look at subsystem=logging you see that there are many
kinds
>>>>>> of entities that might need to be created (loggers, handlers,
etc.).
>>>>>> That makes it hard for the tool to guess what you are trying to
add.
>>>>> I got around this in the jmx facade. Connect to the running process
with jconsole, and go to the jboss.as:management=server mbean (appears as simply
'server' in the list. This corresponds to the root resource. In the operations it
has an addXXX operation for each child type. e.g.
>>>>>
>>>>> addExtension -> /extension=*:add
>>>>> addSubsystemEjb3 -> /subsystem=ejb3:add
>>>>> addSystemProperty -> /system-property=*:add
>>>>> addSubsystemJaxrs -> /subsystem=jaxrs:add
>>>> Or to use your logging subsystem example, go to
jboss.as:subsystem=logging (appears as just 'logging' in jconsole), and you will
see addSizeRotatingFileHandler, addPeriodicRotatingFieldHandler, addLogger etc.
>>>>
>>>>>> Beyond that, there is no way for the tool to know what params
are
>>>>>> required for a new entity.
:read-operation-description(name=add)
>>>>>> doesn't usually help in this case.
>>>>>>
>>>>>> IMO, each management handler should fully implement the add
operation,
>>>>>> specify the expected params, and never rely on default behavior.
But
>>>>>> that would be a lot of work to go back and fix them all.
>>>>> I'm not 100% sure what you mean here so I might be
misunderstanding what you're saying. The add handlers are different for different
places e.g.:
>>>>>
>>>>> /system-property=*:read-operation-description(name=add)
>>>>> /interface=*:read-operation-description(name=add)
>>>>> /subsystem=jmx:read-operation-description(name=add)
>>>>> /subsystem=ee:read-operation-description(name=add)
>>>>>
>>>>> all return different descriptions. (Some have an add operation for
'*' meaning all children take the same parameters, others one for each child like
the subsystems)
>>>>>
>>>>>> Anyone else have comments/suggestions?
>>>>>>
>>>>>>> On 10 Jan 2012, at 16:16, Kabir Khan wrote:
>>>>>>>
>>>>>>>> I've been out so I didn't see this until my
previous reply, I'll try it now
>>>>>>>>
>>>>>>>> On 10 Jan 2012, at 14:11, ssilvert(a)redhat.com wrote:
>>>>>>>>
>>>>>>>>> Kabir (or someone with OS X),
>>>>>>>>>
>>>>>>>>> Can you give this a try?
>>>>>>>>>
>>>>>>>>>
https://github.com/ssilvert/jboss-as/commit/9f90081c86c54278ec3be444f9fb1...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/10/2012 8:28 AM, ssilvert(a)redhat.com wrote:
>>>>>>>>>> On 1/10/2012 8:06 AM, Kabir Khan wrote:
>>>>>>>>>>> This has been merged. However, I've not
been able to play with it. I added
https://github.com/jbossas/jboss-as/commit/999beb90268d94e4e6547986b7277f... to get
around this problem
>>>>>>>>>> Thanks. I don't have an OS X box, so I
don't have any way to test.
>>>>>>>>>>> The next thing is that right-clicking does
not seem to work on OS X so I don't see the menu
>>>>>>>>>> Looks like this is a well known issue with OS X
and the Swing
>>>>>>>>>> isPopupTrigger() method. What I'm reading
says that you need to hold
>>>>>>>>>> down the control key while pressing button one.
>>>>>>>>>>
http://stackoverflow.com/questions/5736872/java-popup-trigger-in-linux
>>>>>>>>>>
>>>>>>>>>> I'll see if there is a workaround. I'll
probably also add a regular
>>>>>>>>>> menu at the top so we don't have to rely on
right-click.
>>>>>>>>>>> On 10 Jan 2012, at 12:20, ssilvert(a)redhat.com
wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 1/10/2012 4:47 AM, Darran Lofthouse
wrote:
>>>>>>>>>>>>> Do we want to verify the various
security features already in the CLI
>>>>>>>>>>>>> are supported before it is pulled or
follow up once it is in?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Darran Lofthouse.
>>>>>>>>>>>> The GUI is built on top of the CLI. So
it's running the same
>>>>>>>>>>>> authentication/authorization. The only
difference is that it brings up
>>>>>>>>>>>> a GUI instead of a command line.
>>>>>>>>>>>>
>>>>>>>>>>>> BTW, I have to give props to Alexey on
this. His CLI code is extremely
>>>>>>>>>>>> well organized and easy to extend.
>>>>>>>>>>>>> On 01/09/2012 09:42 PM, Jason T.
Greene wrote:
>>>>>>>>>>>>>> You have to merge his pull to get
it
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 1/9/12 3:41 PM, Kabir Khan
wrote:
>>>>>>>>>>>>>>> Does it need to be enabled
somehow?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
[~/sourcecontrol/jboss-as7/git/jboss-as]
>>>>>>>>>>>>>>>
$./build/target/jboss-as-7.1.0.Final-SNAPSHOT/bin/jboss-admin.sh --gui --connect
>>>>>>>>>>>>>>> '--gui' is not a
valid operation name.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
[~/sourcecontrol/jboss-as7/git/jboss-as]
>>>>>>>>>>>>>>>
$./build/target/jboss-as-7.1.0.Final-SNAPSHOT/bin/jboss-admin.sh --connect --gui
>>>>>>>>>>>>>>> '--gui' is not a
valid operation name.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9 Jan 2012, at 19:33,
Jason T. Greene wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Just saw Stan did this:
>>>>>>>>>>>>>>>>
http://community.jboss.org/docs/DOC-17457
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I haven't played with
it yet, but it looks awesome!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> IMO this is exactly what
we need for an "advanced" mode in the console
>>>>>>>>>>>>>>>> (post 7.1 obviously)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Jason T. Greene
>>>>>>>>>>>>>>>> JBoss AS Lead / EAP
Platform Architect
>>>>>>>>>>>>>>>> JBoss, a division of Red
Hat
>>>>>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>>>>>> jboss-as7-dev mailing
list
>>>>>>>>>>>>>>>>
jboss-as7-dev(a)lists.jboss.org
>>>>>>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>>> jboss-as7-dev mailing list
>>>>>>>>>>>>> jboss-as7-dev(a)lists.jboss.org
>>>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>> jboss-as7-dev mailing list
>>>>>>>>>>>> jboss-as7-dev(a)lists.jboss.org
>>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>>>> _______________________________________________
>>>>>>>>>> jboss-as7-dev mailing list
>>>>>>>>>> jboss-as7-dev(a)lists.jboss.org
>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>>> _______________________________________________
>>>>>>>>> jboss-as7-dev mailing list
>>>>>>>>> jboss-as7-dev(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>> _______________________________________________
>>>>>>>> jboss-as7-dev mailing list
>>>>>>>> jboss-as7-dev(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> jboss-as7-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev