I tend to be the stern taskmaster of coding design. The design of the interceptors and proxies enforces that an interceptor can't bypass its delegate and jump directly to the core service implementation.
I'd rather not expose the core service implementation. There are even cases where the CSI is fabricated on the fly. Perhaps we should expose the *class* of the core service implementation as a method on InterceptorStack. That would be sufficient for your purposes. On 4/25/05, Chris Conrad <[EMAIL PROTECTED]> wrote: > Hello, > > I've discovered what I consider a potential problem with the > ServiceInterceptorFactory. Basically, I've been building a declarative > security system for my application. To reduce the amount of > configuration data, I thought I'd use Java 5 annotations to declare the > security semantics of service methods. What I discovered, however, is > there is no way to get at the core service implementation. Since my > transaction interceptor uses Java proxies and it's applied before the > security interceptor, I can no longer access the annotations on the > implementation class. > > So, how should I go about handling this? I guess I can declare the > annotations on the service interface, but I can certainly imagine > situations where the annotation is truly an implementation detail and > shouldn't be exposed to the callers of the service. And I'd guess this > will become more of an issue as people start using annotations more. > > Thanks, > --Chris > > --------------------------------------------------------------------- > 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 Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
