Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book 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 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.
You searched this site for "appfuse". 771 entries found.

You can also try this same search on Google.

Java.net vs. SourceForge

I think it's about time I moved AppFuse from the Struts project on SourceForge to its own project. That way, I'll have more control over controlling spam on mailing lists, adding developers and other such stuff. So the question is - should I stick with SF or move to java.net? I'm fairly happy with SF, except for their recent CVS hiccup and regular CVS outages. It's cool that java.net gives you a wiki, but I doubt I'll convert all my JSPWiki wiki pages to java.net's wiki syntax (whatever it is). So I guess the question is for you folks that have used both (i.e. OpenSymphony developers): Is java.net better than SF?

Dave asked this same question in June of last year - and Roller still lives on SourceForge. I wonder if that's any indication?

Posted in Java at Feb 24 2004, 09:18:56 AM MST 6 Comments

Simplify your AppFuse Managers

I figured out a way to remove any ActionForm references from my Managers yesterday. It was pretty simple, but I thought others might benefit from this knowledge. Basically, you just need to add a couple methods to your BaseManager.java file. Here is the latest one from CVS HEAD. Then you can pretty much eliminate any *Form references in your Manager by using the convert(Object) method. This method will convert POJOs <-> Forms and vise versa. You will likely have to do some tweaks on the package names if you're using anything < v1.4. Looking at this diff of the UserManager before and after this change will show you what's changed.

I started this task thinking I could remove the need for Forms in my classpath when compiling the service layer. However, I soon discovered that my Tests have Forms all over the place - since they replicate what my Actions will pass in. Oh well, at least my code is a bit cleaner now.

Of course, this code will become even simpler when I start using an MVC Framework that allows my POJOs to be my data handlers on the UI. These frameworks make me question if I even need Managers. Then again, it's nice to unit test what your DAOs are returning/receiving from the web layer.

Posted in Java at Feb 19 2004, 11:28:41 AM MST 2 Comments

How do you i18n your drop-downs?

As I'm developing this morning and pulling a drop-down list from the database, it hit me - I'm not internationalizing these drop-down values. Sure, putting them in the database makes it easier for admins to edit the values, but if a user visits the site with a Spanish locale, they're going to get English drop-downs. So how do I fix this?

Is the best solution to put the drop-down choices in Struts' ApplicationResources.properties file so that I can render the values with <bean:message/> or <fmt:message/>? How do you do it in your webapps?

In some cases, I guess it doesn't matter as the values need to be in English. Take for instance, AppFuse's edit user screen (user/pass: mraible/tomcat). The list of roles comes from the database and should always be in English because the form-based authentication depends on having an English role_name value in the user_role.role_name column - since this is the value coded in web.xml.

Posted in Java at Feb 18 2004, 10:37:10 AM MST 8 Comments

AppFuse 1.3 vs. 1.4

Mike Lawrence (the guy who wrote the AppFuse on Orion tutorial), sent me an e-mail yesterday asking about AppFuse 1.3 (the latest release) vs. 1.4 (still in CVS).

Spring
This looks like a pretty new framework. I wonder how stable it is? 

How far along are you with 1.4? You've made more changes to 1.3 to move
to 1.4 than I've made to 1.3. So, I'd be better off just taking your 1.4
base and integrating my changes.

Did you eliminate struts as the MVC framework?

Doesn't this invalidate your awesome AppFuse tutorials?

I'd really like to stay in sync with your new release, however, I've got
major production deadlines to meet. It would stink if I automated a
bunch of stuff for 1.3 that you couldn't use in 1.4. Yet, if I move to
1.4, will I be facing stability issues and no tutorial docs?

I figured it'd be better if I answer his questions here, as other folks might be wondering the same thing.

Spring - how stable is it?

As with most open source projects, the version number doesn't always indicate the stability of a product. Roller hasn't reached 1.0, but I would venture to say it's a mature and stable product. If you asked this question on the Spring mailing list, you'd likely received a lot of responses saying that it's very stable and used in many production systems. IMO, it's a very stable framework and likely to be the next Struts (in terms of popularity). I don't know that it's MVC framework will be that popular, but it's persistence support classes, declarative transactions and AOP framework are pretty slick. The fact that it integrates smoothly with all leading MVC frameworks is a nice touch too.

I think the best answer is - you need to work with Spring and then decide for yourself. I love writing one-line DAO methods for Hibernate...

