Adam Bien's Weblog
JavaEE ...And The Bloat Is Gone (Session at InfoShare Conference)
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
NEW Java EE 7 Workshops: July 22nd-26th, 2013, Airport Munich
A book about rethinking Java EE Patterns
Tweet Follow @AdamBienMVP, IoC, DI and WYSIWG …with JavaFX--A Free Article
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:
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
NEW Java EE 7 Workshops: July 22nd-26th, 2013, Airport Munich
A book about rethinking Java EE Patterns
Tweet Follow @AdamBienGlassfish v4 Is Out (with JavaEE 7)
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
NEW Java EE 7 Workshops: July 22nd-26th, 2013, Airport Munich
A book about rethinking Java EE Patterns
Tweet Follow @AdamBienJDD JavaEE Session: Future Is Now, But Is Not Evenly Distributed Yet
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
NEW Java EE 7 Workshops: July 22nd-26th, 2013, Airport Munich
A book about rethinking Java EE Patterns
Tweet Follow @AdamBienJavaEE 7 Heals Crippled Jars And java.lang.ClassFormatError
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>
would result in:
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>
If you are starting with JavaEE 7, just use the Essential Java EE 7 POM
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
NEW Java EE 7 Workshops: July 22nd-26th, 2013, Airport Munich
A book about rethinking Java EE Patterns
Tweet Follow @AdamBienSummer Of JavaEE Workshops And Gigs
- Free Hacking night:11.06.2013, Utrecht JavaEE 7 Meets HTML 5 and AngularJS
- Workshops: 24.06-26.06.13, Munich Java EE Summit
- Conference: JayDay, 02.07.2013, Munich Nothing Compares To …Java EE 7
- Jug Session: 02.07.2013, Nürnberg JavaEE 7 And Why There Is No More Room For Overengineering (Livehacking)
- 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
NEW Java EE 7 Workshops: July 22nd-26th, 2013, Airport Munich
A book about rethinking Java EE Patterns
Tweet Follow @AdamBienWhy It Is Impossible To Automatically Handle javax.persistence.OptimisticLockException
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:
- First update wins
- Last update wins
- 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
NEW Java EE 7 Workshops: July 22nd-26th, 2013, Airport Munich
A book about rethinking Java EE Patterns
Tweet Follow @AdamBienEssential Maven POM For JavaEE 7
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
NEW Java EE 7 Workshops: July 22nd-26th, 2013, Airport Munich
A book about rethinking Java EE Patterns
Tweet Follow @AdamBienEJB: How To Catch javax.persistence.OptimisticLockException
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
Posted at 07:48AM May 27, 2013 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Comments[3] | Views/Hits: 5625
NEW Java EE 7 Workshops: July 22nd-26th, 2013, Airport Munich
A book about rethinking Java EE Patterns
Tweet Follow @AdamBienAJAX, SOAP, NoSQL, EJB--All Wrong Acronyms
Most of the popular acronyms are wrong:
- 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
- AJAX (Asynchronous JavaScript and XML): Most of AJAX applications are using JSON, not XML. AJAX' core component is the
XMLHttpRequestJavaScript object / browser API. WithoutXMLHttpRequestwould be hard to implement an AJAX application... - 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 :-)
- EJB (Enterprise Java Beans): Well designed JavaBeans are actually not well designed EJBs.
- 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
NEW Java EE 7 Workshops: July 22nd-26th, 2013, Airport Munich
A book about rethinking Java EE Patterns
Tweet Follow @AdamBien
