[infinispan-dev] @Marshallable as an option for end user externalizers?

[Galder Zamarreño]

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/org/infinispan/lifecycle/AbstractModuleLifecycle.java. 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 at 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 at jboss.org
>>> twitter.com/maniksurtani
>>> 
>>> Lead, Infinispan
>>> http://www.infinispan.org
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 

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