Pro JSP gets 10 Horseshoes!
Gregg Bolinger has reviewed Pro JSP and gives it 10 horseshoes! Very nice - thanks Gregg! The book from which AppFuse was born...
The Angular Mini-Book is a
guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and
deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.
Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.
For book updates, follow @angular_book on Twitter.
The JHipster Mini-Book is a
guide to getting started with hip technologies today: Angular, Bootstrap, and Spring
Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.
This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.
For book updates, follow @jhipster-book on Twitter.
10+ YEARS
Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.
RECENT ENTRIES
You searched this site for "<a href=".
3,022 entries found.
You can also try this same search on Google.
AppFuse Refactorings Part IV: Replacing Hibernate with iBATIS
This is a continuing series on what I'm doing to make AppFuse a better application in Winter/Spring 2004. Previous titles include: Changing the Directory Structure
, Spring Integration and Remember Me refactorings.
- - - -
On my last project, we ported an existing JSP/Servlet/JDBC app to use JSP/Struts/iBATIS. In the process, I got to learn a lot about iBATIS and grew to love the framework (although I prefer to spell it iBatis). It was super easy to port the existing JDBC-based application because all of the SQL was already written (in PreparedStatements). Don't get me wrong, I think Hibernate is the better O/R Framework of the two, but iBATIS works great for existing databases. The best part is that iBATIS is just as easy to code as Hibernate is. For example, here's how to retrieve an object with Spring/Hibernate:
List users =
|
And with Spring/iBATIS, it requires a similar amount of Java code:
List users = getSqlMapTemplate().executeQueryForList("getUser", user);
|
The main difference between the two is that iBATIS uses SQL and Hibernate uses a mapping file. Here's the "getUser" mapped statement for iBATIS:
<mapped-statement name="getUser" result-class="org.appfuse.model.User">
SELECT * FROM app_user WHERE username=#username#;
</mapped-statement>
Spring makes it super easy to configure your DAOs to use either Hibernate or iBATIS. For Hibernate DAOs, you
can simply extend HibernateDaoSupport and for iBATIS DAOs you can extend SqlMapDaoSupport.
Now to the point of this post: How I replaced Hibernate with iBATIS. The first thing I had to do was write the XML/SQL mapping files for iBATIS. This was actually the hardest part - once I got the SQL statements right, everything worked. One major difference between iBATIS and Hibernate was I had to manually fetch children and manually create primary keys. For primary key generation, I took a very simple approach: doing a max(id) on the table's id and then adding 1. I suppose I could also use the RandomGUID generator - but I prefer Longs for primary keys. Hibernate is pretty slick because it allows easy mapping to children and built-in generation of primary keys. The ability to generate the mapping file with XDoclet is also a huge plus.
As far as integrating iBATIS into AppFuse, I created an installer in contrib/ibatis. If you navigate to this directory (from the command line), you can execute any of the following targets with Ant. It might not be the most robust installer (it'll create duplicates if run twice), but it seems to work good enough.
install: installs iBatis into AppFuse
uninstall: uninstalls iBatis from AppFuse
uninstall-hibernate: uninstalls Hibernate from AppFuse
help: Print this help text.
All of these targets simply parse lib.properties, build.xml and properties.xml to add/delete iBATIS stuff or delete Hibernate stuff. They also install/remove JARs and source .java and .sql files. If you're going to run this installer, I recommend running "ant install uninstall-hibernate". Of course, you can also simply "install" it and then change the dao.type in properties.xml. This will allow you to use both Hibernate and iBATIS DAOs side-by-side. To use both Hibernate and iBATIS in an application, you could create an applicationContext-hibatis.xml file in src/dao/org/appfuse/persistence and change the dao.type to be hibatis (like that nickname ;-). In this file, you'd have to then define your transactionManager and sqlMap/sessionFactory. I tested this and it works pretty slick. Click here to see my applicationContext-hibatis.xml file.
Some things I noticed in the process of developing this:
- Running "ant clean test-dao" with iBATIS (28 seconds) is a bit faster than Hibernate (33 seconds). I'm sure if I optimized Hibernate, I could make these numbers equal.
- The iBATIS install is about 500K, whereas Hibernate's JARs are around 2 MB. So using iBATIS will get you a slightly faster and smaller AppFuse application, but it's a bit harder to manipulate the database on the fly. There's no way of generating the tables/columns with iBATIS. Instead it uses a table creation script - so if you add new persistent objects, you'll have to manually edit the table creation SQL.
Hibernate is still the right decision for me, but it's cool that iBATIS is an option. Even cooler is the fact that you can mix and match Hibernate and iBATIS DAOs.
[ANN] Spring 1.0 RC1 Released
Download or read the (rather long) set of release notes. The good thing is that all tests pass with AppFuse - so that seems like a good release to me! You can also read a condensed version of the release notes.
[DJUG] Hibernate and Jabber Tonight
Tonight's Denver JUG should be good. The basic concepts meeting is on Hibernate and the main show is on Jabber: XMPP and Jabber Streaming Objects library. Nice! It's snowing like the dickens right now so getting there might be tough. Good thing I live close to downtown! The meeting is actually located in the same building where Julie works.
Update: Tonight's meeting was pretty good, but kinda boring. I didn't learn anything new in the
Hibernate session - but I did see Chris do a lot of stuff via command line (vs. Ant). I do everything in Ant, so
I was again able to see the beauty of Ant and Hibernate's <schemaexport> task.
The Jabber talk was interesting but dry - probably because Peter and Matt didn't
have a presentation or agenda for the meeting. Rather, they just stood up and talked about Jabber and its
XMPP Protocol. From what
they said, Jabber's streaming XML protocol is being used for a lot of things besides Instant Messaging. It's biggest feature seems
to be presence - the ability to know when someone (or something) is online. For using Jabber in your
Java applications, you might want to look at Matt's JSO Project. While
I'm at it, I might as well mention my article describing how to setup a Jabber Server.
Hibernate and iBatis co-existing
AppFuse is in an interesting state right now. In order for me to easily switch to using iBatis for the DAO layer, I left all the Hibernate stuff intact and just added iBatis classes and JARs. The next step is to extract the iBatis stuff into a separate CVS module and write a build.xml file to replace the Hibernate implementation with iBatis.
The one thing that will suck, in the iBatis version, is that the database can't be dynamically created from POJOs. However, if you're going to use the iBatis implementation, its likely that the database (or SQL) already exists. The reason I'm writing this post is because right now, in CVS, you can change the dao.type property to "ibatis" or "hibernate" when building and Voila! - that's the implementation you'll get. I see no reason why any project would ever want to have both implementations (maintenance would be a nightmare), so that's why I'm extracting the iBatis stuff in the next few days.
Tapestry looks very nice
While leaving a comment on my ActionForms: Struts' bastard child post, Erik Hatcher sounds like a broken record:
> When are you going to just quit asking questions and try out Tapestry? > You can build it from CVS HEAD easily or just grab a 3.0 binary (currently > beta, but way stable). Drop in the WorkBench WAR file and see for yourself.
So I took 5 minutes and downloaded and deployed the WorkBench WAR. Check it out if you like. Looks pretty nice to me. The DatePicker is pretty cool, but it shows up in the wrong spot on Firefox - and it's annoying that I can't close it just by clicking on the screen somewhere (like most popup calendars). Also the Chart doesn't work on my Linux box (it worked fine on Windows).
However, if you're looking for something like the DisplayTag, Tapesty has that. The URLs it constructs for everything look a little ridiculous though. I wonder if a Filter with smarts could pretty those up?
Mozilla Firebird 0.8 - I'm not impressed
I downloaded Mozilla Firefox (formerly known as Mozilla Firebird) for my Mac this morning and I'm definitely not impressed. I can't change the fonts and there's no scrollbar when I visit any sites. What a CF. As for Windows, I can't even download the installer. Too bad - this release had real potential.
[ANN] WebWork 2.0 and XWork 1.0 Released!
From the WebWork mailing list:
I'm pleased to announce the release of WebWork 2.0. You can download it at: https://webwork.dev.java.net/files/documents/693/2886/webwork-2.0.zip XWork 1.0 has also been released and is available at: https://xwork.dev.java.net/files/documents/709/2885/xwork-1.0.zip Thank you to everyone who provided patches, support, and ideas for over the past year to get this project from initial concept to completion.
Congrats to all who lent a hand in getting this release out. We all know that releasing software is a great feeling - hope these guys enjoy a night or two of good sleep.
It looks like Spring 2004 is going to be a fun time - WebWork 2.0, Spring 1.0, JSF 1.0 (in March) and Tapestry 3.0 is right around the corner. It's a good time to learn a new web framework. Now if we could only get them to agree on something like their choice of expression languages and validation. ;-)
iChat AV can now talk to Windows users!
I've been waiting for this for quite some time now.
iChat AV v2.1 Public Beta adds support for video conferencing with the AOL Instant Messenger 5.5 for Microsoft Windows.
I've been waiting for Windows <-> Mac video-conferencing so Abbie can talk/see her grandparents all the time. My dad has been video-conferencing with my uncle for years - it's about time I got up to snuff and started using this stuff. Sweet - too bad I'm leaving for Vegas tonight and my dad is leaving for Africa tomorrow! Maybe I should buy an iSight tonight so I can talk to Julie over the weekend. Is there an Apple Store in Vegas?
AppFuse Refactorings Part II: Spring Integration
I took some time last weekend and refactored AppFuse to use Spring to replace my Factories and Hibernate configuration. It only took me a couple of hours, which says a lot for Spring. I was amazed at how many things just worked. It actually lifted me out of my flu symptoms and made me feel euphoric. Or it could have been the Sudafed. In reality, I only replaced one Factory class (DAOFactory) - a fairly large class that instantiated DAOs using reflection and constructor variable inspection. I was also able to get rid of the ServiceLocator class, the getConnnection() stuff in ActionFilter and the hibernate.cfg.xml file.
The one thing I found when looking at the Petclinic and JPetstore apps was that they used an applicationContext.xml file for unit tests, and a (very similar) one for running the app in a container. To me, this was a warning sign. DRY (Don't Repeat Yourself) is a big reason for using XDoclet and I'm beginning to think that Spring could benefit from a little XDoclet lovin'. Anyway, back to the story.
I wanted to find a way to use the same XML files for testing and in-container execution. As you might know from Part I, AppFuse has 3 different tiers: dao, service and web. To run unit tests for the dao and service layers, I simply load a applicationContext.xml file in my JUnit test's setUp() method and go from there. I saw this in the petclinic app and found that it works pretty well. In the end, I decided to setup different XML files for each layer - applicationContext-hibernate.xml, applicationContext-service.xml and applicationContext.xml for the web layer. The main applicationContext.xml uses entity includes to reference the other two files.
The main pain I found was that the entity includes required different paths for tests vs. running in container. Basically, for tests, I had to use:
<!ENTITY database SYSTEM "applicationContext-database.xml">
While tests, using the ClassPathXmlApplicationContext required:
<!ENTITY database SYSTEM "WEB-INF/applicationContext-database.xml">
Using Ant to do a little replace logic allowed me to jump over this hurdle.
Using this setup, any new DAO definitions are added in src/dao/org/appfuse/persistence/hibernate/applicationContext-hibernate.xml, new Manager definitions (and declarative transaction settings) are be added in /src/service/org/appfuse/service/applicationContext-service.xml. The test-specific applicationContext-database.xml sits in the "test" directory and contains the following:
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location"><value>database.properties</value></property>
</bean>
<bean id="dataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName">
<value>${hibernate.connection.driver_class}</value>
</property>
<property name="url">
<value>${hibernate.connection.url}</value>
</property>
<property name="username">
<value>${hibernate.connection.username}</value>
</property>
<property name="password">
<value>${hibernate.connection.password}</value>
</property>
</bean>
While the applicationContext-database.xml for the web is simply:
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName"><value>jdbc/appfuse</value></property>
</bean>
To integrate Spring with my web layer (Struts), I just used the ContextLoaderListener in my web.xml file. I didn't see any point in bringing yet another JAR file into the mix.
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
Finally, to expose Spring's context to my Struts Actions, I added the following to my BaseAction.java class:
private WebApplicationContext ctx = null;
|
This way, the UserManager implementation can be easier retrieved using:
UserManager userMgr = (UserManager) getBean("userManager");
|
The best part about the Spring integration in AppFuse is: (IMO) its Hibernate support and how it drastically simplifies my Hibernate DAOs (as if Hibernate wasn't simple enough already). I dig the ability to specify declarative transactions, and this refactoring seems to have reduced the "src" distribution of AppFuse by 2 MB (to 10MB total)! I don't know where this came from since the Spring JAR is almost 1 MB. The appfuse.war is about 500 KB larger, but I can live with that.
Of course, all of this has been checked into CVS if you'd like to take a look.