Apologies for my long absence from this thread.
On 20 May 2011, at 15:28, Jason T. Greene wrote:
On 5/18/11 11:06 AM, Manik Surtani wrote:
1) Class loader per session/cache.
I like Jason/Sanne/Trustin's suggestions of a session-like contract, and
specifically I think this is best
On 20 May 2011, at 15:39, Jason T. Greene wrote:
So I think to ever justify it, it would take some very convincing
numbers that eager deserialization is indeed better.
Agreed.
--
Manik Surtani
ma...@jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
On 8 Jun 2011, at 11:42, Dan Berindei wrote:
Yes, no reason why the delegate Cache can't do this. These setters would
need to exist on the Cache interface though. For now, we should just
restrict to setClassLoader().
From an implementation perspective, given where we are with 5.0
On 8 Jun 2011, at 14:06, Pete Muir wrote:
We've decided that rather than swap out the TCCL (which is frankly a bit
error prone), to fix this properly and have it so that each time a class is
loaded it must select the classloaders it wants. To help, we will add an
On 5/18/11 11:06 AM, Manik Surtani wrote:
1) Class loader per session/cache.
I like Jason/Sanne/Trustin's suggestions of a session-like contract, and
specifically I think this is best achieved as a delegate to a cache, again as
suggested elsewhere by Pete, etc. E.g.,
Cache?, ?
On 5/19/11 5:11 AM, Manik Surtani wrote:
Guys - what are we talking about? Specifying ClassLoaders is only
meaningful if storeAsBinary is set to true.
In general, any situation where you have code booted off different
ClassLoaders running in the same JVM and sharing the same cache (or
cache
On Wed, May 18, 2011 at 7:06 PM, Manik Surtani ma...@jboss.org wrote:
Hi guys
Sorry I've been absent from this thread for a while now (it's been growing
faster than I've been able to deal with email backlog!)
Anyway, this is a very interesting discussion. To summarise - as Pete did at
On May 18, 2011, at 6:06 PM, Manik Surtani wrote:
Hi guys
Sorry I've been absent from this thread for a while now (it's been growing
faster than I've been able to deal with email backlog!)
Anyway, this is a very interesting discussion. To summarise - as Pete did at
some point - there
On May 18, 2011, at 6:06 PM, Manik Surtani wrote:
2) Class loader per invocation.
I've been less than happy with this, not just because it pollutes the API but
that it adds a layer of confusion. If all use cases discussed can be solved
with (1) above, then I'd prefer to just do that.
On May 19, 2011, at 11:45 AM, Galder Zamarreño wrote:
On May 18, 2011, at 6:06 PM, Manik Surtani wrote:
2) Class loader per invocation.
I've been less than happy with this, not just because it pollutes the API
but that it adds a layer of confusion. If all use cases discussed can be
On Thu, May 19, 2011 at 1:31 PM, Galder Zamarreño gal...@redhat.com wrote:
On May 19, 2011, at 12:11 PM, Manik Surtani wrote:
Guys - what are we talking about? Specifying ClassLoaders is only
meaningful if storeAsBinary is set to true.
Ok, that was not clear to me throughout the
On 4 May 2011, at 14:55, Dan Berindei wrote:
If V is SetMyObject then SetMyObject.class.getClassLoader() will
give you the system classloader, which in most cases won't be able the
MyObject class. It may not even be a SetMyObject of course, it could
be just Set?.
We could have a
On May 12, 2011, at 11:18 AM, Dan Berindei wrote:
On Wed, May 11, 2011 at 11:18 PM, David Bosschaert da...@redhat.com wrote:
On 11/05/2011 17:54, Dan Berindei wrote:
On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com wrote:
Were we developing for OSGi I would certainly agree with
On 16 May 2011, at 18:20, Galder Zamarreño wrote:
On May 12, 2011, at 11:18 AM, Dan Berindei wrote:
On Wed, May 11, 2011 at 11:18 PM, David Bosschaert da...@redhat.com wrote:
On 11/05/2011 17:54, Dan Berindei wrote:
On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com wrote:
Were
I don't like the TCCL either, so I'll repeat my suggestion from two
weeks ago to just have:
Cache c = cacheManager.getCache( cacheName, classLoader );
sounds reasonable to me to have the application declare it's intentions once ?
BTW I don't like
cache.get(K key, ClassV clazz)
as we're not
I don't enjoy using JBoss Logging for that reason :)
I always have to get down to the JavaDoc or figure out the list of available
params to understand what debug* does for example and which one I need.
I guess that's taste and for something like JBoss Logging, a fluent API is
costly
What about a helper that just returns a cache with a specific classloader
from a cache?
cache.withLoader(cl).get(K key)
-a
On Mon, May 16, 2011 at 11:14 AM, Galder Zamarreño gal...@redhat.comwrote:
On May 16, 2011, at 7:57 PM, Sanne Grinovero wrote:
I don't like the TCCL either, so I'll
2011/5/16 Pete Muir pm...@redhat.com:
This is the hibernate session style contract that Jason is talking about.
As the CM can be shared (e.g. in JNDI), then the same Cache object can be
returned in multiple applications in the app server, meaning you can't simply
associate the CL with a
BTW having thought about it more, this seems to be the only option that
actually works at the API level, even if it will require some re-eng in
Infinispan core.
On 16 May 2011, at 19:29, Pete Muir wrote:
On 16 May 2011, at 19:24, Sanne Grinovero wrote:
2011/5/16 Pete Muir
Not to be the guy that breaks the circle, how about the threads that
handle incoming RPCs from other nodes? With storeAsBinary=false
those threads have to unmarshal the objects in order to store them on
the local node, so we'd need a way to register a classloader with the
cache, not just with the
On 5/12/11 4:18 AM, Dan Berindei wrote:
On Wed, May 11, 2011 at 11:18 PM, David Bosschaertda...@redhat.com wrote:
On 11/05/2011 17:54, Dan Berindei wrote:
On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.comwrote:
Were we developing for OSGi I would certainly agree with you. However
On Fri, May 13, 2011 at 5:48 PM, Jason T. Greene
jason.gre...@redhat.com wrote:
On 5/12/11 4:18 AM, Dan Berindei wrote:
On Wed, May 11, 2011 at 11:18 PM, David Bosschaertda...@redhat.com
wrote:
On 11/05/2011 17:54, Dan Berindei wrote:
On Wed, May 11, 2011 at 7:08 PM, Pete
On Wed, May 11, 2011 at 11:18 PM, David Bosschaert da...@redhat.com wrote:
On 11/05/2011 17:54, Dan Berindei wrote:
On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com wrote:
Were we developing for OSGi I would certainly agree with you. However in
many environments today we can
On Thu, May 12, 2011 at 1:22 PM, Emmanuel Bernard
emman...@hibernate.org wrote:
On 12 mai 2011, at 11:18, Dan Berindei wrote:
That seems like a lot of overhead to me, and forcing the user to
provide the classloader doesn't seem that bad in comparison. Perhaps
we should use something other
Were we developing for OSGi I would certainly agree with you. However in many
environments today we can reasonably expect the TCCL to be set and to be able
to load the classes we need. So whilst making it part of the API is the safest
option, it's also making complicated an API for the sake of
On 11/05/2011 17:54, Dan Berindei wrote:
On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com wrote:
Were we developing for OSGi I would certainly agree with you. However in
many environments today we can reasonably expect the TCCL to be set and to
be able to load the classes we need.
On 9 May 2011, at 18:02, Galder Zamarreño wrote:
On May 9, 2011, at 7:01 PM, Galder Zamarreño wrote:
Guys,
It's funny that we're talking about this but this appears to be precisely
the use case that we don't support as per user forum post in:
If you have a Bundle object or BundleContext object you can figure out
what classloader is associated with that. Also, if you have a class from
a bundle you can find out what it's classloader is (obviously).
However, you need to have one of those things to find this out. There is
nothing
Guys,
It's funny that we're talking about this but this appears to be precisely the
use case that we don't support as per user forum post in:
http://community.jboss.org/thread/166080?tstart=0
Pete, do we have a JIRA for this? If not, would you mind creating one?
Cheers,
On May 9, 2011, at
On May 9, 2011, at 7:01 PM, Galder Zamarreño wrote:
Guys,
It's funny that we're talking about this but this appears to be precisely the
use case that we don't support as per user forum post in:
http://community.jboss.org/thread/166080?tstart=0
Pete, do we have a JIRA for this? If not,
Yeah, the bottom line is that the value of the TCCL is not defined by
the OSGi standards. You can define it yourself by setting it before you
call the relevant code but as said before this is ugly and it's actually
very error-prone because there's nothing in the API to remind you to do
it, so
On Thu, May 5, 2011 at 10:05 PM, Emmanuel Bernard
emman...@hibernate.org wrote:
Quick question.
In case of 2.a (ie setting the TCCL), this is a requirement for frameworks
and libraries using Infinispan, right? Not / never for a user application
using Infinispan (in this case it seems that
On May 4, 2011, at 4:08 PM, Pete Muir wrote:
On 4 May 2011, at 09:55, Dan Berindei wrote:
On Wed, May 4, 2011 at 7:18 AM, 이희승 (Trustin Lee) trus...@gmail.com
wrote:
On 05/03/2011 09:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM,
I talked about this with Emmanuel last night, and we were
a) concerned about the pollution of the API that this implies
b) not sure why we need to do this
So I also spoke to Jason to understand his initial motivation, and from this
chat I think it's clear that things have gone off course here.
On 5 May 2011, at 03:31, Galder Zamarreño wrote:
On May 4, 2011, at 4:08 PM, Pete Muir wrote:
On 4 May 2011, at 09:55, Dan Berindei wrote:
On Wed, May 4, 2011 at 7:18 AM, 이희승 (Trustin Lee) trus...@gmail.com
wrote:
On 05/03/2011 09:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승
On 05/05/2011 10:55, Pete Muir wrote:
I talked about this with Emmanuel last night, and we were
a) concerned about the pollution of the API that this implies
b) not sure why we need to do this
So I also spoke to Jason to understand his initial motivation, and from this
chat I think it's
On 05/05/2011 10:49 AM, David Bosschaert wrote:
On 05/05/2011 10:55, Pete Muir wrote:
I talked about this with Emmanuel last night, and we were
a) concerned about the pollution of the API that this implies
b) not sure why we need to do this
So I also spoke to Jason to understand his initial
Quick question.
In case of 2.a (ie setting the TCCL), this is a requirement for frameworks and
libraries using Infinispan, right? Not / never for a user application using
Infinispan (in this case it seems that the application class loader will do the
right thing and is set as the TCCL by the AS
On May 3, 2011, at 2:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani ma...@jboss.org:
On 1 May 2011, at 13:38, Pete Muir wrote:
As in, user API? That's a little intrusive... e.g., put(K,
(key);
T
From: Sanne Grinovero sanne.grinov...@gmail.com
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Mon, 2 May, 2011 21:08:47
Subject: Re: [infinispan-dev] [Pull Request] Modular Classloading
Compatibility
2011/5/2 Manik Surtani ma
On Wed, May 4, 2011 at 10:14 AM, Galder Zamarreño gal...@redhat.com wrote:
On May 3, 2011, at 2:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani ma...@jboss.org:
On 1 May 2011, at 13:38, Pete
On Wed, May 4, 2011 at 7:18 AM, 이희승 (Trustin Lee) trus...@gmail.com wrote:
On 05/03/2011 09:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani ma...@jboss.org:
On 1 May 2011, at 13:38, Pete Muir
On 4 May 2011, at 09:55, Dan Berindei wrote:
On Wed, May 4, 2011 at 7:18 AM, 이희승 (Trustin Lee) trus...@gmail.com wrote:
On 05/03/2011 09:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani
On 4 May 2011, at 05:34, Dan Berindei wrote:
On Wed, May 4, 2011 at 10:14 AM, Galder Zamarreño gal...@redhat.com wrote:
On May 3, 2011, at 2:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani
On Wed, May 4, 2011 at 5:09 PM, Pete Muir pm...@redhat.com wrote:
On 4 May 2011, at 05:34, Dan Berindei wrote:
On Wed, May 4, 2011 at 10:14 AM, Galder Zamarreño gal...@redhat.com wrote:
On May 3, 2011, at 2:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On
2011/5/4 Pete Muir pm...@redhat.com:
On 4 May 2011, at 09:55, Dan Berindei wrote:
On Wed, May 4, 2011 at 7:18 AM, 이희승 (Trustin Lee) trus...@gmail.com
wrote:
On 05/03/2011 09:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani ma...@jboss.org:
On 1 May 2011, at 13:38, Pete Muir wrote:
As in, user API? That's a little intrusive... e.g., put(K, V, cl) ?
Not for put, since you have the class, just get, and I was thinking
something more like:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani ma...@jboss.org:
On 1 May 2011, at 13:38, Pete Muir wrote:
As in, user API? That's a little intrusive... e.g., put(K, V, cl) ?
Not for put, since you have the class, just
On 2 May 2011, at 10:10, Manik Surtani wrote:
On 1 May 2011, at 13:38, Pete Muir wrote:
As in, user API? That's a little intrusive... e.g., put(K, V, cl) ?
Not for put, since you have the class, just get, and I was thinking
something more like:
Foo foo = getUsing(key, Foo.class)
On 05/03/2011 12:41 PM, Pete Muir wrote:
On 2 May 2011, at 10:10, Manik Surtani wrote:
On 1 May 2011, at 13:38, Pete Muir wrote:
As in, user API? That's a little intrusive... e.g., put(K, V, cl) ?
Not for put, since you have the class, just get, and I was thinking
something more like:
On 05/03/2011 09:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani ma...@jboss.org:
On 1 May 2011, at 13:38, Pete Muir wrote:
As in, user API? That's a little intrusive... e.g., put(K, V, cl) ?
On 1 May 2011, at 13:38, Pete Muir wrote:
As in, user API? That's a little intrusive... e.g., put(K, V, cl) ?
Not for put, since you have the class, just get, and I was thinking
something more like:
Foo foo = getUsing(key, Foo.class)
This would be a pretty useful addition to the API
I like this solution.
T
From: Manik Surtani ma...@jboss.org
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Mon, 2 May, 2011 15:10:03
Subject: Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
On 1 May 2011, at 13:38, Pete
sanne.grinov...@gmail.com
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Mon, 2 May, 2011 21:08:47
Subject: Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
2011/5/2 Manik Surtani ma...@jboss.org:
On 1 May 2011, at 13:38, Pete Muir wrote:
As in, user API? That's
On 29 Apr 2011, at 12:45, Jason T. Greene wrote:
On 4/28/11 4:52 PM, Manik Surtani wrote:
On 27 Apr 2011, at 12:39, Jason T. Greene wrote:
Available here:
https://github.com/infinispan/infinispan/pull/278
The problem is basically that infinispan currently is using TCCL for all
class
On 4/28/11 4:52 PM, Manik Surtani wrote:
On 27 Apr 2011, at 12:39, Jason T. Greene wrote:
Available here:
https://github.com/infinispan/infinispan/pull/278
The problem is basically that infinispan currently is using TCCL for all
class loading and resource loading. This has a lot of
56 matches
Mail list logo
