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.
You searched this site for "param". 72 entries found.

You can also try this same search on Google.

Fun with Log4J and JBoss

I've had the pleasure of working with JBoss (3.2.5) and an AppFuse-based application for the past week. It was fairly easy to setup thanks to Rick Hightower's instructions. AppFuse uses commons logging (like many of its open-source dependencies), but uses log4j to control what gets printed to where. By default, it changes Hibernate and Spring to use WARN and the application classes to use DEBUG. For most containers, this works great. Drop in the WAR, or package it in an EAR and voila - your logging statements show up in the console. Not so with JBoss. Spring and Hibernate use INFO and I can't get any debug statements to show from my classes.

I shouda known this would be a pain since Rick wrote "Setting up logging is a pain in JBoss. Don't mess with the console log... it misbehaves. Create a file logger and tail it.". Is this the best practice for logging with Log4J in JBoss?

You'd think printing to the console would be easy. This wiki page even makes it look easy: change your log4j.properties to log4j.xml and add a <class-loading> snippet to your jboss-web.xml. Unfortunately, I get this nice error message:

00:21:17,593 WARN  [DeploymentInfo] Only the root deployment can set the loader repository, ingoring
 config=LoaderRepositoryConfig(repositoryName: log4j.config:loader=appfuse.war, repository
ClassName: org.jboss.mx.loading.HeirarchicalLoaderRepository3, configParserClassName: org.jboss.mx.l
oading.HeirarchicalLoaderRepository3ConfigParser, repositoryConfig: java2ParentDelegation=false)

Any ideas are appreciated - it seems wrong that I have to write to file just to tail it so I get the same console behavior I get with other servers.

Posted in Java at Oct 29 2004, 12:12:15 AM MDT 7 Comments

Make your JUnit Tests run faster when using Spring

JRoller is down, and has been down for an hour or so - so I've decided to post this Spring Live entry here.

I discovered an interesting thing today about Spring and my JUnit tests. I noticed that the VelocityEngine I was setting on my PositionManager was getting initialized once for each test* method in my Test. This means that since my PositionManagerTest has 10 test methods - it would load the context 10 times.

Loading the context so many times was because the following code was in my Test's parent's constructor:

    ctx = new ClassPathXmlApplicationContext("/applicationContext.xml");

I suppose I expected any constructor-iniatialized variables to be initialized once and only once. So I figured out a solution to make my JUnit tests run faster. By making the ctx variable static, and loading the file in the member variables definition, I greatly reduced the amount of time needed to run tests. Below is the new code I'm using:

    protected static ApplicationContext ctx = 
    	new ClassPathXmlApplicationContext("/applicationContext.xml");

By doing this, the ApplicationContext is only set once, and my tests run much faster. Here's some performance comparisons from Struts Resume:

Average time to run "ant test-dao": 36 seconds
Average time to run "ant test-dao" after this change: 26 seconds

A 10 second improvement - that's crazy talk dontcha think?! I've tried it on single tests, as well as suites - and it seems to improve performance by approximately 30% across the board.

Because of this experience, I have to recommend that when you write JUnit tests that use Spring - you should initialize your ApplicationContext in a static member variable. It seems to be the best performing and logical choice. Of course, if I'm off my rocker - please let me know.

On a sidenote, it would be cool if Roller allowed me to turn off comments for a single post. I like how Simon posts stuff on java.net and then aggregates it to his personal weblog.

Posted in Java at Apr 08 2004, 01:22:14 AM MDT 21 Comments

[ANN] Struts Resume 0.9 Released!

Struts Resume 0.9 is a major improvement over 0.8. Not only did I upgrade all the code to use AppFuse 1.4 (release notes), but I also removed Struts from the services layer. Moreover, you can actually enter almost all of the pieces of a resume and render it in HTML and Word format. The resume-entry piece (and sections you can enter) is largely based on what Monster.com uses. I may add other sections in the future (i.e. awards and publications).

The main reason this is not a 1.0 release is because an administrator is the only one who can edit the HTML template - and the Word/RTF template is not editable online. Allowing a user to override the default template(s) will be the primary goal in 1.0.

Here's a specific rundown of all the changes from the changelog:

Download (~10.5 MB for src, ~5.4 MB for bin), Online Demo and Homepage.

Posted in Java at Apr 05 2004, 05:02:22 AM MDT 12 Comments

AppFuse Refactorings Part III: Remember Me

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 and Spring Integration.

- - - -
AppFuse includes a Remember Me feature that works with Container-Managed Authentication. In version 1.3 it works by setting a few cookies: username, password and rememberMe. The last one being a simple flag that the user wants to be remembered. Then a LoginFilter checks for the rememberMe cookie, and if present, logs in the user using the other cookie values. The obvious issue with this is that the password being sent and stored on the user's browser.

This was easily solved in Tomcat 4 by placing the form-login-page and form-error-page under a "security" directory and then setting cookies on the /appfuse/security path. This way, since no other part of the app can access /appfuse/security, these cookies can never be retrieved in any part of the application. The problem is that this didn't work in Tomcat 5 since it forwards to the login page (rather than redirecting). Since forwarding is obviously a better solution (user's can't bookmark the login page), I needed a new way to implement the Remember Me feature.

