Thursday Feb 20, 2014

JAX-RS 2.0 MessageBodyReader not found error

From time to time we all make silly mistakes which lead to much head scratching and time being wasted. This is a short missive about just such a mistake that I made yesterday which then had me totally stumped (for a a few minutes at least!) this morning.

So, here's the story.  I was taking a long flight back to the UK from California yesterday and had wanted to keep working on a client UI for a RESTful service provided by our build infrastructure.  As you can imagine, it's not going to work very well to access those services in flight, so I spent the wait time in the lounge building out a quick mock implementation of the data structure using the same POJOs so I could switch to that and continue with the UI development offline. As part of this I thoughtlessly added a new constructor into my main POJO that the REST service JSON structure mapped in to.  All was well.

This morning I'm back online, so I switch the implementation of my UI data provider back to the real service to see what the UI now looks like with more data - it fails? Huh? OK back to the test client - it also fails:

Exception in thread "main" 
  MessageBodyReader not found for media type=application/json, 
  type=class com.groundside.model.Orchestration, 
  genericType=class com.groundside.model.Orchestration.
 at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.aroundReadFrom(
 at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed(
 at org.glassfish.jersey.message.internal.MessageBodyFactory.readFrom(
 at org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(
 at org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(
 at org.glassfish.jersey.client.ClientResponse.readEntity(
 at org.glassfish.jersey.client.InboundJaxrsResponse$
 at org.glassfish.jersey.internal.Errors.process(
 at org.glassfish.jersey.internal.Errors.process(
 at org.glassfish.jersey.internal.Errors.process(
 at org.glassfish.jersey.process.internal.RequestScope.runInScope(
 at org.glassfish.jersey.client.InboundJaxrsResponse.readEntity( 

So now I spin round and make all the checks I can think of.  The libraries are all unchanged, perhaps the shape of the service has been changed overnight? - nope, every thing is the same.  The mime type coming from the service is still application/json as well. 

So I'm pretty confused. Back to first principles though. Has really nothing changed? Well in fact yes there was a change - just one little, tiny thing, that new constructor.  Of course that was it.  One of the requirements for the JAX-RS unmarshalling is that the entity class should have an empty constructor.  Before it was implicit, but now I'd added that new constructor for the mocking which included arguments and that replaced the implicit empty constructor and broke the above requirement to boot.  So it was simple to fix in the end just annoying. Hey ho...

Friday May 17, 2013

Launching JConsole as an External Tool From JDeveloper

I find JConsole to be a useful tool, particularly for MBean browsing, but frankly getting the correct command line arguments to get it to connect correctly to my WebLogic instances is a bit of a pain. I always have to go and look it up. - generally from here. However, setting all those paths is tedious. Given that I'm usually working in an environment where my JDeveloper, and the WebLogic servers I'm using JConsole on, are matched from a version perspective I can get JDeveloper's external tools capability to do the lifting.

Very simple this. Just choose Tools > External Tools from the menu and press New.  Then run through the wizard:

  1. Type is External Program
  2. Program Options > Program Executable = jconsole 
  3. Program Options > Arguments =  (All on one line of course, reformatted here for readability)

And that's it.  JDeveloper helpfully substitutes both the Java location and the WebLogic location for us saving all that hunting around.  


 Thanks to Torsten Kleiber who discovered and followed up on the twist of ${java.path} not expanding correctly (or rather expanding to null). Before running the tool command with the macro make sure that you have a project open and selected as the actual java path is obtained in the context of the JRE version used by the selected project. (Project Properties > Libraries and Classpath > Java SE Version)

Wednesday Feb 20, 2013

Using JDeveloper & with Subversion 1.7

This issue has come up a couple of times this week and has also be raised on the OTN JDeveloper Forum, so it seemed to be worth a quick public-service announcement.  

Subversion 1.7 introduces changes (AKA complete re-write) into the way that working copies are stored, the implication of this is that a 1.6 client and a 1.7 client cannot operate again the same working copy on a developer's workstation. 

Current versions of JDeveloper's SVN support contain 1.6 client code, so if you are mixing and matching JDeveloper and SVN / Tortoise command line operations you will run into trouble. 

e.g. The following sequence of operations will fail:

  1. Checkout working copy from the command line with the svn 1.7 client
  2. Make updates and attempt to checkin from JDeveloper 

However, the following should work:

  1. Checkout working copy from JDeveloper 
  2. Make updates and checkin from JDeveloper 

As will:

  1. Checkout working copy from the command line with the svn 1.7 client
  2. Disable the JDeveloper SVN plugin - (Versioning -> Configure -> Uncheck - Versioning Support for Subversion )
  3. Make updates  to existing files only from JDeveloper
  4. Commit / Add / Delete operations from Command line svn 1.7 client. 

Obviously, for convenience and because some operations such as refactoring need to issue SVN commands I'd recommend that, if using a 1.7 repository, you carry out all operations including the initial checkout from within the IDE.  

As a general guidance if you are going to upgrade your repository (and my further advice would be not to upgrade at the moment if your primary client is JDeveloper) I'd recommend that you clean up any outstanding transactions before the upgrade, and then, once the server is up to 1.7, do a clean checkout from JDeveloper and stick to working within that environment.

Thursday May 17, 2012

Setting Up Embedded WLS for MySQL

For a while, on and off,  I've been playing with MySQL in various applications, to the extent that it made sense to work out how to specifically configure the domain so that the MySQL driver would always be available. The advice in the great googleblogosphere seems to be to drop the jar file in the DefaultDomain/lib directory and all will be well. But although you can then see the jar being loaded as WLS starts up, it certainly wasn't working for some of my pre-loading services within the container which could still not find the driver. (Although I'm not saying that this technique would not be OK for an ADF application that you deploy that uses MySQL)  

In the end I thought that the simplest thing was to work out what we do with the Oracle driver and emulate that. Sure enough it's there in the /DefaultDomain/bin/setDomainEnv script (.cmd or .sh).  You'll find it in there in the PRE_CLASSPATH section. So my solution was to simply add the driver reference there (code below reformatted for clarity):

if NOT "%PRE_CLASSPATH%"=="" (
  set PRE_CLASSPATH=%COMMON_COMPONENTS_HOME%\modules\oracle.jdbc_11.1.1\ojdbc6dms.jar;
) else (
  set PRE_CLASSPATH=%COMMON_COMPONENTS_HOME%\modules\oracle.jdbc_11.1.1\ojdbc6dms.jar;

And that's certainly done the trick for me.  So I think I can guarantee that at least one of the two methods here will work for you... At some point I'll put together a proper MySQL Extension for JDev that creates a library, sets this up, and registers a custom type-map for ADFBC, but alas time is always at a premium... 

Tuesday Jun 07, 2011

Unsung Heroes of 11.1.2

Given that 11.1.2 came out today I thought I'd take a slight sidestep from my current pursuit of all things ADFLogger related to highlight some of the unsung features in this release. There's no doubt that the headline features such as JSF 2 and Facelets are great but I'm sure lots of folks will be exploring those, so now for something a little different:

Sparse Data Control for Beans

In the past the bean data control generated a bunch of XML descriptor files for each class it needed to describe. Well in this release that has all gone by default, and all that is needed is a single entry in the DCX file for each class - much neater. Mind you, you can still have the XML descriptors if you need to decorate the bean attributes (say with validation). There is a lot more going on with the Bean DC which I will try and get around to writing up soon enough.

Hot Deploy!

Oh yeh! If you live and breathe in the IDE all day long that whole process of running and re-running to deploy the latest metadata and classes is frankly a little boring and time consuming. The great news here is that all you have to do is save and magically  the classes, pages and metadata are redefined in the running server without you having to re-run to force the deploy. Up until now you've only been able to save get the changes instantly if you're only changing the JSPX structure and not changing bindings or classes.

This is just such a huge time-saver although you have to remind yourself not to press run sometime. I'll warn you though, there is a bit of an art to using this feature. bear in mind that any state that your application is carrying is not re-initialized so weird things can happen if you're half way through a transaction and then swap out some essential class or binding.  I've found the best approach is to include a test link in my page template which essentially restarts the app in a new session so I'm working with an expected environment for each test. At least I've bypassed all of that re-deploy stuff. 

New Refactor Option 

We have added an externalize/ Internationalize Strings refactoring, which as you would correctly guess takes your inline String and pops it into a resource bundle. I don't know why this one appeals to me so much it just does. There are about 4 other new refactorings in the release but this is my favorite. 

But Wait, There's More... 

Of course there's lots lots more in this release, over 500 features and enhancements, and it's fast! On my Air here I'm running off of the internal solid state disk and 11.1.2 off of an external 5600 USB hard drive. Despite this, the startup time for 11.1.2 is almost exactly half that of the earlier version. I should probably swap the two around and see how fast R2 is off the solid state, I suspect that that will get me down to about a  10 second startup for the IDE.


Hawaii, Yes! Duncan has been around Oracle technology way too long but occasionally has interesting things to say. He works in the Development Tools Division at Oracle, but you guessed that right? In his spare time he contributes to the Hudson CI Server Project at Eclipse
Follow DuncanMills on Twitter

Note that comments on this blog are moderated so (1) There may be a delay before it gets published (2) I reserve the right to ignore silly questions and comment spam is not tolerated - it gets deleted so don't even bother, we all have better things to do with our lives.
However, don't be put off, I want to hear what you have to say!


« July 2016