I saw a very similar question asked a few months back in a general Java forum, and I suggested an answer that I've never had the chance to actually try out... the theory is interesting though...
In the method you want to "protect", immediately throw an exception and catch it. Then, parse the stack trace and see who the caller was. If it's not a class you want to have access to the method, throw an IllegalAccessException. Again, it's one of those things that sounds good in your head, I have no idea if it translates to anything workable :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Thu, February 16, 2006 1:24 pm, Laurie Harper said: > Tom Ziemer wrote: >> Hi, >> >> I have got a question quite unrelated to Struts: My app. is pretty much >> layered, meaning, I have Hibernate, on top of which there are >> SpringDAOs, on top of which are Managers that represent my business >> logic. >> >> Now I wonder, if it is possible, to *hide* (maybe with annotations?) my >> DAOs from all classes except my Managers. The reason for this is, that >> my Managers use declarative transactions, therefore multiple DAOs can be >> used in on session and I can initialize lazy collections. If DAOs are >> used on their own, this will not work but result in tons of exceptions >> instead. >> >> Basically it boils down to the question, whether I can "hide" certain >> classes in my API, so that potential users are forced to use the correct >> way (via the manager classes). > > > The only mechanisms Java provides for this are a) default (package) > scope, which would require you to keep your DAOs or other classes you > wanted to 'hide' in the same package as the classes you want them to be > seen by; or b) the security manager infrastructure, which lets you > control what code has access to what classes/methods elsewhere. > > Unless you have very stringent requirements, though, it's usually enough > to establish clear architectural layers and rely on your developers to > respect the boundaries between them. > > L. > > > --------------------------------------------------------------------- > 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]
