Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
Message-ID: <SNT147-W39F7CA762EF694B03B2E00CF2A0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_850aa6d4-aa9c-45d3-a0b3-b71821e3be61_"
From: Andrey Kornev <andrewkornev@hotmail.com>
To: "dev@ignite.apache.org" <dev@ignite.apache.org>
Subject: RE: OSGi migration may require a special marshaller
Date: Wed, 4 Nov 2015 07:48:48 -0800
Importance: Normal
In-Reply-To: 
 <CAKoNANsosguFk5WvaTtu_XQiB5EhXbdbcGtDnT8j-ZP-yoD-ng@mail.gmail.com>
References: 
 <AM4PR06MB15054C7FCE6CC67149947C4AE82C0@AM4PR06MB1505.eurprd06.prod.outlook.com>,<CAKoNANvA65rRd6N8XUXJxiW=oN=et_Kzt3=O+UJEGXs25npqcw@mail.gmail.com>,<SNT147-W71ACEA4350127097EAE368CF2C0@phx.gbl>,<CAKoNANuXuqS=McrXcX85xLL2wKRzsTTpD0VP-k3r_4xEOMijzQ@mail.gmail.com>,<CAHG4OXubd7C_vhaNq6YGAgOp1F4RgAgHtSrSoGQXL+G_jCiGeQ@mail.gmail.com>,<CA+0=VoWvxnzZ2fQb-XTKp2B=BW2kXK_yQ17_J7XG3Frj-MBPnQ@mail.gmail.com>,<CAHG4OXvCP6yKfTQf1D=ikjERvY4PubZNa5NSY+NMGUuijqGm5Q@mail.gmail.com>,<SNT147-W927545618FB28FBA6CF02BCF2B0@phx.gbl>,<CAHG4OXtn4SChjjNPmkR3xOycNicrqKtj9TbXzwh7+kCXUOQC6g@mail.gmail.com>,<CA+0=VoUTdmCOh-96=6AnfhgcJ5J1cWdUjtkhYfAfp2VY87pvZw@mail.gmail.com>,<SNT147-W275F63D4B5366FAAE1F038CF2A0@phx.gbl>,<CA+0=VoX1xD4JNMNchxPUeBNoANoZCV9U0UH-gpdDqdVy1oHgeQ@mail.gmail.com>,<CAKoNANsosguFk5WvaTtu_XQiB5EhXbdbcGtDnT8j-ZP-yoD-ng@mail.gmail.com>
MIME-Version: 1.0

--_850aa6d4-aa9c-45d3-a0b3-b71821e3be61_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Raul=2C

While we're waiting for the specific proposal(s) from you=2C I'd like to po=
int out that OSGi bundle is much more than just a jar or a packaging unit. =
First and foremost an OSGi bundle is also a class loader unlike the jars in=
 non-OSGi environment. We're after the class loader hence the proposal to u=
se the bundle symbolic name and bundle version for serialization of the *cl=
ass loader*.

Have a safe trip and please=2C do get back to us at your earliest.

Regards
Andrey

> Date: Wed=2C 4 Nov 2015 10:56:32 +0000
> Subject: Re: OSGi migration may require a special marshaller
> From: raul@evosent.com
> To: dev@ignite.apache.org
>=20
> Could we rewind a little bit please? What is the point of using the bundl=
e
> symbolic name in the first place?
>=20
> In OSGi=2C it is bad practice to refer to bundles directly. A bundle is a
> packaging unit=2C that's all=2C but it should not have any further
> consideration.
>=20
> It is perfectly feasible that a given package is exported by bundle A in =
a
> container=2C and by bundle B in another. One should not make any assumpti=
ons
> in that regard. A simple example of this is an enterprise-wide deployment
> of Ignite=2C where multiple apps in different OSGi containers share cache
> entities. Why would one expect these entities to be hosted in the same
> bundle across all apps?
>=20
> Referring to a bundle in OSGi world is like referring to a JAR in a norma=
l
> Java environment. One would not always expect to resolve class A.B.C from
> bundle xyz-1.2.3.jar=2C right? You would resolve from the classpath.
>=20
> There are other mechanisms to reach into the OSGi environment and resolve=
 a
