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

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sanne Grinovero-2
I'm sorry, this is especially relevant to infinispan-dev, but my
previous CC was bounced.
Sanne


---------- Forwarded message ----------
From: Sanne Grinovero <[hidden email]>
Date: 2011/2/2
Subject: Re: [hibernate-dev] Have Infinispan share Hibernate's
TransactionManagerLookup strategy
To: Galder Zamarreño <[hidden email]>
Cc: Emmanuel Bernard <[hidden email]>, Hibernate
<[hidden email]>, infinispan -Dev List
<[hidden email]>


2011/2/2 Galder Zamarreño <[hidden email]>:
> Hmmm, I already did a similar thing for Infinispan 2LC a while back:
>
> https://github.com/galderz/hibernate-core/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/InfinispanRegionFactory.java#L418

Nice, you're taking it from the Settings, I like your approach more.
But be aware of ISPN-883, just solved.

>
> I take Hibernate's TM and hook it into Infinispan. The way I did it is create a HibernateTransactionManagerLookup class that implements org.infinispan.transaction.lookup.TransactionManagerLookup and looks up the transaction manager with Settings.getTransactionManagerLookup().getTransactionManager(properties)
>
> Maybe we should look into consolidating this code?

Definitely; in which project would you store the common
TransactionManagerLookup wrapper?
I would be fine in depending to the second level cache module, I'd
assume that anybody having setup Infinispan and Hibernate would use
the second level cache too, or at least have no issues having to
depend on it being classpath.

We could add a simplified EmbeddedCacheManager constructor to maintain
most of the complexity of building a cache via a configuration but
overriding components via provided instances, this relates to a brief
chat I had yesterday with Vladimir about a forum thread [1]. Maybe
easies way is to expose the GlobalComponentRegistry during the
configuration phase, as overrides for internal components?

1 - http://community.jboss.org/thread/161913?tstart=0

Cheers,
Sanne



>
> Cheers,
>
> On Feb 1, 2011, at 8:17 PM, Sanne Grinovero wrote:
>
>> As discussed, I have been playing with Infinispan's configuration
>> options to have it startup using hibernate's TransactionManagerLookup.
>> It wasn't working initially because of ISPN-883, but this is now
>> solved (thanks Mircea!).
>>
>> I'm not sure yet if this should be pushed to Hibernate Search, but it
>> might be useful to have a look for OGM:
>>
>> https://github.com/Sanne/hibernate-search/commits/InfinispanTransactionManagerLookup
>>
>> it's quite verbose, if you have suggestions I can try pushing some of
>> the complexity into Infinispan, assuming they are fine with it.
>>
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Manik Surtani
>
> 2011/2/2 Galder Zamarreño <[hidden email]>:
>> Hmmm, I already did a similar thing for Infinispan 2LC a while back:
>>
>> https://github.com/galderz/hibernate-core/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/InfinispanRegionFactory.java#L418
>
> Nice, you're taking it from the Settings, I like your approach more.
> But be aware of ISPN-883, just solved.
>
>> I take Hibernate's TM and hook it into Infinispan. The way I did it is create a HibernateTransactionManagerLookup class that implements org.infinispan.transaction.lookup.TransactionManagerLookup and looks up the transaction manager with Settings.getTransactionManagerLookup().getTransactionManager(properties)
>>
>> Maybe we should look into consolidating this code?
>
> Definitely; in which project would you store the common
> TransactionManagerLookup wrapper?
> I would be fine in depending to the second level cache module, I'd
> assume that anybody having setup Infinispan and Hibernate would use
> the second level cache too, or at least have no issues having to
> depend on it being classpath.

+1.

> We could add a simplified EmbeddedCacheManager constructor to maintain
> most of the complexity of building a cache via a configuration but
> overriding components via provided instances, this relates to a brief
> chat I had yesterday with Vladimir about a forum thread [1]. Maybe
> easies way is to expose the GlobalComponentRegistry during the
> configuration phase, as overrides for internal components?
>
> 1 - http://community.jboss.org/thread/161913?tstart=0

Shall we discuss the config improvements on the forum, since that's where it started?

Cheers
Manik

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Vladimir Blagojevic
On 11-02-02 9:16 AM, Manik Surtani wrote:

