Return-Path: Mailing-List: contact turbine-jcs-user-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list turbine-jcs-user@jakarta.apache.org Received: (qmail 39541 invoked from network); 17 Apr 2003 17:58:29 -0000 Received: from mail.metasolv.com (HELO srvmaddog.metasolv.com) (12.105.131.5) by daedalus.apache.org with SMTP; 17 Apr 2003 17:58:29 -0000 Received: by mail.metasolv.com with Internet Mail Service (5.5.2655.55) id <2V8ZF75T>; Thu, 17 Apr 2003 13:03:05 -0500 Message-ID: From: "Young, Wayne" To: 'Turbine JCS Users List' Subject: RE: JCS & J2EE Date: Thu, 17 Apr 2003 13:03:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3050B.972AF5A0" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ------_=_NextPart_001_01C3050B.972AF5A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Les, The way we do it is to add jcs-1.0-dev.jar, the folder containing = cache.ccf, & the supporting jars to the CLASSPATH variable before we start BEA. = (on exteNd we set AGCLASSPATH) When the appserver starts, the JCS classes = are available everywhere.=20 You don't actually have to do a JNDI lookup. You just do a JCS.getInstance("SOMEREGION") to get the singleton reference pointing = to the cache region "SOMEREGION". We didn't actually use an MBean. I meant "service" in a generic sense, = not specific to BEA. Thanks. Wayne -----Original Message----- From: Les Hazlewood [mailto:lhazlewood@transdynatlanta.com] Sent: Thursday, April 17, 2003 12:52 PM To: 'Turbine JCS Users List' Subject: RE: JCS & J2EE Wayne, Perhaps I interpreted your email incorrectly. Are you referring to a = user defined JCS MBean service? -----Original Message----- From: Les Hazlewood [mailto:lhazlewood@transdynatlanta.com]=20 Sent: Thursday, April 17, 2003 12:34 PM To: 'Turbine JCS Users List' Subject: RE: JCS & J2EE Wayne, Thanks for the reply... Can you explain to me how this works? I'm not familiar with running services within the application server environment outside of whatever = is explicitly defined in ear files. I'm assuming you can do a jndi lookup = on the cache and use it that way? Any information at all would be greatly appreciated. Perhaps a link or = two could explain the idea of running services on the classpath outside of = ear files. Thanks very much, Les -----Original Message----- From: Young, Wayne [mailto:WYoung@metasolv.com]=20 Sent: Thursday, April 17, 2003 11:19 AM To: 'Turbine JCS Users List' Subject: RE: JCS & J2EE We're using JCS in a J2EE environment with remote cache servers that = use RMI to communicate. (under both BEA and exteNd) It works fine. We add it to the appserver classpath, ie, we do not add = jcs to the individual ear files. Basically it just becomes another service = in the application server and is available to all the deployed = applications. We have also been investigating the JavaGroups cache sync mechanism. Wayne -----Original Message----- From: Honig, Daniel [mailto:DHonig@tiaa-cref.org] Sent: Thursday, April 17, 2003 11:07 AM To: 'Turbine JCS Users List' Subject: RE: JCS & J2EE I'd love to collaborate on this. Time doesn't look too good though. = But I'm sure we coudl get a minimal implementation down. I don't like idea = of running socket based cacheing in a J2EE=20 environment. I think using JMS to synchronize caches would be a = superior solution and take JCS to the next level. -----Original Message----- From: Les Hazlewood [mailto:lhazlewood@transdynatlanta.com] Sent: Thursday, April 17, 2003 10:55 AM To: 'Turbine JCS Users List' Subject: RE: JCS & J2EE Absolutely, there's interest! That=E2=80=99s why I asked about pluggable components. One could come up with a communications interface that allows you to send/receive updates. My thoughts were that the communications interface would remain the = same (avoiding code changes) and provide coding abstraction, while the = underlying implementation used JMS or Sockets, depending on the deployment requirements. Les Hazlewood P.S. So I'm assuming this means JCS doesn't support J2EE environements? Anyone know about threading issues with JCS that prevent execution in a = J2EE environment? -----Original Message----- From: Honig, Daniel [mailto:DHonig@tiaa-cref.org]=20 Sent: Thursday, April 17, 2003 9:50 AM To: 'Turbine JCS Users List' Subject: RE: JCS & J2EE In regards to the sockets comment. Why not use JMS to keep cache's in = sync? I think there are a few commercial vendors who use this approach. Is = there interest in this? -----Original Message----- From: Les Hazlewood [mailto:lhazlewood@transdynatlanta.com] Sent: Thursday, April 17, 2003 10:19 AM To: 'turbine-jcs-user@jakarta.apache.org' Subject: JCS & J2EE Hi all, =20 I just finished reading the docs on JCS...great idea and looks like a = great product. I like the additions to JSR 107 that it has made. =20 =20 I have just a few questions: =20 Why isn't this project in the Jakarta commons domain? This is a far = more useful product than just being able to work with turbine. =20 Also, can JCS work in a J2EE environment? In the brief time I've spent looking over code (very brief), I've noticed JCS uses sockets and synchronization code, both of which aren't allowed in a J2EE = environment. =20 =20 Does JCS have pluggable modules that allows it to work in a J2EE environment? =20 Thanks so much, =20 Les Hazlewood =20 Les A. Hazlewood Software Engineer Transdyn Controls, Inc. 2855 Premiere Parkway Suite F Duluth, GA 30097 Telephone: (678) 473-6400 Direct: (678) 473-6423 Fax: (678) 473-9003 =20 ********************************************************************** This message, including any attachments, contains confidential = information intended for a specific individual and purpose, and is protected by = law. If you are not the intended recipient, please contact sender immediately = by reply e-mail and destroy all copies. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of = any action based on it, is strictly prohibited. TIAA-CREF ********************************************************************** --------------------------------------------------------------------- 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 ------_=_NextPart_001_01C3050B.972AF5A0--