<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Jersey on tl;dr</title>
    <link>https://blog.dejavu.sk/tags/jersey/</link>
    <description>Recent content in Jersey on tl;dr</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <managingEditor>michal@dejavu.sk (Michal Gajdoš)</managingEditor>
    <webMaster>michal@dejavu.sk (Michal Gajdoš)</webMaster>
    <lastBuildDate>Tue, 17 Mar 2015 09:15:06 +0000</lastBuildDate>
    
	<atom:link href="https://blog.dejavu.sk/tags/jersey/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>JAX-RS Providers on Client and on Server</title>
      <link>https://blog.dejavu.sk/jax-rs-providers-on-client-and-on-server/</link>
      <pubDate>Tue, 17 Mar 2015 09:15:06 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/jax-rs-providers-on-client-and-on-server/</guid>
      <description>&lt;p&gt;In this article I&amp;#8217;d like to explain two things. First, what to do when you want to restrict JAX-RS providers to be used on, for example, client-side only. And second, what are the issues (and how to solve them) with injecting providers when you create and register instances of them directly.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Jersey CDI Integration – Few Notes and EAR Support</title>
      <link>https://blog.dejavu.sk/jersey-cdi-integration-few-notes-and-ear-support/</link>
      <pubDate>Wed, 11 Mar 2015 13:35:43 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/jersey-cdi-integration-few-notes-and-ear-support/</guid>
      <description>&lt;p&gt;During our last sprint I was porting support for CDI injections for EARs that contain multiple JAX-RS web applications (WARs). This worked fine in Jersey 1 and it works on WebLogic but we didn&amp;#8217;t have support for these kind of deployments directly in Jersey (which means that Glassfish was affected as well) until this very moment. I&amp;#8217;d like to share some findings I&amp;#8217;ve made while working on this task.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Checkstyle matters to Jersey too …</title>
      <link>https://blog.dejavu.sk/checkstyle-matters-to-jersey-too/</link>
      <pubDate>Fri, 06 Mar 2015 12:09:38 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/checkstyle-matters-to-jersey-too/</guid>
      <description>&lt;p&gt;Last week &lt;a href=&#34;https://twitter.com/pavel_bucek&#34;&gt;Pavel&lt;/a&gt; wrote and published an interesting blog post about &lt;a href=&#34;https://blogs.oracle.com/PavelBucek/entry/why_checkstyle_matters&#34;&gt;Why Checkstyle matters &amp;#8230;&lt;/a&gt; I remember how he was describing his encounter with &lt;a href=&#34;https://github.com/zeromq/jeromq&#34;&gt;JeroMQ&lt;/a&gt; to me. Especially the part where he wasn&amp;#8217;t able to build the project for a few times because of the &lt;a href=&#34;http://checkstyle.sourceforge.net&#34;&gt;Checkstyle&lt;/a&gt; issues that pop-up right after he executed the build. I found the whole idea behind running code style checks during build appealing as well and decided to do something similar for Jersey.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Performance Improvements of Sub-Resource Locators in Jersey</title>
      <link>https://blog.dejavu.sk/performance-improvements-of-sub-resource-locators-in-jersey/</link>
      <pubDate>Thu, 12 Feb 2015 16:50:12 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/performance-improvements-of-sub-resource-locators-in-jersey/</guid>
      <description>&lt;p&gt;There were many performance improvements since Jersey 2 first came out almost 2 years ago. Jakub and I decided to present some of the latest ones in our recent articles. Jakub took a look at general performance gains in Jersey in his &lt;a href=&#34;https://blogs.oracle.com/japod/entry/jersey_2_performance&#34;&gt;Jersey 2 Performance&lt;/a&gt;. I&amp;#8217;ll try to cover the change we introduced in Jersey 2.16 and that affected processing and performance of sub-resource locators in Jersey applications.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Jersey’s Entity Filtering meets Jackson</title>
      <link>https://blog.dejavu.sk/jerseys-entity-filtering-meets-jackson/</link>
      <pubDate>Wed, 04 Feb 2015 09:25:53 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/jerseys-entity-filtering-meets-jackson/</guid>
      <description>&lt;p&gt;Support for Entity Filtering in Jersey introduces a convenient facility for reducing the amount of data exchanged over the wire between client and server without a need to create specialized data view components. The main idea behind this feature is to give you means that will let you selectively filter out any non-relevant data from the model before sending the data to the other party.&lt;/p&gt;

