[infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache

[Paul Ferraro]

----- Original Message -----
> From: "Galder Zamarreño" <galder at redhat.com>
> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> Cc: hibernate-dev at lists.jboss.org, "jboss-as7-dev at lists.jboss.org Development" <jboss-as7-dev at lists.jboss.org>
> Sent: Tuesday, March 6, 2012 2:27:13 PM
> Subject: Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan	dependency for clustered JPA second level
> cache
> 
> So, to summarise all of this. What I suggest is this:
> 
> - Short term:
> The "quick fix" I suggest in
> http://lists.jboss.org/pipermail/infinispan-dev/2012-March/010317.html
> 
> - Medium term:
> Have a way to pass in marshalling configurations per cache manager
> and per-cache (or an abstraction of it), which allows the right
> class resolver to be passed in. (***)
> https://issues.jboss.org/browse/ISPN-1367
> 
> - Long term:
> https://issues.jboss.org/browse/ISPN-1413
> 
> (***) I still don't fully understand how web apps don't have the same
> issue as 2LC of not seeing Infinispan classes (Reminder: we're not
> talking about the contents of the cache, but about the Infinispan
> classes themselves).

To reiterate: in the case of web sessions, the cache instance for an application is associated with the classloader of the org.jboss.as.clustering.web.infinispan module.  The AS clustering code shields Infinispan from direct interaction with application objects by storing sessions as MarshalledValues which are eagerly marshalled into byte[] and lazily unmarshalled using an application-specific MarshallingConfiguration.
This has been the case since AS5, if not earlier (albeit using JBoss Serialization + JBoss Cache + TCCL manipulation).

> On Mar 6, 2012, at 8:19 PM, Galder Zamarreño wrote:
> 
> > 
> > On Mar 6, 2012, at 8:06 PM, David M. Lloyd wrote:
> > 
> >> On 03/06/2012 01:02 PM, Galder Zamarreño wrote:
> >>> On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
> >>> </snip>
> >>>> To work around this, we typically store MarshalledValues in the
> >>>> cache - which are marshalled/unmarshalled using a marshalling
> >>>> configuration specific to the application (e.g. via a
> >>>> ModularClassResolver using the ModuleLoader of the deployment
> >>>> unit).
> >>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/MarshalledValue.java
> >>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/SimpleMarshalledValue.java
> >>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/HashableMarshalledValue.java
> >>> 
> >>> Isn't a class resolver and a class loader, functionality wise,
> >>> doing the same thing? I wonder if a custom classloader could not
> >>> be built that delegates to a ModularClassResolver...
> >> 
> >> No, not really.  A class loader loads a class, given a name.  But
> >> a
> >> class resolver loads a class given a name *and* stream
> >> information.  The
> >> modular class resolver reads the stream information to know which
> >> class
> >> loader houses the class in question.  This is critically important
> >> because it's possible (common even) for more than one class to
> >> exist in
> >> an AS instance with the same name.  And there is no single class
> >> loader
> >> which has visibility to all classes which could potentially be
> >> stored in
> >> a cache.
> >> 
> >> Yes, accepting a class loader to use is a powerful feature.
> >>  However it
> >> *should* just be a convenience abstraction over a more fundamental
> >> feature which allows a class resolver to be set.
> > 
> > Thanks for the clarification, makes sense.
> > 
> > So, if I understand this correctly, Infinispan should really be
> > enhanced to accept global and per-cache class resolvers, or more
> > globally, as paul suggested below, marshalling configuration
> > instances (or abstractions of them).
> > 
> > I think https://issues.jboss.org/browse/ISPN-1367 should be
> > reporpoused to do this.
> > 
> >> 
> >>>> So, essentially Infinispan itself only ever has to
> >>>> marshal/unmarshal a byte[] wrapper - so the AS has full control
> >>>> over the marshalling process.
> >>>> 
> >>>> I would recommend that the 2LC do something similar, and include
> >>>> a mechanism for providing a MarshallingConfiguration per
> >>>> persistence unit.
> >>> 
> >>> Possibly…
> >>> 
> >>> --
> >>> Galder Zamarreño
> >>> Sr. Software Engineer
> >>> Infinispan, JBoss Cache
> >>> 
> >> 
> >> 
> >> --
> >> - DML
> >> _______________________________________________
> >> 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
> 
> --
> 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
>