You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by Knut Wannheden <kn...@gmail.com> on 2004/10/26 17:45:21 UTC
Re: Simple Bean injection
How about some kind of "ServiceWirer" service in HiveMind? Users
could have it injected into their services, where they would be able
to use it programatically to wire up any POJO with the matching
HiveMind services. Of course this service could also be injected into
BuilderFactory for the autowiring taking place there.
--knut
On Tue, 26 Oct 2004 07:51:43 -0400, Howard Lewis Ship <hl...@gmail.com> wrote:
> This is a feature, some call it "resources", that has been requested
> ... a way to use BuilderFactory logic to construct ordinary beans.
>
>
>
>
> On Mon, 25 Oct 2004 08:33:56 -0500, Jason Vasquez <ja...@mugfu.com> wrote:
> > Hi all -- I'm new to Hivemind, and I have a feeling I'm missing
> > something here....
> >
> > I'd like to create an Object factory which serves up simple
> > POJO beans. But, it would be nice to take advantage of the
> > auto-wiring that takes place with the other services I have
> > defined, as long as wiring in other services into the newly
> > created POJOs. (maybe even applying interceptors?) At this
> > point, I can simply do the wiring myself within the factory,
> > but I want to make sure I'm not missing out on something good :)
> >
> > Anyway, I'm unclear as to how this can be accomplished. Is
> > this something that has been covered?
> >
> > Thanks,
> > Jason
> >
> > --
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
> http://howardlewisship.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-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: Simple Bean injection
Posted by James Carman <ja...@carmanconsulting.com>.
How about calling it "DependencyInjector"?
-----Original Message-----
From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
Sent: Tuesday, October 26, 2004 11:45 AM
To: hivemind-dev@jakarta.apache.org; Howard Lewis Ship
Subject: Re: Simple Bean injection
How about some kind of "ServiceWirer" service in HiveMind? Users
could have it injected into their services, where they would be able
to use it programatically to wire up any POJO with the matching
HiveMind services. Of course this service could also be injected into
BuilderFactory for the autowiring taking place there.
--knut
On Tue, 26 Oct 2004 07:51:43 -0400, Howard Lewis Ship <hl...@gmail.com>
wrote:
> This is a feature, some call it "resources", that has been requested
> ... a way to use BuilderFactory logic to construct ordinary beans.
>
>
>
>
> On Mon, 25 Oct 2004 08:33:56 -0500, Jason Vasquez <ja...@mugfu.com> wrote:
> > Hi all -- I'm new to Hivemind, and I have a feeling I'm missing
> > something here....
> >
> > I'd like to create an Object factory which serves up simple
> > POJO beans. But, it would be nice to take advantage of the
> > auto-wiring that takes place with the other services I have
> > defined, as long as wiring in other services into the newly
> > created POJOs. (maybe even applying interceptors?) At this
> > point, I can simply do the wiring myself within the factory,
> > but I want to make sure I'm not missing out on something good :)
> >
> > Anyway, I'm unclear as to how this can be accomplished. Is
> > this something that has been covered?
> >
> > Thanks,
> > Jason
> >
> > --
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
> http://howardlewisship.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-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: Simple Bean injection
Posted by Knut Wannheden <kn...@gmail.com>.
A slightly different approach...
As HiveMind is agnostic about the type of dependency injection used it
would make sense to colocate the code dealing with both constructor
based and setter based dependency injection. Thus, if this were a
service, it should really be an implementation factory service. I'll
refer to it as the "ServiceFactory".
This would be the core implementation factory service with support for
dependency injection. Think of it as a stripped down BuilderFactory.
Maybe we could have the <create-instance> element represent this
service (as a shorthand) in the module descriptors. This would of
course imply that <create-instance> would now also have support for
autowiring.
The beauty of this would be that every service implementation would be
constructed by an implementation factory. What about the
ServiceFactory itself then? That would be left as a detail of the
registry bootstrap. Which ClassLoader object in a JVM loaded the
bootstrap classloader class? I think it's left up as a detail of the
JVM implementation.
Further the ServiceFactory could be configurable or maybe even be
replaced by the user. The BuilderFactory and BeanFactory could
delegate part of their job to the ServiceFactory. The reference to it
could be injected, but I think it would be cleaner to obtain it by
querying the Module object.
--knut
On Wed, 27 Oct 2004 17:45:03 +0200, Knut Wannheden
<kn...@gmail.com> wrote:
> So there is a catch (22). Didn't think about that! And it's a very
> good reason not to provide a ServiceInjector service. The logic could
> still be encapsulated in a class and be reused as such. Even as a
> convenience method as Marcus suggests.
>
>
>
> --knut
>
> On Wed, 27 Oct 2004 11:14:44 -0400, Howard Lewis Ship <hl...@gmail.com> wrote:
> > Don't forget the bootstrap issues; the BuilderFactory can't construct
> > itself! So it may have a captive instance of ServiceInjectorImpl that
> > would be different from the one accessed (via the normal paths) by
> > other services.
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Simple Bean injection
Posted by Knut Wannheden <kn...@gmail.com>.
So there is a catch (22). Didn't think about that! And it's a very
good reason not to provide a ServiceInjector service. The logic could
still be encapsulated in a class and be reused as such. Even as a
convenience method as Marcus suggests.
--knut
On Wed, 27 Oct 2004 11:14:44 -0400, Howard Lewis Ship <hl...@gmail.com> wrote:
> Don't forget the bootstrap issues; the BuilderFactory can't construct
> itself! So it may have a captive instance of ServiceInjectorImpl that
> would be different from the one accessed (via the normal paths) by
> other services.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Simple Bean injection
Posted by Knut Wannheden <kn...@gmail.com>.
I wasn't saying that the Registry or Module should be injected into
the user CSIs. I agree with you that it wouldn't be a good idea. It
is currently not even possible, is it? Implementation factories (as
e.g. BuilderFactory and your proposed service I dubbed as BeanFactory)
do at construction time have access to the invoking Module object
(provided by HiveMind) and could thus pass this as a parameter to the
ServiceInjector. I.e.
public interface ServiceInjector
{
public void injectServices(Object target, Module invokingModule);
}
I don't think the ServiceInjector would be useful other than to
implemenation factory services.
What I'm wondering about is if it makes sense to wrap up the
dependency injection logic inside a service (which will only be used
by implementation factories) or if that is overkill? IOW: Is there a
reason a user would like to write an implementation factory with
autowiring capabilities instead of using BuilderFactory or
BeanFactory. IMO that would justify a ServiceInjector service.
We could of course also solve the problem by adding a configuration
point which all services would be contributed to... Not being serious
here :-)
--knut
On Wed, 27 Oct 2004 09:22:48 -0400, Howard Lewis Ship <hl...@gmail.com> wrote:
> I'm not very keen on injecting the Module instance into a CSI. I
> consider the Module to be part of the internals of HiveMind and want
> to hide it as much as possible from end-user code.
>
> I strongly object to injecting or otherwise exposing the Registry;
> anything you'd need from the Registry is available from the Module,
> and will do visibility checks properly from the Module.
>
> On Wed, 27 Oct 2004 15:03:38 +0200, Knut Wannheden
> <kn...@gmail.com> wrote:
> > I haven't thought to hard about it either, but I think you're right:
> > it would need a reference to the Registry or any Module object. Since
> > I don't think it's currently possible to inject either of these into
> > the core implementation it would have to be a method parameter.
> > Shouldn't be a problem for factory services which do have access to
> > the invoking Module object.
> >
> > Note that we already have a class named DependencyDescriptor in
> > HiveMind. And wouldn't it almost be easier for the client to perform
> > the dependency injection itself than using this 2nd method? E.g.
> >
> > PropertyUtils.write(dependentObject, propertyName,
> > Registry.getService(dependencyId);
> >
> > instead of:
> >
> > serviceInjector.injectDependencies(registry, dependentObject, new
> > DependencyDescriptor[] { new DependencyDescriptorImpl(dependencyType,
> > propertyName, dependencyId) });
> >
> > But instead of an array of DependencyDescriptors the client could
> > maybe pass a set of objects, which the service could select from for
> > the injection.
> >
> > --knut
> >
> > On Wed, 27 Oct 2004 08:36:42 -0400, James Carman
> >
> >
> > <ja...@carmanconsulting.com> wrote:
> > > Do you think it would be overkill to also provide a method which performs
> > > specified injection? Something like this...
> > >
> > > public void injectDependencies( Registry registry, Object dependentObject );
> > > public void injectDependencies( Registry registry, Object dependentObject,
> > > DependencyDescriptor[] dependencies );
> > >
> > > A DependencyDescriptor would look like...
> > >
> > > public class DependencyDescriptor
> > > {
> > > public Class getDependencyType();
> > > public String getPropertyName();
> > > public String getDependencyId();
> > > }
> > >
> > > Basically, this is for when you have multiple service points with the same
> > > service interface. I added the Registry parameter because I don't know
> > > whether or not this should be a service. Maybe it could just be a helper
> > > method somewhere (or added to Registry itself). Wouldn't we run into a
> > > chicken and egg situation if we wanted to make this a service? I mean, what
> > > builds the service implementation for this service? BuilderFactory? But,
> > > what does BuilderFactory use to wire together the implementation object?
> > > Even if we make it a primitive service (which I don't think is built by
> > > BuilderFactory), what injects its dependencies? I may be wrong here, as I
> > > haven't really thought through it completely (need more coffee), but
> > > something just doesn't smell right to me (maybe I need a shower too).
> > >
> > >
> >
> > ---------------------------------------------------------------------
>
>
> > 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
> 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: Simple Bean injection
Posted by Howard Lewis Ship <hl...@gmail.com>.
I'm not very keen on injecting the Module instance into a CSI. I
consider the Module to be part of the internals of HiveMind and want
to hide it as much as possible from end-user code.
I strongly object to injecting or otherwise exposing the Registry;
anything you'd need from the Registry is available from the Module,
and will do visibility checks properly from the Module.
On Wed, 27 Oct 2004 15:03:38 +0200, Knut Wannheden
<kn...@gmail.com> wrote:
> I haven't thought to hard about it either, but I think you're right:
> it would need a reference to the Registry or any Module object. Since
> I don't think it's currently possible to inject either of these into
> the core implementation it would have to be a method parameter.
> Shouldn't be a problem for factory services which do have access to
> the invoking Module object.
>
> Note that we already have a class named DependencyDescriptor in
> HiveMind. And wouldn't it almost be easier for the client to perform
> the dependency injection itself than using this 2nd method? E.g.
>
> PropertyUtils.write(dependentObject, propertyName,
> Registry.getService(dependencyId);
>
> instead of:
>
> serviceInjector.injectDependencies(registry, dependentObject, new
> DependencyDescriptor[] { new DependencyDescriptorImpl(dependencyType,
> propertyName, dependencyId) });
>
> But instead of an array of DependencyDescriptors the client could
> maybe pass a set of objects, which the service could select from for
> the injection.
>
> --knut
>
> On Wed, 27 Oct 2004 08:36:42 -0400, James Carman
>
>
> <ja...@carmanconsulting.com> wrote:
> > Do you think it would be overkill to also provide a method which performs
> > specified injection? Something like this...
> >
> > public void injectDependencies( Registry registry, Object dependentObject );
> > public void injectDependencies( Registry registry, Object dependentObject,
> > DependencyDescriptor[] dependencies );
> >
> > A DependencyDescriptor would look like...
> >
> > public class DependencyDescriptor
> > {
> > public Class getDependencyType();
> > public String getPropertyName();
> > public String getDependencyId();
> > }
> >
> > Basically, this is for when you have multiple service points with the same
> > service interface. I added the Registry parameter because I don't know
> > whether or not this should be a service. Maybe it could just be a helper
> > method somewhere (or added to Registry itself). Wouldn't we run into a
> > chicken and egg situation if we wanted to make this a service? I mean, what
> > builds the service implementation for this service? BuilderFactory? But,
> > what does BuilderFactory use to wire together the implementation object?
> > Even if we make it a primitive service (which I don't think is built by
> > BuilderFactory), what injects its dependencies? I may be wrong here, as I
> > haven't really thought through it completely (need more coffee), but
> > something just doesn't smell right to me (maybe I need a shower too).
> >
> >
>
> ---------------------------------------------------------------------
> 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
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: Simple Bean injection
Posted by Knut Wannheden <kn...@gmail.com>.
I haven't thought to hard about it either, but I think you're right:
it would need a reference to the Registry or any Module object. Since
I don't think it's currently possible to inject either of these into
the core implementation it would have to be a method parameter.
Shouldn't be a problem for factory services which do have access to
the invoking Module object.
Note that we already have a class named DependencyDescriptor in
HiveMind. And wouldn't it almost be easier for the client to perform
the dependency injection itself than using this 2nd method? E.g.
PropertyUtils.write(dependentObject, propertyName,
Registry.getService(dependencyId);
instead of:
serviceInjector.injectDependencies(registry, dependentObject, new
DependencyDescriptor[] { new DependencyDescriptorImpl(dependencyType,
propertyName, dependencyId) });
But instead of an array of DependencyDescriptors the client could
maybe pass a set of objects, which the service could select from for
the injection.
--knut
On Wed, 27 Oct 2004 08:36:42 -0400, James Carman
<ja...@carmanconsulting.com> wrote:
> Do you think it would be overkill to also provide a method which performs
> specified injection? Something like this...
>
> public void injectDependencies( Registry registry, Object dependentObject );
> public void injectDependencies( Registry registry, Object dependentObject,
> DependencyDescriptor[] dependencies );
>
> A DependencyDescriptor would look like...
>
> public class DependencyDescriptor
> {
> public Class getDependencyType();
> public String getPropertyName();
> public String getDependencyId();
> }
>
> Basically, this is for when you have multiple service points with the same
> service interface. I added the Registry parameter because I don't know
> whether or not this should be a service. Maybe it could just be a helper
> method somewhere (or added to Registry itself). Wouldn't we run into a
> chicken and egg situation if we wanted to make this a service? I mean, what
> builds the service implementation for this service? BuilderFactory? But,
> what does BuilderFactory use to wire together the implementation object?
> Even if we make it a primitive service (which I don't think is built by
> BuilderFactory), what injects its dependencies? I may be wrong here, as I
> haven't really thought through it completely (need more coffee), but
> something just doesn't smell right to me (maybe I need a shower too).
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: Simple Bean injection
Posted by James Carman <ja...@carmanconsulting.com>.
Do you think it would be overkill to also provide a method which performs
specified injection? Something like this...
public void injectDependencies( Registry registry, Object dependentObject );
public void injectDependencies( Registry registry, Object dependentObject,
DependencyDescriptor[] dependencies );
A DependencyDescriptor would look like...
public class DependencyDescriptor
{
public Class getDependencyType();
public String getPropertyName();
public String getDependencyId();
}
Basically, this is for when you have multiple service points with the same
service interface. I added the Registry parameter because I don't know
whether or not this should be a service. Maybe it could just be a helper
method somewhere (or added to Registry itself). Wouldn't we run into a
chicken and egg situation if we wanted to make this a service? I mean, what
builds the service implementation for this service? BuilderFactory? But,
what does BuilderFactory use to wire together the implementation object?
Even if we make it a primitive service (which I don't think is built by
BuilderFactory), what injects its dependencies? I may be wrong here, as I
haven't really thought through it completely (need more coffee), but
something just doesn't smell right to me (maybe I need a shower too).
-----Original Message-----
From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
Sent: Wednesday, October 27, 2004 8:23 AM
To: hivemind-dev@jakarta.apache.org; Howard Lewis Ship
Subject: Re: Simple Bean injection
Then IIUYC the service you're talking about (let's call it
BeanFactory) would be a factory service implementing
ServiceImplementationFactory. Thus, by the user only used inside
module descriptors. This would certainly be useful.
The service I was trying to describe (let's call it ServiceInjector)
would be yet another service responsible for the actual dependency
injection. It could be injected into BuilderFactory and BeanFactory,
which would use it to implement the autowiring.
In addition to that users could have ServiceInjector injected into
their own service implementations, where they'd be able to use it to
autowire any objects being constructed. Would that make sense?
--knut
On Wed, 27 Oct 2004 07:57:48 -0400, Howard Lewis Ship <hl...@gmail.com>
wrote:
> I think we could have a service and configuration. The configuration
> contributions look much like the <construct> parameter to
> BuilderFactory. The service simply allows access to beans specified
> inside.
>
> Because there aren't proxies for beans, we'll have to be extra careful
> to detect dependency cycles between beans.
>
> In addition, we could define a ObjectProvider for prefix bean:
> (perhaps that will be the only way to access such beans?)
>
---------------------------------------------------------------------
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: Simple Bean injection
Posted by Knut Wannheden <kn...@gmail.com>.
Then IIUYC the service you're talking about (let's call it
BeanFactory) would be a factory service implementing
ServiceImplementationFactory. Thus, by the user only used inside
module descriptors. This would certainly be useful.
The service I was trying to describe (let's call it ServiceInjector)
would be yet another service responsible for the actual dependency
injection. It could be injected into BuilderFactory and BeanFactory,
which would use it to implement the autowiring.
In addition to that users could have ServiceInjector injected into
their own service implementations, where they'd be able to use it to
autowire any objects being constructed. Would that make sense?
--knut
On Wed, 27 Oct 2004 07:57:48 -0400, Howard Lewis Ship <hl...@gmail.com> wrote:
> I think we could have a service and configuration. The configuration
> contributions look much like the <construct> parameter to
> BuilderFactory. The service simply allows access to beans specified
> inside.
>
> Because there aren't proxies for beans, we'll have to be extra careful
> to detect dependency cycles between beans.
>
> In addition, we could define a ObjectProvider for prefix bean:
> (perhaps that will be the only way to access such beans?)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: Simple Bean injection
Posted by James Carman <ja...@carmanconsulting.com>.
I don't think it really muddles the principles at all. If you have a
service implementation declared in your module which requires a DataSource
and you declare a service point in your module which implements DataSource,
I would think that you would want your service implementation to be wired to
that one. And you wouldn't want your module to break when another module
comes along, which declares another service point implementing DataSource.
If anything, this strategy will save you some typing in your module
descriptor. I don't think it breaks anything, really. Worst case, you
could still do exactly what you said, and use the <set-service> for the
problematic dependencies. But, you wouldn't have to if you really did want
to use the one from your module (I can't see it happening any other way,
realistically).
-----Original Message-----
From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
Sent: Wednesday, October 27, 2004 5:39 PM
To: HiveMind Dev List
Subject: Re: Simple Bean injection
Yes, it does cause the problem you describe. From the documentation on
BuilderFactory:
"Autowiring may be complicated by the fact that one module may
define a service point that will tangentially affect the construction
of a service in another module (simply by implementing the same
service interface). In this situation, service autowiring can be
turned off, by setting the autowire-services attribute to false."
In my experience the cases where this problem could arise are known in
beforehand. E.g. a DataSource. In those cases autowiring can be
disabled. Or I think you should also be able to "prophylactically"
protect your services against clashes of this kind by leaving
autowiring enabled *and* using explicit <set-service> elements for the
problematic services. The autowiring should ignore those.
That said I still think your approach sounds reasonable. It would be
a different dependency injection strategy. (This would IMO again
favor providing a configurable ServiceInjector :-) But somehow I
still get the feeling that this approach would muddle the principles
behind HiveMind.
--knut
On Wed, 27 Oct 2004 16:55:12 -0400, James Carman
<ja...@carmanconsulting.com> wrote:
> But, doesn't that potentially cause a problem? What if another module
> declares a service point with the same service interface unbeknownst to
you
> and that module is added to the registry at runtime? Without that other
> module, my module will work. With that other module, my module will not.
> It would be better if it attempted to autowire WITHIN my module first,
> thereby taking care of my dependency. Then, when it tries to autowire
> within the rest of the registry, it would see that my dependency is
already
> injected and bypass it. Does that sound reasonable?
>
>
>
> -----Original Message-----
> From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
> Sent: Wednesday, October 27, 2004 4:48 PM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: Simple Bean injection
>
> BuilderFactory autowires all the setters of the implementation it
> finds a service with the matching interface for; irrespective of what
> module contributes that service. If there's more than one or no
> matching service then none is wired and an error is reported.
>
> --knut
>
> On Wed, 27 Oct 2004 16:01:03 -0400, James Carman
> <ja...@carmanconsulting.com> wrote:
> > Does it attempt to autowire first within the declaring module?
> >
> >
> >
> > -----Original Message-----
> > From: Howard Lewis Ship [mailto:hlship@gmail.com]
> > Sent: Wednesday, October 27, 2004 3:36 PM
> > To: hivemind-dev@jakarta.apache.org
> > Subject: Re: Simple Bean injection
> >
> > To be clear, the visibility doesn't limit auto-wiring to just services
> > in a given module. From within a module, it allows wiring to visible
> > services in any module.
> >
> > The methods on Registry will only "see" public services (in any module).
> >
> > On Wed, 27 Oct 2004 12:23:38 -0400, James Carman
> > <ja...@carmanconsulting.com> wrote:
> > > I believe I forgot to account for the "scoping" of the autowiring.
> > Somehow
> > > we need to be able to tell the injector that we only want it to
autowire
> > > services from within a specific module. I believe that's how the
> default
> > > autowiring works now. Is this to avoid the situation where another
> module
> > > declares the same service interface as a different service point,
> thereby
> > > breaking your module's autowiring?
> > >
>
> ---------------------------------------------------------------------
> 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: Simple Bean injection
Posted by Knut Wannheden <kn...@gmail.com>.
Yes, it does cause the problem you describe. From the documentation on
BuilderFactory:
"Autowiring may be complicated by the fact that one module may
define a service point that will tangentially affect the construction
of a service in another module (simply by implementing the same
service interface). In this situation, service autowiring can be
turned off, by setting the autowire-services attribute to false."
In my experience the cases where this problem could arise are known in
beforehand. E.g. a DataSource. In those cases autowiring can be
disabled. Or I think you should also be able to "prophylactically"
protect your services against clashes of this kind by leaving
autowiring enabled *and* using explicit <set-service> elements for the
problematic services. The autowiring should ignore those.
That said I still think your approach sounds reasonable. It would be
a different dependency injection strategy. (This would IMO again
favor providing a configurable ServiceInjector :-) But somehow I
still get the feeling that this approach would muddle the principles
behind HiveMind.
--knut
On Wed, 27 Oct 2004 16:55:12 -0400, James Carman
<ja...@carmanconsulting.com> wrote:
> But, doesn't that potentially cause a problem? What if another module
> declares a service point with the same service interface unbeknownst to you
> and that module is added to the registry at runtime? Without that other
> module, my module will work. With that other module, my module will not.
> It would be better if it attempted to autowire WITHIN my module first,
> thereby taking care of my dependency. Then, when it tries to autowire
> within the rest of the registry, it would see that my dependency is already
> injected and bypass it. Does that sound reasonable?
>
>
>
> -----Original Message-----
> From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
> Sent: Wednesday, October 27, 2004 4:48 PM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: Simple Bean injection
>
> BuilderFactory autowires all the setters of the implementation it
> finds a service with the matching interface for; irrespective of what
> module contributes that service. If there's more than one or no
> matching service then none is wired and an error is reported.
>
> --knut
>
> On Wed, 27 Oct 2004 16:01:03 -0400, James Carman
> <ja...@carmanconsulting.com> wrote:
> > Does it attempt to autowire first within the declaring module?
> >
> >
> >
> > -----Original Message-----
> > From: Howard Lewis Ship [mailto:hlship@gmail.com]
> > Sent: Wednesday, October 27, 2004 3:36 PM
> > To: hivemind-dev@jakarta.apache.org
> > Subject: Re: Simple Bean injection
> >
> > To be clear, the visibility doesn't limit auto-wiring to just services
> > in a given module. From within a module, it allows wiring to visible
> > services in any module.
> >
> > The methods on Registry will only "see" public services (in any module).
> >
> > On Wed, 27 Oct 2004 12:23:38 -0400, James Carman
> > <ja...@carmanconsulting.com> wrote:
> > > I believe I forgot to account for the "scoping" of the autowiring.
> > Somehow
> > > we need to be able to tell the injector that we only want it to autowire
> > > services from within a specific module. I believe that's how the
> default
> > > autowiring works now. Is this to avoid the situation where another
> module
> > > declares the same service interface as a different service point,
> thereby
> > > breaking your module's autowiring?
> > >
>
> ---------------------------------------------------------------------
> 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: Simple Bean injection
Posted by James Carman <ja...@carmanconsulting.com>.
But, doesn't that potentially cause a problem? What if another module
declares a service point with the same service interface unbeknownst to you
and that module is added to the registry at runtime? Without that other
module, my module will work. With that other module, my module will not.
It would be better if it attempted to autowire WITHIN my module first,
thereby taking care of my dependency. Then, when it tries to autowire
within the rest of the registry, it would see that my dependency is already
injected and bypass it. Does that sound reasonable?
-----Original Message-----
From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
Sent: Wednesday, October 27, 2004 4:48 PM
To: hivemind-dev@jakarta.apache.org
Subject: Re: Simple Bean injection
BuilderFactory autowires all the setters of the implementation it
finds a service with the matching interface for; irrespective of what
module contributes that service. If there's more than one or no
matching service then none is wired and an error is reported.
--knut
On Wed, 27 Oct 2004 16:01:03 -0400, James Carman
<ja...@carmanconsulting.com> wrote:
> Does it attempt to autowire first within the declaring module?
>
>
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Wednesday, October 27, 2004 3:36 PM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: Simple Bean injection
>
> To be clear, the visibility doesn't limit auto-wiring to just services
> in a given module. From within a module, it allows wiring to visible
> services in any module.
>
> The methods on Registry will only "see" public services (in any module).
>
> On Wed, 27 Oct 2004 12:23:38 -0400, James Carman
> <ja...@carmanconsulting.com> wrote:
> > I believe I forgot to account for the "scoping" of the autowiring.
> Somehow
> > we need to be able to tell the injector that we only want it to autowire
> > services from within a specific module. I believe that's how the
default
> > autowiring works now. Is this to avoid the situation where another
module
> > declares the same service interface as a different service point,
thereby
> > breaking your module's autowiring?
> >
---------------------------------------------------------------------
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: Simple Bean injection
Posted by Knut Wannheden <kn...@gmail.com>.
BuilderFactory autowires all the setters of the implementation it
finds a service with the matching interface for; irrespective of what
module contributes that service. If there's more than one or no
matching service then none is wired and an error is reported.
--knut
On Wed, 27 Oct 2004 16:01:03 -0400, James Carman
<ja...@carmanconsulting.com> wrote:
> Does it attempt to autowire first within the declaring module?
>
>
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Wednesday, October 27, 2004 3:36 PM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: Simple Bean injection
>
> To be clear, the visibility doesn't limit auto-wiring to just services
> in a given module. From within a module, it allows wiring to visible
> services in any module.
>
> The methods on Registry will only "see" public services (in any module).
>
> On Wed, 27 Oct 2004 12:23:38 -0400, James Carman
> <ja...@carmanconsulting.com> wrote:
> > I believe I forgot to account for the "scoping" of the autowiring.
> Somehow
> > we need to be able to tell the injector that we only want it to autowire
> > services from within a specific module. I believe that's how the default
> > autowiring works now. Is this to avoid the situation where another module
> > declares the same service interface as a different service point, thereby
> > breaking your module's autowiring?
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: Simple Bean injection
Posted by James Carman <ja...@carmanconsulting.com>.
Does it attempt to autowire first within the declaring module?
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Wednesday, October 27, 2004 3:36 PM
To: hivemind-dev@jakarta.apache.org
Subject: Re: Simple Bean injection
To be clear, the visibility doesn't limit auto-wiring to just services
in a given module. From within a module, it allows wiring to visible
services in any module.
The methods on Registry will only "see" public services (in any module).
On Wed, 27 Oct 2004 12:23:38 -0400, James Carman
<ja...@carmanconsulting.com> wrote:
> I believe I forgot to account for the "scoping" of the autowiring.
Somehow
> we need to be able to tell the injector that we only want it to autowire
> services from within a specific module. I believe that's how the default
> autowiring works now. Is this to avoid the situation where another module
> declares the same service interface as a different service point, thereby
> breaking your module's autowiring?
>
> -----Original Message-----
> From: Marcus Brito [mailto:mbrito@gmail.com]
> Sent: Wednesday, October 27, 2004 11:12 AM
> To: hivemind-dev@jakarta.apache.org; Howard Lewis Ship
> Subject: Re: Simple Bean injection
>
> The scenario here are legacy "services": suppose that for some
> unfathomable reason you can't build/expose a service in the hivemind
> registry, but you'd love to satisfy this service's dependencies from a
> hivemind registry. So, we need something like this:
>
> CrapService myCrap = new CrapService();
> Registry registry = <... get the registry from some context, attribute,
etc>
> registry.injectDependencies(myCrap);
>
> This would try to "autowire" the myCrap object with services available
> in the registry. Another option would be to specify which dependencies
> we need, as James wisely pointed out:
>
> ...
> Collection crapDependencies = new ArrayList();
> crapDependencies.add(new DependencyDescriptor(WiseService.class,
> "wiseService", "wiseServiceId");
> crapDependencies.add(new DependencyDescriptor(BillService.class,
> "killer", "blackMamba");
> registry.inejectDependencies(myCrap, crapDependencies.toArray(new
> DependencyDescriptor[crapDependencies.size()]);
>
> This would inject th "wiseServiceId" service by calling
> myCrap.setWiseService(), and the "blackMamba" service by calling
> myCrap.setKiller().
>
> I know I just repeated what everyone said above ;) I just thought that
> Howard didn't get it, and now I tried to explain more througly what we
> want, the motivation and some fictious code. I hope this helps to
> makes things clearer.
>
> -- Marcus Brito <mb...@gmail.com>
>
> On Wed, 27 Oct 2004 07:57:48 -0400, Howard Lewis Ship <hl...@gmail.com>
> wrote:
> > I think we could have a service and configuration. The configuration
> > contributions look much like the <construct> parameter to
> > BuilderFactory. The service simply allows access to beans specified
> > inside.
> >
> > Because there aren't proxies for beans, we'll have to be extra careful
> > to detect dependency cycles between beans.
> >
> > In addition, we could define a ObjectProvider for prefix bean:
> > (perhaps that will be the only way to access such beans?)
>
> ---------------------------------------------------------------------
> 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
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: Simple Bean injection
Posted by Howard Lewis Ship <hl...@gmail.com>.
To be clear, the visibility doesn't limit auto-wiring to just services
in a given module. From within a module, it allows wiring to visible
services in any module.
The methods on Registry will only "see" public services (in any module).
On Wed, 27 Oct 2004 12:23:38 -0400, James Carman
<ja...@carmanconsulting.com> wrote:
> I believe I forgot to account for the "scoping" of the autowiring. Somehow
> we need to be able to tell the injector that we only want it to autowire
> services from within a specific module. I believe that's how the default
> autowiring works now. Is this to avoid the situation where another module
> declares the same service interface as a different service point, thereby
> breaking your module's autowiring?
>
> -----Original Message-----
> From: Marcus Brito [mailto:mbrito@gmail.com]
> Sent: Wednesday, October 27, 2004 11:12 AM
> To: hivemind-dev@jakarta.apache.org; Howard Lewis Ship
> Subject: Re: Simple Bean injection
>
> The scenario here are legacy "services": suppose that for some
> unfathomable reason you can't build/expose a service in the hivemind
> registry, but you'd love to satisfy this service's dependencies from a
> hivemind registry. So, we need something like this:
>
> CrapService myCrap = new CrapService();
> Registry registry = <... get the registry from some context, attribute, etc>
> registry.injectDependencies(myCrap);
>
> This would try to "autowire" the myCrap object with services available
> in the registry. Another option would be to specify which dependencies
> we need, as James wisely pointed out:
>
> ...
> Collection crapDependencies = new ArrayList();
> crapDependencies.add(new DependencyDescriptor(WiseService.class,
> "wiseService", "wiseServiceId");
> crapDependencies.add(new DependencyDescriptor(BillService.class,
> "killer", "blackMamba");
> registry.inejectDependencies(myCrap, crapDependencies.toArray(new
> DependencyDescriptor[crapDependencies.size()]);
>
> This would inject th "wiseServiceId" service by calling
> myCrap.setWiseService(), and the "blackMamba" service by calling
> myCrap.setKiller().
>
> I know I just repeated what everyone said above ;) I just thought that
> Howard didn't get it, and now I tried to explain more througly what we
> want, the motivation and some fictious code. I hope this helps to
> makes things clearer.
>
> -- Marcus Brito <mb...@gmail.com>
>
> On Wed, 27 Oct 2004 07:57:48 -0400, Howard Lewis Ship <hl...@gmail.com>
> wrote:
> > I think we could have a service and configuration. The configuration
> > contributions look much like the <construct> parameter to
> > BuilderFactory. The service simply allows access to beans specified
> > inside.
> >
> > Because there aren't proxies for beans, we'll have to be extra careful
> > to detect dependency cycles between beans.
> >
> > In addition, we could define a ObjectProvider for prefix bean:
> > (perhaps that will be the only way to access such beans?)
>
> ---------------------------------------------------------------------
> 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
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: Simple Bean injection
Posted by James Carman <ja...@carmanconsulting.com>.
I believe I forgot to account for the "scoping" of the autowiring. Somehow
we need to be able to tell the injector that we only want it to autowire
services from within a specific module. I believe that's how the default
autowiring works now. Is this to avoid the situation where another module
declares the same service interface as a different service point, thereby
breaking your module's autowiring?
-----Original Message-----
From: Marcus Brito [mailto:mbrito@gmail.com]
Sent: Wednesday, October 27, 2004 11:12 AM
To: hivemind-dev@jakarta.apache.org; Howard Lewis Ship
Subject: Re: Simple Bean injection
The scenario here are legacy "services": suppose that for some
unfathomable reason you can't build/expose a service in the hivemind
registry, but you'd love to satisfy this service's dependencies from a
hivemind registry. So, we need something like this:
CrapService myCrap = new CrapService();
Registry registry = <... get the registry from some context, attribute, etc>
registry.injectDependencies(myCrap);
This would try to "autowire" the myCrap object with services available
in the registry. Another option would be to specify which dependencies
we need, as James wisely pointed out:
...
Collection crapDependencies = new ArrayList();
crapDependencies.add(new DependencyDescriptor(WiseService.class,
"wiseService", "wiseServiceId");
crapDependencies.add(new DependencyDescriptor(BillService.class,
"killer", "blackMamba");
registry.inejectDependencies(myCrap, crapDependencies.toArray(new
DependencyDescriptor[crapDependencies.size()]);
This would inject th "wiseServiceId" service by calling
myCrap.setWiseService(), and the "blackMamba" service by calling
myCrap.setKiller().
I know I just repeated what everyone said above ;) I just thought that
Howard didn't get it, and now I tried to explain more througly what we
want, the motivation and some fictious code. I hope this helps to
makes things clearer.
-- Marcus Brito <mb...@gmail.com>
On Wed, 27 Oct 2004 07:57:48 -0400, Howard Lewis Ship <hl...@gmail.com>
wrote:
> I think we could have a service and configuration. The configuration
> contributions look much like the <construct> parameter to
> BuilderFactory. The service simply allows access to beans specified
> inside.
>
> Because there aren't proxies for beans, we'll have to be extra careful
> to detect dependency cycles between beans.
>
> In addition, we could define a ObjectProvider for prefix bean:
> (perhaps that will be the only way to access such beans?)
---------------------------------------------------------------------
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: Simple Bean injection
Posted by Marcus Brito <mb...@gmail.com>.
The scenario here are legacy "services": suppose that for some
unfathomable reason you can't build/expose a service in the hivemind
registry, but you'd love to satisfy this service's dependencies from a
hivemind registry. So, we need something like this:
CrapService myCrap = new CrapService();
Registry registry = <... get the registry from some context, attribute, etc>
registry.injectDependencies(myCrap);
This would try to "autowire" the myCrap object with services available
in the registry. Another option would be to specify which dependencies
we need, as James wisely pointed out:
...
Collection crapDependencies = new ArrayList();
crapDependencies.add(new DependencyDescriptor(WiseService.class,
"wiseService", "wiseServiceId");
crapDependencies.add(new DependencyDescriptor(BillService.class,
"killer", "blackMamba");
registry.inejectDependencies(myCrap, crapDependencies.toArray(new
DependencyDescriptor[crapDependencies.size()]);
This would inject th "wiseServiceId" service by calling
myCrap.setWiseService(), and the "blackMamba" service by calling
myCrap.setKiller().
I know I just repeated what everyone said above ;) I just thought that
Howard didn't get it, and now I tried to explain more througly what we
want, the motivation and some fictious code. I hope this helps to
makes things clearer.
-- Marcus Brito <mb...@gmail.com>
On Wed, 27 Oct 2004 07:57:48 -0400, Howard Lewis Ship <hl...@gmail.com> wrote:
> I think we could have a service and configuration. The configuration
> contributions look much like the <construct> parameter to
> BuilderFactory. The service simply allows access to beans specified
> inside.
>
> Because there aren't proxies for beans, we'll have to be extra careful
> to detect dependency cycles between beans.
>
> In addition, we could define a ObjectProvider for prefix bean:
> (perhaps that will be the only way to access such beans?)
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Simple Bean injection
Posted by Howard Lewis Ship <hl...@gmail.com>.
I think we could have a service and configuration. The configuration
contributions look much like the <construct> parameter to
BuilderFactory. The service simply allows access to beans specified
inside.
Because there aren't proxies for beans, we'll have to be extra careful
to detect dependency cycles between beans.
In addition, we could define a ObjectProvider for prefix bean:
(perhaps that will be the only way to access such beans?)
On Tue, 26 Oct 2004 18:11:54 +0200, Knut Wannheden
<kn...@gmail.com> wrote:
> On Tue, 26 Oct 2004 11:53:50 -0400, Howard Lewis Ship <hl...@gmail.com> wrote:
> > I was actually thiking about re-using the BuilderFactory's
> > BuilderFactoryLogic and generalzing it a bit so that it can handle
> > non-services. In this scenario, BuilderFactory would be the
> > specialized case, and POJOBuilder would be the more general case.
> >
>
> I think I see what you mean. Would this POJOBuilder be a service?
> And what objects would it be able to wire up a POJO against? Just
> loaded HiveMind services or objects from any given set?
>
> I think a service which can be used to programatically wire up a POJO
> (against HiveMind services) would be quite useful.
>
> I see this being useful in factory services (not "service factory
> services" implementing ServiceImplementationFactory, but rather more
> general POJO factories). The factory service could then wire up the
> POJOs it creates with services loaded in the HiveMind registry. E.g.
>
> _pojoBuilder.injectServices(createdPojo);
>
> > Might also be a good chance to revist how we do constructor injection,
> > since the current implementation is a bit stupid and weak.
> >
>
> +1
>
> --knut
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
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: Simple Bean injection
Posted by Knut Wannheden <kn...@gmail.com>.
On Tue, 26 Oct 2004 11:53:50 -0400, Howard Lewis Ship <hl...@gmail.com> wrote:
> I was actually thiking about re-using the BuilderFactory's
> BuilderFactoryLogic and generalzing it a bit so that it can handle
> non-services. In this scenario, BuilderFactory would be the
> specialized case, and POJOBuilder would be the more general case.
>
I think I see what you mean. Would this POJOBuilder be a service?
And what objects would it be able to wire up a POJO against? Just
loaded HiveMind services or objects from any given set?
I think a service which can be used to programatically wire up a POJO
(against HiveMind services) would be quite useful.
I see this being useful in factory services (not "service factory
services" implementing ServiceImplementationFactory, but rather more
general POJO factories). The factory service could then wire up the
POJOs it creates with services loaded in the HiveMind registry. E.g.
_pojoBuilder.injectServices(createdPojo);
> Might also be a good chance to revist how we do constructor injection,
> since the current implementation is a bit stupid and weak.
>
+1
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org