&lt;p&gt;Entity Data Filtering is not a new feature but so far the support was limited to MOXy JSON provider. Since Jersey 2.16, we support also &lt;a href=&#34;https://github.com/FasterXML/jackson&#34;&gt;Jackson&lt;/a&gt; (2.x) JSON processor and in this article we&amp;#8217;re going to take a look into it in more detail.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>JAX-RS.next and Reactive Jersey Client – Slides from CZJUG presentations</title>
      <link>https://blog.dejavu.sk/jax-rs-next-and-reactive-jersey-client-slides-from-czjug-presentations/</link>
      <pubDate>Tue, 27 Jan 2015 12:41:41 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/jax-rs-next-and-reactive-jersey-client-slides-from-czjug-presentations/</guid>
      <description>&lt;p&gt;Yesterday I was given the opportunity to speak at our local Java User Group meeting (CZJUG). I was covering two topics – &lt;em&gt;JAX-RS.next&lt;/em&gt; and &lt;em&gt;Reactive Jersey Client&lt;/em&gt;. In this post I&amp;#8217;d like to share the used slide-decks and some additional resources.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Intercepting Jersey resource method calls</title>
      <link>https://blog.dejavu.sk/intercepting-jersey-resource-method-calls/</link>
      <pubDate>Wed, 21 Jan 2015 09:30:29 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/intercepting-jersey-resource-method-calls/</guid>
      <description>&lt;p&gt;Sometimes it would be nice to have a possibility to wrap a resource method call. Imagine a use-case in which you need to process business code, placed in your resource method, in a transaction (open transaction before resource method, commit or rollback transaction at the end) or apply some advanced security constraints. If you&amp;#8217;re using JAX-RS together with CDI in your application it&amp;#8217;s not a problem to do such things. Fortunately, with Jersey it&amp;#8217;s also possible to do those things outside of CDI.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Reactive Jersey Client, Part 3 – Customization</title>
      <link>https://blog.dejavu.sk/reactive-jersey-client-part-3-customization/</link>
      <pubDate>Wed, 07 Jan 2015 08:15:43 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/reactive-jersey-client-part-3-customization/</guid>
      <description>&lt;p&gt;Reactive Jersey Client API is a generic API allowing end users to utilize the popular reactive programming model when using Jersey Client. This part of the series describes SPI and implementation of support for custom reactive libraries.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Reactive Jersey Client, Part 2 – Usage and Supported Libraries</title>
      <link>https://blog.dejavu.sk/reactive-jersey-client-part-2-usage-and-supported-reactive-libraries/</link>
      <pubDate>Wed, 07 Jan 2015 08:10:43 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/reactive-jersey-client-part-2-usage-and-supported-reactive-libraries/</guid>
      <description>&lt;p&gt;Reactive Jersey Client API is a generic API allowing end users to utilize the popular reactive programming model when using Jersey Client. This part of the series describes API, usage and lists all supported reactive libraries.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Reactive Jersey Client, Part 1 – Motivation</title>
      <link>https://blog.dejavu.sk/reactive-jersey-client-part-1-motivation/</link>
      <pubDate>Wed, 07 Jan 2015 08:05:38 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/reactive-jersey-client-part-1-motivation/</guid>
      <description>&lt;p&gt;Reactive Jersey Client API is a generic API allowing end users to utilize the popular reactive programming model when using Jersey Client. This part of the series describes motivation behind creating Reactive Jersey Client.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>JSON in Query Params or How to Inject Custom Java Types via JAX-RS Parameter Annotations</title>
      <link>https://blog.dejavu.sk/inject-custom-java-types-via-jax-rs-parameter-annotations/</link>
      <pubDate>Tue, 11 Feb 2014 09:35:29 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/inject-custom-java-types-via-jax-rs-parameter-annotations/</guid>
      <description>&lt;p&gt;Although I am not a big fan of sending JSON in other places than in the message body as the entity, for example in query parameter in case of requests, it&amp;#8217;s not a rare use-case and the way how it can be solved in JAX-RS 2.0 gives me a nice opportunity to illustrate usage of two new interfaces, &lt;a href=&#34;https://jax-rs.github.io/apidocs/2.0.1/javax/ws/rs/ext/ParamConverterProvider.html&#34;&gt;ParamConverterProvider&lt;/a&gt; and &lt;a href=&#34;https://jax-rs.github.io/apidocs/2.0.1/javax/ws/rs/ext/ParamConverter.html&#34;&gt;ParamConverter&lt;/a&gt;. You can then re-use this approach to inject other media-types or formats your application relies on via @*Param annotations (@MatrixParam, @QueryParam, @PathParam, @CookieParam, @HeaderParam).&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Filtering JAX-RS Entities with Standard Security Annotations</title>
      <link>https://blog.dejavu.sk/filtering-jax-rs-entities-with-standard-security-annotations/</link>
      <pubDate>Tue, 04 Feb 2014 09:35:13 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/filtering-jax-rs-entities-with-standard-security-annotations/</guid>
      <description>&lt;p&gt;Few times I&amp;#8217;ve ran into a situation in which I wanted to return only a part of entity I was working with, in my service, to the client-side. Feature that would allow me to send this partial set of fields should not only be driven by my own filtering rules but it also should take into consideration application roles the current user is in. It&amp;#8217;s not an uncommon use-case I&amp;#8217;d say so in Jersey we&amp;#8217;d come up with the Entity Filtering concept that would allow you to do such a thing: sending subgraph of entities from server to client (and vice versa), define your own filtering rules and make sure users get only the fields they are supposed to see.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Handling JAX-RS and Bean Validation Errors with MVC</title>
      <link>https://blog.dejavu.sk/handling-jax-rs-and-bean-validation-errors-with-mvc/</link>
      <pubDate>Tue, 28 Jan 2014 09:35:12 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/handling-jax-rs-and-bean-validation-errors-with-mvc/</guid>
      <description>&lt;p&gt;Since JAX-RS 2.0 you can use Bean Validation to validate inputs received from users and outputs created in your application. It&amp;#8217;s a handy feature and in most cases it works great. But what if you&amp;#8217;re using also MVC and you want to display custom error page if something goes wrong? Or what if you want to handle Bean Validation issues in a slightly different way than JAX-RS implementation you&amp;#8217;re using does? This article will give you some answers to these questions.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Updating Jersey 2 in GlassFish 4</title>
      <link>https://blog.dejavu.sk/updating-jersey-2-in-glassfish-4/</link>
      <pubDate>Tue, 21 Jan 2014 13:35:26 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/updating-jersey-2-in-glassfish-4/</guid>
      <description>&lt;p&gt;Different life-cycles of Jersey 2 and GlassFish 4 arise a question how to make sure that ones GlassFish instance contains always the latest version of Jersey. This question is even more important in case you don&amp;#8217;t want to download the nightly/promoted build every-time a new version of Jersey is released but you still want to use the latest and greatest Jersey.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Note: The script below is not compatible with Jersey 2.6 at the moment. I&amp;#8217;ll update it as soon as possible.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Managed JAX-RS Client</title>
      <link>https://blog.dejavu.sk/managed-jax-rs-client/</link>
      <pubDate>Thu, 16 Jan 2014 17:35:41 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/managed-jax-rs-client/</guid>
      <description>&lt;p&gt;Common use-case in web-application development is aggregating data from multiple resources, combining them together and returning them to the used as XML/JSON or as a web page. In Java world these (external) resources can be approached via standardized &lt;a href=&#34;https://jax-rs.github.io/apidocs/2.0.1/javax/ws/rs/client/Client.html&#34;&gt;Client&lt;/a&gt;s from JAX-RS 2.0. Jersey 2 application can use so-called managed client mechanism that brings a convenient way to create JAX-RS &lt;a href=&#34;https://jax-rs.github.io/apidocs/2.0.1/javax/ws/rs/client/Client.html&#34;&gt;clients&lt;/a&gt; and &lt;a href=&#34;https://jax-rs.github.io/apidocs/2.0.1/javax/ws/rs/client/WebTarget.html&#34;&gt;web targets&lt;/a&gt; for such resources.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Running Jersey 2 Applications on Heroku</title>
      <link>https://blog.dejavu.sk/running-jersey-2-applications-on-heroku/</link>
      <pubDate>Thu, 09 Jan 2014 13:50:32 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/running-jersey-2-applications-on-heroku/</guid>
      <description>&lt;p&gt;In this article we&amp;#8217;ll create a simple &lt;a href=&#34;https://jersey.github.io/&#34;&gt;Jersey&lt;/a&gt; application deploy it in &lt;a href=&#34;http://www.eclipse.org/jetty/&#34;&gt;Jetty&lt;/a&gt; servlet container and everything will be hosted on &lt;a href=&#34;http://heroku.com/&#34;&gt;Heroku&lt;/a&gt;.&lt;/p&gt;

