Mailing-List: contact jcs-users-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JCS Users List" <jcs-users@jakarta.apache.org>
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=LNeT/WBi5QVwzZwk8jY0d9eEFdQwyFRq+PeHqQi4IqHkl6oJp26xw+Jd32UmI7zWcb7jp4XZog8pqcawNEAjaR+USCgLKdTeOEvUJE/ILJFQn2wQhsJDHm5zk13foaoebd9/1NBsF7zWclNyYMW/rY/0okZEffT8TRWl8fBKO2s=
  ;
Message-ID: <20061006151124.44308.qmail@web38710.mail.mud.yahoo.com>
Date: Fri, 6 Oct 2006 08:11:24 -0700 (PDT)
From: Aaron Smuts <asmuts@yahoo.com>
Subject: Re: Removing singleton design of JCS
To: JCS Users List <jcs-users@jakarta.apache.org>
In-Reply-To: 
 <35DC02724A9D12418D84928ECB5A34F7323DFF@nues-exc03-23.100world.global>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

No, we are not currently working on removing the
enforced singleton nature of JCS, but yes it would be 
somewhat useful if you could run multiple instances in
a vm  The only things that rely on the singleton
nature are the remote and lateral listeners.  

I started making changes such that the listeners would
be passed a cache manager on construction.  I think it
is nearly complete.  There are a few static lists and
maps in the various managers that would have to change
too.  We should try to come up with a list and then go
from there.  Any help is, of course, appreciated.

(Yes, JBoss cache is awful.  I've discussed it before
on the list. . . .  EH is a stripped down version of
JCS with almost none of the features.  The orignal
code was JCS about 4 years ago . . . . .  Please don't
get me started.)

Cheers,

Aaron

--- Denis Pasek <dpasek@100world.de> wrote:

> Hi,
> 
>  
> 
> it would be nice if JCS wouldn't rely on singletons
> (this mainly affects
> the CompositeCacheManager) in the VM / local
> classloader. Scanning the
> source code it should be quite easy to refactor JCS
> to a POJO based
> approach since there are only a few spots where
> classes rely on the
> singleton behaviour of the composite cache manager
> (eg. remote
> listeners). The hooks in the CompositeCacheManager
> for extension (see
> CompositeCacheManager.createInstance() ) won't work
> since these methods
> are static and so don't support polymorphism.
> 
> Scanning the Subversion repository I found a branch
> "removing singleton
> core". Does this mean you're already working on a
> non-singleton version?
> If so, is there a planned release date/version for
> this redesign? Maybe
> I can contribute to this refactoring.
> 
>  
> 
> I think JCS is really a nice cache und compares very
> well to EHCache and
> especially JBossCache. I've worked with these two
> competitors before.
> EHCache is ok, but JBossCache is quite a disaster.
> It has tons of
> dependencies and the source code is a real mess.
> 
>  
> 
>  
> 
> Denis
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 


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