Matt RaibleMatt Raible is a writer with a passion for software. 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.

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;

    public Object getBean(String name) {
        if (ctx == null) {
            ctx = WebApplicationContextUtils
                  .getRequiredWebApplicationContext(servlet.getServletContext());
        }
        return ctx.getBean(name);
    }

This way, the UserManager implementation can be easier retrieved using:

    UserManager userMgr = (UserManagergetBean("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.

Posted in Java at Feb 05 2004, 12:52:18 PM MST 17 Comments

How much CPU Power does a Java/Tomcat app need?

I tried posting the following to the tomcat-user list, but after not seeing it show up for 2 days, I'll just try it here.
----

I have developed a webapp that uses basic open source stuff (struts, hibernate,
etc.).  I've been developing/testing it on the following platforms - where it
works fine and runs lickedy-split:

OS X 10.3, 1.33 GHz, 1 GB RAM
Windows XP, 2.6 GHz, 1.5 GB RAM
Windows 2000 Server, 1 GHz, 512 MB RAM
Windows 2000 Server, 1.5 GHz, 256 MB RAM

All of these are running Tomcat 4.1.29 or 4.1.12.  I recently tried to deploy
it to the "test web server" (Windows 2000 Server) at my client and it runs 
dreadfully slow.  It takes almost 30 seconds to load a page.  The main difference
is that the test web server has a 667 MHz CPU.  It has 512 MB RAM, and we 
upgraded it to 1 GB, but that didn't help at all.  

I've recommended we get a faster CPU for the test web server, but I wanted to
confirm that this could be the source of the problem.  On this server, and the
1.5 GHz/256 MB RAM machine, IIS is integrated with Tomcat.  All machines are
running JDK 1.4.0 or above.

Any help is appreciated.

Posted in Java at Feb 05 2004, 07:38:05 AM MST 13 Comments

ActionForms: Struts' bastard child

Folks that rag on Struts seem to point to ActionForms as one of its major design flaws. I've been slightly frustrated with ActionForms this week, but overall, I think they're a good thing. It's possible my ActionForm affection is misguided. The major reasons I like them is because I believe they allow me to do stuff that is not possible in other web frameworks. I definitely could be wrong though, so I'm hoping the other framework authors/users will speak up and say "My framework does that!" Specifically, I'm talking to the WebWork, Tapestry, JSF and Spring folks.

I do wish that I could throw my POJOs up to my UI, so I hope the following things are possible with the WTJS frameworks. It would simplify things if I didn't need to transform POJOs -> ActionForms (particularly with Hibernate).

  • Validation and re-displaying the user's entered values. I love Struts' Validator. It's great how I can generate the validation.xml file with XDoclet and have a "required" struts.validator tag right next to a hibernate not-null="true" tag. Two questions:

    1. Can any of the WTJS frameworks re-display the user's entered values? Specifically, back into the input fields where the user entered them? I think this is important for useability.

    2. Do any of them have the ability to generate client and server-side validation, or at least declaratively write it in XML?

    I'd love to find a way to hack the Validator to allow you to define validation rules for a POJO and then use an Interceptor to validate it. I don't like how Spring requires you to write YAJC (Yet Another Java Class) to do validation.
  • Handling checkboxes. The basic reason for the reset() method in ActionForms is to handle checkboxes. Since unchecked checkboxes don't send a value - there needs to be a way to set a boolean back to null. I'm sure all of the WTJS frameworks support checkbox handling, I just want to make sure - and frankly - I'd like to learn a little more about how each framework handles it.

I guess there's only two reasons I like ActionForms - the major one being the ability to specify (and generate) my client and server-side validation in XML. If I don't find this same slick feature in the other frameworks, I might have to do a bit of hacking to do the Interceptor with Validator thing - but hopefully I won't need to go there.

Posted in Java at Feb 04 2004, 08:31:13 PM MST 25 Comments

[ANNOUNCE] Hibernate 2.1.2 Released

Hibernate 2.1.2 has been released. Looks like they fixed a whole sh*tload of bugs. Read the Release Notes or Download. All tests pass in AppFuse!

Posted in Java at Feb 04 2004, 04:18:51 PM MST 1 Comment

apache.org won't let e-mail through from comcast.net

I don't use my comcast.net account, but I do use their SMTP server to send e-mail. I've sent a few messages to the tomcat and ant mailing lists in the past couple of days, and they've never shown up. Today, I realized why. Howard says:

...it appears that there's a disruption which is preventing mail originating at comcast.net's domain from reaching apache.org's. This may have been going on for a week (its probably related to the massive amount of e-mail from the MyDoom virus).

I guess I'll have to resend those suckers from my Yahoo account. Even with this disruption, I still think Comcast's broadband is the best in the business. Who can complain about 2 MB/sec (downloads average 250K/sec)? OK, maybe it's not that today, but usually it's pretty close.

Posted in The Web at Feb 04 2004, 01:41:14 PM MST Add a Comment

Running AppFuse on Orion (a.k.a. OracleAs)

Mike Lawrence has been beating his head against the wall trying to get AppFuse running on Oracle App Server for the last few days. The good news is he finally got it working and he's written up some documentation. I wiki-fied his contribution and now I present you [How To run AppFuse on Orion|AppFuseOnOrion]. Enjoy!

Posted in Java at Feb 04 2004, 10:18:41 AM MST 2 Comments

Approved for Google Ads

After seeing that Tim Bray is making $500/month of Google Ads, I decided it was high time I try to get this site approved again. Low and behold it worked! So they've approved me, but I only want to show them when folks come from Google. As in, when the referer (yeah, I know that's spelled wrong, but it is in Java and JavaScript too) contains "google" - show the ads. Anyone know how to do this cleanly in Roller/Velocity? Or JavaScript? I tried the following, but it doesn't work:

if (document.referer != null 
    && document.referer.toString().indexOf("google") != -1) {
    // define variables
    document.write("<scr" + "ipt type='text/javascript' src='ads.js'><\/scr" + "ipt>");
}

Since Google is my top referrer - I think I'll get a fair amount of users seeing the ads, and it won't disturb the folks who come here just to read my ramblings.

Posted in Roller at Feb 03 2004, 08:10:33 PM MST 10 Comments

AppFuse Refactorings Part I: Changing directory structure

I changed the directory structure of AppFuse's "src" and "test" directories this weekend. Rather than:

src 
  - common
  - ejb
  - web

I changed it to:

src
  - dao
  - service
  - web

The change wasn't too difficult, but the results of doing it make me a bit sick to my stomach. I always new that the Managers in AppFuse were dependent on Struts, that's why I originally put them in the src/web/**/webapp/service folder. Now that I've moved them into the service folder, they don't inherit all the luxuries like struts.jar being in the classpath. Even worse, to compile the Managers, I have to compile any ActionForms, both from the build/web/gen directory, as well as from src/web/**/Form. This is because the Managers use BeanUtils.copyProperties() to transfer values from POJOs -> ActionForms and visa-versa.

Ech - this exercise has really shown me how tied together the different directories and layers are. I think I liked it better the other way - or maybe I just liked not knowing how tightly integrated everything was. ;-) The most frustrating thing turned out to be that Ant's <javac> task wanted to re-compile the generated ActionForm's each time I I ran "ant compile-service". Adding an <uptodate> property fixed this problem, but it seems like it should be easier than that.

