inner class Builder is in charge of creating Customer instances
mandatory fields – either primitive (e.g. id) or annotated with @NotNull (e.g. lastName) – are part of the builder's constructor
all optional fields setter methods on the builder are provided
newly created Customer instance is validated using the Validator#validate() method
impossible to retrieve an invalid Customer instance
extract the validation routine into a base class:
abstract class AbstractBuilder<T>
T build() throws ConstraintViolationException
protected abstract T buildInternal();
private static Validator validator
Concrete builder classes have to
extend AbstractBuilder
must implement the buildInternal() method:
Builder extends AbstractBuilder<Customer>
@Override
protected Customer buildInternal()
Implementing the Builder Pattern using the Bean Validation API
variation of the Builder design pattern for instantiating objects with multiple optional attributes.
this pattern frees you from providing multiple constructors with the different optional attributes as parameters (hard to maintain and hard to read for clients)
or providing setter methods for the optional attributes
(require objects to be mutable, can leave objects in inconsistent state)
map multiple properties as @Id
properties and declare an external class to be the identifier
type
declared on the entity via
the @IdClass annotation
The identifier
type must contain the same properties as the identifier properties
of the entity: each property name must be the same, its type must
be the same as well if the entity property is of a
basic type
last case is far from obvious
recommend you not to use it (for simplicity sake)
@EmbeddedId property
@EmbeddedId
@Embeddable
@EmbeddedId
@Embeddable
@Embeddable
@EmbeddedId
Multiple @Id properties
arguably more natural, approach
place
@Id on multiple properties of my entity
only supported by Hibernate
does not require an
extra embeddable component.
@IdClass
@IdClass on an entity points to the
class (component) representing the identifier of the class
WarningThis approach is inherited from the EJB 2 days and we
recommend against its use. But, after all it's your application
and Hibernate supports it.
Mapping entity associations/relationships
One-to-one
three cases for
one-to-one associations:
associated entities share the same
primary keys values
foreign key is held by one of the entities
(note that this FK column in the database should be constrained unique
to simulate one-to-one multiplicity)
association table is used
to store the link between the 2 entities (a unique constraint has to
be defined on each fk to ensure the one to one multiplicity)
@PrimaryKeyJoinColumn
shared primary
keys:
explicit foreign key column:
@JoinColumn(name="passport_fk")
foreign key column named
passport_fk in the Customer
table
may be bidirectional
owner is responsible for the association column(s) update
In a bidirectional
relationship, one of the sides (and only one) has to be the owner
To declare
a side as
not responsible for the relationship
the attribute
mappedBy
is used
mappedBy
Indexed collections (List, Map)
Lists can be mapped in two different ways:
as ordered lists
as indexed lists
@OrderBy("number")
List<Order>
List<Order>
List<Order>
To use one of the target entity property as a key of the map,
use
history is persisted in the database
by means of a JPA entity bean and those objects are serialized back to the Flex client each time you enter a new name.
the glory of Spring's founding myth of killing the beast that was J2EE seems to be fading. The former beast is now as manageable and easy to use as Spring ever was, or even more so
Deconstructing Spring myths
looking at the capabilities of the Spring Framework itself, where are the killer features?
list of reasons why I feel more productive on Java EE 6 than on Spring 3.1
these days there's really no reason for preferring vendor-specific APIs over JPA 2.0
Spring and Java EE applications mostly differ in the following areas only:
the web framework (Spring MVC vs. JSF vs. Wicket vs. Vaadin vs. Struts vs.....)
Spring Beans vs. EJB
Spring Dependency Injection vs. CDI or Java EE 5 @EJB or @Resource injection
able to deploy my application directly from the workspace
bad news is that JBoss AS 7 does not currently support other persistence providers like Eclipselink, OpenJPA or DataNucleus
GlassFish and Resin, you can simply drop the JARs of your preferred provider and its dependencies in a designated folder of your server installation and edit your persistence.xml to override the default provider of the server
JBoss AS 7 appears to require an adapter per persistence provider, which to me looks like an unfortunate and unnecessary design decision
potential to take over the lead from GlassFish
documentation continues to be sketchy and far below the standard of JBoss AS 5
surprisingly lean and fast
top-level performance
classloader leaks
productivity issues of the Eclipse integration
lack of support for JPA providers other than Hibernate
Each of these is currently a blocker for using JBoss AS 7 in production
Redeployment
after a couple of redeployments, there was an OutOfMemoryError
new classloader leak
JBoss AS 7: Catching up with Java EE 6
Performance measurements
JBoss AS 7.0.2
GlassFish 3.1.1
Empty server startup time 1.9 s
3.2 s
Empty server heap memory 10.5 MB
26.5 MB
Empty server PermGen memory 36.3 MB
28.4 MB
MyApp deployment time 5.8 s
JBoss AS 7 is now at a competitive level with Resin and Glassfish and actually outperforms Glassfish in almost all of these tests
discuss the rationale for migrating your applications from Spring to Java EE 6 and show you real examples of upgrading the web UI, replacing the data access layer, migrating AOP to CDI interceptors, migrating JMX, how to deal with JDBC templates, and as an added bonus will demonstrate how to perform integration tests of you Java EE 6 application using Arquillian
EntityManagerClinicTest
There is also an interesting Arquillian Persistence extension that integrates DBUnit in Arquillian where you can define your test data externally
JDBC Templates hardly give any abstraction on top of the database and you’re on your own for Object Relational Mapping. We strongly advise to use JPA wherever possible; it gives portability by abstracting most of the database specific SQL that you would need, and it does all the hard and painful work of object mapping