Who else has encountered this problem? Since it affects all non-ASCII UTF-8
characters, it should be basically everybody who's not using English in their
webservice app ...
Note my patch for 1.2.1GA (comes with JBoss 4.2.0GA) in the post above.
View the original post :
http://www.jboss.com/ind
I've been debugging for hours on this one and eventually tracked the problem
down, which I posted on the JIRA:
http://jira.jboss.org/jira/browse/JBWS-1716
A workaround UTF-8 fix can be downloaded there for version 1.2.1GA of JBossWS.
Setting the system property file.encoding may not work when y
Sorry for my late reply, been too busy yesterday.
anonymous wrote : So I am missing something. You mean to tell me that
TreeCache.remove() *fails* if the node does not exist even when you explicitly
specify "fail silently"? I needed the "protection check" in
OptimisitcTreeCache.remove() because
Exceptions all over the place, must be my lucky day!;) (today is the
13th after all...)
Fortunately for one part it seems a simple beauty fixup, I replaced in your
latest OptimisticTreeCache:
| public void writeLoad(Object key, Object value, Object currentVersion) {
|
Just checked out the latest Hibernate source from
http://anonhibernate.labs.jboss.com/trunk/Hibernate3, but I can't find a method
testNoVersioningProvided() in there ... where should this be included?
Anyway, my guess is still remains: TreeCache doesn't work fine if you mix
non-versioning and
More news:
It seems it is happening with the query cache enabled, since at the location of
the exception the toString() of workspaceNode is:
WorkNode fqn=/org/hibernate/cache/StandardQueryCache dirty ver=null
When I disable the query cache, I get another similar exception:
Caused by: java.lang
Well, no luck. I replaced OptimisticTreeCache with the latest version from CVS,
which, as I understood from reading HHH-1796 at least, should fix the problem
using a new Fqn.
I've been debugging and browsing code for hours now trying to figure out what
is going on and I think problem is twofold
I'll dig into this further tomorrow.
But just by quickly looking at the test case you mention, and according to what
I saw TreeCache doing today, that test may pass since it only seems to deal
with non-versioning stuff within a transaction. But that might not be the case
when running for real,
Clarification to my previous post:
As for point 2, yes, I confirm, source==null happened in a case where a cached
collection was loading (or being put into; don't remember) from its collection
cache.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957164#3957
