RE: [jbosscache-dev] FW: [JBoss-dev] Version numbers in libraryfilenames - Bad
by Galder Zamarreno
However, Dimitris comments class with the convention used by Maven which seem like is the one that we're following. More on JBoss-Dev list.
Galder Zamarreño
Support Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: Brian Stansberry
Sent: 20 September 2006 16:27
To: Galder Zamarreno; jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] FW: [JBoss-dev] Version numbers in libraryfilenames - Bad
Not directly, because JBC doesn't get its libs from the repository. But, IMHO this kind of thing should be handled consistently across JBoss, so JBC probably should follow the standard.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Guys,
>
> I think this affects our decision to put version numbers in
> the library filenames, am I correct?
>
> Galder Zamarreño
> Support Engineer
> JBoss, a division of Red Hat
>
>
> -----Original Message-----
> From: jboss-development-bounces(a)lists.jboss.org
> [mailto:jboss-development-bounces@lists.jboss.org] On Behalf
> Of Dimitris Andreadis
> Sent: 20 September 2006 13:37
> To: JBoss.org development list
> Cc: The Core
> Subject: [JBoss-dev] Version numbers in library filenames - Bad
>
> I've seen a few cases where in repository.jboss.com the
> version number for a library is included in the library filename,
>
> E.g.
> antlr-2.7.6.jar
> addressing-1.0.jar
> odmg-3.0.jar
> quartz-all-1.5.2.jar
> dtdparser121.jar
> commons-lang-2.1.jar
> myfaces-impl-1.1.3.jar
>
> Even worse:
> Cglib/2.1.0/lib/cglib.jar, cglib-2.1.1.jar
>
> This is wrong, because
> - whenever a library is updated we have to correct all
> explicit references to it
> - If you don't wipe your thirdparty on every update you may
> end up with
> 3 different versions of the same library and wonder for hours what's
> wrong.
>
> The version is encoded in the path and the library's
> META-INF/MANIFEST.MF, not the filename, e.g:
>
> apache-logging/1.0.3/lib/commons-logging.jar
>
> For existing libs the harm is already done, but for new
> library additions to repository.jboss.com, please have that
> in mind and remove any version number from the filenames.
>
> Thanks
> /Dimitris
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
17 years, 7 months
RE: [jbosscache-dev] FW: [JBoss-dev] Version numbers in libraryfilenames - Bad
by Brian Stansberry
Not directly, because JBC doesn't get its libs from the repository. But, IMHO this kind of thing should be handled consistently across JBoss, so JBC probably should follow the standard.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Guys,
>
> I think this affects our decision to put version numbers in
> the library filenames, am I correct?
>
> Galder Zamarreño
> Support Engineer
> JBoss, a division of Red Hat
>
>
> -----Original Message-----
> From: jboss-development-bounces(a)lists.jboss.org
> [mailto:jboss-development-bounces@lists.jboss.org] On Behalf
> Of Dimitris Andreadis
> Sent: 20 September 2006 13:37
> To: JBoss.org development list
> Cc: The Core
> Subject: [JBoss-dev] Version numbers in library filenames - Bad
>
> I've seen a few cases where in repository.jboss.com the
> version number for a library is included in the library filename,
>
> E.g.
> antlr-2.7.6.jar
> addressing-1.0.jar
> odmg-3.0.jar
> quartz-all-1.5.2.jar
> dtdparser121.jar
> commons-lang-2.1.jar
> myfaces-impl-1.1.3.jar
>
> Even worse:
> Cglib/2.1.0/lib/cglib.jar, cglib-2.1.1.jar
>
> This is wrong, because
> - whenever a library is updated we have to correct all
> explicit references to it
> - If you don't wipe your thirdparty on every update you may
> end up with
> 3 different versions of the same library and wonder for hours what's
> wrong.
>
> The version is encoded in the path and the library's
> META-INF/MANIFEST.MF, not the filename, e.g:
>
> apache-logging/1.0.3/lib/commons-logging.jar
>
> For existing libs the harm is already done, but for new
> library additions to repository.jboss.com, please have that
> in mind and remove any version number from the filenames.
>
> Thanks
> /Dimitris
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
17 years, 7 months
FW: [JBoss-dev] Version numbers in library filenames - Bad
by Galder Zamarreno
Guys,
I think this affects our decision to put version numbers in the library filenames, am I correct?
Galder Zamarreño
Support Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org [mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Dimitris Andreadis
Sent: 20 September 2006 13:37
To: JBoss.org development list
Cc: The Core
Subject: [JBoss-dev] Version numbers in library filenames - Bad
I've seen a few cases where in repository.jboss.com the version number
for a library is included in the library filename,
E.g.
antlr-2.7.6.jar
addressing-1.0.jar
odmg-3.0.jar
quartz-all-1.5.2.jar
dtdparser121.jar
commons-lang-2.1.jar
myfaces-impl-1.1.3.jar
Even worse:
Cglib/2.1.0/lib/cglib.jar, cglib-2.1.1.jar
This is wrong, because
- whenever a library is updated we have to correct all explicit
references to it
- If you don't wipe your thirdparty on every update you may end up with
3 different versions of the same library and wonder for hours what's
wrong.
The version is encoded in the path and the library's
META-INF/MANIFEST.MF, not the filename, e.g:
apache-logging/1.0.3/lib/commons-logging.jar
For existing libs the harm is already done, but for new library
additions to repository.jboss.com, please have that in mind and remove
any version number from the filenames.
Thanks
/Dimitris
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
17 years, 7 months
RE: [jbosscache-dev] Packaging
by Ben Wang
OK, no one objects. So I have done the first iteration of repackaging. Please let me know if there is any problem.
Thanks,
-Ben
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Tuesday, September 19, 2006 10:52 PM
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] Packaging
Hi,
Just had a call with Ben about JBoss Cache packaging. WHat do people think about:
1) JBossCache-core - binaries, jars and sample configs only
2) JBossCache-pojo - as above, with PojoCache jar as well
3) JBossCache-all - as above, with srcs, unit tests, examples and tutorial
4) JBossCache-external-jars - Just the BDBJE jar
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 7 months
Notification interceptor
by Manik Surtani
Hi,
There was talk of a separate notification interceptor some while
back. What happened around this?
Looking at wiring in the relevant notifications for move() and
realise what a PITA it is with notification calls scattered all over
the code base.
I think an interceptor at (or close to) the head of the chain to fire
notifications would be quite straightforward and easy - pre and post
notifications would be easily handled. The only notification that
would originate outside of this interceptor would be load/evict/
activate/passivate notifications ...
What do people think?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
17 years, 7 months
RE: [jbosscache-dev] CacheSPI.setStateTransferManager
by Brian Stansberry
Ah good, didn't know you had the RPCManager.
Which leads me back to the API question, because maybe RPCManager
exposes stuff too that we may not consider "public API". Public in the
sense that people can code against it and rely on it for the life of a
major release. Like the JGroups Address and MethodCall classes. But if
exposed through the CacheSPI getter, the class is out there. So a
general question is, where do we draw the line on what is the public
API?
Ideally it would be Cache and CacheSPI, plus any API exposed by a
class/interface that those interfaces expose. So, RPCManager and
StateManager would be "public". But following that rule exposes all
sorts of other stuff as well (RegionManager, TransactionManager, ...).
Manik Surtani wrote:
> It should call CacheSPI.getRPCManager().callRemote...
>
>
> On 19 Sep 2006, at 16:31, Brian Stansberry wrote:
>
>>
>> StateTransferManager invokes TreeCache.callRemoteMethods, which I
>> can't imagine being added to CacheSPI. There may be other methods
>> as well. It has a public getter/setter for the cache that subclasses
>> can use.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
17 years, 7 months
RE: [jbosscache-dev] CacheSPI.setStateTransferManager
by Brian Stansberry
Yes, but replaced with some other interaction with the JGroups layer,
which again won't be directly exposed via CacheSPI.
Vladimir Blagojevic wrote:
> But this stuff will be removed anyway as soon as we have
> partial state transfer in place, correct?
>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: Tuesday, September 19, 2006 11:48 AM
>> To: Brian Stansberry
>> Cc: Ben Wang; Vladimir Blagojevic; Manik Surtani;
>> jbosscache-dev(a)lists.jboss.org
>> Subject: Re: [jbosscache-dev] CacheSPI.setStateTransferManager
>>
>> It should call CacheSPI.getRPCManager().callRemote...
>>
>>
>> On 19 Sep 2006, at 16:31, Brian Stansberry wrote:
>>
>>>
>>> StateTransferManager invokes TreeCache.callRemoteMethods, which I
>>> can't imagine being added to CacheSPI. There may be other methods
>>> as well. It has a public getter/setter for the cache that
>>> subclasses can use.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
17 years, 7 months
RE: [jbosscache-dev] CacheSPI.setStateTransferManager
by Vladimir Blagojevic
But this stuff will be removed anyway as soon as we have partial state
transfer in place, correct?
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Tuesday, September 19, 2006 11:48 AM
> To: Brian Stansberry
> Cc: Ben Wang; Vladimir Blagojevic; Manik Surtani;
> jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] CacheSPI.setStateTransferManager
>
> It should call CacheSPI.getRPCManager().callRemote...
>
>
> On 19 Sep 2006, at 16:31, Brian Stansberry wrote:
>
> >
> > StateTransferManager invokes TreeCache.callRemoteMethods, which I
> > can't imagine being added to CacheSPI. There may be other
> methods as
> > well.
> > It has a public getter/setter for the cache that subclasses can use.
>
>
17 years, 7 months
RE: [jbosscache-dev] CacheSPI.setStateTransferManager
by Brian Stansberry
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Manik and I have just chatted. One possibility. Instead of
> have a setter on STM, we expose a sort of a static factory
> method to obtain the STM class. But this also has the same
> concern as you do to expose this prior to defining the contract.
>
We already expose StateTransferManager via the getter. Unless that can
be removed, the class is already exposed.
> The other possibility is I defer the implementation of
> PojoCacheStateTransferManager after the alpha release and
> wait for the STM API to settle down, althouhg I'd prefer to
> implement it ASAP, especially for partial state transfer piece.
>
The STM API is going to have to be settled before 2.0.0.CR1. It doesn't
have to be settled for an alpha. We need to get the alpha out for
preliminary integration work in the AS, or else cut a snapshot to
integrate. IMHO we shouldn't worry too much about the current state of
the StateTransferManager API as long as we're comfortable we can settle
it for the CR1.
> Another question. Currently, StateTransferManager is using
> TreeCache directly. Would it be possibel to use CacheSPI
> instead? Otherwise, any subclass of StateTransferManager
> isn't having access to TreeCache.
StateTransferManager invokes TreeCache.callRemoteMethods, which I can't
imagine being added to CacheSPI. There may be other methods as well.
It has a public getter/setter for the cache that subclasses can use.
>
> -Ben
>
> -----Original Message-----
> From: Vladimir Blagojevic
> Sent: Tuesday, September 19, 2006 9:41 PM
> To: Manik Surtani; Ben Wang
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: RE: [jbosscache-dev] CacheSPI.setStateTransferManager
>
> One downside is that we are opening StateTransferManager API
> to extensions and plugins prior to clearly defining the
> contract around StateTransferManager. It is sort of internal
> class that has to be promoted to a new role without being completely
> ready for it.
>
> Brian?
>
>
>> -----Original Message-----
>> From: jbosscache-dev-bounces(a)lists.jboss.org
>> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik
>> Surtani Sent: Tuesday, September 19, 2006 7:29 AM
>> To: Ben Wang
>> Cc: jbosscache-dev(a)lists.jboss.org
>> Subject: Re: [jbosscache-dev] CacheSPI.setStateTransferManager
>>
>> There should be a setter as well. Vladimir, Brian: can you think of
>> a
>
>> good reason not to allow this to be set programmatically in the SPI?
>> -- Manik Surtani
>>
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>>
>> Email: manik(a)jboss.org
>> Telephone: +44 7786 702 706
>> MSN: manik(a)surtani.org
>> Yahoo/AIM/Skype: maniksurtani
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
17 years, 7 months
Configuration.isUseInterceptorMbeans flag
by Ben Wang
We currently use this flag to signal for adding Mbean support. Any objection to change the name into a more generic one like isUseMBean? Or any other suggestion?
Thanks,
-Ben
17 years, 7 months
