Adam Bien's Weblog

Session video: "JavaEE ...And The Bloat Is Gone at InfoShare" in Gdansk. This time no live coding, just slides :-)

See you at Java EE Workshops at MUC Airport, contents of the video are also covered at the Architecture Day!

See also other screencasts at: http://tv.adam-bien.com or subscribe to http://www.youtube.com/user/bienadam.

Posted at 07:51AM Jun 18, 2013 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices |  Comments[1]  | Views/Hits: 697

A book about rethinking Java EE Patterns

The JavaMagazine article: Integrating JavaFX Scene Builder Into Enterprise Applications discusses a pragmatic integration of JavaFX Scene Builder into the "Enterprise Application Workflow". DI is used to integrate backend services and composition of visually created views.

See also:

1. http://afterburner.adam-bien.com
2. https://github.com/AdamBien/airhacks-control

See you at Java EE Workshops at MUC Airport. The material from the article is going to be also covered at the JavaEE UI day!

Posted at 11:04AM Jun 14, 2013 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices |  Comments[0]  | Views/Hits: 2053

A book about rethinking Java EE Patterns

Glassfish v4 (the "Killer Appserver") is available for download

The glassfish.org website was redesigned as well. It looks clean and fresh.

I'm using Glassfish v4 for a while in daily development--it looks promising. Glassfish v4 also ships with NetBeans (JavaEE). With NetBeans and Glassfish you will get the most efficient JavaEE 7 environment to start (double click, wait 2 minutes) and to develop your applications (everything you need comes out-of-the-box--without any plugin hell).

See you at Java EE Workshops at MUC Airport--I will use Glassfish v4 for live hacking!

Posted at 10:05AM Jun 13, 2013 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices |  Comments[0]  | Views/Hits: 1195

A book about rethinking Java EE Patterns

A session about JavaEE, JDD Conference 2012

See also other screencasts at: http://tv.adam-bien.com or subscribe to http://www.youtube.com/user/bienadam.

Let's do it together at Java EE Workshops at MUC Airport:-).

Posted at 10:54AM Jun 09, 2013 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices |  Comments[0]  | Views/Hits: 1412

A book about rethinking Java EE Patterns

JavaEE 6 APIs in Maven central were only usable for compiling. Any attempt to load the classes from

<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-web-api</artifactId>
    <version>6.0</version>
    <scope>provided</scope>
</dependency>

java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/persistence/LockModeType
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)

The official Java EE 7 APIs do not have that problem any more:

   <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <version>7.0</version>
            <scope>provided</scope>
        </dependency>

When I spotted the "crippled" dependency in JavaEE 6 projects, I always asked "Do you write Unit Tests?". "Yes" answers were not honest. Now Java EE 7 killed my litmus tests :-)

The whole example with workaround was checked into http://kenai.com/projects/javaee-patterns The name of the project is: MavenUnitTestWithCrippledAPI. Just increase the dependency version to 7.0 and the unit tests should pass without any workarounds needed.

See you at Java EE Workshops at MUC Airport!

Posted at 09:15AM Jun 07, 2013 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices |  Comments[0]  | Views/Hits: 1487

A book about rethinking Java EE Patterns

1. Free Hacking night:11.06.2013, Utrecht JavaEE 7 Meets HTML 5 and AngularJS
2. Workshops: 24.06-26.06.13, Munich Java EE Summit
3. Conference: JayDay, 02.07.2013, Munich Nothing Compares To …Java EE 7
4. Jug Session: 02.07.2013, Nürnberg JavaEE 7 And Why There Is No More Room For Overengineering (Livehacking)
5. JavaEE Tribe Gathering :-) 22.7-26.7.2013 Modular Java EE 7 Workshops--Airhacks From "absolute beginning" over JavaEE 7 architectures to User Interfaces and HTML 5

See you at Java EE Workshops at MUC Airport!

Posted at 10:51AM Jun 05, 2013 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices |  Comments[0]  | Views/Hits: 2045

A book about rethinking Java EE Patterns

A field denoted with the javax.persistence.Version annotation represents the state of the database at read (select) time. At the end of transaction the actual value of the entity is compared with the current value in the database and the entity is only going to be written back to the database in case both values are matching. If both are not equal the update "fails" (no rows are going to be updated) and javax.persistence.OptimisticLockException is thrown at the end of transactions. The unchecked OptimisticLockException causes transaction's rollback.

@Entity
public class SomeEntity {

    @Id
    private String name;

    private String description;

