springnet-developer — Mailing list for development related to the Spring Framework .NET

Re: [Springnet-developer] JMX/JConsole like features in Spring.NET by leveraging WMI

[Bruno B. <br...@gm...>]

http://forum.springframework.net/showthread.php?t=3478

2007/9/10, Erich Eichinger <E.E...@di...>:
>
>  Hi all,
>
> I investigated this a little bit. "WMI Studio" from the "WMI Tools"
> (google for it to download) seemed appealing since it provides JConsole like
> functionality. Although it is possible to export .NET classes via
> System.Management.Instrumentation to the WMI infrastructure, there are
> some important limitations (outlined here:
> http://msdn2.microsoft.com/en-us/library/ms186136.aspx) - mostly that .NET
> types can't export methods and writable properties :-(
>
> Thus all u can do is export property values to WMI clients (e.g. for
> monitoring apps). It would have been nice, if they didn't stop half way
> again... - according to some comments on msdn blogs, NET 3.5 still
> doesn't offer more support in this field.
>
> cheers,
> Erich
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springnet-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springnet-developer
>
>

Re: [Springnet-developer] Tests Internal or External to Physical Assembly (was: Object creation invokingprotectedconstructors?)

[Trudel, S. <ste...@ba...>]

Erich,

I think many (if not most) times the author of the software has a biased
opinion as to its simplicity/usability.  Why?  They understand the
abstractions naturally because they wrote them ... they understand what
those abstractions are responsible for, how those abstractions behave,
where those abstractions fit, what abstractions are related to each
other, when the abstractions are created, when the abstractions are
used, how those abstractions are configured, etc etc etc.  That can be a
lot of information to consume for consumers.  With that said, I think
there is sound rationale to keep many things internal especially on a
commercial framework (more so than a line-of-business application or
perhaps even an open-source framework).  

With respect to Microsoft, what they have done with the .Net Framework
is very intentional by design.  A book that talks specifically to this
is Framework Design Guidelines by Brad Abrams ... you may have this one
or are familiar with it.  They specifically say they try to reduce the
number of externally abstractions (visible or not).  After all, they are
trying to create a framework of all things for all communities (C++,
Java, VB, etc, etc, etc).  Microsoft does usability studies on their
APIs to test how much suffering they are causing. I think a key question
is what type of suffering are they concerned with?  Perhaps the
suffering you are experiencing could be different based on what you are
trying to do.  Perhaps you have to learn internal details of types that
Microsoft probably did not have any intention of you learning.  I am not
sure.  What I am confident of is their intent.

Regards,
Stephen





-----Original Message-----
From: Erich Eichinger [mailto:eei...@gm...] 
Sent: Friday, September 14, 2007 5:06 AM
To: Trudel, Stephen; 'Mark Pollack'; 'Bruno Baia'; 'springnet-developer'
Subject: RE: [Springnet-developer]Object creation
invokingprotectedconstructors?


Hi Stephen,

God knows how we are suffering from MS framework folks making everything
internal. It made enabling Spring.Web DI and others a nightmare and took
me
weeks of browsing the framework assemblies using reflector. It's also
the
major reason, why there is no production-ready WinForms DI available
yet.

Thanks for taking the time to elaborate your position. It's very
interesting
for me to understand your reasoning. In fact I struggled with this
problem
for a long time until I made my decision - one of my reasons to place
tests
in a different assembly was to avoid references to nunit.framework (&
co) in
my production assemblies. I never had the idea of placing the tests
inside a
preprocessor switch. Nevertheless I won't revert my decision. Especially
when looking at the .net framework bcl, I'm pretty sure that their
design
would have been much better and more modular if they wrote their tests
in
external assemblies.

cheers,
Erich

> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...] On 
> Behalf Of Trudel, Stephen
> Sent: Donnerstag, 13. September 2007 15:04
> To: Erich Eichinger; Mark Pollack; Bruno Baia; springnet-developer
> Subject: Re: [Springnet-developer]Object creation 
> invokingprotectedconstructors?
> 
> Erich,
> 
> I believe Mark was referring to the overhead of excluding the 
> tests at a
> later time.  
> 
> There are also dangers to having the tests outside the assembly.  I
> often look at open source libraries and wonder why some abstractions
> which in fact support internal details are made public.  Is it so they
> can be tested?  A person using the API has to understand what 
> all these
> types are for and how they fit together.  That can be quite
> overwhelming.  Do we want to muddy the waters with types and members
> that should be internal?  Not if usability and productivity are of
> utmost importance.  I recommend taking a peek inside Reflector for the
> Microsoft Framework and taking inventory of the internal types and
> members ... there are quite a few.  In fact, in the Windows.Forms
> assembly there are entire modules that have internal types. How
> Microsoft tests these is their problem but by no means should they be
> public.  Hopefully their test coverage of internal members 
> and types are
> a side-effect of externally visible members.
> 
> Also there are other (less important yet important) things to consider
> outside design ... there may be a people factor involved.  Perhaps I
> want to improve the visibility of unit tests and a means of 
> emphasis of
> their importance to a staff that is NOT exactly "test infected."    
> 
> Placement of your tests outside the assembly is fine ... for you.  You
> have assessed the tradeoffs on design, etc and have made a decision as
> have I.  What we are left with is a preference.  
> 
> Regards,
> Stephen
>  
> 
> -----Original Message-----
> From: Erich Eichinger [mailto:E.E...@di...] 
> Sent: Wednesday, September 12, 2007 11:53 AM
> To: Trudel, Stephen; Mark Pollack; Bruno Baia; springnet-developer
> Subject: RE: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 
> 
> Hi Stephen,
>  
> agreed that these circumstances exist and I'm pretty sure 
> that everyone
> is already more or less convinced, that Spring.NET should 
> support them.
> Means +1 from me for supporting non-public classes and their members
> (ctor, method, props).
>  
> What I was trying to say - and I think Mark as well - is, 
> that it drives
> your design positively if you place your tests in another assembly,
> because the need for testing internal classes is more an 
> exception than
> the usual case. Sometimes you find, that you can't test a 
> class because
> it is internal - which in general (at least to my experience) 
> is a sign
> to rethink the design or it is an implementation detail. I 
> remember when
> starting TDD myself, I placed my tests into the same 
> assemblies for the
> same reasons you described here. The danger you run into when 
> doing this
> is that you might easily overlook that you are testing implementation
> details - which makes it hard to change these details later. A lot of
> tests later I'm convinced that it is an important instrument for
> improving the API of my classes to place the tests into their own
> assembly.
>  
> cheers,
> Erich
> 
> 
> ________________________________
> 
> 	From: Trudel, Stephen [mailto:ste...@ba...] 
> 	Sent: Wednesday, September 12, 2007 2:50 PM
> 	To: Mark Pollack; Erich Eichinger; Bruno Baia;
> springnet-developer
> 	Subject: RE: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 	
> 	
> 	Mark,
> 	 
> 	As we all know, the whole point is to allow separation the
> abstraction from its implementation so the two can vary independently
> (GoF, Bridge Pattern) ... that is great and I am glad Spring helps to
> apply this pattern declaratively.
> 	 
> 	The question is one of scope.  By design do we want client code
> outside the physical assembly ("external code") to inject
> implementations?  The answer to this question is rarely yes in my
> opinion so I agree with you.  
> 	 
> 	- Maybe allowing external code to inject would do more harm than
> good.  Rare?  Yes. 
> 	- Maybe it just does not make sense for external code to provide
> the implementation but for testing purposes the developer want to swap
> in a separate mock implementation. 
> 	- etc
> 	 
> 	I think a more important question is do these circumstances
> exist?  I think they do.  
> 	 
> 	I did not interpret your email as aggressive at all with regard
> to unit test placement.  
> 	 
> 	Regards,
> 	Stephen
> 
> ________________________________
> 
> 	From: Mark Pollack [mailto:mpo...@in...] 
> 	Sent: Tuesday, September 11, 2007 6:23 PM
> 	To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia';
> 'springnet-developer'
> 	Subject: RE: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 	
> 	
> 
> 	Hi Stephen,
> 
> 	 
> 
> 	Yup, at your own risk pretty much summarizes what I think is
> going on here.   I'd hope that this is a rare case since if one was
> developing an API for public consumption one would assume it 
> has enough
> functionality marked as public so that it is amenable to instantiate
> configuration via its public API, either via 'new' or via dedicated
> factory objects. I also see your point with environments putting
> constraints on where test cases reside, I wasn't trying to 
> imply a 'best
> way' as usually the best way is dependent on many many things, such as
> how you migrate to PROD, shipping policies...sometimes it is just the
> whim of a point-haired manager J  Anyway, I realize my email 
> might have
> been a bit terse/aggressive, that wasn't my intention, just trying to
> sneak in a few emails on my vacation.
> 
> 	 
> 
> 	Cheers,
> 
> 	Mark
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	From: Trudel, Stephen [mailto:ste...@ba...] 
> 	Sent: Tuesday, September 11, 2007 2:52 PM
> 	To: Mark Pollack; Erich Eichinger; Bruno Baia;
> springnet-developer
> 	Subject: RE: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 
> 	 
> 
> 	Mark,
> 
> 	 
> 
> 	I think most of us agree if developers are invoking non-public
> members on classes they did not create then they are doing so at their
> own risk.  I think there is an argument that perhaps is being 
> overlooked
> or I did not read everyone posts carefully.  If so I apologize.
> Consider if you are the class designer, your classes have internal
> members by design, and today you are NOT using Spring.  Tomorrow you
> decide to use Spring and you now have to change your class 
> design.  That
> seems intrusive.  
> 
> 	 
> 
> 	I really like your idea for top level attribute to the objects
> element ... its explicit.  
> 
> 	 
> 
> 	Whether the tests can shipped to production or not depends in
> part on if you promote source or promote binaries through the 
> promotion
> pipeline.  Our releases (QA, UAT, PROD) are done by another group who
> for audit reasons CANNOT promote binaries (rule only applies 
> to PROD but
> we follow the same process regardless).  This group must build the
> application from version control.  Based on certain conditions (e.g.
> non-DEV build) we can turn on or off a compilation switch resulting in
> our unit tests being excluded from a release.  There are other
> approaches to achieve this exclusion as well.  Clearly there are
> tradeoffs to consider.  In my experience no one has convinced me that
> tests residing in the same assembly is a bad practice.
> 
> 	 
> 
> 	Regards,
> 
> 	Stephen
> 
> 	 
> 
> ________________________________
> 
> 	From: Mark Pollack [mailto:mpo...@in...] 
> 	Sent: Tuesday, September 11, 2007 1:42 PM
> 	To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia';
> 'springnet-developer'
> 	Subject: RE: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 
> 	Hi,
> 
> 	 
> 
> 	I can see the +'s of allowing it, i.e. if a developer *really*
> needs to go under the covers to get something to work,  we 
> shouldn't get
> in the way, and the -'s of doing it, you subvert the intention of the
> original designer of the class.   How about we provide  a top level
> attribute to the <objects> element that allow for one to call 
> protected
> constructors and appropriate API changes to the context classes.  This
> way, the default is not to allow it, but if you need it, the
> requirements is made explicitly and the contract is global.  It also
> keeps the solutions simple, i.e. not per object functionality.
> 
> 	 
> 
> 	An additional question, should one also allow calling of
> protected properties, private ctor/properties?  Probably 
> something along
> the lines of xor'ing of binding properties would make sense if we want
> to go down that path.   
> 
> 	 
> 
> 	I'd guess that in some cases, people don't like having the test
> .dll dependencies within the 'production' assembly that gets shiped to
> clients, so tests are placed in a separate assembly.   
> 
> 	 
> 
> 	Cheers,
> 
> 	Mark
> 
> 	 
> 
> 	 
> 
> 	  
> 
> 	 
> 
> 	From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of
> Trudel, Stephen
> 	Sent: Tuesday, September 11, 2007 8:19 AM
> 	To: Erich Eichinger; Bruno Baia; springnet-developer
> 	Subject: Re: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 
> 	 
> 
> 	The goals of TDD can be achieved as easily when the tests are
> inside the assembly.  
> 
> 	 
> 
> ________________________________
> 
> 	From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of
> Erich Eichinger
> 	Sent: Tuesday, September 11, 2007 8:10 AM
> 	To: Bruno Baia; springnet-developer
> 	Subject: Re: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 
> 	Hi,
> 
> 	 
> 
> 	Personally I'm also not a big fan of making everything internal.
> Even more, I think that writing tests for my classes *outside* the
> assembly is a really good way for driving the design. I 
> *want* my tests
> to influence the design (that's what TDD is all about I guess). 
> 
> 	 
> 
> 	Although I think Spring should somewhat enforce what we think
> are best practices, the world is not always ideal and there are
> situations where I wished that Spring supported accessing non-public
> code.
> 
> 	 
> 
> 	-Erich
> 
> 	 
> 
> 	 
> 
> 		 
> 
> 		________________________________
> 
> 				From:
> spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of
> Bruno Baia
> 		Sent: Tuesday, September 11, 2007 2:02 PM
> 		To: Erich Eichinger
> 		Cc: springnet-developer
> 		Subject: Re: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 
> 		Hi,
> 
> 		 
> 
> 		To do that, Microsoft uses their new feature in .NET 2.0
> : the InternalsVisibleTo attribute to specify the assembly to 
> which all
> nonpublic types are to be made visible. (Take a look to
> System.ServiceModel.dll for an example.) 
> 
> 		I've also read somewhere MS uses reflection to testes
> non visible classes too.
> 
> 		 
> 
> 		Anyway, I'm really not a fan of that
> InternalsVisibleToAttribute because everything becomes internal now...
> 
> 		 
> 
> 		 
> 
> 		Bruno
> 		
> 		 
> 
> 		2007/9/11, Erich Eichinger <E.E...@di...>:
> 
> 
> 		Hi Stepen,
> 
> 		 
> 
> 		playing the "advocatus diaboli" now: How do you write
> tests for this class then? If your design does not allow for
> instantiating the class, why should Spring be allowed to? 
> 
> 		 
> 
> 		-Erich
> 
> 			 
> 
> 			________________________________
> 
> 						From:
> spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of
> Trudel, Stephen
> 			Sent: Tuesday, September 11, 2007 1:40 PM
> 			To: Erich Eichinger; springnet-developer
> 			Subject: Re: [Springnet-developer] Object
> creation invokingprotected constructors?
> 			
> 			 
> 
> 			Related question ... does Spring.Net support
> object construction for objects with internal constructors?  
> If one does
> not want the instantiation of an object to be allowed outside 
> the scope
> of a module for purposes of conceptual integrity or otherwise then
> Spring.Net  should support its construction in my opinion ... seem
> somewhat awkward when class design is influenced by a framework ... 
> 
> 			
> 			 
> 
> ________________________________
> 
> 			From:
> spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of
> Erich Eichinger
> 			Sent: Sunday, September 09, 2007 6:36 AM
> 			To: springnet-developer
> 			Subject: [Springnet-developer] Object creation
> invoking protected constructors?
> 			
> 			 
> 
> 			Steinar on the forum asked this here:
> http://forum.springframework.net/showthread.php?t=3448
> 
> 			 
> 
> 			I'd like to revisit the design decision to not
> allow accessing non-public types/constructors/methods/properties and
> hear your opinions on this. 
> 
> 			 
> 
> 			I recently ran into this issue myself when
> trying to provide a DI capable wrapper for
> "System.Web.UI.SimpleHandlerFactory" from System.Web 
> assembly. This type
> is internal and can't be instantiated using Spring which required to
> implement a (non-trivial) workaround. The easy way would be to remove
> the restriction to public types. 
> 
> 			 
> 
> 			I know of opinions out there to don't enforce
> any restrictions within the framework. Developers should know 
> what they
> are doing and if someone wants to instantiate a non-public 
> type, let him
> do it at his own risk. 
> 
> 			 
> 
> 			Other opinions?
> 
> 			 
> 
> 			cheers,
> 
> 			Erich
> 
> 			 
> 
> 		
> 	
> --------------------------------------------------------------
> ----------
> -
> 		This SF.net email is sponsored by: Microsoft
> 		Defy all challenges. Microsoft(R) Visual Studio 2005. 
> 		http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 		_______________________________________________ 
> 		Springnet-developer mailing list
> 		Spr...@li...
> 	
> https://lists.sourceforge.net/lists/listinfo/springnet-developer
> 
> 		 
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springnet-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springnet-developer

Re: [Springnet-developer] Object creation invokingprotectedconstructors?

[Erich E. <eei...@gm...>]

Hi Stephen,

God knows how we are suffering from MS framework folks making everything
internal. It made enabling Spring.Web DI and others a nightmare and took me
weeks of browsing the framework assemblies using reflector. It's also the
major reason, why there is no production-ready WinForms DI available yet.

Thanks for taking the time to elaborate your position. It's very interesting
for me to understand your reasoning. In fact I struggled with this problem
for a long time until I made my decision - one of my reasons to place tests
in a different assembly was to avoid references to nunit.framework (& co) in
my production assemblies. I never had the idea of placing the tests inside a
preprocessor switch. Nevertheless I won't revert my decision. Especially
when looking at the .net framework bcl, I'm pretty sure that their design
would have been much better and more modular if they wrote their tests in
external assemblies.

cheers,
Erich

> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...] On 
> Behalf Of Trudel, Stephen
> Sent: Donnerstag, 13. September 2007 15:04
> To: Erich Eichinger; Mark Pollack; Bruno Baia; springnet-developer
> Subject: Re: [Springnet-developer]Object creation 
> invokingprotectedconstructors?
> 
> Erich,
> 
> I believe Mark was referring to the overhead of excluding the 
> tests at a
> later time.  
> 
> There are also dangers to having the tests outside the assembly.  I
> often look at open source libraries and wonder why some abstractions
> which in fact support internal details are made public.  Is it so they
> can be tested?  A person using the API has to understand what 
> all these
> types are for and how they fit together.  That can be quite
> overwhelming.  Do we want to muddy the waters with types and members
> that should be internal?  Not if usability and productivity are of
> utmost importance.  I recommend taking a peek inside Reflector for the
> Microsoft Framework and taking inventory of the internal types and
> members ... there are quite a few.  In fact, in the Windows.Forms
> assembly there are entire modules that have internal types. How
> Microsoft tests these is their problem but by no means should they be
> public.  Hopefully their test coverage of internal members 
> and types are
> a side-effect of externally visible members.
> 
> Also there are other (less important yet important) things to consider
> outside design ... there may be a people factor involved.  Perhaps I
> want to improve the visibility of unit tests and a means of 
> emphasis of
> their importance to a staff that is NOT exactly "test infected."    
> 
> Placement of your tests outside the assembly is fine ... for you.  You
> have assessed the tradeoffs on design, etc and have made a decision as
> have I.  What we are left with is a preference.  
> 
> Regards,
> Stephen
>  
> 
> -----Original Message-----
> From: Erich Eichinger [mailto:E.E...@di...] 
> Sent: Wednesday, September 12, 2007 11:53 AM
> To: Trudel, Stephen; Mark Pollack; Bruno Baia; springnet-developer
> Subject: RE: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 
> 
> Hi Stephen,
>  
> agreed that these circumstances exist and I'm pretty sure 
> that everyone
> is already more or less convinced, that Spring.NET should 
> support them.
> Means +1 from me for supporting non-public classes and their members
> (ctor, method, props).
>  
> What I was trying to say - and I think Mark as well - is, 
> that it drives
> your design positively if you place your tests in another assembly,
> because the need for testing internal classes is more an 
> exception than
> the usual case. Sometimes you find, that you can't test a 
> class because
> it is internal - which in general (at least to my experience) 
> is a sign
> to rethink the design or it is an implementation detail. I 
> remember when
> starting TDD myself, I placed my tests into the same 
> assemblies for the
> same reasons you described here. The danger you run into when 
> doing this
> is that you might easily overlook that you are testing implementation
> details - which makes it hard to change these details later. A lot of
> tests later I'm convinced that it is an important instrument for
> improving the API of my classes to place the tests into their own
> assembly.
>  
> cheers,
> Erich
> 
> 
> ________________________________
> 
> 	From: Trudel, Stephen [mailto:ste...@ba...] 
> 	Sent: Wednesday, September 12, 2007 2:50 PM
> 	To: Mark Pollack; Erich Eichinger; Bruno Baia;
> springnet-developer
> 	Subject: RE: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 	
> 	
> 	Mark,
> 	 
> 	As we all know, the whole point is to allow separation the
> abstraction from its implementation so the two can vary independently
> (GoF, Bridge Pattern) ... that is great and I am glad Spring helps to
> apply this pattern declaratively.
> 	 
> 	The question is one of scope.  By design do we want client code
> outside the physical assembly ("external code") to inject
> implementations?  The answer to this question is rarely yes in my
> opinion so I agree with you.  
> 	 
> 	- Maybe allowing external code to inject would do more harm than
> good.  Rare?  Yes. 
> 	- Maybe it just does not make sense for external code to provide
> the implementation but for testing purposes the developer want to swap
> in a separate mock implementation. 
> 	- etc
> 	 
> 	I think a more important question is do these circumstances
> exist?  I think they do.  
> 	 
> 	I did not interpret your email as aggressive at all with regard
> to unit test placement.  
> 	 
> 	Regards,
> 	Stephen
> 
> ________________________________
> 
> 	From: Mark Pollack [mailto:mpo...@in...] 
> 	Sent: Tuesday, September 11, 2007 6:23 PM
> 	To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia';
> 'springnet-developer'
> 	Subject: RE: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 	
> 	
> 
> 	Hi Stephen,
> 
> 	 
> 
> 	Yup, at your own risk pretty much summarizes what I think is
> going on here.   I'd hope that this is a rare case since if one was
> developing an API for public consumption one would assume it 
> has enough
> functionality marked as public so that it is amenable to instantiate
> configuration via its public API, either via 'new' or via dedicated
> factory objects. I also see your point with environments putting
> constraints on where test cases reside, I wasn't trying to 
> imply a 'best
> way' as usually the best way is dependent on many many things, such as
> how you migrate to PROD, shipping policies...sometimes it is just the
> whim of a point-haired manager J  Anyway, I realize my email 
> might have
> been a bit terse/aggressive, that wasn't my intention, just trying to
> sneak in a few emails on my vacation.
> 
> 	 
> 
> 	Cheers,
> 
> 	Mark
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	From: Trudel, Stephen [mailto:ste...@ba...] 
> 	Sent: Tuesday, September 11, 2007 2:52 PM
> 	To: Mark Pollack; Erich Eichinger; Bruno Baia;
> springnet-developer
> 	Subject: RE: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 
> 	 
> 
> 	Mark,
> 
> 	 
> 
> 	I think most of us agree if developers are invoking non-public
> members on classes they did not create then they are doing so at their
> own risk.  I think there is an argument that perhaps is being 
> overlooked
> or I did not read everyone posts carefully.  If so I apologize.
> Consider if you are the class designer, your classes have internal
> members by design, and today you are NOT using Spring.  Tomorrow you
> decide to use Spring and you now have to change your class 
> design.  That
> seems intrusive.  
> 
> 	 
> 
> 	I really like your idea for top level attribute to the objects
> element ... its explicit.  
> 
> 	 
> 
> 	Whether the tests can shipped to production or not depends in
> part on if you promote source or promote binaries through the 
> promotion
> pipeline.  Our releases (QA, UAT, PROD) are done by another group who
> for audit reasons CANNOT promote binaries (rule only applies 
> to PROD but
> we follow the same process regardless).  This group must build the
> application from version control.  Based on certain conditions (e.g.
> non-DEV build) we can turn on or off a compilation switch resulting in
> our unit tests being excluded from a release.  There are other
> approaches to achieve this exclusion as well.  Clearly there are
> tradeoffs to consider.  In my experience no one has convinced me that
> tests residing in the same assembly is a bad practice.
> 
> 	 
> 
> 	Regards,
> 
> 	Stephen
> 
> 	 
> 
> ________________________________
> 
> 	From: Mark Pollack [mailto:mpo...@in...] 
> 	Sent: Tuesday, September 11, 2007 1:42 PM
> 	To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia';
> 'springnet-developer'
> 	Subject: RE: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 
> 	Hi,
> 
> 	 
> 
> 	I can see the +'s of allowing it, i.e. if a developer *really*
> needs to go under the covers to get something to work,  we 
> shouldn't get
> in the way, and the -'s of doing it, you subvert the intention of the
> original designer of the class.   How about we provide  a top level
> attribute to the <objects> element that allow for one to call 
> protected
> constructors and appropriate API changes to the context classes.  This
> way, the default is not to allow it, but if you need it, the
> requirements is made explicitly and the contract is global.  It also
> keeps the solutions simple, i.e. not per object functionality.
> 
> 	 
> 
> 	An additional question, should one also allow calling of
> protected properties, private ctor/properties?  Probably 
> something along
> the lines of xor'ing of binding properties would make sense if we want
> to go down that path.   
> 
> 	 
> 
> 	I'd guess that in some cases, people don't like having the test
> .dll dependencies within the 'production' assembly that gets shiped to
> clients, so tests are placed in a separate assembly.   
> 
> 	 
> 
> 	Cheers,
> 
> 	Mark
> 
> 	 
> 
> 	 
> 
> 	  
> 
> 	 
> 
> 	From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of
> Trudel, Stephen
> 	Sent: Tuesday, September 11, 2007 8:19 AM
> 	To: Erich Eichinger; Bruno Baia; springnet-developer
> 	Subject: Re: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 
> 	 
> 
> 	The goals of TDD can be achieved as easily when the tests are
> inside the assembly.  
> 
> 	 
> 
> ________________________________
> 
> 	From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of
> Erich Eichinger
> 	Sent: Tuesday, September 11, 2007 8:10 AM
> 	To: Bruno Baia; springnet-developer
> 	Subject: Re: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 
> 	Hi,
> 
> 	 
> 
> 	Personally I'm also not a big fan of making everything internal.
> Even more, I think that writing tests for my classes *outside* the
> assembly is a really good way for driving the design. I 
> *want* my tests
> to influence the design (that's what TDD is all about I guess). 
> 
> 	 
> 
> 	Although I think Spring should somewhat enforce what we think
> are best practices, the world is not always ideal and there are
> situations where I wished that Spring supported accessing non-public
> code.
> 
> 	 
> 
> 	-Erich
> 
> 	 
> 
> 	 
> 
> 		 
> 
> 		________________________________
> 
> 				From:
> spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of
> Bruno Baia
> 		Sent: Tuesday, September 11, 2007 2:02 PM
> 		To: Erich Eichinger
> 		Cc: springnet-developer
> 		Subject: Re: [Springnet-developer] Object creation
> invokingprotectedconstructors?
> 
> 		Hi,
> 
> 		 
> 
> 		To do that, Microsoft uses their new feature in .NET 2.0
> : the InternalsVisibleTo attribute to specify the assembly to 
> which all
> nonpublic types are to be made visible. (Take a look to
> System.ServiceModel.dll for an example.) 
> 
> 		I've also read somewhere MS uses reflection to testes
> non visible classes too.
> 
> 		 
> 
> 		Anyway, I'm really not a fan of that
> InternalsVisibleToAttribute because everything becomes internal now...
> 
> 		 
> 
> 		 
> 
> 		Bruno
> 		
> 		 
> 
> 		2007/9/11, Erich Eichinger <E.E...@di...>:
> 
> 
> 		Hi Stepen,
> 
> 		 
> 
> 		playing the "advocatus diaboli" now: How do you write
> tests for this class then? If your design does not allow for
> instantiating the class, why should Spring be allowed to? 
> 
> 		 
> 
> 		-Erich
> 
> 			 
> 
> 			________________________________
> 
> 						From:
> spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of
> Trudel, Stephen
> 			Sent: Tuesday, September 11, 2007 1:40 PM
> 			To: Erich Eichinger; springnet-developer
> 			Subject: Re: [Springnet-developer] Object
> creation invokingprotected constructors?
> 			
> 			 
> 
> 			Related question ... does Spring.Net support
> object construction for objects with internal constructors?  
> If one does
> not want the instantiation of an object to be allowed outside 
> the scope
> of a module for purposes of conceptual integrity or otherwise then
> Spring.Net  should support its construction in my opinion ... seem
> somewhat awkward when class design is influenced by a framework ... 
> 
> 			
> 			 
> 
> ________________________________
> 
> 			From:
> spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of
> Erich Eichinger
> 			Sent: Sunday, September 09, 2007 6:36 AM
> 			To: springnet-developer
> 			Subject: [Springnet-developer] Object creation
> invoking protected constructors?
> 			
> 			 
> 
> 			Steinar on the forum asked this here:
> http://forum.springframework.net/showthread.php?t=3448
> 
> 			 
> 
> 			I'd like to revisit the design decision to not
> allow accessing non-public types/constructors/methods/properties and
> hear your opinions on this. 
> 
> 			 
> 
> 			I recently ran into this issue myself when
> trying to provide a DI capable wrapper for
> "System.Web.UI.SimpleHandlerFactory" from System.Web 
> assembly. This type
> is internal and can't be instantiated using Spring which required to
> implement a (non-trivial) workaround. The easy way would be to remove
> the restriction to public types. 
> 
> 			 
> 
> 			I know of opinions out there to don't enforce
> any restrictions within the framework. Developers should know 
> what they
> are doing and if someone wants to instantiate a non-public 
> type, let him
> do it at his own risk. 
> 
> 			 
> 
> 			Other opinions?
> 
> 			 
> 
> 			cheers,
> 
> 			Erich
> 
> 			 
> 
> 		
> 	
> --------------------------------------------------------------
> ----------
> -
> 		This SF.net email is sponsored by: Microsoft
> 		Defy all challenges. Microsoft(R) Visual Studio 2005. 
> 		http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 		_______________________________________________ 
> 		Springnet-developer mailing list
> 		Spr...@li...
> 	
> https://lists.sourceforge.net/lists/listinfo/springnet-developer
> 
> 		 
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springnet-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springnet-developer

[Springnet-developer] @configurable attribute & PostSharp by Thomas Darimont

[Erich E. <E.E...@di...>]

Hi,

To ensure that nobody misses that: Thomas Darimont has posted a very =
nice solution of "configuration annotations" leveraging postsharp on =
http://forum.springframework.net/showthread.php?t=3D3473

cheers,
Erich

Re: [Springnet-developer] Object creation invokingprotectedconstructors?

[Trudel, S. <ste...@ba...>]

Erich,

I believe Mark was referring to the overhead of excluding the tests at a
later time.  

There are also dangers to having the tests outside the assembly.  I
often look at open source libraries and wonder why some abstractions
which in fact support internal details are made public.  Is it so they
can be tested?  A person using the API has to understand what all these
types are for and how they fit together.  That can be quite
overwhelming.  Do we want to muddy the waters with types and members
that should be internal?  Not if usability and productivity are of
utmost importance.  I recommend taking a peek inside Reflector for the
Microsoft Framework and taking inventory of the internal types and
members ... there are quite a few.  In fact, in the Windows.Forms
assembly there are entire modules that have internal types. How
Microsoft tests these is their problem but by no means should they be
public.  Hopefully their test coverage of internal members and types are
a side-effect of externally visible members.

Also there are other (less important yet important) things to consider
outside design ... there may be a people factor involved.  Perhaps I
want to improve the visibility of unit tests and a means of emphasis of
their importance to a staff that is NOT exactly "test infected."    

Placement of your tests outside the assembly is fine ... for you.  You
have assessed the tradeoffs on design, etc and have made a decision as
have I.  What we are left with is a preference.  

Regards,
Stephen
 

-----Original Message-----
From: Erich Eichinger [mailto:E.E...@di...] 
Sent: Wednesday, September 12, 2007 11:53 AM
To: Trudel, Stephen; Mark Pollack; Bruno Baia; springnet-developer
Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?


Hi Stephen,
 
agreed that these circumstances exist and I'm pretty sure that everyone
is already more or less convinced, that Spring.NET should support them.
Means +1 from me for supporting non-public classes and their members
(ctor, method, props).
 
What I was trying to say - and I think Mark as well - is, that it drives
your design positively if you place your tests in another assembly,
because the need for testing internal classes is more an exception than
the usual case. Sometimes you find, that you can't test a class because
it is internal - which in general (at least to my experience) is a sign
to rethink the design or it is an implementation detail. I remember when
starting TDD myself, I placed my tests into the same assemblies for the
same reasons you described here. The danger you run into when doing this
is that you might easily overlook that you are testing implementation
details - which makes it hard to change these details later. A lot of
tests later I'm convinced that it is an important instrument for
improving the API of my classes to place the tests into their own
assembly.
 
cheers,
Erich


________________________________

	From: Trudel, Stephen [mailto:ste...@ba...] 
	Sent: Wednesday, September 12, 2007 2:50 PM
	To: Mark Pollack; Erich Eichinger; Bruno Baia;
springnet-developer
	Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?
	
	
	Mark,
	 
	As we all know, the whole point is to allow separation the
abstraction from its implementation so the two can vary independently
(GoF, Bridge Pattern) ... that is great and I am glad Spring helps to
apply this pattern declaratively.
	 
	The question is one of scope.  By design do we want client code
outside the physical assembly ("external code") to inject
implementations?  The answer to this question is rarely yes in my
opinion so I agree with you.  
	 
	- Maybe allowing external code to inject would do more harm than
good.  Rare?  Yes. 
	- Maybe it just does not make sense for external code to provide
the implementation but for testing purposes the developer want to swap
in a separate mock implementation. 
	- etc
	 
	I think a more important question is do these circumstances
exist?  I think they do.  
	 
	I did not interpret your email as aggressive at all with regard
to unit test placement.  
	 
	Regards,
	Stephen

________________________________

	From: Mark Pollack [mailto:mpo...@in...] 
	Sent: Tuesday, September 11, 2007 6:23 PM
	To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia';
'springnet-developer'
	Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?
	
	

	Hi Stephen,

	 

	Yup, at your own risk pretty much summarizes what I think is
going on here.   I'd hope that this is a rare case since if one was
developing an API for public consumption one would assume it has enough
functionality marked as public so that it is amenable to instantiate
configuration via its public API, either via 'new' or via dedicated
factory objects. I also see your point with environments putting
constraints on where test cases reside, I wasn't trying to imply a 'best
way' as usually the best way is dependent on many many things, such as
how you migrate to PROD, shipping policies...sometimes it is just the
whim of a point-haired manager J  Anyway, I realize my email might have
been a bit terse/aggressive, that wasn't my intention, just trying to
sneak in a few emails on my vacation.

	 

	Cheers,

	Mark

	 

	 

	 

	 

	 

	 

	From: Trudel, Stephen [mailto:ste...@ba...] 
	Sent: Tuesday, September 11, 2007 2:52 PM
	To: Mark Pollack; Erich Eichinger; Bruno Baia;
springnet-developer
	Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?

	 

	Mark,

	 

	I think most of us agree if developers are invoking non-public
members on classes they did not create then they are doing so at their
own risk.  I think there is an argument that perhaps is being overlooked
or I did not read everyone posts carefully.  If so I apologize.
Consider if you are the class designer, your classes have internal
members by design, and today you are NOT using Spring.  Tomorrow you
decide to use Spring and you now have to change your class design.  That
seems intrusive.  

	 

	I really like your idea for top level attribute to the objects
element ... its explicit.  

	 

	Whether the tests can shipped to production or not depends in
part on if you promote source or promote binaries through the promotion
pipeline.  Our releases (QA, UAT, PROD) are done by another group who
for audit reasons CANNOT promote binaries (rule only applies to PROD but
we follow the same process regardless).  This group must build the
application from version control.  Based on certain conditions (e.g.
non-DEV build) we can turn on or off a compilation switch resulting in
our unit tests being excluded from a release.  There are other
approaches to achieve this exclusion as well.  Clearly there are
tradeoffs to consider.  In my experience no one has convinced me that
tests residing in the same assembly is a bad practice.

	 

	Regards,

	Stephen

	 

________________________________

	From: Mark Pollack [mailto:mpo...@in...] 
	Sent: Tuesday, September 11, 2007 1:42 PM
	To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia';
'springnet-developer'
	Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?

	Hi,

	 

	I can see the +'s of allowing it, i.e. if a developer *really*
needs to go under the covers to get something to work,  we shouldn't get
in the way, and the -'s of doing it, you subvert the intention of the
original designer of the class.   How about we provide  a top level
attribute to the <objects> element that allow for one to call protected
constructors and appropriate API changes to the context classes.  This
way, the default is not to allow it, but if you need it, the
requirements is made explicitly and the contract is global.  It also
keeps the solutions simple, i.e. not per object functionality.

	 

	An additional question, should one also allow calling of
protected properties, private ctor/properties?  Probably something along
the lines of xor'ing of binding properties would make sense if we want
to go down that path.   

	 

	I'd guess that in some cases, people don't like having the test
.dll dependencies within the 'production' assembly that gets shiped to
clients, so tests are placed in a separate assembly.   

	 

	Cheers,

	Mark

	 

	 

	  

	 

	From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
	Sent: Tuesday, September 11, 2007 8:19 AM
	To: Erich Eichinger; Bruno Baia; springnet-developer
	Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

	 

	The goals of TDD can be achieved as easily when the tests are
inside the assembly.  

	 

________________________________

	From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
	Sent: Tuesday, September 11, 2007 8:10 AM
	To: Bruno Baia; springnet-developer
	Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

	Hi,

	 

	Personally I'm also not a big fan of making everything internal.
Even more, I think that writing tests for my classes *outside* the
assembly is a really good way for driving the design. I *want* my tests
to influence the design (that's what TDD is all about I guess). 

	 

	Although I think Spring should somewhat enforce what we think
are best practices, the world is not always ideal and there are
situations where I wished that Spring supported accessing non-public
code.

	 

	-Erich

	 

	 

		 

		________________________________

				From:
spr...@li...
[mailto:spr...@li...] On Behalf Of
Bruno Baia
		Sent: Tuesday, September 11, 2007 2:02 PM
		To: Erich Eichinger
		Cc: springnet-developer
		Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

		Hi,

		 

		To do that, Microsoft uses their new feature in .NET 2.0
: the InternalsVisibleTo attribute to specify the assembly to which all
nonpublic types are to be made visible. (Take a look to
System.ServiceModel.dll for an example.) 

		I've also read somewhere MS uses reflection to testes
non visible classes too.

		 

		Anyway, I'm really not a fan of that
InternalsVisibleToAttribute because everything becomes internal now...

		 

		 

		Bruno
		
		 

		2007/9/11, Erich Eichinger <E.E...@di...>:


		Hi Stepen,

		 

		playing the "advocatus diaboli" now: How do you write
tests for this class then? If your design does not allow for
instantiating the class, why should Spring be allowed to? 

		 

		-Erich

			 

			________________________________

						From:
spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
			Sent: Tuesday, September 11, 2007 1:40 PM
			To: Erich Eichinger; springnet-developer
			Subject: Re: [Springnet-developer] Object
creation invokingprotected constructors?
			
			 

			Related question ... does Spring.Net support
object construction for objects with internal constructors?  If one does
not want the instantiation of an object to be allowed outside the scope
of a module for purposes of conceptual integrity or otherwise then
Spring.Net  should support its construction in my opinion ... seem
somewhat awkward when class design is influenced by a framework ... 

			
			 

________________________________

			From:
spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
			Sent: Sunday, September 09, 2007 6:36 AM
			To: springnet-developer
			Subject: [Springnet-developer] Object creation
invoking protected constructors?
			
			 

			Steinar on the forum asked this here:
http://forum.springframework.net/showthread.php?t=3448

			 

			I'd like to revisit the design decision to not
allow accessing non-public types/constructors/methods/properties and
hear your opinions on this. 

			 

			I recently ran into this issue myself when
trying to provide a DI capable wrapper for
"System.Web.UI.SimpleHandlerFactory" from System.Web assembly. This type
is internal and can't be instantiated using Spring which required to
implement a (non-trivial) workaround. The easy way would be to remove
the restriction to public types. 

			 

			I know of opinions out there to don't enforce
any restrictions within the framework. Developers should know what they
are doing and if someone wants to instantiate a non-public type, let him
do it at his own risk. 

			 

			Other opinions?

			 

			cheers,

			Erich

			 

		
	
------------------------------------------------------------------------
-
		This SF.net email is sponsored by: Microsoft
		Defy all challenges. Microsoft(R) Visual Studio 2005. 
		http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
		_______________________________________________ 
		Springnet-developer mailing list
		Spr...@li...
	
https://lists.sourceforge.net/lists/listinfo/springnet-developer

		 

Re: [Springnet-developer] Object creation invokingprotectedconstructors?

[Erich E. <E.E...@di...>]

Hi Stephen,
=20
agreed that these circumstances exist and I'm pretty sure that everyone =
is already more or less convinced, that Spring.NET should support them. =
Means +1 from me for supporting non-public classes and their members =
(ctor, method, props).
=20
What I was trying to say - and I think Mark as well - is, that it drives =
your design positively if you place your tests in another assembly, =
because the need for testing internal classes is more an exception than =
the usual case. Sometimes you find, that you can't test a class because =
it is internal - which in general (at least to my experience) is a sign =
to rethink the design or it is an implementation detail. I remember when =
starting TDD myself, I placed my tests into the same assemblies for the =
same reasons you described here. The danger you run into when doing this =
is that you might easily overlook that you are testing implementation =
details - which makes it hard to change these details later. A lot of =
tests later I'm convinced that it is an important instrument for =
improving the API of my classes to place the tests into their own =
assembly.
=20
cheers,
Erich


________________________________

	From: Trudel, Stephen [mailto:ste...@ba...]=20
	Sent: Wednesday, September 12, 2007 2:50 PM
	To: Mark Pollack; Erich Eichinger; Bruno Baia; springnet-developer
	Subject: RE: [Springnet-developer] Object creation =
invokingprotectedconstructors?
=09
=09
	Mark,
	=20
	As we all know, the whole point is to allow separation the abstraction =
from its implementation so the two can vary independently (GoF, Bridge =
Pattern) ... that is great and I am glad Spring helps to apply this =
pattern declaratively.
	=20
	The question is one of scope.  By design do we want client code outside =
the physical assembly ("external code") to inject implementations?  The =
answer to this question is rarely yes in my opinion so I agree with you. =
=20
	=20
	- Maybe allowing external code to inject would do more harm than good.  =
Rare?  Yes.=20
	- Maybe it just does not make sense for external code to provide the =
implementation but for testing purposes the developer want to swap in a =
separate mock implementation.=20
	- etc
	=20
	I think a more important question is do these circumstances exist?  I =
think they do. =20
	=20
	I did not interpret your email as aggressive at all with regard to unit =
test placement. =20
	=20
	Regards,
	Stephen

________________________________

	From: Mark Pollack [mailto:mpo...@in...]=20
	Sent: Tuesday, September 11, 2007 6:23 PM
	To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; =
'springnet-developer'
	Subject: RE: [Springnet-developer] Object creation =
invokingprotectedconstructors?
=09
=09

	Hi Stephen,

	=20

	Yup, at your own risk pretty much summarizes what I think is going on =
here.   I'd hope that this is a rare case since if one was developing an =
API for public consumption one would assume it has enough functionality =
marked as public so that it is amenable to instantiate configuration via =
its public API, either via 'new' or via dedicated factory objects. I =
also see your point with environments putting constraints on where test =
cases reside, I wasn't trying to imply a 'best way' as usually the best =
way is dependent on many many things, such as how you migrate to PROD, =
shipping policies...sometimes it is just the whim of a point-haired =
manager J  Anyway, I realize my email might have been a bit =
terse/aggressive, that wasn't my intention, just trying to sneak in a =
few emails on my vacation.

	=20

	Cheers,

	Mark

	=20

	=20

	=20

	=20

	=20

	=20

	From: Trudel, Stephen [mailto:ste...@ba...]=20
	Sent: Tuesday, September 11, 2007 2:52 PM
	To: Mark Pollack; Erich Eichinger; Bruno Baia; springnet-developer
	Subject: RE: [Springnet-developer] Object creation =
invokingprotectedconstructors?

	=20

	Mark,

	=20

	I think most of us agree if developers are invoking non-public members =
on classes they did not create then they are doing so at their own risk. =
 I think there is an argument that perhaps is being overlooked or I did =
not read everyone posts carefully.  If so I apologize.  Consider if you =
are the class designer, your classes have internal members by design, =
and today you are NOT using Spring.  Tomorrow you decide to use Spring =
and you now have to change your class design.  That seems intrusive. =20

	=20

	I really like your idea for top level attribute to the objects element =
... its explicit. =20

	=20

	Whether the tests can shipped to production or not depends in part on =
if you promote source or promote binaries through the promotion =
pipeline.  Our releases (QA, UAT, PROD) are done by another group who =
for audit reasons CANNOT promote binaries (rule only applies to PROD but =
we follow the same process regardless).  This group must build the =
application from version control.  Based on certain conditions (e.g. =
non-DEV build) we can turn on or off a compilation switch resulting in =
our unit tests being excluded from a release.  There are other =
approaches to achieve this exclusion as well.  Clearly there are =
tradeoffs to consider.  In my experience no one has convinced me that =
tests residing in the same assembly is a bad practice.

	=20

	Regards,

	Stephen

	=20

________________________________

	From: Mark Pollack [mailto:mpo...@in...]=20
	Sent: Tuesday, September 11, 2007 1:42 PM
	To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; =
'springnet-developer'
	Subject: RE: [Springnet-developer] Object creation =
invokingprotectedconstructors?

	Hi,

	=20

	I can see the +'s of allowing it, i.e. if a developer *really* needs to =
go under the covers to get something to work,  we shouldn't get in the =
way, and the -'s of doing it, you subvert the intention of the original =
designer of the class.   How about we provide  a top level attribute to =
the <objects> element that allow for one to call protected constructors =
and appropriate API changes to the context classes.  This way, the =
default is not to allow it, but if you need it, the requirements is made =
explicitly and the contract is global.  It also keeps the solutions =
simple, i.e. not per object functionality.

	=20

	An additional question, should one also allow calling of protected =
properties, private ctor/properties?  Probably something along the lines =
of xor'ing of binding properties would make sense if we want to go down =
that path.  =20

	=20

	I'd guess that in some cases, people don't like having the test .dll =
dependencies within the 'production' assembly that gets shiped to =
clients, so tests are placed in a separate assembly.  =20

	=20

	Cheers,

	Mark

	=20

	=20

	 =20

	=20

	From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
Trudel, Stephen
	Sent: Tuesday, September 11, 2007 8:19 AM
	To: Erich Eichinger; Bruno Baia; springnet-developer
	Subject: Re: [Springnet-developer] Object creation =
invokingprotectedconstructors?

	=20

	The goals of TDD can be achieved as easily when the tests are inside =
the assembly. =20

	=20

________________________________

	From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
Erich Eichinger
	Sent: Tuesday, September 11, 2007 8:10 AM
	To: Bruno Baia; springnet-developer
	Subject: Re: [Springnet-developer] Object creation =
invokingprotectedconstructors?

	Hi,

	=20

	Personally I'm also not a big fan of making everything internal. Even =
more, I think that writing tests for my classes *outside* the assembly =
is a really good way for driving the design. I *want* my tests to =
influence the design (that's what TDD is all about I guess).=20

	=20

	Although I think Spring should somewhat enforce what we think are best =
practices, the world is not always ideal and there are situations where =
I wished that Spring supported accessing non-public code.

	=20

	-Erich

	=20

	=20

		=20

		________________________________

				From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
Bruno Baia
		Sent: Tuesday, September 11, 2007 2:02 PM
		To: Erich Eichinger
		Cc: springnet-developer
		Subject: Re: [Springnet-developer] Object creation =
invokingprotectedconstructors?

		Hi,

		=20

		To do that, Microsoft uses their new feature in .NET 2.0 : the =
InternalsVisibleTo attribute to specify the assembly to which all =
nonpublic types are to be made visible. (Take a look to =
System.ServiceModel.dll for an example.)=20

		I've also read somewhere MS uses reflection to testes non visible =
classes too.

		=20

		Anyway, I'm really not a fan of that InternalsVisibleToAttribute =
because everything becomes internal now...

		=20

		=20

		Bruno
	=09
		=20

		2007/9/11, Erich Eichinger <E.E...@di...>:=20

		Hi Stepen,

		=20

		playing the "advocatus diaboli" now: How do you write tests for this =
class then? If your design does not allow for instantiating the class, =
why should Spring be allowed to?=20

		=20

		-Erich

			=20

			________________________________

						From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
Trudel, Stephen
			Sent: Tuesday, September 11, 2007 1:40 PM
			To: Erich Eichinger; springnet-developer
			Subject: Re: [Springnet-developer] Object creation invokingprotected =
constructors?
		=09
			=20

			Related question ... does Spring.Net support object construction for =
objects with internal constructors?  If one does not want the =
instantiation of an object to be allowed outside the scope of a module =
for purposes of conceptual integrity or otherwise then Spring.Net  =
should support its construction in my opinion ... seem somewhat awkward =
when class design is influenced by a framework ...=20

		=09
			=20

________________________________

			From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
Erich Eichinger
			Sent: Sunday, September 09, 2007 6:36 AM
			To: springnet-developer
			Subject: [Springnet-developer] Object creation invoking protected =
constructors?
		=09
			=20

			Steinar on the forum asked this here: =
http://forum.springframework.net/showthread.php?t=3D3448

			=20

			I'd like to revisit the design decision to not allow accessing =
non-public types/constructors/methods/properties and hear your opinions =
on this.=20

			=20

			I recently ran into this issue myself when trying to provide a DI =
capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web =
assembly. This type is internal and can't be instantiated using Spring =
which required to implement a (non-trivial) workaround. The easy way =
would be to remove the restriction to public types.=20

			=20

			I know of opinions out there to don't enforce any restrictions within =
the framework. Developers should know what they are doing and if someone =
wants to instantiate a non-public type, let him do it at his own risk.=20

			=20

			Other opinions?

			=20

			cheers,

			Erich

			=20

	=09
		=
-------------------------------------------------------------------------=

		This SF.net email is sponsored by: Microsoft
		Defy all challenges. Microsoft(R) Visual Studio 2005.=20
		http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
		_______________________________________________=20
		Springnet-developer mailing list
		Spr...@li...
		https://lists.sourceforge.net/lists/listinfo/springnet-developer

		=20

Re: [Springnet-developer] Object creation invokingprotectedconstructors?

[Trudel, S. <ste...@ba...>]

Mark,
 
As we all know, the whole point is to allow separation the abstraction
from its implementation so the two can vary independently (GoF, Bridge
Pattern) ... that is great and I am glad Spring helps to apply this
pattern declaratively.
 
The question is one of scope.  By design do we want client code outside
the physical assembly ("external code") to inject implementations?  The
answer to this question is rarely yes in my opinion so I agree with you.

 
- Maybe allowing external code to inject would do more harm than good.
Rare?  Yes. 
- Maybe it just does not make sense for external code to provide the
implementation but for testing purposes the developer want to swap in a
separate mock implementation. 
- etc
 
I think a more important question is do these circumstances exist?  I
think they do.  
 
I did not interpret your email as aggressive at all with regard to unit
test placement.  
 
Regards,
Stephen

________________________________

From: Mark Pollack [mailto:mpo...@in...] 
Sent: Tuesday, September 11, 2007 6:23 PM
To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia';
'springnet-developer'
Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?



Hi Stephen,

 

Yup, at your own risk pretty much summarizes what I think is going on
here.   I'd hope that this is a rare case since if one was developing an
API for public consumption one would assume it has enough functionality
marked as public so that it is amenable to instantiate configuration via
its public API, either via 'new' or via dedicated factory objects. I
also see your point with environments putting constraints on where test
cases reside, I wasn't trying to imply a 'best way' as usually the best
way is dependent on many many things, such as how you migrate to PROD,
shipping policies...sometimes it is just the whim of a point-haired
manager J  Anyway, I realize my email might have been a bit
terse/aggressive, that wasn't my intention, just trying to sneak in a
few emails on my vacation.

 

Cheers,

Mark

 

 

 

 

 

 

From: Trudel, Stephen [mailto:ste...@ba...] 
Sent: Tuesday, September 11, 2007 2:52 PM
To: Mark Pollack; Erich Eichinger; Bruno Baia; springnet-developer
Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?

 

Mark,

 

I think most of us agree if developers are invoking non-public members
on classes they did not create then they are doing so at their own risk.
I think there is an argument that perhaps is being overlooked or I did
not read everyone posts carefully.  If so I apologize.  Consider if you
are the class designer, your classes have internal members by design,
and today you are NOT using Spring.  Tomorrow you decide to use Spring
and you now have to change your class design.  That seems intrusive.  

 

I really like your idea for top level attribute to the objects element
... its explicit.  

 

Whether the tests can shipped to production or not depends in part on if
you promote source or promote binaries through the promotion pipeline.
Our releases (QA, UAT, PROD) are done by another group who for audit
reasons CANNOT promote binaries (rule only applies to PROD but we follow
the same process regardless).  This group must build the application
from version control.  Based on certain conditions (e.g. non-DEV build)
we can turn on or off a compilation switch resulting in our unit tests
being excluded from a release.  There are other approaches to achieve
this exclusion as well.  Clearly there are tradeoffs to consider.  In my
experience no one has convinced me that tests residing in the same
assembly is a bad practice.

 

Regards,

Stephen

 

________________________________

From: Mark Pollack [mailto:mpo...@in...] 
Sent: Tuesday, September 11, 2007 1:42 PM
To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia';
'springnet-developer'
Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?

Hi,

 

I can see the +'s of allowing it, i.e. if a developer *really* needs to
go under the covers to get something to work,  we shouldn't get in the
way, and the -'s of doing it, you subvert the intention of the original
designer of the class.   How about we provide  a top level attribute to
the <objects> element that allow for one to call protected constructors
and appropriate API changes to the context classes.  This way, the
default is not to allow it, but if you need it, the requirements is made
explicitly and the contract is global.  It also keeps the solutions
simple, i.e. not per object functionality.

 

An additional question, should one also allow calling of protected
properties, private ctor/properties?  Probably something along the lines
of xor'ing of binding properties would make sense if we want to go down
that path.   

 

I'd guess that in some cases, people don't like having the test .dll
dependencies within the 'production' assembly that gets shiped to
clients, so tests are placed in a separate assembly.   

 

Cheers,

Mark

 

 

  

 

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
Sent: Tuesday, September 11, 2007 8:19 AM
To: Erich Eichinger; Bruno Baia; springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

 

The goals of TDD can be achieved as easily when the tests are inside the
assembly.  

 

________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
Sent: Tuesday, September 11, 2007 8:10 AM
To: Bruno Baia; springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

Hi,

 

Personally I'm also not a big fan of making everything internal. Even
more, I think that writing tests for my classes *outside* the assembly
is a really good way for driving the design. I *want* my tests to
influence the design (that's what TDD is all about I guess). 

 

Although I think Spring should somewhat enforce what we think are best
practices, the world is not always ideal and there are situations where
I wished that Spring supported accessing non-public code.

 

-Erich

 

 

	 

	
________________________________


	From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Bruno Baia
	Sent: Tuesday, September 11, 2007 2:02 PM
	To: Erich Eichinger
	Cc: springnet-developer
	Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

	Hi,

	 

	To do that, Microsoft uses their new feature in .NET 2.0 : the
InternalsVisibleTo attribute to specify the assembly to which all
nonpublic types are to be made visible. (Take a look to
System.ServiceModel.dll for an example.) 

	I've also read somewhere MS uses reflection to testes non
visible classes too.

	 

	Anyway, I'm really not a fan of that InternalsVisibleToAttribute
because everything becomes internal now...

	 

	 

	Bruno
	
	 

	2007/9/11, Erich Eichinger <E.E...@di...>: 

	Hi Stepen,

	 

	playing the "advocatus diaboli" now: How do you write tests for
this class then? If your design does not allow for instantiating the
class, why should Spring be allowed to? 

	 

	-Erich

		 

		
________________________________


		From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
		Sent: Tuesday, September 11, 2007 1:40 PM
		To: Erich Eichinger; springnet-developer
		Subject: Re: [Springnet-developer] Object creation
invokingprotected constructors?
		
		 

		Related question ... does Spring.Net support object
construction for objects with internal constructors?  If one does not
want the instantiation of an object to be allowed outside the scope of a
module for purposes of conceptual integrity or otherwise then Spring.Net
should support its construction in my opinion ... seem somewhat awkward
when class design is influenced by a framework ... 

		
		 

________________________________

		From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
		Sent: Sunday, September 09, 2007 6:36 AM
		To: springnet-developer
		Subject: [Springnet-developer] Object creation invoking
protected constructors?
		
		 

		Steinar on the forum asked this here:
http://forum.springframework.net/showthread.php?t=3448

		 

		I'd like to revisit the design decision to not allow
accessing non-public types/constructors/methods/properties and hear your
opinions on this. 

		 

		I recently ran into this issue myself when trying to
provide a DI capable wrapper for "System.Web.UI.SimpleHandlerFactory"
from System.Web assembly. This type is internal and can't be
instantiated using Spring which required to implement a (non-trivial)
workaround. The easy way would be to remove the restriction to public
types. 

		 

		I know of opinions out there to don't enforce any
restrictions within the framework. Developers should know what they are
doing and if someone wants to instantiate a non-public type, let him do
it at his own risk. 

		 

		Other opinions?

		 

		cheers,

		Erich

		 

	
	
------------------------------------------------------------------------
-
	This SF.net email is sponsored by: Microsoft
	Defy all challenges. Microsoft(R) Visual Studio 2005. 
	http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
	_______________________________________________ 
	Springnet-developer mailing list
	Spr...@li...
	https://lists.sourceforge.net/lists/listinfo/springnet-developer

	 

Re: [Springnet-developer] Object creation invokingprotectedconstructors?

[Mark P. <mpo...@in...>]

Hi Stephen,

 

Yup, at your own risk pretty much summarizes what I think is going on here.
I'd hope that this is a rare case since if one was developing an API for
public consumption one would assume it has enough functionality marked as
public so that it is amenable to instantiate configuration via its public
API, either via 'new' or via dedicated factory objects. I also see your
point with environments putting constraints on where test cases reside, I
wasn't trying to imply a 'best way' as usually the best way is dependent on
many many things, such as how you migrate to PROD, shipping
policies.sometimes it is just the whim of a point-haired manager J  Anyway,
I realize my email might have been a bit terse/aggressive, that wasn't my
intention, just trying to sneak in a few emails on my vacation.

 

Cheers,

Mark

 

 

 

 

 

 

From: Trudel, Stephen [mailto:ste...@ba...] 
Sent: Tuesday, September 11, 2007 2:52 PM
To: Mark Pollack; Erich Eichinger; Bruno Baia; springnet-developer
Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?

 

Mark,

 

I think most of us agree if developers are invoking non-public members on
classes they did not create then they are doing so at their own risk.  I
think there is an argument that perhaps is being overlooked or I did not
read everyone posts carefully.  If so I apologize.  Consider if you are the
class designer, your classes have internal members by design, and today you
are NOT using Spring.  Tomorrow you decide to use Spring and you now have to
change your class design.  That seems intrusive.  

 

I really like your idea for top level attribute to the objects element ...
its explicit.  

 

Whether the tests can shipped to production or not depends in part on if you
promote source or promote binaries through the promotion pipeline.  Our
releases (QA, UAT, PROD) are done by another group who for audit reasons
CANNOT promote binaries (rule only applies to PROD but we follow the same
process regardless).  This group must build the application from version
control.  Based on certain conditions (e.g. non-DEV build) we can turn on or
off a compilation switch resulting in our unit tests being excluded from a
release.  There are other approaches to achieve this exclusion as well.
Clearly there are tradeoffs to consider.  In my experience no one has
convinced me that tests residing in the same assembly is a bad practice.

 

Regards,

Stephen

 

  _____  

From: Mark Pollack [mailto:mpo...@in...] 
Sent: Tuesday, September 11, 2007 1:42 PM
To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; 'springnet-developer'
Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?

Hi,

 

I can see the +'s of allowing it, i.e. if a developer *really* needs to go
under the covers to get something to work,  we shouldn't get in the way, and
the -'s of doing it, you subvert the intention of the original designer of
the class.   How about we provide  a top level attribute to the <objects>
element that allow for one to call protected constructors and appropriate
API changes to the context classes.  This way, the default is not to allow
it, but if you need it, the requirements is made explicitly and the contract
is global.  It also keeps the solutions simple, i.e. not per object
functionality.

 

An additional question, should one also allow calling of protected
properties, private ctor/properties?  Probably something along the lines of
xor'ing of binding properties would make sense if we want to go down that
path.   

 

I'd guess that in some cases, people don't like having the test .dll
dependencies within the 'production' assembly that gets shiped to clients,
so tests are placed in a separate assembly.   

 

Cheers,

Mark

 

 

  

 

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
Sent: Tuesday, September 11, 2007 8:19 AM
To: Erich Eichinger; Bruno Baia; springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

 

The goals of TDD can be achieved as easily when the tests are inside the
assembly.  

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
Sent: Tuesday, September 11, 2007 8:10 AM
To: Bruno Baia; springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

Hi,

 

Personally I'm also not a big fan of making everything internal. Even more,
I think that writing tests for my classes *outside* the assembly is a really
good way for driving the design. I *want* my tests to influence the design
(that's what TDD is all about I guess). 

 

Although I think Spring should somewhat enforce what we think are best
practices, the world is not always ideal and there are situations where I
wished that Spring supported accessing non-public code.

 

-Erich

 

 

 


  _____  


From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Bruno Baia
Sent: Tuesday, September 11, 2007 2:02 PM
To: Erich Eichinger
Cc: springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

Hi,

 

To do that, Microsoft uses their new feature in .NET 2.0 : the
InternalsVisibleTo attribute to specify the assembly to which all nonpublic
types are to be made visible. (Take a look to System.ServiceModel.dll for an
example.) 

I've also read somewhere MS uses reflection to testes non visible classes
too.

 

Anyway, I'm really not a fan of that InternalsVisibleToAttribute because
everything becomes internal now...

 

 

Bruno

 

2007/9/11, Erich Eichinger <E.E...@di...>: 

Hi Stepen,

 

playing the "advocatus diaboli" now: How do you write tests for this class
then? If your design does not allow for instantiating the class, why should
Spring be allowed to? 

 

-Erich

 


  _____  


From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
Sent: Tuesday, September 11, 2007 1:40 PM
To: Erich Eichinger; springnet-developer
Subject: Re: [Springnet-developer] Object creation invokingprotected
constructors?

 

Related question ... does Spring.Net support object construction for objects
with internal constructors?  If one does not want the instantiation of an
object to be allowed outside the scope of a module for purposes of
conceptual integrity or otherwise then Spring.Net  should support its
construction in my opinion ... seem somewhat awkward when class design is
influenced by a framework ... 


 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
Sent: Sunday, September 09, 2007 6:36 AM
To: springnet-developer
Subject: [Springnet-developer] Object creation invoking protected
constructors?

 

Steinar on the forum asked this here:
http://forum.springframework.net/showthread.php?t=3448

 

I'd like to revisit the design decision to not allow accessing non-public
types/constructors/methods/properties and hear your opinions on this. 

 

I recently ran into this issue myself when trying to provide a DI capable
wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web assembly.
This type is internal and can't be instantiated using Spring which required
to implement a (non-trivial) workaround. The easy way would be to remove the
restriction to public types. 

 

I know of opinions out there to don't enforce any restrictions within the
framework. Developers should know what they are doing and if someone wants
to instantiate a non-public type, let him do it at his own risk. 

 

Other opinions?

 

cheers,

Erich

 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ 
Springnet-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springnet-developer

 

Re: [Springnet-developer] Object creation invokingprotectedconstructors?

[Trudel, S. <ste...@ba...>]

Mark,
 
I think most of us agree if developers are invoking non-public members
on classes they did not create then they are doing so at their own risk.
I think there is an argument that perhaps is being overlooked or I did
not read everyone posts carefully.  If so I apologize.  Consider if you
are the class designer, your classes have internal members by design,
and today you are NOT using Spring.  Tomorrow you decide to use Spring
and you now have to change your class design.  That seems intrusive.  
 
I really like your idea for top level attribute to the objects element
... its explicit.  
 
Whether the tests can shipped to production or not depends in part on if
you promote source or promote binaries through the promotion pipeline.
Our releases (QA, UAT, PROD) are done by another group who for audit
reasons CANNOT promote binaries (rule only applies to PROD but we follow
the same process regardless).  This group must build the application
from version control.  Based on certain conditions (e.g. non-DEV build)
we can turn on or off a compilation switch resulting in our unit tests
being excluded from a release.  There are other approaches to achieve
this exclusion as well.  Clearly there are tradeoffs to consider.  In my
experience no one has convinced me that tests residing in the same
assembly is a bad practice.
 
Regards,
Stephen

________________________________

From: Mark Pollack [mailto:mpo...@in...] 
Sent: Tuesday, September 11, 2007 1:42 PM
To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia';
'springnet-developer'
Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?



Hi,

 

I can see the +'s of allowing it, i.e. if a developer *really* needs to
go under the covers to get something to work,  we shouldn't get in the
way, and the -'s of doing it, you subvert the intention of the original
designer of the class.   How about we provide  a top level attribute to
the <objects> element that allow for one to call protected constructors
and appropriate API changes to the context classes.  This way, the
default is not to allow it, but if you need it, the requirements is made
explicitly and the contract is global.  It also keeps the solutions
simple, i.e. not per object functionality.

 

An additional question, should one also allow calling of protected
properties, private ctor/properties?  Probably something along the lines
of xor'ing of binding properties would make sense if we want to go down
that path.   

 

I'd guess that in some cases, people don't like having the test .dll
dependencies within the 'production' assembly that gets shiped to
clients, so tests are placed in a separate assembly.   

 

Cheers,

Mark

 

 

  

 

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
Sent: Tuesday, September 11, 2007 8:19 AM
To: Erich Eichinger; Bruno Baia; springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

 

The goals of TDD can be achieved as easily when the tests are inside the
assembly.  

 

________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
Sent: Tuesday, September 11, 2007 8:10 AM
To: Bruno Baia; springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

Hi,

 

Personally I'm also not a big fan of making everything internal. Even
more, I think that writing tests for my classes *outside* the assembly
is a really good way for driving the design. I *want* my tests to
influence the design (that's what TDD is all about I guess). 

 

Although I think Spring should somewhat enforce what we think are best
practices, the world is not always ideal and there are situations where
I wished that Spring supported accessing non-public code.

 

-Erich

 

 

	 

	
________________________________


	From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Bruno Baia
	Sent: Tuesday, September 11, 2007 2:02 PM
	To: Erich Eichinger
	Cc: springnet-developer
	Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

	Hi,

	 

	To do that, Microsoft uses their new feature in .NET 2.0 : the
InternalsVisibleTo attribute to specify the assembly to which all
nonpublic types are to be made visible. (Take a look to
System.ServiceModel.dll for an example.) 

	I've also read somewhere MS uses reflection to testes non
visible classes too.

	 

	Anyway, I'm really not a fan of that InternalsVisibleToAttribute
because everything becomes internal now...

	 

	 

	Bruno
	
	 

	2007/9/11, Erich Eichinger <E.E...@di...>: 

	Hi Stepen,

	 

	playing the "advocatus diaboli" now: How do you write tests for
this class then? If your design does not allow for instantiating the
class, why should Spring be allowed to? 

	 

	-Erich

		 

		
________________________________


		From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
		Sent: Tuesday, September 11, 2007 1:40 PM
		To: Erich Eichinger; springnet-developer
		Subject: Re: [Springnet-developer] Object creation
invokingprotected constructors?
		
		 

		Related question ... does Spring.Net support object
construction for objects with internal constructors?  If one does not
want the instantiation of an object to be allowed outside the scope of a
module for purposes of conceptual integrity or otherwise then Spring.Net
should support its construction in my opinion ... seem somewhat awkward
when class design is influenced by a framework ... 

		
		 

________________________________

		From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
		Sent: Sunday, September 09, 2007 6:36 AM
		To: springnet-developer
		Subject: [Springnet-developer] Object creation invoking
protected constructors?
		
		 

		Steinar on the forum asked this here:
http://forum.springframework.net/showthread.php?t=3448

		 

		I'd like to revisit the design decision to not allow
accessing non-public types/constructors/methods/properties and hear your
opinions on this. 

		 

		I recently ran into this issue myself when trying to
provide a DI capable wrapper for "System.Web.UI.SimpleHandlerFactory"
from System.Web assembly. This type is internal and can't be
instantiated using Spring which required to implement a (non-trivial)
workaround. The easy way would be to remove the restriction to public
types. 

		 

		I know of opinions out there to don't enforce any
restrictions within the framework. Developers should know what they are
doing and if someone wants to instantiate a non-public type, let him do
it at his own risk. 

		 

		Other opinions?

		 

		cheers,

		Erich

		 

	
	
------------------------------------------------------------------------
-
	This SF.net email is sponsored by: Microsoft
	Defy all challenges. Microsoft(R) Visual Studio 2005. 
	http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
	_______________________________________________ 
	Springnet-developer mailing list
	Spr...@li...
	https://lists.sourceforge.net/lists/listinfo/springnet-developer

	 

Re: [Springnet-developer] Common.Logging usage in Spring.NET

[Mark P. <mpo...@in...>]

Hi,
I saw your post on the NLog list as well where the solution was posted.  It
seems we should create a log call using LogEvent.  I'll add that as an issue
to fix.  If you are keen to contribute a patch for that, please let me know.
Sorry for the delay in responding.
Cheers,
Mark

Btw. This approach is done using the log4net adapter code in common.logging.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Adrian Rodriguez
Sent: Friday, September 07, 2007 2:49 PM
To: spr...@li...
Subject: [Springnet-developer] Common.Logging usage in Spring.NET

I posted a question to the netcommon developer list about a logging
question I had.  I noticed that Spring.NET uses Common.Logging so I
figured I would ask you guys the same question.  

Here is the question I asked to netcommon:

We started using common logging with nlog.  Unfortunately, the nlog
${callsite} always renders the method name in Common.Logging.  Has
anyone here been through this before?  I want the ${callsite} to render
the method I called Common.Logging from.  If I don't have this, I don't
know where the message came from.

If anyone could provide some help in this area, I'd be very grateful.

Thanks.

<adrian />



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Springnet-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springnet-developer

Re: [Springnet-developer] Object creation invokingprotectedconstructors?

[Mark P. <mpo...@in...>]

Hi,

 

I can see the +'s of allowing it, i.e. if a developer *really* needs to go
under the covers to get something to work,  we shouldn't get in the way, and
the -'s of doing it, you subvert the intention of the original designer of
the class.   How about we provide  a top level attribute to the <objects>
element that allow for one to call protected constructors and appropriate
API changes to the context classes.  This way, the default is not to allow
it, but if you need it, the requirements is made explicitly and the contract
is global.  It also keeps the solutions simple, i.e. not per object
functionality.

 

An additional question, should one also allow calling of protected
properties, private ctor/properties?  Probably something along the lines of
xor'ing of binding properties would make sense if we want to go down that
path.   

 

I'd guess that in some cases, people don't like having the test .dll
dependencies within the 'production' assembly that gets shiped to clients,
so tests are placed in a separate assembly.   

 

Cheers,

Mark

 

 

  

 

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
Sent: Tuesday, September 11, 2007 8:19 AM
To: Erich Eichinger; Bruno Baia; springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

 

The goals of TDD can be achieved as easily when the tests are inside the
assembly.  

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
Sent: Tuesday, September 11, 2007 8:10 AM
To: Bruno Baia; springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

Hi,

 

Personally I'm also not a big fan of making everything internal. Even more,
I think that writing tests for my classes *outside* the assembly is a really
good way for driving the design. I *want* my tests to influence the design
(that's what TDD is all about I guess). 

 

Although I think Spring should somewhat enforce what we think are best
practices, the world is not always ideal and there are situations where I
wished that Spring supported accessing non-public code.

 

-Erich

 

 

 


  _____  


From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Bruno Baia
Sent: Tuesday, September 11, 2007 2:02 PM
To: Erich Eichinger
Cc: springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?

Hi,

 

To do that, Microsoft uses their new feature in .NET 2.0 : the
InternalsVisibleTo attribute to specify the assembly to which all nonpublic
types are to be made visible. (Take a look to System.ServiceModel.dll for an
example.) 

I've also read somewhere MS uses reflection to testes non visible classes
too.

 

Anyway, I'm really not a fan of that InternalsVisibleToAttribute because
everything becomes internal now...

 

 

Bruno

 

2007/9/11, Erich Eichinger <E.E...@di...>: 

Hi Stepen,

 

playing the "advocatus diaboli" now: How do you write tests for this class
then? If your design does not allow for instantiating the class, why should
Spring be allowed to? 

 

-Erich

 


  _____  


From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
Sent: Tuesday, September 11, 2007 1:40 PM
To: Erich Eichinger; springnet-developer
Subject: Re: [Springnet-developer] Object creation invokingprotected
constructors?

 

Related question ... does Spring.Net support object construction for objects
with internal constructors?  If one does not want the instantiation of an
object to be allowed outside the scope of a module for purposes of
conceptual integrity or otherwise then Spring.Net  should support its
construction in my opinion ... seem somewhat awkward when class design is
influenced by a framework ... 


 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
Sent: Sunday, September 09, 2007 6:36 AM
To: springnet-developer
Subject: [Springnet-developer] Object creation invoking protected
constructors?

 

Steinar on the forum asked this here:
http://forum.springframework.net/showthread.php?t=3448

 

I'd like to revisit the design decision to not allow accessing non-public
types/constructors/methods/properties and hear your opinions on this. 

 

I recently ran into this issue myself when trying to provide a DI capable
wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web assembly.
This type is internal and can't be instantiated using Spring which required
to implement a (non-trivial) workaround. The easy way would be to remove the
restriction to public types. 

 

I know of opinions out there to don't enforce any restrictions within the
framework. Developers should know what they are doing and if someone wants
to instantiate a non-public type, let him do it at his own risk. 

 

Other opinions?

 

cheers,

Erich

 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ 
Springnet-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springnet-developer

 

Re: [Springnet-developer] Object creation invokingprotectedconstructors?

[Trudel, S. <ste...@ba...>]

The goals of TDD can be achieved as easily when the tests are inside the
assembly.  
 
________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
Sent: Tuesday, September 11, 2007 8:10 AM
To: Bruno Baia; springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?


Hi,
 
Personally I'm also not a big fan of making everything internal. Even
more, I think that writing tests for my classes *outside* the assembly
is a really good way for driving the design. I *want* my tests to
influence the design (that's what TDD is all about I guess). 
 
Although I think Spring should somewhat enforce what we think are best
practices, the world is not always ideal and there are situations where
I wished that Spring supported accessing non-public code.
 
-Erich
 
 


________________________________

	From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Bruno Baia
	Sent: Tuesday, September 11, 2007 2:02 PM
	To: Erich Eichinger
	Cc: springnet-developer
	Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?
	
	
	Hi,
	 
	To do that, Microsoft uses their new feature in .NET 2.0 : the
InternalsVisibleTo attribute to specify the assembly to which all
nonpublic types are to be made visible. (Take a look to
System.ServiceModel.dll for an example.) 
	I've also read somewhere MS uses reflection to testes non
visible classes too.
	 
	Anyway, I'm really not a fan of that InternalsVisibleToAttribute
because everything becomes internal now...
	 
	 
	Bruno
	
	 
	2007/9/11, Erich Eichinger <E.E...@di...>: 

		Hi Stepen,
		 
		playing the "advocatus diaboli" now: How do you write
tests for this class then? If your design does not allow for
instantiating the class, why should Spring be allowed to? 
		 
		-Erich


________________________________

			From:
spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
			Sent: Tuesday, September 11, 2007 1:40 PM
			To: Erich Eichinger; springnet-developer
			Subject: Re: [Springnet-developer] Object
creation invokingprotected constructors?
			
			 
			
			Related question ... does Spring.Net support
object construction for objects with internal constructors?  If one does
not want the instantiation of an object to be allowed outside the scope
of a module for purposes of conceptual integrity or otherwise then
Spring.Net  should support its construction in my opinion ... seem
somewhat awkward when class design is influenced by a framework ... 
			
			 
________________________________

			From:
spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
			Sent: Sunday, September 09, 2007 6:36 AM
			To: springnet-developer
			Subject: [Springnet-developer] Object creation
invoking protected constructors?
			
			 
			Steinar on the forum asked this here:
http://forum.springframework.net/showthread.php?t=3448
			 
			I'd like to revisit the design decision to not
allow accessing non-public types/constructors/methods/properties and
hear your opinions on this. 
			 
			I recently ran into this issue myself when
trying to provide a DI capable wrapper for
"System.Web.UI.SimpleHandlerFactory" from System.Web assembly. This type
is internal and can't be instantiated using Spring which required to
implement a (non-trivial) workaround. The easy way would be to remove
the restriction to public types. 
			 
			I know of opinions out there to don't enforce
any restrictions within the framework. Developers should know what they
are doing and if someone wants to instantiate a non-public type, let him
do it at his own risk. 
			 
			Other opinions?
			 
			cheers,
			Erich
			 


	
------------------------------------------------------------------------
-
		This SF.net email is sponsored by: Microsoft
		Defy all challenges. Microsoft(R) Visual Studio 2005. 
		http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
		_______________________________________________ 
		Springnet-developer mailing list
		Spr...@li...
	
https://lists.sourceforge.net/lists/listinfo/springnet-developer
		
		

Re: [Springnet-developer] Object creation invokingprotectedconstructors?

[Erich E. <E.E...@di...>]

Hi,
=20
Personally I'm also not a big fan of making everything internal. Even =
more, I think that writing tests for my classes *outside* the assembly =
is a really good way for driving the design. I *want* my tests to =
influence the design (that's what TDD is all about I guess).=20
=20
Although I think Spring should somewhat enforce what we think are best =
practices, the world is not always ideal and there are situations where =
I wished that Spring supported accessing non-public code.
=20
-Erich
=20
=20


________________________________

	From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
Bruno Baia
	Sent: Tuesday, September 11, 2007 2:02 PM
	To: Erich Eichinger
	Cc: springnet-developer
	Subject: Re: [Springnet-developer] Object creation =
invokingprotectedconstructors?
=09
=09
	Hi,
	=20
	To do that, Microsoft uses their new feature in .NET 2.0 : the =
InternalsVisibleTo attribute to specify the assembly to which all =
nonpublic types are to be made visible. (Take a look to =
System.ServiceModel.dll for an example.)=20
	I've also read somewhere MS uses reflection to testes non visible =
classes too.
	=20
	Anyway, I'm really not a fan of that InternalsVisibleToAttribute =
because everything becomes internal now...
	=20
	=20
	Bruno
=09
	=20
	2007/9/11, Erich Eichinger <E.E...@di...>:=20

		Hi Stepen,
		=20
		playing the "advocatus diaboli" now: How do you write tests for this =
class then? If your design does not allow for instantiating the class, =
why should Spring be allowed to?=20
		=20
		-Erich


________________________________

			From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
Trudel, Stephen
			Sent: Tuesday, September 11, 2007 1:40 PM
			To: Erich Eichinger; springnet-developer
			Subject: Re: [Springnet-developer] Object creation invokingprotected =
constructors?
		=09
			=20
		=09
			Related question ... does Spring.Net support object construction for =
objects with internal constructors?  If one does not want the =
instantiation of an object to be allowed outside the scope of a module =
for purposes of conceptual integrity or otherwise then Spring.Net  =
should support its construction in my opinion ... seem somewhat awkward =
when class design is influenced by a framework ...=20
		=09
			=20
________________________________

			From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
Erich Eichinger
			Sent: Sunday, September 09, 2007 6:36 AM
			To: springnet-developer
			Subject: [Springnet-developer] Object creation invoking protected =
constructors?
		=09
			=20
			Steinar on the forum asked this here: =
http://forum.springframework.net/showthread.php?t=3D3448
			=20
			I'd like to revisit the design decision to not allow accessing =
non-public types/constructors/methods/properties and hear your opinions =
on this.=20
			=20
			I recently ran into this issue myself when trying to provide a DI =
capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web =
assembly. This type is internal and can't be instantiated using Spring =
which required to implement a (non-trivial) workaround. The easy way =
would be to remove the restriction to public types.=20
			=20
			I know of opinions out there to don't enforce any restrictions within =
the framework. Developers should know what they are doing and if someone =
wants to instantiate a non-public type, let him do it at his own risk.=20
			=20
			Other opinions?
			=20
			cheers,
			Erich
			=20


		=
-------------------------------------------------------------------------=

		This SF.net email is sponsored by: Microsoft
		Defy all challenges. Microsoft(R) Visual Studio 2005.=20
		http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
		_______________________________________________=20
		Springnet-developer mailing list
		Spr...@li...
		https://lists.sourceforge.net/lists/listinfo/springnet-developer
	=09
	=09

Re: [Springnet-developer] Object creation invokingprotected constructors?

[Bruno B. <br...@gm...>]

Hi,

To do that, Microsoft uses their new feature in .NET 2.0 : the
InternalsVisibleTo attribute to specify the assembly to which all nonpublic
types are to be made visible. (Take a look to System.ServiceModel.dll for an
example.)
I've also read somewhere MS uses reflection to testes non visible classes
too.

Anyway, I'm really not a fan of that InternalsVisibleToAttribute because
everything becomes internal now...


Bruno


2007/9/11, Erich Eichinger <E.E...@di...>:
>
>  Hi Stepen,
>
> playing the "advocatus diaboli" now: How do you write tests for this class
> then? If your design does not allow for instantiating the class, why should
> Spring be allowed to?
>
> -Erich
>
>  ------------------------------
> *From:* spr...@li... [mailto:
> spr...@li...] *On Behalf Of *Trudel,
> Stephen
> *Sent:* Tuesday, September 11, 2007 1:40 PM
> *To:* Erich Eichinger; springnet-developer
> *Subject:* Re: [Springnet-developer] Object creation invokingprotected
> constructors?
>
>
>  Related question ... does Spring.Net support object construction for
> objects with *internal* constructors?  If one does not want the
> instantiation of an object to be allowed outside the scope of a module for
> purposes of conceptual integrity or otherwise then Spring.Net should
> support its construction in my opinion ... seem somewhat awkward when
> class design is influenced by a framework ...
>
>
>  ------------------------------
> *From:* spr...@li... [mailto:
> spr...@li...] *On Behalf Of *Erich
> Eichinger
> *Sent:* Sunday, September 09, 2007 6:36 AM
> *To:* springnet-developer
> *Subject:* [Springnet-developer] Object creation invoking protected
> constructors?
>
>
>  Steinar on the forum asked this here:
> http://forum.springframework.net/showthread.php?t=3448
>
> I'd like to revisit the design decision to not allow accessing non-public
> types/constructors/methods/properties and hear your opinions on this.
>
> I recently ran into this issue myself when trying to provide a DI capable
> wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web assembly.
> This type is internal and can't be instantiated using Spring which required
> to implement a (non-trivial) workaround. The easy way would be to remove the
> restriction to public types.
>
> I know of opinions out there to don't enforce any restrictions within the
> framework. Developers should know what they are doing and if someone wants
> to instantiate a non-public type, let him do it at his own risk.
>
> Other opinions?
>
> cheers,
> Erich
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springnet-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springnet-developer
>
>

Re: [Springnet-developer] Object creation invokingprotected constructors?

[Trudel, S. <ste...@ba...>]

I prefer to have my tests are embedded in the module (i.e. there is a
UnitTest sub-module in every module).  I don't want the fact that my
unit tests are outside the project to influence class design either.  I
use a compilation switch to exclude them.
 
 
 
________________________________

From: Erich Eichinger [mailto:E.E...@di...] 
Sent: Tuesday, September 11, 2007 7:44 AM
To: Trudel, Stephen; springnet-developer
Subject: RE: [Springnet-developer] Object creation invokingprotected
constructors?


Hi Stepen,
 
playing the "advocatus diaboli" now: How do you write tests for this
class then? If your design does not allow for instantiating the class,
why should Spring be allowed to?
 
-Erich


________________________________

	From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
	Sent: Tuesday, September 11, 2007 1:40 PM
	To: Erich Eichinger; springnet-developer
	Subject: Re: [Springnet-developer] Object creation
invokingprotected constructors?
	
	
	Related question ... does Spring.Net support object construction
for objects with internal constructors?  If one does not want the
instantiation of an object to be allowed outside the scope of a module
for purposes of conceptual integrity or otherwise then Spring.Net should
support its construction in my opinion ... seem somewhat awkward when
class design is influenced by a framework ... 
	
	 
________________________________

	From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
	Sent: Sunday, September 09, 2007 6:36 AM
	To: springnet-developer
	Subject: [Springnet-developer] Object creation invoking
protected constructors?
	
	
	Steinar on the forum asked this here:
http://forum.springframework.net/showthread.php?t=3448
	 
	I'd like to revisit the design decision to not allow accessing
non-public types/constructors/methods/properties and hear your opinions
on this.
	 
	I recently ran into this issue myself when trying to provide a
DI capable wrapper for "System.Web.UI.SimpleHandlerFactory" from
System.Web assembly. This type is internal and can't be instantiated
using Spring which required to implement a (non-trivial) workaround. The
easy way would be to remove the restriction to public types.
	 
	I know of opinions out there to don't enforce any restrictions
within the framework. Developers should know what they are doing and if
someone wants to instantiate a non-public type, let him do it at his own
risk.
	 
	Other opinions?
	 
	cheers,
	Erich
	 

Re: [Springnet-developer] Object creation invokingprotected constructors?

[Erich E. <E.E...@di...>]

Hi Stepen,
=20
playing the "advocatus diaboli" now: How do you write tests for this =
class then? If your design does not allow for instantiating the class, =
why should Spring be allowed to?
=20
-Erich


________________________________

	From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
Trudel, Stephen
	Sent: Tuesday, September 11, 2007 1:40 PM
	To: Erich Eichinger; springnet-developer
	Subject: Re: [Springnet-developer] Object creation invokingprotected =
constructors?
=09
=09
	Related question ... does Spring.Net support object construction for =
objects with internal constructors?  If one does not want the =
instantiation of an object to be allowed outside the scope of a module =
for purposes of conceptual integrity or otherwise then Spring.Net should =
support its construction in my opinion ... seem somewhat awkward when =
class design is influenced by a framework ...=20
=09
	=20
________________________________

	From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
Erich Eichinger
	Sent: Sunday, September 09, 2007 6:36 AM
	To: springnet-developer
	Subject: [Springnet-developer] Object creation invoking protected =
constructors?
=09
=09
	Steinar on the forum asked this here: =
http://forum.springframework.net/showthread.php?t=3D3448
	=20
	I'd like to revisit the design decision to not allow accessing =
non-public types/constructors/methods/properties and hear your opinions =
on this.
	=20
	I recently ran into this issue myself when trying to provide a DI =
capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web =
assembly. This type is internal and can't be instantiated using Spring =
which required to implement a (non-trivial) workaround. The easy way =
would be to remove the restriction to public types.
	=20
	I know of opinions out there to don't enforce any restrictions within =
the framework. Developers should know what they are doing and if someone =
wants to instantiate a non-public type, let him do it at his own risk.
	=20
	Other opinions?
	=20
	cheers,
	Erich
	=20

Re: [Springnet-developer] Object creation invoking protected constructors?

[Trudel, S. <ste...@ba...>]

Related question ... does Spring.Net support object construction for
objects with internal constructors?  If one does not want the
instantiation of an object to be allowed outside the scope of a module
for purposes of conceptual integrity or otherwise then Spring.Net should
support its construction in my opinion ... seem somewhat awkward when
class design is influenced by a framework ... 

 
________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
Sent: Sunday, September 09, 2007 6:36 AM
To: springnet-developer
Subject: [Springnet-developer] Object creation invoking protected
constructors?


Steinar on the forum asked this here:
http://forum.springframework.net/showthread.php?t=3448
 
I'd like to revisit the design decision to not allow accessing
non-public types/constructors/methods/properties and hear your opinions
on this.
 
I recently ran into this issue myself when trying to provide a DI
capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web
assembly. This type is internal and can't be instantiated using Spring
which required to implement a (non-trivial) workaround. The easy way
would be to remove the restriction to public types.
 
I know of opinions out there to don't enforce any restrictions within
the framework. Developers should know what they are doing and if someone
wants to instantiate a non-public type, let him do it at his own risk.
 
Other opinions?
 
cheers,
Erich
 

[Springnet-developer] JMX/JConsole like features in Spring.NET by leveraging WMI

[Erich E. <E.E...@di...>]

Hi all,
=20
I investigated this a little bit. "WMI Studio" from the "WMI Tools" =
(google for it to download) seemed appealing since it provides JConsole =
like functionality. Although it is possible to export .NET classes via =
System.Management.Instrumentation to the WMI infrastructure, there are =
some important limitations (outlined here: =
http://msdn2.microsoft.com/en-us/library/ms186136.aspx) - mostly that =
.NET types can't export methods and writable properties :-(
=20
Thus all u can do is export property values to WMI clients (e.g. for =
monitoring apps). It would have been nice, if they didn't stop half way =
again... - according to some comments on msdn blogs, NET 3.5 still =
doesn't offer more support in this field.
=20
cheers,
Erich
=20

Re: [Springnet-developer] Welcome Marko Lahma to Spring.NET

[Marko L. <mar...@gm...>]

Thank you everybody for the warm welcome. I've monitored Spring.NET
development since 0.x (and used it since 1.0) and I'm really happy to
get the chance to contribute something back to this wonderful project.
Hopefully we have soon some scheduling integration up and running for
Spring.NET (as soon as I get my Subversion-spoiled CVS skills back on
track).

-Marko

On 9/10/07, Bruno Baia <br...@gm...> wrote:
> Welcome Marko !
>
> Cheers,
> Bruno
>
>
> 2007/9/6, Mark Pollack <mpo...@in...>:
> >
> >
> >
> >
> > Hi everyone,
> >
> >
> >
> > I'd like everyone to welcome Marko Lahma to the Spring .NET team.  He is
> the author of Quartz.NET and will be contributing integration code relating
> to easy configuration of Quartz.NET within Spring.   The initial version of
> the integration code will be available in the coming week or two as a
> separate download with a merge into the main Spring.NET distribution
> expected for Spring.NET 1.2 based on Quartz.NET 1.0.
> >
> >
> >
> > Welcome aboard Marko, looking forward to working with you.
> >
> >
> >
> > Cheers,
> >
> > Mark
> >
> >
> >
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > _______________________________________________
> > Springnet-developer mailing list
> > Spr...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/springnet-developer
> >
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springnet-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springnet-developer
>
>

Re: [Springnet-developer] Spring Quartz.NET integration

[Bruno B. <br...@gm...>]

Mark, you should create a Quartz.NET integration forum now :)

- Bruno


2007/8/29, Marko Lahma <mar...@gm...>:
>
> Hi Mark,
>
> Whatever you guys find best is fine with me. It's for sure that it
> should be kept away from core Spring, at least until it gets 1.0 ;-)
>
> The biggest thing is XML configuration support (the Quartz way). The
> no-op implementation is already in place to make Spring.NET
> integration possible. There's also the remotable Quartz scheduler, but
> I need to see how it makes sense in .NET world. So not much really,
> but as a side project of course it always takes more time than in day
> job to finish. Goal is to jump from upcoming 0.7 to 1.0 when 0.7 is
> found stable.
>
> I would guess integration is now already safe API-wise and there
> haven't been any new bug reports after 0.6 release.
>
> -Marko
>
> On 8/29/07, Mark Pollack <mpo...@in...> wrote:
> > Hi Marko,
> >
> > Thanks, sorry if I didn't get back to you before.  I think this would be
> > very useful indeed.  How do you feel about adding this as an associated
> > Spring.NET 'modules' project (much like the TIBCO/NMS support)
> now.  I've
> > been thinking of having just a single download for all the external
> modules,
> > but for now, infrastructure wise, we could be easier to add it side by
> side.
> > I'd also be in favor of having this added to Spring.NET 1.2.
> >
> > What is left on the roadmap to bring Quartz.NET to 1.0?  I didn't see
> much
> > remaining on JIRA.  A custom schema might be nice to addition.
> >
> > Cheers,
> > Mark
> >
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On Behalf Of
> > Marko Lahma
> > Sent: Wednesday, August 29, 2007 3:06 PM
> > To: spr...@li...
> > Subject: [Springnet-developer] Spring Quartz.NET integration
> >
> > Hi guys,
> >
> > I was wondering whether you had some time (I do know you are busy with
> > 1.1 release) to check the integration effort I've done for Quartz.NET.
> > This is quite straight port from Java land but seemed to work quite OK
> > with some tweaks - comments welcome.
> >
> > I would like your input on how I / we should go forward with this if
> > you find this useful.
> >
> > The zip contains Spring.Scheduling.Quartz which can be dropped to
> > Spring.Net\src\ (the project files refer to other Spring-projects.
> > I've worked mostly with VS2005 so there might be some quirks with the
> > VS2003 version.
> >
> > AdoJobStore has same issue as Java version with storing inherited
> > triggers to database with this Quartz version (0.6) I have a fix
> > already in trunk and it's scheduled for 0.7.
> >
> > http://www.cs.tut.fi/~lahma/SpringQuartzNetIntegration.zip
> >
> > Kind Regards,
> >
> > Marko Lahma
> > Quartz.NET project lead
> > http://quartznet.sourceforge.net/
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > _______________________________________________
> > Springnet-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springnet-developer
> >
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Springnet-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springnet-developer
>

Re: [Springnet-developer] Welcome Marko Lahma to Spring.NET

[Bruno B. <br...@gm...>]

Welcome Marko !

Cheers,
Bruno


2007/9/6, Mark Pollack <mpo...@in...>:
>
>  Hi everyone,
>
>
>
> I'd like everyone to welcome Marko Lahma to the Spring .NET team.  He is
> the author of Quartz.NET and will be contributing integration code
> relating to easy configuration of Quartz.NET within Spring.   The initial
> version of the integration code will be available in the coming week or two
> as a separate download with a merge into the main Spring.NET distribution
> expected for Spring.NET 1.2 based on Quartz.NET 1.0.
>
>
>
> Welcome aboard Marko, looking forward to working with you.
>
>
>
> Cheers,
>
> Mark
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Springnet-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springnet-developer
>
>

[Springnet-developer] Object creation invoking protected constructors?

[Erich E. <E.E...@di...>]

Steinar on the forum asked this here: =
http://forum.springframework.net/showthread.php?t=3D3448
=20
I'd like to revisit the design decision to not allow accessing =
non-public types/constructors/methods/properties and hear your opinions =
on this.
=20
I recently ran into this issue myself when trying to provide a DI =
capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web =
assembly. This type is internal and can't be instantiated using Spring =
which required to implement a (non-trivial) workaround. The easy way =
would be to remove the restriction to public types.
=20
I know of opinions out there to don't enforce any restrictions within =
the framework. Developers should know what they are doing and if someone =
wants to instantiate a non-public type, let him do it at his own risk.
=20
Other opinions?
=20
cheers,
Erich
=20

Re: [Springnet-developer] Ref: Microsft Object Builder

[Gaurav V. <gau...@gm...>]

Great!

Anxiously looking forward to it.... :)

Cheers,
Gaurav Vaish
www.mastergaurav.com
www.edujini-labs.com
------------------
Spoken Words Fly Away, Written Words Last Forever
------------------


  ----- Original Message -----=20
  From: Mark Pollack=20
  To: 'Gaurav Vaish' ; 'Spring.Net Devlopers'=20
  Sent: Thursday, September 06, 2007 17:16
  Subject: RE: [Springnet-developer] Ref: Microsft Object Builder


  Hi,

  From the end user point of view it will be just as clean. I wouldn't =
worry about the implementation details at the moment.  The goal will of =
course to be as feature complete, and probably more, (by type wiring, by =
named, autowiring etc)  than what object builder offers.=20

  Cheers,

  Mark

  =20

  =20

  From: Gaurav Vaish [mailto:gau...@gm...]=20
  Sent: Thursday, September 06, 2007 7:19 AM
  To: Mark Pollack; 'Spring.Net Devlopers'
  Subject: Re: [Springnet-developer] Ref: Microsft Object Builder

  =20

  Hi Mark,

  =20

      Thanks for the pointer... I do understand the tight-boundedness to =
the attributes, but IMHO - that may be sometimes preferred. At least, =
there's an option.

  =20

      However, I do not, at least at this point in time, feel really =
comfortable with the way it seems to be implemented -- implementing =
IObjectFactoryAware and PostProcessPropertyValues -- seems very =
cumbersome.

  =20

      I find the Object-Builder a lot more cleaner approach. Having said =
that I must also confess that I don't know the insights when you say, =
"I've currently scheduled it for Spring.NET 1.2" -- possibly it's clean =
there.

  =20

      I'll just give a sample of how it can be used in Object-Builder:

  =20

  1. Class with dependency (can be InjectionContructor, =
InjectionProperty or InjectionMethod)

  =20

      public class DependentClass

      {

          [InjectionContructor]

          public DependentClass([Service] IMyService service)

          {

              ....

          }

      }

  =20

  2. Serivce implementation:

  =20

      //Lazy initialization for a service of type IMyService

      [Service(typeof(IMyService), AddOnDemand =3D true)]

      public class ServiceImplementation : IMyService

      {

          ...

      }

  =20

      and, that's it.

  =20

      There are other ways also, but what I have is that my class is not =
bound to (dependent on) anything except for these attributes, which I =
think looks cleaner.

  =20

      Cleaner... as compared to what I find the URL you pointed out, =
which reads "[Inject("MyMovieFinder")]" -- which says that I must =
register a type with a name MyMovieFinder and then must know the name of =
the component at design time.

  =20

      IMHO, binding should be on the type and may not be on the name. =
Having said that, I would also say that one thought just came to my mind =
-- let the "Service / Injection" be allowed to take a name - but =
optionally. I can look for a specific implementation and may be leave it =
for the default implementation.

  =20

      Not sure if I made any sense for the readers... :)

  =20

  Cheers,
  Gaurav Vaish
  www.mastergaurav.com
  www.edujini-labs.com
  ------------------
  Spoken Words Fly Away, Written Words Last Forever
  ------------------

  =20

  =20

    ----- Original Message -----=20

    From: Mark Pollack=20

    To: 'Gaurav Vaish' ; 'Spring.Net Devlopers'=20

    Sent: Thursday, September 06, 2007 16:35

    Subject: RE: [Springnet-developer] Ref: Microsft Object Builder

    =20

    Hi,

    =20

    Yes, there is.  You will see this week this functionality added to =
the Spring Java feature set.  I've posted on the forum how one might go =
about doing this now if you are interested in using the existing =
extension points in the current spring.net container.  The link is here =
http://forum.springframework.net/showthread.php?t=3D3393 =20

    =20

    Just to note the trade offs, while there are pros to doing this, it =
does tie your class to a specific library, that one that attribute, even =
if you use that object in cases where the attribute is not read for any =
purpose.

    =20

    Hope this helps.

    Mark

    =20

    =20

    From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
Gaurav Vaish
    Sent: Thursday, September 06, 2007 6:23 AM
    To: Spring.Net Devlopers
    Subject: [Springnet-developer] Ref: Microsft Object Builder

    =20

    Hi,

    =20

        I still wonder looking at the configuration required to work =
with SpringFramework.Net...

    =20

        Why do we need to specify the injection properties / =
constructors the way that we currently do in the configuration?

    =20

        Are there any plans to make use of the Object Builder =
(Dependency Injection) mechanism as provided in the Microsoft Object =
Builder (part of Composite UI Application Block) -- using attributes... =
This makes it a lot more convenient and elegant to work with. More =
importantly, I get rid of a large part of configuration file....

    =20

    =20

    =20

    Cheers,
    Gaurav Vaish
    www.mastergaurav.com
    www.edujini-labs.com
    ------------------
    Spoken Words Fly Away, Written Words Last Forever
    ------------------

    =20

    =20

[Springnet-developer] Common.Logging usage in Spring.NET

[Adrian R. <aro...@ef...>]

I posted a question to the netcommon developer list about a logging
question I had.  I noticed that Spring.NET uses Common.Logging so I
figured I would ask you guys the same question. =20

Here is the question I asked to netcommon:

We started using common logging with nlog.  Unfortunately, the nlog
${callsite} always renders the method name in Common.Logging.  Has
anyone here been through this before?  I want the ${callsite} to render
the method I called Common.Logging from.  If I don't have this, I don't
know where the message came from.

If anyone could provide some help in this area, I'd be very grateful.

Thanks.

<adrian />

Re: [Springnet-developer] Welcome Marko Lahma to Spring.NET

[Erich E. <E.E...@di...>]

Hi Marko,
=20
Welcome to the team!
=20
cheers,
Erich
=20


________________________________

	From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
Mark Pollack
	Sent: Thursday, September 06, 2007 6:55 PM
	To: 'Spring.Net Devlopers'
	Subject: [Springnet-developer] Welcome Marko Lahma to Spring.NET
=09
=09

	Hi everyone,

	=20

	I'd like everyone to welcome Marko Lahma to the Spring .NET team.  He =
is the author of Quartz.NET and will be contributing integration code =
relating to easy configuration of Quartz.NET within Spring.   The =
initial version of the integration code will be available in the coming =
week or two as a separate download with a merge into the main Spring.NET =
distribution expected for Spring.NET 1.2 based on Quartz.NET 1.0.

	=20

	Welcome aboard Marko, looking forward to working with you.

	=20

	Cheers,

	Mark

	=20

	=20