ServerObject NPE

[atomatom]

I'm getting this stack trace and I've really no idea what is causing it to crash. The logs give me nothing to go on.

I now need to rollback my code to try and figure out what I changed that caused this. I'm an ass because I had a ton of changes since the last commit. I'm really hating not seeing what is going on in the server.

The only reason I'm posting this here is that perhaps you can add some more NPE checks and log messages in the server object code.

=== 2011-02-13 22:43:07,417 [22-2] WARN  RequestContext - dsRequest.execute() failed: 
java.lang.NullPointerException
	at com.isomorphic.rpc.ServerObject.<init>(ServerObject.java:88)
	at com.isomorphic.rpc.ServerObject.<init>(ServerObject.java:70)
	at com.isomorphic.datasource.DataSourceDMI.execute(DataSourceDMI.java:416)
	at com.isomorphic.datasource.DataSourceDMI.execute(DataSourceDMI.java:64)
	at com.isomorphic.datasource.DSRequest.execute(DSRequest.java:1454)
	at com.isomorphic.servlet.IDACall.handleDSRequest(IDACall.java:173)
	at com.isomorphic.servlet.IDACall.processRPCTransaction(IDACall.java:130)
	at com.isomorphic.servlet.IDACall.processRequest(IDACall.java:95)
	at com.isomorphic.servlet.IDACall.doPost(IDACall.java:54)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
	at com.isomorphic.servlet.BaseServlet.service(BaseServlet.java:152)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

Here's a peek from the Variables window in Eclipse

serverObject  (id=118)	
	context	RequestContext  (id=119)	
		cachingEnabled	true	
		clientContextHeaderSent	false	
		compression	null	
		contentType	null	
		jsTrans	JSTranslater  (id=124)	
		log	Logger  (id=126)	
		out	null	
		pathInfo	null	
		request	ISCHttpServletRequest  (id=128)	
		requestPath	"/myproject/sc/IDACall" (id=130)	
		response	ServeBlobFilter$ResponseWrapper  (id=132)	
		servletContext	AppEngineWebAppContext$AppEngineServletContext  (id=137)	
		servletPath	"/myproject/sc/IDACall" (id=139)	
		session	null	
	contextString	"Default serverObject for DataSource userAccount_DataSource" (id=121)	
	factoryOptionalArgs	null	
	lookupStyle	null	
	method	null	
	serverObjectClass	null	
	serverObjectConfig	null	
	serverObjectInstance	null

[atomatom]

I found it. *sigh* I think it was something to do with JXPath blowing up because I had not set the flag:

-Dorg.apache.commons.jxpath.JXPathContextFactory=org.apache.commons.jxpath.ri.JXPathContextFactoryReferenceImpl

I already reported this as a problem when running on GAE. If you have tried to address the problem, I suggest the fix needs more attention. If not, perhaps have the SmartGWTEE server code check to see if this property is set and assign this value if it is unset. Then JXPath will work on GAE.

[atomatom]

Yeah, if you add the following to IDACall it fixes the JXPath GAE problem. If Isomorphic don't fix this, you can always extend your own IDACall and add this.

	static {
		String key = "org.apache.commons.jxpath.JXPathContextFactory";
		String value = System.getProperty(key);
		if (value==null)
			System.setProperty(key, "org.apache.commons.jxpath.ri.JXPathContextFactoryReferenceImpl");
	}

This was previously reported here: http://forums.smartclient.com/showth...ghlight=JXpath

[Isomorphic]

It does not seem to be necessary for anyone else to set this (and it's not needed for the Showcase). What's special about your config?

[atomatom]

See the thread I linked to. Anyone using JXPath and GAE will encounter this.

[atomatom]

I mention it only for other people. It's fixed in my code.

[Isomorphic]

Do you have an explanation for why this makes JXPath work on GAE? Does it remove a dependency on GAE-forbidden libraries? Is it a setting that makes sense outside of GAE too?

[atomatom]

The last time around it was throwing an access violation. This time, I didn't even get an access violation, so I'm not sure.

I'm not sure if anyone not using GAE would gain from that fix, and worse, if you want to set the JXPathContextFactory using a file, then that will be broken. The better fix to this would be wrapping the JXPath reads in something stronger than an IOException.

[atomatom]

One fix here that would benefit everyone is more defensive coding in ServerObject. I hit this error again because it was unable to construct a DMI object (different reason, exact same symptom).

The ideal would be a log warning stating which part of ServerObject had a problem. At the moment, it seems this code is written so that it presumes everything works.

[Isomorphic]

We catch lots of cases (essentially every case that anyone has ever previously reported). Can you show the misconfiguration you used where you did not receive a clear error?

[atomatom]

To reproduce the last one I got, make a private constructor for a DMI datasource class. Yes, stupid error, but no hints on what went wrong, and sure /facepalm.

[Isomorphic]

We'd love to add such a check, but can you clarify, are you talking about serverConstructor, serverObject, both? lookupStyle "new", "spring", something else?

[atomatom]

This is the kind of config

DataSource ID="userAccount_DataSource" serverType="generic"
	schemaBean=".........">
	<operationBindings>
		<operationBinding operationType="fetch">
			<serverObject className="com.project.server.Service"
				targetXPath="userService" methodName="getCurrentUserAccount" />
		</operationBinding>

...

My guess it's reflection code that presumed it had a good method and then calls it and blows up?...

at com.isomorphic.rpc.ServerObject.<init>(ServerObject.java:88)

[Isomorphic]

So really, this is exactly the same scenario (GAE + JXPath) - the single case you've reported before.

We'd be happy to apply your suggested workaround, but we won't generally apply something unless we understand how it works - it would be great if you could explain what exactly you believe your change works around.

[atomatom]

Please reread the last messages posted. We already discussed this.

I think the correct action is to catch the NPE and put out a warning message.