>> We could add a simplified EmbeddedCacheManager constructor to maintain
>> most of the complexity of building a cache via a configuration but
>> overriding components via provided instances, this relates to a brief
>> chat I had yesterday with Vladimir about a forum thread [1]. Maybe
>> easies way is to expose the GlobalComponentRegistry during the
>> configuration phase, as overrides for internal components?
>>
>> 1 - http://community.jboss.org/thread/161913?tstart=0
> Shall we discuss the config improvements on the forum, since that's where it started?
>
> Cheers
> Manik
>
+1 I believe this can coexist/complement current setters approach. I do
not see how this can affect JAXB. It should work.
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Manik Surtani

On 2 Feb 2011, at 12:22, Vladimir Blagojevic wrote:

> On 11-02-02 9:16 AM, Manik Surtani wrote:
>>> We could add a simplified EmbeddedCacheManager constructor to maintain
>>> most of the complexity of building a cache via a configuration but
>>> overriding components via provided instances, this relates to a brief
>>> chat I had yesterday with Vladimir about a forum thread [1]. Maybe
>>> easies way is to expose the GlobalComponentRegistry during the
>>> configuration phase, as overrides for internal components?
>>>
>>> 1 - http://community.jboss.org/thread/161913?tstart=0
>> Shall we discuss the config improvements on the forum, since that's where it started?
>>
>> Cheers
>> Manik
>>
> +1 I believe this can coexist/complement current setters approach. I do
> not see how this can affect JAXB. It should work.

Yeah it shouldn't affect the XML parsing at all.  

But it would need to happen in 5.0, and the sooner the better since it will change API.  :-)

I added some thoughts to the forum post - do we have a JIRA for this?
--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Vladimir Blagojevic
On 11-02-02 9:26 AM, Manik Surtani wrote:
> Yeah it shouldn't affect the XML parsing at all.
>
> But it would need to happen in 5.0, and the sooner the better since it will change API.  :-)
>
> I added some thoughts to the forum post - do we have a JIRA for this?
Saw the post. Excellent ideas. No JIRA yet, I'll create it.

Cheers
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Vladimir Blagojevic
On 11-02-02 9:47 AM, Vladimir Blagojevic wrote:

> On 11-02-02 9:26 AM, Manik Surtani wrote:
>> Yeah it shouldn't affect the XML parsing at all.
>>
>> But it would need to happen in 5.0, and the sooner the better since it will change API.  :-)
>>
>> I added some thoughts to the forum post - do we have a JIRA for this?
> Saw the post. Excellent ideas. No JIRA yet, I'll create it.
>
> Cheers
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
https://issues.jboss.org/browse/ISPN-911
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Mircea Markus
In reply to this post by Vladimir Blagojevic

On 2 Feb 2011, at 12:22, Vladimir Blagojevic wrote:

> On 11-02-02 9:16 AM, Manik Surtani wrote:
>>> We could add a simplified EmbeddedCacheManager constructor to maintain
>>> most of the complexity of building a cache via a configuration but
>>> overriding components via provided instances, this relates to a brief
>>> chat I had yesterday with Vladimir about a forum thread [1]. Maybe
>>> easies way is to expose the GlobalComponentRegistry during the
>>> configuration phase, as overrides for internal components?
>>>
>>> 1 - http://community.jboss.org/thread/161913?tstart=0
>> Shall we discuss the config improvements on the forum, since that's where it started?
>>
>> Cheers
>> Manik
>>
> +1 I believe this can coexist/complement current setters approach. I do
> not see how this can affect JAXB. It should work.
you mean setXyzClass?
I agree that this can coexist but I think the point is to simplify configuration so I'd rather take these methods out (5 doesn't need to be backward compatible).
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Vladimir Blagojevic
On 11-02-02 10:41 AM, Mircea Markus wrote:
>> +1 I believe this can coexist/complement current setters approach. I do
>> not see how this can affect JAXB. It should work.
> you mean setXyzClass?
> I agree that this can coexist but I think the point is to simplify configuration so I'd rather take these methods out (5 doesn't need to be backward compatible).
You would only leave this new API and remove the old setters? I guess we
can do that as well, did not even cross my mind, but maybe, why not?
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Mircea Markus

On 2 Feb 2011, at 13:51, Vladimir Blagojevic wrote:

> On 11-02-02 10:41 AM, Mircea Markus wrote:
>>> +1 I believe this can coexist/complement current setters approach. I do
>>> not see how this can affect JAXB. It should work.
>> you mean setXyzClass?
>> I agree that this can coexist but I think the point is to simplify configuration so I'd rather take these methods out (5 doesn't need to be backward compatible).
> You would only leave this new API and remove the old setters? I guess we
> can do that as well, did not even cross my mind, but maybe, why not?
the point of this is to simplifying the config :)
Adding more setter on top of all the setters we have would just make things uglier imo. (even with the very nice builder approach)


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Manik Surtani
In reply to this post by Vladimir Blagojevic

