-
1. Re: Utilizing Infinispan's GridFilesystem
meetoblivion Apr 13, 2010 7:19 AM (in response to rhauch)What about option 4?
create a new project that depends on one of the other 2 projects (e.g. infinispan connector or file system connector) and subclass from there.
i think you should look at how the seam 3 team is working w/ their modules; everything is a separate artifact and you don't need to release your entire infrastructure for it.
-
2. Re: Utilizing Infinispan's GridFilesystem
bcarothers Apr 13, 2010 9:12 AM (in response to meetoblivion)I think option 3 and option 4 are both saying the same thing. I vote for option 3/4. It's consistent with our de facto existing approach ("make a million small subprojects for connectors to keep them as independent as possible"). This is also consistent with Spring (and, apparently, SEAM) packaging practices.
-
3. Re: Utilizing Infinispan's GridFilesystem
rhauch Apr 13, 2010 9:20 AM (in response to bcarothers)This is also consistent with Spring (and, apparently, SEAM) packaging practices.
I believe that SEAM is starting to move towards releasing each subproject independently, on its own schedule. That's still different than what we're currently doing.
I'm not quite sure we're ready for that yet. It wouldn't really affect a Maven-based app, but for "regular" Java apps with a classpath, the classpath would contain a hodge-podge of different connector/sequencer versions, and that could get messy. So while this wouldn't be my preferred choice, I definitely see the advantages and could be convinced if the community wants to go this route.
-
4. Re: Utilizing Infinispan's GridFilesystem
meetoblivion Apr 13, 2010 9:41 AM (in response to rhauch)Well, your connectors are just implementing a single interface, correct? I would think if the connector interface does not change then x connector would be compatible with modeshape v.something.
plus, from the mavenized side, i can't imagine a project being dependent on more than 2 connectors.
but that's kind of deviating from this thread's topic.
-
5. Re: Utilizing Infinispan's GridFilesystem
rhauch Apr 13, 2010 9:42 AM (in response to bcarothers)John Ament wrote:
What about option 4? ... create a new project that depends on one of the other 2 projects (e.g. infinispan connector or file system connector) and subclass from there.
...
Brian Carothers wrote:
I think option 3 and option 4 are both saying the same thing. I vote for option 3/4. It's consistent with our de facto existing approach ("make a million small subprojects for connectors to keep them as independent as possible"). ...
This would also be very minimal code if we created a new connector project and subclassed the existing FileSystemSource class (in the file system connector).
Then there's the question of which Infinispan version(s) should our connectors depend on. Again, I see three options (please holler if you see other options):
- Have this new connector depend on the latest Infinispan release (e.g., 4.1.0.BETA1 that is due in a few weeks), and leave 'modeshape-connector-infinispan' on 4.0.0.FINAL. This would imply the two connectors couldn't (easily) be used in the same app, unless some classloader magic is used.
- Change both connectors to use Infinispan 4.1.0.BETA1, allowing both to be (easily) used within the same app. If someone wanted to use Infinispan 4.0.0.FINAL, it's quite likely they could use 'modeshape-connector-infinispan' from ModeShape 1.1.
- Keep things simple and wait to create this new connector until a ModeShape release that can depend on Infinispan 4.1.0.FINAL.
Thoughts?
-
6. Re: Utilizing Infinispan's GridFilesystem
rhauch Apr 13, 2010 9:48 AM (in response to meetoblivion)John Ament wrote:
...
plus, from the mavenized side, i can't imagine a project being dependent on more than 2 connectors.
...
You're right - in most traditional JCR applications, there'd be just a single connector to store all content. But with ModeShape it's easy to use the federated connector for the JCR storage, where most content is projected from one storage connector but project other content from other connectors. There are several folks looking at this scenario to allow them to store/access files and directories in one system but the rest of the JCR content in a traditional way.
-
7. Re: Utilizing Infinispan's GridFilesystem
meetoblivion Apr 13, 2010 9:49 AM (in response to rhauch)My vote goes to #1, assuming that you add documentation explaining how to use maven excludes in order to do this properly (since I'd assume 4.1 doesn't change what 4.0 does so the infinispan connector can work correctly).
Also, I'm curious to know why you don't have a way to configure infinispan from within modeshape? it seems weird that it's either use the default cache manager or look one up via jndi, but no way to pass in the infinispan config file?
-
8. Re: Utilizing Infinispan's GridFilesystem
rhauch Apr 13, 2010 9:53 AM (in response to meetoblivion)John Ament wrote:
...
Also, I'm curious to know why you don't have a way to configure infinispan from within modeshape? it seems weird that it's either use the default cache manager or look one up via jndi, but no way to pass in the infinispan config file?
Good point. I'm not sure why we don't offer that option. Care to log a JIRA?
-
9. Re: Utilizing Infinispan's GridFilesystem
meetoblivion Apr 13, 2010 10:04 AM (in response to rhauch) -
10. Re: Utilizing Infinispan's GridFilesystem
jdbrown May 2, 2010 8:23 PM (in response to rhauch)Does the "cacheConfigurationName" decribed in the connector for 1.1.0Final Reference guide provide this functionality? At least from the description it sounds like it:
"Optional property that, if used, specifies the name of the configuration that is supplied to the cache manager when creating a new
Infinispan CacheManager instance."Am I missing something?
-
11. Re: Utilizing Infinispan's GridFilesystem
bcarothers May 2, 2010 10:44 PM (in response to jdbrown)I believe that, in this case, the documentation describes how it's supposed to work rather than how it works. The cacheConfigurationName parameter doesn't get read in InifnispanSource.getConnection().
You can expect to see that bug get fixed in the near future, but a workaround for right now is to configure the Infinispan cache outside of ModeShape, bind it to JNDI, and use the cacheManagerJndiName property to link the InifnispanRepository to your cache manager.
-
12. Re: Utilizing Infinispan's GridFilesystem
meetoblivion May 2, 2010 11:39 PM (in response to jdbrown)i think what i'm describing and what you're describing are two very different things. what i'm saying is that there's no way to tell modeshaper how to configure infinispan before using it - either you create a cache manager and bind it to JNDI, then initial mode shape to use that cache manager; or you use the default cache manager only. using only the default cache manager covers a very simplistic use case - you miss out on the clustering/replication of infinispan. the property you're describing tells modeshape what to plugin for the method call cacheManager.getCache(String cacheName), and this doesn't seem to work either. looking back at what i describe though, it seems clear that there were a few things missed along the way
-
13. Re: Utilizing Infinispan's GridFilesystem
bcarothers May 3, 2010 6:46 AM (in response to meetoblivion)I could be mistaken, but it sounds like you're expecting the cacheConfigurationName (once fixed) to be used as an argument to cacheManager.getCache(cacheName). This won't work in the current implementation, as we use one cache per workspace. In other words, we're already calling cacheManager.getCache(workspaceName).[1]
My intent was to implement this as cacheManager = new DefaultCacheManager(cacheConfigurationName) and use cacheConfigurationName as a path to a resource or file containing configuration information. This restores the ability to bundle custom Infinispan configuration with a ModeShape deployment that I accidentally removed a few months ago.
This falls somewhat short of the original request in MODE-711 to be able to provide Infinispan configuration either through an external file or inline in the connector configuration. I'm trying to avoid having inline configuration that would have to match how some other project laid out their configuration file. Does the approach above get us to where we need to be?
Thanks to all for the discussion and for any future feedback.
[1] - It's possible that this could change in the near future. The connectors that support referenceable nodes are currently undergoing some rework to have better support for atomic transactions. That's why I haven't already implemented my proposed fix for MODE-711 - the code is in flux.
-
14. Re: Utilizing Infinispan's GridFilesystem
jdbrown May 3, 2010 8:31 AM (in response to bcarothers)Brian, yes I think we are on the same page. I was expecting that property to point to an Infinispan resource configuration file, so that I could configure the Infinispan cache as distributed or replicated, etc - basically full control over the cache configuration. Sounds like that is the plan for the future. For now, I will try the workaround you suggested of instantiating the cache externally and connecting via JNDI. However, you metion this functionality use to work? If so, what version of ModeSpace was this working with - perhaps I will revert back to that version... Thanks again.