The Holy Java

Building the right thing, building it right, fast

Archive for the ‘j2ee’ Category

What Is CDI, How Does It Relate to @EJB And Spring?

Posted by Jakub Holý on November 9, 2011

A brief overview of dependency injection in Java EE, the difference between @Resource/@EJB and @Inject, and how does that all relate to Spring – mostly in the form of links.

Context Dependency Injection (CDI, JSR 299) is a part of Java EE 6 Web Profile and itself builds on Dependency Injection for Java (JSR 330), which introduces @Inject, @Named etc. While JSR 330 is for DI only and is implemented e.g. by Guice and Spring, CDI adds various EE stuff such as @RequestScoped, interceptors/decorators, producers, eventing and a base for integration with JSF, EJBs etc. Java EE components such as EJBs have been redefined to build on top of CDI (=> @Stateless is now a CDI managed bean with additional services).

A key part of CDI aside of its DI capabilities is its awarness of bean contexts and the management of bean lifecycle and dependencies within those contexts (such as @RequestScoped or @ConversationScoped).

CDI is extensible – you can define new context scopes, drop-in interceptors and decorators, make other beans (e.g. from Spring) available for CDI,… .

Resources to check: Read the rest of this entry »

Advertisements

Posted in j2ee | Tagged: , | Comments Off on What Is CDI, How Does It Relate to @EJB And Spring?

Most interesting links of October

Posted by Jakub Holý on October 31, 2011