On 2 Feb 2011, at 13:51, Vladimir Blagojevic wrote:

> On 11-02-02 10:41 AM, Mircea Markus wrote:
>>> +1 I believe this can coexist/complement current setters approach. I do
>>> not see how this can affect JAXB. It should work.
>> you mean setXyzClass?
>> I agree that this can coexist but I think the point is to simplify configuration so I'd rather take these methods out (5 doesn't need to be backward compatible).
> You would only leave this new API and remove the old setters? I guess we
> can do that as well, did not even cross my mind, but maybe, why not?

Hmm, leave the old setters IMO, and deprecate them.  Lets allow existing stuff to work!  ;)

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Mircea Markus

On 2 Feb 2011, at 13:54, Manik Surtani wrote:

>
> On 2 Feb 2011, at 13:51, Vladimir Blagojevic wrote:
>
>> On 11-02-02 10:41 AM, Mircea Markus wrote:
>>>> +1 I believe this can coexist/complement current setters approach. I do
>>>> not see how this can affect JAXB. It should work.
>>> you mean setXyzClass?
>>> I agree that this can coexist but I think the point is to simplify configuration so I'd rather take these methods out (5 doesn't need to be backward compatible).
>> You would only leave this new API and remove the old setters? I guess we
>> can do that as well, did not even cross my mind, but maybe, why not?
>
> Hmm, leave the old setters IMO, and deprecate them.  Lets allow existing stuff to work!  ;)
-1 as the new stuff would look worse than the one we already have. Perhaps add a new Configuration class hierarchy in a new package? Or just move this one in an "deprecated" package so that users would have to make minor changes for backward compatibility (i.e. change the import statement).



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Manik Surtani

On 2 Feb 2011, at 13:58, Mircea Markus wrote:

>
> On 2 Feb 2011, at 13:54, Manik Surtani wrote:
>
>>
>> On 2 Feb 2011, at 13:51, Vladimir Blagojevic wrote:
>>
>>> On 11-02-02 10:41 AM, Mircea Markus wrote:
>>>>> +1 I believe this can coexist/complement current setters approach. I do
>>>>> not see how this can affect JAXB. It should work.
>>>> you mean setXyzClass?
>>>> I agree that this can coexist but I think the point is to simplify configuration so I'd rather take these methods out (5 doesn't need to be backward compatible).
>>> You would only leave this new API and remove the old setters? I guess we
>>> can do that as well, did not even cross my mind, but maybe, why not?
>>
>> Hmm, leave the old setters IMO, and deprecate them.  Lets allow existing stuff to work!  ;)
> -1 as the new stuff would look worse than the one we already have. Perhaps add a new Configuration class hierarchy in a new package? Or just move this one in an "deprecated" package so that users would have to make minor changes for backward compatibility (i.e. change the import statement).

I'm not as worried about "look" as I am about usability.  We still get the benefit of an easier to use API while not pissing too many people off.  :-)  Plus the fact that it is deprecated means it can and will be removed in Infinispan 6, etc.

Yeah the parallel hierarchy is an option too - a 'compat' sub-package.

>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Vladimir Blagojevic
On 11-02-02 11:10 AM, Manik Surtani wrote:
> I'm not as worried about "look" as I am about usability.  We still get the benefit of an easier to use API while not pissing too many people off.  :-)  Plus the fact that it is deprecated means it can and will be removed in Infinispan 6, etc.
>
> Yeah the parallel hierarchy is an option too - a 'compat' sub-package.
Ok let me investigate how this compat sub-package could work. I'll
report back.
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Manik Surtani

On 2 Feb 2011, at 14:38, Vladimir Blagojevic wrote:

> On 11-02-02 11:10 AM, Manik Surtani wrote:
>> I'm not as worried about "look" as I am about usability.  We still get the benefit of an easier to use API while not pissing too many people off.  :-)  Plus the fact that it is deprecated means it can and will be removed in Infinispan 6, etc.
>>
>> Yeah the parallel hierarchy is an option too - a 'compat' sub-package.
> Ok let me investigate how this compat sub-package could work. I'll
> report back.

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.  :-)

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Galder Zamarreño-2
In reply to this post by Sanne Grinovero-2

