[infinispan-dev] Where to put KeyValueFilterFactory and ConverterFactory...

[Galder Zamarreño]

2 votes for core vs 1 for commons, going for core/

On 19 Jun 2014, at 16:34, William Burns <mudokonman at gmail.com> wrote:

> I was able to look into the details with this a bit.  At first thought
> I would think having a module that both the client and server packages
> could both depend on would be best.  However the issue is that these
> factories produce instances that implement interfaces that live in the
> core package, which means the server/client would have to depend on
> core anyways.  So I am thinking core is probably the best place for
> now.
> 
> Thinking about these factories even more it could be useful to use
> these at some point in core to allow for non serializable
> KeyValueFilter/Converter instances and instead have the factory be
> serializable and just create them on each node as needed.

^ Very good point, in fact, why not do this now? It could solve my problem of [1] in a very clean way. If each node instantiates the KeyValueFilter/Converter instances locally, I can plug the marshaller more easily? If I can plug the factory, I could try to initialise the factory with the marshaller and pass that to the cache, which involves the callback to create the KeyValueFilter/Converter instances, and I can use the marshaller in the factory to initialise these instances.

[1] https://issues.jboss.org/browse/ISPN-4378

> 
> - Will
> 
> On Thu, Jun 19, 2014 at 10:25 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
>> To me core is ideal:
>> when you develop these components, it's as if you were running in an
>> embedded environment (which is what the server essentially is), and core
>> is the closest you can get.
>> 
>> Tristan
>> 
>> On 19/06/14 16:12, Galder Zamarreño wrote:
>>> Hi all,
>>> 
>>> As I work on ISPN-3950, I’ve been thinking about the location of KeyValueFilterFactory  and ConverterFactory interfaces. These interfaces provide filter/converter instances to be installed in server/hotrod, but we expect users to provide implementations of such classes and plug the server with them.
>>> 
>>> These interfaces are currently in server/hotrod project, something I’m not keen on doing any more, because users would need to get access to these interfaces and they could start fiddling with other stuff in that module, and I want to avoid that at all costs, particularly since I’m hoping to do some major refactoring of the decoders in 7.1.
>>> 
>>> So, the q is: where should KeyValueFilterFactory and ConverterFactory live?
>>> 
>>> They’re for sure needed by server/hotrod. client/hotrod-client does not need them explicitly, but the users need to provide implementations of them and plug them to the server. With this in mind, core/ might be the best place for it. They cannot live in commons/ cos it’d would require to move KeyValueFilter/Converter and other dependant classes to commons.
>>> 
>>> Is everyone happy with ConverterFactory and KeyValueFilterFactory being in core/?
>>> 
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> galder at redhat.com
>>> twitter.com/galderz
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz