Ken Paulsen wrote:
>
> Hi Sreeni,
>
> Thanks for sending this out.
>
> In order to proceed, I think we need to decide on the interface
> between JSFT's LDM and the POJO. First the LDM needs to "find" the
> POJO. How do you propose we do this? Assuming that NO gui code is
> written for this page, the URL itself will need to locate the POJO.
> This may mean the URL has some encoded version of the ObjectName, or
> do you have another idea?
One approach is to use HK2 infrastructure to discover the POJO when it
comes into existence. I'll have to discuss this with Koshuke to provide
more details.
By URL, do you mean hard coding the mBean ObjectName ?
>
> After it is found, or some reference to it is found, how do we get
> information from it? Should we use Class.getAnnotations()? And
> similarly for Methods? Or will there be a reference (facade) to the
> POJO that extracts this information and provides some API for us to use?
To start with, I expect it to read the annotations directly.
>
> Another concern that I have is keeping GlassFish specific API's out of
> JSFTemplating. I think we can achieve this, but keep this in mind
> while thinking about how this works. This may mean that JSFT provides
> an interface which it uses to walk the data, and a concrete
> implemenation of that interface exists in the GlassFish GUI codebase
> which is able to interact more directly with backend GlassFish code.
>
Sure, we'll maintain the separation as appropriate.
> On the JSFT side, we need to consider what to do with this
> information. We need to have a way to map an output-only or i/o
> component to a concrete JSF component. Also, we should be able to
> specify some config information describing default templates and maybe
> a means to override that template for particular "viewId's."
>
You know best :-)
> Let's use the example you wrote and see if we can get this working.
>
> Sreeni, let me know how you'd like to proceed in addressing these
> issues. I'm open to meeting via irc, phone, or email. In the mean
> time, I am going to think about this some more...
I'll get back once I have mored details on hooking up LDM with POJO.
>
> Thanks!
>
> Ken
>
> Sreenivas Munnangi wrote:
>
>> Hi,
>>
>> In the first place, I would like to congratulate you on your efforts
>> and making JSF Templating popular.
>> I am glad to be involved with this forum and send the attached
>> proposal for making JSF Templating even more useful and popular.
>>
>> You may see from the proposal that basically what I am proposing for
>> is to discover the annotations on a POJO, create corresponding GUI
>> and enable the runtime management.
>>
>> Please let me know your comments/suggestions and what it would take
>> to make this happen.
>>
>> Thanks,
>> Sreeni.
>>
>>
>>
>>
>>
>>> Proposal for exposing Management Info through JSF Templating.
>>> -------------------------------------------------------------
>>> Sreenivas Munnangi, 29jan08
>>>
>>> GlassFish V3 is based on modular architecture and provides for
>>> extensibility by enabling integration of external modules. These
>>> modules would like to be managed and monitored the same way
>>> GlassFish V3 does. To facilitate the runtime management, the
>>> external module will expose its management thru GUI so that the user
>>> experience is uniform.
>>>
>>> One approach is to ask the developer to come up with all the GUI
>>> code by himself so that it intergates into GlassFish V3 GUI. And an
>>> easier appraoch for simple CRUD functionality would be to ask the
>>> developer to annotate the POJO and discover those annotations at
>>> compile time or runtime and generate the GUI code ourselves instead
>>> of burdening the developer and I am sure many developers will love
>>> such a facility.
>>>
>>> For example, consider the following POJO and its interest in being
>>> exposed in GUI through the annotation @GUI
>>>
>>> @RuntimeMgmt
>>> @GUI
>>> public class MangeNewModule {
>>>
>>> @ManagedAttribute
>>> public int getCacheSize() {...}
>>>
>>> @ManagedAttribute
>>> public void setCacheSize(int size) {...}
>>>
>>> @ManagedAttribute
>>> public String getModuleName() {...}
>>>
>>> @ManagedOperation
>>> public void start() {...}
>>>
>>> @ManagedOperation
>>> public void stop() {...}
>>>
>>> @ManagedOperation public void refresh(Integer minThreshold,
>>> Integer maxThreshold) {...}
>>> }
>>>
>>> Corresponding to the above annotations, the GUI is expected to
>>> display the following and allow for the update appropriately.
>>>
>>> ------------------------------------------------------
>>> ManageNewModule:
>>>
>>> CacheSize: ____ <update>
>>>
>>> ModuleName: ____
>>>
>>> <start>
>>>
>>> <stop>
>>>
>>> MinThreshold: ____ MaxThreshold: ____ <refresh>
>>> ------------------------------------------------------
>>>
>>> - CacheSize can be updated because it has setter and getter methods
>>> - ModuleName cannot be updated because it doesn't have a setter
>>> - start and stop methods need to be invoked without any parameters
>>> - refresh method needs to be invoked with 2 parameters, minimum and
>>> maxmimum thresholds.
>>> Above is a simple scenario for us to get started and I am sure
>>> several improvements will be possible as we progress. Some of them
>>> include representing complex data types, and describining
>>> annotations in more detail to enable Rich Interface.
>>>
>>
>>