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(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
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev