MyPage is a personalized page based on your interests.The page is customized to help you to find content that matters you the most.


I'm not curious

Using JNDI and JPA for J2EE Container- Free Code Testing

Published on 03 November 14
471
0
0

JPA Code testing is considered as one of the most crucial activities performed during implementation of JPA Code patterns. Irrespective of the method you choose for testing the JPA code, you need to ensure that the final code is free from all sorts of bugs. In this article, I'll be discussing about testing the JPA code using the JNDI and JPA. I hope by the end of this article, you, as a renowned Java Development Service provider will be all geared up for testing your JPA code in a hassle-free way.


What's with JPA Configuration?

Well, testing JPA code is a simple process, with no use of the application server or any J2EE container. A basic JPA Configuration requires two crucial things viz: a database for storing the data and JNDI for accessing the respective database. JPA includes two types of objects including the domain objects and the data access objects(DAO's). Since domain objects aren't tied to the JPA, you can easily choose to test their functionality without using a JPA container.


Using standalone JNDI and an embedded in-memory database for testing JPA code

Whether you've chosen to hire Java programmer or want to perform JPA Code testing by yourself, JNDI is the perfect solution. The standalone JNDI solution for testing the JPA code comes with three specific API classes as mentioned below:

> JNDIUtil- This class comprises of JNDI initialization along with some convenience methods.

> InMemoryDBUtil
- This class is used for database and data source creation/removal.

> AbstractTestCase
- This class is used for a database clean up way before the first test and the JNDI clean up prior to each test.

A brief on how the test is performed

Every JPA test case that has been extended from the AbstractTestCase will drop the database before the very first test. Also, it would install standalone JNDI and run Liquibase changelog against the database well before each JPA code testing process.


A walk through basic usage of JNDI

JNDI actually allows the clients to store and search for data and objects via a specific name. All the data that's being stored into the database is being accessed via a seamless implementation of the interface Context. Mentioned below is the code that's used for storing data in JNDI:


Context ctx = new InitialContext();

ctx.bind("jndiName", "value");

ctx.close();


And now, here's the code used for searching data within JNDI:

Context ctx = new InitialContext();

Object result = ctx.lookup("jndiName");

ctx.close();


A bit about Context Factories

All the real context that would work throughout the JPA testing process needs to be created a context factory. Well, context factory is basically a section that displays the technique of creating a context factory, followed by configuring the InitialContext method for using the same. It is crucial to ensure that each context factory implements InitialContextFactory interface has no-argument constructor as shown in the below code snippet:


package org.meri.jpa.jndi;

public class MyContextFactory implements InitialContextFactory {

@Override

public Context getInitialContext(Hashtable environment) throws NamingException {

return new MyContext();

}

}


While on one hand the Initial context uses the NamingMAnager for creating a real context, the naming manager itself has a static method called getInitialContext(Hashtable env) that returns an instance of the context, with the env parameter including the configuration properties that are used for building the context.

Summary

So, that was a detailed insight into testing the JPA code without the usage of a JPA Container. Hope these details would serve as a handy guide during your next JDP code testing venture.
















JPA Code testing is considered as one of the most crucial activities performed during implementation of JPA Code patterns. Irrespective of the method you choose for testing the JPA code, you need to ensure that the final code is free from all sorts of bugs. In this article, I'll be discussing about testing the JPA code using the JNDI and JPA. I hope by the end of this article, you, as a renowned Java Development Service provider will be all geared up for testing your JPA code in a hassle-free way.

What's with JPA Configuration?

Well, testing JPA code is a simple process, with no use of the application server or any J2EE container. A basic JPA Configuration requires two crucial things viz: a database for storing the data and JNDI for accessing the respective database. JPA includes two types of objects including the domain objects and the data access objects(DAO's). Since domain objects aren't tied to the JPA, you can easily choose to test their functionality without using a JPA container.

Using standalone JNDI and an embedded in-memory database for testing JPA code

Whether you've chosen to hire Java programmer or want to perform JPA Code testing by yourself, JNDI is the perfect solution. The standalone JNDI solution for testing the JPA code comes with three specific API classes as mentioned below:

> JNDIUtil- This class comprises of JNDI initialization along with some convenience methods.

> InMemoryDBUtil
- This class is used for database and data source creation/removal.

> AbstractTestCase
- This class is used for a database clean up way before the first test and the JNDI clean up prior to each test.

A brief on how the test is performed

Every JPA test case that has been extended from the AbstractTestCase will drop the database before the very first test. Also, it would install standalone JNDI and run Liquibase changelog against the database well before each JPA code testing process.

A walk through basic usage of JNDI

JNDI actually allows the clients to store and search for data and objects via a specific name. All the data that's being stored into the database is being accessed via a seamless implementation of the interface Context. Mentioned below is the code that's used for storing data in JNDI:

Context ctx = new InitialContext();

ctx.bind("jndiName", "value");

ctx.close();

And now, here's the code used for searching data within JNDI:

Context ctx = new InitialContext();

Object result = ctx.lookup("jndiName");

ctx.close();

A bit about Context Factories

All the real context that would work throughout the JPA testing process needs to be created a context factory. Well, context factory is basically a section that displays the technique of creating a context factory, followed by configuring the InitialContext method for using the same. It is crucial to ensure that each context factory implements InitialContextFactory interface has no-argument constructor as shown in the below code snippet:

package org.meri.jpa.jndi;

public class MyContextFactory implements InitialContextFactory {

@Override

public Context getInitialContext(Hashtable environment) throws NamingException {

return new MyContext();

}

}

While on one hand the Initial context uses the NamingMAnager for creating a real context, the naming manager itself has a static method called getInitialContext(Hashtable env) that returns an instance of the context, with the env parameter including the configuration properties that are used for building the context.

Summary

So, that was a detailed insight into testing the JPA code without the usage of a JPA Container. Hope these details would serve as a handy guide during your next JDP code testing venture.

This blog is listed under Development & Implementations and Networks & IT Infrastructure Community

Post a Comment

Please notify me the replies via email.

Important:
  • We hope the conversations that take place on MyTechLogy.com will be constructive and thought-provoking.
  • To ensure the quality of the discussion, our moderators may review/edit the comments for clarity and relevance.
  • Comments that are promotional, mean-spirited, or off-topic may be deleted per the moderators' judgment.
Awards & Accolades for MyTechLogy
Winner of
REDHERRING
Top 100 Asia
Finalist at SiTF Awards 2014 under the category Best Social & Community Product
Finalist at HR Vendor of the Year 2015 Awards under the category Best Learning Management System
Finalist at HR Vendor of the Year 2015 Awards under the category Best Talent Management Software
Hidden Image Url

Back to Top