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 (unnecessary object creation etc).
On 16 mai 2011, at 20:01, David M. Lloyd wrote:
> As a rule I've never cared about exploding the number of methods on an
> API class as long as:
>
> 1. There are few basic functions - i.e. get is get, and regardless of
> which overload we're talking about it behaves consistently - and the
> large number of methods is due mainly to overloads
> 2. The end user is not expected to ever need to implement the interface
>
> For example, org.jboss.logging.Logger has about a zillion methods but
> they all boil down to: log, trace, debug, info, warn, error, fatal. So,
> there's relatively little confusion possible.
>
> Just FWIW...
>
> On 05/16/2011 12:57 PM, Sanne Grinovero wrote:
>> 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, Class<V> clazz)"
>>
>> as we're not speaking only about the get(K) method, but about many
>> methods and this will explode the number of method of Cache; on the
>> other hand I think it;s acceptable to have a single Cache instance
>> used by a single application/classloader. You can still have multiple
>> applications share the same underlying cache and use different
>> classloaders:
>>
>> getCache( cacheName, classLoader ) would return a delegate to the
>> original cache, having a specific marshaller in the invocation context
>> as Trustin was suggesting.
>>
>> Cheers,
>> Sanne
>>
>>
>> 2011/5/16 Pete Muir<pm...@redhat.com>:
>>>
>>> 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 Muir<pm...@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. So whilst making it part
>>>>>>>> of the API is the safest option, it's also making complicated an API
>>>>>>>> for the sake of the few at the cost of the many. Further this also
>>>>>>>> seems kinda nasty to me. We know the class (and hence bundle/module)
>>>>>>>> when we put the object into Infinispan, therefore why do we require
>>>>>>>> people to respecify this again?
>>>>>>>>
>>>>>>>> David, can we not actually do something here akin to what we are
>>>>>>>> discussing for Weld? Whereby we can serialize out the bundle id and
>>>>>>>> then find the correct CL based on that when we deserialize.
>>>>>>> What if the object is a java.util.ArrayList? Each element in the list
>>>>>>> could belong to a different bundle, so you'd have to write a bundle id
>>>>>>> for every element in the list.
>>>>>> Yes, if you know the Bundle-SymbolicName and Version (or the Bundle ID)
>>>>>> you can find its classloader.
>>>>>>
>>>>>> On the other question, if you're passing in a class object then you can
>>>>>> obtain its classloader and hence the bundle where it came from. But, and
>>>>>> I think this is what Dan allused to above, is it always true that the
>>>>>> class your passing in comes from the bundle that you need to have or
>>>>>> could it also come from one of its parent class loaders?
>>>>>>
>>>>>
>>>>> Exactly David, sorry if my message was a little cryptic. I think in
>>>>> order to handle every case properly you would have to go through the
>>>>> entire object graph being stored in the cache in order to find all the
>>>>> classloaders/bundle ids that you will need on get().
>>>>>
>>>>> 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 than a thread-local for this though, so
>>>>> that users can do a onto the result of a
>>>>> cacheManager.getCache("A").usingClassLoader(A.class) and never have to
>>>>> provide the classloader again.
>>>>>
>>>>> In fact I think this is a good idea for the invocation flags we
>>>>> already have, too. It would involve creating lots of overloads in
>>>>> CacheDelegate with a PreInvocationContext parameter and a new
>>>>> CacheDelegateWithContext class to invoke those methods, but the public
>>>>> API would remain the same.
>>>>
>>>> No matter how I look at it, putting a classloader in a thread local makes
>>>> me shiver.
>>>
>>> I also wonder why we want do this, given we already have a construct called
>>> the Thread Local Context Classloader ;-)
>>>
>>> Either we use that, or use some other mechanism.
>>>
>>>> Just imagine the mayhem you can cause if you "forget" to clear the thread
>>>> local.
>>>>
>>>> I've done enough of Apache Commons Logging support to understand that you
>>>> should limit the references to classloaders to the minimum, particularly
>>>> in system classes/infrastructure.
>>>>
>>>> If we need to end up forcing users to register classloaders in these
>>>> scenarions, we need to do it in such way that either:
>>>>
>>>> - we can detect these leaks (it might be a bit primitive now but old JBoss
>>>> JCA code had an interesting way of discovering unclosed open connections)
>>>>
>>>> - if we give you on trying to detect them, the impact of a leak is reduced
>>>> as much as possible.
>>>>
>>>> Cheers,
>>>> --
>>>> Galder Zamarreño
>>>> Sr. Software Engineer
>>>> Infinispan, JBoss Cache
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> - DML
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
