I am doing a session on Hibernate Search all this week at JavaRanch. Manning will give away free books of Hibernate Search in Action for the occasion.
If you have questions on Hibernate Search, express yourself :)
I am doing a session on Hibernate Search all this week at JavaRanch. Manning will give away free books of Hibernate Search in Action for the occasion.
If you have questions on Hibernate Search, express yourself :)
Great news this week:
Also, on the Bean Validation (JSR 303) side, I am finalizing the last changes in the spec for the public draft. We made a lot of progress in the last two weeks on various subjects including type-safe groups and JPA / JSF / EE integration (with the finalized draft, I will officially contact the EE expert group). Stay tuned, hopefully the draft should be out in a week or two.
Finally, Hibernate Search in Action is supposed to be released in final PDF monday (still not believing in it till I see that one ;) ).
Great week on my side. See you at Devoxx for a drink or two.
DZone has a nice Hibernate Search 3.1 6-pages ref card. It is packed with:
It's free but you need to register.
Speaking of the devil. John and I have given back our last edits for Hibernate Search in Action. So we are still on target for releasing the book in december. I personally still can't believe I am done, so I will play the St Thomas and will wait till I can touch the paper :)
You can get the paper book at Amazon or on the Manning website. Manning also offers the PDF version.
Ayende, one of the active bees behind the NHibernate portfolio, has a nice review of Hibernate Search in Action on his blog.
By the way, Ayende has ported Hibernate Search to .net : NHibernate.Search. I don't think there is documentation specific to the project but the Hibernate Search documentation is just as useful.
I don't know Ayende personally, but I can only admire someone that blogs more that I can tweet and still have a full time job :)
We just had our third review of Hibernate Search in Action. Receiving this feedback has been a humble experience. Lot's of good reviews (good) and some critical ones (even better). Every imperfection we left aside came back in the spot lights of our reviewers.
Based on this feedback, we have been working hard the last two weeks to improve a lot the manuscript:
The code is almost ready for prime time, we will publish it as soon as we find the right vehicle for it.
Thanks to all our reviewers. While I am not sure I appreciate the recent sleep depravation, this definitely improved the book a lot.
As usual, you can get the preview version electronically at Manning, it has all the chapters and I hope to get the latest changes uploaded soon.
There is a tiny little utility that let's you inspect JAR/WAR/EAR files on the Mac OS platform. The software is available here. Install it. To open a JAR, simply right click and chose JarInspector as the application. I personally did not set JarInspector as my default .jar application to let the default JAR launcher kicks in but I have been very close to.
Amongst the useful features:
By the way, this utility also opens zip files.
Enjoy.
I have always been annoyed quite a bit by automatic Out of Office messages. This summer was no exception. So here are my top reasons for not doing it.
Please don't overuse this tool. If you need to set that kind of message, it means your organization has flaws.
That's now official, I handed over the last chapter to the publisher yesterday. All chapters will be available to the early access program in the next few days. The journey is not finished yet. A lot of reviewing and correction are at sight. If you have feedback, now is the time :)
The last last few chapters out cover:
Filters are a neat feature allowing to apply cross cutting restrictions on Lucene queries: you might want to filter to the latest month item creations or filter according to the security level the user is granted. Filters do just that in a declarative fashion: enable one or more of them by their names.
The chapter of performance is a mix of existing content and new content focused around performance at various stages: indexing and searching. It also includes an explanation about index sharding.
The last chapter describes problems that arise when you try to cluster Lucene and how Hibernate Search addresses them. We primarily describe the asynchronous clustering approach implemented out of the box in Hibernate Search (using JMS). The chapter also describes how to customize Hibernate Search to your own clustering strategy to meet your architectural needs.
Now off to the correction marathon :)
This tutorial will show you how to create a queue in JBoss AS 5 (which uses JBoss Messaging 1.4.1), send a message to a remote queue and listen to the queue using a Message Driven Bean.
I have been playing with JMS queues and MDBs in JBoss AS 5 today to complete the clustering chapter of Hibernate Search in Action and went through more bumps than I should have. Let me share what I've learnt. Disclaimer, I am a JMS noob: this tutorial will go only over the basic concepts. In particular, I will not cover subjects like security, message persistence and so on. This tutorial can be partly reused by Hibernate Search users using clustering (just ignore the part when we send and consume messages as Hibernate Search does that under the hood).
First of all, get a fresh version of JBoss AS 5.0 (currently in Release Candidate 1) here. We will launch two instances of JBoss AS in parallel. If you are lucky enough, run them in two different machines (virtual image or not). If you are not, you will have to remap a few ports to avoid any conflict and this is what I will just describe now.
Go to JBOSS_HOME/server and copy the default directory as master.
cp -r default master
We now have two versions of the JBoss configuration. default will contain our slave instance configuration and master will contain our master instance configuration. Let's now change the default ports on the master configuration. In the master directory, open each file described and change the following ports
This step is only required if you use the same server to run both instances. There is an alternative and more elegant approach described here (thanks Julien for tweeting me the answer after I did all the hard work :) )
You need to make sure JBoss Messaging has a different ServerPeerID between different instances. Update deploy/messaging/messaging-service.xml, and set ServerPeerID to 1 (the default configuration uses 0)
We will now create the queue in the master instance. Open deploy/messaging/destinations-service.xml, and add the following fragment
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=hibernatesearch"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
</mbean>
A queue is an MBean object, you can refine it's configuration as explained in the JBoss Messaging documentation. As a start, you can simply copy the fragment and replace hibernatesearch by the name of your queue. The queue will be available in JNDI under queue/hibernatesearch (this can be overridden if needed). If you start the master instance of JBoss AS (go to JBOSS_HOME/bin and launch ./run.sh -c master), you should see the following lines in the console
The next step is to publish a message from the default JBoss AS instance into the queue. Here is a simple servlet doing so:19:27:46,403 INFO [QueueService] Queue[/queue/hibernatesearch] started, fullSize=200000, pageSize=2000, downCacheSize=2000
@Override
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
QueueConnectionFactory factory;
Queue queue;
try {
Properties jndiProps = new Properties();
jndiProps.setProperty("java.naming.provider.url", "jnp://localhost:1199")
InitialContext initialContext = new InitialContext( jndiProps );
factory = (QueueConnectionFactory) initialContext.lookup( "/ConnectionFactory" );
queue = (Queue) initialContext.lookup( "queue/hibernatesearch" );
}
catch (NamingException e) {
throw new Exception( "Unable to lookup queue", e );
}
QueueConnection cnn;
QueueSender sender;
QueueSession session;
try {
cnn = factory.createQueueConnection();
session = cnn.createQueueSession( false, QueueSession.AUTO_ACKNOWLEDGE );
TextMessage message = session.createTextMessage();
message.setText("Pass it along");
sender = session.createSender( queue );
sender.send( message );
session.close();
}
catch (JMSException e) {
throw new Exception( "Unable to send message to JMS queue", e );
}
finally {
try {
if (cnn != null) cnn.close();
}
catch ( JMSException e ) {
log.warn( "Unable to close JMS connection", e );
}
}
}
A few things are noticeable here:
On the master side, you can deploy a MDB (a trivial task with EJB 3 as no deployment descriptor is needed).
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
@ActivationConfigProperty(propertyName="destination", propertyValue="queue/hibernatesearch"),
@ActivationConfigProperty(propertyName="DLQMaxResent", propertyValue="1")
} )
public class MDBPassOnController implements MessageListener {
private final Logger log = LoggerFactory.getLogger( MDBPassOnController.class );
public void onMessage(Message message) {
if ( !( message instanceof TextMessage ) ) {
log.error( "Incorrect message type: {}", message.getClass() );
return;
}
TextMessage textMessage = (TextMessage) message;
System.out.println( textMessage.getText() );
}
}
The new embedded console (to come with JBoss AS 5 final) based on a stripped down version of JBoss ON will make some of these steps much easier but now that you have gone the roots way, don't you feel stronger? :)
... and uses it as their iTunes Store infrastructure. Now it's broke!
I updated my iPhone firmware this morning *as requested by Apple* and the process is hung because the iTunes Store is down. I now have a totally bricked legit iPhone: no call, no text. Great!
Apple, I am very angry at you. Why are you penalizing your legit customers by not allowing the phone to be activated without your blessing. People who want, will jailbreak it anyway. Please this is the 21st century, be smarter.
PS: sorry Twitter to pick on you. I love your service, and it helped me to discover I was not stuck alone in this madness. Summize is a totally awesome pulse checker.
We have just pushed another set of chapters for Hibernate Search in Action and reached the symbolic limit of 2/3. Yoohoo! We have also enhanced some of the existing chapters based on the feedbacks we received and the perseverance of our editor. They have just shipped as part of the early access program available in ebook format. I am very happy with the new chapters especially the description of analyzers in chapter 5.
I describe the use of Hibernate Search and the new Solr integration (coming up in Hibernate Search 3.1) to enable synonym, phonetic, n-gram and snowball search. Snowball is an algorithm that deduces the root of a word enabling searches for words of the same family: work, working, worker will all be reduced to the same root (called stemmer). The chapter both aims at demystifying analyzers and providing a concrete approach on how to use them. I really enjoyed writing it, I hope you will like reading it.
Beyond analyzers, here is a small list of the subjects I am personally happy with in the book:
We (and by we, I mean John) also have finished the Lucene dedicated content. While Hibernate Search hides the gory details of indexing and searching, its let you use all the flexibility of Lucene queries. Understanding Lucene is key and we have added the necessary knowledge you need for your daily work with Hibernate Search.
Let us know what you think and, of course, go buy the e-book :)
Lucene Java 2.3.1 available
This release contains fixes for serious bugs in 2.3.0 that could cause index corruptions in autoCommit=false mode or in cases where multiple threads are adding documents where some have term-vector enabled fields and some don't. The autoCommit option was added to IndexWriter with release 2.2.0. If not explicitly set to false, the IndexWriter runs in autoCommit=true mode.
See CHANGES.txt for a detailed listing of changes.
2.3.1 does not contain any new features, API or file format changes, which makes it fully compatible to 2.3.0.
We would like to encourage everyone who is currently using Lucene Java 2.3.0 to upgrade to 2.3.1 to prevent possible index corruptions!
Rod Johnson has been quite aggressive against JBoss AS in the last few weeks. It did not really bother me per se but the move is interesting. While it is well known that some JBoss folks and some Interface21 folks has been having tensions in the past, it came to a surprise that Rod joins the arena. Since Rod does not attack people for emotional reasons contrary to other folks, let's try a guess what's going on.
Interface21 (now SpringSource) received VC funding last year. Don't be naive, VC do transform a company, they are seeking for quick returns on their investment. Interface21 was mainly a consulting oriented company (in term of business) around the Spring portfolio. While this is a very steady and nobel business, it cannot provide the ROI VC people want to get: SpringSource's strategy had to be adjusted, the most obvious, safe and well defined solution is to follow the JBoss Inc model: go for the support money.
Well, to sell support, you need runtime. Unfortunately for SpringSource, Spring as a framework is not appealing enough for customers to jump into the support model. I think SpringSource did some interesting partnership / support deals with the folks at IBM, BEA and possibly Oracle (something JBoss never really did well because of the direct competition), but the only reasonable way to scale up the business is to have and support your own runtime. By the way, you can see the partnership going on in Rod's blogs, his tone is very sympathetic to IBM, BEA and Sun (I will come back to Sun later on). Generally speaking, the broader your platform is, the more likely you will be able to sell support. So SpringSource needs a platform to "sell and support".
Writing your own proprietary set of platform API is not so much in the air (to unquote Steve Jobs). That's why SpringSource joined the JCP and started to bless Sun and the Java EE 6 efforts, especially the profile effort. They need a mini-EE they can reach implementation-wise. If I were SpringSource, I would then try and get the smallest web-ish profile as possible out of the Java EE expert group, implement it and then raise the Java EE compliant flag to sell supports.
Side note on profiles. While everybody agrees Java EE needs some profile, I am sure nobody agrees on what to put in which profile: every application has different needs. What people really need is an ability to deploy and buy infrastructure components a la carte (whether it be one vendor or several) with the warranty of well defined API / SPI so that the whole platform keep a coherent vision freeing the customer from any integration work (component integration or programmatic model integration). Nothing a rigid profiling set can do. But that is a hard job.
Back to the main story. Even with the smallest possible Java EE profile, SpringSource is lacking some important pieces, the first one being the servlet container. And here comes the reason why Rod has been trying to not so subtly sent the message that JBoss AS is crap (I summarize here) and Tomcat is great. The only obvious choice for SpringSource is Tomcat. They need to enter the platform/runtime by the low end and gain market share (as in support market share). I would not be surprised if SpringSource announce a fully supported platform effort based on Tomcat and Spring at it's core. Of course, they need to hire some of the key contributors of Tomcat to gain some credibility. Let's imagine this done, the first competition they think they will face is JBoss AS, so seeing Rod poopooing on JBoss AS and EJB 3 is not a surprise. The first competition they will face though is people that do not want support for Tomcat: JBoss has been offering Tomcat support for a long time but not surprisingly monetizing Tomcat never succeeded. Most applications deployed on Tomcat do not want need (of course exceptions apply). Maybe Tomcat + Spring will be the silver bullet but I seriously doubt it for a bunch of reasons. The second biggest competition will probably be their own ecosystem. When you start to compete with them, your partners tend to be pissed, that's life. Ask Larry about that.
By the way, Rod does not seem to know that JBoss uses an enhanced version of Tomcat as a web container named JBoss Web. Remy (Tomcat) and Mladen (Apache httpd) sat down and wrote a native integration between Tomcat and APR to make this server the best of both Tomcat and Apache httpd. Maybe he wants to check it out and fork it :) Oh, one more thing, anybody that has been charged by an elephant tend to smile at the cat vs elephant analogy.
Tomcat + Spring will still be a weak platform, SpringSource will have to beef it up with some additional components:
- a persistence framework (and no Spring is not a persistence framework :) )
- a transaction manager
- a messaging system
- maybe some webservices thingy stuffs
and a few more components. They probably will also have to announce a developer tooling strategy around that.
I will only comment on the persistence piece of their platform as I know the field quite well. They can technically chose between Hibernate, OpenJPA, and Toplink. Hibernate would be the smartest move for them and the most aligned with their customer base but this probably will be a tough call for Rod. The two alternative strategie are Toplink (aka EclipseLink) and OpenJPA. If I were them, I guess I would go for OpenJPA as a second choice but they will have to invest R&D in the pieces that differenciate OpenJPA from Kodo.
Rod, please be more open with your strategy. I always liked Marc Fleury's own way to tell everyone what strategy he was following and what will be the next moves. To everyone, including the competition :)
Good luck anyway, I am eager to have competition in this field as I think JBoss AS, Seam, Web Beans and the technologies around them (JPA, EJB 3, JSF and so on) are more appealing to the next leap forward.