CFMX for J2EE Session variable case sensitivity

15 Aufrufe
Direkt zur ersten ungelesenen Nachricht

Wes R.

11.04.2003, 10:12:5511.04.03
We are having problems with case sensitivity in Java when using the
cold fusion session variable. We do have J2EE session variable support
turned on in the admin.

We have been using CFMX Server for a while and have had no problems
with case sensitivity in java. It appears as though nearly any case
works when looking things up in the cold fusion session from java. I
suspect the map implementation used does something to make the lookups

So, now we are moving to CFMX for J2EE, and things have started to
break. The cold fusion session lookups now have to be in lowercase to
return any values. If you ask the cold fusion session (which is a Map
on the java side) for a value by a mixed-case key, null is always
returned; the key has to be lowercased before anything can be
returned. This seems odd since it is still CFMX, but the behavior has
changed and doesn't seem to be documented anywhere that I can find.

I did some checking, I called "session.getClass().getName()" (where
"session" has been retrieved as a Map variable already) and received
different values for CFMX Server and CFMX for J2EE. CFMX Server
returns coldfusion.runtime.J2eeSessionScope and CFMX for J2EE returned
coldfusion.runtime.J2eeSessionScopeStub. Logic tells me that the
"stub" probably represents a wrapper and that hopefully
coldfusion.runtime.J2eeSessionScope is what is being wrapped, but that
isn't clearly true. Is there a way I can effect where this "stub"

Am I missing something? Is there something I can do to get the regular
"CFMX Server" behavior on "CFMX for J2EE"? Is there a setting I need
to change?

- Wes


15.04.2003, 15:55:3815.04.03

I have noticed that same issue and am also having problems using the
"put()" method of the J2EESessionScopeStub. When invoking put() a
UnsupportedOperation is being thrown. I am not seeing this issue
pre-Updater3. In an eariler version of CFMX for J2ee the returned
object is J2EESessionScope and not the Stub.

Did you find a solution to your problem?

Thanks (Wes R.) wrote in message news:<>...

Wes R.

16.04.2003, 11:32:0916.04.03
I'm pretty sure I have the pre-updator3 installation but could be
wrong. However, I have figured out why things have changed.

- CFMX Server used to put the real J2eeSessionScope class into the
HttpSession, which was later retrieved by java code. This
implementation used an AbstractMap as its basis, and hence is
essentially a Set and Map.get iterates over the Map.Entry objects in
the set until Map.Entry.getKey() returns a match. J2eeSessionScope
overrides "Map.get()" to attempt a base call with the passed in key,
and if that fails calls "toLowerCase" on the key and tries again.
Essentially all java accesses into this "Map" requires 2 real
Map.get() calls since all values are stored in the CF Session as

- CFMX for J2EE does not put the real J2eeSessionScope class into the
HttpSession, it puts a J2eeSessionScopeStub class in there instead.
The Stub class is initialized with the J2eeSessionScope, and
J2eeSessionScopeStub extends java.util.AbstractMap and only implements
"Map.entrySet()" as returning J2eeSessionScope.entrySet(); well,
more/less, it actually passes J2eeSessionScope.entrySet() into a new
implementation of Set that acts like a wrapper to make it an
unmodifiable set so that this map is unmodifiable. So, when someone
essentially calls "J2eeSessionScopeStub.get(key)" they are calling
AbstractMap.get() which only uses the entrySet() from
J2eeSessionScope; the important part is that a failure never from
AbstractMap.get(originalKey) results in calling "toLowerCase" on the
originalKey and recalling AbstractMap.get(lowerCasedKey).

My solution to this problem is writing a wrapper class that
re-implements "get()" and "put()", these two methods call
getJ2eeSessionScope() on the J2eeSessionScopeStub class and then call
its "get() and put()" methods; otherwise I just call the Map methods
off of J2eeSessionScopeStub.

Another solution I found is to remove the "app name" from you Cold
Fusion application, this forces Cold Fusion to put all values into the
real HttpSession (actually implemented by your j2ee app server). This
session is truely case-sensitive, so all gets/puts must now be case

- Wes (Kris) wrote in message news:<>...

Allen antworten
Dem Autor antworten
0 neue Nachrichten