Planet UCLUG

The NetBeans 7.1 IDE has a feature that has been around for a while, but does not get as much attention as it should. NetBeans allows you to take advantage of using remote databases for doing Java development. There are a number of wizards which can take advantage of connections created in the Services → Database tab.

In the demonstration video, I connect to a remote Apache Derby Database, but the same principals apply to any database as long as you have JDBC drivers available.

Tips & Tricks


To verify that a remote database is Apache Derby (Java DB) which is listening on port 1527 (default Derby port). I connect to the remote application and append XXX;create=true; to the end of the connection string. When I test the database connection, if it is Apache Derby, it will create the new database which confirms our suspicion.

This 3 minute video demonstrates this valuable feature which developers should use for all their database needs.

The NetBeans 7.1 IDE introduces a really cool new feature called shelving. This allows a developer to make changes to a project without committing them to a source control system.

How often have you wanted to try out some new idea on your code without having to check it into source control? This allows you to do just that.

What is shelving?

Shelving creates a patch based on whether an individual file, files, or project is selected. This is a standard patch file and can be applied from the command line, or sent via email to others.

A nice feature is that you can provide meaningful names to the shelved changes. This makes it easier to go back later and apply them to your project.

Note: This functionality is only available for Subversion and Mercurial based projects.

I created a five minute video to demonstrate this really cool new feature.

I gave a talk this month at the Greenville Java Users Group (GreenJUG) on the new features, and tips & tricks in the new NetBeans 7.1 IDE.

One of the most popular demonstrations was using NetBeans to download Apache Commons IO from the Apache Subversion repository, open the Apache Maven project natively, and upgrade it from JDK 5 to JDK 7.

This is a real world demonstration of the incredible and powerful new capabilities in the IDE. What is particularly interesting is that the Apache Commons IO project does a great job of providing  unit tests to validate our changes.

I created a 20 minute video which demonstrates this really vital new functionality to help you migrate your projects to JDK 7.

JAX-RS (Jersey) offers a GZIP filter to compress data for responses, and to handle GZIP compressed requests. This functionality is very easy to enable, and is configurable for both requests, and responses. That does not get much easier.


 You can prove that this works by querying your resource with Firebug, or Developer Tools (depending on browser). You can also confirm that it is working by performing a query like:

curl -HAccept-Encoding:gzip -HAccept:application/json http://localhost:8080/content-coding-gzip/webresources/widget > json.gz
gzip -v -l json.gz

method  crc     date  time           compressed        uncompressed  ratio uncompressed_name
defla 3a79ae18 Jan 20 15:25                1370                3389  60.3% json

The only issue that I have with the currently implemented version is that it does not use configurable compression level.

Did you know that you can make an OPTIONS method call to a JAX-RS resource to determine its capabilites? JAX-RS supports a complete set of HTTP methods including OPTIONS.

If you make a specific URI request to a resource, it will return the supported methods like GET, PUT, HEAD, and OPTIONS. In addition, Jersey supports returning the WADL file by default. This allows tools like NetBeans to take advantage of the resource.

So I guess some examples are in order. The first example is a request to the server URI which in this case is GlassFish 3.1.1. This is followed by a request to a specific resource on the server instance.

curl -X OPTIONS -v http://localhost:8080

* About to connect() to localhost port 8080 (#0)
*   Trying ::1... Operation not permitted
*   Trying 127.0.0.1... connected
> OPTIONS / HTTP/1.1
> User-Agent: curl/7.22.0 (i686-pc-cygwin) libcurl/7.22.0 OpenSSL/0.9.8r zlib/1.2.5 libidn/1.22 libssh2/1.2.7
> Host: localhost:8080
> Accept: */*
>
 HTTP/1.1 200 OK
 X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.1 Java/Sun Microsystems Inc./1.6)
 Server: GlassFish Server Open Source Edition 3.1.1
 Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS
 Content-Length: 0
 Date: Tue, 17 Jan 2012 14:31:17 GMT

* Connection #0 to host localhost left intact
* Closing connection #0

As you can see the command reports that GlassFish supports all standard HTTP 1.1 methods as denoted by the Allow: header. This example calls a specific resource on the server which only supports a subset of the HTTP methods based on the annotations in the resource. The methods always supported by a resource are HEAD and OPTIONS, but this has two methods annotated as @GET and @POST. Additionally, not that the Content-Type: application/vnd.sun.wadl+xml is returned which includes the WADL for this particular resource.

curl -X OPTIONS -v http://localhost:8080/RESTApproachFormParameter/resources/example

* About to connect() to localhost port 8080 (#0)
*   Trying ::1... Operation not permitted
*   Trying 127.0.0.1... connected
> OPTIONS /RESTApproachFormParameter/resources/example HTTP/1.1
> User-Agent: curl/7.22.0 (i686-pc-cygwin) libcurl/7.22.0 OpenSSL/0.9.8r zlib/1.2.5 libidn/1.22 libssh2/1.2.7
> Host: localhost:8080
> Accept: */*
>
 HTTP/1.1 200 OK
 X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.1 Java/Sun Microsystems Inc./1.6)
 Server: GlassFish Server Open Source Edition 3.1.1
 Allow: OPTIONS,POST,GET,HEAD
 Content-Type: application/vnd.sun.wadl+xml
 Content-Length: 1085
 Date: Tue, 17 Jan 2012 15:01:49 GMT

