Packaging
by Manik Surtani
Hi,
Just had a call with Ben about JBoss Cache packaging. WHat do people
think about:
1) JBossCache-core - binaries, jars and sample configs only
2) JBossCache-pojo - as above, with PojoCache jar as well
3) JBossCache-all - as above, with srcs, unit tests, examples and
tutorial
4) JBossCache-external-jars - Just the BDBJE jar
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
17 years, 7 months
RE: [jbosscache-dev] CacheSPI.setStateTransferManager
by Ben Wang
Manik and I have just chatted. One possibility. Instead of have a setter
on STM, we expose a sort of a static factory method to obtain the STM
class. But this also has the same concern as you do to expose this prior
to defining the contract.
The other possibility is I defer the implementation of
PojoCacheStateTransferManager after the alpha release and wait for the
STM API to settle down, althouhg I'd prefer to implement it ASAP,
especially for partial state transfer piece.
Another question. Currently, StateTransferManager is using TreeCache
directly. Would it be possibel to use CacheSPI instead? Otherwise, any
subclass of StateTransferManager isn't having access to TreeCache.
-Ben
-----Original Message-----
From: Vladimir Blagojevic
Sent: Tuesday, September 19, 2006 9:41 PM
To: Manik Surtani; Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] CacheSPI.setStateTransferManager
One downside is that we are opening StateTransferManager API to
extensions and plugins prior to clearly defining the contract around
StateTransferManager. It is sort of internal class that has to be
promoted to a new role without being completely ready for it.
Brian?
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik
> Surtani
> Sent: Tuesday, September 19, 2006 7:29 AM
> To: Ben Wang
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] CacheSPI.setStateTransferManager
>
> There should be a setter as well. Vladimir, Brian: can you think of a
> good reason not to allow this to be set programmatically in the SPI?
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
17 years, 7 months
RE: [jbosscache-dev] Re: Logging jars
by Ben Wang
+1. We currently have many scripts that use for tutorial and examples. How can we sync them up quickly between each release and test them out can be the key.
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Bela Ban
Sent: Tuesday, September 12, 2006 4:47 AM
To: Manik Surtani
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Re: Logging jars
I'm all for version numbers in JARs, but we also need scripts that add
(e.g.) all JARs in a given dir to the classpath, rather than list them.
If we list them explicitly, we have to change those scripts when we change the JAR name.
Manik Surtani wrote:
> I was trying it out as per our discussions on dev.
>
> Also, I think it is best to have version numbers on such jars just so
> we're clear on what versions we're using (I couldn't tell which
> version of JCL we had before, for example)
>
> What does everyone think about version numbers in the jars we use,
> like this?
>
> Cheers,
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
> On 11 Sep 2006, at 18:29, Brian Stansberry wrote:
>
>> Hey dude,
>>
>> Looks like you checked in commons-logging-1.1.jar and log4j-1.2.13.jar.
>> Was this intentional? These files have a different name from what's
>> in the Eclipse project classpath, so that breaks Eclipse. I can
>> check in a fixed Eclipse .classpath file, but don't want to if you're
>> going to revert the library change.
>>
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
--
Bela Ban
Lead JGroups / Manager JBoss Clustering Group JBoss - a division of Red Hat
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 7 months
DummyInMemoryCacheLoader
by Manik Surtani
Hi guys
I've created a new DummyInMemoryCacheLoader, an easy way to test
cache loader functionality when used in conjunction with other areas
of functionality (such as the new move() API). A lot quicker than a
file CL, easier to debug.
It is in the tests/functional dir to prevent it from ever being used
for anything other than unit tests. Hope you guys find it useful.
PS: It is not transactional at the moment (as I haven't had a need
for it to be so so far) but this can be added if there is a need.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
17 years, 7 months
RE: [jbosscache-dev] CacheSPI.setStateTransferManager
by Vladimir Blagojevic
One downside is that we are opening StateTransferManager API to
extensions and plugins prior to clearly defining the contract around
StateTransferManager. It is sort of internal class that has to be
promoted to a new role without being completely ready for it.
Brian?
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
> Manik Surtani
> Sent: Tuesday, September 19, 2006 7:29 AM
> To: Ben Wang
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] CacheSPI.setStateTransferManager
>
> There should be a setter as well. Vladimir, Brian: can you
> think of a good reason not to allow this to be set
> programmatically in the SPI?
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
17 years, 7 months
CacheSPI.setStateTransferManager
by Ben Wang
Manik,
I am trying to override the state transfer manager in PojoCache. But I only have getStateTransferManager from CacheSPI. Is it possible to have a setStateTransferManager api or there is other way to do it?
Thanks,
-Ben
17 years, 7 months
Cache JMX MBean
by Ben Wang
Manik,
Is the Cache JMX Mbean implementation complete already? I am looking into integrating it with PojoCache. Is the test under jmx the one to look into?
Thanks,
-Ben
17 years, 7 months
RE: [jbosscache-dev] More breaking UTs in HEAD
by Ben Wang
OK, how about we sync up twomorrow then?
-Ben
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Sunday, September 17, 2006 7:30 PM
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] More breaking UTs in HEAD
How does mid-week (wed) sound then? I'll have my stuff cleaned up by Mon, I'm waiting on a new jboss-serialization.jar from Clebert to fix some marshalling issues (which should be out over the weekend).
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 17 Sep 2006, at 09:35, Ben Wang wrote:
> OK, looks like there is a problem in the Cache passivation failure
> that causes PojoCache passivation to fail as well. But it should go
> away when you have them in order.
>
> BTW, how do things look like on your side now for the Alpha release?
> PojoCache is mostly ready except state transfer code and some clean up
> on examples and tutorial. I expect to finish them within 2-3 days.
>
> Thanks,
>
> -Ben
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-
> bounces(a)lists.jboss.org] On Behalf Of Manik Surtani
> Sent: Saturday, September 16, 2006 8:02 PM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] More breaking UTs in HEAD
>
> Hi guys
>
> The reason for a higher failure rate in CC is that I added a whole
> bunch of unit tests to stress the new move() API in various ways.
> Some of these need fixing (such as deep locks on nodes when moving
> subtrees and optimistic locks on subtrees, notifications while moving,
> and cacheloader/passivation code to reflect moves) but I expect these
> to be in place Monday.
>
> Just in case you were wondering why the test pass-rate dropped from
> 98.5% to 92.5%! :-)
>
> Cheers,
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 7 months
RE: [jbosscache-dev] More breaking UTs in HEAD
by Ben Wang
OK, looks like there is a problem in the Cache passivation failure that causes PojoCache passivation to fail as well. But it should go away when you have them in order.
BTW, how do things look like on your side now for the Alpha release? PojoCache is mostly ready except state transfer code and some clean up on examples and tutorial. I expect to finish them within 2-3 days.
Thanks,
-Ben
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Saturday, September 16, 2006 8:02 PM
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] More breaking UTs in HEAD
Hi guys
The reason for a higher failure rate in CC is that I added a whole
bunch of unit tests to stress the new move() API in various ways.
Some of these need fixing (such as deep locks on nodes when moving subtrees and optimistic locks on subtrees, notifications while moving, and cacheloader/passivation code to reflect moves) but I expect these to be in place Monday.
Just in case you were wondering why the test pass-rate dropped from 98.5% to 92.5%! :-)
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 7 months
