Thanks for you answer. I had a look at the ContextualHttpServletRequest before. In my understanding it sets up the complete seam contexts only for the request and then looses them again. Wouldn't that lead to additional (perhaps unnecessary) overhead? But enough theory. I give it a try and meter performance. Lets see...
Florian Bantner wrote on Apr 10, 2008 10:28 PM:
Is it ok to save a reference to application scoped ejbeans in the filter for later use? Are there any Problems which could arrise from this?
Yes, the contexts aren't available so it almost certainly won't work (unless you do something trivial that doesn't require any Seam functionality). Drew is correct, and if you consider your response carefully, you'll understand why!
Pete Muir wrote on Apr 14, 2008 12:49 AM:
Yes, the contexts aren't available so it almost certainly won't work (unless you do something trivial that doesn't require any Seam functionality).
to be more concrete: I've got an application scoped bean which reads in configuration from some files and database which is used from almost every other component. After building it doeesn't require any active database connection or fileaccess. It simply holds a datomodel with (very fast) access methods. This seams fairly trivial to me :)
Drew is correct, and if you consider your response carefully, you'll understand why!
Ok. So I try: Since no seam context is available in the filter it won't be available to the bean I reference. Even worse since I use a direct reference there won't be any whatsoever in/outjection or any other annotaion releveant stuff and the state is the one which was the last the bean was in when last accessed (read: not defined). What remains is just good old java access to a class which is more or less static. In this case that would be fine with me.
But what bothers me more: I'm learning seam while I'm learning ejb3. So I read in an ejb3 book that beans are subject to outsourcing to an inactive state. Could that happen to the backing bean I hold a reference to in the filter? An what happens to my reference then? Or can I / do I have to stop the appserver from doing this?
So, why not store your configuration data in a simple java object, which you outject into the application scope. You can then access this during the init() method and store a reference to it there. This means that you won't even have to consider any seam stuff (and it should be more performant).
Thanks very much,
this short comment may not only be a solution to my problem but although shows me a complete new way of thinking of architecture with seam in a way I haven't considered until now. It even may solve my performance problem I have at another place...