* Connection #0 to host localhost left intact
* Closing connection #0

In summary, you can take advantage of the OPTIONS method to determine what a particular resource will provide for you without any knowledge of the subject domain.

Saturday at FUDcon began with BarCamp pitches, followed by the BarCamp sessions themselves along with the workshop sessions running in parallel. Lots of awesome content made decisions on what to attend difficult. There seemed to be a ton of cloud-related stuff going on, and most of which concentrated in a single room. I pitched and was able to give a session about CloudStack – and in particular on getting it into Fedora. As evening (and FUDpub) approached things started to wind down.

FUDpub’s venue was quite nice, with TVs (for those wishing to watch the game) multiple bowling lanes, and plenty of pool tables. Plenty of food to be had. And much fun abounded.

Sunday had a slower start for me, with an early non-Fedora meeting taking place, but once  I made it over to McBryde hall there were very clearly still lots of work taking place. As normally happens on the last day of FUDcon – the crowd started thinning out after mid-day. The board had a massive session that lasted about 3 hours, and covered both business and some discussion around monies and intra-project collaboration.And thus this FUDcon drew to a close for me.

I personally find that FUDcon is great for ‘recharging’ my interest in and commitment to Fedora, and getting to meet folks I’ve previously only dealt with via IRC or mailing lists helps build relationships.

Thanks to Ben, Cathy, and Jamie for doing the tons of work necessary for pulling off a FUDcon, and to Virginia Tech for hosting us.

FUDcon never ceases to amaze me. I am fortunate (or cursed, depending on your perspective I suppose) to be able to attend lots of free software and sysadmin conferences. However, FUDcon is always unique – the people who attend are focused on getting things done, and are generally interested in helping others to get things done as well.

I started a bit late in the morning for my arrival – the winds of Appalachia emphasizing the coolness. A number of folks camped out in an empty classroom (dubbed the Nothing Room) and started working on various things. I had a chance to meet Marek Goldmann (mgoldmann) of Boxgrinder fame, who I’ve conversed with a number of times, but never met in person. Marek, Andy Grimm (mull), Bob McWhirter, and I talked about some of the struggles and challenges with getting Java-based software into Fedora – and the differences between the Java development and distro-packaging worlds.

While I was there, I was working on getting a new version of ceph packaged – and Jon Stanley (jds2001) spent some time helping me get it to build.

Lunch time rolled around and then the spins process session from Cristoph Wickert (cwickert) started and we spent some time discussing process, dates, etc.

Following that I stopped in on Mo Morsi’s (mmorsi) Aeolus/Snap session before heading to the Board Meeting at FUDcon.

One of the things that was asked was how were the goals we had set earlier in 2011 – and did we accomplish anything, and how had the board performed. One of the things that came out of this (and for which I am one of the folks at fault) is that while we had identified good strategic goals – as a board overall we had failed to champion any of them, failed to work towards getting some of the tactical actions accomplished for those goals. We talked about how, in volunteer organizations, there’s no ability to ‘direct resources’ – but instead only the ability to inspire, and excite others, and that as a board we had done a poor job of that. Out of that we agreed that in Fedora, things happen by doing, specifically leading happens by getting things done, and hopefully getting others excited in the process. We, as a Board, agreed that we needed to individually adopt some of the tactical actions aimed at furthering the strategic goals, champion those tasks, and hopefully excite others in the process. We agreed to report our individual ‘tasks’ no later than Feb 1, and to provide regular timely updates.

I hope that the preceeding paragraph doesn’t strike folks as being doom and gloom – while I tend to think that as a board we could have executed better, I am also thrilled that we had the chance to sit down, converse, acknowledge, and hopefully begin addressing the problem.

Of course 5pm doesn’t mean FUDcon stops, lots of sessions kept making progress, lots of hallway track session in the hotel lobby, and groups going off for dinner, followed by more hacking in the lobby. An awesome day at FUDcon, nice seeing Fedora friends, and meeting those I’ve only conversed with on mailing lists and IRC. Can’t wait for tomorrow.

GlassFish default encoding returns text encoded as ISO-8859-1. This is based on the Hypertext Transfer Protocol -- HTTP/1.1 RFC 3.7.1 Canonicalization and Text Defaults which requires the default encoding for text to be returned in this manner.

