[Building Sakai] Deprecation Notice: kernel static covers

[Jim Eng]

Quick question:

As I recall, each static cover has a getInstance() method that gets  
the current instance of that service from the ComponentManager. Would  
it be possible to have a mock ComponentManager from which one would  
get the mock service impl's for unit tests?

Thanks.

Jim


On Mar 18, 2010, at 10:00 AM, David Haines wrote:

> There are good reasons both for keeping and removing the covers.   
> IMHO the fact that using static covers makes uniform unit testing  
> impossible is the critical issue in the long term. However requiring  
> a lot of code changes in a lump is pretty unattractive too.
>
> What do people think of incrementally moving to the following  
> pattern?  It should allow the use of either covers or dependency  
> injection (DI) with minimal impact.
>
> 1)  Add  an "assureInstance(S)" method to each static cover.  This  
> is guaranteed to return an instance of the service implementation.   
> That instance will be either the existing instance S, if an existing  
> service instance value is passed in, or if the argument value is  
> null the value would be the instance that would be used internally  
> by the static cover.
>
> 2) In client code initialize the service variable using the static  
> cover like this:
>
> MyServiceApi s = null;
> :
> :
> :
> s = MyServiceCover.assureInstance(s);
> :
> :
> :
>
> 3) Make it a best practice for future work to reference service  
> methods based on a instance variable holding a reference to  
> service.  If the service variable is set using the assureInstance  
> method then using the variable will eliminate the explicit  
> dependence on most static cover methods while still allowing the  
> convenience of using the static cover initialization.
>
> 4) Optionally create constructor argument and/or setter method to  
> allow injecting the service implementation.
>
> The current static covers would be changed to implement  
> assureInstance.  The other methods in the static covers could be  
> depreciated but wouldn't need to be removed.
>
> This doesn't require any changes to code currently using static  
> covers.  It allows optional DI to be added to existing code with  
> little effort and few code changes.
>
> For testing this means that it is possible, and even easy, to remove  
> this critical obstacle to testing on a case by case basis.  For  
> people with existing code it has no impact.
>
> Comments?  Suggestions?
>
> - Dave
>
> David Haines
> CTools Developer
> Digital Media Commons
> University of Michigan
> dlhaines at umich.edu
>
>
>
>
> On Mar 17, 2010, at 12:27 PM, csev wrote:
>
>> -1
>>
>> Covers are not harmful and the transition from K1 to K2 is a  
>> complete rewrite and of course K2 will never have covers. If K1 to  
>> K2 were some kind of "upgrade" - we should deprecate all of K1.
>>
>> I personally think that excessive use of Spring when not needed is  
>> *bad practice*.   I am happy to switch to the more factory-like  
>> locator pattern - but switching to Spring injection is not a step  
>> forward IMHO in terms of code cleanliness and maintainability.  And  
>> is it not the case that K2 a completely different service model?
>>
>> Don't even deprecate these.  We don't want to have so many  
>> deprecation warnings that we start to ignore them in general or  
>> turn them off in compiles - this way when there is something that  
>> *really* needs attention because a third-party jar is changing will  
>> get missed in the sea of superfluous deprecation warnings.
>>
>> /Chuck
>>
>> On Mar 17, 2010, at 4:04 AM, David Horwitz wrote:
>>
>>> Deprecation Notice: In the next scheduled release in the 1.1  
>>> kernel series (1.1.2) all the Static covers of kernel services  
>>> will be marked as deprecated. Developers are urged to review their  
>>> code and replace the use of static covers with spring injection or  
>>> lookup from the component manager in line with stated Sakai best  
>>> practices [http://confluence.sakaiproject.org/display/SAKDEV/Best+Practices+for+Kernel+code#BestPracticesforKernelcode-Nousageofstaticcovers 
>>> ]. The covers are scheduled for removal in Kernel 2.0.0
>>>
>>> Regards
>>>
>>> David
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>>>  with a subject of "unsubscribe"
>>>
>>>
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>>  with a subject of "unsubscribe"
>>
>>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100318/d1266832/attachment.html