To my knowledge, cookies can only be stolen if someone is able to login to your AppFuse app and insert JavaScript to send the "document.cookie" value to an external URL. So for AppFuse, it's likely that stealing cookies is not much of an issue. However, for applications like Roller, it is an issue - since other bloggers on the same server (i.e. JRoller) could put JavaScript on their blog to grab cookies from other users.

Just as I was about to give up searching for solutions, along came Charle's persistent cookie strategy. Here's how I implemented it in AppFuse. Hopefully it follows all the rules and is a good solution. Here's what I did make it happen.

- - - -
Step 1: Setting the cookie.
Scenario: A user logs in and selects the "Remember Me" checkbox.
What Happens: When a user clicks the Login button, they submit to a LoginServlet that redirects them to "j_security_check" to take advantage of Container-Managed Authentication. This servlet is responsible for ensuring an SSL Login (if enabled), encrypting the user's password (if enabled) and also sets a session variable to indicate the user wants to be remembered. After authenticating, the user will hit the ActionFilter, where the following code sits:

    // if user wants to be remembered, create a remember me cookie
    if (session.getAttribute(Constants.LOGIN_COOKIE!= null) {
        session.removeAttribute(Constants.LOGIN_COOKIE);
        String loginCookie = mgr.createLoginCookie(username);
        RequestUtil.setCookie(response, Constants.LOGIN_COOKIE,
                              loginCookie, request.getContextPath());
    

In the above code snippet, the UserManager.createLoginCookie(username) method is responsible for creating a new cookie string and storing this information in the database.

    public String createLoginCookie(String usernamethrows Exception {
        UserCookie cookie = new UserCookie();
        cookie.setUsername(username);

        return saveLoginCookie(cookie);
    }
  
    /**
     * Convenience method to set a unique cookie id and save to database
     @param cookie
     @return
     @throws Exception
     */
    private String saveLoginCookie(UserCookie cookiethrows Exception {
        cookie.setCookieId(new RandomGUID().toString());
        dao.saveUserCookie(cookie);

        return cookie.getUsername() "|" + cookie.getCookieId();
    }

The RandomGUID is a class I found on Java Exchange. Once the rememberMe cookie was set, I had to configure LoginFilter.java (mapped to form-login-page and form-error-page) to look for this cookie. This brings us to Step 2.

- - - -
Step 2: Using the cookie to login the user.
Scenario: A User has already logged in successfully with "Remember Me" enabled.
What Happens: When the login page is served up to the user, the LoginFilter is invoked and it checks the validity of the "Remember Me" cookie.

    Cookie c = RequestUtil.getCookie(request, Constants.LOGIN_COOKIE);

    WebApplicationContext context = 
        (WebApplicationContextconfig.getServletContext().getAttribute
        (WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
    UserManager mgr = (UserManagercontext.getBean("userManager");
  
    if (c != null) {
        try {
            String loginCookie = mgr.checkLoginCookie(c.getValue());

The UserManager.checkLoginCookie(value) method looks up a record based on the random GUID, and if it finds a match, it creates a new GUID and saves it in the database. If null is returned, it means the cookieId doesn't exist, and the login proceeds as it normally would. Below is the guts of the checkLoginCookie() method.

    public String checkLoginCookie(String valuethrows Exception {

        String[] values = StringUtils.split(value, "|");

        if (log.isDebugEnabled()) {
            log.debug("looking up cookieId: " + values[1]);
        }

        UserCookie cookie = dao.getUserCookie(values[1]);

        if (cookie != null) {
            if (log.isDebugEnabled()) {
                log.debug("cookieId lookup succeeded, generating new cookieId");
            }

            return saveLoginCookie(cookie);
        else {
            if (log.isDebugEnabled()) {
                log.debug("cookieId lookup failed, returning null");
            }

            return null;
        }
    }

You can see from this, that if the lookup succeeds - a new cookieId is saved and returned. If a not-null cookieId is returned, the remember me cookie is updated, the user is looked up and the Filter forwards an authentication request (with username/password) to the LoginServlet. The Filter also sets an attribute to let the application know that this user authenticated via cookies. This is important so that cookie-authenticated users cannot change passwords. When using cookie-authentication, the password field is hidden and a message warns the user that they must logout/login to change passwords.

Lastly, I had to come up with a solution to remove these login cookies.

- - - -
Step 3: Allow the user to clear their login cookies.
Scenario: A User has already logged in successfully with "Remember Me" enabled.
What Happens: For this, I implemented a simple solution. When a user logs out, all persistent login cookies are removed.

I don't know if it's best to divulge the details of AppFuse's cookie login strategy. However - it *is* open source - so folks can find figure it out if they really want to. By exposing it to the world, I hope to get the most robust solution possible.

Next up, how I replaced Hibernate with iBatis. Using Spring, it only took me a few hours! Pretty slick, eh? ;-)

Posted in Java at Feb 10 2004, 10:35:37 AM MST 4 Comments

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

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

Running AppFuse on Resin

Want to run AppFuse on Resin? I did some research (a.k.a. banging my head against the wall) and figured out how this morning. It isn't too tough, now that I've figured out how. You can read about my journey on my wiki, or follow the following steps (for the CVS version):

  • Edit $RESIN_HOME/conf/resin.conf and add the following after the last </web-app> closing tag.
<resin:include href='appfuse.conf'/>
  • Download appfuse.conf(info) and put it in the $RESIN_HOME/conf directory.
  • Put activation.jar, mail.jar and mysql-connector-java-3.0.9-stable-bin.jar in $RESIN_HOME/lib.
  • Remove password encryption by changing the Login Servlet's encrypt-password init-param (in web.xml) to false. You can do this in the build process by changing "encrypt.password" to false in app-settings.xml. You could also do it from the command line using -Dencrypt.password=false. For testing, you will need to change a number of files that have the encrypted password. Search for "536c0b339345616c1b33caf454454d8b8a190d6c" and change it to "tomcat".
  • Remove the <filter-mapping> for CompressionFilter.
  • To enable the "Remember Me" feature, remove the <c:if test="${rememberMeEnabled}"> check in loginForm.jsp. (AppFuse 1.3-dev)

DISCLAIMER: I did not thoroughly test that everything works, I just ran through a couple of pages.

Posted in Java at Jan 04 2004, 09:47:43 AM MST

A little EL Lovin' for the DisplayTag

Tim McCune submitted a patch for the Display Tag Library to add Expression Language support. I committed it today, along with a few other enhancements. You can read more on the displaytag-devel mailing list. Tim's patch was a nice clean approach to adding EL support. He just subclassed the existing tags and then evaluated the expressions. All I did to integrate was to create an "el" package under "tags" and added an additional .tld file. So there's really nothing that's taken away from the original tag library, and if you want EL support, you simply need to use the "*-el.tld" in your web.xml or change your URI to "http://jakarta.apache.org/taglibs/display-el". Of course, you'll need to include JSTL's JARs (standard.jar and jstl.jar) in your WEB-INF/lib to make this work. This patch included the ability to specify a titleKey attribute - a much asked-for feature.

I like Tim's approach so much, I might have to use it for Struts Menu. It's a slick way of supporting JSP 1.1 containers, and adding optional EL support for JSP 1.2 containers. I haven't had any feedback from the dev team, but hopefully this will make it into the next release.

Posted in Java at Jan 02 2004, 10:52:46 PM MST 10 Comments

My IDEA Evaluation - Eclipse is better

I've been trying to use IDEA (on OS X) for the past few weeks and I keep reverting back to Eclipse for features that seem to be missing. I know the features must be there, but I just can't find them. Why else would everyone like it so much? Sidenote: I've never used IDEA for a feature that doesn't exist in Eclipse - I'm sure there are some, I'm just not using them. It sure would be cool if someone created a HowTo explaining how to migrate from Eclipse to IDEA. In the meantime, I'll settle for posting my questions here:

  • Debugging in Tomcat - I'm currently using Sysdeo's Tomcat Plugin in Eclipse for Tomcat 4.1.27. It's super easy to setup and use - I expect the same ease-of-use from IDEA. I haven't looked much, but I'd love to hear feedback on IDEA's Tomcat debugging support.
  • Renaming a variable in a JavaBean renames getter and setter methods. Sounds simple enough, in my 10 second search, I couldn't find it. In Eclipse, right-click -> Refactor -> Rename.
  • Override/Implement methods (from parent classes and interfaces). Right click -> Source -> Override/Implement methods in Eclipse.

I'll add more as I think of them throughout the day. So far, I like IDEA, but to be honest - it's not saving me any time over Eclipse. It also locks up as much as Eclipse and it's responsiveness is still a big sluggish on OS X (10.2.8) with 1 GB of RAM (1.33 MHz processor). Hopefully Panther will make both IDEs faster. Two weeks ago, I was thinking of buying it (as well as Dreamweaver) - now I'm frustrated with IDEA's lack of features and Dreamweaver's slowness. I'll probably pass on shelling out the cash since Eclipse and BBEdit are giving me all the features I need in IDEA and Dreamweaver.

Posted in Java at Oct 20 2003, 06:17:51 AM MDT 22 Comments

Log4J: 2 Appenders - one gets errors, other gets all (doesn't work)

I sent a message to the log4j-user mailing list this afternoon, but have not received a response - so hopefully someone can help me out. Here's the problem I'm having:

I have two appenders - a console and a file.  I want all messages to 
go to the console and only <= error to go to the file.

In my file appender, I have a filter to only get the error messages:

<filter class="org.apache.log4j.varia.LevelRangeFilter">
  <param name="LevelMax" value="ERROR" />
</filter>

Then in <root> I have:

  <root>
    <level value="DEBUG"/>
    <appender-ref ref="CONSOLE"/>
    <appender-ref ref="FILE"/>
  </root>

From the documentation I've read (i.e. http://tinyurl.com/meef), this
*should* work.  However, all messages get logged to both the console
appender and the file appender.

Any advice is appreciated.

Posted in Java at Sep 05 2003, 10:11:38 PM MDT 6 Comments