[infinispan-dev] Refactoring API and Commons

[Michal Linhard]

On 10/26/2011 06:29 PM, Galder Zamarreño wrote:
> 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.
Personally, what I don't like about the infinispan-core dependency is 
that it makes you falsely think that you should keep the infinispan-core 
version in sync on both sides.

But that's not true. You should be able to use infinispan-core as old as 
the Hot rod protocol version allows even with the newest infinispan. 
OTOH This problem will actually exist even with refactored packaging.

Actually, what I don't like is the fact that we say that this client is 
e.g. infinispan 5.1.0.BETA2, but actually we should be saying that this 
client supports hotrod v1 - infinispan version shouldn't bother us on 
the client side...

m.
> 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Michal Linhard
Quality Assurance Engineer
JBoss Enterprise Datagrid

Red Hat Czech s.r.o.
Purkynova 99 612 45 Brno, Czech Republic
phone: +420 532 294 320 ext. 62320
mobile: +420 728 626 363