Hi James, Thank you for your suggestion. I already thought about the ThreadLocal possibility, but: 1- anyway, the ThreadLocal variable itself will have to be static 2- does it make sense to "allow" different Registries on a per-thread basis?
Ok, for the point 2, it helps solving the problem of reusability across web-applications, but is that really a problem (I mean: should we care about shared libs)? Or maybe there are cases in the same web-application where this could make sense, but I don't see any currently. Anyway, since that solution seems cleaner than the 100% static one, I will give it a try (should be easy since the code is centralized in the Filter class). Cheers -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Sunday, November 28, 2004 10:23 PM To: [email protected] Subject: RE: HiveMindFilter Why not use a thread local variable rather than a totally static variable? -----Original Message----- From: Jean-Francois Poilpret [mailto:[EMAIL PROTECTED] Sent: Sunday, November 28, 2004 9:51 AM To: [email protected] Subject: RE: HiveMindFilter Marcus, I know that "static are evil"! However, what you say about static that are shared between different web applications will not occur as long as you deploy the libraries in the war (and not in shared directory). Of course, the idea of putting all commonly used libraries in a shared directory, to reduce the size of the war (size of both files and memory), is attractive. However, how many common libraries today can work this way? A simple example: struts, if I remember well, it is explicitly stated in the web site that it _may_ work, but strongly advised not to do so. Many other libraries (velocity for instance) depend on statics as well. So at the end it becomes almost impossible to put "common" libs in a shared location... Finally, since I need to go forward, I chose the simplest solution (and the most evil one;-)): I rewrote my own Filter and stored the Registry in a static. The SecurityRealm does not access the ServletContext either. The constructor must be no-arg, and the authentication method is just passed the username and password! Regarding JNDI, I am not very keen on that (too much code to write with too many checked exceptions to check... not talking about configuration, specific to the container) Thank you for your feedback. Cheers -----Original Message----- From: Marcus Brito [mailto:[EMAIL PROTECTED] Sent: Sunday, November 28, 2004 8:23 PM To: [email protected] Subject: Re: HiveMindFilter > After having a look at HiveMindFilter implementation, I was wondering why it > seems so "complex", I mean: why do we need to store the same Registry in the > request, why not store it directly in a static variable and make it > available through a static method with no argument? Is there a problem to > having the Registry as static? Repeat after me: statics are evil. I'm joking, but there's some truth in that. If you're deploying more than one web application, statics will get you into trouble: the Registry class might be shared between the web applications, and if you use a static variable to store it, it will be shared by the two applications. That being said, the current request really isn't the best place to store the registry either. The servlet context would be more appropriate, IMHO. Another good candidate is a JNDI directory. > What should I do to work around this problem? If you have a way to access the servlet context from the SecurityRealm interface, write your own filter that stores the registry as a servlet context attribute. If you don't, you should consider storing it in a JNDI directory that you can access from the SecurityRealm. -- Marcus Brito --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
