[infinispan-dev] [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy

[Sanne Grinovero]

To clarify, I was *not* asking to remove the current configuration
API, which I actually do like a lot and think was quite well designed;
it works fine and so why should we remove it or even consider changing
the API.

Just for some borderline situations, like framework integrations as
OGM, Hibernate Search, Hibernate 2LC it seems useful to have an
additional API giving access to the internal ComponentRegistry to
inject some overrides, or just to reuse existing instances. Apparently
from the forums, occasionally users need something similar.

Cheers,
Sanne


2011/2/3 Manik Surtani <manik at jboss.org>:
>
> On 2 Feb 2011, at 20:45, Vladimir Blagojevic wrote:
>
>> On 11-02-02 12:16 PM, Manik Surtani wrote:
>>> Essentially, org.infinispan.config.{Configuration, GlobalConfiguration, etc} would both be the new, simpler, fluent cfg beans.
>>>
>>> Essentially, org.infinispan.config.compat.{Configuration, GlobalConfiguration, etc} would be delegates to the new style beans, but will be 100% API compatible with what we have now.  And would be marked as @Deprecated.  :-)
>>
>> So fluent API and these fluent API enabling beans are excellent solution
>> for setters but what about getters on GlobalConfiguration and
>> Configuration? We leave them as is, no?
>>
>> If so, then I am not so sure about these parallel hierarchies. Its major
>> PITA with minimal benefits. Users will still have to recompile their
>> codebase.  Given that, what if we release fluent API along with current
>> APIs as-is in next alpha with a warning that they old setter API's will
>> be removed in BETA1? That's fair!
>
> I don't think anyone should be doing anything too important with an ALPHA release.  :-)
>
> I'm more concerned about folks using 4.2.x.FINAL who eventually switch to 5.0.0.FINAL.
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>