Category Archives: NetBeans

PlayerManager – Qualifying Round (Application Server)

Tomcat, TomEE or GlassFish? I like the simple life. But getting to the simple always seems to take so long. And with enterprise java sometimes even longer than that… I was experimenting with Java EE 6 RESTful Web Services and Entity beans generated with NetBeans when I thought it would be good to test how easy it would be run this app on Tomcat, TomEE and GlassFish. Well, with Tomcat I would have to build my own Tomcat based Java EE 6 server (again). To be honest I couldn’t be bothered and the guys at TomEE had already done that. So it was between GlassFish, the reference EE server, and TomEE.

Running one of the sample NetBean apps, Customer Database on Spring, on GlassFish is as easy as you might expect, but porting that to TomEE was more difficult than I expected… With TomEE there is a choice to be made from the 3 versions currently available; standard, web services and enterprise options (not the official names). I really only wanted the web service version (Java EE 6 Certified JAX-RS) for its RESTful web services but as I wasn’t sure if that contained everything that I would need I went with the enterprise version (TomEE 1.5.1 Plus) which has the most supported APIs.

With the TomEE version choice made I started googling for what seemed like days for documentation, help, examples, anything that would help me to configure  an app on TomEE, an app that took minutes to write in NetBeans and run on GlassFish. Finally stumbling across this I was able to piece together what was required to get things working on TomEE.

A resources.xml file needs to be in the WEB-INF/classes/META-INF folder to define a data source, e.g. this example defines a Derby data source.

<!--
A TomEE 1.5 Resource definition file used to configure application specific resources.
Location: <webapp>/WEB-INF/classes/META-INF/resources.xml
-->
<resources>
<Resource id="jdbc/sample" type="DataSource">
JdbcDriver org.apache.derby.jdbc.ClientDriver
JdbcUrl jdbc:derby://localhost:1527/sample
UserName app
Password app
JtaManaged true
</Resource>
</resources>
view raw resources.xml hosted with ❤ by GitHub

I also had to update the persistence.xml file to use the EclipseLink JPA provider as I just couldn’t get the default TomEE JPA provider (OpenJPA) to work…

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="CustomerDBSpringPU" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>jdbc/sample</jta-data-source>
<class>customerdb.Customer</class>
<class>customerdb.DiscountCode</class>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<properties/>
</persistence-unit>
</persistence>
view raw persistence.xml hosted with ❤ by GitHub

TomEE 1.5.1 doesn’t like Spring injecting an EntityManager, as documented here. So I removed that from the Spring config, instead relying on the GlassFish managed entity manager. No big deal there, and not a big deal either to remove the lines of code that were closing the entity manager, as that isn’t allowed with a container manager entity manager.

All in all it wasn’t too hard to prove that a simple Java EE 6 app can be ported from GlassFish to TomEE.

Advertisement

Development Environment II

I’ve been rethinking using Eclipse as my Java & HTML5/JavaScript IDE of choice since discovering that NetBeans 7.3 supports both, and with integrated Chrome JavaScript debugging and Twitter Bootstrap, BackBone.js and Jersey RESTful WebServices support it seems too good to be true. But after getting a couple of building a couple of simple apps with NetBeans it could be time to wave goodbye to Eclipse plugin hell and say hello to NetBeans simplicity.

One thing I couldn’t figure out was why the CustomerDBSpring sample app and the CustomerRestfulService  app were producing different JSON. It turns out it was all down to how Jersey was configured to convert Java to JSON. This guy describes the problem well and the first solution that I tried, but clearly that wasn’t a great long term option. The longer term solution was to use Jersey’s POJO support, which basically amounts to sticking this in your web.xml.

<init-param>
  <param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name>
  <param-value>true</param-value>
</init-param>

BTW I don’t usually blog on a Saturday night, not that I’m saying there is anything wrong with that, but its just that my wife is watching the final of Strictly Come Dancing 😦