Re: [jboss-as7-dev] [infinispan-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
by David M. Lloyd
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
12 years, 10 months
Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
by Jason T. Greene
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
12 years, 10 months
Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
by Paul Ferraro
----- 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
12 years, 10 months
Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
by David M. Lloyd
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
12 years, 10 months
PicketLink Console and AS7 Console
by Anil Saldhana
Heiko,
wanted your opinion on this.
Pedro Silva is working on a PicketLink Console using GWT and uses
Ballroom (https://community.jboss.org/wiki/BallroomLookFeel). Since PL
jars are shipped as part of JBoss AS7.1.x, users will definitely like a
console to configure PL SSO etc.
So we are debating around: a) developing a standalone PL console or b)
try to have it as an *extension* of the AS admin console to give a
consistent user experience.
If we develop a standalone PL console, it will come packaged in a AS7
instance.
Any guidance for console writers who are integrating with AS7.
Regards,
Anil
12 years, 10 months
Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
by David M. Lloyd
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
12 years, 10 months
EJB remote lookup without authentication
by Wolf-Dieter Fink
Hi,
if I lookup a SLSB in as 7.1.0.Final or 7.1.1 the JNDI call
'my.ear/my.jar...' will not work without having a (application) user and
set the credential.
If I use native 'ejb:my.ear...' it will work nevertheless whether I set
username/password in jboss-ejb-client.properties or not.
For standalone.xml the security looks enabled:
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
<connector name="remoting-connector" socket-binding="remoting"
security-realm="ApplicationRealm"/>
</subsystem>
I use 7.1.0.FINAL and 7.1.1 upstream (~noon)
Is this a BUG? Or is something changed between 7.1.0.SNAPSHOT and later?
Wolf
12 years, 10 months
AS7-4007 missing Infinispan dependency for clustered JPA second level cache
by Scott Marlow
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
12 years, 10 months
"driver-name" attribute while creating the JDBC driver
by Jaikiran Pai
I was trying out creation of a JDBC driver through the management
operation. Initially I used this operation:
[standalone@localhost:9999 /]
/subsystem=datasources/jdbc-driver=mysql-5-driver:add(driver-module-name=mysql,
driver-class-name=com.mysql.jdbc.Driver)
Note that it _doesn't_ specify the "driver-name" attribute. However, it
failed with:
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: No
child 'driver-name' exists",
"rolled-back" => true
}
(the error message isn't clear by the way, but that's a different matter).
I then had to change the operation to explicitly specify the driver-name
attribute:
[standalone@localhost:9999 /]
/subsystem=datasources/jdbc-driver=mysql-5-driver:add(driver-name=mysql-5-driver,
driver-class-name=com.mysql.jdbc.Driver, driver-module-name=mysql)
That worked fine.
But why is this operation unlike other "add" operations which use the
value before the ":" as the name of the new resource? By the way, I even
tried this command:
[standalone@localhost:9999 /]
/subsystem=datasources/jdbc-driver=foo:add(driver-name=bar,
driver-class-name=com.mysql.jdbc.Driver, driver-module-name=mysql)
Note that I use "foo" as the resource name for the add operation and
"bar" as the driver-name attribute value. This creates a driver named
"bar" in the standalone.xml:
<driver name="bar" module="mysql">
<driver-class>com.mysql.jdbc.Driver</driver-class>
</driver>
and there's no reference to "foo" anywhere. So what's the significance
of using it in the operation?
-Jaikiran
12 years, 10 months
