Looks a lot like the CLI GUI. We should collaborate.

For now we just added the "raw" view but would like to either make this more "beginner user-friendly" or move it over to something like the full blown JMX console we got for "older" AS's where you can do edit operations etc. but for now we just do this "baby" raw console as a read only operation and see where it takes us. /max On Feb 10, 2012, at 19:08, Rob Cernich wrote: >> Looks a lot like the CLI GUI. We should collaborate. > > It was certainly inspired by the CLI GUI, though I haven't had a chance to look at the code yet. The UI piece is probably going to be specific to each (SWT on the Eclipse side, I assume Swing on the CLI side). The model code could be shared, but there's not much there on the Eclipse side: > * a resource node - represents an addressable resource (e.g. /subsystem=switchyard) > * an attributes node - container for attributes defined by a resource > * an attribute node - an attribute value associated with a resource > * a category node - represents a "child-type" defined by a resource (e.g. subsystem). > > The model is built using read-resource-description, read-children-names and read-resource, depending on the node type. > > For me, I was just looking to make sure I had access to the management interface from within Eclipse so I could add some SwitchYard specific capabilities to the Servers View. The "baby console" was just a POC demonstrating the possibilities. > > Best, > Rob > _______________________________________________ > 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 _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Afaik there is no tree browser in console and even if there is then its a webapp with no way to integrate with besides viewing.

> you know eclipse better then me and your concerns about embedding > may > be right. but if you guys could work towards something decoupled > from it's view technology, I might be able to re-use large parts of > it. I certainly think there may be opportunity here from a model perspective. For example, creating higher level types than "resource" (e.g. data source), that encapsulate specific resource types within the server. That said, I'm not sure if there is any support available for the AutoBean framework in Eclipse (knowing the console makes heavy use of AutoBean). If there is, that would certainly simplify adding more detailed capabilities. The model used in the Eclipse POC is simply a model around the low level, generic resource API, nothing more. It's simple, complete, but not very pretty (or usable, in my opinion). Best, Rob _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

> That said, there is a lot of mileage to be gained by simply being able to use the AutoBean framework within Eclipse. Does anyone have any experience using AutoBeans in an Eclipse or OSGi environment? (In SY land, we're slowly moving to a place where our core management/configuration model API can be used in the tooling as well.)

See my previous response. The real problem is the stability of those APIs. No amount of decoupling allows you to instantly see new features or retract removed features, unless you're putting together a dynamic GUI, which is then limited in its usability (e.g. generic JMX consoles, generic WS testers, etc.; they get the job done, they adapt nicely, but they aren't very pretty). Best, Rob _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

> Does the API allow decoupling ? (i.e. one option is the plugin to > load dynamically the runtime jars from the targeted runtime) See my previous response. The real problem is the stability of those APIs. No amount of decoupling allows you to instantly see new features or retract removed features, unless you're putting together a dynamic GUI, which is then limited in its usability (e.g. generic JMX consoles, generic WS testers, etc.; they get the job done, they adapt nicely, but they aren't very pretty).

> I know very little about AutoBean framework so cannot say how/if it > will work. The framework creates a dynamic proxy for a bean interface which is backed by JSON, and can serialize object instances to JSON. The shared component would be the interfaces. The nice bit here is that it really simplifies the task of converting to/from JSON (much easier than managing ModelNode objects).

> What I'm most worried about though is any eclipse tooling that > hard-binds/limits itself to specific versions of runtimes/admin > apis. You cannot avoid this problem.

Ideally, the best solution is to have well defined rules regarding the evolution of the API. In my opinion, the management model should be treated no differently than any other public API provided by the server.

Back in the real world, this may require tooling specific to each version. (The tooling is different between AS 5 and 7.)

> Will this allow you to support multiple versions better or worse ? No difference here. If the API changes between releases, you're stuck either way. (Although, it may be better. Because the framework simply proxies back to JSON, added structure will be invisible and removed structure will be null; i.e. you won't really see the changes. It may be odd for the user, wondering why some setting appears to be ignored, but...)

> What I understand is you would be using/linking with the Admin > console code which would tie you 100% to a specific version ... that > sounds like a bad approach to me ? Actually, you would be tied to an API specific to the management structure for each version of the runtime. The console and other bits of tooling would depend upon that API. If the API is stable between releases, then all is well. If the API changes, then the console and other bits of tooling will need to be updated.

