So, a user has to be careful not to use any non-public/protected methods which use any injected dependencies, or else they'll get a NPE, since the "outer proxy" itself will be fulfilling the request and the dependencies will not have been injected into the proxy!? I don't know that it's a problem, necessarily. I'm just trying to think through it. Any reason why you didn't just fabricate a subclass (yet another) of the bean implementation class that just implements the bean interface and just place that on the interceptor stack so that the last interceptor would just call that? Wouldn't that have worked?
Yes, my head is spinning. I had already written my section on services in my TSS article where I said that all services must implement a service interface. I guess I'm going to have to re-write that a bit to discuss these new features. I don't know how deeply I'm going to delve into it, though! This is some cornfusing (sorry, I'm from Kentucky) stuff for a layperson. :-) -----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Friday, February 25, 2005 6:05 PM To: [email protected] Subject: Re: Bean Services... On Fri, 25 Feb 2005 17:53:08 -0500, James Carman <[EMAIL PROTECTED]> wrote: > > > > Ok, I'm trying to make sure I understand how bean services have been > implemented. From what I understand (could be way off base, though). > > > > The proxy returned to the client is a subclass of the bean service > implementation class. Yes; it adds the sematics to delegate all behavior to the service implementation (including any interceptors, etc.). It fulfils the role of an "outer proxy". It also understands Registry shutdown semantics. > It also implements some sort of dynamically generated > interface (we'll call it bean interface) which has all of the public methods > of the bean class in it. Yep, we generate a synthetic service interface from the public methods of the bean. > The proxy returned to the client doesn't call any of the superclass > implementations of the methods. It overrides the methods, forwarding calls > to the InterceptorStack (which also uses the bean interface). Yep, though its not the InterceptorStack, its the inner proxy that gets replaced by the service or the outermost interceptor. > > > > I do have some questions. > > > > We can't put service interceptors on non-public (or protected) methods, > correct? Correct; just the public methods. > What type of object is at the end of the interceptor stack? The service implementation is left alone, a bridge class is created that implements the synthetic service interface and delegates to the service implementation. So, we can end up with something like: bean subclass as outer proxy +--> interceptor (implementing service interface) +--> bridge (implementating service interface) +--> service implementation But in actuallity, the bridge is only needed if there aren't any interceptors (because the delegate of the outer proxy must implement the service interface; the bridge and interceptors do, the service implementation doesn't). Head spinning yet? -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
