Into the Garbage Chute, Flyboy

Hibernate/JPA objects in an HTTP session

2008-12-22T06:01:00.001-08:00

Last week I ran into an unexpected problem.

My application has a User object, which contains various fields. User also has a JPA-managed One-To-Many relationship with something called Store. This relationship had been working fine (and in fact through this story never stopped working).

For the first time, last week, I added a JPA-managed relationship between User and an entity class called QuickListEntry. QuickListEntry in turn has a relationship with Product, which in turn has plenty of other relationships with other entities.

We're using Struts 2, which is only marginally relevant here.

In Action A, we load up the User object from the SecurityContext, do some stuff with him, and then stuff him into the Session for access later. In Action B, we pull him out of the session and read his data, including his QuickListEntries. Well what do you know -- I'm getting a Hibernate LazyInitializationException. This has never happened before. It never happed with the User's Stores. What's going on?

Well here's what's going on. When the User is stuffed into the Session, he is disconnected from the JPA EntityManager. When he is pulled out of the Session, his extended relationships (User to QuickListEntry to Product) can't be followed, because he is disconnected from the EntityManager.

So the most correct solution in this case is not to stuff the User object into the Session at all. Either stuff the userid in there (which is probably harmless) and then use the userid to re-load the User from the DB in every Action's prepare() method; or pull the User from the SecurityContext on every page load (again, I'd put this in the prepare() method of every Action class).

Eclipse/Tomcat note to self

2008-12-17T07:07:00.000-08:00

Tomcat stops reading config data. Error with docBase, directory does not exist or is not readable. Here's what seemed to help:

Remove Tomcat as a server. Close and restart Eclipse. Add Tomcat as a server, with the correct project. Re-add /Catalina/localhost/my.xml. Make sure the entry is in my.xml and not in server.xml.

2008-09-26T07:04:00.000-07:00

Dear Internet,

I swear to god I'm going to buy http://www.localhost.com/ just so I can put a bigass message up on port 8080 saying REREAD YOUR URL, DUMBASS.

Sincerely yours,

Dumbass

I'll forget this if I don't save it

2008-05-20T11:16:00.000-07:00

If you use a framework like Struts, you will find that your internal file paths don't match your external ones. So you may have /foo/bar/myThingy.action (externally) which is mapped to /WEB-INF/secure/jsps/myThingy.jsp internally.

If you use SiteMesh, the decorator patterns you put in decorators.xml should be mappings to your internal directory structure, not your external structure.

The only valid measure of code quality

2008-03-25T16:23:00.000-07:00

http://www.osnews.com/story/19266/WTFs_m

Hibernate Session vs. EntityManager

2008-03-21T08:22:00.000-07:00

The answer to the question below is depressingly easy. I was overthinking the problem. Session is Hibernate's custom implementation; EntityManager is the standard JPA creature. If you want to stick to the standards (in this case, I do, although the odds of our shifting to a different JPA provider are very slender), stick to EntityManager. The big thing I'm missing out on so far is access to Hibernate's various CascadeTypes; the JPA default CascadeTypes are rather limited.

The way I'm working lately

2008-03-21T07:56:00.000-07:00

This is actually almost fun.

Figure out some functionality that needs to exist. Within a unit test, write the top-level code for it regardless of whether the supporting methods exist or not.

List people = populationDao.getPeople();

...even if I haven't written populationDao.getPeople() yet.

Eclipse will complain that I have written references to methods that don't exist. Hit control-1 and choose the answer that is "create method 'getPeople' in interface 'populationDao'." Then, of course, PopulationDaoImpl will have errors, because I have a method in populationDao that I haven't implemented. Open up PopulationDaoImpl, control-1, 'add unimplemented methods,' and write the implementation for getPeople().

This way I know that getPeople() has at least some test coverage right from the start.

Open Hibernate Question

2008-03-17T07:57:00.000-07:00

Open question: I see in the Hibernate documentation that Hibernate's EntityManager is "similar to" Hibernate's Session interface. But it isn't clear when I should be using one versus the other. I'm using the EntityManager now and everything's going fine. But I want to make sure I'm doing this The Right Way so that I don't have to rip it apart and rewrite it in three months when I better understand the business problems I'm fighting. Any readers have any insight?

Acegi: It Makes Sense Now

2008-03-07T11:20:00.001-08:00

I was trying to write a massive security infrastructure beast. I don't need to do that.

The first thing I've done since the last post is to write my own 'SecurityService' class that implements the UserDetailsService interface. UserDetailsService has just one method -- UserDetails loadUserByUsername(String). So it takes a username and loads that whole user object.

Well this confused me. Where the hell, I thought, does the password get dealt with here?

