-
2. Re: Mbean attributes
There are couple of ways to handle this:
1) You define different editor objects for different user defined types that are exposed in the management interface. So for instance, an URL object would map into an editor javabean that takes a string and validates the input as a correct URL format.
Since you cannot know all user defined types you need to provide a way in your GUI to plugin new editor types
2) Look at how JavaBeans spec handled the automatic visualization of JavaBean properties in the BeanBox implementation. Essentially you require that all user defined types are JavaBeans (default no args constructor and follow the set/get accessor convention) and introspect these objects to find out the basic field types they consist of (primitives + common objects such as java.net.URL or java.util.Dates).
In this way you can automatically build a panel that requires user to fill in the fields necessary to create and initialize the custom object.
3) Allow the MBean itself to instruct how its visual representation should be created. Pick a well established GUI description format (XForms being the strongest candidate) and allow the MBean to attach this XML as part of its metadata. Then render the GUI component based on the description given in the XForms docu instance. This has the added benefit of possibly being rendered automatically by a web console in future browser incarnation.
4) Require strict Open MBean compliance. This would work but will lead to a very poor user interfaces I'm afraid.
--
The different approaches are not mutually exclusive. You can start from 1 and progress to 3 and add different level of support as you go. You can have your GUI with "hard coded" Java editors for specific types, down to primitives, as the fallback option, you can allow the user to override this by providing "hard coded" Java GUI components for specific types or support MBean defined XForms instructions which allows a GUI designer to provide an XML instance without having to write or compile any Java code and a combination of all the above.
Basically this same problem was already encountered and at least partly tackled with the JavaBean component specification and how to visualize JavaBeans, so most IDE's should have some type of approach to this problem. You should probably look at a couple of approaches to find some ideas.