QUESTION: How to debug DataSourceLoader

[lpolvani]

I am working on a new SmartGWT-based application, the software will be packaged as a runnable jar containing jetty.

DataSourceLoader throws an exception, and I'd like to look at what is going on inside the class and how the resources are loaded in order to adjust the assembly of my application so the ds.xml files are in the right place.

Problem is that the sources are not provided even though we are enterprise customers.

I am currently stuck, how can I move forward with my application?



Stacktrace:

java.lang.ExceptionInInitializerError
    at com.isomorphic.datasource.DataSourceManager.getDataSource(DataSourceManager.java:168)
    at com.isomorphic.datasource.DataSourceManager.getDataSource(DataSourceManager.java:121)
    at com.isomorphic.servlet.DataSourceLoader.processRequest(DataSourceLoader.java:186)
    at com.isomorphic.servlet.DataSourceLoader.doGet(DataSourceLoader.java:110)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:645)
    at com.isomorphic.servlet.BaseServlet.service(BaseServlet.java:176)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:755)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:547)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1297)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1212)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
    at org.eclipse.jetty.server.Server.handle(Server.java:500)
    at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
    at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:270)
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
    at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
    at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:388)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
    at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.NullPointerException
    at com.isomorphic.datasource.DataSource.<clinit>(DataSource.java:1173)
    ... 33 more
=== 2020-01-20 13:05:36,128 [7-28] ERROR DataSourceLoader - BaseServlet Global Exception
javax.servlet.ServletException: DataSource 'batchUpload' failed to load due to an exception on the server:
null
See the server-side log for additional details.
    at com.isomorphic.servlet.DataSourceLoader.processRequest(DataSourceLoader.java:295)
    at com.isomorphic.servlet.DataSourceLoader.doGet(DataSourceLoader.java:110)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:645)
    at com.isomorphic.servlet.BaseServlet.service(BaseServlet.java:176)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:755)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:547)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1297)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1212)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
    at org.eclipse.jetty.server.Server.handle(Server.java:500)
    at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
    at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:270)
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
    at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
    at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:388)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
    at java.base/java.lang.Thread.run(Thread.java:834)

[Isomorphic]

It looks like you removed the initialization servlet from web.xml. If your environment doesn't have a web.xml, you can perform initialization manually: see Server Init.

Note that, while source code access wasn't actually the issue here, enterprise licenses can potentially include source escrow or access - your organization just didn't bring it up.

[lpolvani]

I have the same issue on a .war version of the application running on a classic jetty.

Access to source would be greatly beneficial in a situation like the one I am finding myself right now. How do I go about requesting it, and is there any additional cost associated to that?

[Isomorphic]

Regardless of whether you're running in a .war environment or not, the same initialization needs to happen, and the docs we already link to tell you how to do it in both situations.

If you're interested in adding source code access, start from the contact form. However, consider that in this situation, you would have immediately found the answer by just searching the docs for "initialization" or similar. Firing up the source code would probably have led to a long investigation of why the log system isn't set up.. waste of time. We see that kind of "wild goose chase" go on with people with the client source code all the time.

Source code debugging is the only choice with some OSS projects, but with a well-documented product like ours, source code debugging should be a last resort, and you do not appear to have hit a situation where it would have been the best path forward (which is exceedingly rare).

[lpolvani]

The issue was that some configurations were in the framework.properties file, instead of the server.properties.
Once moved from one file to the other everything started working as expected.

I do read the docs (most of the times)

[Isomorphic]

FYI framework.properties should never be modified, and settings documented only within that file (and not anywhere else within the docs) are not valid settings for your use.

That's why it's wrapped up in a .jar file and never referred to in the docs.

[lpolvani]

I have learned the hard way :|

Shall this be a lesson to the future generations!

(just discovered forum doesn't support emoji ~sad face~)