Blog from August, 2017

I've created an updated "about" page on the website.  It's currently not linked, but can be viewed via this URL...

http://juneau.incubator.apache.org/index2.html

I've tried to break up the information based on the Maven artifacts.  

Let me know your thoughts....

FYI.....I plan on reworking the Juneau projects to use nested feature group projects.  The groups will be as follows...

• juneau-core - Core projects.
• juneau-rest - REST and Microservice projects.
• juneau-examples - Example projects.
• juneau-releng - Release engineering projects.

The layout will be as follows....

Note:  The juneau-rest-test project prereqs the juneau-microservice project which is why the REST and microservice projects are in the same group. 

Let me know if anyone has any concerns with this change.

The Juneau serializers will now serialize the contents of Readers and InputStreams directly to the output stream.  They used to just call call the toString() method on these objects (which wasn't particularly useful).

When used in conjunction with swaps, you can now provide low-level serialization of POJOs for any of the non-RDF languages:

@Pojo(swap=MyBeanSwap.class)
   public class MyBean {...}
   
   public class MyBeanSwap extends PojoSwap<MyBean,Object> {
      public Object swap(BeanSession session, MyPojo o) throws Exception {
         MediaType mt = session.getMediaType();
         if (mt.hasSubType("json"))
            return new StringReader("{foo:'bar'}");  // Custom JSON output
         return o; // Otherwise treat as normal bean
      }
   }
   
   // Produces "{foo:'bar'}"
   String json = JsonSerializer.DEFAULT_LAX.toString(new MyBean());

* This doesn't work for RDF because we don't have access to the underlying stream.  Instead, we use an intermediate Jena model.  In this case, the contents of the Reader/InputStream are converted to a literal.

This is a stepping stone to supporting FreeMarker template support for POJOs.  Instead of a solution for just HTML, I'm interested in finding a generalized template solution for any language that builds upon the existing Swap API.  

The general idea is that we can define template strings against POJOs using an annotation such as the following:

@Pojo(templates={"freemarker:/MemberAddressRender.div.ftl"})
public class MemberAddress {
}

Or they can be defined on @RestResource and @RestMethod annotations...

@RestMethod(
   templates={
      "MemberAddress=freemarker:/MemberAddressRender.div.ftl"
   }, 
   templateEngines={
      FreeMarkerTemplateEngine.class
   }
)

Engines would be tied to media types.  So for example, the FreeMarkerTemplateEngine would be mapped to the "text/html" media type and thus only be invoked by HtmlSerializer.  The engine would swap out POJOs with either Readers or HTML5 beans.  

I've added a new annotation that resolves the feature request shown below.

1. JUNEAU-64 Support advanced annotated variables on methods implementing onPreCall and onPostCall

It also adds the capability for performing child resource initialization before parent resource initialization.

The change replaces the various servlet and REST call lifecycle methods with a single unifying method annotation:
http://juneau.incubator.apache.org/site/apidocs/org/apache/juneau/rest/annotation/RestHook.html

One of the nice features is that you can add as many of these annotated methods as you like to your class.  For example, instead of a single init(RestConfig) method, just add your own init methods and never have to worry about calling super.init(RestConfig).                

In order to get this to work, I did have to make the RestServlet.init(ServletConfig) final so that it can no longer be extended.  The normal HttpServlet.init() method can still be overridden, however it's probably best-practice to just use @RestHook(INIT).

I debated whether to keep these, but decided to remove them from the RestServlet class to keep things simple:

• • init(RestConfig) - Use HookEvent.INIT instead.
  • onSuccess(RestRequest, RestResponse, long) - Use HookEvent.END_CALL instead.
  • onPreCall(RestRequest) - Use HookEvent.PRE_CALL instead.
  • onPostCall(RestRequest, RestResponse) - Use HookEvent.POST_CALL instead.

Some updates have been made around the use of Jetty in the microservice API:

1. The version of Jetty has been upgraded to v9.4.6.v20170531
   
   
2. The microservice now ships with a default jetty.xml file that can be used to configure Jetty.  Settings related to authentication and SSL have been removed from the cfg file.  You can still define resource mappings and used ports in the cfg file, but the default behavior is to specify these in the jetty.xml file.  
   
   
3. The introduction of the new Jetty version required me to bump up the javax.servlet version from 3.0.1 to 3.1.0 and add some minor code changes.  This is going to require at least a minor version bump.