5:54 a.m.
I'm sorry, this is especially relevant to infinispan-dev, but my
previous CC was bounced.
Sanne
---------- Forwarded message ----------
From: Sanne Grinovero <sanne(a)hibernate.org>
Date: 2011/2/2
Subject: Re: [hibernate-dev] Have Infinispan share Hibernate's
TransactionManagerLookup strategy
To: Galder Zamarreño <galder(a)jboss.org>
Cc: Emmanuel Bernard <emmanuel(a)hibernate.org>, Hibernate
<hibernate-dev(a)lists.jboss.org>, infinispan -Dev List
<infinispan-dev(a)lists.jboss.org>
2011/2/2 Galder Zamarreño <galder(a)jboss.org>:
Hmmm, I already did a similar thing for Infinispan 2LC a while back:
https://github.com/galderz/hibernate-core/blob/master/hibernate-infinispa...
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/InfinispanTransactionMa...
>
> 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
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
6:16 a.m.
2011/2/2 Galder Zamarreño <galder(a)jboss.org>:
> Hmmm, I already did a similar thing for Infinispan 2LC a while back:
>
>
https://github.com/galderz/hibernate-core/blob/master/hibernate-infinispa...
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
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
6:22 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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.
6:26 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
6:47 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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
7:21 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
https://issues.jboss.org/browse/ISPN-911
7:41 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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).
7:51 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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?
7:53 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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)
7:54 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
7:58 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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).
8:10 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
8:38 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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.
9:16 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
10:13 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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.
2:45 p.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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
5:24 a.m.
New subject: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
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(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
5:30 a.m.
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(a)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(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5357
days inactive
5358
days old
infinispan-dev@lists.jboss.org
17 comments
5 participants
participants (5)
-
Manik Surtani -
Mircea Markus -
Sanne Grinovero -
Sanne Grinovero -
Vladimir Blagojevic