On 28/03/13 9:00 AM, "Kelven Yang" <kelven.y...@citrix.com> wrote: >> >>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
Thanks Kelven. Temporarily I pushed e8a144a21d46467109ae2780fe30cc1e34b0abcf to master that bypass auto wiring. This will unblock the OSS builds. I will apply clean fix based on what you suggested.