The answer is that the password is handled by the Authentication Provider (in this example, an org.acegisecurity.providers.dao.DaoAuthenticationProvider). So this particular authentication provider accepts a username and password, uses the username to pull the UserDetails data out of the UserDetailsService, and then (in memory) (presumably) compares the submitted password to the password returned from the UserDetails object's getPassword() method.

I'm not thrilled by this implementation, because it assumes that passwords will be stored in plaintext! They shouldn't be.

Anyway, I verified all of this by building out a deliberately stupid implementation of the UserDetailsService and wiring it into my application -- specifically I wrote one that always returns the same UserDetails object, with a known and bogus username and password. I tested this and it worked, so it all makes more sense to me now. Next step is to rewrite my bogus UserDetailsService to talk to my actual application code and return real user objects.

Down the road a bit I'm probably going to have to look at the other authentication providers, so that I can handle encrypted passwords. But in the interim this is good progress.

Stupid side note: for some reason, whenever I log in, users are getting redirected to an image file the first time.

Back with Acegi

2008-03-07T08:09:00.000-08:00

After a ColdFusion-induced layoff I'm back hacking at Acegi Security.

At this point I have a simple (very simple) Struts 2 application in place and I'm applying Acegi Security to it.

What I've done so far is taken the Acegi Petclinic Tutorial and applied it to my application. I used just about the simplest possible security implementation there -- I changed some names in their default users.properties file and implemented properties-file-driven security.

So far it does work, though -- the login page is exposed to all comers, while the more secure pages deeper in the app are hidden. Routing to the "landing" page upon login works correctly as well.

Next I want to change authentication so that it looks at my users table instead of looking at the properties file. I'll continue to assume just two levels of authorization (anonymous and logged-in user). The Acegi Security reference documentation suggests that I'm going to want to implement the UserDetailsService interface... but of course UserDetailsService doesn't accept a password argument. So I'm going to have to figure out what to do to really authenticate the user, as opposed to just looking them up.

Acegi and Struts 2

2008-02-27T13:23:00.000-08:00

The easy part is done. Acegi's jar files are in place and they reliably block access to the "protected" part of the application, and redirect users to the login page. Unfortunately I haven't yet figured out how to connect my login action to Acegi authentication.

I believe I will have to have my login action point at my own custom implementation of UserDetailsService, which will in turn have a link to my already-existing UserDao. It will have to put the UserDetails in question into the security context... I think I got it. Now just to, y'know, write the code.

2008-02-27T10:56:00.001-08:00

First real step was to tell web.xml that I was going to have multiple applicationContext files (applicationContext.xml and securityContext.xml) so that I don't poop all over my application context with security stuff. Yeesh, there's a lot of configuration there.

Acegi Security

2008-02-27T10:31:00.000-08:00

Today I am checking out Acegi Security for our app. I'm slapping it against the application now, early on, rather than trying to shoehorn it in later, after everything works in an insecure fashion.

I would like to know how the hell it's supposed to be pronounced.

It certainly looks cool. Pretty pluggable. Should fit reasonably well within our current application design; I'm just going to write a UserDetailsService implementation that uses our existing Hibernate configuration.

More as I actually do it.

Incredibly Basic Design Problem

2008-02-22T12:58:00.000-08:00

I'm working on a web application. All noteworthy data in here has been scrubbed appropriately.

This application has users. There are both external and internal users. Each user may have access to a certain subset of the application's functionality, although generally speaking internal users' functionality access is different from external users' functionality access. For instance, we might have an external user who is a customer, and another external user who is a supplier. We might have an internal user who is a sales rep, and another who provides support to the logistics team.

The question I immediately ask myself is this: Am I looking at an inheritance hierarchy, or am I looking at an opportunity for composition?

In other words, do I have:

public abstract class User {...}
public abstract class InternalUser extends User {...}
public class LogisticsUser extends InternalUser {...}

?

Or should I rely instead on composition?

public class User {
Set availableRoles = new HashSet();
}
User fred = new User();
fred.addRole(LOGISTICS);

I might consider answering this question with a look at the database tables that I'm relying on, but (1) I'm more concerned with the conceptual problem here than the implementation details and (2) in this particular case the tables are no help at all anyway.

So here is the core question: Can a user ever fill multiple roles? Java doesn't support multiple concrete inheritance, so a given user either IS a LogisticsUser or he IS a CafeteriaUser or what-have-you. If users can fill multiple roles, then I should be assigning them roles rather than slotting them in a particular concrete class.

And in this particular case, yes, some users do need to fill multiple roles (for instance, we might have a logistics support person who also has administrative authority over some of the website). So I'll be making a simple User hierarchy with a more complex collection of Roles available.

Today I Am A Real Boy

2008-02-20T15:38:00.000-08:00

Today a client coworker gave me some Java code of his to work on and finish up, because we're going to need it for forward development.

So I looked at what stuff could be refactored, wrote a couple of unit tests, refactored some bits out, ran the tests, and...