&lt;h2 id=&#34;create-an-application&#34;&gt;Create an Application&lt;/h2&gt;

&lt;p&gt;To create a skeleton of Jersey 2 web-app that can be run on Heroku from the &lt;a href=&#34;https://github.com/jersey/jersey/tree/2.5.1/archetypes/jersey-heroku-webapp&#34;&gt;jersey-heroku-webapp&lt;/a&gt; archetype (available since Jersey 2.5), execute the following Maven command in the directory where you want the new project should be located:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre class=&#34;chroma&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;mvn archetype:generate -DarchetypeArtifactId&lt;span class=&#34;o&#34;&gt;=&lt;/span&gt;jersey-heroku-webapp &lt;span class=&#34;se&#34;&gt;\
&lt;/span&gt;&lt;span class=&#34;se&#34;&gt;&lt;/span&gt;    -DarchetypeGroupId&lt;span class=&#34;o&#34;&gt;=&lt;/span&gt;org.glassfish.jersey.archetypes -DinteractiveMode&lt;span class=&#34;o&#34;&gt;=&lt;/span&gt;&lt;span class=&#34;nb&#34;&gt;false&lt;/span&gt; &lt;span class=&#34;se&#34;&gt;\
&lt;/span&gt;&lt;span class=&#34;se&#34;&gt;&lt;/span&gt;    -DgroupId&lt;span class=&#34;o&#34;&gt;=&lt;/span&gt;com.example -DartifactId&lt;span class=&#34;o&#34;&gt;=&lt;/span&gt;simple-heroku-webapp -Dpackage&lt;span class=&#34;o&#34;&gt;=&lt;/span&gt;com.example &lt;span class=&#34;se&#34;&gt;\
&lt;/span&gt;&lt;span class=&#34;se&#34;&gt;&lt;/span&gt;    -DarchetypeVersion&lt;span class=&#34;o&#34;&gt;=&lt;/span&gt;&lt;span class=&#34;m&#34;&gt;2&lt;/span&gt;.5.1&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Adjust the &lt;code&gt;groupId&lt;/code&gt;, &lt;code&gt;package&lt;/code&gt; and/or &lt;code&gt;artifactId&lt;/code&gt; of your new web application project to your needs or, alternatively, you can change it by updating the new project &lt;code&gt;pom.xml&lt;/code&gt; once it gets generated.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Binding JAX-RS Providers to Resource Methods</title>
      <link>https://blog.dejavu.sk/binding-jax-rs-providers-to-resource-methods/</link>
      <pubDate>Wed, 08 Jan 2014 18:35:02 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/binding-jax-rs-providers-to-resource-methods/</guid>
      <description>&lt;p&gt;When you register providers (such as filters and interceptors) in your application they&amp;#8217;re associated and applied to each resource method by default. In other words they&amp;#8217;re bound globally. For most cases this approach is sufficient but sometimes, especially when you want to use your provider only with a few methods, it&amp;#8217;s not enough. JAX-RS 2.0 brings a solution for this situation: Name and Dynamic Binding.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Registering Resources and Providers in Jersey 2</title>
      <link>https://blog.dejavu.sk/registering-resources-and-providers-in-jersey-2/</link>
      <pubDate>Tue, 19 Nov 2013 09:35:26 +0000</pubDate>
      <author>michal@dejavu.sk (Michal Gajdoš)</author>
      <guid>https://blog.dejavu.sk/registering-resources-and-providers-in-jersey-2/</guid>
      <description>&lt;p&gt;There has been some confusion on &lt;a href=&#34;http://stackoverflow.com/&#34;&gt;StackOverflow&lt;/a&gt; lately about how to register JAX-RS resource classes and custom providers in Jersey 2. The main problem seemed to be finding and using correct properties and methods to configure a JAX-RS/Jersey application. In this article I&amp;#8217;d like to discuss 3 ways how to configure such an application properly.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>