The CDI programming model has pre-requisite requirements for beans which are lucky enough to leverage its services (DI, contextual state management etc.). This ranges from typical Java EE Managed Beans, EJB (session) beans etc. (I’ll leave the details for another post)
But the good thing is that
.. it also provides some freebies i.e. beans which are available for injection by default
To be noted
- One can user either @Resource or the more obvious @Inject annotation to trigger injection
- The @Default qualifier is applicable to injected instances of these beans
Where can I inject these beans ?
Well, standard rules (defined by the CDI specification) apply here. I would recommend looking into the official Java EE Platform specification document (section EE 5.2.5, Table EE.5-1) which details this clearly. Here is a snapshot – Java EE managed beans, CDI managed beans, EJB, Servlet spec components, Web Socket endpoints, JSF managed beans etc.
Go on, check out the freebies …
Let’s quickly look at the Java EE 8-JCache bridge project. This is another concrete step as far as Java EE 8 integration efforts are concerned..
Details on the general idea behind this can be picked up from one of my recent posts on this topic
A bridge ?? What for ?
- Serve as the integration point for JCache & Java EE 8
- Provide decoupling: the Java EE 8 platform and the JCache API can be allowed to evolve separately and the bridge would provide a much needed cushion. Think of it as a regular Bridge Pattern (from the GoF) – just implemented in the form of a JSR ;-)
- Derive from exiting (and popular) specifications like JPA which can make it easier to adopt and use
- Standardise a JCache descriptor (configuration)
- Implement Cache injection
- Look at support for custom cache properties (which vary across different providers)
Crossing the bridge
Here is a rather simple example. Its a Java EE 7 Maven project on GitHub. You should be able to pull in into any IDE (Netbeans recommended) and get going
All it does is
- Defines a named cache in cache.xml placed within WEB-INF/classes/META-INF (this is a pre-requisite for WAR based artifacts)
- Inject the cache in a JAX-RS resource
- Save the JSR info in the cache for future use (if it already does not exist there)
- It provides you JSR information e.g. http://localhost:9000/jcachejavaee8bridge/370 and tells you whether it has been picked up from the cache
Other notable points
- The cache bridge API source has been included directly into the sample project to make dependency management easier (since its not in Maven yet). You might want to have the latest fork for your experiments
- The JCache RI is being used by internally by the bridge. Experiment with another JCache provider (Hazelcast, Infinispan etc.), include its dependency and include it in the cache.xml configuration
How can you contribute ?
- Explore the project
- Provide ideas, files issues
- Write tests, break stuff, file some more issues !
- Get in touch with Adam Bien, translate your ideas into code and submit a PR…
Previously on Java EE 8…
I had come up with a 2-part blog series with regards to its specifications and potential goals. But this was a long time back. I am hoping to track it on a more consistent basis, now that’s there is more concrete stuff to discuss. I recently posted about some JCache integration related discussions.
On this episode..
Let’s look at what’s going on with the Java EE 2.0 Management API. I provided a brief intro in one of my previous posts, so let me reuse that ;-)
What’s changed from the last time I blogged was that there is a experimental example available for you to explore. You should check this post from Adam Bien for more details and dig and further.
I have not dug into the Bean Validation specification into detail before, but one of the entries posted in the Payara issue tracker made me explore how the JAX-RS specification integrates/leverages the Bean Validation features
Note: Bean Validation has been around since Java EE 6, but its integration with JAX-RS was materialized only in the latest (2.0) version (part of Java EE 7)
In case you want to jump right into the code, you can fork it from GitHub
I don’t want to dive into too many details
- JAX-RS supports declarative (as opposed to programmatic) validation using annotations from Bean Validation specification
- It supports application of constraints to JAX-RS resource classes, method parameters (both request bodies as well as other components such as headers and URI parts like query parameters etc.), method return types and fields as well
The JAX-RS spec also defines default behaviour for scenarios when the bean validation constraints are violated
JAX-RS implementations are forced to provide (by the spec) a default ExceptionMapper for handling bean validation constraint violation exceptions. It returns standard responses (HTTP 400/500) to clients based on some (default) rules outlined in the specification (see section 7.6 of the JAX-RS spec doc)
Customizing default JAX-RS behaviour
The default JAX-RS behaviour can be overridden by providing your own (custom) Exception Mapper implementation
- I would encourage you to dig into Chapter 7 of the JAX-RS 2.0 specification document for deeper insight into this topic. It’s brief and to the point
- Oh, and here is the link to the latest Bean Validation (1.1) spec doc
The contents of this post are derieved from conversations on the Java EE 8 mailing lists with regards to JCache integration. There are a couple of threads
Here are a bunch of points which seemed to have to come out of the discussions so far
JCache & Java EE 8 integration points
CDI can be used to manage caches with the help of Producers. Containers can also provide portable CDI extensions to make the job a little easier and reduce boilerplate (see TomEE jcache-cdi)
Implementing JCache annotations
JCache ships with annotations meant to be leveraged by DI containers. A Java EE implementation would need to provide support for these annotations which can also be achieved by CDI interceptors (possibly in the form of portable CDI extensions)
Other Jaa EE specs leveraging JCache
Different Java EE 8 specs can make use of the presence of JCache standards and make use of its features. One of the most common example would be JPA 2.2 using JCache provider as a (distributed) L2 (Level 2) cache. Payara has this lined up as well
Payara is leading the way with some other use cases in the pipeline
What’s the bare minimum ?
As Johan Vos stated, just including it in the Java EE 8 Platform would be great!
I’ll stop rambling and open the floor for discussions, inputs and suggestions – over here, on the open Java EE 8 mailings lists or maybe in a blog post of your own ..?
Injection made easy
JAX-RS provides simple set of API components to make it easy to extract information from your HTTP requests. It takes care of all the heavy lifting – all you need to do is use the applicable annotation (from the list below) and the container will inject the data for you
- @MatrixParam, @QueryParam, @PathParam: injects URI related info
- @HeaderParam, @CookieParam: takes care of headers and cookies sent along with a HTTP request
- @FormParam: handles form data (application/x-www-form-urlencoded content type) POSTed over HTTP
but there are a few rules…
As far as automatic injection is concerned, JAX-RS applies the following constraints
- applicable for Java primitives (or equivalent wrappers) and String (of course)
- A custom type which has a static valueOf method or public constructor (both should accept a single parameter of type String)
- Supported Collections types: List, Set (whose generic type parameters comply with above mentioned rules)
what about exceptional scenarios ?
More often than not, you would need to deal with data types which do not comply with the above rules. Also, you might not have the ability to retrofit (change) the actual source. In such scenarios, you can use a ParamConverter implementation to provide custom conversion logic of your HTTP request data (String) to your desired Java type. Here is an example
we are not done yet !
The ParamConverter implementation is not the actual provider which the JAX-RS runtime accesses directly. A ParamConverterProvider implementation provides another layer of abstraction in order to select the right ParamConverter for the job.
To be noted…
- The JAX-RS runtime automatically passes some parameters in the getConverter method. This allows for some extra processing/decision making logic based on the parameters passed in by the JAX-RS runtime
- The ParamConverter and ParamConverterProvider interfaces were introduced in JAX-RS 2.0 (part of Java EE 7 Platform)
Just click here for some of my previous JAX-RS posts …
This post briefly demonstrates how to develop and deploy (server and client) Websocket endpoints using the programmatic version of the Java Websocket API
To begin with…
extend the javax.websocket.Endpoint class
Let’s code the client endpoint as well (using the same set of APIs)
.. and then
implement the ServerApplicationConfig interface
It is part of the javax.websocket.server package and can be overridden to implement custom logic for endpoint deployment (for both annotated as well as programmatic endpoints)
What about the client endpoint ?
If required, you can create a your own instance of ClientEndpointConfig and use it while initiating a connection to the websocket server endpoint
To be noted
- Both the client as well as server endpoint config objects are nothing but object (programmatic) equivalents of the elements (value, encoders, decoders, configurator etc.) of the @ServerEndpoint and @ClientEndpoint annotations
- Separate builder classes (ServerEndpointConfig.Builder and ClientEndpointConfig.Builder) were used to create server and client configuration instances respectively
- The creation of a ServerEndpointConfig instance is mandatory since server endpoints cannot be deployed without a URI. This is not the case with client endpoints though – all they do is connect to an existing server endpoint.
- The endpoint config (server & client) have the notion of a configurator which can be created and set via the respective builder methods.
Stay tuned for some more Websocket related action in the near future
feel free to…
I am happy to announce the beta version of my (mini) book – EJB Annotations Primer :-)
To download …
Just visit the book page and click the Add Ebook to Cart button. Don’t worry, the book is absolutely free ! :-)
- Covers Enterprise Java Beans (EJB 3.2): part of the Java EE Platform
- Emphasis on it’s annotations
- Can be used as a quick refresher or a entry/high level guide
- Geared towards easing the learning process
- Explores (almost) all the EJB features: life cycle management, dependency & resource injection, pooling, concurrency, web services, interceptors, security, transactions, schedulers & timers, asynchronous model, eager initialisation, heterogenous interfaces/views and exception handling
- Source code available on GitHub (will be updated along with the rest of the content)
- Remaining chapters: dependency and resource injection, transactions, security and heterogenous views
- A better cover page [ maybe ? :-) ]
- More code/examples
- Leanpub: empowering publishing medium ! Love it..
- NetBeans: Awesome IDE (specially for Java EE devs)
- GlassFish: bleeding edge Java EE RI !
- MacDown: my markdown editor
- Pandoc: very helpful in the initial stages of the project (when I was stuck with .doc and needed to convert it to markdown)
- and…. myself ;-)
Although it is still work in progress, I would encourage you to give it a go and provide feedback. I’ll provide further updates as and when I make further inroads..
CDI events allow your application components to communicate with each other in a loosely coupled manner. Those more familiar with JMS can also think of CDI events as a Synchronous equivalent of JMS (with Java EE 8, CDI 2.0 will offer asynchronous event mechanism).
Events can be enriched using qualifiers. Think of these as message selectors (the concept is not very different from Message Selectors in JMS).
Using Dynamic CDI event qualifiers
The above example demonstrates the static way of declaring qualifiers. CDI also provides a more dynamic version of the same feature (qualifier declaration).
Please note that you can specify multiple qualifiers with this mechanism
Although not discussed here, the Event interface also exposes couple of other methods to allow dynamic qualifier selection.
The benefits are obvious…
The select method (and its overloaded counterparts) provide a flexible way of handling qualified events and helps avoid proliferation of injected Event instances for specific set of qualifiers.
The folks at Webucator have converted one of my previous blog posts (about automatically retrying operations in Java EE applications using Interceptors) into a video tutorial.
Personally, I tend to stick to text only blogs due to lack of time and sometimes sheer laziness ;-) Thanks to the Webucator team who have come up with a nice explanation of the core concept outlined in my post. Do check out their Java EE training material as well.