Gavin Terrill's Blog

Acegi Petclinic JUnit

My last post on how to use Acegi Security while JUnit integration testing drew a fair bit of traffic, so I thought I'd write a small Eclipse project that pulls all the bits together, and updated to run with Spring 2.0 and Acegi 1.0.3.

To build this project I followed the following steps:

1. Got petclinic 2.0.2 going (download Spring here) and followed the instructions in the readme.txt files.
2. Got acegi 1.0.3 (download Acegi here) and followed the instructions on integrating it with petclinic as described here (including the optional bonus section - "securing the middle tier").
3. (optional) Ran the JdbcClinicTests from within Eclipse. This allowed me to step through the code in the debugger.
4. Modified JdbcClinicTests so that it used the Acegi post-interceptor.

To get JdbcClinicTests working with Acegi (Step 4) I made the following changes:

1. Add

   /WEB-INF/applicationContext-acegi-security.xml

to JdbcClinicTests.getConfigLocations.

2. Applied the same changes to /test/../applicationContext-jdbc.xml that were done in step 2 above - i.e. add a "postInterceptor" entry to the clinic bean and create a "methodSecurityInterceptor" bean.
3. Add the acegi libraries to the debug profile, and include the war directory (so that it can find users.properties and the acegi context file). Here is a screen grab of my settings: Download acegi-debug-settings.gif

If you ran the project at this point you would get a AuthenticationCredentialsNotFoundException for every single test. To prevent this, we need to use a TestingAuthenticationProvider instead. I created a class called AcegiTestIntegration that does the replacement on the fly in its' constructor, and has a setAuthenticationToken method that sets up the security context.

For example, here is how it is initialized in the JdbcClinic.setClinic method:

acegiTestIntegration = new AcegiTestIntegration(getApplicationContext());
acegiTestIntegration.setAuthenticationToken(dianne);

The variable dianne is declared as:

private TestingAuthenticationToken dianne = new TestingAuthenticationToken("dianne", "emu", new GrantedAuthority[] {ROLE_USER});

Now if you ran the project, every test would pass except the last one - testInsertVisit - which would get an AccessDeniedException. Success! You have validated that only users with the supervisor role can invoke the method. Now, to get the unit test to pass, we simply catch the exception, and set up a token that should pass:

try {
 this.clinic.storeVisit(visit);
 fail("Should of thrown an AccessDeniedException because dianne is not ROLE_SUPERVISOR");
} catch (AccessDeniedException e) {
 // expected - dianne is ROLE_USER, not ROLE_SUPERVISOR
}
acegiTestIntegration.setAuthenticationToken(marissa); // ROLE_SUPERVISOR
this.clinic.storeVisit(visit);

That's it.

Choose from one of the following downloads:

• Download petclinic-acegi-junit.zip - The full source tree (including jar files) and eclipse project (12,603 KB).
• Download AcegiTestIntegration.java - AcegiTestIntegration source file (put this under petclinic/test/org etc) (2 KB).

Additional notes:

• An alternative approach you may want to consider is having seperate applicationContext-acegi-security.xml files - one for production and one for testing. The testing one would be configured to use a TestingAuthenticationProvider. The down side to this is having to move different configuration files around in the build script and/or keeping changes in sync between the files.
• AcegiTestIntegration could be configured as a bean and injected into the test class. In this case, make it ApplicationContextAware and move the code that is in the constructor to it's setApplicationContext method, then get rid of the constructor.
  

Please leave a comment if you find this useful, or have suggestions for improvements. Thanks.

ETags considered useful

Nice post about how using ETags can save you bandwidth and computation.

Summary: when you send something to a client, give them a token they can use later to see if that something has changed. If nothing has changed, then don't send anything.

I'd love to turn this on for our application somehow, but given the dynamic nature of it I suspect it could get a bit tricky. The stats Joe shows indicate that roughly 1 out 4 requests don't need a reply. I'd be interested to know what the breakdown of "user agents" making the requests were, as not every browser is ETag savvy. My other concern would be that once I got into the messy details, I would discover there are problems using this type of caching mechanism in a clustered environment.