    @Version
    private long version;

Each database write operation also changes the version column in the DB, entity manipulations on the other hand, do not change the @Version JPA-entity field. Optimistic locking effectively prevents overriding changed columns in the database with stale values.

An occurrence of OptimisticLockException usually is an indicator of "process bottlenecks". Several users compete for the same data set, the first update will succeed, all other attempts will raise exceptions. This is very similar to merge conflicts in a source code management tool like svn, git or hg. Although there is a strategy to automatically resolve conflicts called "Override and Commit", it is not considered as best practice.

The only feasible strategy in the SCM case is manual merging and testing. Use cases in enterprise applications have a more narrow scope, so you could choose from several strategies:

1. First update wins
2. Last update wins
3. Manual merging

Each choice has a big impact on the business logic, so domain experts, end users or someone with business knowledge needs to be involved. Handling javax.persistence.OptimisticLockException generically (with e.g. repeating and reloading) is only viable for simple technical use cases (e.g. primary key generation).

[See also an in-depth discussion in the "Real World Java EE Patterns--Rethinking Best Practices" book (Second Iteration, "Green Book"), page 21 in, chapter "Locking for Consistency"]

See you at Java EE Workshops at MUC Airport (particularly the Effective and Architecture Days)!

Thanks Johny Newald for his comment and so idea for this post.

Posted at 06:15PM May 30, 2013 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices |  Comments[2]  | Views/Hits: 2812

A book about rethinking Java EE Patterns

The essential POM for JavaEE 7 is 30 lines of xml:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.airhacks</groupId>
    <artifactId>javaee-essentials-pom</artifactId>
    <version>1.0</version>
    <url>http://airhacks.com</url>
    <packaging>war</packaging>
    <dependencies>
        <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <version>7.0</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>
    <build>
        <defaultGoal>clean install</defaultGoal>
        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.1</version>
                <configuration>
                    <source>1.7</source>
                    <target>1.7</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

The src/main/webapp/WEB-INF folder comprises a minimalistic web.xml, so there is no need for WAR-plugin configuration:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
    <session-config>
        <session-timeout>
            30
        </session-timeout>
    </session-config>
</web-app>

The pom.xml was also checked-in into: https://github.com/AdamBien/javaee-essentials-pom

See you at Java EE Workshops at MUC Airport (Maven is discussed at second day, in the "Effective JavaEE" workshop)!

Posted at 08:50PM May 28, 2013 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices |  Comments[0]  | Views/Hits: 1757

A book about rethinking Java EE Patterns

Exceptions like javax.persistence.OptimisticLockException may occur at commit time and so after the execution of an EJB method. Therefore some occurrences are impossible to catch with the convenient "Container Managed Transactions" configuration.

The method DataStore#update fails, because SomeEntity changes are going to be recognized at commit time and so after the execution of this method.

@Stateless
public class DataStore {

    @PersistenceContext
    EntityManager em;

    public void update(String id) {
        SomeEntity forUpdate = this.em.find(SomeEntity.class, id);
        forUpdate.makeDirty();
    }

}

The exception: "javax.ejb.EJBException: Transaction marked for rollback" is raised after the execution of the EJB and can be only caught in the presentation layer.

However, transactions can be started and committed, and so handled, in an interceptor:

public class TXEnforcer {

    @Resource
    UserTransaction tx;
    private final static Logger LOG = Logger.getLogger(TXEnforcer.class.getName());

    @AroundInvoke
    public Object beginAndCommit(InvocationContext ic) throws Exception {
        try {
            tx.begin();
            Object retVal = ic.proceed();
            tx.commit();
            return retVal;
        } catch (RollbackException e) {
            LOG.severe("-----------------Caught (in interceptor): " + e.getCause());
            throw e;
        } catch (RuntimeException e) {
            tx.rollback();
            throw e;
        }

    }
}

The EJB needs to use the TXEnforcer interceptor to handle transactions and has to switch to the "Bean Managed Transactions" strategy (otherwise you get a: Caused by: javax.naming.NameNotFoundException: Lookup of java:comp/UserTransaction not allowed for Container managed Transaction beans):

@Stateless
@Interceptors(TXEnforcer.class)
@TransactionManagement(TransactionManagementType.BEAN)
public class DataStore {
}

In this example the DataStore EJB is a boundary which always initiates a new transaction. Therefore there is no need to handle existing transactions.

Thanks Marian S. for asking the question!

[See also Boundary pattern in the "Real World Java EE Patterns--Rethinking Best Practices" book (Second Iteration, "Green Book"), page 57 in, chapter "Boundary"]

The project catchemall was checked in into http://kenai.com/projects/javaee-patterns

See you at Java EE Workshops at MUC Airport (Effective + Architectures -- usually transactions are heavily discussed at these days)!

Posted at 07:48AM May 27, 2013 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices |  Comments[3]  | Views/Hits: 5625

A book about rethinking Java EE Patterns

Most of the popular acronyms are wrong:

1. SOAP (Simple Object Access Protocol): is neither simple nor object oriented. "SOAP originally stood for 'Simple Object Access Protocol' but this acronym was dropped with Version 1.2 of the standard.[2] Version 1.2 became a W3C recommendation on June 24, 2003. The acronym is sometimes confused with SOA, which stands for Service-oriented architecture, but the acronyms are unrelated…" http://en.wikipedia.org/wiki/SOAP
2. AJAX (Asynchronous JavaScript and XML): Most of AJAX applications are using JSON, not XML. AJAX' core component is the XMLHttpRequest JavaScript object / browser API. Without XMLHttpRequest would be hard to implement an AJAX application...
3. NoSQL: "… Some authors refer to them as "Not only SQL" to emphasize that some NoSQL systems do allow SQL-like query language to be used…" https://en.wikipedia.org/wiki/NoSQL. …and often the offered NoSQL query language is structured and very similar to SQL :-)
4. EJB (Enterprise Java Beans): Well designed JavaBeans are actually not well designed EJBs.
5. YAGNI there should be no acronym for that. Thinking about that may cause endless loops :-)

See you at Java EE Workshops at MUC Airport!

Posted at 11:45AM May 15, 2013 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices |  Comments[2]  | Views/Hits: 4070

A book about rethinking Java EE Patterns