You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by James Carman <ja...@carmanconsulting.com> on 2005/02/25 23:53:08 UTC
Bean Services...
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).
1. The proxy returned to the client is a subclass of the bean service
implementation class. 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.
2. 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).
I do have some questions.
1. We can't put service interceptors on non-public (or protected)
methods, correct?
2. What type of object is at the end of the interceptor stack? Do we
generate a new subclass of the bean service implementation class which
implements the bean interface?
RE: Bean Services...
Posted by James Carman <ja...@carmanconsulting.com>.
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:hlship@gmail.com]
Sent: Friday, February 25, 2005 6:05 PM
To: hivemind-dev@jakarta.apache.org
Subject: Re: Bean Services...
On Fri, 25 Feb 2005 17:53:08 -0500, James Carman
<ja...@carmanconsulting.com> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Bean Services...
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Fri, 25 Feb 2005 17:53:08 -0500, James Carman
<ja...@carmanconsulting.com> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org