> class arbitrarily from another bundle. Some of which I've pointed out. Bu=
t
> relying on a bundle symbolic name receives an -1 from me.
>=20
> Can't elaborate now=2C I'm travelling.
>=20
> Will get back to my office tomorrow and I'll dig deeper into possibilitie=
s.
>=20
> Regards=2C
> Ra=FAl.
> On 4 Nov 2015 03:07=2C "Dmitriy Setrakyan" <dsetrakyan@apache.org> wrote:
>=20
> > Andrey=2C et al=2C
> >
> > Can you provide a way on how to get a required Bundle object based on=
=2C say=2C
> > bundle symbolic name and version?
> >
> > I have reached the end of the internet trying to find a way in OSGI to =
look
> > up a Bundle based on something other than an actual Class belonging to =
that
> > bundle=2C but no luck.
> >
> > D.
> >
> > On Tue=2C Nov 3=2C 2015 at 5:15 PM=2C Andrey Kornev <andrewkornev@hotma=
il.com>
> > wrote:
> >
> > > Dmitriy=2C
> > >
> > > I think your approach will work=2C but I let Romain respond.
> > >
> > > Also=2C in terms of the implementation=2C please keep in mind that th=
e
> > > resolver must be called for each non-JDK and non-Ignite core class (i=
t
> > > would probably make sense to eschew storing class loaders for such
> > classes
> > > in favor of compactness of the serialized representation -- see below=
).
> > > Also=2C it's worth keeping a cache of already resolved class loaders =
per
> > > marshaller invocation (this is probably the context that Romain has
> > > mentioned in his previous posting) to minimize the number of the reso=
lver
> > > calls.
> > >
> > > In terms of the resolver's implementation=2C the simplest way to seri=
alize
> > > the class loader would be by capturing two pieces of information (bot=
h
> > > strings): the bundle symbolic name and the bundle version. This appro=
ach
> > > however may result in bloating of the serialized representation: I'd
> > > roughly estimate the overhead per element to be at least 20-30 bytes =
(the
> > > length of the symbolic name string=2C plus the length of the version
> > string).
> > > There are way to reduce the overhead (like serializing the hash code =
of
> > the
> > > bundle id string rather than the string itself=2C and then come up wi=
th a
> > > clever way of resolving the hash collisions)=2C but they all come at =
cost
> > of
> > > increased complexity...
> > >
> > > An alternative approach would be rely on the special bundle id which =
is
> > an
> > > integer and is generated by the OSGi container. But in this case=2C a=
ll
> > nodes
> > > must ensure that all the bundles have consistent ids (bundle A with i=
d 42
> > > on node N1=2C has the same id on every other node) which is not easy =
--
> > while
> > > not entirely impossible -- to guarantee. As long as the nodes are
> > > homogeneous (have the same set of bundles deployed) the OSGi containe=
r is
> > > guaranteed to assign to the bundles the same ids.
> > >
> > > Thanks
> > > Andrey
> > >
> > > > From: dsetrakyan@apache.org
> > > > Date: Tue=2C 3 Nov 2015 16:29:41 -0800
> > > > Subject: Re: OSGi migration may require a special marshaller
> > > > To: dev@ignite.apache.org
> > > >
> > > > Romain=2C
> > > >
> > > > In the upcoming release we will be deprecating the OptimizedMarshal=
ler
> > > and
> > > > will be switching to a default internal marshaller (which is based =
on
> > the
> > > > new PortableMarshaller donated by GridGain).
> > > >
> > > > Having said that=2C we may be able to pass BinaryWriter and BinaryR=
eader
> > > > instead of byte arrays. This will be pretty close to passing the
> > stream=2C
> > > as
> > > > suggested by Andrey.
> > > >
> > > > Also=2C I still think that we should only resolve class loaders and=
 not
