Anissa Lam wrote On 04/22/07 01:10 AM,:
>
> While waiting for the meeting with Sankara, let me give a little
> history of the management rule screen in GUI. The screens layout and
> callflow were designed only expecting the six predefined event types.
> <!ENTITY % event-type "(log | timer | trace | monitor | cluster |
> lifecycle | notification)">
>
> So, to answer Bill's question
>
>> Did you implement the GUI assuming there would never be any other
>> event types?
>
> We were told to support these 6 event types. If there will be other
> event types in the future, its true that we may have to redesign the
> screen at that time.
> The management rule screens were the most complicated set in the GUI,
> and came together with the input of Sankara, HIE and the management
> team at that time after going through many iterations.
Did Kedar and Sreeram approve of this use of properties even though it
is an explicit violation of their rules for attributes vs. properties?
Or did one team simply not know about the work of the other?
> The only change in GUI for the management rule screen for v2 is to
> change the text box with calendar component for the date-string in
> the timer event. Due to the limitation of calendar component and the
> fact that there is the pattern properties, we will need to change back
> to use text box as in v1, and thats what triggers this thread.
>
> June seems to indicate that the properties of the management rules has
> changed quite a bit. The GUI hasn't changed since Glassfish v1, so
> what we have now in v2 is the same as in v1.
Then the initial communication failure occurred during the v1
timeframe. I asked for a review of the event element description at
least twice and no one caught the errors.
> We were never told of any changes in the management rule area. Since
> GUI is able to support the out-of-box sample management rule, i
> believe what GUI has currently is correct.
I'm not saying that the GUI is incorrect. I'm saying 1) someone didn't
tell the doc team about the properties, and 2) the properties should
have been attributes.
Further, if Bill Shannon wants more flexibility in the future, we should
take a completely different approach and use MBeans, because anything
that ends up hard-coded in the GUI would seem to be inflexible by
definition.
June
> There seems to be lots of questions regarding mangement rule, Sankara
> will have to answer that.
>
> thanks
> Anissa.
>
> Senthil Chidambaram wrote:
>
>> Ken,
>> Sure, I'll try to schedule up a meeting with him on Monday. I'll post
>> the meeting details in this alias.
>>
>> thx
>> Senthil
>>
>> Ken Paulsen wrote:
>>
>>>
>>> Senthil,
>>>
>>> I think we have more questions than answers, can you plan on talking
>>> to Sankara to find out exactly what should be supported / is
>>> required from the GUI? If he has some example use cases, that would
>>> be great. Let me know if you'd like me to join the conversation.
>>>
>>> Thanks,
>>>
>>> Ken
>>>
>>>
>>> Senthil Chidambaram wrote:
>>>
>>>> I was fixing a bug on this screen that's when I found out the
>>>> problem on the calendar component. I believe this screen was
>>>> implemented by Nitya to begin with, in consultation with Sankara in
>>>> IEC. I can check with Anissa, and see whether we've to redo this
>>>> screen to support unknown event types, and I want Sankara to
>>>> confirm whether unknown types are supported. I'm cutting, and
>>>> pasting the two lines from
>>>> https://glassfish.dev.java.net/javaee5/selfmanagement/selfmanagementhome.html
>>>>
>>>>
>>>> "An event triggers the action to be executed. A set of events are
>>>> provided by default with the glassfish and user could extend the
>>>> events by using JMX Notification mechanism".
>>>>
>>>> The above line indicates to me that users could extend events. If
>>>> we've to redo this screen to support unknown event typest, it's not
>>>> difficult to do. We've to provide a properties table for users to
>>>> add properties as name/value pairs.
>>>>
>>>> thx
>>>> Senthil
>>>>
>>>> Bill Shannon wrote:
>>>>
>>>>> Senthil Chidambaram wrote:
>>>>>
>>>>>> Bill Shannon wrote:
>>>>>>
>>>>>>> Senthil Chidambaram wrote:
>>>>>>>
>>>>>>>> The six supported event types by GF can be extended. This is
>>>>>>>> what the document says, and that's how GUI is implemented.
>>>>>>>> Sankara has to confirm this.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If the DTD only allows the six types, how can I add a new type?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> You can't add a new type in the current screen flow. GUI is
>>>>>> implemented for the six supported types.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> First you say I can add a new type and then you say I can't.
>>>>> No wonder I'm confused!!! :-)
>>>>>
>>>>> Did you implement the GUI assuming there would never be any other
>>>>> event types?
>>>>>
>>>>> Or do you plan to completely redo the GUI in the future to support an
>>>>> open ended set of event types?
>>>>>
>>>>> Was it faster or easier to implement a GUI for six built-in types
>>>>> than
>>>>> to implement a GUI for an extensible set of types?
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>