• Home
  • Events
  • About
  • Interview with Antonio Goncalves about the past, present, and future of Java EE

    March 31st, 2011

    I got a chance to sit down and talk to Java Champion Antonio Goncalves about the past, present, and future of Java EE. I’ve been working for the last six months in a heavy EE/SOA stack, and it’s been interesting to see the advantages and disadvantages. I definitely come from the other side of the world where specifications aren’t seen as an inherent sign of quality, and frameworks not sanctioned by Sun/Oracle are not to be feared. It was fun to get his opinions about this stuff.

    The full interview is on the JetBrains Zone at DZone. We’re both JetBrains Academy Members and we’re slowly interviewing each other.

    P.S. This is the first post I’ve ever made that mentioned Java Enterprise Edition. I suspect the next time EE is mentioned will be in another few years 🙂

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    IntelliJ IDEA Static Analysis: Custom Rules with Structural Search & Replace

    March 29th, 2011

    Well, well, I made another screencast. This time I’m taking on IntelliJ IDEA code inspections, and writing your own static code analysis rule (and quick fix!) using Structural Search & Replace. Not bad for under 5 minutes.

    If you have any trouble viewing the video then perhaps you should watch it directly on the JetBrains site. And if you’re feeling generous, then clicky clicky to upvote at DZone.

    Check out these pages for more information on IDEA inspections: 

    Read these pages to learn more about Structural Search and Replace: 

    I’ve made a lot of screencasts and blog posts over the years. If you like this, then there are many ways to see the other stuff I’ve done: 

    Phew, that’s a lot of self-promotion 🙂

    Thanks for watching, and leave a comment! 

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    LEGO® Java (IV): Apache Camel, Spring and ElasticSearch

    March 24th, 2011

    If you don’t know it yet, this is the fourth part of a series about Apache Camel. The previous posts can be found here: first part, second part and third part.
    In this fourth article, we are going to show how to properly use the Spring framework in the sample application, while adding some extra functionality to it.

    Extracting RSS feeds

    If you remember what we have done so far, the sample application is capable of, given the URL of a web page, extract the text content of the body paragraphs. To make our application a little more powerful, let’s add some functionality to extract the contents of web pages listed in RSS feeds. To accomplish this, add a new class called “RssExtractorRoutes” with the following content:

    This simple route uses the Camel “rss” endpoint to access the RSS feed from BBC news, transforms the content with the rss “marshaller” and then extracts the article links by mean of XPath. As last step, it routes the extracted links to our already existing “page extractor” route.

    Because we have added a new component, we need to add a new dependency to our Maven pom file:

    We need to apply this new route builder to the camel context and we will also eliminate the code used to send a URL to the extractor route. For this, adjust the code of the main class like this:

    If you run the application, you should see in the log entries that all the articles present in the feed are routed to the extractor and afterward, the extracted paragraphs get lost in the space.
    Let’s do something useful with them and store them in a search index. For that, we could use the Apache Lucene “endpoint” that Camel already offers, but instead of this, let’s use an Elastic Search node and explore how to configure and manage the life cycle of an Elastic Search instance by mean of Spring.
    We need a new Elastic Search “bean” class with this content:

    This class is a little bit more complicated than what we have done until now, but what it basically does is creating an elastic search “local” node, offering a method to index a content under a certain structure and another method to search for a text within the previously indexed contents. Some aspects of the bean are also configurable: the name of the index, the type of the content, the index field where the content will be stored and the number of returned search results.

    To use it in the RSS extractor, adjust the code like this:

    And finally, add the Eleasctic Search dependency to the Maven pom file:

    If you paid attention to the changes in the RSS extractor route builder, you should have noticed that now we have created an static instance and configured it in an static way. This is not completely bad but it has some disadvantages and one problem:

    • If we would like to test this route, we cannot supply a different implementation of the bean.
    • In case that we want to change the name of the index, the name of the field or any other configurable value, we have to do it in the code and recompile the application.
    • When the bean is created, the Elastic Serach node is correctly initialized but, when is the “close” method called to shutdown the instance properly? This is, of course, the problem I mentioned.

    To correct these issues, we can take advantage of the Spring framework and the excellent Spring support that Camel offers.

    First of all, let’s include the Spring dependency in our Maven pom file:

    Now, let’s create a file named “camel-context.xml” under “resources/META-INF/spring” with this content:

    And as last step, adpat the “main” class like this:

    If you run the application now, the only difference that you should notice is that the application does not stop after 100 seconds.
    By using the “Main” class that the Camel Spring support offers, we are starting the Spring container and looking for Spring configuration files that will be automatically loaded and used to configure the Spring container. Such files should have the extension “.xml” and be placed under the “META-INF/spring” package.
    The “enableHangupSupport” call instructs the application to listen to “ctrl-c” key strokes and, before terminating, to stop properly the Spring container.

    Now that we have configured Spring, let’s move the Elastic Search bean into the Spring beans file (“camel-context.xml”):

    And adjust the Rss extractor route like this:

    What we have done with these changes is: letting Spring instantiate and configure an unique instance of our bean (a singleton) and instructing Spring to invoke the “close” method whenever the container is destroyed (what happens when the user presses “ctrl-c” on the shell).
    Because now the bean will be searched by name in the Camel bean registry (the Spring container in our case), in order to substitute the bean implementation with another one, it would be enough to use a different spring configuration file or to overwrite the bean definition by loading a second beans file with a new definition of the same bean. This is a convenient thing if, for example, we want to use mocks for testing or want to have different search services.
    To avoid having to edit the spring beans file in order to change the Elastic Search bean configuration values, we can use a spring “PropertyPlaceHolderConfigurer” and create a properties file in the classpath (we will store it within the application and under the “resources” directory):

    With this configuration change, Spring searches in the top-level package for a properties file with the name “elasticsearch.properties” and resolves the “${}” values against it, giving us more flexibility to alter these values without affecting the application.

    To end this article doing something useful with our indexed contents, let’s create a search web service that allows us executing a search query and displays a web page with the matching article links.

    For this, create a new route builder:

    Notice that now, it is not necessary to add explicitly the new route builders to the camel context due to the fact that Spring will instantiate the context and look for route builders under the package “com.canoo.camel” (as configured in “camel-context.xml”).

    We need also to extend the functionality of the class “HtmlFormatterBean” as follows:

    Please notice that, because now this bean has more than only one method, you will also need to specify the method to call in every bean reference within the application.

    To test our new search service, start the application and point to the URL: http://localhost:8080/search?query=news. If some of the indexed articles contains the word “news”, you should see a list with their links.

    The camel ride ends here. I hope that you enjoyed reading the articles as much as I enjoyed writing them. I also hope that it has helped you in getting to know how Camel works and that you can found some use cases where to apply this slightly different way of building integration applications.

    The code of this fourth part is here, to execute the application just unzip the file, change to the directory where the pom file is and type ‘mvn compile exec:java -Dexec.mainClass=”com.canoo.camel.Part4″‘ in the console.

    Hope to see you soon in another post!

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    LEGO® Java (III): Apache Camel Routing and Testing

    March 21st, 2011

    In the first part of this series we saw the basics of Apache Camel routing and contexts, and in the second part we learned about error handling and web services. Today, in the third part, we will add more functionality to our Camel extractor application and we will do it in a modular way. We will also have a look at how to effectively test our functionality.

    Improving our HTML cleaner

    In a perfect world, our application would never need any bug fixing or improvements. But because we know that the world is not perfect, it happens often that we discover limitations in our applications and we must make some improvements to correct them. If you try extracting a URL from DZone (“http://www.dzone.com“) with the application, then you will see an exception in the console indicating that “TagSoup” cannot fix a problem related with the DOM structure (TagSoup is used by the “TidyMarkup” marshaller to clean our HTML) . We could configure “TagSoup” differently, but instead, let’s assume that we have to use another tool to do the work. In this case, we are going to use “HtmlCleaner” and we’ll integrate it into our application using a Java “bean”.

    Add a new Java class to your project containing this code:

    This class uses “HtmlCleaner” and therefore requires the following Maven dependency:

    We could add more steps to our extractor route, but it is starting to become a little verbose and unclear. So instead, let’s better add a new route for our improved html functionality:

    And replace the tidy markup marshalling with a detour through the new created route:

    To get this route created in the Camel context, adjust the main method in the “main” class like this:

    As you can see, in the new “HtmlImproverRoutes” class, we have applied an “onException” clause to detect when “TagSoup” html parsing fails. The difference this time is that we no longer use “handled” to end the processing of the message (as we were in the previous case, where we redelivered the message to the same endpoint). This time, we use “continued” to instruct Camel to send the message through the error handling steps and then continue processing from where the error occurred.

    We have also performed some changes in the page extractor route. First, we have activated the “streamcaching” to avoid exceptions when the inputstream returned by the “http” extractor is consumed several times. Also, after setting the URL to extract in the “CamelHttpUri” header, we are now resetting the body of the message sent to the “http” endpoint. If not done, the body causes some problems when accessing certain web servers because the endpoint uses the HTTP POST method (used when the body is not empty) instead of the more suitable GET. The last change is to route the result of the “http” endpoint to the newly created route. To enforce a little bit more the sequential character of this process, we have applied the “pipeline” enterprise integration pattern instead of the default “to” construct of the Java DSL.

    If you run the application now, you should see how it detects the parsing error and continues the processing of the content using “HtmlCleaner” instead of “TagSoup”.
    This functionality (the “html improver”) has been moved from the initial route builder to an specific one, what contributes a to better modularization and re-usability of the code in Apache Camel. Because the endpoints are named with string constants and now the strings: “direct:page_extractor” and “direct:html_improver” appear in different files, it is usually a good practice to extract these values as constants in the route builders. This, makes more difficult to get the code broken in case of a change in the endpoint name or type, and it plays the role of an interface.

    Testing the routes

    Apache Camel offers mock testing support for testing the routes in an effective way. But, while in most of the examples out there, a mock endpoint is added explicitly to the route, let’s see how to do it in a programmatic way to avoid altering the route that we want to test.

    First, add these two dependencies to your Maven pom file:

    Second, add this class with some run-time support for mock testing:

    Third, create a test based on this approach:

    If you run this test, you should see a nice green bar (or the like) indicating that the test passed. Please, note the static import for “HTML_IMPROVER_EP”, which contains the name of the endpoint, extracted as a constant (as explained before).
    As of Apache Camel 2.7, some advice functionality has been added to mock testing making possible introduce the mock endpoints in an aspect oriented way.

    As summary of this third part, we have shown how to organize the project routes using several route builders and how you can use mocks to test and, therefore, improve the quality and stability of your Apache Camel project.

    In the next Camel “ride”, we will introduce the Spring framework and unveil what to do with the extracted data. Hope to see you there!

    Source code of this third part for download. To run the application, just expand the file, change to the folder where the pom file is and execute: ‘mvn compile exec:java -Dexec.mainClass=”com.canoo.camel.Part3″‘

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    LEGO® Java (II): Apache Camel Error Handling, Java Beans and Web Services

    March 16th, 2011

    The first part of this series showed you how to start a Camel context, write a simple route, and then stop the context. You’re starting to see how to do some things in the “Camel way”. Let’s go for a second Camel ride and see how far we can go.

    Error Handling in Camel

    As promised, we’re going to add some error handling to our route and see how to deal with the usual problems. To see what I mean, go to the main class from the first article and substitute the URL of the W3C site (“http://www.w3.org”) with this alternate version: “http://www.w3c.org”. Run the application once again and now you should see the application failing to retrieve the page with a “HttpOperationFailedException” error. The problem is that the new URL is a redirect to the old one, but our route doesn’t know how to deal with this.

    If you have a look at the “http” endpoint documentation, you will notice how flexible and configurable it is. You’ll also see that some HTTP response codes are thrown as exceptions by default. In plain Java, you can instruct a connection to follow redirections in a transparent way. With the “http” configuration options, we could probably do the same by configuring the “HttpClient” and modifying the “http” endpoint it uses internally. Instead of this, let’s learn some error handling strategies in Camel.

    We want some sepcial logic for when an “HttpOperationFailedException” is thrown: we should grab the redirection location present in the exception and retry the request. For this, modify the code of the extractor route in the following way:

    If you re-run the application now, there is no exception in the console and a new log entry indicates the URL failed and fetching was retried using the redirection location.

    What we introduced at the beginning of the route is an “onException” clause that, in case of an exception of the given type (or types) being thrown within this route, executes the steps contained in the clause. Please, notice the “end” method call separating what should be done in case of such an exception from the normal route steps.

    In the error handling code, the first action we take is to log some information about what is about to happen. Then, we mark that the exception has already been handled and, after setting in the body the relocation URL, we send the message back to the endpoint to be retried.

    The “onException” clause has a lot of options and the topic “error handling” is very well described in the chapter 5 from Camel in Action.

    Fine grained logic with Java beans

    If you need functionality that you cannot express with the Camel Java DSL, then using Java or any other languages supported in Camel is pretty easy. One option is to use the “process” method from the Java DSL. This method accepts a “Processor” parameter in through which you have access to the complete message (“Exchange” in Camel). While this seems pretty easy and practical, you will be tempted to pollute your routes with anonymous Java classes containing logic. You should also notice that, following this approach, you need to do almost the same mapping every time to access the body of the “in” exchange and set the result back into it. Another drawback of anonymous classes is that you cannot easily test the logic on them and, if you want to test them, you must create top-level classes that are both more complicated than simple Java beans and coupled to the Camel API through the “Exchange” class.

    A better option is to use plain Java classes (“beans”) with the least possible logic, and let Camel do the default mapping using the signature of the methods invoked. If mapping the body of the exchange is not enough, you can use annotations to get access to some other parts of the exchange or even the whole exchange in your bean methods (this time relying on the Camel API because of the specific annotations).

    To see the problem that we want to solve with this option, try now the application with the following URL: “http://www.w3.org/notfound”. It does not exist and you will notice that Camel retries the operation with an empty URL obtained from the redirect location property in the “HttpOperationFailedException” exception. The application fails with a “UnknowHostException” produced by the now empty URL.
    Using the “bean” option, let’s see how to distinguish between any HTTP response code and a HTTP redirection code and avoid retrying the fetch unnecessarily. We can read this information by inspecting the “HttpOperationFailedException” properties. For this, create a class named “HttpErrorHelperBean” with the following content:

    And modify the route introducing an “onWhen” clause after the “onException” in the following way:

    If you try once again the non-existing URL, you will see that now the thrown exception is the initial “HttpOperationFailedException” with a response code 404. This exception does not match the condition in our bean and therefore the error handling has not been applied.

    Did you also notice something strange in the “bean” method construction? We indicated no method name or bean instance, but Camel seems to have instantiated the class and called the method we expected. What Camel does is try to find an instance of the passed class in the “registry” or instantiate the class if it could not find an instance (for this, the class needs to have a default no arguments constructor). For guessing which method to call, Camel applies a matching algorithm based on the method signature and the message payload type. If you want to know how it exactly works, you can find a detailed description in the chapter 4.4 of Camel in Action.

    Exposing our extractor service as a Web service

    Now let’s expose our logic as a web service. But first let me clarify: the kind of Web service we expose here is a plain and simple HTTP&HTML service (not a REST or a SOAP based Web Service).

    To implement a web service, create a class named “HtmlFormatterBean” with the following code:

    Add a new dependency in the Maven pom file:

    And modify the route builder adding this second route within the “configure” method:

    Now, if you run the application and access the URL: “http://localhost:8080/page_extractor?extractUrl=http://www.w3c.org” from your web browser, then you should see a minimal HTML page containing a list with the extracted contents (you may need to increase the 10 seconds wait time before the context shuts down).

    Wow! It was a short route but it had a big impact! By using the “jetty” endpoint in this way, Camel creates an embedded instance of the Jetty web server and starts listening to all the local IP interfaces, publishing the endpoint under the “page_extractor” web application context (“http://0.0.0.0:8080/page_extractor”). When you access this URL from a web browser adding the parameter “extractUrl=http://www.w3c.org”, the route creates a new message populating its headers with the different URL parameters and their values, and routes the message to the next step which happens to be the page extractor.

    To send the request to our page extractor, we have to first set the value of the message body to the URL that we want to extract (which has been saved as a message header under the name of the HTTP parameter: “extractUrl”). To accomplish this, use the “setBody” method and, after this, the modified message is routed to the page extractor. When it comes back from the extractor, its body contains a list with the text chunks. The last step is to translate this payload into HTML, which is returned as a response to the HTTP request received in the “jetty” endpoint. If you do not like return HTML then instead of using a Java class you could also use the “velocity” Camel component.

    This is the end of the second part of this series. In the next one, we introduce new functionality in a modular way and show how to test with the Camel testing framework.

    I hope that you enjoyed the reading and that you come back for a new Camel ride in the next part.

    Update: added source code for download. To run the application, just expand the file, change to the folder where the pom file is and execute: ‘mvn compile exec:java -Dexec.mainClass=”com.canoo.camel.Part2″‘

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    css.php