Recommended Readings

  • Steve Yegge’s Execution in the Kingdom of Nouns – I guess you’ve already read this one but if not – it is a well-written and amusing post about why not having functions as first class citizens in Java causes developers to suffer. Highly recommended.
  • Reply to Comparing Java Web Frameworks – a very nice and objective response to a recent blog summarizing a JavaOne presentation about the “top 4” web frameworks. The author argues that based on number of resources such as job trends, StackOverflow questions etc. (however data from each of them on its own is biased in a way) JSF is a very popular framework – and rightly so for even though JSF 1 sucked, JSF 2 is really good (and still improving). Interesting links too (such as What’s new in JSF 2.2?). Corresponds to my belief that GWT and JSF are some of the best frameworks available.
  • Using @Nullable – use javax.annotation.Nullable with Guava’s checkNotNull to fail fast when an unexpected null appeares in method arguments
  • JavaOne 2011: Migrating Spring Applications to Java EE 6 (slides) – nice (and visually attractive) comparison of JavaEE and Spring and proposal of a migration path. It’s fun and worthy to see.
  • xUnitPatterns – one of the elementary sources that anybody interested in testing should read through. Not only it explains all the basic concepts (mocks, stubs, fakes,…) but also many pitfalls to avoid (various test smells such as fragile tests due to Data Sensitivity, Behavior Sensitivity, Overspecified Software [due to mocks] etc.), various strategies (such as for fixture setup), and general testing principles. The materials on the site were turned into the book xUnit Test Patterns: Refactoring Test Code (2007), which is more up-to-date and thus a better source.
  • Eclipse tip: Automatically insert at correct position: Semicolon, Braces – in “while(|)” type “true {” to get “while(true) {|” i.e. the ‘{‘ is moved to the end where it belongs, the same works for ‘;’
  • Google Test Analytics – Now in Open Source – introduces Google’s Attributes-Components-Capabilities (ACC) application intended to replace laborous and write&forget test plans with something much more usable and quicker to set up, it’s both a methodology for determining what needs to be tested and a tool for doing so and tracking the progress and high-risk areas (based not just on estimates but also actual data such as test coverage and bug count). The article is a good and brief introduction, you may also want to check a live hosted version and a little more detailed explanation on the project’s wiki.
  • JSF and Facelets: build-time vs. render-time (component) tags (2007) – avoid mixing them incorrectly
  • StackOverflow: What are the main disadvantages of Java Server Faces 2.0? Answer: The negative image of JSF comes from 1.x, JSF 2 is very good (and 2.2 is expected to be just perfect :-)). Nice summary and JSF history review.
  • Ola Bini: JavaScript in the small – best practices for projects using partly JavaScript – the module pattern (code in the body of an immediately executed function not to polute the global var namespace), handling module dependencies with st. like RequireJS, keeping JS out of HTML, functions generating functions for more readable code, use of many anonymous functions e.g. as a kind of named parameters, testing, open questions.

Talks

  • Kent Beck’s JavaZone talk Software G Forces: The Effects of Acceleration is absolutely worth the 1h time. Kent describes how the development process, practices and partly the whole organization have to change as you go from annual to monthly to weekly, daily, hourly deployments. What is a best practice for one of these speeds becomes an impediment for another one – so know where you are. You can get an older version of the slides and there is also a detailed summary of the talk from another event.
  • Rich Hickey: Simple Made Easy – Rich, the author of Clojure, argues very well that we should primarily care for our tools, constructs and artifacts to be “simple”, i.e. with minimal complexity, rather than “easy” i.e. not far from our current understanding and skill set. Simple means minimal interleaving – one concept, one task, one role, minimal mixing of who, what, how, when, where, why. While easy tools may make us start faster, only simplicity will make it possible to keep going fast because (growing) comlexity is the main cause of slowness.  And simplicity is a choice – we can create the same programs we do today with the tools of complexity with drastically simpler tools. Rich of course explains what, according to him, are complex tools and their simple(r) alternatives – see below. The start of the 1h talk is little slow but it is worth the time. I agree with him that we should much more thing about the simplicity/complexity of the things we use and create rather than easiness (think ORM).
    Read also Uncle Bob’s affirmative reaction (“All too often we do what’s easy, at the expense of what’s simple. And so we make a mess. […] doing what is simple as opposed to what is easy is one of the defining characteristics of a software craftsman.”).

Random Notes from Rich’s Simple Made Easy Talk:

There are also better notes by Alex Baranosky and you may want to check a follow-up discussion with some Rich’s answers.

The complex vs. simple toolkit (around 0:31):

COMPLEXITY                             SIMPLICITY
State, objects                            Values
Methods                                   Functions, namespaces
vars                                          Managed refs
Inheritance, switch, matching  Polymorphism a la carte
Syntax                                      Data
Imperative loops, fold              Set functions
Actors                                      Queues
ORM                                         Declarative data manipulation
Conditionals                             Rules
Inconsistency                            Consistency

What each of the complexity constructs mixes (complects) together

CONSTRUCT                        COMPLECTS (MIXES)
State, objects – everything that touches it (for state complects time and value)
Methods – function and state, namespaces (2 classes, same m. name)
Syntax – Meaning, order
Inheritance – Types (ancestors, child)
Switch/matching – Multiple who/what pairs (1.decide who, 2.do what ?)
var(iable)s – Value, time
Imperative loops, fold – what/how (fold – order)
Actors – what/who
ORM – OMG 🙂
Conditionals – Why, rest of program (rules what program does are intertw. with the structure and order of the program, distributed all over it)

HE SIMPLICITY TOOLKIT (around 0:44)
CONSTRUCT            GET IT IVA…
Values – Final, persistent collections
Functions – a.k.a. stateless methods
Namespaces – Language support
Data – Maps, arrays, sets, XML, JSON etc.
Polymorphism a la carte – Protocols, Haskell type classes
Managed refs – Clojure/Haskell refs (compose time and value , not mix)
Set functions – Libraries
Queues – Libraries
Declarative data manipulation – SQL/LINQ/Datalog
Rules – Libraries, Prolog
Consistency – Transactions, values

True abstraction isn’t hiding complexity but drawing things away – along one of the dimensions of who, what, when, where, why [policy&rules of the app.], how.
Abstraction => there are things I don’t need – and don’t want – to know.
Why – do explore rules and declarative logic systems.
When, where – when obj. A communicates with obj. B. => put a queue in between them so that A doesn’t need to know where B is; you should use Qs extensively.

Links to Keep

  • Incredibly Useful CSS Snippets –  “a list of CSS snippets that will help you minimize headaches, frustration and save your time while writing css” – few float resets, targetting specific browsers & browser hacks, cross-rowser transparency/min height/drop shadow, Google Font API, link styled by file type,

DevOps: Tools and libraries for system monitoring and (time series) data plotting

  • Hyperic SIGAR API – open-source library that unifies collection of system-related metrics such as memory, CPU load, processes, file system metrics across most common operating systems
  • rrd4j – Java clone of the famous RRDTool, which stores, aggregates and plots time-series data (RRD = round-robin database, i.e. keeps only a given number of samples and thus has a fixed size)
  • JRDS “is performance collector, much like cacti or munins”, uses rrd4j. The documentation could be better and it seems to be just a one man project but it might be interesting to look at it.

Clojure Corner

  • Alex Miller: Real world Clojure – a summary of experiences with using Clojure in enterprise data integration and analytics products at Revelytix, since early 2011 with a team of 5-10 devs. Some observations: Clojure code is 1-2 order of magnitude smaller than Java. It might take more time to learn than Java but not much. Clojure tooling is acceptable, Emacs is still the best. Debugging tools are unsurprisingly quite inferior to those for Java. Java profiling tools work but it may be hard to interpret the results. “[..]  I’ve come to appreciate the data-centric approach to building software.” Performance has been generally good so far.
  • Article series Real World Clojure at World Singles – the series focuses on various aspects of using Clojure and how it was used to solve particular problems at a large dating site that starting to migrate to it in 2010. Very interesting. F. ex. XML generation, multi-environment configuration, tooling (“If Eclipse is your drug of choice, CCW [Counter ClockWise] will be a good way to work with Clojure.”, “Clojure tooling is still pretty young [..]  – but given how much simpler Clojure is than most languages, you may not miss various features as much as you might expect!”)
  • StackOverflow: Comparing Clojure books – Programming Clojure, Clojure in Action, The Joy of Clojure, Practical Clojure – which one to pick? A pretty good comparison.
  • Clojure is a Get Stuff Done Language – experience report – “For all that people think of Clojure as a “hard” “propeller-head” language, it’s actually designed right from the start not for intellectual purity, but developer productivity.”

Posted in eclipse, General, j2ee, Languages, Testing, Top links of month | Tagged: , , , , , , , , , , | 3 Comments »

JSF: Beware the Difference Between Build-Time and Render-Time Tags in Facelets

Posted by Jakub Holý on October 28, 2011

This is to remind me that I should never ever forget the cruical difference between build-time-only tags (i.e. having tag handlers only) and render-time tags that have corresponding components. The problem is that their lifespan is different and thus mixing them can easily lead to nasty surprises. Build time tags are used to modify the building of a component tree and have no effect during its rendering, where only the components participate.

A typical mistake is the nesting of ui:include (build-time) inside ui:repeat (render-time) using the var that ui:repeat declares: Read the rest of this entry »

Posted in j2ee, Languages | Tagged: , , , | Comments Off on JSF: Beware the Difference Between Build-Time and Render-Time Tags in Facelets

Intro: Java Webapp Monitoring with Hyperic HQ + How to Alert on Too Many Errors in Logs

Posted by Jakub Holý on October 17, 2011

This post describes how to set up the Java-based open source monitoring tool Hyperic HQ to monitor application server error logs and send a single warning e-mail when there are more of them than a threshold. In the previous post Aggregating Error Logs to Send a Warning Email When Too Many of Them – Log4j, Stat4j, SMTPAppender we’ve seen how to achieve that programatically while this solution is just about configuration. We will also see a little what else (a lot!) Hyperic can do for you and what the impressions after a short experimentation with it are. Read the rest of this entry »

Posted in j2ee, Tools | Tagged: , , , | Comments Off on Intro: Java Webapp Monitoring with Hyperic HQ + How to Alert on Too Many Errors in Logs

Aggregating Error Logs to Send a Warning Email When Too Many of Them – Log4j, Stat4j, SMTPAppender

Posted by Jakub Holý on October 15, 2011

Our development team wanted to get notified as soon as something goes wrong in our production system, a critical Java web application serving thousands of customers daily. The idea was to let it send us an email when there are too many errors, indicating usually a problem with a database, an external web service, or something really bad with the application itself. In this post I want to present a simple solution we have implemented using a custom Log4J Appender based on Stats4j and an SMTPAppender (which is more difficult to configure and troubleshoot than you might expect) and in the following post I explore how to achieve the same effect with the open-source Hyperic HQ monitoring SW.

Read the rest of this entry »

Posted in j2ee, Tools | Tagged: , , , | 1 Comment »

Inspect Your Webapp in a Live Environment Interactively with GroovyConsole

Posted by Jakub Holý on September 27, 2011

Have you ever needed to check the state of your webapp’s objects/Session/.. to find out why the hell something doesn’t work or have you had to learn a weird 3rd party API that is only available on the server? Then you were doomed … until the publication of GroovyConsole. JeeUtils GroovyConsole provides a JSP page that let you execute any Groovy/Java code on the server side, with access to server-side objects like request/session etc.

Here is a screenshot of my recent troubleshooting session, where I needed to check the state of a session-scoped JSF Managed Bean:

Read the rest of this entry »

Posted in j2ee, Languages, Tools | Tagged: , , , , | Comments Off on Inspect Your Webapp in a Live Environment Interactively with GroovyConsole

Experiencing JSF 1.2: Good but Needs a Framework

Posted by Jakub Holý on July 30, 2011

I’ve got an opportunity to experiment with JSF 1.2 while preparing a lecture about DbUnit Express and test webapp for JSF EL Validator. Same as JSF 1.1, it’s much easier to use than the low level, too HTTP-ish servlets but still it is not flexible enough and usable per se, it is absolutely necessary to use a decent framework (such as Rich or ICE Faces) to be really productive. Automatic value and method binding is cool but not sufficient.

For example forcing dataTable to get filtered when you change selection in a select list was rather non-trivial and making the table sortable by every column required quite lot of work and if I wanted to have that for every table, I’d need to develop framework of my own. Of course with various JSF component libraries you get such things out of the box but still JSF 1.2 is little to rigid, for example methods that could take parameters (which came in JSF 2.0) would make things a lot simpler.

I’ve also considered using business objects – such as EJBs – directly as JSF backing beans but I feel that in this version it might be suitable only for small applications (where the overhead of concern separation doesn’t pay off) or  some special ones. The problem is that even though backing beans are POJOs, JSF still forces them to a rather specific shape, which should be confined to the web layer  – such as having action methods that take no parameters and return an indication of which view to dislay next.

I would very much like to experiment with and compare other interesting frameworks such as Play!, Grails, and GWT (and given that I’ve finally got to learning Clojure, perhaps also Compojure), though I likely won’t have time for that. If I do, you will come to know 🙂

Related posts

Posted in j2ee, Languages | Tagged: , , , | 4 Comments »

Validating JSF EL Expressions in JSF Pages with static-jsfexpression-validator

Posted by Jakub Holý on June 22, 2011

Update: Version 1.0 was released in March 2012
Update: Version 0.9.9 with finished basic support for Facelets
(autodetection of annotated beans, handling of ui:repeat) is available
Update: Version 0.9.7 with experimental Facelets support and a fix of method binding validation released in Nov. (Not mentioning 0.9.5 and .6.) Always check the latest version available! The text below would need to be updated for the new API, which will be done by the end of 2011.
Update: Version 0.9.3 with new group/artifactId released
on 7/25 including native support for JSF 1.2 (reflected below in the pom snippet).
Update: Version 0.9.4 with function tolerance for JSF 1.2 released on 7/28 (it doesn’t check functions are OK but checks their parameters etc.)

static-jsfexpression-validator is utility for verifying that EL expressions in JSF pages, such as #{bean.property}, are correct, that means that they don’t reference undefined managed beans and nonexistent getters or action methods. The purpose is to make JSF-based web applications safer to refactor as the change of a method name will lead to the detection of an invalid expression without need for extensive manual UI tests. It can be run statically, for example from a test. Currently it builds on the JSF implementation v. 1.1 but can be in few hours (or days) modified to support newer version of JSF. How does it work?

Read the rest of this entry »

Posted in j2ee, Languages, Tools | Tagged: , , | 3 Comments »

Hacking Jasper to Get Object Model of a JSP Page

Posted by Jakub Holý on June 10, 2011

To perform some checks and statistical analysis on my JSPs I needed a DOM-like, hierarchical model of elements contained in them. But parsing JSP pages isn’t trivial and is best left to a tool that excels in it – the Jasper JSP compiler used by Tomcat, Jetty, GlassFish and likely also by all others. There is an easy way to tweak it to produce whatever output you need nad to transform a JSP into whatever form you want, including an object model of the page:

  1. Define a Node.Visitor subclass for handling the nodes (tags etc.) of a JSP
  2. Write a simple subclass of Compiler, overriding its generateJava() to invoke the visitor
  3. Subclass the compiler executor JspC overriding its method getCompilerClassName() to return the class of the Compiler of yours

Let’s see the code.

Read the rest of this entry »

Posted in j2ee, Languages, Tools | Tagged: , , , , | 1 Comment »

Version hell with JSFUnit, Arquillian, and (embedded) Glassfish and other containers

Posted by Jakub Holý on June 7, 2011

JSFUnit and the JBoss Arquillian test framework for JavaEE look very promissing, but according to my experience there are good reasons why they are only beta and alpha versions. May be you can get them working but you must pick the right version of each dependency – for many things change between individual versions at this point – and be lucky to hit one of the “happy paths”. At the end I nearly got JSFUnit 1.0.0.Beta1 running with Arquillian 10.0.0.Alpha4 and glassfish-embedded 3.0.1 but failed to deploy due to a strange parse exception of an arquillian’s web fragment. I record this failure to help those who are struggling with this too.

There are the following fatal constraints:

Read the rest of this entry »

Posted in j2ee, Languages, Testing | Tagged: | 2 Comments »