I want to test an enterprise java bean (that should later be deployed to a JBoss server) using JUnit. But I don't exactly know how tools I can use for this. Plain JUnit fails because of the missing EJB Container and the caused lack of needed injections.
Googling a bit around lead me to a library called JBoss EJB embedded container, but it seems that it is obsolete. I also couldn't find any source or binary files to download.
So please help, what's a easy way to locally generate a "mock" container that is able to run the JUnit tests on the enterprise beans?
Greetings
Ben
I suggest you to have a look at Arquillian:
Arquillian enables you to test your business logic in a remote or embedded container. Alternatively, it can deploy an archive to the container so the test can interact as a remote client.
There is still a living Embedded JBoss AS. The Seam Framework also provides a testing environment with an embedded JBoss to run component tests (with TestNG) of your application.
openEJB is an embedded EJB container that's a perfect fit for unit testing EJBs. You can test them outside your normal app server. And, it's fast! And, it spins up fast! And, it has an Eclipse plugin for easy management! Gotta love it! It's been around for a while, there are plenty of tutorials on how to set it up and use it, so you shouldn't have problems with it.
You can use a EJB remote client in your JUnit program to test your EJB. Only drawback is that you have to have a running Application Server during testing.
Check out this blog entry for an example on how to invoke a EJB remotely.
It's been awhile, but I always wrote my EJBs as simple wrappers of POJOs. An interface would define the methods, and both the POJO and the EJB (session, of course) would implement that interface.
I could fully test the "business logic" of the POJOs without any container issues. Then if I had the server running, I could run the same tests against the session bean, just by testing against the client instead of the POJO...
Since I did not need the JNDI stuff (e.g. Cannot instantiate class: org.jnp.interfaces.NamingContextFactory) altogether in my DAO (ORM interface) tests it was enough for me to
include the hibernate jars in the classpath
remove/outcomment the <jta-data-source>...</jta-data-source> part in my persistence.xml
inject/assign your own entitymanagerfactory with Persistence.createEntityManagerFactory( "my-persistence-unit-name" )
Related
This is what I did right now, when I create a EJB bean, I have to manually copy the interface.java to client project. This is really not a good idea when you make a change to your interface. So I am thinking I should create a seperate interface project for both EJB and EJB client. In eclipse, how can i do this?
Thank you.
Create a separate Java project and put the interface(s) in there. Then you can have your EJB and client projects depend on that one. Depending on what you use to do your builds (Ant, Maven, etc) you'll need to do some work to make sure things are built correctly.
We have ".sar"(Service Archive file) used in jboss. Currently we are planning to migrate the code to Weblogic.
Is there a way to deploy .sar files into weblogic.
If not directly possible, is there a work around where we can deploy the services on web logic.
In order to get the custom mbeans that are in the .sar you will need to repackage the contents as an .ear as a .sar is not standard Java EE deployment mechanism - that is a JBoss proprietary archive.
Here are some instructions on how to create, package and deploy your own service MBeans (JMX Beans) along with an example of how to use it.
https://blogs.oracle.com/WebLogicServer/entry/developing_custom_mbeans_to_ma
One thing you could do is to "substitute" or "emulate" the SAR Deployer, by creating, configuring and registering MBeans. That, AFAIK, could be done in two ways:
1) Using Standard Java EE components: that means on web tier you can use the init() method of a servlet (make sure that it is preloaded on startup) or, better, a ServletContextListener
2) Using WebLogic specific components. I'm talking about Startup classes. Simply register a startup class that creates, configures and registers your MBeans.
If you are using a web module, the first approach has the obvious advantage that you are using pure Java EE components. Although you are not using that, you can add a "dummy" web module only for doing that
Concerning what you have to do in those classes, you can choose a "from scratch" approach, by parsing the xml files that describe services and therefore manually create, configure and register MBeans or, if I remember well, the XMBeans from JBoss is something that can be reused outside JBoss but you need to check because I'm not sure
I'm using IBM RAD 7 (aka Eclipse 3.4) and WebSphere 7.
I have an EJB project that contains an #Stateless EntityService and an #Stateless EntityDAO and so on.
I have an Web project that contains a JAX-RS restful web service that looks up the EntityService with this JNDI URL:
ejblocal:entityEAR/entityEJB.jar/EntityService#com.test.EntityServiceLocal
That all works great.
My question is, what would be the "correct" way to write JUnit tests to test the EntityService and EntityDAO classes?
Since the system needs to be running in the WebLogic server to function, I thought I would get the app running, then launch the JUnit test which does a look up of the same JNDI that the web service is using, but I get an error:
Naming Manager ... getURLContext cannot find the factory for this scheme: ejbLocal
Any suggestions are useful, how should I approach writing JUnit tests?
If you're writing Unit Tests, then they shouldn't depend on the container (because they execute only in a JVM) so you can't do JNDI lookups in them. To test your EJB Beans and DAO's with JUnit a Mocking Framework (like EasyMock) can be a great help.
But if you're interested in testing the communication between your EJB's and your REST Services, then you need Integration Tests and I doubt JUnit can help you here. A popular tool for Integration Tests is Selenium, and you need a fully-functional container and enviroment for your tests to execute.
In general, JUnit is intended to write unit tests. Within unit test you verify work of a single component having single responsibility (at least it should have single responsibility :))- all dependencies are mocked somehow (easymock, mockito and so on).
Dependency injection used in EJB simplifies this process - you can instantiate bean in your unit test setUp() method using new operator (you don't need container) and then, inject mocked dependencies (the same way container injects real dependencies).
This is the approach I use. The other thing are integration tests, which verifies entire scenario - starting from webservice (or other remote facade method) call, through beans logic, up to the DB queries. However, in such case you don't verify components standing after webservice/facade. Just webservice output for the specific input.
The good approach is to write test first (failing at the beginning) and then, write the implementation to satisfy it. For unit tests (single bean, tests not run within container) I'd recommend JUnit and EasyMock/Mockito. For integration tests you can use Selenium or JUnit+OpenEJB as a form of simple container for tests (especially if you have remote facade in a form of EJB component). Also, using tools like SoapUI you can create entire tests scenarios for your webservice - post some data, get them, modify, put, againg get, delete and so on.
At the end of the day, I implemented a #Remote remote interface for the Service classes I wanted to test, and did a remote JNDI lookup to the service bean.
More details here:
how to write a JUnit test that can see my EJB service?
After reading about it for so long, I now have chance to get my hand dirty with EJB. I use Glassfish+Eclipse 3.7 on Ubuntu.
I first created an EJB that just returns a greeting message. Then I create the application client to access this EJB using InitialContext. This works exactly like expected.
Then, I created a servlet to access to that EJB. Neither access with #EJB nor InitialContext works.
When I use #EJB, the 404 page appear with this description: "The requested resource () is not available."
When I use InitialContent, an ClassNotFoundException is thrown. Apparently, the class loader of the servlet cannot access to the EJB class. I tried to add EJB jar file to the servlet's lib folder and I got the error message that the JNDI name already exists. Apparently, Glass Fish tries publish the EJB in the Servlet's lib folder too.
The only way to get this to work is to publish the EJB with the servlet. This way, both I can get the servlet and a stand-alone application to access to that EJB. The problem is that I need to always employ the servlet with the EJB which is not desirable since my client may not want to use web front end.
Anyway, my question is what is appropriate way to have the servlet access to the EJB employed outside its class loader without repeatedly publishing the EJB.
P.S. It is also possible that the problem might be the way Eclipse configure and employ those components.
Thank a lot for any helps.
Perhaps you need to treat the EJB component as if it were remote. And maybe it really is since you don't give a lot of detail on how you are deploying. Try the directions at http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#nonJavaEEwebcontainerRemoteEJB.
A few pointers:
you may need to put the webapp and the ejb-jar in an .ear (enterprise application) and deploy it to glassfish
you may need the remote interfaces on the classpath of the webapp (if they are not available at runtime, but they were at compile time, you can't expect it to work)
NetBeans is generally better with enterprise stuff and wizards for creating and deploying applications. Give it a try.
After try out a while, I found that I can do by referring it as "/". This even works with injection.
How do I use a deployed EJB app from a separate JSF application?
I'm attempting to separate the two applications and access the EJB through the remote interface. To do this I have two eclipse projects - one contains the EJB and persistence logic, tested independently and works. I then created a JSF project that references the EJB project (so I gain access to the remote interface), however this fails when attempting to either inject the EJB instance or lookup the JNDI name (I've tried several variants to no avail). This is what my JSF backing bean contains:
#EJB(lookup="java:global/LocEJB/LocalityEJB!com.ame.business.LocalityEJBRemote")
private LocalityEJBRemote locality;
This is on Glassfish, and I am only referencing the EJB project and not packaging it with the JSF project. When I do the latter, I receive error initializing EJB container problems on the JSF project. So, how do I access the remote EJB and does the way I'm approaching this make any sense?
Thanks in advance!
Your JSF application has to know about the EJB interfaces (at least they did on EJB 2.0). You're using the Proxy pattern to hide the fact that this is a remote component from your JSF client.
First of all you can not use Local interface if trying to access outside the container. You must use Remote Interface.
You can define your Remote interface in the sun-web.xml or EJB injection in the bean.
sun-web.xml code:
<ejb-ref>
<ejb-ref-name>com.xxx.session.UserRemote</ejb-ref-name>
<jndi-name>corbaname:iiop:127.0.0.xxx:3700#com.xxx.session.UserRemote</jndi-name>
</ejb-ref>
Another thing you must have Remote interfaces in your classpath.