On 3/27/13 7:53 PM, "Murali Reddy" <murali.re...@citrix.com> wrote:
>On 28/03/13 7:42 AM, "Chip Childers" <chip.child...@sungard.com> wrote: > >>On Wed, Mar 27, 2013 at 04:31:05PM -0700, Kelven Yang wrote: >>> For UCS issue, I've put a fix in. >>> >>> For GSLB, a work around is to run non-OSS build, hopefully this can >>>unlock >>> developers temporarily on master branch >> >>Good work-around for now. >> >>Murali - This appears to be something that we *all* missed realizing >>prior to the merge of the GSLB functionality. Can you sort this out >>during your day today? > >I was running Non-oss builds, so could not hit this issue. My apologies >for the breaking OSS build. > >Kelven, > >I am not sure how to fix this issue. If there is no implementing class, >why should inject fail? I was under impression it will be set to null? > >I have this code in one of the managers in server, but the implementing >class for GslbServiceProvider is only present in non-oss NetScaler >plug-in. If you can suggest how to deal with this in Spring auto wiring >that would be useful for me to quickly fix this. > >@Inject > protected GslbServiceProvider _gslbProvider; > In this case, you should avoid using auto-wiring, so that it won't be bound at loading time. Spring is designed to shout out loudly at loading time instead of run-time if it finds any unresolvable auto-wiring in place. It is good to expose the issue early and force developer to fix it. This is what you may do, 1) Remove @Inject for _gslbProvider; 2) Make your code be safe at runtime to deal with the possibility that _gslbProvider is null 3) Provide getter and setters to _gslbProvider 4) Put the wiring logic in nonossComponentContext.xml so that it is only loaded in non-OSS build Kelven >