This is really no different than depending on any other API, like Eclipse or OSGi.

Those just happen to have a well defined process for managing the evolution of their API, which is the crux of the problem here.

That said, having a specific project(s) for a management model(s) might help ensure the stability of the API.

Sent from my iPhone On Feb 29, 2012, at 12:23 PM, Rob Cernich <rcernich(a)redhat.com&gt; wrote: >> I know very little about AutoBean framework so cannot say how/if >> it >> will work. > > The framework creates a dynamic proxy for a bean interface which is > backed by JSON, and can serialize object instances to JSON. The > shared component would be the interfaces. The nice bit here is > that it really simplifies the task of converting to/from JSON > (much easier than managing ModelNode objects). That's a subjective argument. The amount of code to build a DMR request is roughly equivalent to the amount used with static javabeans. The trade-off is giving up nice compiler static typing in favor of being able to handle forward and backwards compatibility, supporting dynamic clients, and being friendly to detyped languages.

The first management prototype was static and attempted to solve these issues part way, but it turned out to not only fall short but was also cumbersome from a long term maintenance standpoint. A client had to have a jar for every subsystem that it potentially used, so you factor in the limitations of the Java type system, which leads to multiple additional interfaces or multiple jars for multiple versions and it gets messy pretty quickly.

I have always thought a stub compiler based on DMR descriptions would be a nice way to bring back static typing without hampering the model. A nice side project for someone...

