The issue isn't related with Windsor. The issue is that the ILogger abstraction is the most obvious one, and any project/application/framework that tries to decouple/abstract it's logging machinery ends up using it.
Since logging and data access usually share the same space inside a model, the new interface introduced by NHibernate causes a lot of friction: the developer must open each class that consumes the logger service and something from NHibernate and fix his namespace using directives. Cheers, Henry Conceição On Mon, Sep 20, 2010 at 2:57 PM, Fabio Maulo <[email protected]> wrote: > Don't worry. > We have the adapter for log4net and won't have anything else because the > logger is now injectable. > zero config, zero friction, zero breaking-changes, flexible solution, > everybody happy. > I'm using NH with Windsor and... zero problem even there... but well... > http://www.youtube.com/watch?v=ZBvy7mmiD-8&; > > On Mon, Sep 20, 2010 at 3:33 PM, Patrick Earl <[email protected]> wrote: >> >> The problem is that the NHibernate namespace is commonly used by other >> applications, but in this case we're using it for an "internal" >> class. It'd be nice to even mark the logger interface as internal, >> but we need to make it accessible to other NH-related assemblies. The >> work-around is to rename it or put it in it's own namespace. I'm in >> favor of it's own namespace myself (given the number of classes that >> are there and could potentially be there if further log providers are >> integrated into the core). No biggie though, just wanted to get my 2 >> cents in there. :) >> >> On an unrelated topic, I wanted to say thanks to Fabio and Julian who >> have been applying my patches. I feel that my work is valued and that >> I'm helping to make a difference in this excellent project. Thanks! >> >> Patrick Earl > > > -- > Fabio Maulo > >
