Invoking EJB deployed on a remote machine

By -


Invoking EJB deployed on a remote machine

In case we are calling remote ejb( ejb deployed on remote machines),
The JNDI lookup might lookup like,

Properties env = new Properties();
  env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
  env.put(Context.PROVIDER_URL, "10.227.16.72:1099");  
  env.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces"); 
  Context ctx = new InitialContext(env);

If we are calling local ejb then we can simply create InitialContext without any parameters.

Like,
Context ctx = new InitialContext();


Using ENC JNDI to access EJBs 

IF we want to use ENC JNDI then the , in the lookup method the name of the JNDI passed is prefixed with java:comp/env/ so, if we wish to use ENC JNDI and access ejb Sidd
The JNDI name will look like java:comp/env/ejb/Fibo.

It is a good practice to use ENC JNDI, since it seperates configuration from coding. In case of ENC JNDI we have to put the entries in web.xml and jboss-web.xml



Reasons to USE ENC(Environment Naming Context:: java:comp/env) JNDI 

Some of the reasons why ENC JNDI is advocated ,

1) You can easily change Datasource, EJB without code modification.

For example:
1)- you want to change datasource for your application, thanks to ENC JNDI you
can do it without modifing code and recompiling, just edit xml file,

2) - you can write complete EJB and test it without complete design of whole
application (you don't have to know exact JNDI name of EJB),

 3) - It's easy to write GUI application for configuring J2EE applications -
everything is in XML files not in code.

4) Someone else writes the code and someone else configures. "Application
Assembler" and "Application Deployer and Administrator" theoretically even
don't have to know java.


Pseudo Code to get Home interface of and EJB using ENC JNDI


Context ctx = new InitialContext();
Object narrowFromObj = ctx.lookup(remoteHomeJndiName);
 remoteHome = (EJBHome) PortableRemoteObject.narrow(narrowFromObj,ejbRemoteHomeClass); 

where remoteHomeJndiName="java:comp/env/" +EJB_REF_NAME;

where EJB_REF_NAME is the <ejb-ref-name> EJB_REF_NAME </ejb-ref-name> defined in side web.xml





Lookup an EJB from a different application, deployed on the same server, in JBoss

In the web.xml of your war(the web application through which you want to access the EJB), have the following entry:
<ejb-ref>
  <ejb-ref-name>GiveAnyNameByWhichYouWouldLikeToReferTheBeanInYourWebApp</ejb-ref-name>
  <ejb-ref-type>session</ejb-ref-type>
  <home>packageName.ClassNameOfTheHomeObjectOfTheBeanYouWantToRefer
</home>
  <remote>packageName.ClassNameOfTheRemoteObjectOfTheBeanYouWantToRefer</remote>
  </ejb-ref>
 
  In the jboss-web.xml of your war, have the following entry:
 
  <ejb-ref>
  <ejb-ref-name>GiveAnyNameByWhichYouWouldLikeToReferTheBeanInYourWebApp(This should be same as the one given in the web.xml above)
</ejb-ref-name>
  <jndi-name>TheJndiNametoWhichTheBeanIsBound(Example:somecontext/somejndiName)YouWillFindThisJndiNameInTheJboss.xmlOfTheEJB</jndi-name>
  </ejb-ref>
  In your code, do the lookup as:
 
  Context ic = new InitialContext();
  Object ejbHome = ic.lookup("java:comp/env/TheNameThatYouHadGivenInTheEJB-REF-NAMETagOfJbossWeb.xmlAbove");
Here's an example:
web.xml:
<ejb-ref>
  <ejb-ref-name>MyTestBean</ejb-ref-name>
  <ejb-ref-type>session</ejb-ref-type>
  <home>com.test.ejb.MyBeanHome</home>
  <remote>com.test.ejb.MyBeanRemote</remote>
  </ejb-ref>
jboss-web.xml:
 <ejb-ref>
  <ejb-ref-name>MyTestBean</ejb-ref-name>
  <jndi-name>myejb/test/MyTestBean</jndi-name>
 </ejb-ref>
 
Lookup code:
Context ic = new InitialContext();
  Object ejbHome = ic.lookup("java:comp/env/MyTestBean");



Comments

Post a Comment

Popular posts from this blog

Difference between volatile and synchronized

By -
volatile is a field modifier, while synchronized modifies code blocks and methods. So we can specify three variations of a simple accessor using those two keywords: int i1; int geti1() {return i1;} volatile int i2; int geti2() {return i2;} int i3; synchronized int geti3() {return i3;} geti1() accesses the value currently stored in i1 in the current thread . Threads can have local copies of variables, and the data does not have to be the same as the data held in other threads. In particular, another thread may have updated i1 in it's thread, but the value in the current thread could be different from that updated value. In fact Java has the idea of a "main" memory, and this is the memory that holds the current "correct" value for variables. Threads can have their own copy of data for variables, and the thread copy can be different from the "main" memory. So in fact, it is possible for the "main"
Read more

Converting Java Map to String

By -
Java Collections framework, String manipulation etc is something that we often encounter in Development process. For processing collections (like checking null/empty, Intersection, Disjunction) We do have some of the very use full libraries. Some of the Collection related libraries are Apche Commons Collections and Google  Collections(Guava). Problem Use Case This article explains how to convert a Java Map to String(and vice versa) using different libraries and technique. One way is to use StringBuilder(Or String) and loop though the Map and build the String by applying some sort of separator ( for key:value and entry). Here we have to take care of the null value etc. Without Any Library If we want to convert the map to a String with key value separator and also individual entry seperator in the resulting String, we have to write code for that. For a simple Map, we have to iterate though the map, take care of the null values etc. Following is a sample to get String built
Read more

Masking Credit Card number in Java

By -
Sometimes we need to mask crucial information like Credit Card Numbers, CVV numbers etc before storing  or logging the information. This example mask Credit Card Number (Except last 4 Digit) from a Text which contains information along with Credit Card Number. The following example demonstrates how we can easily mask the credit card with Matcher and Pattern Classes. This Sample Code uses Matcher and Pattern. Pattern Used in this sample is not optimized for Credit Card Numbers, this pattern will get any numerical numbers in the String Content.  Based on the Credit Card Type a more efficient and Strict RegEx can be used to mask the Credit Card. /**Mask the Credit card number but last four digit value **/   Pattern PATTERN = Pattern.compile( "[0-9]+" ); String message = content; Matcher matcher = PATTERN.matcher(message); String maskingChar = "*"; StringBuilder finalMask = new StringBuilder(maskingChar);
Read more