Return-Path: Delivered-To: apmail-jakarta-turbine-jcs-user-archive@www.apache.org Received: (qmail 59900 invoked from network); 17 Nov 2003 21:30:28 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 17 Nov 2003 21:30:28 -0000 Received: (qmail 63480 invoked by uid 500); 17 Nov 2003 21:30:16 -0000 Delivered-To: apmail-jakarta-turbine-jcs-user-archive@jakarta.apache.org Received: (qmail 63468 invoked by uid 500); 17 Nov 2003 21:30:16 -0000 Mailing-List: contact turbine-jcs-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Turbine JCS Users List" Reply-To: "Turbine JCS Users List" Delivered-To: mailing list turbine-jcs-user@jakarta.apache.org Received: (qmail 63455 invoked from network); 17 Nov 2003 21:30:16 -0000 Received: from unknown (HELO smtp1.doit.wisc.edu) (144.92.197.145) by daedalus.apache.org with SMTP; 17 Nov 2003 21:30:16 -0000 Received: from conversion-daemon.smtp1.doit.wisc.edu by smtp1.doit.wisc.edu (iPlanet Messaging Server 5.2 HotFix 1.20 (built Aug 27 2003)) id <0HOI00701LZM9I@smtp1.doit.wisc.edu> for turbine-jcs-user@jakarta.apache.org; Mon, 17 Nov 2003 15:29:03 -0600 (CST) Received: from dellpc (dyn-192-32.vpn.wisc.edu [146.151.192.32]) by smtp1.doit.wisc.edu (iPlanet Messaging Server 5.2 HotFix 1.20 (built Aug 27 2003)) with ESMTP id <0HOI00GVZMCFQI@smtp1.doit.wisc.edu> for turbine-jcs-user@jakarta.apache.org; Mon, 17 Nov 2003 15:29:03 -0600 (CST) Date: Mon, 17 Nov 2003 15:31:18 -0600 From: Aaron Smuts Subject: RE: Alter behavior through event handling? In-reply-to: To: 'Turbine JCS Users List' Message-id: <000001c3ad52$2340f910$20c09792@smuts> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N In the cache access class you can get the elementattributes for and item. Every item in the cache is given one by default. If you are putting something in, you can get the default elementattributes and then modify it and then use the put method that takes the elementattributes as an argument. To the elmentattributes, you can add something that implements org.apache.jcs.engine.control.event.behavior.IElementEventHandler This has only one method. public Serializable handleElementEvent( IElementEvent event ); The ElementEvent extends java's event object. So you can call event.getSource() This will return an object. Cast it to an ICacheElement. You can also find out what the event code is. The element events are put in a queue and run in the background. You can do whatever you want there. This should be easy: Again, implement an IElementEventHandler and add it to the elementattributes for the item you want. (You can add more than one event handler.) Get the event id and the ICacheElement from the event object that is passed to the handler's only method, and do whatever you want there. It will run in the background. Right now only two events are handled by the compositecache, spool to disk available and unavailable. I will implement all the events in IElementEventConstants soon. > -----Original Message----- > From: Todd Carmichael [mailto:toddc@concur.com] > Sent: Monday, November 17, 2003 11:14 AM > To: 'Turbine JCS Users List' > Subject: RE: Alter behavior through event handling? > > +1 for event handling. > +1 For similar changes in Torque so that a JCS event handling mechanism > calls into org.apache.torque.manager.CacheListener. In particular, I want > the remote and Lateral caching updates/removes to hook into Torque. > > ToddC > > > -----Original Message----- > From: Sean Cooper [mailto:secooper@vt.edu] > Sent: Wednesday, September 24, 2003 12:37 PM > To: turbine-jcs-user@jakarta.apache.org > Subject: Alter behavior through event handling? > > > I have not been able to determine if this is possible, but here is what I > am > trying to do. > > app 1) When something runs its life in the cache, rather then drop from > the > cache entirely, call a method on that particular object to refresh its > data > > app 2) When something runs its life in the cache, drop it from the cache, > and since the item being cached is a java.io.File reference delete the > file > from the hard drive (no, I cannot simple cache the java.io.File contents > in > JCS they aren't truly serializable and need to be streamed/loaded manually > to disk) > > I envision achieving this behavior by intercepting a cache release event > of > sorts, but I cannot figure out how to latch on to the event handler to > process it. Am I missing something? Or are the events and event handlers > not supposed to be fooled around with? > > -Sean > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org > For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org > For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org