Pencils Down

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.