Uploaded image for project: 'Tamaya'
  1. Tamaya
  2. TAMAYA-25

Simplify Component Loading



    • Improvement
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 0.1-incubating
    • API
    • None


      • Rename Bootstrap to Singleton (or something other) and ensure there is a static set method to define service loading with in Tamaya programmatically.
      • Remove caching of spi's in different singletons.

      Extract of the mailing:

      2014-12-14 0:25 GMT+01:00 Romain Manni-Bucau <rmannibucau@gmail.com>:
      > I saw in several projects this kind of pattern:
      > Singleton.get()/Singleton.set(Instance) // replace the SPI. set() can
      > throw an exception if already set, I would just log a warn/err but not
      > fail.
      ​I personally do not like this pattern much​. I would prefer a clear API
      that is free of such initialization things. Using ServiceLoader and on top
      reading a system property would work as well in most cases.
      But one aspect where I have to say, has its pros, is that you can add any
      kind of complexity of initialization on top of it, instead of being stick
      to exactly one kind of root initialization.
      > Then Singleton.get() returns a Context. Then Context has a
      > ServiceResolver. Then ServiceResolver has a T getService(Class<T>). If
      > you need a list of service you define a dedicated service
      > (FormatsProvider.getFormats() or PropertySources.getSources() for
      > instance)
      ​Pros and Cons I see here. Pro: the spi and the debugging​
      ​would be possibly easier. Con: you probably duplicate the loading code for
      services mutliple times for each​, whereas I would expect the loading
      policy to be unified for a certain runtime (eg if I support loading SPIs
      from CDI I would expect this is the case for all kind of SPIs in my system,
      not only for some).
      > In sumarry the singleton allows to define a behavior for the current
      > environment (EE, standalone, OSGi etc...) then Context represent
      > current app services.
      ​Agree, that is what currently Bootstrap (via ServiceProvider) does.​
      > The good point is you can get rid of classloader assumptions (which
      > will never be portable or even work - see deltaspike
      > BeanManagerProvider if you doubt of it) simply providing a container
      > specific implementation without impacting apps/extensions themself if
      > tamaya is provided by the container - which will hopefully be the case
      > after some work ;).
      ​So summarizing, I would propose:
      1) Rename *Boostrap *to *Singleton*
      2) Rename the (existing) *Singleton.init(ServiceProvider) *method to
      *    Singleton.set(ServiceProvider)*, writing a warning if one is already
          (currently it throws an error).
      3) Let all backing calls go to* Singleton.get(SPIClass.class)* instead of
          static instance variables​
      ​holding the loaded backing beans, making CDI
          support (and testing)
      4) If no *ServiceProvider *was registered using* set(ServiceProvider) *I
      would still
          fallback to the *ServiceLoader *based version and additionally write an
      INFO log
          that the default loading is in place. This will make it work OOTB in
      all SE
          scenarios, but with the INFO log developers also some hint that they
          running on defaults...
      5) I would not add additional services just for asking for collection of
         but keep the *public static <T> Collection<? extends T>
      getServices(Class<T> *
      *   serviceType)*on *Singleton*.
      6) Perhaps we should also rename *public static <T> T getService(Class<T>
      serviceType) *to *getSingleton(...)* ?




            anatole Anatole Tresch
            anatole Anatole Tresch
            1 Vote for this issue
            2 Start watching this issue