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

[Eduardo Martins]

David, in our (Mobicents Cluster framework) case, the actual
(un)marshall code is "interfaced", and depends on apps deployed, so
it's not granted that the externalizer will actually work. Also a
trouble in our case, in Mobicents we must rely in our own
classloading, due to "app version" isolation models not possible with
the AS classloader domains, and with that in mind considering that a
class may be loaded remotely is a big mess. Anyway, like I said, we
took our own precautions to define our framework in a way that it will
work in any possible setup, but also like I said, the current lifecyle
of Infinispan cache is too "short", restricts the usage too much, and
may become a big issue in AS7.

-- Eduardo
..............................................
http://emmartins.blogspot.com
http://redhat.com/solutions/telco



On Thu, Mar 17, 2011 at 6:44 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>