How does that quote from go? - "If it was easy, everyone would be doing it."

How to fix schema info messages in Visual Studio 2005 when using App.config and remoting

Sorry for the title, but I'm hoping to save some time for people who are searching for a solution to this problem in the future.

I'm using Visual Studio 2005 (build 8.0.50727-4200) to create a project that uses .Net remoting. When I try to configure remoting using App.config via RemotingConfiguration.Configure(...), I get annoying messages in the error list window telling me that it "Could not find schema information for the element 'application'".   The problem is because DotNetConfig.xsd in c:\program files\microsoft visual studio 8\xml\schemas doesn't have all the bits required to understand remoting.

Here is how to fix the problem:

1. Open App.config
2. Select the XML | Create Schema menu option
3. Copy everything inside the <xs:element name="system.runtime.remoting"> tag to the clipboard
4. Open C:\Program Files\Microsoft Visual Studio 8\Xml\Schemas\DotNetConfig.xsd
5. Search for "remoting"
6. Change the line that says

   <xs:element name="system.runtime.remoting" vs:help="configuration/system.runtime.remoting"/>

   to

   <xs:element name="system.runtime.remoting" vs:help="configuration/system.runtime.remoting">
   </xs:element>

7. Paste the clipboard contents inside the remoting element

This will only pick up the elements and attributes you are currently using in App.Config. If you change the file you will have to go through this rigmorale again, or edit DotNetConfig.xsd by hand.

I imagine this will get fixed eventually, but in the mean time I hope this helps.

How to slow down your application - Part 1

I promise this will deliver at least a 200% slow down to your Hibernate app. Just add the following to your log4j file:

log4j.logger.net.sf.hibernate=DEBUG

My oh my, my log file overfloweth...

JUnit testing with Acegi Security

Here's a tip if you are trying to do some unit testing with Acegi Security - particularly if you are doing role based authorization of method calls on your manager objects via interception.

Basically, a secure method interceptor will a) need an authentication token to play with, and b) a way to  find out what authorities the user has.  We need to cater for this when running the tests.

Acegi Security conveniently provides a TestingAuthenticationToken for unit testing purposes so we are Ok with the token part. You will now need to provide a suitable authentication provider. Somewhat unsurprisingly, there is a TestingAuthenticationProvider that you can add to your Spring config file to accommodate this.

But here is the problem: we already have this configured for production using a different provider (obviously), so we would have to resort to changing the config files depending on if you are running tests or not. This is too fragile for me, so here is the essence of the tip: leave the configuration file alone and dynamically changes the provider in the setup of the unit test.

Here is some code that I have in my JUnit setUp() method:

        // Grant all roles to noddy.
        TestingAuthenticationToken token = new TestingAuthenticationToken(
                "noddy", "test", new GrantedAuthority[] {
                        new GrantedAuthorityImpl("User"),
                        new GrantedAuthorityImpl("Administrator") });
        
        // Override the regular spring configuration 
        ProviderManager providerManager = (ProviderManager) ctx.getBean("authenticationManager");
        List list = new ArrayList();
        list.add(new TestingAuthenticationProvider());
        providerManager.setProviders(list);
        
        // Create and store the Acegi SecureContext into the ContextHolder. 
        SecureContextImpl secureContext = new SecureContextImpl();
        secureContext.setAuthentication(token);
        ContextHolder.setContext(secureContext);

So... it sets up an authentication token, then resets the authentication managers' provider list with one that contains the TestingAuthenticationProvider. It then creates the context for the method execution.

The problem with this is it does it for every single test method - that is how JUnit works for better or worse.

Hope it proves useful for you.

Update 2007-01-31: I've updated this to work with Acegi 1.0.3 and Spring 2.0.2.

Eclipse 3.1

