Thus, we decided to embed a SQLite database in the app. This worked fine as long as I was locally testing the application. However, when deploying to a production Tomcat instance I started getting these exceptions:

java.sql.SQLException: opening db: 'restfulepcis.db': Permission denied
at org.sqlite.Conn. init(Conn.java:117)
at org.sqlite.Conn. init(Conn.java:49)
at org.sqlite.JDBC.connect(JDBC.java:86)

The reason is pretty clear, on the production server I did not have permission to write to the Tomcat working directory.

I was left with two solutions:
1) have the directory where the database has to be created as a config parameter
2) find a directory that’s universally accessible from an app in an app server.
Since 1) involved user-configuration it was not an option.

There is actually a folder to which any Web app can write, the folder where the app is deployed (or at least my knowledge). The location of this folder can be found by calling:


ServletContext context = servletContext.getRealPath("/")


from a servlet. Since my app is a JAX-RS (RESTful) application I can obtain it by CDI (Contexts and Dependency Injection):

@Context
ServletContext servletContext;

/**
* Returns a representation of the EPCIS REST Adapter home resource according to the requested mime type
*
* @param context
* @return an instance of javax.ws.rs.core.Resource
*/
@GET
public Resource getRESTfulEPCIS(@Context UriInfo context) {
System.setProperty("sqlite.system.home", servletContext.getRealPath("/"));
RESTfulEPCISBusinessLogic logic = new RESTfulEPCISBusinessLogic();
return logic.getRESTfulEPCIS(context);
}


I then load the sqlite.system.home from my database manager class (which is not a Servlet) and use it as path in my database connection URI:


...
String sqliteHome = System.getProperty("sqlite.system.home");
...
private Connection getConnection() {
Connection connection = null;
try {
Class.forName(DRIVER);
connection = DriverManager.getConnection("jdbc:sqlite:" + sqliteHome + DB_NAME + ".db");
...


Note that for Apache Derby, you can make it even easier by simply setting the derby.system.home in the servlet class. Then, you do not need to read it manually from your database manager class as it is read automatically when loading the driver:

System.setProperty("derby.system.home", servletContext.getRealPath("/"));


HttpTransportSE androidHttpTransport = new HttpTransportSE(URL);
androidHttpTransport.debug = true;


and get a hold on the raw response from the service using:

String result = androidHttpTransport.responseDump;

I was retrieving a JSON object in the GWT (Google Web Toolkit) and putting its Java representation in a HashMap. The only problem is that I could never find it again by referring to its key which I also extracted from JSON object. Here is why:

currentCons.get("URI").isString().toString()

Is actually not returning the String representation of a JSONString object but the quoted representation of that String: e.g. “key” and not key. It was in the API but it took me a while to figure it out…

The solution is:

currentCons.get("URI").isString().stringValue();

Which gets what I wanted, i.e. the String representation without the quotes.

How not to use iterators:


while(views.iterator().hasNext()) {
View currentView = (View) views.iterator.next();
currentView.update();
}


Bing that basically crashed my Firefox (this is part of a GWT app) when running it as well as my Netbeans / GWT debugger. Notice that Firefox was so good to tell me that apparently the script I was running in a weird manner.

And it was indeed in an endless loop as you can guess: invoking the iterator() method returns a new Iterator object every time (which it is supposed to do, I’m the dumb one in that story). Thus, I was basically getting the same “next()” object every time and hasNext() was thus always true

Anyway that fixes it:


Iterator viewsIt = views.iterator();
while(viewsIt.hasNext()) {
View currentView = (View) viewsIt.next();
currentView.update();
}


Ok that was a trivial one, but actually so trivial that I just felt like shaming me a little more and publishing it here

A few remarks thought, when trying to integrate the awesome OFCGWT chart library in my application I had to face two problems.

First of all the GWT4NB tutorial on Netbeans.org says you should use the 1.4 java compiler because the GWT does not support Java EE 1.5. Well I’m pretty sure the GWT does not offer support for EJBs and the like (because it has nothing to do with the backend, it’s a UI toolkit!) but it does support Java SE 6 constructs. Thus, if you do select Java EE 1.4 when first creating your project be sure to then change the source/binary version to 1.6 in the project properties.

As an example I could not compile the OFCGWT example without it.

The next thing to be aware of is that the GWT4NB module does not fully comply with the URL assigned to your application by the GWT, when a typical application URL would look like (in GWT):

http://localhost:8080/UWTest/org.test.Main

Netbeans with the GWT4NB plugin exposes it as:

http://localhost:8080/UWTest/

That basically means the entry point .html file is not located in org.test.Main in the GWT4NB version but rather directly at the root context of your app.

A consequence of this is that GWT modules assuming that the compiled javascript will be loaded by a page at org.test.Main will look for files in the wrong place. Namely, in the case of OFCGWT, the .js references .swf files which it expects to be located in the same folder as where it has been loaded from.

Anyway, I found two workarounds for that matter:

1:

We need to override the post-compile target in our build.xml which is guaranteed
never to be re-generated by the IDE:

<target name="-post-compile">
<property name="gwt.compiler.output.style" value="OBFUSCATED"/>
<property name="gwt.compiler.logLevel" value="WARN"/>
<java classpath="${javac.classpath}:${src.dir}"
failonerror="true"
classname="com.google.gwt.dev.GWTCompiler" fork="true"
maxmemory="512m">
<arg value="-out"/>
<arg path="${build.web.dir}/"/>
<arg value="-style"/>
<arg value="${gwt.compiler.output.style}"/>
<arg value="-logLevel"/>
<arg value="${gwt.compiler.logLevel}"/>
<arg value="${gwt.module}"/>
</java>
<property name="gwt.output.dir" value="${gwt.module}"/>
<move todir="${build.web.dir}/${gwt.output.dir}">
<fileset dir="${build.web.dir}/${gwt.module}"/>
<fileset dir="${build.web.dir}">
<include name="**/*.html"/>
<include name="**/*.css"/>
</fileset>
</move>
</target>

This will actually move all the .css and .html files of your web folder to the correct output dir. You then need to be sure that the correct .js file is loaded in your welcomeGWT.html file. That is: you need to remove the org.test.Main/ part.

When deploying Apache might not really be happy anymore since there is no html file at the root of your application anymore however, you just need to call it explicitely like:
http://localhost:8080/UWTest/org.test.Main/welcomeGWT.html and that
should do the trick! BUT –>

2:

BUT, that said, there is a much simpler way of getting rid of that problem: In gwt.properties change the line gwt.output.dir to gwt.output.dir=/
This will deploy the GWT files (all of them, including the .html and the ofcgwt .swf files) at the root http://localhost:8080/UWTest/ which then means that the .js, .swf and .html files are all located in the same folder and thus all on the same path.

This will actually move all the .css and .html files of your web folder to the correct output dir. You then need to be sure that the correct .js file is loaded in your welcomeGWT.html file. That is: you need to remove the org.test.Main/ part.