>>>> I know very little about AutoBean framework so cannot say how/if >>>> it >>>> will work. >>> >>> The framework creates a dynamic proxy for a bean interface which >>> is >>> backed by JSON, and can serialize object instances to JSON. The >>> shared component would be the interfaces. The nice bit here is >>> that it really simplifies the task of converting to/from JSON >>> (much easier than managing ModelNode objects). >> >> That's a subjective argument. The amount of code to build a DMR >> request is roughly equivalent to the amount used with static >> javabeans. The trade-off is giving up nice compiler static typing >> in >> favor of being able to handle forward and backwards compatibility, >> supporting dynamic clients, and being friendly to detyped >> languages. > > It certainly is subjective, but my preference is: > > String foo = bar.getFoo() > > over: > > String foo; > if (barNode.hasDefined("foo") > foo = barNode.get("foo").asString(); > else > foo = null; > > The notion of static typing is more philosophical. (I won't start > a philosophical debate.) This is all good as long as there are ways to handle: if (runtime.supportsX()) { node.doX(); } else { node.doY(); } And that you can have doX() and doY() even if the schema for the latest version only contains support for doX(). >> The first management prototype was static and attempted to solve >> these issues part way, but it turned out to not only fall short >> but >> was also cumbersome from a long term maintenance standpoint. A >> client had to have a jar for every subsystem that it potentially >> used, so you factor in the limitations of the Java type system, >> which leads to multiple additional interfaces or multiple jars for >> multiple versions and it gets messy pretty quickly. > > That is true, but now one is coding directly against the schema. > If the schema changes, I may not need to rebuild, but if "foo" > becomes "fu" it's broken either way. Now I need to scour my > source for instances of "foo" and change it to "fu," but luckily > I've wrapped all my ModelNode manipulation with my own API > (whether that's static string variables or something more > sophisticated), so my search scope is limited. (Add arguments for > or against static typing...) > > I can see where this would be burdensome if changes were made to a > part of the schema that you weren't using. (Then again, the > classes associated with those areas would never be loaded, so it > wouldn't matter whether I rebuilt my library or not.) > > The real benefit here is that the provider is free to change the > structure without worrying about breaking clients, or requiring > them to recompile. However, if the client is impacted by the > changes, they'll be forced to update their library anyway. And > maintenance is pushed onto them by forcing them to accommodate for > various versions of the schema. Continuing the example: > > String foo; > if (bar.hasDefined("fu")) > foo = bar.get("fu").asString(); > else if (bar.hasDefined("foo")) > foo = bar.get("foo").asString(); > else > foo = null; > > (Perhaps too trivial an example, as it's more likely that > structural changes will occur, as opposed to simple name changes, > but it illustrates the point.) Yes - so can you support/handle such changes via AutoBeans ?

>> I have always thought a stub compiler based on DMR descriptions >> would >> be a nice way to bring back static typing without hampering the >> model. A nice side project for someone... > > While it may not generate the code for you, the AutoBean framework > allows you to wrap the underlying JSON with an API. Continuing > the above example: > > interface Bar { > String getFoo(); > void setFoo(String value); > } > interface BarBeanFactory extends AutoBeanFactory { > AutoBean<Bar> newBar(); > } > Bar bar = AutoBeanCodex.decode(barBeanFactory, Bar.class, > barNode.toJSONString(true)).as(); > > In my original post, I was simply asking if anybody had attempted > to use the AutoBean framework outside a GWT environment and > whether or not it would be beneficial to reuse a set of interfaces > representing management objects (e.g. interface Bar above). It > sounds like the answer to the latter is, "We advise against that." For the question on usage within AutoBean then my reading on it sounds like it should technically be doable (you might need to use eclipse buddyclassloading to make it work since the fwk need to load user classees - I didn't find a way to set the classloader used but that might just be me not looking closely enough). But sharing classes with runtime specific binaries I do advise against by default since it more often than not cannot be encapsulated to allow the client to use multiple versions without a massive hassle. /max

> The notion of static typing is more philosophical. (I won't start a philosophical debate.) No one can deny the technical benefits of static typing and you certainly don't have to convince me of them. My point was that as with anything there are trade offs. Java's type model isn't flexible enough to meet the requirements for compatibility and dynamicity that we needed in the management API.

[snip...] >> While it may not generate the code for you, the AutoBean framework >> allows you to wrap the underlying JSON with an API. Continuing >> the above example: >> >> interface Bar { >> String getFoo(); >> void setFoo(String value); >> } >> interface BarBeanFactory extends AutoBeanFactory { >> AutoBean newBar(); >> } >> Bar bar = AutoBeanCodex.decode(barBeanFactory, Bar.class, >> barNode.toJSONString(true)).as(); > > I take it this imposes a particular data format? Yes. JSON.

Embedding webui is crapy.

Which is why we link To the console and show in browser externally or embedded. We deliberately try not to depend Nor duplicate the console.

For now we just added the "raw" view but would like to either make this more "beginner user-friendly" or move it over to something like the full blown JMX console we got for "older" AS's where you can do edit operations etc. but for now we just do this "baby" raw console as a read only operation and see where it takes us. /max On Feb 10, 2012, at 19:08, Rob Cernich wrote: >> Looks a lot like the CLI GUI. We should collaborate. > It was certainly inspired by the CLI GUI, though I haven't had a chance to look at the code yet. The UI piece is probably going to be specific to each (SWT on the Eclipse side, I assume Swing on the CLI side). The model code could be shared, but there's not much there on the Eclipse side: > * a resource node - represents an addressable resource (e.g. /subsystem=switchyard) > * an attributes node - container for attributes defined by a resource > * an attribute node - an attribute value associated with a resource > * a category node - represents a "child-type" defined by a resource (e.g. subsystem). > > The model is built using read-resource-description, read-children-names and read-resource, depending on the node type. > > For me, I was just looking to make sure I had access to the management interface from within Eclipse so I could add some SwitchYard specific capabilities to the Servers View. The "baby console" was just a POC demonstrating the possibilities. > > Best, > Rob > _______________________________________________ > 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

> BTW, is it impossible to run Swing code from inside Eclipse? I believe it's possible, but I don't think it's very pretty. The biggest problem is that the underlying windowing systems are very different between the two: SWT rides the OS, while Swing provides its own. All SWT controls are either native controls or built using native controls. That said, I've never attempted this, never researched and never seen it done. (I don't get out much though. ;) ) _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Contributed by Rob Cernich. work in progress - feedback welcome ;) /max http://about.me/maxandersen _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk81V3EACgkQU4HO8G8hNxUiMgCfSNHxcXI5Bl4WIb01EoE2DTui 06oAoOHSzas1KhCLyrc0Te1A+0wHbT2g =4BUu -----END PGP SIGNATURE-----