The property dependencies will be satisfied iff they exists.
But if they do not exist, they will not prevent the object from being created.
You can change that behavior by:
Creating a new IContributeComponentModelConstruction that behaves exactly like PropertiesDependenciesModelInspector except that is set the dependencies to non optional.
(Pass false in line 86 and 90, instead of true).
Then you need to extend DefaultComponentModelBuilder and override InitializeContributors()
It sould look like this:
protected abstractvoid InitializeContributors()
{
#if DOTNET2
AddContributor(new GenericInspector());
#endif
AddContributor(new ConfigurationModelInspector());
AddContributor(new LifestyleModelInspector());
AddContributor(new ConstructorDependenciesModelInspector());
AddContributor(new MandatoryPropertiesDependenciesModelInspector());
AddContributor(new LifecycleModelInspector());
AddContributor(new ConfigurationParametersInspector());
AddContributor(new InterceptorInspector());
}
The bolded section is the part you need to change.
Notice that the orderring has meaning, so you propbably can't just replace the existing one.
Then you replace the IComponentModelBuilder on the kernel, and you start registering components.
On 7/18/06, Shawn Hinsey <[EMAIL PROTECTED]> wrote:
inline
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto: [EMAIL PROTECTED]] On
> Behalf Of hammett
> Sent: Tuesday, July 18, 2006 1:32 PM
> To: [email protected]
> Subject: Re: [Castle-users] Startable facility
>
> On 7/18/06, Shawn Hinsey <[EMAIL PROTECTED]> wrote:
> > Ah, I don't pass the logger in via a constructor, it's
> coming from a
> > property in a base class that does a lookup in the container.
>
> This is, well, strange... You're using an IoC container but
> not taking advantages from it, and while base classes have
> references to it, you're contaminating your API and creating
> a strong dependency on the container implementation...
It's definitely a hack. Again, I'm coming from a slightly different
world. In spring, you could easily define a property-based dependency
without having to use constructor injection. I'd love to hear that I
just missed something in the documentation. I'm not averse to
constructor injection, it just wasn't my first instinct when I designed
this application so it'd require a lot of refactoring to implement.
> > This makes
> > sense for the logger, but I do that frequently, for
> example, my domain
> > objects (I'm not using Active Record, I use iBATIS) have private
> > properties that refer to their DAO objects, and those DAOs are
> > obtained from the container in the same way (i.e.,
> > ApplicationContext.Current[typeof(IListingDao)] as IListingDao).
>
> Well, this is also strage, but I undertand that you want your
> models to have rich support for persistence operations. I'd
> use value objects and rely on that separated layer as it
> makes my code more natural.
This is the same as above. I essntially went with a Service Locator
pattern for my DAOs to compensate.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
CastleProject-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/castleproject-users
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ CastleProject-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/castleproject-users