Web application developers often use UTF-8 as the encoding in their applications, but fail to change the server defaults. This applies to anything which uses Servlets (including JSP, and JSF). You can change the defaults in the sun-web.xml, or glassfish-web.xml as shown below by setting the parameter-encoding element. This remove a number of default encoding warnings like this:

WARNING: WEB0500: default-locale attribute of locale-charset-info element is being ignored

WARNING: PWC4011: Unable to set request character encoding to UTF-8 from context /, because request parameters have already been read, or ServletRequest.getReader() has already been called.

One of the less discussed aspects of JAX-RS based on the HTTP 1.1 specification is client negotiation. We often write our applications from the server side and expect the client to send us an Accept: */* header which details which media types the client can accept. The server simply returns whatever we have coded for example @Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML}). However I bet a number of you have seen something like this before:

http://www.example.com/documents/mydoc?format=doc
http://www.example.com/documents/mydoc.xml

The first example is not very subtle. It tells you the client wants a mydoc.doc by requesting a specific format. The second example is more subtle, and the end user (client) may not notice. I made it a "little" more obvious by changing it to .xml. However, most folks would have missed it if I used mydoc.doc. You would have assumed it was a MS Word document to start with. In actuality, the media type returned here is controlled by the file extension.

Note: Updated the source code to include header based negotiation, but this is just mimicking server content negotiation.

In the attached Apache Maven project developed on NetBeans 7.1: jersey-content-negotiation.zip. I demonstrate how to do it.

The first example returns JSON by default, and other media formats as requested. If it does not understand the media type requested, it simply returns plain text.

On the second example which uses the media type extension, I return a 400 - Bad Request instead of plain text like the first example. This subtlety is based on the fact that the client is requesting a specific type based on extension. If you ask for .pdf and get .txt, the result may cause an unanticipated consequence so it is better to throw an exception.

The mixed media type returns are possible because of the Response being wrapped as demonstrated in a previous post: JAX-RS Tip of the Day: Use Response to wrap... Responses.

ContentNegotiationResource.java

---

Client Negotiation Examples

One of the really nice features of JAX-RS is the ability to implement fine grained control over the response returned from the server based on the client request. The Response.ResponseBuilder gives us incredible flexibility to generate the response. Since it uses the builder pattern, it is easy to daisy-chain the information we want into a custom response.

I would highly recommend that you consider returning a custom response for all requests. I would like to explain with an example. I would like to perform a @POST request where I am creating a new object on the server. Since it is a HTTP 1.1 request, I look at Hypertext Transfer Protocol -- HTTP/1.1 (RFC-2616) to see what I must, should, and may return. The difference in the word choices has specific meaning in the specification. In my case, I would like to be completely compliant.

10.2.2 201 Created
The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.
A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section 14.19.

OK, the basic response must return 201 - Created status, and a Location header. It should contain an entity (which may only be entity-headers) and may contain an ETag. This is all very easy to do with Jersey. As you can see from the code snippet, we read the @FormParam information from a form, and create an object which we add to a List<Widget%gt; objects signified by the ws.add(widget) we get the index value for use in our URI. Next we create a URI from our request, and add a path to it for our index.

Finally we use Apache Commons Codec Hex to generate a hex string for our ETag. Finally this is all combined in a Response sent back to the client. This can be seen below.

What do I Read?

I was asked what articles I really like on Jersey, and how to learn more about it. Here is an incomplete list.

If you find more really good ones, please post comments, and I will add them to the list if I like them.

• What Makes Jersey Interesting: Parameter Classes - This article includes examples which explain parametrized classes being used in Jersey.
• What Makes Jersey Interesting: Injection Providers - This article demonstrates a method of doing dependency injection in Jersey. Specifically, it addresses using the @Context annotation to inject a UriInfo object.
• RESTful services with jQuery and Java using JAX-RS and Jersey - This is a great article on using jQuery with JAX-RS. It also demonstrates using curl to test your services and includes code and sample syntax. This article is very professionally done.
• Building RESTful Services with Java Using JAX-RS and Jersey — Sample Application - A demo application including code which demonstrates JAX-RS (Jersey). It is very well done, and it is easy to follow.
• JAX-RS @FormParam example - This simple demo application uses an HTML based form to submit to a Jersey based REST service.
• @FormParam - This is a simple to the point version of using @FormParam. It also explains how to test it using Jersey client.
• REST web services with JAXB, JAX-RS and Sun Jersey - A well written article on using JAXB along with Jersey to create applications. The article includes examples of using curl to test the results.
• JAX-RS @MatrixParam example - An example application that demonstrates @MatrixParam usage.
• How to access parameters in a RESTful POST method - Multiple examples of how to get parameters from a POST.
• REST with Java (JAX-RS) using Jersey - Tutorial - This is a superb article on JAX-RS and is very professionally done.
• JAX-RS as the one Java web framework to rule them all? - This is just a general discussion article with links to other related technologies.