> > the
> > > > class itself. The main reason is that Ignite will encode class name=
s
> > into
> > > > an integer hash code and will store the integer->class-fqn mapping =
in
> > > > internal replicated cache. I doubt users will get more efficient th=
an
> > an
> > > > integer (4 bytes) for a class name.
> > > >
> > > > On the receiving side=2C once we are able to get the right class lo=
ader=2C
> > we
> > > > can easily get the proper class by calling
> > > ClassLoader.findClass(class-fqn).
> > > >
> > > > Thoughts?
> > > >
> > > > D.
> > > >
> > > > On Tue=2C Nov 3=2C 2015 at 2:01 PM=2C Romain Gilles <romain.gilles@=
gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hi=2C
> > > > > Maybe a missing point. I think but I'm not sure that in the
> > > > > OptimizedMarshaller there is a caching of already serialized clas=
ses.
> > > Due
> > > > > to the dynamic nature of OSGi this may lead to memory leak. In fa=
ct
> > if
> > > a
> > > > > bundle is refreshed=2C it will produce a new BundleRevision and
> > > therefore a
> > > > > new classloader. And if you don't release the class from the prev=
ious
> > > > > BundleRevision then you endup with memory leak. So maybe the
> > Marshaller
> > > > > interface or somewhere should provide a way to free those classes=
 /
