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/05 13:34:36 UTC
AOPAlliance Service Interceptors...
Hello, All. Since the AOPAlliance Service Interceptors support didn't make
it into 1.1, when can we expect that to become available? I would like to
discuss service interceptors in my article, but there is NO WAY that I'm
going to try to explain how to do it using Javassist. I would like to use
the AOPAlliance stuff.
James
Re: element
Posted by Albert Kwong <ma...@yahoo.com>.
I think <bean> with DI would be useful for a pattern
where service A depends bean B which in turn depends
on service C. Bean B could be a stateful object that
manages some states on behalf of service A. Another
service D may also depend on another instance of bean
B with independent states.
We can somehow simulate this pattern now with threaded
service model, if service A and service D do not
interleave.
We can also simulate it with a singleton service that
has a state object on every parameter. However this
doesn't look very OO.
Yet we can also do it with ObjectProvider. In this
case the ObjectProvider of bean B will have dependency
on all the services B depends on. When it provides
bean B, it will instantiate it, inject the
dependencies, and return the bean. <bean> + DI shall
be able to reduce the need for the OP in this case.
On the other hand, are we still using the setters on
the bean for DI? A bean's setter may be there for
application use rather than DI. Can we describe the
bean so that some setters are ignored. Can we
configure beans (or services) to use injectXXX for DI
rather than setters?
Albert
--- Knut Wannheden <kn...@gmail.com> 內容：
> I think it would be quite interesting to know what
> others think about
> this proposal as I'm not sure how I'd personally use
> it either.
>
> I have in the past argued for supporting
> interface-less services
> because I think it would be great for prototyping
> and exploring the
> problem domain. Eventually, as I'm clear on the
> responsibilities of
> the services, I'd however convert the beans to
> services.
>
> What this would look like with a top-level <bean>
> element: If I at
> some point decide to add an interface to my bean and
> turn it into a
> service then I have to both change the <bean>
> element into a
> <service-point> *and* change all references to it.
> References exist as
> type declarations of autowired constructor
> parameters and setter
> parameters, any uses of the "bean:" object provider,
> and possibly also
> <set-bean> elements. This means quite a bit of work,
> which I think in
> the end would keep me from using <bean>s for
> prototyping.
>
> So I am wondering how others who have argued for
> interface-less
> services feel about this proposal. What problems
> would (or wouldn't)
> it solve for you?
>
> I'd prefer if the <service-point> element could be
> used as is. Beans
> would simply declare the bean class itself as their
> "interface". All
> other restrictions (e.g. service model) could be
> enforced by HiveMind.
> But I can see how this could be confusing.
>
> Apart from that there is something I think would be
> even more useful
> wrt beans: A HiveMind service or a programmatic
> interface which can be
> used to instantiate and / or autowire beans. I find
> myself quite often
> defining a factory or repository type of service
> which builds POJOs
> and where access to autowiring would be very useful.
>
> --knut
>
> On Sun, 6 Feb 2005 13:54:20 -0500, Howard Lewis Ship
> <hl...@gmail.com> wrote:
> > Part of this has been discussed on the wiki:
> >
> >
> http://wiki.apache.org/jakarta-hivemind/PojoServices
> >
> > People chafe at the use of interfaces for
> one-time use objects, but
> > still want all the dependency injection that
> BuilderFactory provides.
> >
> > Adding a new <bean> element would solve a fair
> amount of this.
> >
> > It wouldn't be quite inline, it might be more
> like:
> >
> > <set-object property="databaseAccess"
> value="bean:DatabaseAccess"/>
> >
> > ...
> >
> > <bean id="DatabaseAccess">
> >
> > <construct class="mypackage.DatabaseAccess">
> > <set-object property="daoService"
> value="service:DAOService"/>
> > </construct>
> > </bean>
> >
> > In this way, beans would be another namespace like
> services and
> > configurations, could have visibility, etc.
> >
> > I think we could also dress up the instance:
> object provider to do
> > some *simple* configuration of the object, i.e.:
> >
> >
>
instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringProperty='some
> > string'
> >
> > You can already do some of this using
> hivemind.lib.BeanFactory.
> >
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> hivemind-dev-help@jakarta.apache.org
>
>
=====
Are you an MBA? Check out http://www.mba.hk for value added services.
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: element
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
I guess i am thinking that the service using the dependancy injector would
have some knowledge of what it is trying to auto-wire/inject service into
and would itself be wired with the correct implementation of the services
required (should there be a conflict) and if there was a problem resolving
a service, it could handle it. But i realise now that the object you are
auto-wiring should not have to rely on the caller for this.
To then separate things even further, I guess you could describe an
objects dependancies as a hivemind configuration and the
DependancyInjector could use those to resolve conflicts:
<contribution configuration-id="hivemind.DependancyInjector">
<bean class="com.acme.JavaBean">
<dependancy property="service" service-id="some.module.ID"/>
</bean>
</contribution>
This would allow you to simply do inject(object); or? Only limit would be
that a bean could not be injected with different services depending on the
caller ...
Cheers,
Johan
On Tue, 8 Feb 2005 11:42:16 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Johan,
>
> How does the "resolver pattern" differ from mere auto-wiring? The
> problem
> with auto-wiring is that your dependencies can be injected just fine at
> one
> point. But, suppose you add in another module to your application which
> exposes another service that implements the service interface you were
> using. Then, all of a sudden, your stuff (which used to work) breaks!
> Yuck!
>
> James
>
> -----Original Message-----
> From: Johan Lindquist [mailto:johan@kawoo.co.uk]
> Sent: Tuesday, February 08, 2005 11:39 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: <bean> element
>
> Yup, missed it fully - and yes, that makes sense ... :) It would however
> build in knownledge about service id's etc (which would have to be kept
> in
> synch) into the code, but I guess that is not the biggest of problems.
> What about using some sort of ResolverPattern? For this service
> interface, give me the instance to use??
>
> Cheers,
>
> Johan
>
> On Tue, 8 Feb 2005 11:06:04 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
>
>> Johan,
>> I think you may be missing my point. The dependency descriptors would
>> describe services within the registry. It would be necessary when there
>> are
>> cases where there are two services which implement the same service
>> interface. A dependency descriptor might look something like...
>>
>> public class DependencyDescriptor
>> {
>> private String propertyName;
>> private Class propertyType;
>> private String serviceId;
>> private String moduleId;
>>
>> // Setters/Getters...
>> }
>>
>> I'm not so sure if the propertyType is necessary, as it can be
>> determined
>> via reflection at runtime.
>>
>> James
>>
>> -----Original Message-----
>> From: Johan Lindquist [mailto:johan@kawoo.co.uk]
>> Sent: Tuesday, February 08, 2005 11:03 AM
>> To: hivemind-dev@jakarta.apache.org
>> Subject: Re: <bean> element
>>
>> I would be happy with just the first case to begin with - whatever is
>> registered within the registry, inject it, otherwise, well, too bad ...
>> If
>> we need to start defining further descriptors outside of the registry,
>> we
>> sort of break the usage of hivemind in the first place or?
>>
>> And I think that having the ability to inject configurations would be
>> good
>> in that you could use that config for display purposes (in a separate
>> part
>> of the system) ...
>>
>> Cheers,
>>
>> Johan
>>
>> On Tue, 8 Feb 2005 08:45:18 -0500, James Carman
>> <ja...@carmanconsulting.com> wrote:
>>
>>> The service shouldn't be limited to just "autowiring" scenarios. It
>>> should
>>> be able to inject ANYTHING, given the necessary
>>> DependencyDescriptor(s).
>>> Something like...
>>>
>>> public interface DependencyInjector
>>> {
>>> public void inject( Object bean );
>>> public void inject( Object bean, DependencyDescriptor[] descriptors
>>> );
>>> }
>>>
>>> Also, would we want to have the option of specifying (maybe in
>>> DependencyDescriptor) a module scope for the dependency? That way, our
>>> programs wouldn't break when we add a new module which defines a new
>>> service
>>> implementing the same service interface as our dependency.
>>>
>>> Would we ever want to inject configurations into something outside the
>>> registry or do you think that's overkill?
>>>
>>> -----Original Message-----
>>> From: Johan Lindquist [mailto:johan@kawoo.co.uk]
>>> Sent: Tuesday, February 08, 2005 8:27 AM
>>> To: hivemind-dev@jakarta.apache.org
>>> Subject: Re: <bean> element
>>>
>>> I agree with Knut on this one - as you get used to using
>>> interface/implementation pairs, even prototyping becomes a brease
>>> (especially with the refactoring support available in popular IDEs) ...
>>> The pain of refactoring all the descriptors just doesn't seem worth it
>>> in
>>> my opinion.
>>>
>>> I also like the idea of exposing a service which would auto-wire beans
>>> -
>>> would be a +1 from me on that one.
>>>
>>> Cheers,
>>>
>>> Johan
>>>
>>> On Tue, 8 Feb 2005 13:24:34 +0100, Knut Wannheden
>>> <kn...@gmail.com> wrote:
>>>
>>>> I think it would be quite interesting to know what others think about
>>>> this proposal as I'm not sure how I'd personally use it either.
>>>>
>>>> I have in the past argued for supporting interface-less services
>>>> because I think it would be great for prototyping and exploring the
>>>> problem domain. Eventually, as I'm clear on the responsibilities of
>>>> the services, I'd however convert the beans to services.
>>>>
>>>> What this would look like with a top-level <bean> element: If I at
>>>> some point decide to add an interface to my bean and turn it into a
>>>> service then I have to both change the <bean> element into a
>>>> <service-point> *and* change all references to it. References exist as
>>>> type declarations of autowired constructor parameters and setter
>>>> parameters, any uses of the "bean:" object provider, and possibly also
>>>> <set-bean> elements. This means quite a bit of work, which I think in
>>>> the end would keep me from using <bean>s for prototyping.
>>>>
>>>> So I am wondering how others who have argued for interface-less
>>>> services feel about this proposal. What problems would (or wouldn't)
>>>> it solve for you?
>>>>
>>>> I'd prefer if the <service-point> element could be used as is. Beans
>>>> would simply declare the bean class itself as their "interface". All
>>>> other restrictions (e.g. service model) could be enforced by HiveMind.
>>>> But I can see how this could be confusing.
>>>>
>>>> Apart from that there is something I think would be even more useful
>>>> wrt beans: A HiveMind service or a programmatic interface which can be
>>>> used to instantiate and / or autowire beans. I find myself quite often
>>>> defining a factory or repository type of service which builds POJOs
>>>> and where access to autowiring would be very useful.
>>>>
>>>> --knut
>>>>
>>>> On Sun, 6 Feb 2005 13:54:20 -0500, Howard Lewis Ship
>>>> <hl...@gmail.com>
>>>> wrote:
>>>>> Part of this has been discussed on the wiki:
>>>>>
>>>>> http://wiki.apache.org/jakarta-hivemind/PojoServices
>>>>>
>>>>> People chafe at the use of interfaces for one-time use objects, but
>>>>> still want all the dependency injection that BuilderFactory provides.
>>>>>
>>>>> Adding a new <bean> element would solve a fair amount of this.
>>>>>
>>>>> It wouldn't be quite inline, it might be more like:
>>>>>
>>>>> <set-object property="databaseAccess" value="bean:DatabaseAccess"/>
>>>>>
>>>>> ...
>>>>>
>>>>> <bean id="DatabaseAccess">
>>>>>
>>>>> <construct class="mypackage.DatabaseAccess">
>>>>> <set-object property="daoService" value="service:DAOService"/>
>>>>> </construct>
>>>>> </bean>
>>>>>
>>>>> In this way, beans would be another namespace like services and
>>>>> configurations, could have visibility, etc.
>>>>>
>>>>> I think we could also dress up the instance: object provider to do
>>>>> some *simple* configuration of the object, i.e.:
>>>>>
>>>>>
>>>
>>
> instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringPro
>>> perty='some
>>>>> string'
>>>>>
>>>>> You can already do some of this using hivemind.lib.BeanFactory.
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: element
Posted by James Carman <ja...@carmanconsulting.com>.
Johan,
How does the "resolver pattern" differ from mere auto-wiring? The problem
with auto-wiring is that your dependencies can be injected just fine at one
point. But, suppose you add in another module to your application which
exposes another service that implements the service interface you were
using. Then, all of a sudden, your stuff (which used to work) breaks!
Yuck!
James
-----Original Message-----
From: Johan Lindquist [mailto:johan@kawoo.co.uk]
Sent: Tuesday, February 08, 2005 11:39 AM
To: hivemind-dev@jakarta.apache.org
Subject: Re: <bean> element
Yup, missed it fully - and yes, that makes sense ... :) It would however
build in knownledge about service id's etc (which would have to be kept in
synch) into the code, but I guess that is not the biggest of problems.
What about using some sort of ResolverPattern? For this service
interface, give me the instance to use??
Cheers,
Johan
On Tue, 8 Feb 2005 11:06:04 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Johan,
> I think you may be missing my point. The dependency descriptors would
> describe services within the registry. It would be necessary when there
> are
> cases where there are two services which implement the same service
> interface. A dependency descriptor might look something like...
>
> public class DependencyDescriptor
> {
> private String propertyName;
> private Class propertyType;
> private String serviceId;
> private String moduleId;
>
> // Setters/Getters...
> }
>
> I'm not so sure if the propertyType is necessary, as it can be determined
> via reflection at runtime.
>
> James
>
> -----Original Message-----
> From: Johan Lindquist [mailto:johan@kawoo.co.uk]
> Sent: Tuesday, February 08, 2005 11:03 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: <bean> element
>
> I would be happy with just the first case to begin with - whatever is
> registered within the registry, inject it, otherwise, well, too bad ...
> If
> we need to start defining further descriptors outside of the registry, we
> sort of break the usage of hivemind in the first place or?
>
> And I think that having the ability to inject configurations would be
> good
> in that you could use that config for display purposes (in a separate
> part
> of the system) ...
>
> Cheers,
>
> Johan
>
> On Tue, 8 Feb 2005 08:45:18 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
>
>> The service shouldn't be limited to just "autowiring" scenarios. It
>> should
>> be able to inject ANYTHING, given the necessary DependencyDescriptor(s).
>> Something like...
>>
>> public interface DependencyInjector
>> {
>> public void inject( Object bean );
>> public void inject( Object bean, DependencyDescriptor[] descriptors );
>> }
>>
>> Also, would we want to have the option of specifying (maybe in
>> DependencyDescriptor) a module scope for the dependency? That way, our
>> programs wouldn't break when we add a new module which defines a new
>> service
>> implementing the same service interface as our dependency.
>>
>> Would we ever want to inject configurations into something outside the
>> registry or do you think that's overkill?
>>
>> -----Original Message-----
>> From: Johan Lindquist [mailto:johan@kawoo.co.uk]
>> Sent: Tuesday, February 08, 2005 8:27 AM
>> To: hivemind-dev@jakarta.apache.org
>> Subject: Re: <bean> element
>>
>> I agree with Knut on this one - as you get used to using
>> interface/implementation pairs, even prototyping becomes a brease
>> (especially with the refactoring support available in popular IDEs) ...
>> The pain of refactoring all the descriptors just doesn't seem worth it
>> in
>> my opinion.
>>
>> I also like the idea of exposing a service which would auto-wire beans -
>> would be a +1 from me on that one.
>>
>> Cheers,
>>
>> Johan
>>
>> On Tue, 8 Feb 2005 13:24:34 +0100, Knut Wannheden
>> <kn...@gmail.com> wrote:
>>
>>> I think it would be quite interesting to know what others think about
>>> this proposal as I'm not sure how I'd personally use it either.
>>>
>>> I have in the past argued for supporting interface-less services
>>> because I think it would be great for prototyping and exploring the
>>> problem domain. Eventually, as I'm clear on the responsibilities of
>>> the services, I'd however convert the beans to services.
>>>
>>> What this would look like with a top-level <bean> element: If I at
>>> some point decide to add an interface to my bean and turn it into a
>>> service then I have to both change the <bean> element into a
>>> <service-point> *and* change all references to it. References exist as
>>> type declarations of autowired constructor parameters and setter
>>> parameters, any uses of the "bean:" object provider, and possibly also
>>> <set-bean> elements. This means quite a bit of work, which I think in
>>> the end would keep me from using <bean>s for prototyping.
>>>
>>> So I am wondering how others who have argued for interface-less
>>> services feel about this proposal. What problems would (or wouldn't)
>>> it solve for you?
>>>
>>> I'd prefer if the <service-point> element could be used as is. Beans
>>> would simply declare the bean class itself as their "interface". All
>>> other restrictions (e.g. service model) could be enforced by HiveMind.
>>> But I can see how this could be confusing.
>>>
>>> Apart from that there is something I think would be even more useful
>>> wrt beans: A HiveMind service or a programmatic interface which can be
>>> used to instantiate and / or autowire beans. I find myself quite often
>>> defining a factory or repository type of service which builds POJOs
>>> and where access to autowiring would be very useful.
>>>
>>> --knut
>>>
>>> On Sun, 6 Feb 2005 13:54:20 -0500, Howard Lewis Ship <hl...@gmail.com>
>>> wrote:
>>>> Part of this has been discussed on the wiki:
>>>>
>>>> http://wiki.apache.org/jakarta-hivemind/PojoServices
>>>>
>>>> People chafe at the use of interfaces for one-time use objects, but
>>>> still want all the dependency injection that BuilderFactory provides.
>>>>
>>>> Adding a new <bean> element would solve a fair amount of this.
>>>>
>>>> It wouldn't be quite inline, it might be more like:
>>>>
>>>> <set-object property="databaseAccess" value="bean:DatabaseAccess"/>
>>>>
>>>> ...
>>>>
>>>> <bean id="DatabaseAccess">
>>>>
>>>> <construct class="mypackage.DatabaseAccess">
>>>> <set-object property="daoService" value="service:DAOService"/>
>>>> </construct>
>>>> </bean>
>>>>
>>>> In this way, beans would be another namespace like services and
>>>> configurations, could have visibility, etc.
>>>>
>>>> I think we could also dress up the instance: object provider to do
>>>> some *simple* configuration of the object, i.e.:
>>>>
>>>>
>>
>
instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringPro
>> perty='some
>>>> string'
>>>>
>>>> You can already do some of this using hivemind.lib.BeanFactory.
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>
>
>
--
you too?
---------------------------------------------------------------------
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: element
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
Yup, missed it fully - and yes, that makes sense ... :) It would however
build in knownledge about service id's etc (which would have to be kept in
synch) into the code, but I guess that is not the biggest of problems.
What about using some sort of ResolverPattern? For this service
interface, give me the instance to use??
Cheers,
Johan
On Tue, 8 Feb 2005 11:06:04 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Johan,
> I think you may be missing my point. The dependency descriptors would
> describe services within the registry. It would be necessary when there
> are
> cases where there are two services which implement the same service
> interface. A dependency descriptor might look something like...
>
> public class DependencyDescriptor
> {
> private String propertyName;
> private Class propertyType;
> private String serviceId;
> private String moduleId;
>
> // Setters/Getters...
> }
>
> I'm not so sure if the propertyType is necessary, as it can be determined
> via reflection at runtime.
>
> James
>
> -----Original Message-----
> From: Johan Lindquist [mailto:johan@kawoo.co.uk]
> Sent: Tuesday, February 08, 2005 11:03 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: <bean> element
>
> I would be happy with just the first case to begin with - whatever is
> registered within the registry, inject it, otherwise, well, too bad ...
> If
> we need to start defining further descriptors outside of the registry, we
> sort of break the usage of hivemind in the first place or?
>
> And I think that having the ability to inject configurations would be
> good
> in that you could use that config for display purposes (in a separate
> part
> of the system) ...
>
> Cheers,
>
> Johan
>
> On Tue, 8 Feb 2005 08:45:18 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
>
>> The service shouldn't be limited to just "autowiring" scenarios. It
>> should
>> be able to inject ANYTHING, given the necessary DependencyDescriptor(s).
>> Something like...
>>
>> public interface DependencyInjector
>> {
>> public void inject( Object bean );
>> public void inject( Object bean, DependencyDescriptor[] descriptors );
>> }
>>
>> Also, would we want to have the option of specifying (maybe in
>> DependencyDescriptor) a module scope for the dependency? That way, our
>> programs wouldn't break when we add a new module which defines a new
>> service
>> implementing the same service interface as our dependency.
>>
>> Would we ever want to inject configurations into something outside the
>> registry or do you think that's overkill?
>>
>> -----Original Message-----
>> From: Johan Lindquist [mailto:johan@kawoo.co.uk]
>> Sent: Tuesday, February 08, 2005 8:27 AM
>> To: hivemind-dev@jakarta.apache.org
>> Subject: Re: <bean> element
>>
>> I agree with Knut on this one - as you get used to using
>> interface/implementation pairs, even prototyping becomes a brease
>> (especially with the refactoring support available in popular IDEs) ...
>> The pain of refactoring all the descriptors just doesn't seem worth it
>> in
>> my opinion.
>>
>> I also like the idea of exposing a service which would auto-wire beans -
>> would be a +1 from me on that one.
>>
>> Cheers,
>>
>> Johan
>>
>> On Tue, 8 Feb 2005 13:24:34 +0100, Knut Wannheden
>> <kn...@gmail.com> wrote:
>>
>>> I think it would be quite interesting to know what others think about
>>> this proposal as I'm not sure how I'd personally use it either.
>>>
>>> I have in the past argued for supporting interface-less services
>>> because I think it would be great for prototyping and exploring the
>>> problem domain. Eventually, as I'm clear on the responsibilities of
>>> the services, I'd however convert the beans to services.
>>>
>>> What this would look like with a top-level <bean> element: If I at
>>> some point decide to add an interface to my bean and turn it into a
>>> service then I have to both change the <bean> element into a
>>> <service-point> *and* change all references to it. References exist as
>>> type declarations of autowired constructor parameters and setter
>>> parameters, any uses of the "bean:" object provider, and possibly also
>>> <set-bean> elements. This means quite a bit of work, which I think in
>>> the end would keep me from using <bean>s for prototyping.
>>>
>>> So I am wondering how others who have argued for interface-less
>>> services feel about this proposal. What problems would (or wouldn't)
>>> it solve for you?
>>>
>>> I'd prefer if the <service-point> element could be used as is. Beans
>>> would simply declare the bean class itself as their "interface". All
>>> other restrictions (e.g. service model) could be enforced by HiveMind.
>>> But I can see how this could be confusing.
>>>
>>> Apart from that there is something I think would be even more useful
>>> wrt beans: A HiveMind service or a programmatic interface which can be
>>> used to instantiate and / or autowire beans. I find myself quite often
>>> defining a factory or repository type of service which builds POJOs
>>> and where access to autowiring would be very useful.
>>>
>>> --knut
>>>
>>> On Sun, 6 Feb 2005 13:54:20 -0500, Howard Lewis Ship <hl...@gmail.com>
>>> wrote:
>>>> Part of this has been discussed on the wiki:
>>>>
>>>> http://wiki.apache.org/jakarta-hivemind/PojoServices
>>>>
>>>> People chafe at the use of interfaces for one-time use objects, but
>>>> still want all the dependency injection that BuilderFactory provides.
>>>>
>>>> Adding a new <bean> element would solve a fair amount of this.
>>>>
>>>> It wouldn't be quite inline, it might be more like:
>>>>
>>>> <set-object property="databaseAccess" value="bean:DatabaseAccess"/>
>>>>
>>>> ...
>>>>
>>>> <bean id="DatabaseAccess">
>>>>
>>>> <construct class="mypackage.DatabaseAccess">
>>>> <set-object property="daoService" value="service:DAOService"/>
>>>> </construct>
>>>> </bean>
>>>>
>>>> In this way, beans would be another namespace like services and
>>>> configurations, could have visibility, etc.
>>>>
>>>> I think we could also dress up the instance: object provider to do
>>>> some *simple* configuration of the object, i.e.:
>>>>
>>>>
>>
> instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringPro
>> perty='some
>>>> string'
>>>>
>>>> You can already do some of this using hivemind.lib.BeanFactory.
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: element
Posted by James Carman <ja...@carmanconsulting.com>.
Johan,
I think you may be missing my point. The dependency descriptors would
describe services within the registry. It would be necessary when there are
cases where there are two services which implement the same service
interface. A dependency descriptor might look something like...
public class DependencyDescriptor
{
private String propertyName;
private Class propertyType;
private String serviceId;
private String moduleId;
// Setters/Getters...
}
I'm not so sure if the propertyType is necessary, as it can be determined
via reflection at runtime.
James
-----Original Message-----
From: Johan Lindquist [mailto:johan@kawoo.co.uk]
Sent: Tuesday, February 08, 2005 11:03 AM
To: hivemind-dev@jakarta.apache.org
Subject: Re: <bean> element
I would be happy with just the first case to begin with - whatever is
registered within the registry, inject it, otherwise, well, too bad ... If
we need to start defining further descriptors outside of the registry, we
sort of break the usage of hivemind in the first place or?
And I think that having the ability to inject configurations would be good
in that you could use that config for display purposes (in a separate part
of the system) ...
Cheers,
Johan
On Tue, 8 Feb 2005 08:45:18 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> The service shouldn't be limited to just "autowiring" scenarios. It
> should
> be able to inject ANYTHING, given the necessary DependencyDescriptor(s).
> Something like...
>
> public interface DependencyInjector
> {
> public void inject( Object bean );
> public void inject( Object bean, DependencyDescriptor[] descriptors );
> }
>
> Also, would we want to have the option of specifying (maybe in
> DependencyDescriptor) a module scope for the dependency? That way, our
> programs wouldn't break when we add a new module which defines a new
> service
> implementing the same service interface as our dependency.
>
> Would we ever want to inject configurations into something outside the
> registry or do you think that's overkill?
>
> -----Original Message-----
> From: Johan Lindquist [mailto:johan@kawoo.co.uk]
> Sent: Tuesday, February 08, 2005 8:27 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: <bean> element
>
> I agree with Knut on this one - as you get used to using
> interface/implementation pairs, even prototyping becomes a brease
> (especially with the refactoring support available in popular IDEs) ...
> The pain of refactoring all the descriptors just doesn't seem worth it in
> my opinion.
>
> I also like the idea of exposing a service which would auto-wire beans -
> would be a +1 from me on that one.
>
> Cheers,
>
> Johan
>
> On Tue, 8 Feb 2005 13:24:34 +0100, Knut Wannheden
> <kn...@gmail.com> wrote:
>
>> I think it would be quite interesting to know what others think about
>> this proposal as I'm not sure how I'd personally use it either.
>>
>> I have in the past argued for supporting interface-less services
>> because I think it would be great for prototyping and exploring the
>> problem domain. Eventually, as I'm clear on the responsibilities of
>> the services, I'd however convert the beans to services.
>>
>> What this would look like with a top-level <bean> element: If I at
>> some point decide to add an interface to my bean and turn it into a
>> service then I have to both change the <bean> element into a
>> <service-point> *and* change all references to it. References exist as
>> type declarations of autowired constructor parameters and setter
>> parameters, any uses of the "bean:" object provider, and possibly also
>> <set-bean> elements. This means quite a bit of work, which I think in
>> the end would keep me from using <bean>s for prototyping.
>>
>> So I am wondering how others who have argued for interface-less
>> services feel about this proposal. What problems would (or wouldn't)
>> it solve for you?
>>
>> I'd prefer if the <service-point> element could be used as is. Beans
>> would simply declare the bean class itself as their "interface". All
>> other restrictions (e.g. service model) could be enforced by HiveMind.
>> But I can see how this could be confusing.
>>
>> Apart from that there is something I think would be even more useful
>> wrt beans: A HiveMind service or a programmatic interface which can be
>> used to instantiate and / or autowire beans. I find myself quite often
>> defining a factory or repository type of service which builds POJOs
>> and where access to autowiring would be very useful.
>>
>> --knut
>>
>> On Sun, 6 Feb 2005 13:54:20 -0500, Howard Lewis Ship <hl...@gmail.com>
>> wrote:
>>> Part of this has been discussed on the wiki:
>>>
>>> http://wiki.apache.org/jakarta-hivemind/PojoServices
>>>
>>> People chafe at the use of interfaces for one-time use objects, but
>>> still want all the dependency injection that BuilderFactory provides.
>>>
>>> Adding a new <bean> element would solve a fair amount of this.
>>>
>>> It wouldn't be quite inline, it might be more like:
>>>
>>> <set-object property="databaseAccess" value="bean:DatabaseAccess"/>
>>>
>>> ...
>>>
>>> <bean id="DatabaseAccess">
>>>
>>> <construct class="mypackage.DatabaseAccess">
>>> <set-object property="daoService" value="service:DAOService"/>
>>> </construct>
>>> </bean>
>>>
>>> In this way, beans would be another namespace like services and
>>> configurations, could have visibility, etc.
>>>
>>> I think we could also dress up the instance: object provider to do
>>> some *simple* configuration of the object, i.e.:
>>>
>>>
>
instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringPro
> perty='some
>>> string'
>>>
>>> You can already do some of this using hivemind.lib.BeanFactory.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>
>>
>
>
>
--
you too?
---------------------------------------------------------------------
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: element
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
I would be happy with just the first case to begin with - whatever is
registered within the registry, inject it, otherwise, well, too bad ... If
we need to start defining further descriptors outside of the registry, we
sort of break the usage of hivemind in the first place or?
And I think that having the ability to inject configurations would be good
in that you could use that config for display purposes (in a separate part
of the system) ...
Cheers,
Johan
On Tue, 8 Feb 2005 08:45:18 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> The service shouldn't be limited to just "autowiring" scenarios. It
> should
> be able to inject ANYTHING, given the necessary DependencyDescriptor(s).
> Something like...
>
> public interface DependencyInjector
> {
> public void inject( Object bean );
> public void inject( Object bean, DependencyDescriptor[] descriptors );
> }
>
> Also, would we want to have the option of specifying (maybe in
> DependencyDescriptor) a module scope for the dependency? That way, our
> programs wouldn't break when we add a new module which defines a new
> service
> implementing the same service interface as our dependency.
>
> Would we ever want to inject configurations into something outside the
> registry or do you think that's overkill?
>
> -----Original Message-----
> From: Johan Lindquist [mailto:johan@kawoo.co.uk]
> Sent: Tuesday, February 08, 2005 8:27 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: <bean> element
>
> I agree with Knut on this one - as you get used to using
> interface/implementation pairs, even prototyping becomes a brease
> (especially with the refactoring support available in popular IDEs) ...
> The pain of refactoring all the descriptors just doesn't seem worth it in
> my opinion.
>
> I also like the idea of exposing a service which would auto-wire beans -
> would be a +1 from me on that one.
>
> Cheers,
>
> Johan
>
> On Tue, 8 Feb 2005 13:24:34 +0100, Knut Wannheden
> <kn...@gmail.com> wrote:
>
>> I think it would be quite interesting to know what others think about
>> this proposal as I'm not sure how I'd personally use it either.
>>
>> I have in the past argued for supporting interface-less services
>> because I think it would be great for prototyping and exploring the
>> problem domain. Eventually, as I'm clear on the responsibilities of
>> the services, I'd however convert the beans to services.
>>
>> What this would look like with a top-level <bean> element: If I at
>> some point decide to add an interface to my bean and turn it into a
>> service then I have to both change the <bean> element into a
>> <service-point> *and* change all references to it. References exist as
>> type declarations of autowired constructor parameters and setter
>> parameters, any uses of the "bean:" object provider, and possibly also
>> <set-bean> elements. This means quite a bit of work, which I think in
>> the end would keep me from using <bean>s for prototyping.
>>
>> So I am wondering how others who have argued for interface-less
>> services feel about this proposal. What problems would (or wouldn't)
>> it solve for you?
>>
>> I'd prefer if the <service-point> element could be used as is. Beans
>> would simply declare the bean class itself as their "interface". All
>> other restrictions (e.g. service model) could be enforced by HiveMind.
>> But I can see how this could be confusing.
>>
>> Apart from that there is something I think would be even more useful
>> wrt beans: A HiveMind service or a programmatic interface which can be
>> used to instantiate and / or autowire beans. I find myself quite often
>> defining a factory or repository type of service which builds POJOs
>> and where access to autowiring would be very useful.
>>
>> --knut
>>
>> On Sun, 6 Feb 2005 13:54:20 -0500, Howard Lewis Ship <hl...@gmail.com>
>> wrote:
>>> Part of this has been discussed on the wiki:
>>>
>>> http://wiki.apache.org/jakarta-hivemind/PojoServices
>>>
>>> People chafe at the use of interfaces for one-time use objects, but
>>> still want all the dependency injection that BuilderFactory provides.
>>>
>>> Adding a new <bean> element would solve a fair amount of this.
>>>
>>> It wouldn't be quite inline, it might be more like:
>>>
>>> <set-object property="databaseAccess" value="bean:DatabaseAccess"/>
>>>
>>> ...
>>>
>>> <bean id="DatabaseAccess">
>>>
>>> <construct class="mypackage.DatabaseAccess">
>>> <set-object property="daoService" value="service:DAOService"/>
>>> </construct>
>>> </bean>
>>>
>>> In this way, beans would be another namespace like services and
>>> configurations, could have visibility, etc.
>>>
>>> I think we could also dress up the instance: object provider to do
>>> some *simple* configuration of the object, i.e.:
>>>
>>>
> instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringPro
> perty='some
>>> string'
>>>
>>> You can already do some of this using hivemind.lib.BeanFactory.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>
>>
>
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: element
Posted by James Carman <ja...@carmanconsulting.com>.
The service shouldn't be limited to just "autowiring" scenarios. It should
be able to inject ANYTHING, given the necessary DependencyDescriptor(s).
Something like...
public interface DependencyInjector
{
public void inject( Object bean );
public void inject( Object bean, DependencyDescriptor[] descriptors );
}
Also, would we want to have the option of specifying (maybe in
DependencyDescriptor) a module scope for the dependency? That way, our
programs wouldn't break when we add a new module which defines a new service
implementing the same service interface as our dependency.
Would we ever want to inject configurations into something outside the
registry or do you think that's overkill?
-----Original Message-----
From: Johan Lindquist [mailto:johan@kawoo.co.uk]
Sent: Tuesday, February 08, 2005 8:27 AM
To: hivemind-dev@jakarta.apache.org
Subject: Re: <bean> element
I agree with Knut on this one - as you get used to using
interface/implementation pairs, even prototyping becomes a brease
(especially with the refactoring support available in popular IDEs) ...
The pain of refactoring all the descriptors just doesn't seem worth it in
my opinion.
I also like the idea of exposing a service which would auto-wire beans -
would be a +1 from me on that one.
Cheers,
Johan
On Tue, 8 Feb 2005 13:24:34 +0100, Knut Wannheden
<kn...@gmail.com> wrote:
> I think it would be quite interesting to know what others think about
> this proposal as I'm not sure how I'd personally use it either.
>
> I have in the past argued for supporting interface-less services
> because I think it would be great for prototyping and exploring the
> problem domain. Eventually, as I'm clear on the responsibilities of
> the services, I'd however convert the beans to services.
>
> What this would look like with a top-level <bean> element: If I at
> some point decide to add an interface to my bean and turn it into a
> service then I have to both change the <bean> element into a
> <service-point> *and* change all references to it. References exist as
> type declarations of autowired constructor parameters and setter
> parameters, any uses of the "bean:" object provider, and possibly also
> <set-bean> elements. This means quite a bit of work, which I think in
> the end would keep me from using <bean>s for prototyping.
>
> So I am wondering how others who have argued for interface-less
> services feel about this proposal. What problems would (or wouldn't)
> it solve for you?
>
> I'd prefer if the <service-point> element could be used as is. Beans
> would simply declare the bean class itself as their "interface". All
> other restrictions (e.g. service model) could be enforced by HiveMind.
> But I can see how this could be confusing.
>
> Apart from that there is something I think would be even more useful
> wrt beans: A HiveMind service or a programmatic interface which can be
> used to instantiate and / or autowire beans. I find myself quite often
> defining a factory or repository type of service which builds POJOs
> and where access to autowiring would be very useful.
>
> --knut
>
> On Sun, 6 Feb 2005 13:54:20 -0500, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>> Part of this has been discussed on the wiki:
>>
>> http://wiki.apache.org/jakarta-hivemind/PojoServices
>>
>> People chafe at the use of interfaces for one-time use objects, but
>> still want all the dependency injection that BuilderFactory provides.
>>
>> Adding a new <bean> element would solve a fair amount of this.
>>
>> It wouldn't be quite inline, it might be more like:
>>
>> <set-object property="databaseAccess" value="bean:DatabaseAccess"/>
>>
>> ...
>>
>> <bean id="DatabaseAccess">
>>
>> <construct class="mypackage.DatabaseAccess">
>> <set-object property="daoService" value="service:DAOService"/>
>> </construct>
>> </bean>
>>
>> In this way, beans would be another namespace like services and
>> configurations, could have visibility, etc.
>>
>> I think we could also dress up the instance: object provider to do
>> some *simple* configuration of the object, i.e.:
>>
>>
instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringPro
perty='some
>> string'
>>
>> You can already do some of this using hivemind.lib.BeanFactory.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
you too?
---------------------------------------------------------------------
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: element
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
I agree with Knut on this one - as you get used to using
interface/implementation pairs, even prototyping becomes a brease
(especially with the refactoring support available in popular IDEs) ...
The pain of refactoring all the descriptors just doesn't seem worth it in
my opinion.
I also like the idea of exposing a service which would auto-wire beans -
would be a +1 from me on that one.
Cheers,
Johan
On Tue, 8 Feb 2005 13:24:34 +0100, Knut Wannheden
<kn...@gmail.com> wrote:
> I think it would be quite interesting to know what others think about
> this proposal as I'm not sure how I'd personally use it either.
>
> I have in the past argued for supporting interface-less services
> because I think it would be great for prototyping and exploring the
> problem domain. Eventually, as I'm clear on the responsibilities of
> the services, I'd however convert the beans to services.
>
> What this would look like with a top-level <bean> element: If I at
> some point decide to add an interface to my bean and turn it into a
> service then I have to both change the <bean> element into a
> <service-point> *and* change all references to it. References exist as
> type declarations of autowired constructor parameters and setter
> parameters, any uses of the "bean:" object provider, and possibly also
> <set-bean> elements. This means quite a bit of work, which I think in
> the end would keep me from using <bean>s for prototyping.
>
> So I am wondering how others who have argued for interface-less
> services feel about this proposal. What problems would (or wouldn't)
> it solve for you?
>
> I'd prefer if the <service-point> element could be used as is. Beans
> would simply declare the bean class itself as their "interface". All
> other restrictions (e.g. service model) could be enforced by HiveMind.
> But I can see how this could be confusing.
>
> Apart from that there is something I think would be even more useful
> wrt beans: A HiveMind service or a programmatic interface which can be
> used to instantiate and / or autowire beans. I find myself quite often
> defining a factory or repository type of service which builds POJOs
> and where access to autowiring would be very useful.
>
> --knut
>
> On Sun, 6 Feb 2005 13:54:20 -0500, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>> Part of this has been discussed on the wiki:
>>
>> http://wiki.apache.org/jakarta-hivemind/PojoServices
>>
>> People chafe at the use of interfaces for one-time use objects, but
>> still want all the dependency injection that BuilderFactory provides.
>>
>> Adding a new <bean> element would solve a fair amount of this.
>>
>> It wouldn't be quite inline, it might be more like:
>>
>> <set-object property="databaseAccess" value="bean:DatabaseAccess"/>
>>
>> ...
>>
>> <bean id="DatabaseAccess">
>>
>> <construct class="mypackage.DatabaseAccess">
>> <set-object property="daoService" value="service:DAOService"/>
>> </construct>
>> </bean>
>>
>> In this way, beans would be another namespace like services and
>> configurations, could have visibility, etc.
>>
>> I think we could also dress up the instance: object provider to do
>> some *simple* configuration of the object, i.e.:
>>
>> instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringProperty='some
>> string'
>>
>> You can already do some of this using hivemind.lib.BeanFactory.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: element
Posted by Harish Krishnaswamy <ha...@gmail.com>.
I am on the same boat as Knut. Initially I did think that "beans" will
be useful but in the last year I have seen no use for a bean when
configurations are available. Now that does NOT mean that there is no
need for it, but I personally would like see a concrete scenario where
it can be useful before giving my vote. My current stand is managed
objects are always either services or configurations.
-Harish
On Tue, 8 Feb 2005 13:24:34 +0100, Knut Wannheden
<kn...@gmail.com> wrote:
> I think it would be quite interesting to know what others think about
> this proposal as I'm not sure how I'd personally use it either.
>
> I have in the past argued for supporting interface-less services
> because I think it would be great for prototyping and exploring the
> problem domain. Eventually, as I'm clear on the responsibilities of
> the services, I'd however convert the beans to services.
>
> What this would look like with a top-level <bean> element: If I at
> some point decide to add an interface to my bean and turn it into a
> service then I have to both change the <bean> element into a
> <service-point> *and* change all references to it. References exist as
> type declarations of autowired constructor parameters and setter
> parameters, any uses of the "bean:" object provider, and possibly also
> <set-bean> elements. This means quite a bit of work, which I think in
> the end would keep me from using <bean>s for prototyping.
>
> So I am wondering how others who have argued for interface-less
> services feel about this proposal. What problems would (or wouldn't)
> it solve for you?
>
> I'd prefer if the <service-point> element could be used as is. Beans
> would simply declare the bean class itself as their "interface". All
> other restrictions (e.g. service model) could be enforced by HiveMind.
> But I can see how this could be confusing.
>
> Apart from that there is something I think would be even more useful
> wrt beans: A HiveMind service or a programmatic interface which can be
> used to instantiate and / or autowire beans. I find myself quite often
> defining a factory or repository type of service which builds POJOs
> and where access to autowiring would be very useful.
>
> --knut
>
> On Sun, 6 Feb 2005 13:54:20 -0500, Howard Lewis Ship <hl...@gmail.com> wrote:
> > Part of this has been discussed on the wiki:
> >
> > http://wiki.apache.org/jakarta-hivemind/PojoServices
> >
> > People chafe at the use of interfaces for one-time use objects, but
> > still want all the dependency injection that BuilderFactory provides.
> >
> > Adding a new <bean> element would solve a fair amount of this.
> >
> > It wouldn't be quite inline, it might be more like:
> >
> > <set-object property="databaseAccess" value="bean:DatabaseAccess"/>
> >
> > ...
> >
> > <bean id="DatabaseAccess">
> >
> > <construct class="mypackage.DatabaseAccess">
> > <set-object property="daoService" value="service:DAOService"/>
> > </construct>
> > </bean>
> >
> > In this way, beans would be another namespace like services and
> > configurations, could have visibility, etc.
> >
> > I think we could also dress up the instance: object provider to do
> > some *simple* configuration of the object, i.e.:
> >
> > instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringProperty='some
> > string'
> >
> > You can already do some of this using hivemind.lib.BeanFactory.
> >
>
> ---------------------------------------------------------------------
> 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: element
Posted by Knut Wannheden <kn...@gmail.com>.
I think it would be quite interesting to know what others think about
this proposal as I'm not sure how I'd personally use it either.
I have in the past argued for supporting interface-less services
because I think it would be great for prototyping and exploring the
problem domain. Eventually, as I'm clear on the responsibilities of
the services, I'd however convert the beans to services.
What this would look like with a top-level <bean> element: If I at
some point decide to add an interface to my bean and turn it into a
service then I have to both change the <bean> element into a
<service-point> *and* change all references to it. References exist as
type declarations of autowired constructor parameters and setter
parameters, any uses of the "bean:" object provider, and possibly also
<set-bean> elements. This means quite a bit of work, which I think in
the end would keep me from using <bean>s for prototyping.
So I am wondering how others who have argued for interface-less
services feel about this proposal. What problems would (or wouldn't)
it solve for you?
I'd prefer if the <service-point> element could be used as is. Beans
would simply declare the bean class itself as their "interface". All
other restrictions (e.g. service model) could be enforced by HiveMind.
But I can see how this could be confusing.
Apart from that there is something I think would be even more useful
wrt beans: A HiveMind service or a programmatic interface which can be
used to instantiate and / or autowire beans. I find myself quite often
defining a factory or repository type of service which builds POJOs
and where access to autowiring would be very useful.
--knut
On Sun, 6 Feb 2005 13:54:20 -0500, Howard Lewis Ship <hl...@gmail.com> wrote:
> Part of this has been discussed on the wiki:
>
> http://wiki.apache.org/jakarta-hivemind/PojoServices
>
> People chafe at the use of interfaces for one-time use objects, but
> still want all the dependency injection that BuilderFactory provides.
>
> Adding a new <bean> element would solve a fair amount of this.
>
> It wouldn't be quite inline, it might be more like:
>
> <set-object property="databaseAccess" value="bean:DatabaseAccess"/>
>
> ...
>
> <bean id="DatabaseAccess">
>
> <construct class="mypackage.DatabaseAccess">
> <set-object property="daoService" value="service:DAOService"/>
> </construct>
> </bean>
>
> In this way, beans would be another namespace like services and
> configurations, could have visibility, etc.
>
> I think we could also dress up the instance: object provider to do
> some *simple* configuration of the object, i.e.:
>
> instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringProperty='some
> string'
>
> You can already do some of this using hivemind.lib.BeanFactory.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: element
Posted by Jean-Francois Poilpret <jf...@hcm.vnn.vn>.
Hello,
I would like to add a few thoughts to this discussion.
I am currently trying to use HiveMind in client (Swing GUI application) and
in the current status (HM1.0, but HM1.1a1 would not bring much to me now), I
found the need for a "PojoFactory", but with needs wider than the ones you
describe.
In particular, I don't need "one-time" objects, but rather need a real
"factory" able to build several instances of the same pojo according to the
same configuration. The number of instances to create is never known in
advance (each instance can be a JPanel, a JTable...)
I finished building my own "ObjectBuilder" service (I would have preferred
"BeanFactory"...) with a very simple interface:
Object create(String name);
And a quite simple configuration (I did not try to reproduce the exact same
features as BuilderFactory, in particular I did not want/need auto-wiring):
<contribution configuration-id="ObjectBuilderObjects">
<object name="MyName" class=" MyClass">
<inject object="service:EventDispatcher"/>
</object>
<object name="OtherName" class="OtherClass">
<inject name="myProperty" object="object:MyName"/>
</object>
</contribution>
The contributions are quite simple since they reuse the "object" translator
and thus can inject:
- services
- configurations
- instances
- beans
- ...
Both constructor and setter injections are supported (if the "name"
attribute is defined then setter-injection is used).
I also added a new ObjectProvider (called "object:") so that other pojos can
be injected also (both in pojos and in services).
It would easily be possible to add new configuration settings so that a name
defines a unique instance (in cases where this would be necessary).
The first version I wrote was a breeze, thanks to HiveMind PropertyUtils and
ConstructorUtils.
Then very quick I discovered problems while using the ObjectTranslator: it
is only evaluated once and very early (as soon as the "ObjectBuilderObjects"
is read by the ObjectBuilder service). This involved two problems:
- all injections (pojos, beans, services, configs...) are instantiated at
the beginning of the application, even if the objects that use these
injections are never used!
- early evaluation could induce recursive calls inside HM (eg: inject a
configuration that itself uses the "object:" ObjectProvider)
So my second version added late evaluation of all injections: for this I
just passed the "object" attribute value as a String (ie, I did not use the
ObjectTranslator anymore at the configuration level). Then the ObjectBuilder
service itself would resolve all injections (by calling the ObjectTranslator
directly, which will be a problem in HM1.1 since the ObjectTranslator has
now private visibility).
Finally, my current version (maybe not the last one however) added the
possibility to inject constructor arguments directly through a new
ObjectBuilder.create(String name, Object[] args) method. In the config, I
just added a new <inject-arg/> empty element to indicate this fact.
This can be used, for instance, to build a JPanel subclass instance, with
some injected services (always the same) plus an additional parameter like
the DTO to show in the panel (which is always different and cannot be
statically configured).
I don't know if I am off-topic here, but I wanted to express my viewpoint
that a new <bean> element to define _individual_ pojos does not seem
interesting to me (I much prefer the service concept with interfaces). What
seems really interesting to me is to have the possibility to create several
instances of one class, with some injected args, and some user-passed args.
I am not sure this would be much useful on the server side, but for sure it
could bring much on the client GUI side (when I have finished my
ObjectBuilder, it eased a lot about adding new panels, new tables... in my
GUI).
Cheers
Jean-Francois
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Monday, February 07, 2005 1:54 AM
To: hivemind-dev@jakarta.apache.org
Subject: <bean> element
Part of this has been discussed on the wiki:
http://wiki.apache.org/jakarta-hivemind/PojoServices
People chafe at the use of interfaces for one-time use objects, but
still want all the dependency injection that BuilderFactory provides.
Adding a new <bean> element would solve a fair amount of this.
It wouldn't be quite inline, it might be more like:
<set-object property="databaseAccess" value="bean:DatabaseAccess"/>
...
<bean id="DatabaseAccess">
<construct class="mypackage.DatabaseAccess">
<set-object property="daoService" value="service:DAOService"/>
</construct>
</bean>
In this way, beans would be another namespace like services and
configurations, could have visibility, etc.
I think we could also dress up the instance: object provider to do
some *simple* configuration of the object, i.e.:
instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringPro
perty='some
string'
You can already do some of this using hivemind.lib.BeanFactory.
On Sun, 6 Feb 2005 10:14:37 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Knut,
>
> Maybe. But, is it really necessary to have to place them at the
top-level,
> especially if they're going to be used just one time? I guess I'd have to
> see an example descriptor file. Maybe I don't quite get what you guys are
> talking about.
>
> James
>
> -----Original Message-----
> From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
> Sent: Sunday, February 06, 2005 10:12 AM
> To: HiveMind Dev List; James Carman
> Subject: Re: AOPAlliance Service Interceptors...
>
> James,
>
> On Sun, 6 Feb 2005 09:44:47 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
> >
> > Well, I think if we're going to do this (generic, dependency injection
> > capable object builder), we should do it the right way. As soon as we
> > implement an object provider with this limited capability and no
> > work-around, someone is going to ask for an improvement. Then, we're
> going
> > to end up trying to encode dependency information (like what service-id
to
> > use when there are multiple services of the property type) into the
> "locator
> > string." What I would like to do would be something like this...
> >
> > <invoke-factory service-id="hivemind.BuilderFactory">
> > <construct class="myco.services.impl.MyServiceImpl">
> > <set-object property="a">
> > <construct class="myco.helpers.A" />
> > </set-object>
> > <set-object property="b">
> > <construct class="myco.helpers.B">
> > <set-service property="c" service-id="mymodule.A" />
> > </construct>
> > </set-object>
> > </construct>
> > </invoke-factory>
> >
> > Maybe we should let object providers provide a schema of their own.
> > Wouldn't that do the trick?
> >
>
> Wouldn't Howard's proposed top-level <bean> and the bean: object
> provider solve this? I find that easier to grasp :-)
>
> --knut
>
> ---------------------------------------------------------------------
> 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
>
>
--
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
element
Posted by Howard Lewis Ship <hl...@gmail.com>.
Part of this has been discussed on the wiki:
http://wiki.apache.org/jakarta-hivemind/PojoServices
People chafe at the use of interfaces for one-time use objects, but
still want all the dependency injection that BuilderFactory provides.
Adding a new <bean> element would solve a fair amount of this.
It wouldn't be quite inline, it might be more like:
<set-object property="databaseAccess" value="bean:DatabaseAccess"/>
...
<bean id="DatabaseAccess">
<construct class="mypackage.DatabaseAccess">
<set-object property="daoService" value="service:DAOService"/>
</construct>
</bean>
In this way, beans would be another namespace like services and
configurations, could have visibility, etc.
I think we could also dress up the instance: object provider to do
some *simple* configuration of the object, i.e.:
instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringProperty='some
string'
You can already do some of this using hivemind.lib.BeanFactory.
On Sun, 6 Feb 2005 10:14:37 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Knut,
>
> Maybe. But, is it really necessary to have to place them at the top-level,
> especially if they're going to be used just one time? I guess I'd have to
> see an example descriptor file. Maybe I don't quite get what you guys are
> talking about.
>
> James
>
> -----Original Message-----
> From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
> Sent: Sunday, February 06, 2005 10:12 AM
> To: HiveMind Dev List; James Carman
> Subject: Re: AOPAlliance Service Interceptors...
>
> James,
>
> On Sun, 6 Feb 2005 09:44:47 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
> >
> > Well, I think if we're going to do this (generic, dependency injection
> > capable object builder), we should do it the right way. As soon as we
> > implement an object provider with this limited capability and no
> > work-around, someone is going to ask for an improvement. Then, we're
> going
> > to end up trying to encode dependency information (like what service-id to
> > use when there are multiple services of the property type) into the
> "locator
> > string." What I would like to do would be something like this...
> >
> > <invoke-factory service-id="hivemind.BuilderFactory">
> > <construct class="myco.services.impl.MyServiceImpl">
> > <set-object property="a">
> > <construct class="myco.helpers.A" />
> > </set-object>
> > <set-object property="b">
> > <construct class="myco.helpers.B">
> > <set-service property="c" service-id="mymodule.A" />
> > </construct>
> > </set-object>
> > </construct>
> > </invoke-factory>
> >
> > Maybe we should let object providers provide a schema of their own.
> > Wouldn't that do the trick?
> >
>
> Wouldn't Howard's proposed top-level <bean> and the bean: object
> provider solve this? I find that easier to grasp :-)
>
> --knut
>
> ---------------------------------------------------------------------
> 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
>
>
--
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: AOPAlliance Service Interceptors...
Posted by James Carman <ja...@carmanconsulting.com>.
Knut,
Maybe. But, is it really necessary to have to place them at the top-level,
especially if they're going to be used just one time? I guess I'd have to
see an example descriptor file. Maybe I don't quite get what you guys are
talking about.
James
-----Original Message-----
From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
Sent: Sunday, February 06, 2005 10:12 AM
To: HiveMind Dev List; James Carman
Subject: Re: AOPAlliance Service Interceptors...
James,
On Sun, 6 Feb 2005 09:44:47 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
>
> Well, I think if we're going to do this (generic, dependency injection
> capable object builder), we should do it the right way. As soon as we
> implement an object provider with this limited capability and no
> work-around, someone is going to ask for an improvement. Then, we're
going
> to end up trying to encode dependency information (like what service-id to
> use when there are multiple services of the property type) into the
"locator
> string." What I would like to do would be something like this...
>
> <invoke-factory service-id="hivemind.BuilderFactory">
> <construct class="myco.services.impl.MyServiceImpl">
> <set-object property="a">
> <construct class="myco.helpers.A" />
> </set-object>
> <set-object property="b">
> <construct class="myco.helpers.B">
> <set-service property="c" service-id="mymodule.A" />
> </construct>
> </set-object>
> </construct>
> </invoke-factory>
>
> Maybe we should let object providers provide a schema of their own.
> Wouldn't that do the trick?
>
Wouldn't Howard's proposed top-level <bean> and the bean: object
provider solve this? I find that easier to grasp :-)
--knut
---------------------------------------------------------------------
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: AOPAlliance Service Interceptors...
Posted by Knut Wannheden <kn...@gmail.com>.
James,
On Sun, 6 Feb 2005 09:44:47 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
>
> Well, I think if we're going to do this (generic, dependency injection
> capable object builder), we should do it the right way. As soon as we
> implement an object provider with this limited capability and no
> work-around, someone is going to ask for an improvement. Then, we're going
> to end up trying to encode dependency information (like what service-id to
> use when there are multiple services of the property type) into the "locator
> string." What I would like to do would be something like this...
>
> <invoke-factory service-id="hivemind.BuilderFactory">
> <construct class="myco.services.impl.MyServiceImpl">
> <set-object property="a">
> <construct class="myco.helpers.A" />
> </set-object>
> <set-object property="b">
> <construct class="myco.helpers.B">
> <set-service property="c" service-id="mymodule.A" />
> </construct>
> </set-object>
> </construct>
> </invoke-factory>
>
> Maybe we should let object providers provide a schema of their own.
> Wouldn't that do the trick?
>
Wouldn't Howard's proposed top-level <bean> and the bean: object
provider solve this? I find that easier to grasp :-)
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: AOPAlliance Service Interceptors...
Posted by James Carman <ja...@carmanconsulting.com>.
Howard,
How about we change the name of BuilderFactoryLogic to
DependencyInjectionLogic? Then, when we reuse it, it's more obvious what
we're trying to do. Maybe we should make a DependencyInjector service?
Does that make sense?
James
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Sunday, February 06, 2005 9:39 AM
To: hivemind-dev@jakarta.apache.org; Knut Wannheden
Subject: Re: AOPAlliance Service Interceptors...
This has been something people would like ... leverage most of the
logic of BuilderFactory, but allow it to build simply POJOs. In fact,
I think people want a <bean> element at the same level of
<service-point>.
To my mind, a <bean> is like a <service-point> except:
- No choice on the "factory"
- No interceptors
- Equivalent to the "primitive" service-model (create on first
reference, cache forever)
Given the split between BuilderFactory and BuilderFactoryLogic, it
should be simple to re-use the BuilderFactory code for creating POJOs.
Q: Do we want beans to be able to register for events? Can't see why not.
Part of this would be to provide an ObjectProvider.
I would say the correct prefix would be "bean:". There's already a
"bean:" prrovided by the hivemind library (and based on the
BeanFactory service). Although it would break backwards
compatibility, I would like to re-appropriate the "bean:" prefix to
reference <bean> elements.
BTW ... I wish I had called "BuilderFactory" something else, say
"DependencyInjectionFactory" or some-such. The terminology, DI, came
a bit later.
On Sun, 6 Feb 2005 12:24:32 +0100, Knut Wannheden
<kn...@gmail.com> wrote:
> James,
>
> It is in fact not very difficult to implement a PojoBuilder as an
> object provider which can perform simple service injection. I'm saying
> "simple" service injection because the parameter to an object provider
> is just a String which IMO shouldn't be overly complicated only to
> carry more information. And note that this wouldn't even require any
> changes in HiveMind.
>
> I was thinking that a locator like "pojo:com.foo.Bar" would have the
> object provider construct an instance of com.foo.Bar (using the
> longest autowirable constructor) and then autowire all writable
> properties for whose type exactly one (visible) service has been
> registered. So in that respect the object provider would be quite
> limited as it would only be able to do what BuilderFactory does by
> default. Yet I think that would be good enough in most cases.
>
> With such an object provider in place I assume that many method
> interceptor factories could be defined with a single service. Would it
> make sense to add an object provider like this to HiveMind or would
> that be going down the wrong road?
>
> On the other side I think adding a "name" attribute to the
> <interceptor> sounds like a really good idea. Two <interceptor>s
> constructed by the same factory could after all be entirely different
> as the factory uses the nested elements inside <interceptor> to
> construct the interceptor. What do others think about this?
>
> --knut
>
> On Sat, 5 Feb 2005 16:00:06 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
> > Knut,
> >
> > I don't see any reason why we couldn't get it in for 1.1. I would agree
> > that having to have two services is a bit cumbersome. If we could, like
you
> > said, inject a MethodInterceptor object into the factory (we have to use
> > separate factories to wrap each type of MethodInterceptor because of the
> > ordering problem, which we may also want to solve sometime by maybe
adding a
> > "name" or "orderingName" attribute to the interceptor element), which in
> > turn can have other services injected into it, then we're golden. We've
> > talked about this before that there needs to be some sort of PojoBuilder
or
> > something that allows us to build arbitrary objects and inject services
into
> > them. These objects are not needed as services themselves. I would
> > consider these objects to be more along the lines of "infrastructure" or
> > "support" objects. But, as we can agree, it's too cumbersome to just
let
> > them be hidden services (one possible alternative), because you have to
> > define a service point and implementation. Then again, if we go down
that
> > road, we're looking more and more like Spring (which isn't necessarily a
bad
> > thing). I still think that all services that are exposed via the
registry
> > should have to be "well-formed" (i.e. have a service interface).
> >
> > James
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
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: AOPAlliance Service Interceptors...
Posted by Knut Wannheden <kn...@gmail.com>.
Howard,
On Sun, 6 Feb 2005 09:39:06 -0500, Howard Lewis Ship <hl...@gmail.com> wrote:
> This has been something people would like ... leverage most of the
> logic of BuilderFactory, but allow it to build simply POJOs. In fact,
> I think people want a <bean> element at the same level of
> <service-point>.
>
Something like a <bean> would be great! I think the dependency
injection logic should even be leveraged to the level where it can be
used programatically to autowire "anonymous" beans. This programatic
interface (maybe as simple as one or two methods) could be exposed by
the Module where it can be conveniently used by service and
interceptor factories.
> To my mind, a <bean> is like a <service-point> except:
> - No choice on the "factory"
> - No interceptors
> - Equivalent to the "primitive" service-model (create on first
> reference, cache forever)
>
Could a <bean> possibly serve as the implementation of a
<service-point> (provided it implements the service interface). Maybe
even as the implementation of multiple service points?
> Given the split between BuilderFactory and BuilderFactoryLogic, it
> should be simple to re-use the BuilderFactory code for creating POJOs.
>
Indeed. I think there are still a few pieces in the
BuilderFactoryLogic which are specific to the BuilderFactory, so maybe
we should split out a DependencyInjectionLogic class with methods for
constructor based and setter based injection.
> Q: Do we want beans to be able to register for events? Can't see why not.
>
Why not?
> Part of this would be to provide an ObjectProvider.
>
> I would say the correct prefix would be "bean:". There's already a
> "bean:" prrovided by the hivemind library (and based on the
> BeanFactory service). Although it would break backwards
> compatibility, I would like to re-appropriate the "bean:" prefix to
> reference <bean> elements.
>
> BTW ... I wish I had called "BuilderFactory" something else, say
> "DependencyInjectionFactory" or some-such. The terminology, DI, came
> a bit later.
>
We could make the BuilderFactory deprecated. HiveMind would then spit
out warnings at load time referring to the DependencyInjectionFactory.
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: AOPAlliance Service Interceptors...
Posted by Howard Lewis Ship <hl...@gmail.com>.
This has been something people would like ... leverage most of the
logic of BuilderFactory, but allow it to build simply POJOs. In fact,
I think people want a <bean> element at the same level of
<service-point>.
To my mind, a <bean> is like a <service-point> except:
- No choice on the "factory"
- No interceptors
- Equivalent to the "primitive" service-model (create on first
reference, cache forever)
Given the split between BuilderFactory and BuilderFactoryLogic, it
should be simple to re-use the BuilderFactory code for creating POJOs.
Q: Do we want beans to be able to register for events? Can't see why not.
Part of this would be to provide an ObjectProvider.
I would say the correct prefix would be "bean:". There's already a
"bean:" prrovided by the hivemind library (and based on the
BeanFactory service). Although it would break backwards
compatibility, I would like to re-appropriate the "bean:" prefix to
reference <bean> elements.
BTW ... I wish I had called "BuilderFactory" something else, say
"DependencyInjectionFactory" or some-such. The terminology, DI, came
a bit later.
On Sun, 6 Feb 2005 12:24:32 +0100, Knut Wannheden
<kn...@gmail.com> wrote:
> James,
>
> It is in fact not very difficult to implement a PojoBuilder as an
> object provider which can perform simple service injection. I'm saying
> "simple" service injection because the parameter to an object provider
> is just a String which IMO shouldn't be overly complicated only to
> carry more information. And note that this wouldn't even require any
> changes in HiveMind.
>
> I was thinking that a locator like "pojo:com.foo.Bar" would have the
> object provider construct an instance of com.foo.Bar (using the
> longest autowirable constructor) and then autowire all writable
> properties for whose type exactly one (visible) service has been
> registered. So in that respect the object provider would be quite
> limited as it would only be able to do what BuilderFactory does by
> default. Yet I think that would be good enough in most cases.
>
> With such an object provider in place I assume that many method
> interceptor factories could be defined with a single service. Would it
> make sense to add an object provider like this to HiveMind or would
> that be going down the wrong road?
>
> On the other side I think adding a "name" attribute to the
> <interceptor> sounds like a really good idea. Two <interceptor>s
> constructed by the same factory could after all be entirely different
> as the factory uses the nested elements inside <interceptor> to
> construct the interceptor. What do others think about this?
>
> --knut
>
> On Sat, 5 Feb 2005 16:00:06 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
> > Knut,
> >
> > I don't see any reason why we couldn't get it in for 1.1. I would agree
> > that having to have two services is a bit cumbersome. If we could, like you
> > said, inject a MethodInterceptor object into the factory (we have to use
> > separate factories to wrap each type of MethodInterceptor because of the
> > ordering problem, which we may also want to solve sometime by maybe adding a
> > "name" or "orderingName" attribute to the interceptor element), which in
> > turn can have other services injected into it, then we're golden. We've
> > talked about this before that there needs to be some sort of PojoBuilder or
> > something that allows us to build arbitrary objects and inject services into
> > them. These objects are not needed as services themselves. I would
> > consider these objects to be more along the lines of "infrastructure" or
> > "support" objects. But, as we can agree, it's too cumbersome to just let
> > them be hidden services (one possible alternative), because you have to
> > define a service point and implementation. Then again, if we go down that
> > road, we're looking more and more like Spring (which isn't necessarily a bad
> > thing). I still think that all services that are exposed via the registry
> > should have to be "well-formed" (i.e. have a service interface).
> >
> > James
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
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: AOPAlliance Service Interceptors...
Posted by James Carman <ja...@carmanconsulting.com>.
Knut,
Well, I think if we're going to do this (generic, dependency injection
capable object builder), we should do it the right way. As soon as we
implement an object provider with this limited capability and no
work-around, someone is going to ask for an improvement. Then, we're going
to end up trying to encode dependency information (like what service-id to
use when there are multiple services of the property type) into the "locator
string." What I would like to do would be something like this...
<invoke-factory service-id="hivemind.BuilderFactory">
<construct class="myco.services.impl.MyServiceImpl">
<set-object property="a">
<construct class="myco.helpers.A" />
</set-object>
<set-object property="b">
<construct class="myco.helpers.B">
<set-service property="c" service-id="mymodule.A" />
</construct>
</set-object>
</construct>
</invoke-factory>
Maybe we should let object providers provide a schema of their own.
Wouldn't that do the trick?
James
-----Original Message-----
From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
Sent: Sunday, February 06, 2005 6:25 AM
To: hivemind-dev@jakarta.apache.org
Subject: Re: AOPAlliance Service Interceptors...
James,
It is in fact not very difficult to implement a PojoBuilder as an
object provider which can perform simple service injection. I'm saying
"simple" service injection because the parameter to an object provider
is just a String which IMO shouldn't be overly complicated only to
carry more information. And note that this wouldn't even require any
changes in HiveMind.
I was thinking that a locator like "pojo:com.foo.Bar" would have the
object provider construct an instance of com.foo.Bar (using the
longest autowirable constructor) and then autowire all writable
properties for whose type exactly one (visible) service has been
registered. So in that respect the object provider would be quite
limited as it would only be able to do what BuilderFactory does by
default. Yet I think that would be good enough in most cases.
With such an object provider in place I assume that many method
interceptor factories could be defined with a single service. Would it
make sense to add an object provider like this to HiveMind or would
that be going down the wrong road?
On the other side I think adding a "name" attribute to the
<interceptor> sounds like a really good idea. Two <interceptor>s
constructed by the same factory could after all be entirely different
as the factory uses the nested elements inside <interceptor> to
construct the interceptor. What do others think about this?
--knut
On Sat, 5 Feb 2005 16:00:06 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Knut,
>
> I don't see any reason why we couldn't get it in for 1.1. I would agree
> that having to have two services is a bit cumbersome. If we could, like
you
> said, inject a MethodInterceptor object into the factory (we have to use
> separate factories to wrap each type of MethodInterceptor because of the
> ordering problem, which we may also want to solve sometime by maybe adding
a
> "name" or "orderingName" attribute to the interceptor element), which in
> turn can have other services injected into it, then we're golden. We've
> talked about this before that there needs to be some sort of PojoBuilder
or
> something that allows us to build arbitrary objects and inject services
into
> them. These objects are not needed as services themselves. I would
> consider these objects to be more along the lines of "infrastructure" or
> "support" objects. But, as we can agree, it's too cumbersome to just let
> them be hidden services (one possible alternative), because you have to
> define a service point and implementation. Then again, if we go down that
> road, we're looking more and more like Spring (which isn't necessarily a
bad
> thing). I still think that all services that are exposed via the registry
> should have to be "well-formed" (i.e. have a service interface).
>
> James
>
---------------------------------------------------------------------
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: AOPAlliance Service Interceptors...
Posted by Knut Wannheden <kn...@gmail.com>.
James,
It is in fact not very difficult to implement a PojoBuilder as an
object provider which can perform simple service injection. I'm saying
"simple" service injection because the parameter to an object provider
is just a String which IMO shouldn't be overly complicated only to
carry more information. And note that this wouldn't even require any
changes in HiveMind.
I was thinking that a locator like "pojo:com.foo.Bar" would have the
object provider construct an instance of com.foo.Bar (using the
longest autowirable constructor) and then autowire all writable
properties for whose type exactly one (visible) service has been
registered. So in that respect the object provider would be quite
limited as it would only be able to do what BuilderFactory does by
default. Yet I think that would be good enough in most cases.
With such an object provider in place I assume that many method
interceptor factories could be defined with a single service. Would it
make sense to add an object provider like this to HiveMind or would
that be going down the wrong road?
On the other side I think adding a "name" attribute to the
<interceptor> sounds like a really good idea. Two <interceptor>s
constructed by the same factory could after all be entirely different
as the factory uses the nested elements inside <interceptor> to
construct the interceptor. What do others think about this?
--knut
On Sat, 5 Feb 2005 16:00:06 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Knut,
>
> I don't see any reason why we couldn't get it in for 1.1. I would agree
> that having to have two services is a bit cumbersome. If we could, like you
> said, inject a MethodInterceptor object into the factory (we have to use
> separate factories to wrap each type of MethodInterceptor because of the
> ordering problem, which we may also want to solve sometime by maybe adding a
> "name" or "orderingName" attribute to the interceptor element), which in
> turn can have other services injected into it, then we're golden. We've
> talked about this before that there needs to be some sort of PojoBuilder or
> something that allows us to build arbitrary objects and inject services into
> them. These objects are not needed as services themselves. I would
> consider these objects to be more along the lines of "infrastructure" or
> "support" objects. But, as we can agree, it's too cumbersome to just let
> them be hidden services (one possible alternative), because you have to
> define a service point and implementation. Then again, if we go down that
> road, we're looking more and more like Spring (which isn't necessarily a bad
> thing). I still think that all services that are exposed via the registry
> should have to be "well-formed" (i.e. have a service interface).
>
> James
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: AOPAlliance Service Interceptors...
Posted by James Carman <ja...@carmanconsulting.com>.
Knut,
I don't see any reason why we couldn't get it in for 1.1. I would agree
that having to have two services is a bit cumbersome. If we could, like you
said, inject a MethodInterceptor object into the factory (we have to use
separate factories to wrap each type of MethodInterceptor because of the
ordering problem, which we may also want to solve sometime by maybe adding a
"name" or "orderingName" attribute to the interceptor element), which in
turn can have other services injected into it, then we're golden. We've
talked about this before that there needs to be some sort of PojoBuilder or
something that allows us to build arbitrary objects and inject services into
them. These objects are not needed as services themselves. I would
consider these objects to be more along the lines of "infrastructure" or
"support" objects. But, as we can agree, it's too cumbersome to just let
them be hidden services (one possible alternative), because you have to
define a service point and implementation. Then again, if we go down that
road, we're looking more and more like Spring (which isn't necessarily a bad
thing). I still think that all services that are exposed via the registry
should have to be "well-formed" (i.e. have a service interface).
James
-----Original Message-----
From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
Sent: Saturday, February 05, 2005 11:53 AM
To: hivemind-dev@jakarta.apache.org
Subject: Re: AOPAlliance Service Interceptors...
James,
Wouldn't it be possible to get it in for the next 1.1 alpha or beta
release? The implementation you have provided
(http://issues.apache.org/jira/browse/HIVEMIND-45) is somewhat
cumbersome to use as two services have to be provided for non trivial
cases, but I think it's a good start. Converting it to Javassist (if
at all necessary) should not be too difficult either.
Slightly off topic (although I think this would make the method
interceptor factory easier to use): What I think would be cool would
be a new object provider similar to instance: but which in addition
also would perform dependency injection. Possibly the instance:
provider could even be extended in such a way to make that an option.
(And maybe even <create-instance>.)
--knut
On Sat, 5 Feb 2005 07:34:36 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
>
>
>
> Hello, All. Since the AOPAlliance Service Interceptors support didn't
make
> it into 1.1, when can we expect that to become available? I would like to
> discuss service interceptors in my article, but there is NO WAY that I'm
> going to try to explain how to do it using Javassist. I would like to use
> the AOPAlliance stuff.
>
>
>
> James
---------------------------------------------------------------------
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: AOPAlliance Service Interceptors...
Posted by Knut Wannheden <kn...@gmail.com>.
James,
Wouldn't it be possible to get it in for the next 1.1 alpha or beta
release? The implementation you have provided
(http://issues.apache.org/jira/browse/HIVEMIND-45) is somewhat
cumbersome to use as two services have to be provided for non trivial
cases, but I think it's a good start. Converting it to Javassist (if
at all necessary) should not be too difficult either.
Slightly off topic (although I think this would make the method
interceptor factory easier to use): What I think would be cool would
be a new object provider similar to instance: but which in addition
also would perform dependency injection. Possibly the instance:
provider could even be extended in such a way to make that an option.
(And maybe even <create-instance>.)
--knut
On Sat, 5 Feb 2005 07:34:36 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
>
>
>
> Hello, All. Since the AOPAlliance Service Interceptors support didn't make
> it into 1.1, when can we expect that to become available? I would like to
> discuss service interceptors in my article, but there is NO WAY that I'm
> going to try to explain how to do it using Javassist. I would like to use
> the AOPAlliance stuff.
>
>
>
> James
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: AOPAlliance Service Interceptors...
Posted by Knut Wannheden <kn...@gmail.com>.
James,
(I think you must have by accident sent your last message to me only
and not the mailing list.)
On Sun, 27 Feb 2005 19:28:46 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Any thoughts on the new method for RegistryBuilder? Also, what is the
> process here? Do I have to get approval for every little thing I do in the
> codebase? Are we supposed to vote on simple little changes such as adding
> the addDefaultModuleDescriptorProvider() method? As I said before, I am new
> to this committer thing, so I'm a little gunshy to start committing changes
> in. But, I don't see this particular method as causing too many problems,
> since most scenarios where you would want to add in custom module
> descriptors, you also want the default ones too. It's really just a
> refactoring, but I am making the extracted/moved method public.
>
I'm +1 on this one. Although I think it was a good start, to me
something still doesn't feel quite right with these
ModuleDescriptorProviders...
IMO small changes like this one can be committed without prior
discussions on the mailing list. We do after all have CVS so the
change is still easily undone if someone feels unhappy about it.
> Anyway, thanks for the tips here on the documentation. I had already found
> a couple of them, but I will address the rest before I check anything in.
> Also, do you think it's worth changing the name of the
> getPrecedingInterceptorIds() and getFollowingInterceptorIds() methods in the
> ServiceInterceptorContribution interface, since they're not really ids
> anymore, but names? I was updating the javadoc of that class when I ran
> across it.
>
Yes, IMO that sounds good.
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: AOPAlliance Service Interceptors...
Posted by Knut Wannheden <kn...@gmail.com>.
James,
Looks good to me. I guess it's now only really some documentation aspects ;-)
- The new framework and library classes and methods added don't have
an "@since 1.1" Javadoc tag.
- The changes to the <interceptor> element should be documented in
descriptor.xml and services.xml. (At some point we should probably
factor out a separate page documenting interceptors.)
- A brief documentation page for the MethodInterceptorFactory would
also be great.
(To verify the documentation changes you should run the Ant "site"
target once and for subsequent checks it should be enough to run the
"fast-site" target. I think you will also have to install Forrest
first.)
--knut
On Sun, 27 Feb 2005 11:48:02 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Here's the patch that implements HIVEMIND-96 and HIVEMIND-45. Let me know
> what you guys think and I'll go ahead and commit them (separately with
> appropriate comments of course).
>
> -----Original Message-----
> From: James Carman [mailto:james@carmanconsulting.com]
> Sent: Sunday, February 27, 2005 11:04 AM
> To: hivemind-dev@jakarta.apache.org; 'Knut Wannheden'
> Subject: RE: AOPAlliance Service Interceptors...
>
> I went to the project level and did a Team -> Update. Then, I go to the
> project level and I do a Team -> Create Patch, but it only recognizes my new
> classes. This is getting on my nerves, because I have both of these issues
> resolved with test cases and I would like to check it into the 1.1 codebase
> for you folks to check out.
>
> -----Original Message-----
> From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
> Sent: Sunday, February 27, 2005 11:01 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: AOPAlliance Service Interceptors...
>
> Sounds strange... Only tips I have:
>
> - Try resynchronizing the entire project
> - Create the patch on the Project level
>
> Sorry if this doesn't help, but I can't think of anything else...
>
> --knut
>
> On Sun, 27 Feb 2005 10:47:11 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
> > Well, I've got it implemented with test cases, but I can't get Eclipse to
> > generate a patch for me! It sees my new classes, but fails to include the
> > changes I have made to existing classes/interfaces. HELP!
> >
> > -----Original Message-----
> > From: Howard Lewis Ship [mailto:hlship@gmail.com]
> > Sent: Sunday, February 27, 2005 10:47 AM
> > To: hivemind-dev@jakarta.apache.org
> > Subject: Re: AOPAlliance Service Interceptors...
> >
> > This works for me. Having the name default to the service id is a
> > perfectly fine idea.
> >
> > On Sun, 27 Feb 2005 08:35:50 -0500, James Carman
> > <ja...@carmanconsulting.com> wrote:
> > >
> > >
> > >
> > > Has anyone else come up with a way to do this cleanly? I think one big
> > step
> > > in the right direction would be support for overriding the interceptor's
> > > name, replacing the factory's id with something else. This way, we
> could
> > > define ONE service interceptor factory which inserts a MethodInterceptor
> > > defined elsewhere in the registry (or inline maybe) and the interceptors
> > > could still be ordered, since they could have unique names. We could
> > leave
> > > it backward compatible, of course, defaulting the interceptor name to
> the
> > > service id of the interceptor factory.
> > >
> > >
> > >
> > > <interceptor service-id="hivemind.lib.MethodInterceptorFactory"
> > > name="security">
> > >
> > > <impl object="service:mymodule.SecurityInterceptor" />
> > >
> > > </interceptor>
> > >
> > >
> > >
> > > <interceptor service-id="hivemind.lib.MethodInterceptorFactory"
> > > name="logging" before="security">
> > >
> > > <impl
> > object="instance:com.myco.myproject.interceptor.LoggingInterceptor"
> > > />
> > >
> > > </interceptor>
> > >
> > >
> > >
> > > Here, we have defined a service interceptor using another service and
> one
> > > using just a plain ole object. What do you guys think?
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: James Carman [mailto:james@carmanconsulting.com]
> > > Sent: Saturday, February 05, 2005 7:35 AM
> > > To: hivemind-dev@jakarta.apache.org
> > > Subject: AOPAlliance Service Interceptors...
> > >
> > >
> > >
> > >
> > > -->
> > >
> > >
> > > Hello, All. Since the AOPAlliance Service Interceptors support didn't
> > make
> > > it into 1.1, when can we expect that to become available? I would like
> to
> > > discuss service interceptors in my article, but there is NO WAY that I'm
> > > going to try to explain how to do it using Javassist. I would like to
> use
> > > the AOPAlliance stuff.
> > >
> > >
> > >
> > > James
> >
> > --
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>
> ---------------------------------------------------------------------
> 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: AOPAlliance Service Interceptors...
Posted by James Carman <ja...@carmanconsulting.com>.
Here's the patch that implements HIVEMIND-96 and HIVEMIND-45. Let me know
what you guys think and I'll go ahead and commit them (separately with
appropriate comments of course).
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Sunday, February 27, 2005 11:04 AM
To: hivemind-dev@jakarta.apache.org; 'Knut Wannheden'
Subject: RE: AOPAlliance Service Interceptors...
I went to the project level and did a Team -> Update. Then, I go to the
project level and I do a Team -> Create Patch, but it only recognizes my new
classes. This is getting on my nerves, because I have both of these issues
resolved with test cases and I would like to check it into the 1.1 codebase
for you folks to check out.
-----Original Message-----
From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
Sent: Sunday, February 27, 2005 11:01 AM
To: hivemind-dev@jakarta.apache.org
Subject: Re: AOPAlliance Service Interceptors...
Sounds strange... Only tips I have:
- Try resynchronizing the entire project
- Create the patch on the Project level
Sorry if this doesn't help, but I can't think of anything else...
--knut
On Sun, 27 Feb 2005 10:47:11 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Well, I've got it implemented with test cases, but I can't get Eclipse to
> generate a patch for me! It sees my new classes, but fails to include the
> changes I have made to existing classes/interfaces. HELP!
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Sunday, February 27, 2005 10:47 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: AOPAlliance Service Interceptors...
>
> This works for me. Having the name default to the service id is a
> perfectly fine idea.
>
> On Sun, 27 Feb 2005 08:35:50 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
> >
> >
> >
> > Has anyone else come up with a way to do this cleanly? I think one big
> step
> > in the right direction would be support for overriding the interceptor's
> > name, replacing the factory's id with something else. This way, we
could
> > define ONE service interceptor factory which inserts a MethodInterceptor
> > defined elsewhere in the registry (or inline maybe) and the interceptors
> > could still be ordered, since they could have unique names. We could
> leave
> > it backward compatible, of course, defaulting the interceptor name to
the
> > service id of the interceptor factory.
> >
> >
> >
> > <interceptor service-id="hivemind.lib.MethodInterceptorFactory"
> > name="security">
> >
> > <impl object="service:mymodule.SecurityInterceptor" />
> >
> > </interceptor>
> >
> >
> >
> > <interceptor service-id="hivemind.lib.MethodInterceptorFactory"
> > name="logging" before="security">
> >
> > <impl
> object="instance:com.myco.myproject.interceptor.LoggingInterceptor"
> > />
> >
> > </interceptor>
> >
> >
> >
> > Here, we have defined a service interceptor using another service and
one
> > using just a plain ole object. What do you guys think?
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: James Carman [mailto:james@carmanconsulting.com]
> > Sent: Saturday, February 05, 2005 7:35 AM
> > To: hivemind-dev@jakarta.apache.org
> > Subject: AOPAlliance Service Interceptors...
> >
> >
> >
> >
> > -->
> >
> >
> > Hello, All. Since the AOPAlliance Service Interceptors support didn't
> make
> > it into 1.1, when can we expect that to become available? I would like
to
> > discuss service interceptors in my article, but there is NO WAY that I'm
> > going to try to explain how to do it using Javassist. I would like to
use
> > the AOPAlliance stuff.
> >
> >
> >
> > James
>
> --
> 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
>
>
---------------------------------------------------------------------
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: AOPAlliance Service Interceptors...
Posted by James Carman <ja...@carmanconsulting.com>.
I went to the project level and did a Team -> Update. Then, I go to the
project level and I do a Team -> Create Patch, but it only recognizes my new
classes. This is getting on my nerves, because I have both of these issues
resolved with test cases and I would like to check it into the 1.1 codebase
for you folks to check out.
-----Original Message-----
From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
Sent: Sunday, February 27, 2005 11:01 AM
To: hivemind-dev@jakarta.apache.org
Subject: Re: AOPAlliance Service Interceptors...
Sounds strange... Only tips I have:
- Try resynchronizing the entire project
- Create the patch on the Project level
Sorry if this doesn't help, but I can't think of anything else...
--knut
On Sun, 27 Feb 2005 10:47:11 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Well, I've got it implemented with test cases, but I can't get Eclipse to
> generate a patch for me! It sees my new classes, but fails to include the
> changes I have made to existing classes/interfaces. HELP!
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Sunday, February 27, 2005 10:47 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: AOPAlliance Service Interceptors...
>
> This works for me. Having the name default to the service id is a
> perfectly fine idea.
>
> On Sun, 27 Feb 2005 08:35:50 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
> >
> >
> >
> > Has anyone else come up with a way to do this cleanly? I think one big
> step
> > in the right direction would be support for overriding the interceptor's
> > name, replacing the factory's id with something else. This way, we
could
> > define ONE service interceptor factory which inserts a MethodInterceptor
> > defined elsewhere in the registry (or inline maybe) and the interceptors
> > could still be ordered, since they could have unique names. We could
> leave
> > it backward compatible, of course, defaulting the interceptor name to
the
> > service id of the interceptor factory.
> >
> >
> >
> > <interceptor service-id="hivemind.lib.MethodInterceptorFactory"
> > name="security">
> >
> > <impl object="service:mymodule.SecurityInterceptor" />
> >
> > </interceptor>
> >
> >
> >
> > <interceptor service-id="hivemind.lib.MethodInterceptorFactory"
> > name="logging" before="security">
> >
> > <impl
> object="instance:com.myco.myproject.interceptor.LoggingInterceptor"
> > />
> >
> > </interceptor>
> >
> >
> >
> > Here, we have defined a service interceptor using another service and
one
> > using just a plain ole object. What do you guys think?
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: James Carman [mailto:james@carmanconsulting.com]
> > Sent: Saturday, February 05, 2005 7:35 AM
> > To: hivemind-dev@jakarta.apache.org
> > Subject: AOPAlliance Service Interceptors...
> >
> >
> >
> >
> > -->
> >
> >
> > Hello, All. Since the AOPAlliance Service Interceptors support didn't
> make
> > it into 1.1, when can we expect that to become available? I would like
to
> > discuss service interceptors in my article, but there is NO WAY that I'm
> > going to try to explain how to do it using Javassist. I would like to
use
> > the AOPAlliance stuff.
> >
> >
> >
> > James
>
> --
> 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
>
>
---------------------------------------------------------------------
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: AOPAlliance Service Interceptors...
Posted by Knut Wannheden <kn...@gmail.com>.
Sounds strange... Only tips I have:
- Try resynchronizing the entire project
- Create the patch on the Project level
Sorry if this doesn't help, but I can't think of anything else...
--knut
On Sun, 27 Feb 2005 10:47:11 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Well, I've got it implemented with test cases, but I can't get Eclipse to
> generate a patch for me! It sees my new classes, but fails to include the
> changes I have made to existing classes/interfaces. HELP!
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Sunday, February 27, 2005 10:47 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: AOPAlliance Service Interceptors...
>
> This works for me. Having the name default to the service id is a
> perfectly fine idea.
>
> On Sun, 27 Feb 2005 08:35:50 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
> >
> >
> >
> > Has anyone else come up with a way to do this cleanly? I think one big
> step
> > in the right direction would be support for overriding the interceptor's
> > name, replacing the factory's id with something else. This way, we could
> > define ONE service interceptor factory which inserts a MethodInterceptor
> > defined elsewhere in the registry (or inline maybe) and the interceptors
> > could still be ordered, since they could have unique names. We could
> leave
> > it backward compatible, of course, defaulting the interceptor name to the
> > service id of the interceptor factory.
> >
> >
> >
> > <interceptor service-id="hivemind.lib.MethodInterceptorFactory"
> > name="security">
> >
> > <impl object="service:mymodule.SecurityInterceptor" />
> >
> > </interceptor>
> >
> >
> >
> > <interceptor service-id="hivemind.lib.MethodInterceptorFactory"
> > name="logging" before="security">
> >
> > <impl
> object="instance:com.myco.myproject.interceptor.LoggingInterceptor"
> > />
> >
> > </interceptor>
> >
> >
> >
> > Here, we have defined a service interceptor using another service and one
> > using just a plain ole object. What do you guys think?
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: James Carman [mailto:james@carmanconsulting.com]
> > Sent: Saturday, February 05, 2005 7:35 AM
> > To: hivemind-dev@jakarta.apache.org
> > Subject: AOPAlliance Service Interceptors...
> >
> >
> >
> >
> > -->
> >
> >
> > Hello, All. Since the AOPAlliance Service Interceptors support didn't
> make
> > it into 1.1, when can we expect that to become available? I would like to
> > discuss service interceptors in my article, but there is NO WAY that I'm
> > going to try to explain how to do it using Javassist. I would like to use
> > the AOPAlliance stuff.
> >
> >
> >
> > James
>
> --
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: AOPAlliance Service Interceptors...
Posted by James Carman <ja...@carmanconsulting.com>.
Well, I've got it implemented with test cases, but I can't get Eclipse to
generate a patch for me! It sees my new classes, but fails to include the
changes I have made to existing classes/interfaces. HELP!
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Sunday, February 27, 2005 10:47 AM
To: hivemind-dev@jakarta.apache.org
Subject: Re: AOPAlliance Service Interceptors...
This works for me. Having the name default to the service id is a
perfectly fine idea.
On Sun, 27 Feb 2005 08:35:50 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
>
>
>
> Has anyone else come up with a way to do this cleanly? I think one big
step
> in the right direction would be support for overriding the interceptor's
> name, replacing the factory's id with something else. This way, we could
> define ONE service interceptor factory which inserts a MethodInterceptor
> defined elsewhere in the registry (or inline maybe) and the interceptors
> could still be ordered, since they could have unique names. We could
leave
> it backward compatible, of course, defaulting the interceptor name to the
> service id of the interceptor factory.
>
>
>
> <interceptor service-id="hivemind.lib.MethodInterceptorFactory"
> name="security">
>
> <impl object="service:mymodule.SecurityInterceptor" />
>
> </interceptor>
>
>
>
> <interceptor service-id="hivemind.lib.MethodInterceptorFactory"
> name="logging" before="security">
>
> <impl
object="instance:com.myco.myproject.interceptor.LoggingInterceptor"
> />
>
> </interceptor>
>
>
>
> Here, we have defined a service interceptor using another service and one
> using just a plain ole object. What do you guys think?
>
>
>
>
>
> -----Original Message-----
> From: James Carman [mailto:james@carmanconsulting.com]
> Sent: Saturday, February 05, 2005 7:35 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: AOPAlliance Service Interceptors...
>
>
>
>
> -->
>
>
> Hello, All. Since the AOPAlliance Service Interceptors support didn't
make
> it into 1.1, when can we expect that to become available? I would like to
> discuss service interceptors in my article, but there is NO WAY that I'm
> going to try to explain how to do it using Javassist. I would like to use
> the AOPAlliance stuff.
>
>
>
> James
--
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: AOPAlliance Service Interceptors...
Posted by Howard Lewis Ship <hl...@gmail.com>.
This works for me. Having the name default to the service id is a
perfectly fine idea.
On Sun, 27 Feb 2005 08:35:50 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
>
>
>
> Has anyone else come up with a way to do this cleanly? I think one big step
> in the right direction would be support for overriding the interceptor's
> name, replacing the factory's id with something else. This way, we could
> define ONE service interceptor factory which inserts a MethodInterceptor
> defined elsewhere in the registry (or inline maybe) and the interceptors
> could still be ordered, since they could have unique names. We could leave
> it backward compatible, of course, defaulting the interceptor name to the
> service id of the interceptor factory.
>
>
>
> <interceptor service-id="hivemind.lib.MethodInterceptorFactory"
> name="security">
>
> <impl object="service:mymodule.SecurityInterceptor" />
>
> </interceptor>
>
>
>
> <interceptor service-id="hivemind.lib.MethodInterceptorFactory"
> name="logging" before="security">
>
> <impl object="instance:com.myco.myproject.interceptor.LoggingInterceptor"
> />
>
> </interceptor>
>
>
>
> Here, we have defined a service interceptor using another service and one
> using just a plain ole object. What do you guys think?
>
>
>
>
>
> -----Original Message-----
> From: James Carman [mailto:james@carmanconsulting.com]
> Sent: Saturday, February 05, 2005 7:35 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: AOPAlliance Service Interceptors...
>
>
>
>
> -->
>
>
> Hello, All. Since the AOPAlliance Service Interceptors support didn't make
> it into 1.1, when can we expect that to become available? I would like to
> discuss service interceptors in my article, but there is NO WAY that I'm
> going to try to explain how to do it using Javassist. I would like to use
> the AOPAlliance stuff.
>
>
>
> James
--
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: AOPAlliance Service Interceptors...
Posted by Knut Wannheden <kn...@gmail.com>.
On Sun, 27 Feb 2005 08:35:50 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
>
>
>
> Has anyone else come up with a way to do this cleanly? I think one big step
> in the right direction would be support for overriding the interceptor's
> name, replacing the factory's id with something else. This way, we could
> define ONE service interceptor factory which inserts a MethodInterceptor
> defined elsewhere in the registry (or inline maybe) and the interceptors
> could still be ordered, since they could have unique names. We could leave
> it backward compatible, of course, defaulting the interceptor name to the
> service id of the interceptor factory.
>
+1.
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: AOPAlliance Service Interceptors...
Posted by Knut Wannheden <kn...@gmail.com>.
The ordering logic should already be sufficiently tested by the
TestOrderer test. I suppose you'll only have to test that the name
attribute properly overrides the service-id attribute.
--knut
On Sun, 27 Feb 2005 09:18:37 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Just found that! Thanks. It took a bit of digging, but I found it. Also,
> does anyone know of a test case that tests the ordering logic for
> interceptors? I need to put in a specific test case for when the name is
> overridden.
>
> -----Original Message-----
> From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
> Sent: Sunday, February 27, 2005 9:15 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: AOPAlliance Service Interceptors...
>
> James,
>
> On Sun, 27 Feb 2005 08:53:01 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
> >
> >
> > I am already implementing it by adding a "name" attribute to
> > ServiceInterceptorContribution (and its impl class and the code that
> builds
> > it)...
> >
>
> I'm not sure if you've found out already (as it's not all that
> obvious), but to extend the syntax you have to edit
> DescriptorParser.properties.
>
> --knut
>
> ---------------------------------------------------------------------
> 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: AOPAlliance Service Interceptors...
Posted by James Carman <ja...@carmanconsulting.com>.
Never mind, I added the tests to TestServicePoint to test the actual
ordering of the interceptors.
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Sunday, February 27, 2005 9:19 AM
To: hivemind-dev@jakarta.apache.org; 'Knut Wannheden'
Subject: RE: AOPAlliance Service Interceptors...
Just found that! Thanks. It took a bit of digging, but I found it. Also,
does anyone know of a test case that tests the ordering logic for
interceptors? I need to put in a specific test case for when the name is
overridden.
-----Original Message-----
From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
Sent: Sunday, February 27, 2005 9:15 AM
To: hivemind-dev@jakarta.apache.org
Subject: Re: AOPAlliance Service Interceptors...
James,
On Sun, 27 Feb 2005 08:53:01 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
>
>
> I am already implementing it by adding a "name" attribute to
> ServiceInterceptorContribution (and its impl class and the code that
builds
> it)...
>
I'm not sure if you've found out already (as it's not all that
obvious), but to extend the syntax you have to edit
DescriptorParser.properties.
--knut
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: AOPAlliance Service Interceptors...
Posted by James Carman <ja...@carmanconsulting.com>.
Just found that! Thanks. It took a bit of digging, but I found it. Also,
does anyone know of a test case that tests the ordering logic for
interceptors? I need to put in a specific test case for when the name is
overridden.
-----Original Message-----
From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
Sent: Sunday, February 27, 2005 9:15 AM
To: hivemind-dev@jakarta.apache.org
Subject: Re: AOPAlliance Service Interceptors...
James,
On Sun, 27 Feb 2005 08:53:01 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
>
>
> I am already implementing it by adding a "name" attribute to
> ServiceInterceptorContribution (and its impl class and the code that
builds
> it)...
>
I'm not sure if you've found out already (as it's not all that
obvious), but to extend the syntax you have to edit
DescriptorParser.properties.
--knut
---------------------------------------------------------------------
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: AOPAlliance Service Interceptors...
Posted by Knut Wannheden <kn...@gmail.com>.
James,
On Sun, 27 Feb 2005 08:53:01 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
>
>
> I am already implementing it by adding a "name" attribute to
> ServiceInterceptorContribution (and its impl class and the code that builds
> it)...
>
I'm not sure if you've found out already (as it's not all that
obvious), but to extend the syntax you have to edit
DescriptorParser.properties.
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: AOPAlliance Service Interceptors...
Posted by James Carman <ja...@carmanconsulting.com>.
+1
I am already implementing it by adding a "name" attribute to
ServiceInterceptorContribution (and its impl class and the code that builds
it)...
public String getName()
{
if( _name == null )
{
return getFactoryServiceId();
}
return _name;
}
Then, in ServicePointImpl, I changed.
orderer.add(sic, sic.getFactoryServiceId(),
sic.getPrecedingInterceptorIds(), sic
.getFollowingInterceptorIds());
to.
orderer.add(sic, sic.getName(), sic.getPrecedingInterceptorIds(), sic
.getFollowingInterceptorIds());
So far, it hasn't broken any test cases, and I'm adding in new ones to test
the functionality. I will send you guys a patch first before I commit,
since I'm new to this whole thing and I'm scared that I'll screw something
up!
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Sunday, February 27, 2005 8:36 AM
To: hivemind-dev@jakarta.apache.org
Subject: RE: AOPAlliance Service Interceptors...
-->
Has anyone else come up with a way to do this cleanly? I think one big step
in the right direction would be support for overriding the interceptor's
name, replacing the factory's id with something else. This way, we could
define ONE service interceptor factory which inserts a MethodInterceptor
defined elsewhere in the registry (or inline maybe) and the interceptors
could still be ordered, since they could have unique names. We could leave
it backward compatible, of course, defaulting the interceptor name to the
service id of the interceptor factory.
<interceptor service-id="hivemind.lib.MethodInterceptorFactory"
name="security">
<impl object="service:mymodule.SecurityInterceptor" />
</interceptor>
<interceptor service-id="hivemind.lib.MethodInterceptorFactory"
name="logging" before="security">
<impl object="instance:com.myco.myproject.interceptor.LoggingInterceptor"
/>
</interceptor>
Here, we have defined a service interceptor using another service and one
using just a plain ole object. What do you guys think?
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Saturday, February 05, 2005 7:35 AM
To: hivemind-dev@jakarta.apache.org
Subject: AOPAlliance Service Interceptors...
-->
Hello, All. Since the AOPAlliance Service Interceptors support didn't make
it into 1.1, when can we expect that to become available? I would like to
discuss service interceptors in my article, but there is NO WAY that I'm
going to try to explain how to do it using Javassist. I would like to use
the AOPAlliance stuff.
James
RE: AOPAlliance Service Interceptors...
Posted by James Carman <ja...@carmanconsulting.com>.
Has anyone else come up with a way to do this cleanly? I think one big step
in the right direction would be support for overriding the interceptor's
name, replacing the factory's id with something else. This way, we could
define ONE service interceptor factory which inserts a MethodInterceptor
defined elsewhere in the registry (or inline maybe) and the interceptors
could still be ordered, since they could have unique names. We could leave
it backward compatible, of course, defaulting the interceptor name to the
service id of the interceptor factory.
<interceptor service-id="hivemind.lib.MethodInterceptorFactory"
name="security">
<impl object="service:mymodule.SecurityInterceptor" />
</interceptor>
<interceptor service-id="hivemind.lib.MethodInterceptorFactory"
name="logging" before="security">
<impl object="instance:com.myco.myproject.interceptor.LoggingInterceptor"
/>
</interceptor>
Here, we have defined a service interceptor using another service and one
using just a plain ole object. What do you guys think?
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Saturday, February 05, 2005 7:35 AM
To: hivemind-dev@jakarta.apache.org
Subject: AOPAlliance Service Interceptors...
-->
Hello, All. Since the AOPAlliance Service Interceptors support didn't make
it into 1.1, when can we expect that to become available? I would like to
discuss service interceptors in my article, but there is NO WAY that I'm
going to try to explain how to do it using Javassist. I would like to use
the AOPAlliance stuff.
James