Wow - I just checked out the "New and Noteworthy" page for Eclipse 3.1 Milestone 4.

Looking good:

• Ant debugger
• Java 5 Annotation support
• Grouping multiproject projects
• Spell checker for property files (wonder how this works for I18n)
• Rerun failed JUnit tests first

M4 was released right on schedule, so I'm hoping to see M5 released on the 18th. (Salivating...) "Late June" can't come quick enough.

Is Tomcat the Reference Implementation?

You learn something new everyday.

What would you be lead to believe if you read this:

Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies.

That quote is the first sentence on the Apache Jakarta Tomcat home page. Well, it seems that  is a little misleading as Tomcat is *not* the reference implementation (see comments) of the Java Servlet and JavaServer Pages technologies.

A little further digging (ok, so a google search) reveals a bit more about it on the Sun Java Servlet Technology - Implementation and Specifications page:

Sun adapts and integrates the Tomcat code base into the J2EE Reference Implementation.

If you follow that link you'll see that the reference implementation is included with the whole J2EE stack. It be true then.

Interestingly enough, I guess at one time (mid 2002) it was  considered the RI, unless the author of this article was also under the misconception.  Anyway, I think it is fair to say the Tomcat engine is unlikely to veer away from the spec too much.  Does it make any practical difference either way? Probably not.

File system or BLOB?

At Karora, we have a document management engine that saves files in a "repository" (abstraction). The idea was that you could choose between saving files on the file system, or in a BLOB column of a database, when setting up the system.

I'm trying to figure out what the pros and cons each are. Here's what I've thought of so far:

	File System	BLOB Column
Good	Simple Administrators can "see" the files by browsing the file tree Ability to use a SAN solution Ability to reuse existing file system tools (e.g. virus scanners)	Easier to backup  both the database and files at the same time Transactional integrity with inserting the metadata and content. Most file systems aren't transactional.
Bad	Easy for the metadata to get out of sync with the database, through files being moved around or deleted outside of the system.	A client told us that a competitor's system that uses BLOBS causes great pain to the backup software, which gets confused when content is changed, causing the entire database to be backed up, instead of increments. (This sounds like more of an issue with the backup software than anything to me). Would file size be an issue? I mean how much stuff can you can you stuff into a BLOB column anyway? We manage files over 100 megs. I suppose you could spread chunks of the file across rows, but that seems to be adding complexity to me. I wonder about the concurrency aspects - BLOB's don't seem to be good at lots of simultaneous activity on the same record. I also wonder about the read performance. Reading from a BLOB is slower than reading from a file on disk.

So far, we've written the file system repository and everyone seems pretty happy. Doesn't really seem to be any big demand for the BLOB solution, so I think we'll just leave it as is for now.

I'd be real interested to hear other people's comments/experiences on this.

Sitemesh AppFuse Blank Page

Posting this in the hopes of saving some googlers a few hours of fustration.

I'm working on a web application and using Sitemesh (actually, the application was "ignited" by AppFuse, to which I give a huge thumbs up - thanks Matt Riable). Anyway, we were experiencing a problem yesterday where the mainMenu page was blank. I discovered that turning off the filter mapping for the sitemesh  fixed the problem, but of course it meant there were no decorators. Turns out it was due to the commented out dispatcher entries in web/filter-mappings.xml file. Removing these entirely, then recreating the web.xml file (using Ant) did the trick.

For reference, the offending lines in filter-mapping.xml looked like this:

<filter-mapping>
    <filter-name>sitemesh</filter-name>
    <url-pattern>/*</url-pattern>
    <!-- These are needed by Tomcat 5 for forwards -->
    <!--dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher-->
</filter-mapping>

Whereas they should look like this:

<filter-mapping>
    <filter-name>sitemesh</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Update 2004-12-18: As Joe points out in the comments, I should have mentioned that this was happening on a Windows 2000 box, running Java 1.4.2_06 and using tomcat 5.0.28.