But, the problem is that he doesn't have a reference to the servlet context either when his logic in invoked. If he's using the open source security filter from sourceforge (I think he is), it uses Digester to create an instance of a class specified in a configuration file. Then, the filter does callback methods on that instance and no servlet API classes are passed in. So, he can't get to the servlet context or the current request.
-----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 10:05 AM To: [email protected] Subject: Re: HiveMindFilter The reason HiveMindfilter works the way it does, is to ensure that Registry.cleanupThread() is invoked at the end of the request, and that Registry.shutdown() is invoked when the application is undeployed. For your purposes, subclass HiveMindFilter and store the Registry in the servlet context. On Mon, 29 Nov 2004 00:24:09 +0700, Jean-Francois Poilpret <[EMAIL PROTECTED]> wrote: > 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] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind http://howardlewisship.com --------------------------------------------------------------------- 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]
