Re: [infinispan-dev] AS7 infinispan subsystem configurations for JDBC, Remote and Cloud cache stores

On Fri, 2011-09-02 at 12:19 +0200, Galder Zamarreño wrote: > 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. Whoops. Sorry for the confusion. > In fact, if you see the JIRA, that's what's missing that Martin spotted (thx Martin!) Sorry, that was a sloppy (and incorrect) response on my part. Let me be more explicit. So, there are actually 2 ways to go about this. 1. Create separate modules for each cache store implementation. Add the modules as dependencies to the module.xml for the org.infinispan module (since these classes will be loaded by the infinispan module). 2. Add the maven artifacts for these cache stores directly to the org.infinispan module. This is done by modifying the main pom.xml (to include the new maven artifacts), adding the dependencies again to build/pom.xml (minus the version), and update the org.infinispan module definition within build/build.xml (which specifies which artifacts should be included in a given module) to include the new artifacts. This is the approach that I attempted to suggest in the jira. It seems you guys are trying to take the 1st approach, though I would actually recommend taking the 2nd approach, since a) it's less cumbersome b) the only reason to create separate modules per cache store is if they were reusable by some other module other than the org.infinispan module.

> 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 No. The way JBoss Modules works, each module needs to enumerate all of its module dependencies, otherwise, you'll get NCDFErrors. However, I don't recommend going this route anyway (see above).

>> >>> 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? Yes. > 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. It should work, so long as the build is updated to include the cache store jars within the org.infinispan module. >>> 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? All I meant was EDG didn't have to wait for it to happen in AS7. You could modify the build to include the desired cache store artifacts (and ideally submit a patch) without having to wait for me to get around to it.

>>> 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 >