4:07 p.m.
Galder,
I'm trying to identify the right fix for addressing AS7-4007. I started
a clustered second level cache test that currently fails since
Infinispan isn't on the test application classpath.
The exception call stack that I'm getting is shown here
http://pastie.org/3503803.
I would like to discuss how we can address AS7-4007 (either on email or
IRC).
Initially, I worked around this by ensuring that the infinispan module
is available in the test application classpath
(https://github.com/jbossas/jboss-as/commit/31f3547960775dac88275447253fda...).
The hack was to export the Infinispan module when the Hibernate module
is brought into an application. This covered both JPA and Hibernate
native applications, however it exports into every other module that
references the Hibernate module (increasing the time that it takes to
link the Hibernate module into other modules). There are other problems
with requiring Infinipan to be in the application classpath (see
https://community.jboss.org/wiki/ModularSerialization).
I would like to better understand the alternatives (both short term and
long term) to address AS7-4007 and issues like it. Perhaps by using
MarshallingConfiguration.setClassResolver() to pass a
ModuleClassResolver to be used with Infinispan
marshalling/unmarshalling. Is that currently configurable with Infinispan?
Paul Ferraro, David Lloyd and myself chatted on irc briefly about this a
few days ago (see http://pastie.org/3528553).
https://github.com/dmlloyd/jboss-marshalling/blob/master/api/src/main/jav...
contains the source for the ModularClassResolver class that David
referred to (as well as the ModularSerialization article linked above).
Scott
9:21 a.m.
This reminds me that we had a discussion about this a few months back:
http://goo.gl/DJLhB
At the time, it wasn't clear whether you can use ModularClassResolver in a non-module
env. Seems like it's not possible.
So, one option is to have a class resolver lookup class, or similar so that AS7 can pass
us the right ClassResolver.
There might a quicker option here though:
- Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and provide a variant of
JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan (this requires JBossMarshaller to be
made non-final)
- Override JBossMarshaller.inject(), call super.inject() and then call
baseCfg.setClassResolver(…)
- This would require that the VersionAwareMarshaller extension be passed the ModuleLoader
that ModularClassResolver requires.
- Configure Infinispan with this new marshaller, via SerializationConfiguration.
Thankfully you can now pass an instance of the marshaller to it, so no need to do any
magic ModuleLoader lookup from the VersionAwareMarshaller extension.
Scott, other than the change in JBossMarshaller to be made non-final, the rest can built
on AS7. Wanna have a go? Ping me on IRC if you need help.
Cheers,
p.s. Silly question, how come this issue is not present in HTTP session replication use
case or EJB3 SFSB?
On Mar 5, 2012, at 11:07 PM, Scott Marlow wrote:
Galder,
I'm trying to identify the right fix for addressing AS7-4007. I started a clustered
second level cache test that currently fails since Infinispan isn't on the test
application classpath.
The exception call stack that I'm getting is shown here http://pastie.org/3503803.
I would like to discuss how we can address AS7-4007 (either on email or IRC).
Initially, I worked around this by ensuring that the infinispan module is available in
the test application classpath
(https://github.com/jbossas/jboss-as/commit/31f3547960775dac88275447253fda...).
The hack was to export the Infinispan module when the Hibernate module is brought into an
application. This covered both JPA and Hibernate native applications, however it exports
into every other module that references the Hibernate module (increasing the time that it
takes to link the Hibernate module into other modules). There are other problems with
requiring Infinipan to be in the application classpath (see
https://community.jboss.org/wiki/ModularSerialization).
I would like to better understand the alternatives (both short term and long term) to
address AS7-4007 and issues like it. Perhaps by using
MarshallingConfiguration.setClassResolver() to pass a ModuleClassResolver to be used with
Infinispan marshalling/unmarshalling. Is that currently configurable with Infinispan?
Paul Ferraro, David Lloyd and myself chatted on irc briefly about this a few days ago
(see http://pastie.org/3528553).
https://github.com/dmlloyd/jboss-marshalling/blob/master/api/src/main/jav...
contains the source for the ModularClassResolver class that David referred to (as well as
the ModularSerialization article linked above).
Scott
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
9:28 a.m.
On 03/06/2012 09:21 AM, Galder Zamarreño wrote:
This reminds me that we had a discussion about this a few months
back: http://goo.gl/DJLhB
At the time, it wasn't clear whether you can use ModularClassResolver in a non-module
env. Seems like it's not possible.
So, one option is to have a class resolver lookup class, or similar so that AS7 can pass
us the right ClassResolver.
There might a quicker option here though:
- Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and provide a variant of
JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan (this requires JBossMarshaller to be
made non-final)
- Override JBossMarshaller.inject(), call super.inject() and then call
baseCfg.setClassResolver(…)
- This would require that the VersionAwareMarshaller extension be passed the ModuleLoader
that ModularClassResolver requires.
- Configure Infinispan with this new marshaller, via SerializationConfiguration.
Thankfully you can now pass an instance of the marshaller to it, so no need to do any
magic ModuleLoader lookup from the VersionAwareMarshaller extension.
Scott, other than the change in JBossMarshaller to be made non-final, the rest can built
on AS7. Wanna have a go? Ping me on IRC if you need help.
Cheers,
p.s. Silly question, how come this issue is not present in HTTP session replication use
case or EJB3 SFSB?
It actually is present anywhere we're using Infinispan (I think). It
just hasn't blown up yet anywhere public (in this case it's a 90%
effective solution versus a 100% effective solution).
On Mar 5, 2012, at 11:07 PM, Scott Marlow wrote:
> Galder,
>
> I'm trying to identify the right fix for addressing AS7-4007. I started a
clustered second level cache test that currently fails since Infinispan isn't on the
test application classpath.
>
> The exception call stack that I'm getting is shown here
http://pastie.org/3503803.
>
> I would like to discuss how we can address AS7-4007 (either on email or IRC).
>
> Initially, I worked around this by ensuring that the infinispan module is available
in the test application classpath
(https://github.com/jbossas/jboss-as/commit/31f3547960775dac88275447253fda...).
The hack was to export the Infinispan module when the Hibernate module is brought into an
application. This covered both JPA and Hibernate native applications, however it exports
into every other module that references the Hibernate module (increasing the time that it
takes to link the Hibernate module into other modules). There are other problems with
requiring Infinipan to be in the application classpath (see
https://community.jboss.org/wiki/ModularSerialization).
>
> I would like to better understand the alternatives (both short term and long term) to
address AS7-4007 and issues like it. Perhaps by using
MarshallingConfiguration.setClassResolver() to pass a ModuleClassResolver to be used with
Infinispan marshalling/unmarshalling. Is that currently configurable with Infinispan?
>
> Paul Ferraro, David Lloyd and myself chatted on irc briefly about this a few days ago
(see http://pastie.org/3528553).
>
>
https://github.com/dmlloyd/jboss-marshalling/blob/master/api/src/main/jav...
contains the source for the ModularClassResolver class that David referred to (as well as
the ModularSerialization article linked above).
>
> Scott
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
--
- DML
9:30 a.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On 3/6/12 9:28 AM, David M. Lloyd wrote:
On 03/06/2012 09:21 AM, Galder Zamarreño wrote:
> This reminds me that we had a discussion about this a few months back:
http://goo.gl/DJLhB
>
> At the time, it wasn't clear whether you can use ModularClassResolver in a
non-module env. Seems like it's not possible.
>
> So, one option is to have a class resolver lookup class, or similar so that AS7 can
pass us the right ClassResolver.
>
> There might a quicker option here though:
> - Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and provide a variant of
JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan (this requires JBossMarshaller to be
made non-final)
> - Override JBossMarshaller.inject(), call super.inject() and then call
baseCfg.setClassResolver(…)
> - This would require that the VersionAwareMarshaller extension be passed the
ModuleLoader that ModularClassResolver requires.
> - Configure Infinispan with this new marshaller, via SerializationConfiguration.
Thankfully you can now pass an instance of the marshaller to it, so no need to do any
magic ModuleLoader lookup from the VersionAwareMarshaller extension.
>
> Scott, other than the change in JBossMarshaller to be made non-final, the rest can
built on AS7. Wanna have a go? Ping me on IRC if you need help.
>
> Cheers,
>
> p.s. Silly question, how come this issue is not present in HTTP session replication
use case or EJB3 SFSB?
It actually is present anywhere we're using Infinispan (I think). It
just hasn't blown up yet anywhere public (in this case it's a 90%
effective solution versus a 100% effective solution).
Session replication does setup a custom marshaller, so it does in fact
work. I think the issue is just that the hibernate-infinispan, which is
part of the hibernate project set, and not AS code does not do this, and
it doesn't expose a way to do it.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
11:31 a.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
----- Original Message -----
From: "Jason T. Greene" <jason.greene(a)redhat.com>
To: "David M. Lloyd" <david.lloyd(a)redhat.com>
Cc: "Galder Zamarreño" <galder(a)redhat.com>, "Paul Ferraro"
<pferraro(a)redhat.com>, "Bela Ban" <bban(a)redhat.com>,
"infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>,
hibernate-dev(a)lists.jboss.org,
"jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>
Sent: Tuesday, March 6, 2012 10:30:11 AM
Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA
second level cache
On 3/6/12 9:28 AM, David M. Lloyd wrote:
> On 03/06/2012 09:21 AM, Galder Zamarreño wrote:
>> This reminds me that we had a discussion about this a few months
>> back: http://goo.gl/DJLhB
>>
>> At the time, it wasn't clear whether you can use
>> ModularClassResolver in a non-module env. Seems like it's not
>> possible.
>>
>> So, one option is to have a class resolver lookup class, or
>> similar so that AS7 can pass us the right ClassResolver.
>>
>> There might a quicker option here though:
>> - Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and provide
>> a variant of JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan
>> (this requires JBossMarshaller to be made non-final)
>> - Override JBossMarshaller.inject(), call super.inject() and then
>> call baseCfg.setClassResolver(…)
>> - This would require that the VersionAwareMarshaller extension be
>> passed the ModuleLoader that ModularClassResolver requires.
>> - Configure Infinispan with this new marshaller, via
>> SerializationConfiguration. Thankfully you can now pass an
>> instance of the marshaller to it, so no need to do any magic
>> ModuleLoader lookup from the VersionAwareMarshaller extension.
>>
>> Scott, other than the change in JBossMarshaller to be made
>> non-final, the rest can built on AS7. Wanna have a go? Ping me on
>> IRC if you need help.
>>
>> Cheers,
>>
>> p.s. Silly question, how come this issue is not present in HTTP
>> session replication use case or EJB3 SFSB?
>
> It actually is present anywhere we're using Infinispan (I think).
> It
> just hasn't blown up yet anywhere public (in this case it's a 90%
> effective solution versus a 100% effective solution).
Session replication does setup a custom marshaller, so it does in
fact
work. I think the issue is just that the hibernate-infinispan, which
is
part of the hibernate project set, and not AS code does not do this,
and
it doesn't expose a way to do it.
Sort of...
To summarize:
The fundamental issue is that Infinispan uses the same marshaller instance for all caches
within a cache manager - which doesn't map cleanly to our use case, which uses a cache
instance per application - thus requires cache-grained marshalling configuration.
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/j...
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
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.
11:44 a.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On 3/6/12 11:31 AM, Paul Ferraro wrote:
----- Original Message -----
> From: "Jason T. Greene"<jason.greene(a)redhat.com>
> To: "David M. Lloyd"<david.lloyd(a)redhat.com>
> Cc: "Galder Zamarreño"<galder(a)redhat.com>, "Paul
Ferraro"<pferraro(a)redhat.com>, "Bela Ban"<bban(a)redhat.com>,
> "infinispan -Dev List"<infinispan-dev(a)lists.jboss.org>,
hibernate-dev(a)lists.jboss.org,
> "jboss-as7-dev(a)lists.jboss.org
Development"<jboss-as7-dev(a)lists.jboss.org>
> Sent: Tuesday, March 6, 2012 10:30:11 AM
> Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA
second level cache
>
> On 3/6/12 9:28 AM, David M. Lloyd wrote:
>> On 03/06/2012 09:21 AM, Galder Zamarreño wrote:
>>> This reminds me that we had a discussion about this a few months
>>> back: http://goo.gl/DJLhB
>>>
>>> At the time, it wasn't clear whether you can use
>>> ModularClassResolver in a non-module env. Seems like it's not
>>> possible.
>>>
>>> So, one option is to have a class resolver lookup class, or
>>> similar so that AS7 can pass us the right ClassResolver.
>>>
>>> There might a quicker option here though:
>>> - Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and provide
>>> a variant of JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan
>>> (this requires JBossMarshaller to be made non-final)
>>> - Override JBossMarshaller.inject(), call super.inject() and then
>>> call baseCfg.setClassResolver(…)
>>> - This would require that the VersionAwareMarshaller extension be
>>> passed the ModuleLoader that ModularClassResolver requires.
>>> - Configure Infinispan with this new marshaller, via
>>> SerializationConfiguration. Thankfully you can now pass an
>>> instance of the marshaller to it, so no need to do any magic
>>> ModuleLoader lookup from the VersionAwareMarshaller extension.
>>>
>>> Scott, other than the change in JBossMarshaller to be made
>>> non-final, the rest can built on AS7. Wanna have a go? Ping me on
>>> IRC if you need help.
>>>
>>> Cheers,
>>>
>>> p.s. Silly question, how come this issue is not present in HTTP
>>> session replication use case or EJB3 SFSB?
>>
>> It actually is present anywhere we're using Infinispan (I think).
>> It
>> just hasn't blown up yet anywhere public (in this case it's a 90%
>> effective solution versus a 100% effective solution).
>
> Session replication does setup a custom marshaller, so it does in
> fact
> work. I think the issue is just that the hibernate-infinispan, which
> is
> part of the hibernate project set, and not AS code does not do this,
> and
> it doesn't expose a way to do it.
Sort of...
To summarize:
The fundamental issue is that Infinispan uses the same marshaller instance for all caches
within a cache manager - which doesn't map cleanly to our use case, which uses a cache
instance per application - thus requires cache-grained marshalling configuration.
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/j...
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
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.
Well the lazy
deserialization thing was really to solve the legacy
problem of receiving deployment data without knowing the classloader for
the deployment. In 7 we know this know, although we still have the
problem that the value is only usable if the deployment is up and running.
Although, I don't see how we need per application marshalling
configuration. The ModularClassResolver will work globally as deployment
module identity is globally unique.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
1:08 p.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On Mar 6, 2012, at 6:44 PM, Jason T. Greene wrote:
On 3/6/12 11:31 AM, Paul Ferraro wrote:
> ----- Original Message -----
>> From: "Jason T. Greene"<jason.greene(a)redhat.com>
>> To: "David M. Lloyd"<david.lloyd(a)redhat.com>
>> Cc: "Galder Zamarreño"<galder(a)redhat.com>, "Paul
Ferraro"<pferraro(a)redhat.com>, "Bela Ban"<bban(a)redhat.com>,
>> "infinispan -Dev List"<infinispan-dev(a)lists.jboss.org>,
hibernate-dev(a)lists.jboss.org,
>> "jboss-as7-dev(a)lists.jboss.org
Development"<jboss-as7-dev(a)lists.jboss.org>
>> Sent: Tuesday, March 6, 2012 10:30:11 AM
>> Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered
JPA second level cache
>>
>> On 3/6/12 9:28 AM, David M. Lloyd wrote:
>>> On 03/06/2012 09:21 AM, Galder Zamarreño wrote:
>>>> This reminds me that we had a discussion about this a few months
>>>> back: http://goo.gl/DJLhB
>>>>
>>>> At the time, it wasn't clear whether you can use
>>>> ModularClassResolver in a non-module env. Seems like it's not
>>>> possible.
>>>>
>>>> So, one option is to have a class resolver lookup class, or
>>>> similar so that AS7 can pass us the right ClassResolver.
>>>>
>>>> There might a quicker option here though:
>>>> - Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and provide
>>>> a variant of JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan
>>>> (this requires JBossMarshaller to be made non-final)
>>>> - Override JBossMarshaller.inject(), call super.inject() and then
>>>> call baseCfg.setClassResolver(…)
>>>> - This would require that the VersionAwareMarshaller extension be
>>>> passed the ModuleLoader that ModularClassResolver requires.
>>>> - Configure Infinispan with this new marshaller, via
>>>> SerializationConfiguration. Thankfully you can now pass an
>>>> instance of the marshaller to it, so no need to do any magic
>>>> ModuleLoader lookup from the VersionAwareMarshaller extension.
>>>>
>>>> Scott, other than the change in JBossMarshaller to be made
>>>> non-final, the rest can built on AS7. Wanna have a go? Ping me on
>>>> IRC if you need help.
>>>>
>>>> Cheers,
>>>>
>>>> p.s. Silly question, how come this issue is not present in HTTP
>>>> session replication use case or EJB3 SFSB?
>>>
>>> It actually is present anywhere we're using Infinispan (I think).
>>> It
>>> just hasn't blown up yet anywhere public (in this case it's a 90%
>>> effective solution versus a 100% effective solution).
>>
>> Session replication does setup a custom marshaller, so it does in
>> fact
>> work. I think the issue is just that the hibernate-infinispan, which
>> is
>> part of the hibernate project set, and not AS code does not do this,
>> and
>> it doesn't expose a way to do it.
>
> Sort of...
>
> To summarize:
> The fundamental issue is that Infinispan uses the same marshaller instance for all
caches within a cache manager - which doesn't map cleanly to our use case, which uses
a cache instance per application - thus requires cache-grained marshalling configuration.
>
> 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/j...
>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>
> 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.
Well the lazy deserialization thing was really to solve the legacy
problem of receiving deployment data without knowing the classloader for
the deployment. In 7 we know this know, although we still have the
problem that the value is only usable if the deployment is up and running.
Thinking through this, I don't think this is the problem here. And 2LC is configured
with lazy deserialization already.
The problem here is that the deployment cannot see the Infinispan classes, not that
Infinispan cannot deserialize the deployment classes.
Although, I don't see how we need per application marshalling
configuration.
The ModularClassResolver will work globally as deployment
module identity is globally unique.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
1:02 p.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
----- Original Message -----
> From: "Jason T. Greene" <jason.greene(a)redhat.com>
> To: "David M. Lloyd" <david.lloyd(a)redhat.com>
> Cc: "Galder Zamarreño" <galder(a)redhat.com>, "Paul Ferraro"
<pferraro(a)redhat.com>, "Bela Ban" <bban(a)redhat.com>,
> "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>,
hibernate-dev(a)lists.jboss.org,
> "jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>
> Sent: Tuesday, March 6, 2012 10:30:11 AM
> Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA
second level cache
>
> On 3/6/12 9:28 AM, David M. Lloyd wrote:
>> On 03/06/2012 09:21 AM, Galder Zamarreño wrote:
>>> This reminds me that we had a discussion about this a few months
>>> back: http://goo.gl/DJLhB
>>>
>>> At the time, it wasn't clear whether you can use
>>> ModularClassResolver in a non-module env. Seems like it's not
>>> possible.
>>>
>>> So, one option is to have a class resolver lookup class, or
>>> similar so that AS7 can pass us the right ClassResolver.
>>>
>>> There might a quicker option here though:
>>> - Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and provide
>>> a variant of JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan
>>> (this requires JBossMarshaller to be made non-final)
>>> - Override JBossMarshaller.inject(), call super.inject() and then
>>> call baseCfg.setClassResolver(…)
>>> - This would require that the VersionAwareMarshaller extension be
>>> passed the ModuleLoader that ModularClassResolver requires.
>>> - Configure Infinispan with this new marshaller, via
>>> SerializationConfiguration. Thankfully you can now pass an
>>> instance of the marshaller to it, so no need to do any magic
>>> ModuleLoader lookup from the VersionAwareMarshaller extension.
>>>
>>> Scott, other than the change in JBossMarshaller to be made
>>> non-final, the rest can built on AS7. Wanna have a go? Ping me on
>>> IRC if you need help.
>>>
>>> Cheers,
>>>
>>> p.s. Silly question, how come this issue is not present in HTTP
>>> session replication use case or EJB3 SFSB?
>>
>> It actually is present anywhere we're using Infinispan (I think).
>> It
>> just hasn't blown up yet anywhere public (in this case it's a 90%
>> effective solution versus a 100% effective solution).
>
> Session replication does setup a custom marshaller, so it does in
> fact
> work. I think the issue is just that the hibernate-infinispan, which
> is
> part of the hibernate project set, and not AS code does not do this,
> and
> it doesn't expose a way to do it.
Sort of...
To summarize:
The fundamental issue is that Infinispan uses the same marshaller instance for all caches
within a cache manager - which doesn't map cleanly to our use case, which uses a cache
instance per application - thus requires cache-grained marshalling configuration.
Well, this is not exactly correct since 5.0. Internally, we differentiate between a global
marshaller and a per-cache marshaller. What's the difference? The classloader with
which they're configured.
Since 5.0, you can configure the classloader to use per cache. You can even configure the
classloader per invocation with cache.with(cl)….
If that's not helping you, we were wasting our time when we did this...
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/j...
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
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...
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
1:06 p.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On 03/06/2012 01:02 PM, Galder Zamarreño wrote:
On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
> ----- Original Message -----
>> From: "Jason T. Greene"<jason.greene(a)redhat.com>
>> To: "David M. Lloyd"<david.lloyd(a)redhat.com>
>> Cc: "Galder Zamarreño"<galder(a)redhat.com>, "Paul
Ferraro"<pferraro(a)redhat.com>, "Bela Ban"<bban(a)redhat.com>,
>> "infinispan -Dev List"<infinispan-dev(a)lists.jboss.org>,
hibernate-dev(a)lists.jboss.org,
>> "jboss-as7-dev(a)lists.jboss.org
Development"<jboss-as7-dev(a)lists.jboss.org>
>> Sent: Tuesday, March 6, 2012 10:30:11 AM
>> Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered
JPA second level cache
>>
>> On 3/6/12 9:28 AM, David M. Lloyd wrote:
>>> On 03/06/2012 09:21 AM, Galder Zamarreño wrote:
>>>> This reminds me that we had a discussion about this a few months
>>>> back: http://goo.gl/DJLhB
>>>>
>>>> At the time, it wasn't clear whether you can use
>>>> ModularClassResolver in a non-module env. Seems like it's not
>>>> possible.
>>>>
>>>> So, one option is to have a class resolver lookup class, or
>>>> similar so that AS7 can pass us the right ClassResolver.
>>>>
>>>> There might a quicker option here though:
>>>> - Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and provide
>>>> a variant of JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan
>>>> (this requires JBossMarshaller to be made non-final)
>>>> - Override JBossMarshaller.inject(), call super.inject() and then
>>>> call baseCfg.setClassResolver(…)
>>>> - This would require that the VersionAwareMarshaller extension be
>>>> passed the ModuleLoader that ModularClassResolver requires.
>>>> - Configure Infinispan with this new marshaller, via
>>>> SerializationConfiguration. Thankfully you can now pass an
>>>> instance of the marshaller to it, so no need to do any magic
>>>> ModuleLoader lookup from the VersionAwareMarshaller extension.
>>>>
>>>> Scott, other than the change in JBossMarshaller to be made
>>>> non-final, the rest can built on AS7. Wanna have a go? Ping me on
>>>> IRC if you need help.
>>>>
>>>> Cheers,
>>>>
>>>> p.s. Silly question, how come this issue is not present in HTTP
>>>> session replication use case or EJB3 SFSB?
>>>
>>> It actually is present anywhere we're using Infinispan (I think).
>>> It
>>> just hasn't blown up yet anywhere public (in this case it's a 90%
>>> effective solution versus a 100% effective solution).
>>
>> Session replication does setup a custom marshaller, so it does in
>> fact
>> work. I think the issue is just that the hibernate-infinispan, which
>> is
>> part of the hibernate project set, and not AS code does not do this,
>> and
>> it doesn't expose a way to do it.
>
> Sort of...
>
> To summarize:
> The fundamental issue is that Infinispan uses the same marshaller instance for all
caches within a cache manager - which doesn't map cleanly to our use case, which uses
a cache instance per application - thus requires cache-grained marshalling configuration.
Well, this is not exactly correct since 5.0. Internally, we differentiate between a
global marshaller and a per-cache marshaller. What's the difference? The classloader
with which they're configured.
Since 5.0, you can configure the classloader to use per cache. You can even configure the
classloader per invocation with cache.with(cl)….
If that's not helping you, we were wasting our time when we did this...
Well.... :) (see below)
> 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/j...
>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
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.
> 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
1:19 p.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
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/j...
>>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>
> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
1:27 p.m.
New subject: [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).
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/j...
>>>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>
>> 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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
1:45 p.m.
New subject: [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/jbo...
appears to be wired to use Paul's ClassLoaderAwareClassResolver.
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/j...
>>>>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>
>>> 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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3:34 p.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
----- Original Message -----
From: "Scott Marlow" <smarlow(a)redhat.com>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Cc: hibernate-dev(a)lists.jboss.org, "jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>,
"Galder Zamarreño" <galder(a)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/jbo...
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/j...
>>>>>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>>>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>>
>>>> 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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:23 a.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On 03/06/2012 02:45 PM, Scott Marlow wrote:
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?
The application workaround of adding the Infinispan jar isn't good
enough (for reasons that others already mentioned.
If we have to make Infinispan changes, wouldn't the smallest change be
to let AS7 pass in a global ModularClassResolver via Infinipan
GlobalConfiguration? I can try that locally if that sounds right to all.
Otherwise, we can try the other suggested changes (pasted again below).
"
There might a quicker option here though:
- Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and provide a
variant of JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan (this
requires JBossMarshaller to be made non-final)
- Override JBossMarshaller.inject(), call super.inject() and then call
baseCfg.setClassResolver(…)
- This would require that the VersionAwareMarshaller extension be passed
the ModuleLoader that ModularClassResolver requires.
- Configure Infinispan with this new marshaller, via
SerializationConfiguration. Thankfully you can now pass an instance of
the marshaller to it, so no need to do any magic ModuleLoader lookup
from the VersionAwareMarshaller extension.
Scott, other than the change in JBossMarshaller to be made non-final,
the rest can built on AS7. Wanna have a go? Ping me on IRC if you need help.
"
1:13 p.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On 6 Mar 2012, at 14:45, Scott Marlow wrote:
>
>
> - 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.
Definitely post EAP 6.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
1:52 p.m.
New subject: [hibernate-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On 03/14/2012 02:13 PM, Manik Surtani wrote:
On 6 Mar 2012, at 14:45, Scott Marlow wrote:
>>
>>
>> - 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.
Definitely post EAP 6.
The ISPN-1367 jira changed a bit since I asked this question. A few
days ago, Galder said that he was working on addressing ISPN-1367 for AS
7.1.2 (so we can specify the AS7 ModularClassResolver as a global
configuration setting passed into Infinispan).
I probably asked the wrong question above (I don't really want to bring
5.2 into As 7.1.2). Can we fix ISPN-1367 in a 5.1.x.FINAL build, that
could be brought into AS 7.1.2?
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:14 a.m.
New subject: [hibernate-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On Mar 14, 2012, at 7:52 PM, Scott Marlow wrote:
On 03/14/2012 02:13 PM, Manik Surtani wrote:
>
> On 6 Mar 2012, at 14:45, Scott Marlow wrote:
>
>>>
>>>
>>> - 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.
>
> Definitely post EAP 6.
The ISPN-1367 jira changed a bit since I asked this question. A few
days ago, Galder said that he was working on addressing ISPN-1367 for AS
7.1.2 (so we can specify the AS7 ModularClassResolver as a global
configuration setting passed into Infinispan).
I probably asked the wrong question above (I don't really want to bring
5.2 into As 7.1.2). Can we fix ISPN-1367 in a 5.1.x.FINAL build, that
could be brought into AS 7.1.2?
yes
>
> --
> Manik Surtani
> manik(a)jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
1:55 p.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On 03/06/2012 01:27 PM, Galder Zamarreño wrote:
(***) 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).
It's possible that someone saw the exception and said to themselves,
"oh... well I'll just add Infinispan to all web apps", and then the
patch slipped by the code review process. Other problems will continue
to lurk beneath the surface though.
--
- DML
3:42 p.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
----- Original Message -----
From: "David M. Lloyd" <david.lloyd(a)redhat.com>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Cc: hibernate-dev(a)lists.jboss.org, "jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>,
"Galder Zamarreño" <galder(a)redhat.com>
Sent: Tuesday, March 6, 2012 2:55:18 PM
Subject: Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for
clustered JPA second level
cache
On 03/06/2012 01:27 PM, Galder Zamarreño wrote:
> (***) 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).
It's possible that someone saw the exception and said to themselves,
"oh... well I'll just add Infinispan to all web apps", and then the
patch slipped by the code review process. Other problems will
continue
to lurk beneath the surface though.
No - web applications don't have this problem because web session clustering uses
ModularClassResolver during marshalling/unmarshalling of sessions.
3:01 p.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
----- Original Message -----
From: "Galder Zamarreño" <galder(a)redhat.com>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Cc: hibernate-dev(a)lists.jboss.org, "jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)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/j...
>>>>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>
>>> 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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:26 a.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On Mar 6, 2012, at 10:01 PM, Paul Ferraro wrote:
----- Original Message -----
> </snip>
>
> (***) 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).
Paul, that explains how you can deserialize the *contents of the cache*.
My question is different: I'm talking about how, the web app, can see *Infinispan
classes*.
In Scott's issue, the web app uses Hibernate but during unmarshalling but it cannot
locate Infinispan classes:
07:27:32,225 SEVERE [org.jgroups.blocks.RequestCorrelator] (OOB-20,null) failed
unmarshalling buffer into return value: java.lang.ClassNotFoundException:
org.infinispan.CacheException from [Module "deployment.stateful.war:main" from
Service Module Loader]
I'm trying to understand how come it works for session repl, but it doesn't for
2LC. It seems to me that you should be having the same problem if you cannot plug
Infinispan with the ModuleClassResolver.
Let's talk on IRC...
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
1:38 p.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
----- Original Message -----
From: "Galder Zamarreño" <galder(a)redhat.com>
To: "Paul Ferraro" <paul.ferraro(a)redhat.com>
Cc: "Jason T. Greene" <jason.greene(a)redhat.com>, "Bela Ban"
<bban(a)redhat.com>, "infinispan -Dev List"
<infinispan-dev(a)lists.jboss.org>, hibernate-dev(a)lists.jboss.org,
"jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>, "David M. Lloyd"
<david.lloyd(a)redhat.com>
Sent: Tuesday, March 6, 2012 2:02:44 PM
Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA
second level cache
On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
> ----- Original Message -----
>> From: "Jason T. Greene" <jason.greene(a)redhat.com>
>> To: "David M. Lloyd" <david.lloyd(a)redhat.com>
>> Cc: "Galder Zamarreño" <galder(a)redhat.com>, "Paul
Ferraro"
>> <pferraro(a)redhat.com>, "Bela Ban" <bban(a)redhat.com>,
>> "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>,
>> hibernate-dev(a)lists.jboss.org,
>> "jboss-as7-dev(a)lists.jboss.org Development"
>> <jboss-as7-dev(a)lists.jboss.org>
>> Sent: Tuesday, March 6, 2012 10:30:11 AM
>> Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan
>> dependency for clustered JPA second level cache
>>
>> On 3/6/12 9:28 AM, David M. Lloyd wrote:
>>> On 03/06/2012 09:21 AM, Galder Zamarreño wrote:
>>>> This reminds me that we had a discussion about this a few months
>>>> back: http://goo.gl/DJLhB
>>>>
>>>> At the time, it wasn't clear whether you can use
>>>> ModularClassResolver in a non-module env. Seems like it's not
>>>> possible.
>>>>
>>>> So, one option is to have a class resolver lookup class, or
>>>> similar so that AS7 can pass us the right ClassResolver.
>>>>
>>>> There might a quicker option here though:
>>>> - Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and
>>>> provide
>>>> a variant of JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan
>>>> (this requires JBossMarshaller to be made non-final)
>>>> - Override JBossMarshaller.inject(), call super.inject() and
>>>> then
>>>> call baseCfg.setClassResolver(…)
>>>> - This would require that the VersionAwareMarshaller extension
>>>> be
>>>> passed the ModuleLoader that ModularClassResolver requires.
>>>> - Configure Infinispan with this new marshaller, via
>>>> SerializationConfiguration. Thankfully you can now pass an
>>>> instance of the marshaller to it, so no need to do any magic
>>>> ModuleLoader lookup from the VersionAwareMarshaller extension.
>>>>
>>>> Scott, other than the change in JBossMarshaller to be made
>>>> non-final, the rest can built on AS7. Wanna have a go? Ping me
>>>> on
>>>> IRC if you need help.
>>>>
>>>> Cheers,
>>>>
>>>> p.s. Silly question, how come this issue is not present in HTTP
>>>> session replication use case or EJB3 SFSB?
>>>
>>> It actually is present anywhere we're using Infinispan (I think).
>>> It
>>> just hasn't blown up yet anywhere public (in this case it's a 90%
>>> effective solution versus a 100% effective solution).
>>
>> Session replication does setup a custom marshaller, so it does in
>> fact
>> work. I think the issue is just that the hibernate-infinispan,
>> which
>> is
>> part of the hibernate project set, and not AS code does not do
>> this,
>> and
>> it doesn't expose a way to do it.
>
> Sort of...
>
> To summarize:
> The fundamental issue is that Infinispan uses the same marshaller
> instance for all caches within a cache manager - which doesn't map
> cleanly to our use case, which uses a cache instance per
> application - thus requires cache-grained marshalling
> configuration.
Well, this is not exactly correct since 5.0. Internally, we
differentiate between a global marshaller and a per-cache
marshaller. What's the difference? The classloader with which
they're configured.
Yes - but there's a difference between supplying a classloader per cache and providing
a custom marshaller per cache.
Since 5.0, you can configure the classloader to use per cache. You
can even configure the classloader per invocation with
cache.with(cl)….
And we use both of these. The ClassLoader supplied to the CacheConfiguration is used to
resolve configuration classes (e.g. cache stores). The AS7 2LC region factory
implementations (which extend hibernate-infinispan) currently use the ClassLoader per
invocation to resolve entity/PK objects - but this is too restrictive, since the
Infinispan's marshaller needs to know about more classes than are available to the
application class loader (hence this discussion), and even that is still not without
issues (e.g. ISPN-1220).
If that's not helping you, we were wasting our time when we did
this...
I disagree. Allowing a user to supply a classloader to a cache/invocation is incredibly
useful.
> 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/j...
>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
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...
Functionally, yes, but technically, no. The ModularClassResolver resolves classes using
the class name and the name of its module, whereas a ClassLoader resolves classes using
just the class name.
> 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…
Apart from possibly adding MarshallingConfiguraion hooks to infinispan-core, what other
solution do you have in mind?
Paul
2:23 p.m.
New subject: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On 3/6/12 1:02 PM, Galder Zamarreño wrote:
On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
> To summarize:
> The fundamental issue is that Infinispan uses the same marshaller instance for all
caches within a cache manager - which doesn't map cleanly to our use case, which uses
a cache instance per application - thus requires cache-grained marshalling configuration.
Well, this is not exactly correct since 5.0. Internally, we differentiate between a
global marshaller and a per-cache marshaller. What's the difference? The classloader
with which they're configured.
Since 5.0, you can configure the classloader to use per cache. You can even configure the
classloader per invocation with cache.with(cl)….
If that's not helping you, we were wasting our time when we did this...
Read this, as it explains in detail how serialization and a multi
classloader (e.g. a modular) environment related to serialization:
https://community.jboss.org/wiki/ModularSerialization
When running in AS7 *EVERYTHING* that serializes classes that can come
from multiple classloaders (e.g. user deployments) *MUST* use the
ModularClassResolver.
Specifying a classloader per cache using cache.with() is *NOT* useful
for deserializing data in a modular environment like AS7. This has all
of the problems described in the above wiki. The .with() feature is
useful if a user is developing a custom classloader, *which is not one
our own* (hence modularclassresolver wouldnt know what to do with it).
It would also be potentially useful outside of AS7, or standalone. Based
on Pauls comments, it sounds like it is useful in allowing the user to
specify custom cache loaders, that we take advantage of, but that is a
non-serialization use case.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
4602
days inactive
4613
days old
infinispan-dev@lists.jboss.org
22 comments
6 participants
participants (6)
-
David M. Lloyd -
Galder Zamarreño -
Jason T. Greene -
Manik Surtani -
Paul Ferraro -
Scott Marlow