How far along are you with 1.4?

If you're already started an application with AppFuse version x, then you should stick with AppFuse version x until your project is finished. It's often a real pain to upgrade an existing app to use the latest stuff, and probably unlikely you'll gain that much value. However, if you're not under a tight deadline - and you really need something in a more recent release - it makes sense to upgrade. The tutorial I wrote on upgrading a 1.3 app to 1.4 is probably a one-time thing. I don't plan to do an upgrade document between all releases.

That being said, if you have enchancements for AppFuse and want me to roll them into the main code base, the best way is to create patches for the CVS version and then it'll be easier for me to figure out what you changed.

Did you eliminate struts as the MVC framework?

Definitely not - Struts will remain as the standard MVC framework because it is the most popular and most AppFuse users will likely use it. When I add MVC alternatives, they will be packaged similar to the iBATIS option - so you'll have to install them. Most MVC options will likely rip out Struts and replace it with their own stuff.

Doesn't this invalidate your awesome AppFuse tutorials?

The tutorials will be updated to support the latest release. I hope to have some time in early March to update these. As soon as I do, I'll release 1.4.

I'd really like to stay in sync with your new release, however, I've got major production deadlines to meet. It would stink if I automated a bunch of stuff for 1.3 that you couldn't use in 1.4. Yet, if I move to 1.4, will I be facing stability issues and no tutorial docs?

Staying in synch with AppFuse as I push out new releases is probably a waste of your time. I did it with Struts Resume for a long time, and it's a lot of work trying to keep up. I firmly believe that each release of AppFuse has been a solid one - they just keep getting better. The only reason to upgrade is for new features and/or bug fixes. I believe that 1.4 will be just as stable as 1.3 and there will be tutorial docs when its released. As far as your automation stuff, the best way to get that added is send me patches against CVS.

BTW, Mike has integrated Middlegen into his AppFuse-based project. He's also working on generating stubs of a lot of the DAO/Manager/Action files - I believe that's his automation stuff. Thanks for giving back so much to AppFuse Mike - now if I only had more time to keep up with your enhancements. ;-)

Posted in Java at Feb 18 2004, 05:11:18 AM MST 2 Comments

Good Ant Tip

Nick has an Ant tip that I can put to good use.

This A little-known Ant feature is the hyphenated target name. If you have a target name that starts with a "-", such as "-test-setup", you will not be able to call that target from the command line. Developers creating utility targets in their build.xml files can use this to avoid confusing other developers with irrelevant support targets.

There are a fair amount of internal targets in AppFuse that don't need to be visible and can't be really be called from the command line. Last time I checked, IDEA and Eclipse both allowed hiding of internal targets - so I rarely see these, but it might be a good idea to make them more explicit. I'll put it on my what-I-can-do-when-I-get-bored list.

Posted in Java at Feb 17 2004, 09:23:10 AM MST 1 Comment

Wanna use Spring in your AppFuse-derived webapp?

Yesterday, I ported an AppFuse application (based on 1.3) to use all the latest stuff I've done in the last month. Basically, I just renamed and reorganized the directory structure, integrated Spring to bind everything together, and implemented the new Remember Me functionality. If you want to upgrade your (AppFuse-derived) webapp to use Spring, I wrote up an article on how I did it. It's quite a process, but hopefully this article will make it a lot easier. Now I can use Tomcat 5 as my primary app server (vs. Tomcat 4) - sweet!

Posted in Java at Feb 13 2004, 09:40:59 AM MST 3 Comments

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...

Posted in Java at Feb 13 2004, 09:06:09 AM MST 2 Comments

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 =
    getHibernateTemplate().find("from User u where u.username=?", username);

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.

Posted in Java at Feb 11 2004, 10:09:23 PM MST 10 Comments

[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.

Posted in Java at Feb 11 2004, 05:15:33 PM MST Add a Comment

Where do you put your extensions in a CVS tree?

AppFuse Directory Structure Now that I'm starting to add extensions to AppFuse, where should I put them in the source tree? I followed the Jakarta convention and put the ibatis install in the contrib folder, but I don't know if that's the best place for it. All the tools folder has in it is Erik Hatcher's StrutsGen tool - maybe that's a good place for all the extensions (ibatis, spring, webwork, tapestry)? Whaddya think? Where do you put extensions in your source tree?

Posted in Java at Feb 11 2004, 10:54:43 AM MST 1 Comment