It has gone some time since I announced the last release of the Hibernate JPA Metamodel Generator. It is time to announce the release of version 1.2.0.CR1. Just as a reminder, JPA Metamodel Generator is an annotation processor which generates the canonical metamodel classes needed for using the strongly typed JPA 2 Criteria queries.

This new release is a maintenance release with a total of 20 enhancements and bug fixes. Most of these issues have been reported by users and many came even with a patch. Thanks!

METAGEN-53, METAGEN-73 and METAGEN-79 are worth mentioning explicitly. METAGEN-53 removes the dependencies to the JPA API. This means that the annotation processor is now a standalone jar without any further dependencies which makes integration of the processor into the build process and into the IDE even easier. METAGEN-73 and METAGEN-79 are about the @Generated annotation. In earlier version you had to explicitly specify the addGeneratedAnnotation option to add the annotation. Now @Generated is added by default and you have to explicitly disable it in case you want Java 5 compliant source files. Also the parameter values of the annotation have changed:

@Generated(value = "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor", date = "2012-01-25T22:22:54.850+0100")

The value is now the fully qualified classname of the annotation processor as suggested by the documentation of @Generated and you can also add the generation date by providing the processor option addGenerationDate (per default the date is not added).

As usual, you can download the release from the JBoss Maven repo or from SourceForge.

To report any issues use the Hibernate Jira project METAGEN.

Enjoy!

One of the new features in 4.1 will be the addition of an actual API for loading entities by natural id. Yes previous versions had the ability to do natural id loading leveraging criteria queries, but that approach was very limiting. The new API will allow caching at both the Session and SessionFactory level in addition to providing a consistent API. The new approach has been made available for identifier based loading as well, again for consistency.

New methods have been added to the Session contract as a starting point (see source or javadoc for additional discussion):

public IdentifierLoadAccess byId(String entityName);
public IdentifierLoadAccess byId(Class entityClass);

public NaturalIdLoadAccess byNaturalId(String entityName);
public NaturalIdLoadAccess byNaturalId(Class entityClass);

public SimpleNaturalIdLoadAccess bySimpleNaturalId(String entityName);
public SimpleNaturalIdLoadAccess bySimpleNaturalId(Class entityClass);

All of the load access delegates have methods for getting an entity reference (getReference) and loading an entity (load). The distinction is similar to the older get and load methods on Session; getReference on load access delegates equate to Session.load and load on load access delegates equate to Session.get

public interface IdentifierLoadAccess {
    public IdentifierLoadAccess with(LockOptions lockOptions);
    public Object getReference(Serializable id);
    public Object load(Serializable id);
}

public interface NaturalIdLoadAccess {
    public NaturalIdLoadAccess with(LockOptions lockOptions);
    public NaturalIdLoadAccess using(String attributeName, Object value);
    public Object getReference();
    public Object load();
}

public interface SimpleNaturalIdLoadAccess {
    public SimpleNaturalIdLoadAccess with(LockOptions lockOptions);
    public Object getReference(Object naturalIdValue);
    public Object load(Object naturalIdValue);
}

So let's say we have an entity defining a natural id:

@Entity
@Table(name="T_USER")
public class User {
    @Id
    private Long id;
    @NaturalId
    private String username;
    ...
}

we can load instances of that class by natural id as follows:

session.byNaturalId( User.class ).using( "username", "steve" ).load();

That actually makes sure we get back an initialized instance, just like Session.get does. If we just want a possibly uninitialized reference we would use this instead:

session.byNaturalId( User.class ).using( "username", "steve" ).getReference();

Since the natural id here is simple (just a single attribute) we can make this even easier:

session.bySimpleNaturalId( User.class ).load( "steve" );

A bit late, but better then never, in case you missed it - JUDCon is coming to India:

• JUDCon India - Agenda

As you can see it will be busy two days for me, talking a bit about the stuff I'm working on atm:

