You can easily use a service loader still, just have it return an object that provides
methods exposing this info. Benefits of following a well known approach to this kind of
stuff can't be over emphasized.
I'll file an issue at some point :-)
On 7 Oct 2011, at 06:07, Sanne Grinovero wrote:
On 6 October 2011 19:30, Pete Muir <pmuir(a)redhat.com> wrote:
> On 6 Oct 2011, at 07:07, Sanne Grinovero wrote:
>> extensions to Infinispan are already using a service interface, have
>> you noticed the "infinispan-module.properties" for example in the
>> Query module and Lucene modules?
>
> This should really be replaced by the service loader approach, there is no real
reason we should reinvent the wheel here ;-)
Right. Why are we having a custom implementation?
I guess because there are multiple properties being read, not just the
interface implementation name.
We have:
infinispan.module.name=
infinispan.module.lifecycle=
infinispan.module.command.initializer=
infinispan.module.command.factory=
But .name is not being used, besides logging;
the other three could be splitted in different services.
It might make sense to keep our own structure for more flexibility,
but even so should we not move this resource at least in META-INF ?
Now it is in the root of the jar.
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev