I'm the person behind annotations in Hibernate: Hibernate Annotations, Hibernate EntityManager, Hibernate Validator and Hibernate Search. I am a member of the JPA 2.0 expert group as well as the JSR-303 Bean validation spec lead. You can check out my book Hibernate Search in Action by Manning.
05. Dec 2013
25. Jul 2013
28. May 2013
21. Mar 2013
16. Jan 2013
07. Nov 2012
03. Oct 2012
28. Jun 2012
01. May 2012
04. Apr 2012
15. Mar 2012
14. Mar 2012
29. Feb 2012
15. Dec 2011
22. Nov 2011
Hibernate and JBoss Seam will be covered by some of the JBoss folks at JavaOne.
TS-4746 - Hibernate Search: Googling Your Java Technology-Based Persistent Domain Model
I will describe the problem addressed, how Hibernate Search backed by Apache Lucene provides a solution, the internal architecture and some tips and tricks. I will also demo how to add Hibernate Search to an application.
TS-4112 - Declarative Programming: Tighten Enterprise JavaBeans (EJB) 3.0 and JSR 303 Beans Validation
TS-4089 - Web Beans Update
BOF-4400 - Improve and Expand JavaServer Faces Technology with JBoss Seam
BOF-9792 - Rapid Seam Application Development with the NetBeans IDE
Michael will also talk about JBoss Seam, the product. These tracks are more focused on JBoss Seam ease of use and Rapid Application Development (this is what JBoss Seam is about after all ;- ) )
I think a party is planed too, see you there.
This is a pretty big day for the Hibernate family. We welcome three new top level projects:
- Hibernate Shards
- Hibernate Validator
- Hibernate Search
So total we have made five new releases today .
Contributed by Google, Hibernate Shards is a horizontal partitioning solution built on top of Hibernate Core. When you need to distribute (shard) your data across multiple databases, Hibernate Shards is for you (too much data for a single database instance, regional deployment requirements, etc.) Like all Hibernate projects, Hibernate Shards is released under the LGPL license. Big thanks to Max Ross, Maulik Shah Tomislav Nad, and Google :-) for contributing back to the community their pretty impressive Google's 20 percent project.
Check the documentation for more information.
Hibernate Search is now a top level project independent of Hibernate Annotations. New in this release:
- out of the box index clustering through JMS - master/slaves model -(maximizing throughput)
- asynchronous indexing (maximizing application response time)
- indexing of embedded/associated objects and correlated queries (semantically similar to a SQL JOIN)
- use of Apache Lucene(tm) 2.1.0 (lot's of performance and scalability improvements)
While marked as Beta because its scope is rapidly growing and some APIs are still subject to change, Hibernate Search is already used by quite a few people, check it out .
Hibernate Validator is also a new top level project independent of Hibernate Annotations. New in this release:
- run with pure Java Persistence Provider (entity listener provided)
- more business oriented validators
A few minor configuration changes (necessary to introduce the previous projects) lead us to an version number increase. This version is however mostly backward compatible with 3.2.x. Some of the new features are listed:
- transparent event wiring for Hibernate Validator and Hibernate Search
- performance improvements during cascading in Hibernate EntityManager
- more SQL customizations as well as fetching and lazy configurations
- the usual bunch of bug fixes
The past few months have been pretty busy preparing this unique feature rich Hibernate bundle with smooth out of the box experience. Enjoy :-)
The most significant part, by far, of Hibernate Annotations 3.2.1 is the complete rewriting and feature expansion of Hibernate Search formerly known as Hibernate Lucene.
Hibernate Search allows you to search your domain model (google it) without the hassle and mismatches introduced by the full text technology. Indexing is done automatically, the mapping between the object model and the index documents is described through annotations, the querying capability is integrated with the regular Hibernate querying system. Hibernate Search use Apache Lucene underneath and lowers the barrier to entry to such a technology technology.
In a few words, bringing Google search capabilities to your domain model.
For most people, queries are synonym of SQL query, and this is indeed the case of most applications. There is a spectrum of queries, however, that are not handled by SQL (at least without proprietary extension): free text search, proximity search, phrase search, synonyms, approaching terms, result by relevance... Full-text search engines solve these classes of problems.
Full text search queries involve two steps. Indexing, ie maintain coherence between the database
information and the full text index information. Querying, the ability to query in a
free form the indexed information.
Integrating such a search capability to a system is not that easy. In most systems, a mismatch exists between the data structure used by the application core and the data structure used by the full text search. For applications using ORM such as Hibernate, the former is mostly designed around the object model, while the latter is designed around the notion of documents containing several fields of strings. Handling this mismatch and maintaining the data synchronized between both part of the system tend to be too tedious for a massive adoption.
Hibernate Search aims to tackle the mismatch complexity for you, and to lower the barrier to entry of full text technology such as Apache Lucene in most applications.
Hibernate Search is a glue code between Hibernate and Apache Lucene. Apache Lucene is a fantastic full-text index Java library, and the de facto standard in the open source world. Hibernate Search listen to any changes made to the domain model thanks to the Hibernate event model. All modifications made to your persistent objects will be propagated to the Apache Lucene index transparently. Under the hood, Hibernate Search is optimizing indexing by batching the works. The current implementation queue the work per transaction. Other pluggable implementations will be possible shortly. Finally, you can force indexing of a given set of objects, which is particularly useful when initializing the index. How indexes are organized is pretty much up to you, you can have one Directory (index) per entity type (recommended) or share the same Directory for several entities.
Indexing means translating the java object attributes to a (potentially degraded) string representation. The bridge between properties and index fields is driven by annotations metadata and defaulted to a built-in set of bridges. Flexibility is provided by the ability to use a custom bridge (very similar to the notion of /UserType/).
One of the mismatch is that full text queries in Apache Lucene returns /Documents/ and not regular domain objects. Hibernate Search implements /org.hibernate.Query/ and gives you a unified query model regardless of the query engine (criteria, HQL, SQL, Lucene). In particular, you have access to pagination and all the query APIs like /scroll()/, /list()/ etc... All queries will return managed objects (ie attached to a session), that you will be able to use and modify at will like a regular hibernate managed object (because it /is/ a regular managed object). You can decide to query on all entities or only a subset of them. Like in Hibernate, querying on a subset of entities is polymorphic.
Hibernate Search goal is really to lower the barrier to entry of full text engine technology. Apache Lucene is often criticized by beginners for its low level API and inherent complexity. Hibernate Search make it simple to use, removing some of the complexity, but let you access all the power and flexibility of Apache Lucene if you need to. Hibernate Search is part of Hibernate Annotations. Check it out and download it , using it is much simpler than explaining it :-)
I heard about FindBugs(tm) while listening to one of the Java Posse podcast. Since Hibernate Annotations and Hibernate EntityManager are very close to their respective final releases, I decided to give it a shot.
FindBugs(tm) is basically a static code analyser that tries to find bugs in your code through some pattern recognition. I have been working in the past with both static and dynamic code analysers and I have been pretty disappointed by their false positive ratios (basically a non-bug considered as a bug), and the complexity of their set up process. FindBugs was a refreshing experience.
The cool stuff about it is, well, there are several cool stuffs:
- it's a no brainer to set up and run
- the amount of false positive is surprisingly low
- it works at the bytecode level, so you don't have to have the source code (more later)
I haven't read the documentation, just downloaded the package and run the .bat file. A couple of clicks and I was analysing Hibernate Annotations and Hibernate EntityManager . No fancy Ant integration required (you can, but you don't have to), no fancy IDE dependency (you can, but you don't have to), no fancy command line requiring you to RTFM (you can, ahem you should, but you don't have to). The provided GUI does the job pretty smoothly, even if a package filtering feature would have been really cool (more later).
THE thing that usually kills such a product is the amount of false positive bug claims. You end up scanning hundreds of warnings without paying attention to them and trash the whole product after 30 minutes. FindBugs has a pretty low false positive ratio, which is very good. And if the warning end up being a false positive, there are usually some good reasons that worth a second look at your code. I must admit I am pretty proud of me ;-) Of course in HAN and HEM, I found some bugs and suboptimal constructs (no worries, I fixed them), but much less than my expectations.
That is probably what makes it easy to use (and hard to develop), FindBugs(tm) works at the bytecode level, not the source level (it highlights the source line if the sources are available). So pointing a jar or a directory containing your compiled classes is enough. Actually what I did, was pointing to my project root directory, and the job was done.
So while analysing Hibernate Annotations and Hibernate EntityManager , I ended up analysing a bunch of jars (Oh Filter, where art thou?), and I can tell you some guys out there should take a look at FindBugs(tm) , this include a bunch of JDBC drivers and well known in-memory Database backed by some big company(ies) ;-)
It's free, it's easy to set up, it's going to take two hours of your time and save you much more.
I've seen lot's of people writing (or using) third party abstraction frameworks on top of ORM solutions like Hibernate so that they can potentially get rid of one ORM engine to another (or even an other technology). Such frameworks are even considered by some architectsas a must-have.
Praiseworthy, but raising more issues than fixing ones. When you abstract technologies
like Hibernate to make them
portable, you end up sacrificing
lot's of power and functionalities. Simply because semantics are slightly different from
one engine to an other.
Let's play with statistics:
- in 1% of the applications, the need for a switch from one ORM engine to an other arise
- in 99% of the applications, the need for one or several advanced features of ORM arise
You should focus on using and knowing your ORM engine and not on spending time in writing (or using) an abstraction framework.
When using abstraction frameworks you haven't written, other kind of problems actually show up.
When your ORM engine introduce new APIs or new features, you have to wait for the abstraction framework to release accordingly making you dependent on someone else's agenda.
You no longer know (either by heart or at all) the actual method abstraction (or semantic alteration) introduced on top of your ORM engine. This user learnt it the hard way (and he is unfortunately not alone), Spring's /HibernateTemplate/ wraps the Hibernate methods without even giving you a hint about the actual semantic.
The only proper abstraction between an ORM engine and another is a common specification they adhere to. This is one of the reasons why JPA (EJB 3.0) has been introduced. Why is it the only way? Because a specification describes in a very detailed way the common semantic the various ORM engines have to follow.
So please, think twice before using some random proprietary abstraction framework (open source or not). They usually bring no value add but increasing bug areas... Specifications are here to solve the engine abstraction problem (but once again, this is a concern in very few applications).
PS in case someone is misleading, I'm not arguing against DAO layers
||Showing 81 to 85 of 93 blog entries||