Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question

Gigaspace 7.1.1 and JBoss 5.1.0 connection issues


I am having some major problems when I am trying to establish connection between client (EJB deployed on JBoss 5.1.0 GA, please see attachment "CacheAdapter.java") and server (Gigaspace 7.1.1).

Client environment (machine1): Windows XP Java 1.6+ (JDK)

Server environment(machine2): Windows XP Java 1.6+ (JDK)

I am having some example space (name="space"), connection is done by invoking:

IJSpace space = new UrlSpaceConfigurer("jini:////space").space(); GigaSpace gigaSpace = new GigaSpaceConfigurer(space).gigaSpace();

I have two scenarios:

Scenario1: I have gigaspace jars in my sample EAR (gs-openspaces-7.1.1.jar, gs-runtime-7.1.1.jar). This EAR is deployed on JBoss 5.1.0 GA. When I am trying to connect to space, I am having error (please see attachment "blad gs.txt")

Scenario2: I've copied gigaspace jars (gs-openspaces-7.1.1.jar, gs-runtime-7.1.1.jar) into /server/all/lib catalog (there are NO gigaspace jars embedded in EAR archive!!) I am having error like: (please see attachments: "blad gs2.txt", "blad gs3.txt", "blad gs4.txt") In most cases it's "blad gs4.txt" error.

I have done some fixes explained on Your WIKI ( http://www.gigaspaces.com/wiki/displa... ) but it does NOT help at all...

P.S When I am connecting to space using some simple client (no EJB and JBoss, please see attachment "CacheAdapter.java -> class Main") everything is OK h4. Attachments

[blad gs.txt|/upfiles/137597054953728.txt]

[blad gs2.txt|/upfiles/13759705494625228.txt]

[blad gs3.txt|/upfiles/13759705492654528.txt]

[blad gs4.txt|/upfiles/13759705494067928.txt]


{quote}This thread was imported from the previous forum. For your reference, the original is [available here|http://forum.openspaces.org/thread.jspa?threadID=3487]{quote}

asked 2010-08-12 06:13:34 -0500

sonic gravatar image

updated 2013-08-08 09:52:00 -0500

jaissefsfex gravatar image
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

Hi Adam, this issue is already fixed in the upcoming service pack 7.1.2 and the early access program of 8.0

Thanks Eitan

answered 2010-08-18 03:50:49 -0500

eitany gravatar image
edit flag offensive delete link more


I've managed to solve that problem...

It appeard that JBoss is using his own LogManager class implementation which reside in JAR "jboss-logmanager.jar" Class name:org.jboss.logmanager.LogManager

After the decompilation I saw that it uses LoggerNode class to get or set loggers to manager (it uses LoggerInstance class implementation for it's loggers). Loggers are kept in variable WeakReference<loggerinstance>

This is the code of JBoss LogManager: LoggerNode getOrCreate(String name) { if ((name == null) || (name.length() == 0)) { return this; } int i = name.indexOf('.'); String nextName = (i == -1) ? name : name.substring(0, i); LoggerNode nextNode = (LoggerNode)this.children.get(nextName); if (nextNode == null) { nextNode = new LoggerNode(this.context, this, nextName); LoggerNode appearingNode = (LoggerNode)this.children.putIfAbsent(nextName, nextNode); if (appearingNode != null) { nextNode = appearingNode; } } if (i == -1) { return nextNode; } return nextNode.getOrCreate(name.substring(i + 1)); }

Then I decompiled class com.gigaspaces.logger.TraceableLogger which extends java.util.logging.Logger; The issue was that in line 103 in method public static TraceableLogger getLogger(String name) there was ClassCastException, because LogManager that is using does not return NULL when the searched logger key ("com.gigaspaces.lrmi.classloading" - it is done in com.gigaspaces.lrmi.classloading.DefaultClassProvider in line 25) is not found!!! In fact is does return new LoggerInstance object which is not TraceableLogger!!!

I've managed to change code in TraceableLogger class to:

public static TraceableLogger getLogger(String name) { synchronized (Logger.class) { String traceableLoggerName = name + ".trace"; TraceableLogger result = null; if (result == null) { Logger logger = Logger.getLogger(name); result = new TraceableLogger(traceableLoggerName, logger, getAssociatedLoggers(name)); } return result; } }

...and everyting is OK :)

In summary:

Using JBoss as application container You can not relay on fact, that LogManager will return NULL when logger is not found. JBoss LogManager implementation (which is set in org.jboss.Main class using environmental variable "java.util.logging.manager", line 128) will always return new LoggerInstance object.

References: 1. http://download.oracle.com/javase/1.4... 2. http://download.oracle.com/javase/1.4...

P.S When using raw LogManager implementation from JDK we are sure that invoking

public Logger getLogger(String name) methos will return NULL if not logger is found


getLogger public Logger getLogger(String name)

Method to find a named logger.

Note that since untrusted code may create loggers with arbitrary names this method should not be relied on to find Loggers for security sensitive logging.

    name - name of the logger 
    matching logger or null if none is found

answered 2010-08-18 01:37:42 -0500

sonic gravatar image
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2010-08-12 06:13:34 -0500

Seen: 109 times

Last updated: Aug 18 '10