5:19 a.m.
On Sep 1, 2011, at 4:31 PM, Paul Ferraro wrote:
On Thu, 2011-09-01 at 13:12 +0200, Galder Zamarreño wrote:
> Hey Paul,
>
> As shown by Martin in https://issues.jboss.org/browse/JBPAPP-6718 , it's clear
that the AS7 Infinispan subsystem is not yet ready to read configurations for stores other
than the FileCacheStore, so I'd assume we'd need to create a new JIRA on AS7 to
deal with configuration of:
> - JDBCCacheStore
> - RemoteCacheStore
> - CloudCacheStore
As I mentioned in the jira, all EDG needs to do to support these is add
the appopriate dependencies to the org.jboss.as.infinispan's module.xml.
Hmmm, I don't see anywhere org.jboss.as.infinispan's module.xml. I see
org.jboss.as.clustering.infinispan's module.xml and I did not touch that.
In fact, if you see the JIRA, that's what's missing that Martin spotted (thx
Martin!)
Btw, if we take JDBCCacheStore as example, I did:
- Create org.infinispan.loaders.jdbc module.xml and added these dependencies there:
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.xml.bind.api"/>
<module name="org.apache.xerces" services="import"/>
<module name="org.infinispan"/>
<module name="org.jboss.logging"/>
<module name="org.jboss.marshalling"/>
<module name="org.jboss.marshalling.river"
services="import"/>
<module name="org.jgroups"/>
<module name="c3p0.c3p0"/>
</dependencies>
Question: Once org.jboss.as.clustering.infinispan is updated, can
org.infinispan.loaders.jdbc's module.xml be simplified to only contain the
dependencies not already included in org.jboss.as.clustering.infinispan
> Looking at what you've done for the FCS, you seem to enable different type of
configs, i.e.
>
> <file-store fetch-state="false" passivation="false"
path="path" preload="true" purge="false"
relative-to="jboss.server.temp.dir" shared="true"
singleton="true"/>
>
> vs
>
> <store class="org.infinispan.loaders.file.FileCacheStore"
fetch-state="true" passivation="true" preload="false"
purge="true" shared="false" singleton="false">
> <property name="location">${java.io.tmpdir}</property>
> </store>
>
> I suspect the idea is to lean towards more strictly typed configurations as shown in
1st example?
There few a couple motivations at play here:
The first was to comply with the AS7 configuration schema requirements,
such that users should not need to define class names in the
configuration file, unless referring to their own classes, or for less
common use cases.
This could have been achieved by enumerating the supported stores:
e.g.
<store type="file"/>
<store type="jdbc"/>
or via separate elements:
<file-store/>
<jdbc-store/>
The motivation for going with the separate element approach was to make
the supported cache store properties explicit, such that some properties
could explicitly reference other subsystems. For example, <file-store>
leverage the paths subsystem (e.g. via the relative-to and path
attributes) for defining the file system location - the advantage of
which is the ability to manage paths from the cli/console.
Several of these cache stores will also want to reference other AS
services, e.g. JDBC cache store will want to reference a JCA data
source.
That said, for AS 7.1, I think we should figure out which cache stores
constitute common use cases, expand the infinispan schema to support
them, and fully document how one would go about using an adhoc cache
store implementation.
+1
The set of cache stores has been pretty stable for a while now, so I'm totally up for
making the schema support the most common ones. In my view, these are the three that I
mentioned above plus file one.
So, before 7.1, if we want to support this before that, the easiest would be to rely on
store/property combo until we have the most commonly used cache stores properly supported?
If that's the case, is there anything extra that needs doing? The reason I ask is cos
you already support this format for FCS, so wondering if it should work as is.
> Also, doing this would probably mean that these cache store jars and their
dependencies make it to AS7, right?
Correct.
Hmmm, then this needs to be resolved in AS7 really, doesn't it? If that's the
case, why modify EDG?
> Did you have any other plans for this? Or maybe you have other jiras already for
this?
I don't believe one exists yet. I'll create the relevant AS7 jiras for
these today.
> Cheers,
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache