11:56 p.m.
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. 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).
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.
Suggestions, recommendations, etc.
Tristan
1:29 a.m.
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
7:15 a.m.
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(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
--
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
3:51 p.m.
On 10/27/2011 12:15 AM, Michal Linhard wrote:
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
I like the JDBC comparison: when you connect to a database you are not
expected to:
1. use exactly the same version of the client as the server
2. embed the server in the client
I just built an empty project with the infinispan-hotrod-client
dependency and it brings in the following:
224958 2011-10-21 14:13 WEB-INF/lib/jboss-marshalling-1.3.0.GA.jar
96221 2011-10-21 14:13 WEB-INF/lib/commons-pool-1.5.4.jar
7635 2011-10-21 14:13 WEB-INF/lib/rhq-pluginAnnotations-3.0.1.jar
70928 2011-10-21 14:13 WEB-INF/lib/jandex-1.0.3.Final.jar
149649 2011-10-25 11:10
WEB-INF/lib/infinispan-client-hotrod-5.1.0.BETA2.jar
80929 2011-10-21 14:13
WEB-INF/lib/jboss-marshalling-river-1.3.0.GA.jar
1760173 2011-10-21 14:12 WEB-INF/lib/jgroups-3.0.0.CR5.jar
50251 2011-10-21 14:13 WEB-INF/lib/jboss-logging-3.0.0.GA.jar
10899 2011-10-21 14:13
WEB-INF/lib/jboss-transaction-api-1.0.1.GA.jar
1601837 2011-10-21 14:12 WEB-INF/lib/infinispan-core-5.1.0.BETA2.jar
For a grand total of just over 4MB. As Yoda would say, "size matters
not", but seeing pointless dependencies in there such as jgroups,
rhq-pluginAnnotations and jandex does make it look unpolished and
unprofessional.
Tristan
11:34 p.m.
On 27 Oct 2011, at 07:51, Tristan Tarrant wrote:
For a grand total of just over 4MB. As Yoda would say, "size matters not", but
seeing pointless dependencies in there such as jgroups, rhq-pluginAnnotations and jandex
does make it look unpolished and unprofessional.
Plus in general it's cleaner to separate core functionality, common utils and public
API as it makes it easier to restrict certain bits from use, such as Infinispan in EAP.
So +1 to all of Tristan's recommendations in his original email.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
12:40 a.m.
On 27 Oct 2011, at 16:01, Tristan Tarrant wrote:
On 10/27/2011 04:34 PM, Manik Surtani wrote:
> So +1 to all of Tristan's recommendations in his original email.
>
Regarding schedule ?
As in, for 5.1? Again, I'm happy with this.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
12:41 a.m.
On 10/27/2011 05:40 PM, Manik Surtani wrote:
On 27 Oct 2011, at 16:01, Tristan Tarrant wrote:
> On 10/27/2011 04:34 PM, Manik Surtani wrote:
>> So +1 to all of Tristan's recommendations in his original email.
>>
> Regarding schedule ?
As in, for 5.1? Again, I'm happy with this.
Ok, I'll issue an initial pull request tomorrow for comments.
Tristan
4576
days inactive
4578
days old
infinispan-dev@lists.jboss.org
7 comments
4 participants
participants (4)
-
Galder Zamarreño -
Manik Surtani -
Michal Linhard -
Tristan Tarrant