> > > > > classloaders.
> > > > >
> > > > > Regards=2C
> > > > >
> > > > > Romain
> > > > >
> > > > > Le mar. 3 nov. 2015 =E0 22:42=2C Andrey Kornev <andrewkornev@hotm=
ail.com
> > >
> > > a
> > > > > =E9crit :
> > > > >
> > > > > > Romain/Dmitriy=2C
> > > > > >
> > > > > > I prefer Romain's approach=2C but just curious=2C in the API yo=
u guys
> > are
> > > > > > proposing why use a byte[] rather than OutputStream/InputStream=
?
> > > With a
> > > > > > byte[]=2C one would inevitably end up wrapping it into a byte s=
tream
> > > class.
> > > > > > Also=2C the stream-based interface would be more in line with t=
he
> > > > > Marshaller
> > > > > > API.
> > > > > >
> > > > > > Also for symmetry with the readClass() method=2C I suggest the
> > > writeClass()
> > > > > > take a Class<?> rather than an object.
> > > > > >
> > > > > > Regards
> > > > > > Andrey
> > > > > >
> > > > > > > From: romain.gilles@gmail.com
> > > > > > > Date: Tue=2C 3 Nov 2015 21:24:01 +0000
> > > > > > > Subject: Re: OSGi migration may require a special marshaller
> > > > > > > To: dev@ignite.apache.org
> > > > > > >
> > > > > > > Hi Dmitriy=2C
> > > > > > > I think your solution is good. Maybe I will change it a littl=
e
> > > bit...
> > > > > :P
> > > > > > > I think you should delegate the Class resolution to the resol=
ver.
> > > > > Because
> > > > > > > for example with your current solution the marshaller may bef=
ore
> > > (or
> > > > > > after)
> > > > > > > store the fqn of the class (maybe only the first time it
> > encounter
> > > it)
> > > > > > but
> > > > > > > in order to save the classloader context resolution the
> > > implementation
> > > > > of
> > > > > > > the resolver may have to save the package name of the given
> > object
> > > and
> > > > > > some
> > > > > > > extra info therefore the content package name will be seriali=
zed
> > > two
> > > > > > times.
> > > > > > > Ok=2C it's not a big deal.
> > > > > > > But now if the resolver identify that it can reuse the same c=
lass
> > > > > loader
> > > > > > > for a couple of classes. It will be interesting for it to hav=
e a
> > > > > > > serialization context in order to save=2C let say=2C classloa=
der/id
> > > mapping
> > > > > > in
> > > > > > > order to save the id instead of a more longer representation.
> > > > > > > So I propose something like that:
> > > > > > > *public interface ClassResolver {*
> > > > > > > *    // This method is invoked on the sender side to *
> > > > > > > *    // marshal the information about the class.*
> > > > > > > *    // where the context is a map style object that is reset=
/new
> > > for
> > > > > > each
> > > > > > > object graph serialization.*
> > > > > > > *    public byte[] writeClass(Object o=2C Context context) th=
rows
> > > > > > > IgniteException=3B*
> > > > > > >
> > > > > > > *    // This method is invoked on the receiving side to*
> > > > > > > *    // retrieve the class based on provided information.*
> > > > > > > *    // where the context is a map style object that is reset=
/new
> > > for
> > > > > > each
> > > > > > > object graph serialization.*
> > > > > > > *    public Class<?> readClass(byte[]=2C Context context) thr=
ows
> > > > > > > IgniteException=3B*
> > > > > > > *}*
> > > > > > >
> > > > > > > I think your proposal will solve our issue and maybe also ope=
n a
> > > door
> > > > > for
> > > > > > > the osgi development.
> > > > > > > Let me know what do you think about me proposal? :)
> > > > > > >
> > > > > > > Thanks=2C
> > > > > > >
> > > > > > > Romain
> > > > > > >
> > > > > > > Le mar. 3 nov. 2015 =E0 20:05=2C Dmitriy Setrakyan <
> > > dsetrakyan@apache.org>
> > > > > a
> > > > > > > =E9crit :
> > > > > > >
> > > > > > > > Romain=2C
> > > > > > > >
> > > > > > > > Can you comment on the ClassLoaderResolver suggestion that =
I
> > > proposed
> > > > > > > > earlier? Will it solve your problem?
> > > > > > > >
> > > > > > > > D.
> > > > > > > >
> > > > > > > > On Tue=2C Nov 3=2C 2015 at 2:38 AM=2C Romain Gilles <
> > > > > romain.gilles@gmail.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Raul=2C
> > > > > > > > >  - Do you plan to use the TCCL when marshalling in OSGi e=
nv?
> > > If yes
> > > > > > how?
> > > > > > > > >  - I like the point 2. Maybe for a graph of object that c=
ome
> > > from
> > > > > > > > different
> > > > > > > > > packages / bundles you may have to recursively capture th=
e
> > > package
> > > > > > > > version
> > > > > > > > > of the individual element of your graph.
> > > > > > > > >  - For the point 3 I wonder if it will not over-complexif=
y
> > the
> > > > > > solution.
> > > > > > > > As
> > > > > > > > > a developer you will have to think about it. And it is no=
t
> > > obvious
> > > > > > in the
> > > > > > > > > code where things are serialized or not. You may use lamb=
da
> > in
> > > your
> > > > > > > > > application code therefore the current package become wha=
t
> > you
> > > call
> > > > > > a DTO
> > > > > > > > > package. The current state of ignite does not enforce you=
 to