Well the code logged a few major exceptions and was unusable. But the test passed.

We were conversing about this code in general terms a few minutes later, and I pointed at the screen and hollered "I want that test to fail! Help me make it fail!"

Dippy

2008-02-16T09:57:00.000-08:00

To go with "ATM machine" we now have "plain POJO," per the Hibernate docs.

Glad to see this works

2008-02-14T09:59:00.001-08:00

I wasn't sure this would work. One quick unit test verifies that it does. Very good to know:

Query query = getEntityManager().createQuery("from User order by ?");
query.setParameter(1, "lastName");

I don't know why it wouldn't work, really, but I had only used replaceable parameters in the WHERE clause of queries before.

Thought I was GONE didn't you

2008-02-14T06:38:00.000-08:00

I've played a bit over the last few days with a simple Struts 2 CRUD app, mostly following the examples given here.

Right now I have a data table that lists the users of the app and provides an exciting 'edit' link for each one. The edit link takes you to a pretty standard 'edit' type page for the given user.

Here's what I'd like to do next (several things, all fairly independent of the others).

Turn the data table into a submit-driven paging sorting data grid.
Turn the data table into an AJAX-driven paging sorting data grid.
Implement a smart(ish) filter for the data grid.
Change the two-page layout (table, data entry grid) into a one-page AJAX-driven layout (click on a user to open the edit grid for that user next to the table).

I think I'm going to start with the first one; I'm going to have to do it eventually anyway.

Another thing that drives me berserk about ColdFusion and CFEclipse

2008-02-07T12:14:00.000-08:00

It is damned near impossible without using the "find" feature and extraordinarily tedious tag-counting (and tag-collapsing) to figure out whether or not a given variable is in scope at a particular part of the page. I can't control-click to go to the spot where the variable is declared; I get no indication as to whether the variable exists at a given spot; I don't even get a warning telling me that the variable may not have been declared conditionally at a given spot.

And then I get exceptions thrown when my predecessor's code references a variable that was conditionally declared earlier and the declaration got skipped this time. Madness.

Wrong Ways, first in a series

2008-02-06T06:25:00.000-08:00

After a few days spent doing ColdFusion support I'm doing some more Struts/Hibernate development today.

An observation: There's a right way to set up developers' environments, and there are dozens of wrong ways. I feel like I have a pretty good grasp of some of the wrong ways, and now I'd like to share them with you. Critically important note: These observations do not pertain to my current client or my employer.

Wrong Way #1: Stint on hardware. A consultant costs, let's say, $100/hr. A fully-loaded full-time employee might be $70/hr. According to newegg, 4 GB of RAM from a no-name vendor costs $100. If you want to go with a really reliable, trusted vendor, you might spend $200. If you are furnishing a consultant with hardware, a really great Wrong Way to do things would be to save $200 on memory. Give him a machine with 1 GB or less. Sure, it takes 15 minutes for his machine to boot every day, and lockups, crashes, and slow response time cost at least an hour a day. But you saved the cost of that memory!

(but seriously) This is especially and offensively common when different cost centers or different managers are paying for developers' time versus developers' hardware. The MIS guys saved $150 off their budget but cost the company an additional $6000 in developer productivity over three months. Woo! Way to contribute! Go team!

Wrong Way #2: Lock down that Internet. Developers can't be trusted with free reign to go to any website they want. Network administrators know what kind of tools, open-source libraries, and reference materials a developer could want. Let the network guys and their management make that determination. Blogs? Forget it! Those things are just time sinks, they're like reading the newspaper at work. And there's no reason to differentiate between a customer service rep and a software developer in terms of Internet access. If you can't trust a CSR with access to blogspot.com, there's no way a developer needs it. Lock 'em all down.

Wrong Way #3: Shared environments. Software licensing is expensive. Rather than spring for a development license for each developer, why not set up a shared dev server, with a shared database and everything? Don't give developers local development environments; just make their desktops into glorified terminals. Also, this way your developers won't have to worry about solving problems when they're away from an Internet connection or when the VPN is down. That will encourage them to spend more time in the office.

Oh, I bet there are plenty more of these I could do...

2008-02-04T06:43:00.000-08:00

Excellent series on developers' database management and putting your db in version control over at http://odetocode.com/:

Part 1
Part 2
Part 3
Part 4
Part 5

Well that was funny

2008-02-01T08:31:00.000-08:00

I only had to change the URLs in hibernate.cfg.xml and in applicationContext.xml. That's good and easy.

Things didn't work for a sec, because in the 'real' database that I'm now using, Users aren't stored in a 'user' table, they are stored in, let's say, a table called 'bogus_user'. With Hibernate 2 I would have known to go into User.hbm.xml and modify the table name reference, but the current quickstart project uses Hibernate 3 annotations. I checked the docs quickly, suspecting I need to change the @Entity annotation on the User class. The docs pointed me at the free Chapter 2 sample of the Manning Java Persistence with Hibernate book. It showed that I needed to add @Table(name="bogus_user") to the User class declaration. I did that, and redeployed.

