Pencils Down

This weblog is about my experiences in software development

Browsing Posts tagged Spring

Another developer and I started seeing this running an app locally.

While it sounds really interesting with hints of transaction state it was really just noise cascading up from a missing property in the local properties file.

Yes, it did not occur on server. But again, from the wording it sounds like some filter error or the like and we use different authorizations running locally.

I like Spring MVC.  It is a great next step in the Spring history of Java/Web development.

I don’t like that Spring has decided that if you redirect from a POST then it unwraps all request parameters and throws them onto all subsequent URLs that are generated.

We have what I think is a fairly common search/results page.  We POST the search criteria when the user changes some aspect and GET to perform manipulations within a search result (such as page, paging, or sorting).

I had been storing the criteria in the model passed to the POST request.  This appears to be the culprit.

If I remove the model setting of the criteria and just store the criteria in the true HTTP session and redirect to my GET handler then everything works correctly.  No ugly URLs with umpteen parameters off the side of the screen.

So, the order of steps is something like:

  1. User changes criteria and POSTS to handler
  2. POST handler stores criteria POJO in the HTTP request object and redirects to same page GET handler
  3. GET handler retrieves criteria from HTTP session and performs updated query

If you are using Spring MVC you may see this message at times when generating HTML from your JSPs.

The full text of the message is:

500 Internal Server Error
Servlet error: An exception occurred. The current application deployment descriptors do not allow for including it in this response. Please consult the application log for details.

Looking at the log you will not see any error or exception whatsoever.

The problem is the coding in the JSP is accessing a variable in the model incorrectly.  Either a getter is missing or a field was changed, added, removed – etc…  Unfortunately this is all occurring in the bowels of Spring so the exception never percolates up.

If it was working fine before some recent change, then you are in luck.  The recent change is the culprit.

If you are on a bigger team or have been out of the loop for a while then you are out of luck.  You may need to do a binary search on the coding (remove 1/2, see if it works, remove 1/4, see if it works, …)

Spring has the ability to provide for Asynchronous processes to run. This would typically be used for some kind of status updater that has to circulate your database to determine if the change a user just made has had any effect on the rest of the system. This is normally not a very quick process, so you would naturally want to throw it over the wall to some asynchronous process that may tell you when it’s done.

This all works pretty well. You just have to tag the method in question with the @Asynch tag. You can still do things like synchronize the method call so that only one of them is running.

The tricky part is how to pass over the credentials of the user that started this all occurring?

If you have a typical MVC implementation for your app, you have gone through some pain to determine that the current user has the rights to exercise some feature that results in an asynchronous process kickoff. But there is no apparent mechanism for passing over the user ‘session’ information over to that asynchronous process. This means your asynchronous process has to run in its own vertical stack, not sharing results with anyone, including the user who kicked the whole thing off in the first place.

This appears to be a flaw in the design: While it is extremely useful to kick stuff off that runs elsewhere and does not tie up the user, there needs to be a connection maintained back to the user thread.

Any useful suggestions here?

Ok, so the Spring Framework allows for a high level of code re-use.  Great.

You use simple XML files to layout the flow of applications in Spring.  This allows for easy configuration of systems.  Great.

You now have a high amount of very atomic code/routines that are put together as needed to implement specific functions.  However, if something goes wrong you can not easily find the problem.  Again, due to the large amount of atomic, small routines that have been pasted together.

Log files are likely useless, as they will point out what happens at the lower level.

The only thing we have found is to log ‘events’ as specially executed code functions at the XML, config layer so we trap the higher level functions attempted to be performed at a specific time.

Other ideas would be great.

We have been (completely) rewriting a fairly large Java app using the Spring framework.  One of the developers had previous experience that became the core for the new system.

As one of the developers working on the existing systems I have subsequently been added on to the swarm working on the new app.

At first look, Spring reminds you of older IBM configuration files: every step is laid out in an XML file.  I guess that works, as most systems are very XML cogniscent.  I was somewhat overwhelmed by the amount of detail, at first.  I had though this to be a very complex undertaking.

Then talking this over with the architect, it became apparent that Spring really just breaks down your code into very atomic units.  What is at first overwhelming becomes more apparent to be a complete specification for an application: every step, function is laid out in explicit detail.

That becomes tha ‘Aha’ moment.  Any developed code fits into the xml ‘path’ of the application.  I still think it’s amazing seeing that much of the guts of an application laid out so cleanly.