bytemechanics / service-repository Goto Github PK

In order to be able to test with non singletons mocks should be available a method in getServiceSupplier to set a particular supplier, better than setInstance that only works for singletons

ServiceRespository.shutdown and ServiceRespository.reset should reset not only service instance also service suppliers

If you replace the servicesupplier for another one, you'll need to regenerate another time the new supplier.

If we try to use a service with one of it's non-public constructors the result is null and does not tell the underlaying cause for this error:

Example:

(...)
public class PersistenceUnitFactoryImpl implements PersistenceUnitFactory,Closeable{

	private final String persistenceUnit;
	private final EntityManagerFactory factory;	

	PersistenceUnitFactoryImpl(final String _persistenceUnit){
		try{
			this.persistenceUnit=_persistenceUnit;
			this.factory=createEntityManagerFactory(Collections.emptyMap());
		}catch(Throwable e){
			System.err.println("Error initiallizing persistenceUnit: "+e.getMessage());
			e.printStackTrace();
			throw e;
		}
	}
(...)

Throws:

Caused by: org.bytemechanics.service.repository.exceptions.ServiceInitializationException: Service PERSISTENCEUNIT can not be initialized properly: Unable to instantiate service with class class com.allianz.ebcm.migration.tool.persistence.impl.PersistenceUnitFactoryImpl using constructor([ebcm-migration-tool])
at org.bytemechanics.service.repository.ServiceSupplier.lambda$null$4(ServiceSupplier.java:217) ~[migration-tool-content-builder.jar:?]
at java.util.Optional.orElseThrow(Unknown Source) ~[?:1.8.0_73]
at org.bytemechanics.service.repository.ServiceSupplier.lambda$generateSupplier$5(ServiceSupplier.java:216) ~[migration-tool-content-builder.jar:?]
at org.bytemechanics.service.repository.ServiceSupplier.get(ServiceSupplier.java:149) ~[migration-tool-content-builder.jar:?]
at org.bytemechanics.service.repository.ServiceRepository.get(ServiceRepository.java:98) ~[migration-tool-content-builder.jar:?]
at org.bytemechanics.service.repository.ServiceRepository.get(ServiceRepository.java:110) ~[migration-tool-content-builder.jar:?]
at com.allianz.ebcm.migration.tool.persistence.JPAPersistenceDao.lambda$createEntityManager$1(JPAPersistenceDao.java:15) ~[migration-tool-content-builder.jar:?]
at java.util.Optional.map(Unknown Source) ~[?:1.8.0_73]
at com.allianz.ebcm.migration.tool.persistence.JPAPersistenceDao.createEntityManager(JPAPersistenceDao.java:15) ~[migration-tool-content-builder.jar:?]
at com.allianz.ebcm.migration.tool.business.services.impl.ContextServiceImpl.registerProcess(ContextServiceImpl.java:44) ~[migration-tool-content-builder.jar:?]
at com.allianz.ebcm.migration.tool.business.services.impl.ContextServiceImpl.(ContextServiceImpl.java:37) ~[migration-tool-content-builder.jar:?]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:1.8.0_73]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) ~[?:1.8.0_73]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) ~[?:1.8.0_73]
at java.lang.reflect.Constructor.newInstance(Unknown Source) ~[?:1.8.0_73]
at org.bytemechanics.service.repository.internal.commons.reflection.ObjectFactory.lambda$null$5(ObjectFactory.java:153) ~[migration-tool-content-builder.jar:?]

This could not look like so important, but it's necessary in order to find easily the initialization error cause.

The idea is that with this interface or annotation detected in the adapter or implementation the service repository treat itself as singleton automatically.

logging.properties never should be packaged with the library

Add annotation (for example @ThreadSafe/@ThreadUnsafe) in order to have some flag to control if some service is prepared to be a singleton.
If the annotation @ThreadUnsafe is found then a warning should be printed in log to warning that use as singleton can create unexpected results.

in http://service-repository.bytemechanics.org/ appears documentation with incorrect format that makes it unreadable

Not all services in standard libraries provide Closeable as implemented interface.
In order to reduce wrapper boilerplate, org.bytemechanics.service.repository.ServiceSupplier may receive an additional parameter in constructor as java.util.function.Consumer<? extends T> in order to destroy the service orderly.

For non singleton services, sometimes is interesting to allow instantiate the service passing some parameters, for this reason should be a very interesting functionality to allow service instantiation with supplied parameters.

Proposed interface:

Object get(Object... _args)
<T extends Object> T get(Class<T> _class,Object... _args)
Optional<Object> tryGet(Object... _args)
<T extends Object> Optional<T> tryGet(Class<T> _class,Object... _args)

To make the usage more intuitive should be interesting to have static instance builder to construct a DefaultServiceSupplier instance from ServiceSupplier :

public static <T extends Object> getInstance(String _name, Class<T> _adapter, Class<? extends T> _implementation, Object[] _args)
public static <T extends Object> getInstance(String _name, Class<T> _adapter, Supplier<? extends T> _supplier)
public static <T extends Object> getInstance(String _name, Class<T> _adapter, boolean _isSingleton, Class<? extends T> _implementation, Object[] _args)
public static <T extends Object> getInstance(String _name, Class<T> _adapter, boolean _isSingleton, Supplier<? extends T> _supplier)
public static <T extends Object> getInstance(String _name, Class<T> _adapter, Class<? extends T> _implementation, boolean _isSingleton, Supplier<? extends T> _supplier)