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). _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