• CapeDwarf -- first look at our super progress on the Blue layer
• Java EE and GAE -- how CapeDwarf actually came about
• Android and the Cloud -- client perspective on CapeDwarf's beginnings

I hope to see you there!

I am very proud to announce the very first alpha release of Weld 2. Weld is the reference implementation of Contexts and Dependency Injection for Java EE (CDI). In the 2.x series of Weld releases, we will be focusing on JSR-346 which is the next version (1.1) of the CDI specification.

The Alpha1 release is a feature-complete implementation of the Early Draft of CDI 1.1. Pete blogged about the news in the early draft some time ago. The following list just highlights some of the new features I consider the most important:

• Ability to access the CDI container from anywhere simply by calling CDI.current()
• Conversations in plain Servlet requests
• Application lifecycle events in Java EE
• Injection into enums
• Ability to override attributes of a Bean via BeanAttributes
• Ability to process modules and manipulate the content of the beans.xml file via ProcessModule
• Ability to wrap the InjectionPoint
• Injection of Bean metadata into bean instances
• Programmatic access to a container provided Producer, InjectionTarget, AnnotatedType

The main reason for building a reference implementation is to prove a specification and reveal potential problem early. While implementing the Early Draft of JSR-346, several issues emerged that were previously unseen. If you are interested in these issues or have an idea of how to address them, feel free to share you opinions in the issue comments or the JSR-346 mailing list. Also, if you want to contribute to Weld 2, now is the right time. Since we are hosted on github forking and playing with Weld is extremely easy.

In addition to our efforts on the Weld side, Martin Kouba has been working on the Technology Compatibility Kit (TCK) for JSR-346. The Alpha1 version of the CDI 1.1 TCK is released along with the Weld release. Martin did a great job and delivered a solid test coverage of the new features. He also migrated the entire testsuite to Arquillian, which enabled us to develop new tests faster while at the same time using more extensive scenarios (such as multiple web applications inside of an enterprise archive).

Weld and CDI TCK artifacts can be obtained from Maven or from a distribution bundle (see the links below). We tried our best to make it easy for you to test-drive the new features. Therefore, we also provide a special build of JBoss AS 7.1.0.CR1 enhanced with Weld 2 :-)

For the next release (Alpha 2), our plan is to look into improving non-functional characteristics of Weld such as memory footprint and start-up time.

[ Distribution (Weld, CDI TCK) ] [ JBoss AS 7.1.0.CR1b with Weld 2.0.0.Alpha1 ] [ Issue tracker (Weld, CDI TCK) ] [ CDI 1.1 EDR1 Javadoc ]

We tagged Hibernate Search 4.1.0.Alpha1, and artifacts are now ready to be downloaded. 4.1 is meant to mainly upgrade the core dependencies and will have a quick development cycle.

Upgraded dependencies

• Apache Lucene 3.5
• Infinispan 5.1
• JGroups 3.0

To use the above versions, upgrading is required as each of the mentioned projects changed some of its API used by Hibernate Search. Of course Hibernate Search shields you from these changes being fully backwards compatible.

MassIndexer performance

The MassIndexer is quick again! To be honest this is not an improvement but is a bugfix of a performance regression. If you noticed a performance drop in mass indexing using 4.0.0.Final, please try again with this new release and you will see a significant improvement. While working towards 4.1 final we're going to improve it's features and possibly performance even more, finally taking advantage of the new internal design provided by 4.0.

Great contributions

Guillaume Smet identified and fixed a regression for which dirty collections would not be re-indexed when having a custom FieldBridge instead of the standard @IndexedEmbedded.

Davide D'Alto improved the algorithm identifying the elements which need to be loaded and re-indexed: it's now able to avoid some unnecessary database loads in specific use cases having complex relations, consequently also reducing the index size.

The usual links

As always distribution bundles are available from Sourceforge, or you can get it via Maven artifacts. User questions are welcome on the forums, bugs and improvements can be discussed on the mailing list or posted to JIRA directly, possibly with unit tests.

Complete details of all changes are tracked on JIRA.