[infinispan-dev] Interested in lending a hand

Olaf Bergner olaf.bergner at gmx.de
Wed Mar 2 17:26:00 EST 2011 

It is my understanding from what Manik said that we would like to have 
this CacheManager implementation being a part of the standard Spring 
distribution. Is that correct? Therefore, I have asked in the 
SpringSource forum

1. if those folks are interested in having an Infinispan backed 
CacheManager implementation contributed to them and
2. if so, what I have to do to have my contribution accepted.

So far, I have not received an answer to my request. I'm a bit 
sceptical, though, since it *seems* as if the Spring folks only accept 
dependencies from their own Enterprise Bundle Repository which would 
leave us obliged to turn Infinispan into an OSGi bundle. Alternatively, 
we could always make it a part of Infinispan itself, maybe separated 
into its own module. Any thoughts on this?

Meanwhile, the implementation thus far seems to progress nicely, a first 
test passes. I'm developing against Infinispan 4.2.0.Final, the current 
stable version. For the time being I concentrate on supporting the 
embedded use case, although I'm aware that there is RemoteCache and its 
ilk. I would prefer to finally have two different implementations of 
org.springframework.cache.CacheManager, one backed by 
EmbeddedCacheManager and the other by RemoteCacheManager. Those two seem 
different enough to render any attempt at implementing a common 
abstraction futile. Any thoughts on this?

In addition to the Infinispan backed CacheManager I implemented two 
FactoryBeans for creating org.infinispan.Cache and 
org.infinispan.manager.EmbeddedCacheManager instances. At least a 
FactoryBean for the latter seems necessary since otherwise users will 
have a hard time trying to obtain an Infinispan backed CacheManager from 
their application context.

Right now, all configuration is done by pointing those FactoryBeans to 
the location of a configuration file in the standard Infinispan format. 
The Spring way to go would be to alternatively offer setters for all 
configuration options. However, org.infinispan.config.Configuration is 
quite ... expansive. Are there any prominent options I should 
concentrate on first?

Cheers,
Olaf


Am 02.03.11 18:03, schrieb Sanne Grinovero:
> Hi Olaf,
> We just created the issue to track this:
> https://issues.jboss.org/browse/ISPN-961
> thanks for your help!
>
> Cheers,
> Sanne
>
> 2011/3/2 Olaf Bergner<olaf.bergner at gmx.de>:
>> So I will implement Spring's CacheManager interface first. After that, I
>> will have a look at ISPN-78. It looks highly interesting, yet not
>> exactly trivial. Which is good and bad ;-) I'll see how it goes. Anyway,
>> the list of open issues for 5.1.0.Final should prove sufficient to keep
>> me entertained for a while.
>>
>> Cheers,
>> Olaf
>>
>> Am 02.03.11 11:29, schrieb Manik Surtani:
>>> Great! If you are a Spring guy (or even if not!), you could implement
>>>
>>>        http://static.springsource.org/spring/docs/3.1.0.M1/javadoc-api/index.html?org/springframework/cache/CacheManager.html
>>>
>>> using Infinispan, and contribute it back to Spring ... we'd really appreciate that and it would be a great start for you to get used to working with Infinispan.  :-)
>>>
>>> Then, perhaps something more meaty like:
>>>
>>>        https://issues.jboss.org/browse/ISPN-78
>>>
>>> might be fun... or if you like Linux/C/JNI:
>>>
>>>        https://issues.jboss.org/browse/ISPN-517
>>>
>>> Otherwise, do any of these look interesting to you?
>>>
>>>        https://issues.jboss.org/secure/IssueNavigator.jspa?mode=hide&requestId=12313236
>>>
>>> Cheers
>>> Manik
>>>
>>> On 1 Mar 2011, at 20:01, Olaf Bergner wrote:
>>>
>>>> Hi Manik,
>>>>
>>>> well, my areas of expertise are probably irrelevant in this context. I
>>>> chose Infinispan primarily as an opportunity to learn while working on a
>>>> fascinating project that addresses some of the pain points in today's
>>>> application development.
>>>>
>>>> As to my areas of interest: I do indeed find transaction management
>>>> fascinating, that's why I was looking for an easy task in that area. But
>>>> all in all, I'm interested in the whole distributed computing thing. I
>>>> read the Dynamo paper, so I understand constant hash rings at least on a
>>>> theoretical level.
>>>>
>>>> Otherwise, I thought there might be some mundane tasks nobody else is
>>>> especially keen on taking on as they are probably not very interesting.
>>>> Improving logging comes to mind, maybe adding some documentation.
>>>> Technically not very demanding and yet those tasks need to be done. Plus
>>>> they might be an opportunity to get to know the code base.
>>>>
>>>> All in all I'm open to suggestions.
>>>>
>>>> Cheers
>>>> Olaf
>>>>
>>>> Am 01.03.11 18:32, schrieb Manik Surtani:
>>>>> Hi Olaf
>>>>>
>>>>> Welcome to the mail list!  :-)
>>>>>
>>>>> I believe someone (Mircea) is already working on ISPN-272 as we speak, but there are lots of other interesting things you can take on.  Are there any specific areas of interest or expertise you may have?
>>>>>
>>>>> Cheers
>>>>> Manik
>>>>>
>>>>> On 1 Mar 2011, at 14:14, Olaf Bergner wrote:
>>>>>
>>>>>> I've been quietly following Infinispan's progress and finally made the
>>>>>> decision to offer to help out. Since I'm not an experienced system-level
>>>>>> programmer - I've got a strong background in JEE application development
>>>>>> - I was looking for a not too complex task to start with. I took a look
>>>>>> at ISPN-272 "Implement XA recovery in TransactionXaAdapter" and if I
>>>>>> interpret Manik Surtani's comments correctly it all boils down to
>>>>>> essentially:
>>>>>>
>>>>>> * Make it so that Xid[] recover(int flags) returns the Xids of the
>>>>>> LocalTransactions managed by this TransactionXaAdapter that are
>>>>>> currently in state 'PREPARED'
>>>>>>
>>>>>> Is this correct? If so I thought about
>>>>>>
>>>>>> 1. adding a method Set<LocalTransaction>
>>>>>> getLocalTransactionsCurrentlyInStatus(int desiredStatus) to
>>>>>> TransactionTable, and
>>>>>> 2. having recover(int flags) on TransactionXaAdapter delegate to this
>>>>>> new method, passing in Status.STATUS_PREPARED.
>>>>>>
>>>>>> So:
>>>>>>
>>>>>> 1. Could you use my help?
>>>>>> 2. Is ISPN-272 a good starting point, or are there better tasks for a
>>>>>> newcomer?
>>>>>> 3. If ISPN-272 is good starting point, is my proposed solution viable,
>>>>>> or is it lacking?
>>>>>>
>>>>>> Regards,
>>>>>> Olaf
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> infinispan-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>> --
>>>>> Manik Surtani
>>>>> manik at jboss.org
>>>>> twitter.com/maniksurtani
>>>>>
>>>>> Lead, Infinispan
>>>>> http://www.infinispan.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> --
>>> Manik Surtani
>>> manik at jboss.org
>>> twitter.com/maniksurtani
>>>
>>> Lead, Infinispan
>>> http://www.infinispan.org
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>

More information about the infinispan-dev mailing list