2 votes for core vs 1 for commons, going for core/ On 19 Jun 2014, at 16:34, William Burns <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> twitter.com/galderz >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño [email protected] twitter.com/galderz _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
