aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes JNDI issue Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "JNDI issue" Watch "JNDI issue" New topic
Author

JNDI issue

Goran Markovic
Ranch Hand

Joined: Sep 26, 2008
Posts: 399
Hi, just as you guess I new to EJB. I;m little confused about jndi reading.
I have this portion of code


Does that mean that ejb has performed jndi lookup from file test-ejb.jar, from the follow element :


if it is, is this code the equivalent to previous obtaining reference to DataSource:


And, if I right in both way, I'm just wondering where I define vendor specifics properties for DataSource, like :sort od database, username, password, pool size and stuff. Is it in persistence.xml unit, or also in the test-ejb.jar file???
Well,it's a lot of question but I believe that my understanding is well ( I hope so), so I just want to check it . Thanks you guys/girl in advance!
Reza Rahman
author
Ranch Hand

Joined: Feb 01, 2005
Posts: 580
    
    5
Slobodan,

The examples you provide are equivalent in terms of declaring a dependency. In the XML declaration case, you will need to do the JNDI look-up yourself, the container will not do automatic DI.

Container resources such as data sources are defined by application server tools. Typically, this will be a setting in a GUI console (GlassFish, WebLogic, WebSphere) or a vendor specific XML configuration file (like JBoss). You are welcome to take a look at the code examples for EJB 3 in Action for specific configuration.

Hope it helps,
Reza


Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Goran Markovic
Ranch Hand

Joined: Sep 26, 2008
Posts: 399
Hi Reza. I know that container perform lookup on its own, but Am I correct about logic that container perform? Is it <resource-ref> element where container reading from? I'm interesting in this because of situation when I need to perform manually lookup? Injection through annotation must be read from somewhere and get information to build an object, isn't it?
Reza Rahman
author
Ranch Hand

Joined: Feb 01, 2005
Posts: 580
    
    5
Slobodan,

The @EJB and @Resource annotations are short-hands for two operations when applied to a field or method - declaring a dependency and injecting the dependent resource. The XML dependency declaration is not needed unless you like XML, are doing a look-up yourself and don't want to depend on global JNDI names. Take a look here for details: https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html.

Hope it helps,
Reza
Goran Markovic
Ranch Hand

Joined: Sep 26, 2008
Posts: 399
Hi Reza
I know that about dependencies. Case study:
We have a stateful bean, which we need into web tier. According to specification, using DI for statful bean injection into servlet, isn't recommended because of thread safety issue.
It's advice to perform JNDI lookup.
I'm wondering what XML file we read from/perform lookup, for certain resource (it's not required to be beans). Is that testname-ejb.xml, file where we perform mapping of objects looked up later by JNDI? That is what bother me.
Reza Rahman
author
Ranch Hand

Joined: Feb 01, 2005
Posts: 580
    
    5
Slobodan,

I would simply look-up via the global JNDI name (being standardized in EJB 3.1) and not bother with XML. You can also use @EJB at the class level to declare the dependency if you want. Also, if you are using stateful session beans heavily, you should take a look at Seam.

Thanks,
Reza
Goran Markovic
Ranch Hand

Joined: Sep 26, 2008
Posts: 399
Ok Reza, thanks in your cooperation.
Goran Markovic
Ranch Hand

Joined: Sep 26, 2008
Posts: 399
from EJB3 in action :

@Resource(name="jdbc/actionBazaarDB",
type=javax.sql.DataSource.class)
private DataSource dataSource;


Here we (container) use DI to inject DataSource instance into variable (no matter we could also through setter). Here container actually perform jndi lookup on it own, instatntiate and inject instance. Also providing attribute 'type' we declare that instance should be of 'javax.sql.DataSource ' class. Am I right so far?
But here

@Resource(name="jdbc/actionBazaarDB")
public void setDataSource(DataSource dataSource) {
this.dataSource = dataSource;
}


We perform the same thing but we didn't provide 'type' attribute to define type of instance. As much as I understood, we should in test-ejb.jar,
In order to provide to the container information of what type our instance is going to be, is that correct? How could otherway container know what instance it need to inject, OR it KNOW that because our annotation is in front of the reference we need to inject ( I believe I figure out during writing is it correct)?
And when I want to perform by myself jndi look up, them I use


Where also, I've previously declare <resource-ref>element??

If al above true, Ifigure out. Still, I've sort of obscure glanse at class level declration.
This is quote from book:

To look up a resource from the helper class, you have to reference the
resource in the EJB class as follows:

@Resource(name="jdbc/actionBazaarDB",mappedName="jdbc/actionBazaarDS",
type=javax.sql.DataSource.class)
@Stateless
public class PlaceBidBean implements PlaceBid

You can look up the resource either from the EJB or the helper class as follows:

Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/ActionBazaarDB")


Does it mean that this lookup is perform also from PlaceBidBean (for DataSource instance)? This is that obscure place...
What is the purpose of [code]

@Stateless
public class PlaceBidBean implements PlaceBid

[/code if I perform on EJB and what is if I perform on Helper class?
Reza Rahman
author
Ranch Hand

Joined: Feb 01, 2005
Posts: 580
    
    5
Slodoban,

As I've explained before, the @EJB and @Resource annotations do *two* things:

1. It declares a component dependency:
- This means that the java:comp/env/ namespace is populated with the local (component private) name of the resource in addition to it's full global
JNDI name.
- In practice, the java:comp/env/ namespace is overkill and no one uses it in real life. It was designed for renaming a resource to something different
specific to an EJB component (sort of like a local alias to a global resource). This is hardly ever needed in real life. We are trying to kill the entire idea
in EJB 3.1 and simply standardize global JNDI names that people can use without needing to "declare" a dependency. This is some of the much hated
Sun over-engineering in play...
- You can also do this via XML if you want, as in your example. The XML just does declaration, not injection (see below).
2. It actually performs the injection if the annotations are placed on a field or method. If the annotation is at the class level, no actual injection happens, but you can look-up the resource from java:comp/env/ yourself. Mind you, the global JNDI reference is always available regardless of what you do.

In practice, no one uses @Resource and @EJB at the class level or uses the java:comp/env/ namespace. Everyone simply uses global JNDI look-ups and @EJB/@Resource for injection purposes only. I objected to Debu adding unnecessary confusion by introducing the java:comp/env/ namespace at all, but he did not listen and wanted to cover what was in the spec instead of what's useful in real life.

The explicit type declaration is only needed when in case of class level dependency declaration. Otherwise, the container can infer the type from the Java field or setter type.

Take a look here for some more details: http://forums.java.net/jive/thread.jspa?threadID=14497.

Hope it helps,
Reza
Goran Markovic
Ranch Hand

Joined: Sep 26, 2008
Posts: 399
Thanks Reza on your comprehend explanation. I hope any further question won't be, but I'm afraid that is inevitable
Best wishes.
Reza Rahman
author
Ranch Hand

Joined: Feb 01, 2005
Posts: 580
    
    5
Slodoban,

It's not a big deal. If the above pointers and further research still leave unanswered questions, I'll see what I can do.

Regards,
Reza
 
 
subject: JNDI issue