@Gustavo, some important info for your transcoding work below:
--
Galder Zamarreño
Infinispan, Red Hat
On 15 Jun 2017, at 11:05, Adrian Nistor <anistor(a)redhat.com>
wrote:
Hi Galder,
this fix is acceptable for now as it quickly enables users to use
CompatibilityProtoStreamMarshaller (provided by Infinispan), but in the long run we would
want users to be able to specify a custom marshaller class that comes from a user supplied
module or even a deployment - the general case.
With the introduction of encoders and deprecation of compat mode we still have the same
class loading issue in the general case. So I propose to refine a bit our approach and
instead of specifying just a class name we should use a naming schema like
"moduleId:slot:className", giving users the ability to specify a class that
comes from a different module or deployment. I'm currently experimenting with this.
I'll come back with results soon.
There are also other code bits that need to be deployed in the server ASAP: protostream
entity marshallers, lucene analyzers. I'm thinking these could all benefit from the
same solution.
I was able to easily get around the issue of deploying protostream entity marshallers by
simply adding a server tasks that did that:
https://github.com/infinispan-demos/swiss-transport-datagrid/blob/master/...
In fact, that server tasks acts serves as a way to add domain pojos to the system... So
when the server starts receiving data, it can deserialize it without problems.
However, there's a potential problem here you might want to consider in your work: If
I deploy the add protobuf task, write data, then redeploy the add protobuf task, then
retrieve some data, the system blows up because the classloader of the domain POJOs has
changed. So you'd start seeing ClassCastException errors...
That's why I think that even though in the past we'd store objects in deserialized
form, this could be problematic because you're committing to domain objects with a
given classloader...
The more I think about it, the more I think we should keep data only in binary format in
the server. IOW, we should never try to keep it in deserialized format. That way, no
matter how many times the domain objects are redeployed, assuming no compile-binary
changes, the lazy transcoding would work without problems.
Btw, what is the relation between ISPN-7814 and ISPN-7710 ?
The relationship between them is explained here:
https://github.com/infinispan-demos/swiss-transport-datagrid#infinispan-s...
I would strongly recommend that you give that demo repository a try, you might get new
ideas on the work you're doing.
Cheers,
Adrian
On 06/14/2017 06:35 PM, Galder Zamarreño wrote:
> Hi all,
>
> I'm seeing more and more people trying to do stuff like I did in [1] WRT to
running server tasks in server.
>
> One of the blockers is [2]. I know we have transcoding coming up but I wondered if we
could implement the quick hack of referencing remote-query.server module from root
org.infinispan module.
>
> So, in essence, adding the following to org/infinispan/main/module.xml:
>
> <module name="org.infinispan.remote-query.server"
optional="true"/>
>
> Once ISPN-7710 is in place, along with ISPN-7814, users can run the demos in [1]
without a custom server build.
>
> Cheers,
>
> [1]
https://github.com/infinispan-demos/swiss-transport-datagrid
> [2]
https://issues.jboss.org/browse/ISPN-7710
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev