Great catch.
So it's this change that crept in jboss-common-core 2.2.8.GA by Ales, without even a
linked
JIRA issue:
To be honest, I wouldn't have thought that changing a protected field to a supertype
would
present compatibility issues.
I've made a jira for Ron, since we are expecting a remoting 2.2.4.SP2, anyway:
https://jira.jboss.org/jira/browse/JBREM-1032
Or the other option would be to rollback Ales' change, but then something else will
break.
Index:
X:/cvs/jboss-public/common/common-core/src/main/java/org/jboss/util/LRUCachePolicy.java
===================================================================
---
X:/cvs/jboss-public/common/common-core/src/main/java/org/jboss/util/LRUCachePolicy.java
(revision 2882)
+++
X:/cvs/jboss-public/common/common-core/src/main/java/org/jboss/util/LRUCachePolicy.java
(revision 2883)
@@ -22,6 +22,7 @@
package org.jboss.util;
import java.util.HashMap;
+import java.util.Map;
/**
* Implementation of a Least Recently Used cache policy.
@@ -39,7 +40,7 @@
/**
* The map holding the cached objects
*/
- protected HashMap m_map;
+ protected Map m_map;
/**
* The linked list used to implement the LRU algorithm
*/
@@ -79,6 +80,16 @@
m_maxCapacity = max;
}
+ /**
+ * Create map holding entries.
+ *
+ * @return the map
+ */
+ protected Map createMap()
+ {
+ return new HashMap();
+ }
+
// Public --------------------------------------------------------
// Service implementation ----------------------------------------------
@@ -90,7 +101,7 @@
*/
public void create()
{
- m_map = new HashMap();
+ m_map = createMap();
m_list = createList();
m_list.m_maxCapacity = m_maxCapacity;
m_list.m_minCapacity = m_minCapacity;
Adrian Brock wrote:
On Thu, 2008-09-04 at 16:28 +0200, Carlo de Wolf wrote:
> On Thu, 2008-09-04 at 15:39 +0200, Adrian Brock wrote:
>> 15:15:34,302 WARN [StartStopLifecycleAction] Error during stop for
>> org.jboss.ejb3.RemotingConnector
>> java.lang.NoSuchFieldError: m_map
>> at
org.jboss.remoting.transport.socket.LRUPool.getContents(LRUPool.java:81)
>> at
org.jboss.remoting.transport.socket.SocketServerInvoker.cleanup(SocketServerInvoker.java:437)
>> at
org.jboss.remoting.transport.socket.SocketServerInvoker.stop(SocketServerInvoker.java:404)
>> at org.jboss.remoting.transport.Connector.stop(Connector.java:1111)
> At a glance LRUPool extends LRUCachePolicy which has a protected m_map
> field. So for the moment I would say: Uh?
>
I've tried
rm -rf ~/.m2/repository/org/jboss/remoting/
rm -rf ~/.m2/repository/org/jboss/ejb3/
and did a clean build (including clobbering thirdparty).
Still seeing the error.
Disassembling LRUCachePolicy, I can see the
protected field m_map
$ javap -c -classpath jboss-common-core.jar
org.jboss.util.LRUCachePolicy
Compiled from "LRUCachePolicy.java"
public class org.jboss.util.LRUCachePolicy extends java.lang.Object
implements org.jboss.util.CachePolicy{
protected java.util.Map m_map;
Disassembing LRUPool, it is expecting a HashMap not a Map
so this has obviously changed at some point.
$ javap -c -classpath jboss-remoting.jar
org.jboss.remoting.transport.socket.LRUPool
Compiled from "LRUPool.java"
public class org.jboss.remoting.transport.socket.LRUPool extends
org.jboss.util.LRUCachePolicy{
...
public java.util.Set getContents();
Code:
0: aload_0
1: getfield #12; //Field m_map:Ljava/util/HashMap;
4: invokevirtual #13; //Method
java/util/HashMap.keySet:()Ljava/util/Set;
7: areturn
So JBoss Remoting needs recompiling over the latest
jboss-common-core
I don't know whether this fixes the other problems?
> Carlo
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-development