A known design pattern for dynamic factory - java

Does this have a proper name?
public class SomethingFactory {
private final String someParameter;
public SomethingFactory(String someParameter) {
this.someParameter = someParameter;
}
public Something create(String anotherParameter) {
return new Something(someParameter, anotherParameter);
}
}
public class Something {
public final String someParameter;
public final String anotherParameter;
public Something(String someParameter, String anotherParameter) {
this.someParameter = someParameter;
this.anotherParameter = anotherParameter;
}
}
What's different from a regular factory is that you have to specify a parameter at runtime to create() whenever you need to create an object.
That way you can make a singleton factory within Spring context for example, configuring first half of parameters there, and then finish with the rest of parameters at runtime when you call create().
Why I need that in the first place if you're curious:
I used to have regular singleton objects in Spring context and it was fine in thread-per-request applications, but now my whole app is non-blocking and I can't use ThreadLocal to keep stuff throughout entire request processing. For example, to keep info on timings with something like Apache StopWatch.
I needed to find a way to implement a "request scope" in a multithreading, non-blocking environment without having to supply the object representing the scope in every method (that would be silly) of my code.
So I thought let's make every (service) class take this scope object in constructor and let's create those classes on every request, but that goes against the singletons. The singletons we're talking are like, UserService that logs a user in, or a CryptoService that generates digital signatures. They're configured once in Spring, injected wheneven needed and everything's ok. But now I need to create those service classes in every method where they're needed, instead of just referencing an injected singleton instance.
So I thought let's call those singletons "templates" and whenever you need an actual instance you call create() supplying the said scope object. That way every class has the scope object, you just have to keep supplying it into other template service constructors. The full thing would look like this:
public class UserService {
private final Scope scope;
private final Template t;
private UserService(Template t, Scope scope) {
this.t = t;
this.scope = scope;
}
public void login(String username) {
scope.timings.probe("before calling database");
t.database.doSomething(username);
scope.timings.probe("after calling database");
}
public static class Template { /* The singleton configured in Spring */
private Database database;
public void setDatabase(Database database) { /* Injected by Spring */
this.database = database;
}
public UserService create(Scope scope) {
return new UserService(this, scope);
}
}
}
public class LoginHttpHandler { /* Also a Spring singleton */
private UserService.Template userServiceT;
public void setUserServiceT(UserService.Template userServiceT) { /* Injected by Spring */
this.userServiceT = userServiceT;
}
public void handle(HttpContext context) { /* Called on every http request */
userServiceT.create(context.scope).login("billgates");
}
}
In Spring you'd just describe a UserService.Template bean with the appropriate dependencies it needs and then inject that bean whenever a UserService is needed.
I just call that a "template". But like always I feel it's already been done. Does it have any name?

That is almost the example given for Guice's AssistedInject:
public class RealPaymentFactory implements PaymentFactory {
private final Provider<CreditService> creditServiceProvider;
private final Provider<AuthService> authServiceProvider;
#Inject
public RealPaymentFactory(Provider<CreditService> creditServiceProvider, Provider<AuthService> authServiceProvider) {
this.creditServiceProvider = creditServiceProvider;
this.authServiceProvider = authServiceProvider;
}
public Payment create(Date startDate, Money amount) {
return new RealPayment(creditServiceProvider.get(), authServiceProvider.get(), startDate, amount);
}
}
public class RealPayment implements Payment {
public RealPayment(
CreditService creditService, // from the Injector
AuthService authService, // from the Injector
Date startDate, // from the instance's creator
Money amount) // from the instance's creator
{
...
}
}
Assisted injection is used to "create classes that need extra arguments at construction time".
Also, this is similar to partial application, so you could have a PartialUserService that creates a UserService.

Related

How Inject prototype spring bean to singleton bean

