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/Injection...
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).