I am new to EJB. I have a requirement of calling a method of remote stateless bean and setting a value, before calling any method on the same bean. The value set from first method call should be available to second method. I know that a stateless bean can't hold instance variables values for next calls. Is there any alternative to make the value available to the bean method without making bean as stateful bean. any tweaking tip?
Is there any alternative to make the value available to the bean method without making bean as stateful bean?
Without passing the value to the second method or persisting it, for example in database, I don't think so (using an instance variables is certainly not a solution as you're not sure to call the same session bean with each method call because the pool can return any session bean for your method call).
It is a wrong use of stateless session bean. Stateless should depend upon only the parameters that are being passed to it and no other previous state. Even if you put a hack around it, think of poor guys who will support it later.
Database is definitely a better way of doing it. Otherwise, can you use interceptors ? They are powerful in EJB 3.0 and can even change the parameters, set some value etc.
Related
So I am autowiring a service bean that I pass a map and it injects objects into it and returns it to my controller. Nowhere in my controller am I ever changing my bean, I send it info, and it returns me something. However, inside the bean, I am using class level variables in order to manage information as it moves around the class. Does this compromise thread safety?
I've removed class level variables, and begun passing the objects I need from method to method. Thank you for all of the input!
I want to refresh bean (destroy, initialize) if some property is changed, for example db url connection. The problem is that this bean might be already injected in other beans in CDI container. I have 2 thoughts about this:
1. If bean is proxied - destroy target for this proxy, re-initialize target inside this proxy.
2. For #Singleton and #Dependent beans, because they are not proxied, I can wrap such beans in proxy and do the same as above.
The reason I want to wrap it in proxy is that when property changed and I want to recreate real object, I should also know all dependent beans that have dependency on my bean.
So my questions are:
1. How to replace real object inside proxy in CDI? or
2. If I dont want to keep proxy as I explained above, how to create proxy object for my bean and re-inject it to all dependent beans in CDI container?
This is my previous question:
Re-inject CDI bean if some injected property changed
Again, I use CDI (Weld), not Spring IoC, so I can not use #RefreshScope from Spring cloud config, but I think my expected functionality can be similar with using custom scope.
For #DependedSCoped beans you can use
class MyBean {
#Inject
private Instance<MYType> myTypeInst;
// This will ensure, that the bean is always fresh created.
// But the property value on the former instance will be lost
// So the changable value has to be provided another way to the created bean
public void do SomeThing(){
MyType bean = myTypeInst.get();
myTypeInst.destroy(bean);
}
}
If you use a #Depended scoped bean, then you must be aware that the injection target gets its instance which is exclusively for this bean, so who is changing the value? Is the #Dependend scope the right scope for your use case?
It should not be necessary to provide an own proxy or hack into an existing one, just find the proper scope for your use case and implement the bean properly. If a connection url can change then the bean managing the connection must be aware of a change and recreate the connection and the beans using this bean need to retrieve the connection each time the use it.
Maybe you could provide an description of your use case, then we maybe can you provide you with an better answer.
Conclusion
As the use case became clear (see comments below), it resulted in the intention to implement a custom scope, because CDI doesn't seem to provide a suitable scope for this use case. I recommend to try to find a provided CDI scope if possible and implement a custom scope only if necessary, because you will have to take care about the lifecycle of your beans, management of your scope and how the beans, managed by your scope, can and will be used by an application. If not implemented with care a custom scope could cause problems such as memory leaks, if for instance your beans are not properly discarded after usage.
I don't understand the decision for why the Spring Framework is designed by default to return instances that are a singleton. So the same object is passed around when calling the application context. What are some reasons that influenced spring's decision to handle bean initialization this way? What are some bad things that can happen if all beans were initialized as prototypes?
Thank you in advance.
I think that Spring documents explain this point very well. Shortly the reason is that if your bean is stateless your do not need more than one instance. Since most beans are stateless "singleton" is a default scope. You can however change this. There are other scopes, e.g. session, request etc.
If for example you implement web store and need curt implementation session scope is what you need. If however you support special parameters that are sent for each request separately you probably want to use request scope for this purpose.
But beans that access database, perform authentication, send email or SMS, do other business logic can and should be implemented using singleton scope.
Please pardon this Spring beginner question. I am reading chapter 4 of first edition and being introduced to both call-back method and Bean post processor.
Now I am just getting confused about the two, it seems like they both do sth. when the bean instance is created, so how can I differentiate the two? Maybe an example would be good?
My personal understanding is, if we have to find a difference, then call-back method is initiated when the bean gets actually created, the Bean post processor gets called slightly after the creation of the bean?Also, I think the diference might also be that initalization call-back method focus on one bean only while Beanpost procsso will pocess all the bean instances one by one?
Also, could anybody help me further explain the difference by comaring and contrasting JSR250 annotation #PreDestroy and #PostConstruct with the two concepts above?
Thank you very much for helping!
It's been a while since I've used either of these, but I think the callback method and #PostConstruct methods you are referring to are the same thing. But to answer your question, the difference....
1) The #PostConstruct (or afterPropertiesSet) method is a method internal to a specific class that will be called after a bean is instantiated. This is really where you put type-specific actions.
2) The BeanPostProcessor will touch all Spring beans. So here's where you can put cross-cutting functionality, not necessarily class-specific.
A small example... say I have a small address book application for keeping track of my friends and their addresses. If I have some crazy bug I can't track down, I might use a BeanPostProcessor to wrap all my Spring beans with some logging, such as "now invoking Address.getStreet()..., now invoking Address.getCity()...".
Now I might use a #PostConstruct method in Address to verify and look up zip codes against some web service for addresses where I only have city/state.
Now, I might not actually have one of my domain objects hitting a web service in reality, but the idea is to illustrate that a #PostConstruct can handle class specific stuff and a BeanPostProcessor can take care of things that span multiple classes.
Also it's worth noting, that BeanPostProcessor has two methods to override: postProcessBeforeInitialization and postProcessAfterInitialization, which will let you decide what to run before and after the bean's #PostConstruct method.
Bean post processors interface has two callback methods: 1. PostProcessBeforeInitialization and PostProcessAfterInitialization.
PostProcessBeforeInitialization method is invoked just before calling your init-method or afterPropertySet method of the bean.
PostProcessAfterInitialization method is just called after just after the initialization of bean completed.
Bean Post Processors gives chance to do something before and after initialization of bean.
I'm in the situation where I need to create a cache to store certains values which need to be updated from the database. Since this cache needs to be singular, some sort of singleton implementation seems appropriate.
The problem is that this cache also needs access to the database via an EJB, which can't be injected since the cache exists outside of context (and yes, I'm looking forward to the #singleton annotation in EJB3.1).
The obvious solution is to pass the EJB into the cache as a parameter, but passing EJBs outside of context feels wrong, though I can't say why. Is it accepted practice?
Do note that you are normally not passing the EJB itself "outside of context". What you are typically passing around is a 'stub'. This stub can be passed around as any other normal object reference. Any calls on it will redirect back to an actual bean instance in the EJB container.
So if you have a cache in say the web module, have a backing bean injected with an EJB (or do a JNDI lookup) and pass that reference to a (static) cache, then I don't see a fundamental problem with that.
For all intends and purposes, the #Singleton annotation was indeed made for something like this. Hope you'll able to use it soon ;)
The main advantage of EJB is inside container. If you pass it outside you loose all the advantages which a container provide. Why don't you create a method in EJB that return the data you need. And the you can do, for example, JNDI lookup and call that method. In this way EJB will stay in the container and you will get your data.