> > > > > specify
> > > > > > it
> > > > > > > > for
> > > > > > > > > "classical" classloading application. If you introduce th=
is
> > > extra
> > > > > > step
> > > > > > > > for
> > > > > > > > > OSGi ready application you will maybe discourage people t=
o
> > use
> > > > > OSGi.
> > > > > > > > >
> > > > > > > > > To comeback to our solution. We start we a strong assumpt=
ion:
> > > our
> > > > > > cluster
> > > > > > > > > is homogeneous in term of code so=2C of course=2C it simp=
lify our
> > > life
> > > > > > :).
> > > > > > > > >
> > > > > > > > > BTW if you can introduce an extension point in the class
> > > resolution
> > > > > > > > > mechanism it can be interesting for end user in order to
> > allow
> > > them
> > > > > > to
> > > > > > > > > optimize it based on there specific use cases.
> > > > > > > > >
> > > > > > > > > Romain.
> > > > > > > > >
> > > > > > > > > Le mar. 3 nov. 2015 =E0 00:21=2C Raul Kripalani <
> > raul@evosent.com>
> > > a
> > > > > > =E9crit :
> > > > > > > > >
> > > > > > > > > > Hi Andrey=2C
> > > > > > > > > >
> > > > > > > > > > Thanks for the participation in this topic.
> > > > > > > > > >
> > > > > > > > > > I don't like the solution to incorporate the bundle
> > symbolic
> > > name
> > > > > > in
> > > > > > > > the
> > > > > > > > > > serialised form. Nothing guarantees that the classdef w=
ill
> > be
> > > > > > located
> > > > > > > > > under
> > > > > > > > > > the same bundle in both source and target machines. We =
also
> > > have
> > > > > to
> > > > > > > > take
> > > > > > > > > > into account that OSGi allows for multiple versions of =
the
> > > same
> > > > > > > > > > bundle/packages to co-exist in the same  container. So =
it
> > > becomes
> > > > > > more
> > > > > > > > > > complex.
> > > > > > > > > >
> > > > > > > > > > Using the TCCL should work when serialising=2C but it'l=
l
> > > probably
> > > > > be
> > > > > > of
> > > > > > > > no
> > > > > > > > > > use when deserialising on the other end.
> > > > > > > > > >
> > > > > > > > > > I need to enhance Ignite to:
> > > > > > > > > >
> > > > > > > > > > 1. Use the TCCL when marshalling on one end.
> > > > > > > > > > 2. Incorporate the package version of the class in the
> > > serialised
> > > > > > form
> > > > > > > > if
> > > > > > > > > > Ignite is running in an OSGi environment.
> > > > > > > > > > 3. On the receiver end=2C discover cache entities / DTO=
s in
> > all
> > > > > > bundles
> > > > > > > > > > through a custom OSGi manifest header or the like=2C as=
 I
