admin@glassfish.java.net

Re: calendar component

From: Bill Shannon <bill.shannon_at_sun.com>
Date: Fri, 20 Apr 2007 11:46:51 -0700

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.