![]() | ![]() | ![]() | ![]() | ![]() | ![]() | |||||||||||||||||||||||||||||||||
![]() | ![]() | ![]() | ![]() | |||||||||||||||||||||||||||||||||||
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | |||||||||||||||||||||||||||||||||
![]() | ![]()
|
Accessing EJBs locally Passing initialization parameters The conf directory gotcha Embedded OpenEJB FAQ ![]() ![]() Accessing EJBs locallyIf you wish to access ejbs locally and not in client/server mode, for example if your application is a server or other middleware, you can do so by embedding OpenEJB as a library and accessing ejbs through OpenEJB's built-in IntraVM (Local) Server. In this case, your application, server, or other middleware accesses beans as you would from any other server. The server just happens to be running in the same virtual machine as your application. The server is thusly called the IntraVM Server, and, for all intense purposes, your application or server is an IntraVM Client. You may have read in the OpenEJB specification that you need to call OpenEJB's init method and the invoke method for all ejb calls thereafter. If you need to propagate a Transaction or Security context from your application to OpenEJB, this is true, otherwise none of this is necessary and you can simply access the IntraVM Server directly as an ordinary non-J2EE client does. Try something like this for a simple IntraVM (Local) Client: That would be the simplest spec compliant client you could create. If you don't care about spec compliance and just want to "cheat", you can do this: Now keep in mind, that is not spec compliant. Also keep in mind that we provide it as a convenience, so if there is something you don't like or think should be changed, send code. Passing initialization parametersWhen accessing OpenEJB in local (intra-vm) mode, the IntraVM server will instantiate OpenEJB for you. When it instantiates OpenEJB, it puts default values for the items in the Properties object OpenEJB needs to actually instantiate. If you want to pass OpenEJB specific parameters, you can do this in two ways: Refer to the OpenEJB Specification for information on the init method or the parameters you can pass to OpenEJB. Here is an example of passing the initialization parameters in to OpenEJB via the first InitialContext creation. I stress, this is only applicable the very first time and InitialContext is created within your Virtual Machine. After that, OpenEJB will have been initialized and the parameters will be ignored. The conf directory gotchaWe are working on functionality that will allow you to set a openejb.home system variable, then you can execute clients anywhere you want. This is partially implemented now and is used to resolve relative paths using the openejb.home to create absolute paths. This, unfortunately, has not been implemented to work for configuration files yet. For now, you have to move *all* the files to your conf directory. Yes, this bites. Eventually all the default.* files will be packed in the jar and retrieved from there. If you want to help out with this functionality, great! Email the development list and we'll have you coding in no-time. Here is an example of how to workaround this. OpenEJB was unpacked in the directory in c:\dir\openejb, but, your app is executed from the directory c:\my\app. You need to copy the c:\dir\openejb\conf directory to c:\my\app\, giving you the new directory c:\my\app\conf. Then you can execute your app from the command line like this: c:\my\app> java MyEjbApplication You must also include the c:\dir\openejb\lib directory in your classpath. Also, if the beans in your app are the directory c:\my\app\my\beans, then you must add this line near the bottom of your OpenEJB configuration file: Embedded OpenEJB FAQWhy do I need so many OpenEJB specific files to implement a client?This is the bane you face when running OpenEJB in the same VM, you have to configure OpenEJB as well as your client. Any server has configuration files, you can't change that. When you run the server in the same vm as your application, you take on some additional responsibility. But as I mentioned, we are implementing some things to make even that "additional" responsibility more transparent. When your clients run OpenEJB in the same VM using the IntraVM Server, you're using OpenEJB as an embedded EJB Server just like InstantDB and Cloudscape are embedded databases servers. Just like InstantDB and Cloudscape, OpenEJB needs configuration files and other files to do it's job. OpenEJB is the only EJB server that I know of that you can run as an embedded library, so the fact that you can even do it is a real feather in our cap. If anyone knows of another, please tell me. In fact, anyone already using InstantDB or Cloudscape as embedded database servers in a product could just as easily use OpenEJB as an embedded EJB Server and add instant EJB support to the product as well. OpenEJB can easily play with InstantDB or Cloudscape, so it would be pretty slick. This would be extremely useful for IDEs like Visual Cafe, JBuilder, Visual Age, etc. What Security Service to I get?OpenEJB doesn't not come with a valid SecurityService, this has been considered the role of the application server vendor since the beginning of the project. However, no app servers have yet created a SecurityService as we had hoped. Months down the road, we will create a simple SecurityService provider if one is not contributed. OpenEJB can do without a server and use the IntraVM Server, but it still needs a SecurityService, therefore, a fake SecurityService implementation is used by default. This PseudoSecurityService just allows you to use OpenEJB without a valid security service, it basically says everyone is a valid user. | ![]() | |||||||||||||||||||||||||||||||||||
![]() ![]() | ||||||||||||||||||||||||||||||||||||||
![]() | ![]() | |||||||||||||||||||||||||||||||||||||
![]() | ![]() | |||||||||||||||||||||||||||||||||||||
![]() |