Re: [infinispan-dev] Refactoring API and Commons

First of all, what is the problem that the Hot Rod client has depending on core/ as it is? It's not clear from the JIRA.

On Oct 25, 2011, at 3:56 PM, Tristan Tarrant wrote: > Hi all, > > I've been looking into refactoring certain interfaces and common classes > as part of https://issues.jboss.org/browse/ISPN-1490 > I have come across a couple of snags (more will come I'm sure). > > Firstly all modules use org.infinispan.util.logging.LoggingFactory to > get a logger. Unfortunately the logger in question implements the > org.infinispan.util.logging.Log interface which contains a ton of > logging methods mostly related to core functionality, and therefore > irrelevant for things such as the remote APIs. Some are irrelevant, some could potentially be re-used by other modules :) (* playing devil's advocate) > My suggestion here is > that each module either uses a specialized LoggingFactory or create a > common one which returns implementations of BasicLogger (which is the > root interface of our Logs). Tbh, I'm not fuzzed about it. I think the reason I originally I designed this as it is to limit the number of changes associated with using JBoss Logging. So, by having a common LogFactory for all, I was saving quite a bit of refactoring! As you can see from this commit, integrating JBoss Logging was no small task: https://github.com/infinispan/infinispan/pull/275/files > Another one is related to org.infinispan.util.FileLookupFactory which > references OSGi classes, even though the org.osgi dependency is marked > as optional in the infinispan-core POM. In my opinion the OsgiFileLookup > should be put in an external class and loaded via reflection so that we > don't get NoClassDefFoundErrors. > > I've also introduced at the API level a BasicCache<K,V> which now > Cache<K,V> extends. BasicCache<K,V> knows nothing about Lifecycle, > Listenable, AdvancedCache, Configuration, eviction, batching and is > intended to be the base for the RemoteCache<K,V> interface. I don't necessarily disagree with these changes, but a little worried about changing all this in the middle of the 5.x series without a good reason. I think we can look into this again for 6.0 > Suggestions, recommendations, etc. > > Tristan > > > _______________________________________________ > 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