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

[Paul Ferraro]

----- Original Message -----
> From: "Scott Marlow" <smarlow 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>,
> "Galder Zamarreño" <galder at redhat.com>
> Sent: Tuesday, March 6, 2012 2:45:03 PM
> Subject: Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level
> cache
> 
> On 03/06/2012 02:27 PM, Galder Zamarreño wrote:
> > 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
> 
> Do we want to try this (requires a new build of Infinispan I think)?
>  Or
> should applications workaround the issue until we can reach the
> medium/long term?
> 
> >
> > - 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
> 
> ISPN-1367 is targeted to Infinispan 5.2, any idea of the target
> release
> date for that?  I'm curious as to which AS release it might align
> with.
> 
> >
> > - 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).
> 
> https://github.com/jbossas/jboss-as/blob/master/web/src/main/java/org/jboss/as/web/deployment/JBossContextConfig.java
> appears to be wired to use Paul's ClassLoaderAwareClassResolver.

ClassLoaderAwareClassResolver is just a hack to workaround AS7-2496 (i.e. Weld still does TCCL switching).
The bottom line is, we still rely on ModularClassResolver to marshal/unmarshal session objects.

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