Return-Path: 
 <avalon-dev-return-1044-apmail-jakarta-avalon-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-avalon-dev-archive@jakarta.apache.org
Received: (qmail 10697 invoked by uid 500); 22 Mar 2001 03:12:50 -0000
Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:avalon-dev@jakarta.apache.org>
List-Help: <mailto:avalon-dev-help@jakarta.apache.org>
List-Unsubscribe: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:avalon-dev-subscribe@jakarta.apache.org>
Reply-To: "Avalon Development" <avalon-dev@jakarta.apache.org>
Delivered-To: mailing list avalon-dev@jakarta.apache.org
Received: (qmail 10686 invoked from network); 22 Mar 2001 03:12:48 -0000
Message-Id: <3.0.6.32.20010322141050.00ebc2b0@alphalink.com.au>
X-Sender: gdonald@alphalink.com.au
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Thu, 22 Mar 2001 14:10:50 +1100
To: avalon-dev@jakarta.apache.org
From: Peter Donald <donaldp@apache.org>
Subject: Re: possible problem with scheduler and should Avalon have JDK
  style scheduling mechanism.
In-Reply-To: <002901c0b27b$0d408e70$0200a8c0@Harmeet>
References: <20010321191025.EMFI286.mta10.onebox.com@onebox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

At 06:49  21/3/01 -0800, Harmeet Bedi wrote:
>JDK Timer class has scehdule methods and TimerTask.
>TimerTask is similar to Target in Avalon.
>The <schedule> methods control trigger/task invocation.
>
>Would it make sense to move the Avalon API towards JDK model.

>Here is a Proposal: Have interfaces such that a JDK or custom Scheduler
>could implement it easily. This could mean adding the scheduling methods to
>TimeScheduler and deprecating TimeTrigger. It would allow multiple
>implementations to plugin - JDK or DefaultTimeScheduler.

a few issues. Using the JDK assumes that only periodic timers will be used
which is not the case. The JDK also assumes a naive environment. However as
Phoenix is essentially a application server we have to worry about setting
up threads appropriately (ie set ContextClassLoader/Thread-specific
JNDI/security/whatever settings). While we could coerce JDK into doing what
we want ... I can not see a significant advantage in doing so - feel free
to do it yourself though ;)

>The advantage would be
>- Smaller and hence easier to maintain codebase.

which if it contains a bug would be virtually impossible to fix.

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org