I don't know if this helps answer the "primitive" vs. "predefined"
question, but the event types are an enumeration in the DTD. One value,
"cluster", doesn't appear to be used.
June
Bill Shannon wrote On 04/20/07 11:46 AM,:
> 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).
>
> If the six event types are primitive, it would make sense for the
> admin GUI to have specific knowledge of each event type.
>
> 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.
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>