I want to change my pojo class to spring, I have a problem for injection protoype bean to singelton bean, My old code was as follows:
public class InsertBankBusiness(){
private ServiceInput input;
public void doBusiness(ServiceInput input){
this.input = input;
....
}
},
public class BankService(){
public void definebank(ServiceInput input){
InsertBankBusiness insertBankBusiness = InsertBankBusiness ()
insertBankBusiness .doBusiness(input)
}
}
Insert BankBusiness class is not thread safe and I need to instantiate from it for every service call, I have now rewritten the code as follows:
#Component(value="insertBankBusiness")
#Scope(value="request", proxyMode=TARGET_CLASS)
public class InsertBankBusiness(){
private ServiceInput input;
public void doBusiness(ServiceInput input){
this.input = input;
....
}
},
#Service(value="bankService")
public class BankService(){
#Autowire InsertBankBusiness insertBankBusiness;
public void definebank(ServiceInput input){
insertBankBusiness.doBusiness(input)
}
}
Is the behavior of the second scenario the same as the first scenario?
Not the same.
In the first scenario, you create InsertBankBusiness service each time when access it, but in the second scenario, service creates once per HTTP request.
You need to use Prototype scope instead of Request to have the same behavior.
#Scope(value= "prototype", proxyMode=TARGET_CLASS)
public class InsertBankBusiness {
}
InsertBankBusiness injected correctly via Scoped Proxy. Each time the method on the proxy object is called, the proxy decides itself whether to create a new instance of the real object or reuse the existing one.

How to discard throwaway #Injected beans?