This time I ran into a hilarious error. The bogus_user table has thousands of entries, and my simpleminded script was trying to display all of them at once. So -- next step -- limit the number of entries returned. That will be after lunch, as my wife and I are going to meet for lunch for the first time in ages.

I'll probably be buying that Manning book this weekend.

Changing a data source

2008-02-01T07:46:00.000-08:00

It's very quiet here this morning. Snow and ice last night, freezing rain this morning. A lot of people are working from home today.

I'm going to try something wacky this morning. Having successfully finished the 'quickstart' demo provided by the fine Struts 2 folks, I've already changed the names of my packages and classes to match the activities I actually plan to undertake (quickstart.service.PersonServiceImpl changes to com.clientname.project.UserDaoImpl, for instance).

Now I'm going to do something more entertaining. I'm going to try to dump a copy of our dev MySQL database and build it locally, and then point this toy app at it. I may not have the right privs for that. So if that doesn't work, I'm going to point my app at our dev database and see what happens. I'm pretty sure I know what will have to change.

Onward

2008-01-31T11:17:00.000-08:00

The rest of the quickstart demo went pretty smoothly. Not surprising, considering that it was largely a matter of typing (or copy and pasting) sample code into real files.

But now the fun begins: problems. The truth is that you don't understand how a technology or combination of technologies works until you've had to fix them when they're supposed to work.

So, first problem: Exception stack trace in my Tomcat log. I am not going to drop the entire stack trace into the blog at this point, but let me describe how I'm handling this. First, I skimmed the stack trace looking for references to code that I know to be mine. In this case there are no "quickstart." files anywhere in the stack trace, so I know it's not my Java code. Now, here are the first few lines of the stack trace:

SEVERE: Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is java.lang.NoSuchMethodError: org.springframework.beans.factory.xml.ParserContext.registerBeanComponent(Lorg/springframework/beans/factory/parsing/BeanComponentDefinition;)V
Caused by: java.lang.NoSuchMethodError: org.springframework.beans.factory.xml.ParserContext.registerBeanComponent(Lorg/springframework/beans/factory/parsing/BeanComponentDefinition;)V
at org.springframework.transaction.config.AnnotationDrivenBeanDefinitionParser$AopAutoProxyConfigurer.configureAutoProxyCreator(AnnotationDrivenBeanDefinitionParser.java:130)
at org.springframework.transaction.config.AnnotationDrivenBeanDefinitionParser.parse(AnnotationDrivenBeanDefinitionParser.java:79)

The most obvious problem appears to be an error parsing applicationContext.xml. Probably I have a typo in there somewhere. However, I can't find one after glancing over the file for five minutes and that is almost certainly enough time for now. So I'm going to do something annoying. I typed this one in by hand and probably fat-fingered something. So I'm going to copy-and-paste the file contents from the demo and see if that makes the problem go away. If it doesn't then I'll have to use my brain and nobody wants that.

That doesn't make the problem go away! Crap. Time to do some Google searches on the exception messages.

And Matt Raible comes through again. Dude is rapidly becoming my hero. A thread on the AppFuse mailing list suggests that there might be collisions between various Spring jars. I'm reorganizing my build path, let's see how this works.

...nope. OK, time to review my build path, make sure I have everything I need. Yes, this would have been a good time to have used Maven, I know.

Hey, it turns out that I ignored a bunch of Hibernate jars earlier -- specifically the Hibernate Annotations and Hibernate Entity Manager jars. I'll grab them now. And that doesn't solve the problem either. Same error.

Clean, refresh, delete the deployment, rebuild, redeploy... and it's a whole new suite of errors! But these are more comprehensible. They can go in another post.

Continuing the Struts 2 / Spring / Hibernate Toy

2008-01-31T09:36:00.000-08:00

If you are just joining us, I am working my way through this.

I'm working on the provided PersonServiceImpl. Eclipse can't find the @Transactional annotation, which is apparently org.springframework.transaction.annotation.Transactional. Thought I had all the Spring jars -- guess not. http://www.docjar.com/ -- which should be in every developer's bookmark list -- suggests that it is found in spring-dao.jar, which I don't have. It looks like I don't have it because it doesn't exist.

I have a hunch here and it turned out to be right. Rather than relying on Eclipse's Spring enablement guck, I went right to the site to download the latest Spring distribution, and grabbed it. Unpacked it, grabbed spring.jar, dropped it into my project. There, right there, is the org.springframework.transaction.annotation package. I had assumed -- wrongly -- that Eclipse's Spring capability enablement would include spring.jar. Sigh.