That depends on what kind of security you are looking for. I was in a project where they were really picky about what/who was using an object. It happened to be a db pool, but they want to make sure only 'known' clients were connecting. Because of other issues, something similar worked out. We used the serialUID of the calling class and a couple other things to do a security check. So, it was security amongst objects, not 'real' users.
It doesn't have a WIDE use, I'll admit, and probably more helpful in debugging. Not sure about the code. I have the magazine and I don't mind typing up what's in it if someone is really interested. Robert -----Original Message----- From: Jeff Robertson [mailto:[EMAIL PROTECTED]] Sent: Friday, February 15, 2002 3:44 PM To: 'Struts Users Mailing List' Subject: RE: Determining the name of a calling class > -----Original Message----- > From: Robert [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 15, 2002 16:35 > To: 'Struts Users Mailing List' > Subject: RE: Determining the name of a calling class > > > Yes there is, and there was a recent article in JavaDev Journal > describing this. Basically what you have to do is is create a > Throwable > object, which you can then inspect the stacktrace. The stack trace > contains the calling order of objects. Yes you have to parse > it, but it > works. The article presented a couple of utility classes to handle the > parsing and such. It was presented as a sort of security mechanism. > > It was in the November 2001 issue and the source is at: > www.sys-con.com/java/sourcec.cfm volume 6 issue 11. > I can't find any code that does what you describe at that site, but as a security mechanism it sounds not only inefficient but also unreliable. As a debugging aid, yes this kind of thing is useful. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
