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

[David M. Lloyd]

The classes have to be present at the destination, just as with any 
serializable class.  This means that if you have:

   @Externalize(Bar.class)
   public class Foo {
      ...
   }

in your module you must also have Bar in your class path.  But note that 
you need Bar present at compile time already; and, this annotation has 
runtime retention so you already have a runtime dependency anyway.

It would be extremely unlikely for someone to use this annotation 
without including the Externalizer class which is associated in the same 
module - that would be a very unusual thing to do.

On 03/17/2011 01:14 PM, Eduardo Martins wrote:
> Hi, so the marshaller is serialized, but what happens to the classes
> it marshalls? And even if whole dependencies are serialized too, in
> our case there are resources that needed to be initialized for it to
> work, in concrete "client" component jars need to be deployed.
>
> 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
> ..............................................
> 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
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
- DML