My ExampleBean needs information from UsefulBean1 only at creation time. So I can discard the UsefulBean1 instance after getting the information I want.
#ManagedBean
public class ExampleBean {
private int value;
#Inject
public void setUseful(UsefulBean usefulBean){
this.value = usefulBean.getValue();
//bye, bye usefulBean. see ya.
}
}
But what about my ExampleBean2, that needs, at creation time, combined information from UsefulBean1and UsefulBean2?
I know I can get them #Injected and combine the information on a #PostConstruct method:
#ManagedBean
public class ExampleBean2 {
private int value;
#Inject
private UsefulBean1 usefulBean1;
#Inject
private UsefulBean2 usefulBean2;
#PostConstruct
public void init(){
this.value = this.usefulBean1.getValue() + this.usefulBean2.getValue();
//from this point on, the usefulBeans fields are useless...
this.usefulBean1 = null;
this.usefulBean2 = null;
}
}
But it annoys me a bit that I keep these two no-longer-necessary fields (this.usefulBean1 and this.usefulBean2).
I have tried a multi-parameter set method, to no avail.
This is surely nothing breaking anything or wasting resources. But the code, IMHO, would just be more clear without fields working as temporary throwaway variables.
Is there a away to initialize a CDI bean with data from multiple other beans, without the need to set them as fields?
(First, #ManagedBean has nothing to do with CDI. It should not be used.)
(Second, always think about lifespans ("scopes"): how long should each bean live? For this example I'll pretend that you want ExampleBean2 to be the only such bean in your application, so I'll mark it with #ApplicationScoped (some of your comments above reference proxying so this is a reasonable guess). You could annotate it with, for example, #RequestScoped or #Dependent or some other scope instead. If you don't annotate it with any scope annotation, then it will behave exactly as if you had annotated it with #Dependent.)
Like this:
#ApplicationScoped
public class ExampleBean2 {
private final int value;
/**
* #deprecated To be used only by the CDI framework, not end users.
*/
#Deprecated
protected ExampleBean2() {
super();
}
#Inject
public ExampleBean2(final UsefulBean1 usefulBean1, final UsefulBean2 usefulBean2) {
super();
this.value = this.usefulBean1.getValue() + this.usefulBean2.getValue();
}
}

DeltaSpike custom ConfigSource with CDI

I am trying to define a custom DeltaSpike ConfigSource. The custom config source will have the highest priority and check the database for the config parameter.
I have a ConfigParameter entity, that simply has a key and a value.
#Entity
#Cacheable
public class ConfigParameter ... {
private String key;
private String value;
}
I have a #Dependent DAO that finds all config parameters.
What I am trying to do now, is define a custom ConfigSource, that is able to get the config parameter from the database. Therefore, I want to inject my DAO in the ConfigSource. So basically something like
#ApplicationScoped
public class DatabaseConfigSource implements ConfigSource {
#Inject
private ConfigParameterDao configParameterDao;
....
}
However, when registering the ConfigSource via META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSource, the class will be instantiated and CDI will not work.
Is there any way to get CDI working in this case?
Thanks in advance, if you need any further information, please let me know.
The main problem is, that the ConfigSource gets instantiated very early on when the BeanManager is not available yet. Even the JNDI lookup does not work at that point in time. Thus, I need to delay the injection/lookup.
What I did now, is add a static boolean to my config source, that I set manually. We have a InitializerService that makes sure that the system is setup properly. At the end of the initialization process, I call allowInitialization() in order to tell the config source, that the bean is injectable now. Next time the ConfigSource is asked, it will be able to inject the bean using BeanProvider.injectFields.
public class DatabaseConfigSource implements ConfigSource {
private static boolean allowInit;
#Inject
private ConfigParameterProvider configParameterProvider;
#Override
public int getOrdinal() {
return 500;
}
#Override
public String getPropertyValue(String key) {
initIfNecessary();
if (configParameterProvider == null) {
return null;
}
return configParameterProvider.getProperty(key);
}
public static void allowInitialization() {
allowInit = true;
}
private void initIfNecessary() {
if (allowInit) {
BeanProvider.injectFields(this);
}
}
}
I have a request-scoped bean that holds all my config variables for type-safe access.
#RequestScoped
public class Configuration {
#Inject
#ConfigProperty(name = "myProperty")
private String myProperty;
#Inject
#ConfigProperty(name = "myProperty2")
private String myProperty2;
....
}
When injecting the Configuration class in a different bean, each ConfigProperty will be resolved. Since my custom DatabaseConfigSource has the highest ordinal (500), it will be used for property resolution first. If the property is not found, it will delegate the resolution to the next ConfigSource.
For each ConfigProperty the getPropertyValue function from the DatabaseConfigSource is called. Since I do not want to retreive the parameters from the database for each config property, I moved the config property resolution to a request-scoped bean.
#RequestScoped
public class ConfigParameterProvider {
#Inject
private ConfigParameterDao configParameterDao;
private Map<String, String> configParameters = new HashMap<>();
#PostConstruct
public void init() {
List<ConfigParameter> configParams = configParameterDao.findAll();
configParameters = configParams.stream()
.collect(toMap(ConfigParameter::getId, ConfigParameter::getValue));
}
public String getProperty(String key) {
return configParameters.get(key);
}
}
I could sure change the request-scoped ConfigParameterProvider to ApplicationScoped. However, we have a multi-tenant setup and the parameters need to be resolved per request.
As you can see, this is a bit hacky, because we need to explicitly tell the ConfigSource, when it is allowed to be instantiated properly (inject the bean).
I would prefer a standarized solution from DeltaSpike for using CDI in a ConfigSource. If you have any idea on how to properly realise this, please let me know.
Even though this post has been answered already I'd like to suggest another possible solution for this problem.
I managed to load properties from my db service by creating an #Signleton #Startup EJB which extends the org.apache.deltaspike.core.impl.config.BaseConfigSource and injects my DAO as delegate which I then registered into the org.apache.deltaspike.core.api.config.ConfigResolver.
#Startup
#Singleton
public class DatabaseConfigSourceBean extends BaseConfigSource {
private static final Logger logger = LoggerFactory.getLogger(DatabaseConfigSourceBean.class);
private #Inject PropertyService delegateService;
#PostConstruct
public void onStartup() {
ConfigResolver.addConfigSources(Collections.singletonList(this));
logger.info("Registered the DatabaseConfigSourceBean in the ConfigSourceProvider ...");
}
#Override
public Map<String, String> getProperties() {
return delegateService.getProperties();
}
#Override
public String getPropertyValue(String key) {
return delegateService.getPropertyValue(key);
}
#Override
public String getConfigName() {
return DatabaseConfigSourceBean.class.getSimpleName();
}
#Override
public boolean isScannable() {
return true;
}
}
I know that creating an EJB for this purpose basically produces a way too big overhead, but I think it's a bit of a cleaner solution instead of handling this problem by some marker booleans with static accessors ...
DS is using the java se spi mechanism for this which is not CD'Injectable'. One solution would be to use the BeanProvider to get hold of your DatabaseConfigSource and delegate operations to it.

Injecting property into a static final field

I have the following class that takes processing events:
public abstract class EventExecutor {
public static final EventExecutor ON_BALANCE_CHANGE_EXECUTOR = new EventExecutor() {
private BalanceDao balanceDao;
#Override
public void executeEvent() {
BigDecimal balance;
//getting the balance
balanceDao.add(balance);
}
//GET, SET, others
};
public abstract void executeEvent();
}
The thing is processing some events means to save some data into a persistent store. Since I use Spring 4 I need to perform a corresponding dependency injection in order to perform db-operation.
Curretly, I intent to allow client to perform event handlings via invoking methods on static final fields in order to increase code readability.
So, there is a possibility to do that via ContextLoader.getCurrentWebApplicationContext().getBean(String beanName) but it introduces spring dependencies which is not a desirable solution.
Maybe there is some spring feature allowing us to do that? Couldn't you suggest anything about that?
Since you create object by hand you cannot inject beans directly in anonymous class. The possible solution is to create static inner class for ON_BALANCE_CHANGE_EXECUTOR and define bean of this type in your config.
public abstract class EventExecutor {
public static class OnBalanceChangeExecutor extends EventExecutor {
private BalanceDao balanceDao;
#Override
public void executeEvent() {
BigDecimal balance;
//getting the balance
balanceDao.add(balance);
}
//GET, SET, others
}}
After that you can create bean in your context config:
<bean id="onBalanceChangeExecutor" class = "your.package.EventExecutor$OnBalanceChangeExecutor">
<property name="balanceDao" ref="balanceDao"/>
</bean>

Changing Guice bindings at runtime

I would like to be able to change the Guice injections at runtime to support multiple injections based on user input. This is what I would like to achieve:
public interface IDao {
public int someMethod();
}
public class DaoEarth implements IDao {
#Override
public int someMethod(){ ... }
}
public class DaoMars implements IDao {
#Override
public int someMethod(){ ... }
}
public class MyClass {
#Inject
private IDao myDao;
public int myMethod(String domain) {
//If Domain == Earth, myDao should be of the type DaoEarth
//If Domain == DaoMars, myDao should be of the type DaoMars
}
}
I was thinking of writing my own Provider, but I don't know how to use that provider to change my bindings at runtime. Any input is welcome and appreciated :)!
Update
Here's what I currently came up with, it's not as pretty as I'd like, so I'm still looking for feedback
public class DomainProvider {
#Inject #Earth
private IDaoProvider earthDaoProvider;
#Inject #Mars
private IDaoProvider marsDaoProvider;
public IDaoProvider get(Domain domain){
switch (domain){
case EARTH:
return earthDaoProvider;
case MARS:
return marsDaoProvider;
}
}
public IDaoProvider get(String domain){
Domain parsedDomain = Domain.valueOf(domain.toUpperCase());
return get(parsedDomain);
}
}
//MarsDaoProvider would be equivalent
public class EarthDaoProvider implements IDaoProvider {
#Inject #Earth
private IDao earthDao;
public IDao getDao() {
return earthDao;
}
}
// This means that in "MyClass", I can do:
public class MyClass {
#Inject
private DomainProvider domainProvider;
public int myMethod(String domain) {
IDaoProvider daoProvider = domainProvider.get(domain);
IDao dao = daoProvider.getDao();
//Now "dao" will be of the correct type based on the domain
}
}
//Of course elsewhere I have the bindings set like
bind(IDao.class).annotatedWith(Earth.class).to(EarthDao.class);
Your version is almost perfect as it is: You're going to need to inject some kind of object that returns one or the other based on code you write, and don't need assisted injection or anything like that. That said, you can skip some of the boilerplate:
public class DomainProvider {
// Just inject Providers directly without binding them explicitly.
#Inject #Earth Provider<IDao> earthDaoProvider;
#Inject #Mars Provider<IDao> marsDaoProvider;
public Provider<IDao> get(Domain domain){
switch (domain){
case EARTH:
return earthDaoProvider;
case MARS:
return marsDaoProvider;
}
}
public Provider<IDao> get(String domain){
Domain parsedDomain = Domain.valueOf(domain.toUpperCase());
return get(parsedDomain);
}
}
Your MyClass in that case would be exactly identical. Here, Provider is either the one-method generic interface com.google.inject.Provider, or the equivalent builtin javax.inject.Provider that it extends. Read more about Guice Providers on the relevant Guice wiki topic.
bind(IDao.class).annotatedWith(Earth.class).to(EarthDao.class);
// You can now inject "#Earth IDao" and also "#Earth Provider<IDao>".
Basically, if you bind a key Foo (to a class, provider, #Provides method, or instance), you automatically get to inject either a Foo or Provider<Foo> with no additional work. Providers are also a great way to ensure that you get a new instance with every call to get, if that's what you want; with your original, you'll always get the same instance of EarthDao or MarsDao for any given DomainProvider you inject. (If you have a scoped binding like #Singleton, Guice will respect that too; Provider just lets Guice get involved, rather than reusing a plain old Java reference.)
This means you can skip your custom EarthDaoProvider and MarsDaoProvider, unless you really need to perform any external initialization on them—at which point you'd probably be better off calling bind(EarthDao.class).toProvider(EarthDaoProvider.class) so the preparation also happens when injecting EarthDao directly. You could also just have DomainProvider return an IDao instance directly by calling get on the appropriate Provider, and be assured that it'll be a new instance every time.

Categories