I ended up putting the org.appfuse.model package in the "dao" directory. It just made things easier - since the model.* classes are used in my DAOs and the "test-dao" needs the XDoclet-generating Hibernate mapping files. I didn't want to have to depend on classes in the src/service directory to compile src/dao. It's bad enough I have to do that with the service-web stuff.

All in all, I'm happy with the refactorings, but implementing workarounds for the service-web relationship was no fun. I probably did this when I originally created AppFuse, but since I haven't heavily manipulated build.xml in so long - I've forgotten the trouble I went through.

Oh yeah, I also integrated Spring for binding the layers and configuring Hibernate. And Charles' persistent cookie strategy? That's done too. I'll write up details on both of these refactorings in the next couple of days.

Posted in Java at Feb 03 2004, 03:56:27 PM MST 10 Comments

One big Service class or several small classes?

I asked this question on the Spring Forums a couple of days ago, but I didn't get a response, so I'll try it here.

Looking through the Spring's petclinic and jpestore applications - both seem to advocate one single class to interface with the database (hibernate or dao/ibatis). I also noticed this pattern in Java Open Source Programming. Is this a recommended pattern or do you still think there's value in several service-level classes (i.e. one for each DAO)? I imagine the single interface and impl could grow quite large on a big project. In fact, in the Spring examples, the Manager isn't even a Business Delegate, it's really a Persistence Manager.

BTW, the Petclinic app is a helluva plug for Hibernate. The Hibernate implementation class is 53 lines, and the JDBC implementation class is 770 lines! If you're still using JDBC over Hibernate, please explain why you put yourself through the pain?

I do like the simplicity of the Single Manager approach, but I tend to do 1 Manager for each DAO (or something resembling this pattern). What do you advocate? AppFuse follows the 1-Manager to 1-DAO pattern. Should I switch to the Single Manager pattern?

Posted in Java at Feb 02 2004, 09:44:39 AM MST 19 Comments

JavaBlogs and Roller's duplicate post problem

Charles has figured out why JavaBlogs gets duplicate posts from Roller-based blogs. And Dave proposes a solution:

I just now changed the JRoller "absolute URL to site" setting to force the domain name to jroller.com. The setting was blank before.

Without this setting, the JRoller feeds were using whatever hostname was requested at cache refresh time. So if the first request after the cache timeout was for freeroller.net then the GUID's in the RSS feed would read freeroller.net until the next cache timeout.

This site was missing the absolute URL to site setting as well, so I changed it to http://raibledesigns.com. I'll try adding myself back to JavaBlogs aggregator and hope that works!

Posted in Java at Feb 02 2004, 08:46:25 AM MST 3 Comments