Reliance on jboss-jmx.jar in 2.0.0
by Manik Surtani
Hi guys,
We currently have 2 instances where we need jboss-jmx.jar in HEAD:
org.jboss.mx.util.MBeanProxyExt is used in TcpCacheServer and
RmiCacheServer.
Before I start digging into this, does anyone know what MBeanProxyExt
is replaced with?
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, 6 months
Fwd: [jbosscache-dev] RE: http://jira.jboss.com/jira/browse/JBCACHE-644
by Manik Surtani
I suppose given that we're not even recommending the FCL for most
production use cases, perhaps just log a warning in the FCL when such
characters are encountered, warning of the lack of portability and
the potential for an IOException?
>
>
>
> On 23 Oct 2006, at 17:13, Galder Zamarreno wrote:
>
>> Looking at this further, what do we wanna do if we encounter one
>> of this characters when creating the file/directory?
>>
>> We could substitute them for other allowed characters, but it
>> would also mean that a get operation would have to translate the
>> fqn to the allowed fqn with the substituted characters. We would
>> need some kind of mapping between the original fqn and the
>> translated one.
>>
>> Is it really worth doing this? The more I think about it, the more
>> I feel that it seems like adding an unnecessary layer of
>> complexity to the FCL, especially when there's a very easy
>> alternative to it, which is not using those characters.
>>
>> I found this article talking about differences between Linux, Mac
>> and Windows: http://linux.wordpress.com/2006/07/23/linux-mac-
>> windows-file-name-friction/
>>
>> Windows is definitely the most restrictive, but Linux and Mac
>> might sound more restrictive in this sense, but might have to get
>> around it to create files with these characters (use ' '
>> characters, or '\').
>>
>> It ends up saying:
>>
>> Avoid using these characaters
>> for maximum portability
>>
>> Asterisk *
>> Colon :
>> Back slash \
>> Forward slash /
>> Less Than <
>> Greater Than >
>> Pipe |
>> Quote "
>> Question mark ?
>>
>> What do you think? Is it really worth it?
>>
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
>>
>>
>> -----Original Message-----
>> From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-
>> dev-bounces(a)lists.jboss.org] On Behalf Of Galder Zamarreno
>> Sent: 20 October 2006 12:00
>> To: Manik Surtani
>> Cc: jbosscache-dev(a)lists.jboss.org
>> Subject: [jbosscache-dev] RE: http://jira.jboss.com/jira/browse/
>> JBCACHE-644
>>
>> I'd stick to general rules.
>>
>> Cheers,
>>
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
>>
>>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: 20 October 2006 11:57
>> To: Galder Zamarreno
>> Cc: jbosscache-dev(a)lists.jboss.org
>> Subject: Re: http://jira.jboss.com/jira/browse/JBCACHE-644
>>
>> Yes, I think so ...
>>
>> Just be generic. Perhaps the FileCacheLoader could take an optional
>> property containing a list of OS-specific illegal characters for the
>> deployed platform, but then again if someone can specify this, they'd
>> know not to use these characters in the cache anyway.
>>
>> I'd just stick with the generic illegal chars.
>>
>>
>> --
>> 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
>>
>>
>> On 20 Oct 2006, at 10:48, Galder Zamarreno wrote:
>>
>>> There's a hard limit in Windows by which a file path cannot be
>>> bigger than 255 characters, so that's an OS limit itself.
>>>
>>> Illegal characters vary depending on the OS, but there's some that
>>> apply to all OS.
>>>
>>> How do you wanna approach this? Shall we focus on limitations
>>> applying to all OS? I doubt we wanna be coding something that is
>>> dependant on the OS.
>>>
>>> Galder Zamarreño
>>> Sr. Software Maintenance Engineer
>>> JBoss, a division of Red Hat
>>>
>>>
>>
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
17 years, 6 months
RE: [jbosscache-dev] RE: http://jira.jboss.com/jira/browse/JBCACHE-644
by Galder Zamarreno
Looking at this further, what do we wanna do if we encounter one of this characters when creating the file/directory?
We could substitute them for other allowed characters, but it would also mean that a get operation would have to translate the fqn to the allowed fqn with the substituted characters. We would need some kind of mapping between the original fqn and the translated one.
Is it really worth doing this? The more I think about it, the more I feel that it seems like adding an unnecessary layer of complexity to the FCL, especially when there's a very easy alternative to it, which is not using those characters.
I found this article talking about differences between Linux, Mac and Windows: http://linux.wordpress.com/2006/07/23/linux-mac-windows-file-name-friction/
Windows is definitely the most restrictive, but Linux and Mac might sound more restrictive in this sense, but might have to get around it to create files with these characters (use ' ' characters, or '\').
It ends up saying:
Avoid using these characaters
for maximum portability
Asterisk *
Colon :
Back slash \
Forward slash /
Less Than <
Greater Than >
Pipe |
Quote "
Question mark ?
What do you think? Is it really worth it?
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Galder Zamarreno
Sent: 20 October 2006 12:00
To: Manik Surtani
Cc: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] RE: http://jira.jboss.com/jira/browse/JBCACHE-644
I'd stick to general rules.
Cheers,
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: 20 October 2006 11:57
To: Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: http://jira.jboss.com/jira/browse/JBCACHE-644
Yes, I think so ...
Just be generic. Perhaps the FileCacheLoader could take an optional
property containing a list of OS-specific illegal characters for the
deployed platform, but then again if someone can specify this, they'd
know not to use these characters in the cache anyway.
I'd just stick with the generic illegal chars.
--
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
On 20 Oct 2006, at 10:48, Galder Zamarreno wrote:
> There's a hard limit in Windows by which a file path cannot be
> bigger than 255 characters, so that's an OS limit itself.
>
> Illegal characters vary depending on the OS, but there's some that
> apply to all OS.
>
> How do you wanna approach this? Shall we focus on limitations
> applying to all OS? I doubt we wanna be coding something that is
> dependant on the OS.
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
>
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 6 months
RE: Pojo-style config
by Brian Stansberry
Agreed. I wrote them as public static class Config, and forgot that for
the MC we'd have to use the '$' instead of the '.' that's usable in java
code. I did the -beans.xml files last night and didn't have the energy
to deal with it.
The 2 files thing does suck though.
________________________________
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Monday, October 23, 2006 5:17 AM
To: Brian Stansberry
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: Pojo-style config
Looks great!
One Q though - about the specific config impls for CacheLoaders,
etc., do we really want them as inner classes, e.g.,
org.jboss.cache.loader.FileCacheLoader$Config? From a Java standpoint,
this makes the most sense and is cleanest, can't say I like the String
representation of the inner class in XML though. :-) Just me being a
pedant, but isn't org.jboss.cache.loader.FileCacheLoaderConfig better,
sure this means 2 .java files per cache loader, but still?
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
On 23 Oct 2006, at 07:05, Brian Stansberry wrote:
FYI on where this sits:
1) I checked in all the stuff we were discussing last
week.
2) When I ran the testsuite, I didn't see regressions.
We'll see what
cc shows. The existing testsuite actually excercises
the new code
fairly well, because even when the old style Element and
Properties
configs are used, everything gets converted behind the
scenes to the new
pojos.
3) I created a stripped down AS head and created
-beans.xml files for
the 4 JBC configs that will go in AS 5 -- tomcat, ejb3
sfsb, ejb3
entity, and the HAPartition cache. They all deploy
cleanly, so that's a
simple test of the MC-style config. Don't know if they
do what they
should (e.g. does eviction actually happen), but I'm
pretty confident
about that. The -beans.xml files are attached so you
can see what they
look like.
There are details about that can be improved or at least
need
discussing, but I think it's pretty reasonable for an
alpha.
Cheers,
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
<tc6-cluster-beans.xml>
<cluster-beans.xml>
<ejb3-clustered-sfsbcache-beans.xml>
<ejb3-entity-cache-beans.xml>
17 years, 6 months
JBCACHE-89
by Manik Surtani
Hi,
This request is over 1.5 years old. Do we still see this as
something useful? As mentioned on the related forum thread, most use
cases seem to inject interceptors programmatically. How important is
it to be able to do this in XML?
Thoughts?
--
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, 6 months
Re: Pojo-style config
by Manik Surtani
Looks great!
One Q though - about the specific config impls for CacheLoaders,
etc., do we really want them as inner classes, e.g.,
org.jboss.cache.loader.FileCacheLoader$Config? From a Java
standpoint, this makes the most sense and is cleanest, can't say I
like the String representation of the inner class in XML
though. :-) Just me being a pedant, but isn't
org.jboss.cache.loader.FileCacheLoaderConfig better, sure this means
2 .java files per cache loader, but still?
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
On 23 Oct 2006, at 07:05, Brian Stansberry wrote:
> FYI on where this sits:
>
> 1) I checked in all the stuff we were discussing last week.
> 2) When I ran the testsuite, I didn't see regressions. We'll see what
> cc shows. The existing testsuite actually excercises the new code
> fairly well, because even when the old style Element and Properties
> configs are used, everything gets converted behind the scenes to
> the new
> pojos.
> 3) I created a stripped down AS head and created -beans.xml files for
> the 4 JBC configs that will go in AS 5 -- tomcat, ejb3 sfsb, ejb3
> entity, and the HAPartition cache. They all deploy cleanly, so
> that's a
> simple test of the MC-style config. Don't know if they do what they
> should (e.g. does eviction actually happen), but I'm pretty confident
> about that. The -beans.xml files are attached so you can see what
> they
> look like.
>
> There are details about that can be improved or at least need
> discussing, but I think it's pretty reasonable for an alpha.
>
> Cheers,
>
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> Ph: 510-396-3864
> skype: bstansberry
> <tc6-cluster-beans.xml>
> <cluster-beans.xml>
> <ejb3-clustered-sfsbcache-beans.xml>
> <ejb3-entity-cache-beans.xml>
17 years, 6 months
Releasing 1.4.0.SP2
by Manik Surtani
Hi all.
What is everyones' feel on releasing 1.4.0.SP2?
List of fixes:
** Bug
* [ JBCACHE-755 ] Potential bug when using (async) replication
queue and region based marshalling
* [ JBCACHE-756 ] Marshaller breaks with Strings of length
greater than 32767
* [ JBCACHE-760 ] TreeCacheListener in PojoCache gets
nodeModify events for invalid objects
* [ JBCACHE-763 ] Transaction rollback does not restore
contents of collection of cached collections
* [ JBCACHE-765 ] implementation of equals() in collections is
incorrect
* [ JBCACHE-767 ] Fail more silently when setting node versions
* [ JBCACHE-769 ] JDBCCacheLoader should not directly serialize
a map passed to put
* [ JBCACHE-776 ] EvictionPolicyProvider WARN message is noisy
and misleading
* [ JBCACHE-777 ] Creating a custom cache loader which
delegates to a standard cache loader, can generate misleading WARN
messages
* [ JBCACHE-785 ] InvocationContext and suspended transactions
* [ JBCACHE-792 ] ChainingCacheLoader method get(Fqn) -
unecessary call of the next CacheLoader
* [ JBCACHE-794 ] Eviction Queue hard limit can cause deadlocks
* [ JBCACHE-795 ] listIterator in a cached list throws
exception on empty list
* [ JBCACHE-799 ] Bug in RmiDelegatingCacheLoader class
* [ JBCACHE-808 ] Add serialVersionUID to ReplicationException
** Task
* [ JBCACHE-680 ] TreeCache demo gui to update view instanteously
* [ JBCACHE-761 ] Make connecting the channel and state
transfer an atomic part of startup
* [ JBCACHE-793 ] hibernate-recommended-config.xml incorrectly
specifies INVALIDATION_SYNC
* [ JBCACHE-798 ] Use ConcurrentHashMap for lock_table
* [ JBCACHE-800 ] Performance problem with TCP & RMI Cache loaders
** Patch
* [ JBCACHE-766 ] Don't return unnecessary values from
_replicate, avoiding need for marshalling
* [ JBCACHE-786 ] errors from "OK" putFailFast replications
Specifically, JBCACHE-766, JBCACHE-786, JBCACHE-792 and JBCACHE-800
for performance, JBCACHE-761 and JBCACHE-767 for correctness, and
some other nasty bugs like JBCACHE-755 have been resolved. Is there
any other reason to hold back this SP?
My original plan was to release 2.0.0.Alpha first, but the 2.0.0 tree
is waiting on some config issues being discussed in
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92931
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, 6 months
RE: http://jira.jboss.com/jira/browse/JBCACHE-644
by Galder Zamarreno
I'd stick to general rules.
Cheers,
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: 20 October 2006 11:57
To: Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: http://jira.jboss.com/jira/browse/JBCACHE-644
Yes, I think so ...
Just be generic. Perhaps the FileCacheLoader could take an optional
property containing a list of OS-specific illegal characters for the
deployed platform, but then again if someone can specify this, they'd
know not to use these characters in the cache anyway.
I'd just stick with the generic illegal chars.
--
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
On 20 Oct 2006, at 10:48, Galder Zamarreno wrote:
> There's a hard limit in Windows by which a file path cannot be
> bigger than 255 characters, so that's an OS limit itself.
>
> Illegal characters vary depending on the OS, but there's some that
> apply to all OS.
>
> How do you wanna approach this? Shall we focus on limitations
> applying to all OS? I doubt we wanna be coding something that is
> dependant on the OS.
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
>
17 years, 6 months
Re: http://jira.jboss.com/jira/browse/JBCACHE-644
by Manik Surtani
Yes, I think so ...
Just be generic. Perhaps the FileCacheLoader could take an optional
property containing a list of OS-specific illegal characters for the
deployed platform, but then again if someone can specify this, they'd
know not to use these characters in the cache anyway.
I'd just stick with the generic illegal chars.
--
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
On 20 Oct 2006, at 10:48, Galder Zamarreno wrote:
> There's a hard limit in Windows by which a file path cannot be
> bigger than 255 characters, so that's an OS limit itself.
>
> Illegal characters vary depending on the OS, but there's some that
> apply to all OS.
>
> How do you wanna approach this? Shall we focus on limitations
> applying to all OS? I doubt we wanna be coding something that is
> dependant on the OS.
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
>
17 years, 6 months