> > > explained
> > > > > > > > before.
> > > > > > > > > > Package version must be taken into account.
> > > > > > > > > >
> > > > > > > > > > What do you think?
> > > > > > > > > >
> > > > > > > > > > Ra=FAl.
> > > > > > > > > > On 2 Nov 2015 17:25=2C "Andrey Kornev" <
> > > andrewkornev@hotmail.com>
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Raul=2C
> > > > > > > > > > >
> > > > > > > > > > > The fundamental hurdle we need to jump over to make
> > Ignite
> > > > > > > > OSGi-enabled
> > > > > > > > > > is
> > > > > > > > > > > the marshalling. More specifically the issue is with
> > > > > > deserialization
> > > > > > > > of
> > > > > > > > > > the
> > > > > > > > > > > classes that are provided by the bundles other than t=
he
> > > Ignite
> > > > > > bundle
> > > > > > > > > > > itself.
> > > > > > > > > > >
> > > > > > > > > > > When the Ignite transport layer receives a message it
> > > needs to
> > > > > > figure
> > > > > > > > > out
> > > > > > > > > > > how to deserialize the bytes and for that it needs to
> > know
> > > the
> > > > > > bundle
> > > > > > > > > > that
> > > > > > > > > > > provides the class to be deserailized. At this point =
TCCL
> > > is of
> > > > > > no
> > > > > > > > use.
> > > > > > > > > > To
> > > > > > > > > > > make things more complex=2C the class may contain oth=
er
> > > classes
> > > > > > that
> > > > > > > > come
> > > > > > > > > > > from other bundles=2C and so on recursively. This mea=
ns
> > that
> > > each
> > > > > > > > object
> > > > > > > > > in
> > > > > > > > > > > the hierarchy must be serialized with its bundle name=
 (or
> > > > > bundle
> > > > > > id)=2C
> > > > > > > > > so
> > > > > > > > > > > that the deserializer will then be able to correctly
> > > resolve
> > > > > the
> > > > > > > > class
> > > > > > > > > > > while traversing the object hierarchy during
> > > deserialization.
> > > > > > > > > > >
> > > > > > > > > > > Unfortunately=2C Ignite's OptimizedMarshaller is lack=
ing
> > the
> > > > > > ability to
> > > > > > > > > > plug
> > > > > > > > > > > in a custom class resolver. Romain's solution was to =
use
> > > Kryo
> > > > > > that
> > > > > > > > does
> > > > > > > > > > > provide a way to customize class resolution. It has
> > solved
> > > the
> > > > > > > > problem
> > > > > > > > > of
> > > > > > > > > > > capturing the bundle info and he was able to successf=
ully
> > > run
> > > > > > Ignite
> > > > > > > > > as a
> > > > > > > > > > > bundle in an OSGi container (after some repackaging a=
nd
> > > > > > inclusion of
> > > > > > > > > the
> > > > > > > > > > > manifest). But Kryo-based marshalling introduced a lo=
t of
> > > > > > complexity
> > > > > > > > to
> > > > > > > > > > the
> > > > > > > > > > > code and incorrect use of Kryo's numerous serializers
> > > caused
> > > > > some
> > > > > > > > weird
> > > > > > > > > > > hard-to-debug issues in the Ignite core (like duplica=
te
> > > cache
> > > > > > entries
> > > > > > > > > due
> > > > > > > > > > > to incorrect marshalling of the GridDhtPArtitonFullMa=
p
> > > class --
> > > > > > go
> > > > > > > > > > > figure!). Overall the Kryo-based solution is brittle =
and
> > > hard
> > > > > to
> > > > > > > > > > maintain.
> > > > > > > > > > >
> > > > > > > > > > > I feel the correct solution to OSGi problem would be =
to
> > > > > > > > > > > 1) enhance the OptimizedMarshaller to allow custom cl=
ass
> > > > > > resolution.
> > > > > > > > > > > 2) provide an OSGi-enabled OptimizedMarshaller (in
> > > addition to
> > > > > > the
> > > > > > > > > > > original one) to be used in OSGi environment.
> > > > > > > > > > >
> > > > > > > > > > > Regards
> > > > > > > > > > > Andrey
> > > > > > > > > > >
> > > > > > > > > > > > From: raulk@apache.org
> > > > > > > > > > > > Date: Mon=2C 2 Nov 2015 12:41:47 +0000
> > > > > > > > > > > > Subject: Re: OSGi migration may require a special
> > > marshaller
> > > > > > > > > > > > To: dev@ignite.apache.org
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Romain=2C
> > > > > > > > > > > >
> > > > > > > > > > > > I'm working on the OSGi compatibility of Ignite. I
> > > appreciate
> > > > > > your
> > > > > > > > > > input.
> > > > > > > > > > > >
> > > > > > > > > > > > I'm thinking about the situation you describe and I
> > > wonder if
> > > > > > > > you're
> > > > > > > > > > > > exporting Ignite as an OSGi service which is then
> > > consumed
> > > > > from
> > > > > > > > other
> > > > > > > > > > > > bundles. Under this situation=2C it would be quite =
easy
> > to
> > > > > > reproduce
> > > > > > > > > the
> > > > > > > > > > > > behaviour you describe if Ignite is not resolving
> > > classes via
> > > > > > the
> > > > > > > > > TCCL.
> > > > > > > > > > > > Need to dig deeper into that.
> > > > > > > > > > > >
> > > > > > > > > > > > Off the top of my head=2C there are two alternative=
s to
> > > solve
> > > > > it:
> > > > > > > > > > > >
> > > > > > > > > > > > 1. Use the TCCL for marshalling/unmarshalling (if n=
ot
> > > already
> > > > > > > > used) =96
> > > > > > > > > > we
> > > > > > > > > > > > gotta be wary of possible regressions.
> > > > > > > > > > > > 2. Create a special OSGi header Ignite-Export-Packa=
ge
> > so
> > > that
> > > > > > > > bundles
> > > > > > > > > > > > containing DTOs can expose packages to Ignite's
> > > marshallers.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards=2C
> > > > > > > > > > > >
> > > > > > > > > > > > *Ra=FAl Kripalani*
> > > > > > > > > > > > PMC & Committer @ Apache Ignite=2C Apache Camel |
> > > Integration=2C
> > > > > > Big
> > > > > > > > Data
> > > > > > > > > > and
> > > > > > > > > > > > Messaging Engineer
> > > > > > > > > > > > http://about.me/raulkripalani |
> > > > > > > > > > http://www.linkedin.com/in/raulkripalani
> > > > > > > > > > > > http://blog.raulkr.net | twitter: @raulvk
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon=2C Nov 2=2C 2015 at 9:56 AM=2C Gilles=2C Rom=
ain <
> > > > > > > > > > romain.gilles@misys.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi all=2C
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm really interested in this issue:
> > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-1270=
 .
