EJB design: Init of Bean on EJB-deployment
I´m working on a backend of a system, and in this backend there are parts/beans that, as an example, will make some checks every 30 minutes.
- Posted by: Johan Persson
- Posted on: September 20 2004 08:44 EDT
These parts should be independant of any events from clients using the backend and start working directly after the beans are deployed.
I have tried to find a good way of doing this using EJB but I have not been able to find a way of letting a Bean initialize itself on its deployment.
The solutions that I have found is to have these parts run as normal Java-applications and communicating with the rest of the system using some for of RPC, and the second solution that I have found is to manually have a client make the init-call.
None of these really appeal to me. There must be a better way?
- Init of Bean on EJB-deployment by Sohail Sikora on September 20 2004 09:34 EDT
- Init of Bean on EJB-deployment by Johan Persson on September 20 2004 09:45 EDT
Init of Bean on EJB-deployment by Sohail Sikora on September 20 2004 11:36 EDT
Init of Bean on EJB-deployment by Johan Persson on September 20 2004 11:50 EDT
Init of Bean on EJB-deployment by Arun Nair on September 21 2004 06:20 EDT
Init of Bean on EJB-deployment by Johan Persson on September 21 2004 07:47 EDT
- Init of Bean on EJB-deployment by Arun Nair on September 21 2004 08:03 EDT
- Init of Bean on EJB-deployment by Johan Persson on September 21 2004 07:47 EDT
- Init of Bean on EJB-deployment by Arun Nair on September 21 2004 06:20 EDT
- Init of Bean on EJB-deployment by Johan Persson on September 20 2004 11:50 EDT
- Init of Bean on EJB-deployment by Sohail Sikora on September 20 2004 11:36 EDT
- Init of Bean on EJB-deployment by Johan Persson on September 20 2004 09:45 EDT
- Why not try something more light weight? by Raymond Tay on September 22 2004 05:42 EDT
- Init of Bean on EJB-deployment by Manvendra Gupta on September 23 2004 10:58 EDT
http://radio.weblogs.com/0135826/2004/04/15.htmlshould help.Well, if I have not misunderstood the Timer Services, the problem with
initializing the Timed Object at the deployment time still remains.
You still have to let a client call a method that inits the timer service.
Or have a missed some important part again?
Can an EJB not function as a client and call another EJB? You maybe able to create a bean that will implement the timer service and call this bean from other beans. If my line of thinking is incorrect, do let me know.
Can an EJB not function as a client and call another EJB? You maybe able to create a bean that will implement the timer service and call this bean from other beans. If my line of thinking is incorrect, do let me know.Sure this is possible. But it does still not solve the actual problem. How is this EJB which function as a client created?
What I´m looking for is some way for a EJB to receive an event of its or the applications deployment.
Did you explore the possibilty of using a startup class (weblogic) or MBean (Jboss) to initialise/create a DEPLOYED Bean. I am not really sure that you able to get EJB Context on start-up. But if that possible, then creating an instance which triggers timer would be easy. I have written start-up for both WL and Jboss but never really looked into the actual calling time.
No I have not, but this sounds very interesting. Could you give an simple example of how to use MBean to init a Bean on deployment (or point me to the right class).
Look for 'Writing a Startup Class'. I am almost certain that startup classes can be configured to run as the last thing in the start process (by specifing the deployment order) but not sure about JBoss.
But before doing anything pls make sure that you could get the ejb context so that you can do a look up.
You can create the timer by either calling the EJB method in ServletContextlistener or a Servlet that is set with load-on-startup.
look at http://radio.weblogs.com/0135826/2004/09/21.html#a81
I have used startup classes in WLS 6.1, and I simply don't like it. The reason is that the startup code is executed outside the scope of the application. (I even had to define the class in a JAR file outside the application WAR file.) I don't know if this has been changed in later versions of WLS.
The method proposed by Debu is very nice and OK according to all specifications. Buyndle yopou EJB JAR with a WAR file to an EAR file. The WAR file will just have one Servlet without any URL mapping (means it cannot never be accessed) and the init method of this Servlet will call the EJB, and finally the EJB creates the timer. I strongly recommend this since it is fully J2EE compliant!
However, note that the timers in J2EE (EJB 2.1) are on business level. This means you will only start one timer in a cluster. So if you, for example, check for a timeout on a preliminary reservation, this will be excellent. On the other hand, if the purpose with the timer is to perform some technical stuff, flr example update a cache, you will run into trouble with the EJB 2.1 time solution. The reason is that the timer will execute on one node in a cluster. (Also note that the "I don't use clusters" argument does not apply. The application server is free to run in many JVMs, and then you will still get the problem since the cache will only be updated in one JVM.)
If the purpose of the timer is technical, I don't know any good solutions that are fully J2EE compliant. But there is a simple (and somewhat dirty) solution that works fine. Tell me if you need to know :-)
(I'm on a conference for two days, so I cannot reply until Thursday night.)
You can create the timer by either calling the EJB method in ServletContextlistener or a Servlet that is set with load-on-startup.look at http://radio.weblogs.com/0135826/2004/09/21.html#a81regardsDebu PandaOracleThanks for link. Right now I´m using JBoss and have implemented an MBean (Actually the same class as the EJB) which is called when the application is started as well as when its stopped. Quite nice but not totally portable so I will probably try the Servlet-approach instead.
But when using the MBean-approach I´m having problem getting hold of the EJB to initialize. I´m quite new to J2EE and EJBs but I´m guessing that it is because the MBean does not have the right Context.
In the start()-method of the MBean am I running:
Context initial = new InitialContext();
Object objref = initial.lookup("java:comp/env/ejb/Foo");
FooHome home = (FooHome)PortableRemoteObject.narrow(objref, Foo.class);
and I get "javax.naming.NameNotFoundException: env not bound"
If someone could help me solving this I would be eternaly grateful, even if
I will probably go with the Servlet-approach instead.
Why dont you try the quartz implementation? Here is the url http://www.quartzscheduler.org/
If you need to run tasks/jobs that run at a specific time, or repeated runs at a specific time, etc then i recommend that you evaluate this software.
Btw its FREE
I had a similar problem in the application I was developing. Needed to automatically initialize and start a poller when the application was deployed. I used a web application bundled into my EAR and had a servlet which set to load on startup. This web application was listed last in application.xml so that it gets loaded after all EJB modules have been loaded.
When the servlet init() method was called, i setup the poller. The poller uses the Quartz API and is triggered at the required intervals. The Poller as such is a pure Java code. But the Poller makes a call to my EJB to actually execute the required code. So the EJB itself is independent of any timing/init code. And Poller does not contain any logic/code of what is to be done.
I also needed to cleanly shutdown the poller. Now Weblogic undeploys the modules in the same order as they were loaded (and this is the order in which they appear in the application.xml). This implied that the my web application unloaded after my EJB and so I could not call the EJB to perform any cleanup operation. To solve this problem I created another webapp which had another servlet also set to load on start-up. This servlet doesnt have any init code but has code for destroy() method, which does the required clean-up. This web-app is listed first in the application.xml so that its the first one to be undeployed.
This scheme allows proper init/clean-up without depending on any weblogic specific code.
Although this does main 2 extra components need to developed and maintained, it seems the simplest and cleanest way to meet this kind of requirement.