Re: Shutdown an embedded instance of OpenEJB programatically
On Aug 2, 2008, at 3:23 PM, David Blevins wrote: We could probably wrap this up into a better package and allow it to be called from the initialContext.close() method so you don't have to have any OpenEJB code in your test case. Ok. I implemented the initialContext.close() logic. It only works on the InitialContext, calling close on any subcontexts will do nothing. As well it only works on the initialContext that booted OpenEJB, subsequent initialContext only refer to the already booted OpenEJB and therefore have to authority/ability to shutdown the container. Give it a try if you get the chance. New snapshots are being uploaded as we speak. I have noticed an ActiveMQ shutdown issue (doesn't fully shutdown so restart is not possible), but aside from that it should be pretty functional. -David
Re: Shutdown an embedded instance of OpenEJB programatically
On Mon, 2008-08-04 at 15:44 -0700, David Blevins wrote:
On Aug 4, 2008, at 5:41 AM, Martin Vysny wrote:
On Sat, 2008-08-02 at 15:23 -0700, David Blevins wrote:
On Jul 30, 2008, at 12:34 AM, Martin Vysny wrote:
Hello,
currently we are starting OpenEJB as an embedded service (by
performing a lookup of
org.apache.openejb.client.LocalInitialContextFactory in JNDI
InitialContext). Is there a way to perform a clean shutdown of this
embedded instance? We are using OpenEJB in testing environment and I
need to shutdown OpenEJB cleanly, for example to stop uncanceled
timers.
Hi Martin,
If you don't mind being tied to some OpenEJB code you could try
something like this:
import org.apache.openejb.loader.SystemInstance;
import org.apache.openejb.assembler.classic.Assembler;
import org.apache.openejb.assembler.classic.AppInfo;
import org.apache.openejb.OpenEJB;
public class Shutdown {
public static void shutdown() throws Exception {
Assembler assembler =
SystemInstance.get().getComponent(Assembler.class);
for (AppInfo appInfo : assembler.getDeployedApplications()) {
assembler.destroyApplication(appInfo.jarPath);
}
OpenEJB.destroy();
}
}
We could probably wrap this up into a better package and allow it to
be called from the initialContext.close() method so you don't have to
have any OpenEJB code in your test case.
Let me know if this does the trick for you and we'll get the cleaner
version in.
-David
Hi David,
thanks for the solution, it works for me! The timers are canceled
correctly in our project now. However the shutdown code is not perfect
yet. Out of curiosity I tried the following scenario: start OpenEJB,
stop it and start it again in the same VM. The following exception was
thrown:
[stacktrace attachment]
This is probably just a corner case (I can't imagine why would anyone
need to start, stop and start the OpenEJB again in same VM :), it's
just
for the sake of completeness.
Thanks, Martin! I'll definitely get that issue cleaned up.
David, I must thank you, for your quick answers and solutions! It's
really a pleasure to work with OpenEJB being backed by such a good
helpdesk :-) Thank you!
In fact, we are adding a close() method to the EJB 3.1 API version
(getting a good embeddable EJB container requirement into the EJB 3.1
spec is one of my top priorities), so this is good feedback. You're
right on the bleeding edge! :)
This is most interesting! Do you mean that all heavyweight J2EE servers
(which are to be compliant to EJB 3.1) will be available as embeddable
containers as well? Or I misunderstood and the close() method will only
allow remote control of the container?
My thoughts for adding a close() method was basically for @Singleton
beans as the @PreDestroy method is only called when the container is
shutdown, but canceling timers is definitely another good reason. If
you see it mentioned in the EJB 3.1 spec, you can know definitively
you're responsible :)
Wow, I might get my salary increased :-p
-David
signature.asc
Description: This is a digitally signed message part
Re: Shutdown an embedded instance of OpenEJB programatically
On Aug 5, 2008, at 12:36 AM, Martin Vysny wrote: On Mon, 2008-08-04 at 15:44 -0700, David Blevins wrote: Thanks, Martin! I'll definitely get that issue cleaned up. David, I must thank you, for your quick answers and solutions! It's really a pleasure to work with OpenEJB being backed by such a good helpdesk :-) Thank you! It's users like you who make things better for everyone. Each question and request helps pave the way for future users. Case in point, I'm pretty sure you were the first person to ask about getting OpenEJB 3.0 beta 1 and Hibernate working together. Every current and future OpenEJB/Hibernate user owes you thanks in one form or another. No small contribution. In fact, we are adding a close() method to the EJB 3.1 API version (getting a good embeddable EJB container requirement into the EJB 3.1 spec is one of my top priorities), so this is good feedback. You're right on the bleeding edge! :) This is most interesting! Do you mean that all heavyweight J2EE servers (which are to be compliant to EJB 3.1) will be available as embeddable containers as well? Exactly. Pretty amazing isn't it? When we launched OpenEJB off as an embeddable EJB container years ago we never dreamed that it would cause this kind of a change. We couldn't be more excited or more proud. My thoughts for adding a close() method was basically for @Singleton beans as the @PreDestroy method is only called when the container is shutdown, but canceling timers is definitely another good reason. If you see it mentioned in the EJB 3.1 spec, you can know definitively you're responsible :) Wow, I might get my salary increased :-p Let's hope so :) Course I'll expect a beer in return. -David
Re: Shutdown an embedded instance of OpenEJB programatically
On Aug 4, 2008, at 5:41 AM, Martin Vysny wrote:
On Sat, 2008-08-02 at 15:23 -0700, David Blevins wrote:
On Jul 30, 2008, at 12:34 AM, Martin Vysny wrote:
Hello,
currently we are starting OpenEJB as an embedded service (by
performing a lookup of
org.apache.openejb.client.LocalInitialContextFactory in JNDI
InitialContext). Is there a way to perform a clean shutdown of this
embedded instance? We are using OpenEJB in testing environment and I
need to shutdown OpenEJB cleanly, for example to stop uncanceled
timers.
Hi Martin,
If you don't mind being tied to some OpenEJB code you could try
something like this:
import org.apache.openejb.loader.SystemInstance;
import org.apache.openejb.assembler.classic.Assembler;
import org.apache.openejb.assembler.classic.AppInfo;
import org.apache.openejb.OpenEJB;
public class Shutdown {
public static void shutdown() throws Exception {
Assembler assembler =
SystemInstance.get().getComponent(Assembler.class);
for (AppInfo appInfo : assembler.getDeployedApplications()) {
assembler.destroyApplication(appInfo.jarPath);
}
OpenEJB.destroy();
}
}
We could probably wrap this up into a better package and allow it to
be called from the initialContext.close() method so you don't have to
have any OpenEJB code in your test case.
Let me know if this does the trick for you and we'll get the cleaner
version in.
-David
Hi David,
thanks for the solution, it works for me! The timers are canceled
correctly in our project now. However the shutdown code is not perfect
yet. Out of curiosity I tried the following scenario: start OpenEJB,
stop it and start it again in the same VM. The following exception was
thrown:
[stacktrace attachment]
This is probably just a corner case (I can't imagine why would anyone
need to start, stop and start the OpenEJB again in same VM :), it's
just
for the sake of completeness.
Thanks, Martin! I'll definitely get that issue cleaned up.
In fact, we are adding a close() method to the EJB 3.1 API version
(getting a good embeddable EJB container requirement into the EJB 3.1
spec is one of my top priorities), so this is good feedback. You're
right on the bleeding edge! :)
My thoughts for adding a close() method was basically for @Singleton
beans as the @PreDestroy method is only called when the container is
shutdown, but canceling timers is definitely another good reason. If
you see it mentioned in the EJB 3.1 spec, you can know definitively
you're responsible :)
-David
