Apache Native Library installation on Linux

Download the native library from http://tomcat.apache.org/download-native.cgi

Then do the following to install it.

 

Maven, Spring 3, and Hibernate 4 Tutorial/Setup

If you are like me, I like my project to always use the latest framework versions. You can easily modify the version under the properties tag at the bottom of the snippet.

Your pom.xml should have the following:

You can now do a mvn eclipse:eclipse to update your project to include the jars. Now it’s time to edit your spring context to make use of these. We will be gunning for annotation rather than XML configuration.

 

I think many of Spring/Hibernate configuration tutorials out there do not really explain what they are doing in the context and I freaking hated it when I was researching this out. Hopefully, you the reader would have a less painful experience that I have had. All the things that I explain are based on my understanding of how the function work rather than copy pasting it from spring documentation to make it easier to understand. Let’s dig in!

Line 1 – You are telling spring to scan the package a.b.catalog and register the beans in the context. You must at least know a little bit about spring if you are reading this. You know that previously, spring needs XML entries for spring to know which beans it needs to manage. We can do that now through annotation. By the way, this is not new to Spring 3 just in case you are wondering.

Line 2- activating the annotation for already registered beans.

Here is an excellent stackoverflow link about our first two lines.

Line 3 – Tells spring to allow dispatching requests to controllers.

Line 4 – Basically telling spring to manage the transaction and use the transaction we have. In this case, tx. But what exactly is tx? We will cover that below.

tx is the spring bean id of our transaction. If you do not know what a transaction is, better google it now before proceeding.

myDataSource – Creates a connection to your database. It is pretty ugly right now because we have it hard coded in you context xml. I will have another post for this using property placeholders in spring.

sessionFactory – creates a hibernate session factory base on the datasource we defined earlier. Something to take note of is the packageToScan line. Like I mentioned earlier, the goal is to use annotation. This is pretty convenient since we do not have to tell what all classes or hbm.xml files we need to load.

tx – Spring hibernate transaction manager. Do not really need to explain this.

This is a good time to take a break. We have a few more paragraphs to read through so take 15 and let’s continue after that.

Ready? Here we go.

So recalling what we have already done, we already have told spring that we are using annotation for transactions. We already told spring to create the transaction. What is missing? When should spring really start monitoring for transaction to start and end? That is where AOP comes in.

 

1st, we create an transaction advice telling spring to monitor all methods for transaction. The aop:config tells aspectJ (won’t go into details about this for now) to monitor the package a.b.catalog.service and use our advise to process the calls to those method.

Done! I will do another follow up post on how our java code should look. Don’t want to bore everyone with one long post!

Maven: Display classpath

Debugging maven for classpath issues might sometimes be hard if you do not know where it is looking, here a simple plugin snippet for your pom.xml to display the classpath.

 

Liferay Service Builder Deployment Issue #1: ClassNotFoundException

I had a portlet project which was running smoothly already for a day. The service and persistence Layer was using Liferay’s Service Builder. It is pretty easy to use once you get the hang of it. I might have to write up a tutorial on it after I get more familiar with it.

Anyways, today, I realized that I have the wrong package and proceeded to fix it. I know that I had to delete the java file generate by service builder when I first ran it with the wrong package because service builder wouldn’t know to clean them. Backed up my changed to my impl classes too.

Before:

After:

Everything went without a hitch until I deployed my application. Every time I deployed my applcation, I get an error regarding my old generated classes! I was pretty sure I cleaned everything. The error looks like below:

This annoyed me so much that I had to stop what I was doing and investigate why this was happening. Gooling around didn’t help, neither Liferay’s website nor manning’s Liferay in Action forum had answer for this.

Went on my linux console and searched the class it was mentioning

Voila, found 2 files still referencing this old method, portlet-hbm.xml and portlet-orm.xml. So I went ahead and proceeded to fix those two files.  These are mapping files like our regular hinbernate mapping file. But much to my surprise, it wasn’t the end of it. Soon after I redeployed my portlet, it still gave me the error! It was driving me crazy.

I realized soon enough that Service Builder must have generated some other file somewhere that I have not fixed but where are they? Grep only gave those shows 2 files. Well, an hour later, it came to me that Impl classes must be implementing an interface. So, somewhere, those interfaces are being referenced!

Turn out, I was right! Service Builder also generates other XML files namely, portlet-spring.xml, portlet-model-hints.xml. In my frustration, I never actually looked into what they contained so I do not have an example to show but delete the file and rerun service builder fixed the issue!

TLDR; delete portlet-spring.xml, portlet-model-hints.xml,portlet-hbm.xml and portlet-orm.xml under docroot/WEB-INF/src/META-INF and rerun ant build-service should fix the java.lang.ClassNotFoundException while deploying your portlet in Liferay.