[infinispan-dev] Distributed Executors in write mode, need reference to Cache

Vladimir Blagojevic vblagoje at redhat.com
Wed Dec 21 10:30:18 EST 2011


Pete, a bit more guidance please :-) I read 
http://docs.jboss.org/weld/reference/latest/en-US/html/extend.html and I 
looked at the infinispan-cdi code and how InfinispanExtension class 
wires into CDI container. I understand that part, well, sort of! I've 
seen how a class whose instances are supposed to be injected 
(DefaultCacheManager, AdvancedCache) is "prepared" for CDI in our 
infinispan-cdi module.

>
> Here is the SPI that CDI has for this purpose:
>
> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/spi/InjectionTarget.html
>
> I would suggest modelling after it, as it's proved successful, and will make CDI integration easy. (BTW I don't mean use it directly, I mean copy and paste it into infinispan code).
I do not understand this part. What do you mean by "copy and paste this 
into Infinispan code"? Making sure we are on the same page: instances of 
Mapper (or Reducer) do not need to be injected somewhere; they are 
provided by the user and used in conjunction with MapReduceTask. 
Implementations of Mapper/Reducer interface need to have its field 
injected, once they are deseralized to remote Infinispan nodes, injected 
with appropriate Cache instance for example.

Thanks,
Vladimir

> Furthermore, what I would suggest you do is support the decorator pattern here, by creating one of these internally, and then allowing it to be got hold of by an extension, wrapped, and handed back to you. This makes it trivial for the extension to override the bits it wants. We also need to consider whether we want to allow overriding the construction and destruction of the object, as I guess by default you serialise/deserialize these? Might be useful to allow overriding anyway, in a fully stateless model (where changes are written back to the cache).







More information about the infinispan-dev mailing list