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

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 >

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

On 1/10/2012 7:43 AM, Darran Lofthouse wrote: > > On 01/10/2012 12:20 PM, 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. > Where do the username / password prompts or the SSL certificate prompts > currently show up? Is this within the GUI or still on the command line? Right now you have to connect from the command line when you start jboss-admin. You have to at least pass the --connect parameter. >> 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

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

The next thing is that right-clicking does not seem to work on OS X so I don't see the menu

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

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

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.

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

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

> 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

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

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.

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

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

I still don'

On 12 Jan 2012, at 17:14, ssilvert(a)redhat.com wrote: > 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 _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

> 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

On 12 Jan 2012, at 19:39, ssilvert(a)redhat.com wrote: > On 1/12/2012 1:09 PM, Kabir Khan wrote: >>> 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? > I just tried that and it did indeed get weird. You end up with nodes > that don't have any correspondence to the address path. So you have to > code around it all over the place. It also made any sort of refresh > impossible to implement without significant hacks. I do need to improve > refresh at some point and I don't want to make that any harder than it > already is. > > Try my three latest commits found here and let me know what you think: > https://github.com/ssilvert/jboss-as/commits/cli-gui-fixadd > > Alexey, once you see it, let me know if you still think that "?" makes > more sense than "*". That's an easy change. It looks better, perhaps instead of * or ? some descriptive string (that will not crash with any names used, so something like ***Root***) could work. Just an idea, not sure if it is a good or bad one...

I think the adds on the actual real nodes, e.g. extension=org.jboss.as.pojo, subsystem=someproperty etc. are a bit confusing now that we have the one mentioned above.

Likewise the adds on the subsystem nodes should not be there, they are wrong, since each subsystem has a different add handler, most of them taking parameters specific to that subsystem.

I thought I had sent the below to the list but I see I just sent it to Alexey not. Basically, it is impossible to add anything to something that has an add handler on a non-wildcard node, such as the subsystems: <mail> On 12 Jan 2012, at 18:57, Alexey Loubyansky wrote: > But these don't appear to be a part of the management model. According > to the model :) Let's fix the model, I'd say. Unless I'm missing > something... I think that is against how the controller works, e.g.: [domain@localhost:9999 /] /subsystem=jmx:read-resource(recursive=true) { "outcome" => "success", "result" => { "connector" => undefined, "show-model" => true } } If we add the jmx child we'll have something defined for connector=>jmx, but then if it is removed that node is removed from the model so we end up with ^ again. Or in the case of subsystems, I don't think we want loads of subsystem=>mysubsystem => undefined entries, when they have not been initialized. </mail> Perhaps a similar node as the one you have added for the non-wildcard case could work, which when opening the context menu looks for child add operations from read-resource-description? So you right-click on subsystem=***Root*** (or whatever we want to call it) and then you get add-jmx, add-ee etc.

On 1/12/2012 7:15 PM, Kabir Khan wrote: > On 12 Jan 2012, at 19:39, ssilvert(a)redhat.com wrote: > >> On 1/12/2012 1:09 PM, Kabir Khan wrote: >>>> 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? >> I just tried that and it did indeed get weird. You end up with nodes >> that don't have any correspondence to the address path. So you have to >> code around it all over the place. It also made any sort of refresh >> impossible to implement without significant hacks. I do need to improve >> refresh at some point and I don't want to make that any harder than it >> already is. >> >> Try my three latest commits found here and let me know what you think: >> https://github.com/ssilvert/jboss-as/commits/cli-gui-fixadd >> >> Alexey, once you see it, let me know if you still think that "?" makes >> more sense than "*". That's an easy change. > It looks better, perhaps instead of * or ? some descriptive string (that will not crash with any names used, so something like ***Root***) could work. Just an idea, not sure if it is a good or bad one... I'm thinking of using a different icon to set it apart.

> I think the adds on the actual real nodes, e.g. extension=org.jboss.as.pojo, subsystem=someproperty etc. are a bit confusing now that we have the one mentioned above. If we remove "add" from the real nodes should we also remove read-operation-description, read-resource-description, and read-operation-names? All those are generic to the resource type and not to a specific resource.

> Likewise the adds on the subsystem nodes should not be there, they are wrong, since each subsystem has a different add handler, most of them taking parameters specific to that subsystem. Sounds like a problem with the metadata.

> I thought I had sent the below to the list but I see I just sent it to Alexey not. Basically, it is impossible to add anything to something that has an add handler on a non-wildcard node, such as the subsystems: > <mail> > On 12 Jan 2012, at 18:57, Alexey Loubyansky wrote: >> But these don't appear to be a part of the management model. According >> to the model :) Let's fix the model, I'd say. Unless I'm missing >> something... > I think that is against how the controller works, e.g.: > [domain@localhost:9999 /] /subsystem=jmx:read-resource(recursive=true) > { > "outcome" => "success", > "result" => { > "connector" => undefined, > "show-model" => true > } > } > > If we add the jmx child we'll have something defined for connector=>jmx, but then if it is removed that node is removed from the model so we end up with ^ again. > > Or in the case of subsystems, I don't think we want loads of subsystem=>mysubsystem => undefined entries, when they have not been initialized. > </mail> > Perhaps a similar node as the one you have added for the non-wildcard case could work, which when opening the context menu looks for child add operations from read-resource-description? So you right-click on subsystem=***Root*** (or whatever we want to call it) and then you get add-jmx, add-ee etc. > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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.

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

> 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

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

Fantastic really! And a complete surprise, to me at least. Stan didn't ask (for) anything. Just did it :) Thanks, Stan! Alexey On 01/09/2012 08:33 PM, 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) > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Nice! ….now who wants to implement the SWT version to embed in eclipse ? :) /max On Jan 9, 2012, at 20: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 /max http://about.me/maxandersen