> > We
> > > > > some
> > > > > > > > stuff
> > > > > > > > > to
> > > > > > > > > > > make
> > > > > > > > > > > > > it work in our osgi environment. The main issue f=
or
> > us
> > > now
> > > > > > is the
> > > > > > > > > > > > > serialization. I think it you will have to rework=
 the
> > > > > > > > > > > OptimizedMarshaller
> > > > > > > > > > > > > or any other marshaller that works with object th=
at
> > > come
> > > > > from
> > > > > > > > > outside
> > > > > > > > > > > your
> > > > > > > > > > > > > class space.
> > > > > > > > > > > > >
> > > > > > > > > > > > > We have try kryo that works. Kryo provide an
> > extension
> > > > > point
> > > > > > in
> > > > > > > > > order
> > > > > > > > > > > to
> > > > > > > > > > > > > resolve the classes:
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > >
> > https://github.com/EsotericSoftware/kryo/blob/master/src/com/esotericso=
ftware/kryo/ClassResolver.java
> > > > > > > > > > > > > . With this extension we are able to solve the
> > problem
> > > of
> > > > > > > > external
> > > > > > > > > > > classes.
> > > > > > > > > > > > > The only issue with kryo is that some classes nee=
d a
> > > > > certain
> > > > > > care
> > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > > > serialization process and therefore a specialized
> > > > > serializer.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So I would like to know from the community what d=
o
> > > think of
> > > > > > > > > changing
> > > > > > > > > > > the
> > > > > > > > > > > > > way the optimized marshaller works or introducing=
 the
> > > > > > support of
> > > > > > > > > yet
> > > > > > > > > > > > > another marshaller based on a kryo like technolog=
y?
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks in advance=2C
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Best regards=2C
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Romain.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > PS: I'm ready to help in the both cases.
> > > > > > > > > > > > > "Misys" is the trade name of the Misys group of
> > > companies.
> > > > > > This
> > > > > > > > > email
> > > > > > > > > > > and
> > > > > > > > > > > > > any attachments have been scanned for known virus=
es
> > > using
> > > > > > > > multiple
> > > > > > > > > > > > > scanners. This email message is intended for the
> > named
> > > > > > recipient
> > > > > > > > > > only.
> > > > > > > > > > > It
> > > > > > > > > > > > > may be privileged and/or confidential. If you are=
 not
> > > the
> > > > > > named
> > > > > > > > > > > recipient
> > > > > > > > > > > > > of this email please notify us immediately and do=
 not
> > > copy
> > > > > > it or
> > > > > > > > > use
> > > > > > > > > > > it for
> > > > > > > > > > > > > any purpose=2C nor disclose its contents to any o=
ther
> > > person.
> > > > > > This
> > > > > > > > > > email
> > > > > > > > > > > does
> > > > > > > > > > > > > not constitute the commencement of legal relation=
s
> > > between
> > > > > > you
> > > > > > > > and
> > > > > > > > > > > Misys.
> > > > > > > > > > > > > Please refer to the executed contract between you=
 and
> > > the
> > > > > > > > relevant
> > > > > > > > > > > member
> > > > > > > > > > > > > of the Misys group for the identity of the
> > contracting
> > > > > party
> > > > > > with
> > > > > > > > > > > which you
> > > > > > > > > > > > > are dealing.
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > >
> > >
> >
 		 	   		  =

--_850aa6d4-aa9c-45d3-a0b3-b71821e3be61_--