You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2005/02/16 14:26:41 UTC
Beans as services
Just had an interesting thought to share.
We need services to have an interface - for proxies and interceptors.
We want beans that act just like services, but don't have an interface.
What if: we fabricate the interface for a bean as needed?
Analyze the the bean, any public method that is not inheritted from
java.lang.Object goes into the synthetic interface. The synthetic
interface extends any interfaces the class implements.
Proxies and interceptors implement the synthetic interface.
The core service implementation does not implement the interface (we
don't change existing code) ... BUT that should not matter due to the
way proxies/interceptors are constructed (using either Javassist or
JDK Proxies).
Might mean that the class attribute of BuilderFactory's <construct> is
optional (if the "interface" for the service is really a class). Or
we just live with a little duplication there (not so bad with
abbreviated class names). There would be a few other kludges
scattered about.
--
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
Fwd: Beans as services
Posted by Howard Lewis Ship <hl...@gmail.com>.
Woops.
---------- Forwarded message ----------
From: Howard Lewis Ship <hl...@gmail.com>
Date: Wed, 16 Feb 2005 09:01:40 -0500
Subject: Re: Beans as services
To: Tapestry development <ta...@jakarta.apache.org>
Yep, abbreviated class names should work everywhere (if I missed
anything, its a bug).
Caveat: The interface attribute (of <service-point>) is a little
different, since HiveMind tries not to resolve the interface name to a
Class instance until absolutely necessary.
On Wed, 16 Feb 2005 14:43:32 +0100, Knut Wannheden
<kn...@gmail.com> wrote:
> On Wed, 16 Feb 2005 08:26:41 -0500, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > What if: we fabricate the interface for a bean as needed?
> >
> > Analyze the the bean, any public method that is not inheritted from
> > java.lang.Object goes into the synthetic interface. The synthetic
> > interface extends any interfaces the class implements.
> >
> > Proxies and interceptors implement the synthetic interface.
> >
> > The core service implementation does not implement the interface (we
> > don't change existing code) ... BUT that should not matter due to the
> > way proxies/interceptors are constructed (using either Javassist or
> > JDK Proxies).
> >
>
> That sounds like it would work! For the case where the primitive
> service model is used it should be even simpler.
>
> > Might mean that the class attribute of BuilderFactory's <construct> is
> > optional (if the "interface" for the service is really a class). Or
> > we just live with a little duplication there (not so bad with
> > abbreviated class names). There would be a few other kludges
> > scattered about.
> >
>
> I don't think it would matter if the "class" attribute would remain
> mandatory. If the bean eventually is converted to a "proper" service
> it will be required anyway.
>
> I like the new abbreviated class names feature. Does it also work for
> attribute values in contributions where the "class" translator is
> used? The one big downside of using abbreviated classnames is that a
> rename refactoring in Eclipse won't pick them up... But that's not all
> that common I suppose.
>
> --knut
>
--
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
--
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
Re: Beans as services
Posted by Howard Lewis Ship <hl...@gmail.com>.
Yep, abbreviated class names should work everywhere (if I missed
anything, its a bug).
Caveat: The interface attribute (of <service-point>) is a little
different, since HiveMind tries not to resolve the interface name to a
Class instance until absolutely necessary.
On Wed, 16 Feb 2005 14:43:32 +0100, Knut Wannheden
<kn...@gmail.com> wrote:
> On Wed, 16 Feb 2005 08:26:41 -0500, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > What if: we fabricate the interface for a bean as needed?
> >
> > Analyze the the bean, any public method that is not inheritted from
> > java.lang.Object goes into the synthetic interface. The synthetic
> > interface extends any interfaces the class implements.
> >
> > Proxies and interceptors implement the synthetic interface.
> >
> > The core service implementation does not implement the interface (we
> > don't change existing code) ... BUT that should not matter due to the
> > way proxies/interceptors are constructed (using either Javassist or
> > JDK Proxies).
> >
>
> That sounds like it would work! For the case where the primitive
> service model is used it should be even simpler.
>
> > Might mean that the class attribute of BuilderFactory's <construct> is
> > optional (if the "interface" for the service is really a class). Or
> > we just live with a little duplication there (not so bad with
> > abbreviated class names). There would be a few other kludges
> > scattered about.
> >
>
> I don't think it would matter if the "class" attribute would remain
> mandatory. If the bean eventually is converted to a "proper" service
> it will be required anyway.
>
> I like the new abbreviated class names feature. Does it also work for
> attribute values in contributions where the "class" translator is
> used? The one big downside of using abbreviated classnames is that a
> rename refactoring in Eclipse won't pick them up... But that's not all
> that common I suppose.
>
> --knut
>
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Beans as services
Posted by Knut Wannheden <kn...@gmail.com>.
On Wed, 16 Feb 2005 08:26:41 -0500, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> What if: we fabricate the interface for a bean as needed?
>
> Analyze the the bean, any public method that is not inheritted from
> java.lang.Object goes into the synthetic interface. The synthetic
> interface extends any interfaces the class implements.
>
> Proxies and interceptors implement the synthetic interface.
>
> The core service implementation does not implement the interface (we
> don't change existing code) ... BUT that should not matter due to the
> way proxies/interceptors are constructed (using either Javassist or
> JDK Proxies).
>
That sounds like it would work! For the case where the primitive
service model is used it should be even simpler.
> Might mean that the class attribute of BuilderFactory's <construct> is
> optional (if the "interface" for the service is really a class). Or
> we just live with a little duplication there (not so bad with
> abbreviated class names). There would be a few other kludges
> scattered about.
>
I don't think it would matter if the "class" attribute would remain
mandatory. If the bean eventually is converted to a "proper" service
it will be required anyway.
I like the new abbreviated class names feature. Does it also work for
attribute values in contributions where the "class" translator is
used? The one big downside of using abbreviated classnames is that a
rename refactoring in Eclipse won't pick them up... But that's not all
that common I suppose.
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org