5:07 p.m.
Bill Middleton wrote:
A cursory (and likely naive) inspection of DefaultCacheFactory and
CacheImpl seems to indicate that providing my own channel should be
fairly easy to implement, even if an extension won't quite get the job
done, since channel is private. The intimidating part is the binding
between the "official" multiplexed channel (mbean) and other
functionality which implies a full app-server, such as the
TransactionManager.
Not sure what you mean here by "binding". Passing a JChannelFactoryMBean
to the RuntimeConfig doesn't carry with it a requirement to pass in a
TransactionManager. Think of RuntimeConfig as basically being a
placeholder through which the external environment can pass in complex
objects the cache may need and through which callers can get access to a
few of the cache internals.
If I were to pass in a channel to CacheImpl,
whether multiplexed or not, I don't think I'll mess with
setUsingMultiplexer() and friends in the Configuration. Since I'm going
to manage the muliplexer functionality myself I guess it makes sense to
let Cache think that it's just a simple channel. This seems safe
enough, I hope.
Sure, as long as in reality it's a multiplexed channel, so the cache
doesn't get messages it won't understand. If you're writing your own
extensions, then presumably you know how the code will be used and can
guard against misuse. So, the barrier for what's considered "safe" can
be a lot lower. :)
Thanks very much for the reply. Those of us who haven't made the
"big
switch" to a full jboss deployment are very glad to be able to use your
products individually in a "mix and match" configuration. :-)
+100; that's why I'm not happy with RuntimeConfig using
JChannelFactoryMBean as its property type; it implies more than is
necessary. We also need to better document the purpose of the
RuntimeConfig (and maybe conceptually tighten it up a bit.)
- Brian
On 4/6/07, *Brian Stansberry* <brian.stansberry(a)redhat.com
<mailto:brian.stansberry@redhat.com>> wrote:
Hmm. The cache's RuntimeConfig object only allowing injection of
JChannelFactoryMBean isn't good; at least being able to inject a plain
org.jgroups.JChannelFactory seems called for. The ugly bit is the class
and the interface have no direct type relationship, so you'd have to
expose properties of both types.
I think the reason for not allowing passing a Channel to the
RuntimeConfig is that would imply exposing the Channel as well. The
Channel is not meant to be exposed to outside callers for the same
reason we no longer expose the RpcDispatcher.
Bill Middleton wrote:
>
> > It does appear that I can get access to the rpcdispatcher
for the
> > jboss cache using getRPCManager(), or via implementing the
> depracated
> > RpcTreeCache, so it may be that my implementation can just
use an
> > standard CacheSPI, and doesn't need to extend CacheImpl
(or some
> other
> > concrete class), right?
>
> I would discourage you from doing that. Exposing the
RpcDispatcher in
> JBossCache was necessary for our internal aspects to invoke
the (public)
> methods on it, but we never intended for users of cache to
use it. So,
> in 2.0 we removed them (or made them available only through
the SPI
> API).
>
>
> Thanks for the advice, Bela. Unfortunately, an mbean is not a viable
> option for us. I can gladly create a multiplexer using the standard
> jgroups api (as seen in MultiplexerStressTest.java, for example), but
> that'd imply an ability to pass in my Channel directly to the Cache
> constructor, I assume, and DefaultCacheFactory doesn't seem to
> interested in letting me do that.
>
> Bill
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
11:31 p.m.
New subject: [javagroups-users] Considering migrating to jboss cache from DistributedTree
Thanks for the encouraging reply, Brian. My followup is inline, and there's
a proposed patch at the end.
Bill
On 4/6/07, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
Bill Middleton wrote:
> A cursory (and likely naive) inspection of DefaultCacheFactory and
> CacheImpl seems to indicate that providing my own channel should be
> fairly easy to implement, even if an extension won't quite get the job
> done, since channel is private. The intimidating part is the binding
> between the "official" multiplexed channel (mbean) and other
> functionality which implies a full app-server, such as the
> TransactionManager.
Not sure what you mean here by "binding". Passing a JChannelFactoryMBean
to the RuntimeConfig doesn't carry with it a requirement to pass in a
TransactionManager. Think of RuntimeConfig as basically being a
placeholder through which the external environment can pass in complex
objects the cache may need and through which callers can get access to a
few of the cache internals.
Every test I run does insist upon looking for a TransactionManager, if one
isn't found then a DummyTransactionManager is the "fall back" solution.
Granted though, it's not bound to an app server.
If I were to pass in a channel to CacheImpl,
> whether multiplexed or not, I don't think I'll mess with
> setUsingMultiplexer() and friends in the Configuration. Since I'm going
> to manage the muliplexer functionality myself I guess it makes sense to
> let Cache think that it's just a simple channel. This seems safe
> enough, I hope.
>
Sure, as long as in reality it's a multiplexed channel, so the cache
doesn't get messages it won't understand. If you're writing your own
extensions, then presumably you know how the code will be used and can
guard against misuse. So, the barrier for what's considered "safe" can
be a lot lower. :)
My proposed patch doesn't require a multiplexed channel be passed in. The
implementation can pass in either an ordinary JChannel (via new JChannel())
or one that's created via createMultiplexerChannel(). All of the state
transfer tests pass in either case. In neither case is the Configuration
set using setUsingMultiplexer(true). isUsingMultiplexer is always false.
Seems to work ok - all tests pass using an adapted
StateTransferCompatibilityTest.java, anyhow.
Generally, my patch adds a new constructor, CacheImpl(Channel c). This is
called by a new createChannel() method in the DefaultChannelFactory which
accepts a channel, configuration, and boolean. If the new constructor is
used to construct a ChannelImpl, then a global boolean is set which makes
the create() method do the right thing at init-time.
Is this approach way too simple minded? It's not providing any additional
access to the internals of the cache per se, but yes, one must be careful in
configuring the channel. Whats still missing here is the ability to fetch
the entire Element <protocol_stacks> from the Configuration and pass it
directly to the JChannelFactory(Element) constructor, so that the external
JGroups stack would be guaranteed to match the one which is specified in the
config.
Bill
PS - sorry about the indentation in the patch, Eclipse cant quite figure
out the scheme that jbosscache is using.
5:11 p.m.
New subject: [javagroups-users] Considering migrating to jboss cache from DistributedTree
Thanks much for this, Bill. Sorry for the slow reply. I'm going to
wait and let Manik Surtani comment on this, as I know he's thought a lot
more than I have about how he wants the factories and the CacheImpl
constructor to work.
Bill Middleton wrote:
Thanks for the encouraging reply, Brian. My followup is inline, and
there's a proposed patch at the end.
Bill
On 4/6/07, *Brian Stansberry* < brian.stansberry(a)redhat.com
<mailto:brian.stansberry@redhat.com>> wrote:
Bill Middleton wrote:
> A cursory (and likely naive) inspection of DefaultCacheFactory and
> CacheImpl seems to indicate that providing my own channel should be
> fairly easy to implement, even if an extension won't quite get
the job
> done, since channel is private. The intimidating part is the binding
> between the "official" multiplexed channel (mbean) and other
> functionality which implies a full app-server, such as the
> TransactionManager.
Not sure what you mean here by "binding". Passing a JChannelFactoryMBean
to the RuntimeConfig doesn't carry with it a requirement to pass in a
TransactionManager. Think of RuntimeConfig as basically being a
placeholder through which the external environment can pass in complex
objects the cache may need and through which callers can get access to a
few of the cache internals.
Every test I run does insist upon looking for a TransactionManager, if
one isn't found then a DummyTransactionManager is the "fall back"
solution. Granted though, it's not bound to an app server.
> If I were to pass in a channel to CacheImpl,
> whether multiplexed or not, I don't think I'll mess with
> setUsingMultiplexer() and friends in the Configuration. Since I'm
going
> to manage the muliplexer functionality myself I guess it makes
sense to
> let Cache think that it's just a simple channel. This seems safe
> enough, I hope.
>
Sure, as long as in reality it's a multiplexed channel, so the cache
doesn't get messages it won't understand. If you're writing your own
extensions, then presumably you know how the code will be used and can
guard against misuse. So, the barrier for what's considered "safe" can
be a lot lower. :)
My proposed patch doesn't require a multiplexed channel be passed in.
The implementation can pass in either an ordinary JChannel (via new
JChannel()) or one that's created via createMultiplexerChannel(). All
of the state transfer tests pass in either case. In neither case is the
Configuration set using setUsingMultiplexer(true). isUsingMultiplexer is
always false. Seems to work ok - all tests pass using an adapted
StateTransferCompatibilityTest.java, anyhow.
Generally, my patch adds a new constructor, CacheImpl(Channel c). This
is called by a new createChannel() method in the DefaultChannelFactory
which accepts a channel, configuration, and boolean. If the new
constructor is used to construct a ChannelImpl, then a global boolean is
set which makes the create() method do the right thing at init-time.
Is this approach way too simple minded? It's not providing any
additional access to the internals of the cache per se, but yes, one
must be careful in configuring the channel. Whats still missing here is
the ability to fetch the entire Element <protocol_stacks> from the
Configuration and pass it directly to the JChannelFactory(Element)
constructor, so that the external JGroups stack would be guaranteed to
match the one which is specified in the config.
Bill
PS - sorry about the indentation in the patch, Eclipse cant quite
figure out the scheme that jbosscache is using.
------------------------------------------------------------------------
? patch
Index: CacheFactory.java
===================================================================
RCS file: /cvsroot/jboss/JBossCache/src/org/jboss/cache/CacheFactory.java,v
retrieving revision 1.7
diff -r1.7 CacheFactory.java
11a12
> import org.jgroups.Channel;
111a113,131
> /**
> * Creates {@link Cache} instance, by passing in a pre-configured {@link
org.jgroups.JChannel}
> * and optionally starts it based on the boolean start value. The new cache's
configuration
> * will be based on a {@link org.jboss.cache.config.Configuration} passed in.
> * <p/>
> * Ensure that the Configuration you pass in is not used by another cache instance
in the same JVM,
> * as it may be concurrently modified. Clone the configuration, if shared, using
> * {@link org.jboss.cache.config.Configuration#clone()}.
> *
> * @param configuration the {@link org.jgroups.JChannel} to use (cast to simple
channel).
> * @param configuration the {@link Configuration} object that is passed in to
setCache the {@link Cache}.
> * @param start if true, the cache is started before returning.
> * @return an optionally running {@link Cache} instance
> * @throws org.jboss.cache.config.ConfigurationException
> * if there are problems with the configuration
> */
> Cache<K, V> createCache(Channel ch, Configuration configuration, boolean
start) throws ConfigurationException;
>
Index: CacheImpl.java
===================================================================
RCS file: /cvsroot/jboss/JBossCache/src/org/jboss/cache/CacheImpl.java,v
retrieving revision 1.57
diff -r1.57 CacheImpl.java
238c238,245
<
---
>
> /**
> * Have we gotten a channel passed in from the
> * implementation? We set this to false in the
> * constructor if so. Ordinarily isMyChannel is always true.
> */
> private boolean isMyChannel = true;
>
260a268,282
> /**
> * Constructs an uninitialized CacheImpl with a provided channel
> */
> protected CacheImpl(Channel ch) throws Exception
> {
> isMyChannel = false;
> if(ch instanceof JChannel){
> channel = (JChannel)ch;
> }
> else{
> throw new Exception("Not a JChannel!");
> }
> notifier = new Notifier(this);
> regionManager = new RegionManager(this);
> }
643c665,669
< if (channel != null)
---
> // We have to test both the channel and disp here, in
> // case we've passed in our own channel. The dispatcher
> // must be created in either case.
> if ((channel != null) && (disp != null))
649,653c675,686
< // Try to create a multiplexer channel
< channel = getMultiplexerChannel();
<
< if (channel != null)
< {
---
> // Try to create a multiplexer channel if we didnt get a channel passed
in
> if(isMyChannel){
> channel = getMultiplexerChannel();
> }
>
> if ((channel != null) && isMyChannel)
> {
>
> // Success creating the multiplexer channel.
> // Now we have to let the config know about our joy.
> // Note that we never do this if we've passed in a channel,
> // even if that channel is multiplexed.
676,680c709,712
< try
< {
< channel = new JChannel(configuration.getClusterConfig());
< }
< catch (Exception e)
---
>
> // If we've not passed in a channel
> // we need to create a non-multiplexed one now
> if (isMyChannel)
682,683c714,720
< throw new CacheException("Unable to create JGroups
channel", e);
< }
---
> try {
> channel = new JChannel(configuration.getClusterConfig());
> } catch (Exception e) {
> throw new CacheException(
> "Unable to create JGroups channel", e);
> }
> }
Index: DefaultCacheFactory.java
===================================================================
RCS file: /cvsroot/jboss/JBossCache/src/org/jboss/cache/DefaultCacheFactory.java,v
retrieving revision 1.6
diff -r1.6 DefaultCacheFactory.java
11a12
> import org.jgroups.Channel;
102a104,135
> /**
> * This implementation clones the configuration passed in before using it.
> * It also allows the client to pass in its own channel.
> *
> * @param ch the pre-configured JChannel to use
> * @param configuration to use. We assume that the channel has been setup using
this
> * @param start whether to start the cache
> * @return a cache
> * @throws ConfigurationException if there are problems with the cfg
> */
> public Cache<K, V> createCache(Channel ch, Configuration configuration,
boolean start) throws ConfigurationException
> {
> try
> {
> CacheImpl<K, V> cache = new CacheImpl<K, V>(ch);
> cache.setConfiguration(configuration);
> if (start) cache.start();
> return cache;
> }
> catch (ConfigurationException ce)
> {
> throw ce;
> }
> catch (RuntimeException re)
> {
> throw re;
> }
> catch (Exception e)
> {
> throw new RuntimeException(e);
> }
> }
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
9:51 p.m.
New subject: [javagroups-users] Considering migrating to jboss cache from DistributedTree
I've opened a jira feature request for this now.
http://jira.jboss.com/jira/browse/JBCACHE-1023 <<< Good number
Thanks again!
Bill
On 4/12/07, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
Thanks much for this, Bill. Sorry for the slow reply. I'm going to
wait and let Manik Surtani comment on this, as I know he's thought a lot
more than I have about how he wants the factories and the CacheImpl
constructor to work.
5:50 p.m.
New subject: [javagroups-users] Considering migrating to jboss cache from DistributedTree
Sorry for being so late jumping in on this.
Bill, I see you've had most of your questions answered already, but I
still don't quite get the need for injecting your own JGroups
Channel, perhaps you could help clarify this for me?
Cheers,
Manik
On 12 Apr 2007, at 20:51, Bill Middleton wrote:
I've opened a jira feature request for this now.
http://jira.jboss.com/jira/browse/JBCACHE-1023 <<< Good number
Thanks again!
Bill
On 4/12/07, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
Thanks much for this, Bill. Sorry for the slow reply. I'm going to
wait and let Manik Surtani comment on this, as I know he's thought
a lot
more than I have about how he wants the factories and the CacheImpl
constructor to work.
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
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
6:31 p.m.
New subject: [javagroups-users] Considering migrating to jboss cache from DistributedTree
Hi Manik, thanks for taking the time to look at this. To answer your
question, the simple reason for allowing this change is to make the cache
independent of an mbean server. I would argue that there are plenty of
older j2se apps out there that could make use of the cache, but are perhaps
not ready to make the jump to a full AS.
But there are other reasons.
Consider, for example, the case where a given application can deploy on and
obtain firewall permissions for only one tcp port. If that application
needs to provide jgroups functionality of both the sync and async type, then
there's little choice but to multiplex a single jchannel. Since I want to
use JbossCache, I have little choice but to grab the cache's Rpcdispatcher
and send my own messages, since I cant get a jchannel out of jbosscache
either.
I guess that's both ends of the argument. Either solution would work,
either allow us non-AS folks to inject our own channel to the cache, or
provide us a means to fetch one out. My patch, which is working ok for me
here, does the former. The single additional method on the factory requires
a complete configuration, which will hopefully discourage all but the most
stubborn from trying to use it.
But I think you'll win some new cache customers if you provide it.
Regards,
Bill Middleton
On 4/20/07, Manik Surtani <manik(a)jboss.org> wrote:
Sorry for being so late jumping in on this.
Bill, I see you've had most of your questions answered already, but I
still don't quite get the need for injecting your own JGroups
Channel, perhaps you could help clarify this for me?
Cheers,
Manik
On 12 Apr 2007, at 20:51, Bill Middleton wrote:
> I've opened a jira feature request for this now.
>
> http://jira.jboss.com/jira/browse/JBCACHE-1023 <<< Good number
>
> Thanks again!
>
> Bill
>
> On 4/12/07, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
> Thanks much for this, Bill. Sorry for the slow reply. I'm going to
> wait and let Manik Surtani comment on this, as I know he's thought
> a lot
> more than I have about how he wants the factories and the CacheImpl
> constructor to work.
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
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
2:16 p.m.
New subject: [javagroups-users] Considering migrating to jboss cache from DistributedTree
Bill,
Fair comment, especially around requiring to use the channel for your
own purposes.
In terms of approach though, I'd rather this channel be injected via
the RuntimeConfig rather than being passed in through the factory as
this is where other services (e.g., TransactionManagers) get injected
by IOC frameworks.
So what you'd do is something like:
cache = DefaultCacheFactory.createCache(config, false);
cache.getConfiguration().getRuntimeConfiguration().setChannel
(myChannel);
cache.start();
Does this make sense?
Cheers,
Manik
On 20 Apr 2007, at 17:31, Bill Middleton wrote:
Hi Manik, thanks for taking the time to look at this. To answer
your question, the simple reason for allowing this change is to
make the cache independent of an mbean server. I would argue that
there are plenty of older j2se apps out there that could make use
of the cache, but are perhaps not ready to make the jump to a full AS.
But there are other reasons.
Consider, for example, the case where a given application can
deploy on and obtain firewall permissions for only one tcp port.
If that application needs to provide jgroups functionality of both
the sync and async type, then there's little choice but to
multiplex a single jchannel. Since I want to use JbossCache, I
have little choice but to grab the cache's Rpcdispatcher and send
my own messages, since I cant get a jchannel out of jbosscache either.
I guess that's both ends of the argument. Either solution would
work, either allow us non-AS folks to inject our own channel to the
cache, or provide us a means to fetch one out. My patch, which is
working ok for me here, does the former. The single additional
method on the factory requires a complete configuration, which will
hopefully discourage all but the most stubborn from trying to use it.
But I think you'll win some new cache customers if you provide it.
Regards,
Bill Middleton
On 4/20/07, Manik Surtani <manik(a)jboss.org> wrote:Sorry for being
so late jumping in on this.
Bill, I see you've had most of your questions answered already, but I
still don't quite get the need for injecting your own JGroups
Channel, perhaps you could help clarify this for me?
Cheers,
Manik
On 12 Apr 2007, at 20:51, Bill Middleton wrote:
> I've opened a jira feature request for this now.
>
> http://jira.jboss.com/jira/browse/JBCACHE-1023 <<< Good number
>
> Thanks again!
>
> Bill
>
> On 4/12/07, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
> Thanks much for this, Bill. Sorry for the slow reply. I'm going to
> wait and let Manik Surtani comment on this, as I know he's thought
> a lot
> more than I have about how he wants the factories and the CacheImpl
> constructor to work.
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
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
--
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
3:20 p.m.
New subject: [javagroups-users] Considering migrating to jboss cache from DistributedTree
That would be lovely.
Thanks Manik.
----
Bill
On 4/23/07, Manik Surtani <manik(a)jboss.org> wrote:
Bill,
Fair comment, especially around requiring to use the channel for your
own purposes.
In terms of approach though, I'd rather this channel be injected via
the RuntimeConfig rather than being passed in through the factory as
this is where other services (e.g., TransactionManagers) get injected
by IOC frameworks.
So what you'd do is something like:
cache = DefaultCacheFactory.createCache(config, false);
cache.getConfiguration().getRuntimeConfiguration().setChannel
(myChannel);
cache.start();
Does this make sense?
Cheers,
Manik
On 20 Apr 2007, at 17:31, Bill Middleton wrote:
> Hi Manik, thanks for taking the time to look at this. To answer
> your question, the simple reason for allowing this change is to
> make the cache independent of an mbean server. I would argue that
> there are plenty of older j2se apps out there that could make use
> of the cache, but are perhaps not ready to make the jump to a full AS.
>
> But there are other reasons.
>
> Consider, for example, the case where a given application can
> deploy on and obtain firewall permissions for only one tcp port.
> If that application needs to provide jgroups functionality of both
> the sync and async type, then there's little choice but to
> multiplex a single jchannel. Since I want to use JbossCache, I
> have little choice but to grab the cache's Rpcdispatcher and send
> my own messages, since I cant get a jchannel out of jbosscache either.
>
> I guess that's both ends of the argument. Either solution would
> work, either allow us non-AS folks to inject our own channel to the
> cache, or provide us a means to fetch one out. My patch, which is
> working ok for me here, does the former. The single additional
> method on the factory requires a complete configuration, which will
> hopefully discourage all but the most stubborn from trying to use it.
>
> But I think you'll win some new cache customers if you provide it.
>
> Regards,
>
> Bill Middleton
>
>
>
>
> On 4/20/07, Manik Surtani <manik(a)jboss.org> wrote:Sorry for being
> so late jumping in on this.
>
> Bill, I see you've had most of your questions answered already, but I
> still don't quite get the need for injecting your own JGroups
> Channel, perhaps you could help clarify this for me?
>
> Cheers,
> Manik
>
> On 12 Apr 2007, at 20:51, Bill Middleton wrote:
>
> > I've opened a jira feature request for this now.
> >
> > http://jira.jboss.com/jira/browse/JBCACHE-1023 <<< Good number
> >
> > Thanks again!
> >
> > Bill
> >
> > On 4/12/07, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
> > Thanks much for this, Bill. Sorry for the slow reply. I'm going to
> > wait and let Manik Surtani comment on this, as I know he's thought
> > a lot
> > more than I have about how he wants the factories and the CacheImpl
> > constructor to work.
> >
> >
> > _______________________________________________
> > jbosscache-dev mailing list
> > jbosscache-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> --
> 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
>
>
>
--
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
6206
days inactive
6223
days old
jbosscache-dev@lists.jboss.org
7 comments
3 participants
participants (3)
-
Bill Middleton -
Brian Stansberry -
Manik Surtani