> On June 30, 2016, 11:47 p.m., Alejandro Fernandez wrote: > > ambari-server/src/main/java/org/apache/ambari/server/controller/ControllerModule.java, > > line 648 > > <https://reviews.apache.org/r/49455/diff/1/?file=1434261#file1434261line648> > > > > Can we use reflection to look up the package name instead of hardcoding > > it?
Fixed this, however ther are other packagenames hardcoded here; long term it would be good to have the whole classpath scanning logic refactored so that all beans are looked up with a single scan ... - Laszlo ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/49455/#review140277 ----------------------------------------------------------- On July 1, 2016, 12:12 p.m., Laszlo Puskas wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/49455/ > ----------------------------------------------------------- > > (Updated July 1, 2016, 12:12 p.m.) > > > Review request for Ambari, Daniel Gergely, Sumit Mohanty, and Sebastian > Toader. > > > Bugs: AMBARI-17505 > https://issues.apache.org/jira/browse/AMBARI-17505 > > > Repository: ambari > > > Description > ------- > > Problem: > During startup the ambari server scasns the classpath for finding components > to be bound in the IoC context. > When binding upgrade check implementations the full ambari package is scanned > that leads to prolonged startup time. > > Solution: > As upgrade check implementations reside in a dedicated package, the scanner > is modified to lookup them in this very package. > (on the local env this shortens the startup time by ~25 seconds) > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/controller/ControllerModule.java > e0bda13 > > Diff: https://reviews.apache.org/r/49455/diff/ > > > Testing > ------- > > Unit tests running. > > > Thanks, > > Laszlo Puskas > >
