Bill,
See my response inline...
Bill Shannon wrote:
> Anissa Lam wrote:
>
>>
>> The Timer event is one of the predefined events for triggering
>> actions. This is part of the self management framework that has been
>> available since GlassFish v1.
>>
>>
>> Timer events
>>
>> The event type is "timer". The Notification subclass is
>> javax.management.timer.TimerNotification.
>> Required property:
>> "datestring", possible values: String - mm/dd/yyyy hh:mm:ss
>> Optional properties are
>> "pattern" if the date string is specified in any other format other
>> than given above.
>> "period" - possible values are long/integer for timer period in
>> milliseconds,
>> "numberofoccurrences" - possible values are long/integer,
>> "message" - possible value: String.
>>
>> More info is available at
>> https://glassfish.dev.java.net/javaee5/selfmanagement/selfmanagementhome.html
>>
>
>
>
> Thanks for the pointer.
>
> I'm trying to understand whether the six event types listed on that page
> are "primitives" (core event classes that can be extended, but no new
> types of core event classes can be created by a user), or are just the
> pre-defined event types that are included with GlassFish (and a user
> can create other event types that the system handles in the same way
> as these event types).
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 six event types are primitive, it would make sense for the
> admin GUI to have specific knowledge of each event type.
Yes, GUI has this knowledge, and that's how the current screen flow is
for the selected event type when you create a management rule.
>
> If the six event types are just a set of events that happened to be
> delivered with GlassFish, and a user could add other event types, I
> would hope that the admin GUI would be more open-ended and handle
> all event types - the six above or user-written - identically.
>
> In the latter case, I don't understand how the admin GUI knows to
> display a string valued property using a calendar component.
Hmm... We don't have an issue here, bcz we've the knowledge of the six
supported event types. Again, if Sankara feels the other way, we've to
redo this screen flow completely.
>
>
> And back to the original issue...
>
> If we can't remove the pattern property (because the calendar component
> doesn't support it) because we already delivered the Timer event in
> GlassFish V1 and removing the pattern would be an incompatible change,
> and we can't fix the calendar component to accept a pattern, then it
> seems that we're stuck with not being able to use the calendar component.
Yes, and No. With AJAX in place we can still make use of calendar
component, some more work though :-) . When user types in the pattern we
can make an AJAX request to the server, and re-render the calendar
component again with the specified pattern. Sounds simple :-) , I'll see
how best I can deliver here. Ken said, he'll also help me to implement
this, so hopefully we can deliver this screen again with calendar component.
I would appreciate if Sankara can answer to your question above. At
least we know for sure that our assumption/implementation is correct for
the supported six event types only.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>