Xpages runtime interpreting java package name as String object

Question

From all the weirdness in our current Xpages project this one currently hits the ceiling:

we have created a few java beans in our current project. Inside Domino Designer they all are stored below Code >> Java, so that it is clear that they are automatically part of the project's classpath. All our beans belong to a package structure de.edcom.* (that's what we have been using forever without any problems). The objects are mostly called from SSJS using the full package names (the aren't registered as managed beans for various reasons) as in

var o = de.edcom.myObject.someMethod();

In none of my previous Xpages projects this caused any problems, it just worked. In the current project, however the XSP runtime all of a sudden started to interpret the package name as a String object giving us this runtime error:

Unknown member 'edcom' in Java class 'java.lang.String'

the ssjs code line in question is looking like this:

return de.edcom.TOC.buildTOC();

We absolutely don't have any clue as to what could be causing this, why only in this project, and why it sometimes IS working, but mostly isn't.

There's one difference between this projects and others before, and that is locallization: users can switch between "english" and "german" locale, and of course we are using codes like

context.setLocaleString("de")

and of course we are having several javascript code fragments looking for local settings as in

if(context.getLocalString()==="de"){...

This morning we in fact have renamed / refactored all java beans to different package names (com.edcom.*), and since then the error hasn't appeared (fingers crossed!).

But then again I think this is just too stupid, there can't really be a connection, or can it?

EDIT:

I tried using importPackage(), in conjunction with an xe:objectData datasource (as recommended by Adrian and Paul in their answers), but I'm still receiving that "unknown member 'edcom' in Java class 'java.lang,String'" message, now only at a different position in the code at my line saying importPackage(de.edcom).

I'll be switching back to the "com.edcom" package and keep looking for a better solution; unfortunately searching for the string "de" inside the entire code yields close to 12.000 matches; now way to find the real reason for this in that haystack

EDIT #2:

looks like we finally found the dreaded "de" variable: it was well hidden in a computed customControl property; I don't have a clue why all the File Searches that I performed over the last few days couldn't find this one.

Anyways it is very good to know that we have to be even more careful when naming our ssjs variables; I never would have thought that a ssjs variable name could ever interfere with TLD parts in Java packages; we probably will make it an internal policy that our variables have to must be named "vDe", "vCom", "vIt" etc. instead of just short lowercase letters...

Don't forget to explain the meaning of such internal policy. Otherways you could get into trouble with variable 'vA' and packages from Vatican :-) — Frantisek Kossuth

Adrian Adrian · Accepted Answer · 2016-06-10T12:44:51

Probably you used a variable de (which is a String) in an other SSJS script that run before that one faces the problem.

I've seen similar issues that a variable that is not explicitly declared in an script block can inherit values from another script block.

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
    <xp:this.beforeRenderResponse><![CDATA[#{javascript:
        var ex1 = "Hello World";
        var ex2 = "Bye bye"}]]>
    </xp:this.beforeRenderResponse>
    <xp:this.afterRenderResponse><![CDATA[#{javascript:
        print("value ex1: " + ex1);
        print("value ex2: " + ex2);}]]>
    </xp:this.afterRenderResponse>
</xp:view>

results in:

[1CA8:000C-4354] 10.06.2016 14:33:01   HTTP JVM: value ex1: Hello World
[1CA8:000C-4354] 10.06.2016 14:33:01   HTTP JVM: value ex2: Bye bye

So you should use the importPackage() function to import the references to your java classes or much better, use managed beans or dataContexts.

Xpages runtime interpreting java package name as String object

2 Answers