On Feb 2, 2011, at 12:41 PM, Sanne Grinovero wrote:

> 2011/2/2 Galder Zamarreño <[hidden email]>:
>> Hmmm, I already did a similar thing for Infinispan 2LC a while back:
>>
>> https://github.com/galderz/hibernate-core/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/InfinispanRegionFactory.java#L418
>
> Nice, you're taking it from the Settings, I like your approach more.

Exactly. The idea was that 2LC users should need to configure as little as possible of Infinispan, hence focusing on configuration options within Hibernate settings. In this case, the transaction manager set up for Hibernate can be detected by the 2LC and plug Infinispan with it.

> But be aware of ISPN-883, just solved.
>
>>
>> I take Hibernate's TM and hook it into Infinispan. The way I did it is create a HibernateTransactionManagerLookup class that implements org.infinispan.transaction.lookup.TransactionManagerLookup and looks up the transaction manager with Settings.getTransactionManagerLookup().getTransactionManager(properties)
>>
>> Maybe we should look into consolidating this code?
>
> Definitely; in which project would you store the common
> TransactionManagerLookup wrapper?
> I would be fine in depending to the second level cache module, I'd
> assume that anybody having setup Infinispan and Hibernate would use
> the second level cache too, or at least have no issues having to
> depend on it being classpath.

I don't think you should depend on the 2LC module. Instead, maybe we should have an infinispan-int/ or infinispan-core/ module for shared Infinispan stuff that several Hibernate modules might benefit from?

>
> We could add a simplified EmbeddedCacheManager constructor to maintain
> most of the complexity of building a cache via a configuration but
> overriding components via provided instances, this relates to a brief
> chat I had yesterday with Vladimir about a forum thread [1]. Maybe
> easies way is to expose the GlobalComponentRegistry during the
> configuration phase, as overrides for internal components?
>
> 1 - http://community.jboss.org/thread/161913?tstart=0
>
> Cheers,
> Sanne
>
>
>
>>
>> Cheers,
>>
>> On Feb 1, 2011, at 8:17 PM, Sanne Grinovero wrote:
>>
>>> As discussed, I have been playing with Infinispan's configuration
>>> options to have it startup using hibernate's TransactionManagerLookup.
>>> It wasn't working initially because of ISPN-883, but this is now
>>> solved (thanks Mircea!).
>>>
>>> I'm not sure yet if this should be pushed to Hibernate Search, but it
>>> might be useful to have a look for OGM:
>>>
>>> https://github.com/Sanne/hibernate-search/commits/InfinispanTransactionManagerLookup
>>>
>>> it's quite verbose, if you have suggestions I can try pushing some of
>>> the complexity into Infinispan, assuming they are fine with it.
>>>
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>>

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Vladimir Blagojevic
In reply to this post by Manik Surtani
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.  :-)
Ok, I'll group these new beans by current defined units. Essentially
whatever is @XmlElement or an element in xml configuration file should
get a fluent bean interface of its own. I'll just make current beans
(SerializationType, TransportType, GlobalJmxStatisticsType etc etc )
implement these new interfaces and then expose them though getters in
GlobalConfiguration and Configuration.
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Emmanuel Bernard
In reply to this post by Galder Zamarreño-2

On 2 févr. 2011, at 16:21, Galder Zamarreño wrote:

>>>
>>>
>>> I take Hibernate's TM and hook it into Infinispan. The way I did it is create a HibernateTransactionManagerLookup class that implements org.infinispan.transaction.lookup.TransactionManagerLookup and looks up the transaction manager with Settings.getTransactionManagerLookup().getTransactionManager(properties)
>>>
>>> Maybe we should look into consolidating this code?
>>
>> Definitely; in which project would you store the common
>> TransactionManagerLookup wrapper?
>> I would be fine in depending to the second level cache module, I'd
>> assume that anybody having setup Infinispan and Hibernate would use
>> the second level cache too, or at least have no issues having to
>> depend on it being classpath.
>
> I don't think you should depend on the 2LC module. Instead, maybe we should have an infinispan-int/ or infinispan-core/ module for shared Infinispan stuff that several Hibernate modules might benefit from?

Not sure it makes any difference in practice as all modules of core are released in sync with the same version number. I'd probably go for a single module as it's simpler.
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Vladimir Blagojevic
In reply to this post by Manik Surtani
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!

Vladimir




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Manik Surtani

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
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]>:

>
> 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
> [hidden email]
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev