Re: [infinispan-dev] @Marshallable as an option for end user externalizers?
On Mar 17, 2011, at 7:14 PM, Eduardo Martins wrote:
</snip>
The proper solution, which is the only way to ensure everything will
always work, is to have a proper life cycle where externalizers are
set before cache starts, we have this already. IMHO what is really
missing in Infinispan, is a instantiated cache state before started,
as JBoss Cache has. It's really hard to come up with a final
configuration (including externalizers), before creating cache
instance. I believe it will be a big problem for reusing
configurations created and managed by JBoss AS, for instance it will
probably be very painful to add custom externalizers to such
configurations...
Eduardo, not sure if you're aware but there're some callback methods available via
classes that extend
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o....
That's what allows users or any of our submodules to enter their own custom
externalizers before the cache manager is started. You could define a lifecycle class to
add your own externalizers on cache manager startup. Did you already look into this? You
could invite any client apps to do the same if they wanna add their own externalizers too
and they wanna avoid having to touch the XML configuration.
Just to clarify you are indeed able to produce a configuration before any cache is
started, that's precisely what you can achieve with defineConfiguration() methods in
EmbeddedCacheManager. However, the only configuration options you can tweak are the Cache
level ones.
-- Eduardo
..............................................
http://emmartins.blogspot.com
http://redhat.com/solutions/telco
On Thu, Mar 17, 2011 at 5:06 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
>
> On Mar 17, 2011, at 3:22 PM, Manik Surtani wrote:
>
>>
>> On 17 Mar 2011, at 14:16, David M. Lloyd wrote:
>>
>>>>
>>>> Ah I see what you mean. Initially I thought you'd only need to
>>>> register the externaliser when you first encounter a new type (i.e.,
>>>> when a user defined type is first encountered with a put()), but this
>>>> may not be the case since on the remote node it may see the a new
>>>> magic number which may not be registered, and then you have a
>>>> problem.
>>>
>>> Marshalling will send Externalizers across the wire too, so the
>>> receiving side need not know about it in advance. The sending side can
>>> then do this kind of discovery safely. In addition, JBMAR already has
>>> the @org.jboss.marshalling.Externalize annotation which does just this.
>>>
>>> Unless you're talking about your own mechanism, anyway. Just thought
>>> I'd throw this bit out there.
>>
>> Sweet. I think we can make this work then - even reusing JBM's annotations.
>
> Hmmm, I wasn't aware of that either. I'll defo look into that for 5.0 -
https://issues.jboss.org/browse/ISPN-986
>
> @Eduardo, this might solve your cache startup issue and the current need to define
Externalizers in advance.
>
>>
>> --
>> 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
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache