[jira] [Updated] (TAMAYA-25) Simplify Component Loading

["Anatole Tresch (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TAMAYA-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anatole Tresch updated TAMAYA-25:
---------------------------------
    Summary: Simplify Component Loading  (was: sIMPLIFY cOMPONENT lOADING)

> Simplify Component Loading
> --------------------------
>
>                 Key: TAMAYA-25
>                 URL: https://issues.apache.org/jira/browse/TAMAYA-25
>             Project: Tamaya
>          Issue Type: Improvement
>          Components: API
>            Reporter: Anatole Tresch
>            Assignee: Anatole Tresch
>
> Rename Bootstrap to Singleton and ensure there is a static set method to define service loading with in Tamaya programmatically.
> Extract of the mailing:
> {noformat}
> 2014-12-14 0:25 GMT+01:00 Romain Manni-Bucau <rm...@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
> set
>     (currently it throws an error).
> 3) Let all backing calls go to* Singleton.get(SPIClass.class)* instead of
> managing
>     static instance variables​
> ​holding the loaded backing beans, making CDI
>     support (and testing)
> easier​
> ​.​
> 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
> are
>     running on defaults...
> 5) I would not add additional services just for asking for collection of
> services,
>    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(...)* ?
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)