EJB reference

I try to a write a sample EJB to show HelloWorld
I finish EJB
but when I run the client
and it always can't find my EJB?
for example my EJB name is "hrApp"
in my ejb-jar.xml file, it contains <ejb-ref>
I try to create a file called application-client.xml
I add <ejb-ref> inside
but it's still fail
Can somebody help me where to set EJB reference?

Specify a t3 <jndi-name>
t3://<hostName_with_EJB>:<port_number>/JndiNameofEjb
For example:
<jndi-name>t3://localhost:7001/JndiNameofEjb</jndi-name>
[email protected] (xuang) wrote:
I have 2 ejb's , one CALLERejb and another CALLEDejb . Both of them is
deployed in difft weblogic server instances (no cluster , no admin
managed relation) , how can I use "ejb-reference-description" tag in
weblogic-ejb-jar.xml file to call the CALLEDejb from CALLERejb?
further I know that using rmi-iiop one can use the below .
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>someRefName</ejb-ref-name>
<jndi-name>corbaname:iiop:1.2@localhost:8001#JndiNameofEjb</jndi-name>
</ejb-reference-description>
</reference-descriptor>
But how do you do the same thing on plain t3?

Similar Messages

Could not lookup PortalManagerHome in the JNDI tree using EJB reference java:comp/env/ejb/PortalManager

Hi
I am just a starter on WLPortal.
I have created a barebone Application from scratch. I have synchronized it properly
from EBCC to WLP. But When I am trying to access the home page of my application,
I am getting from stack trace -
<Nov 6, 2002 5:37:59 PM IST> <Error> <PortalAppflow> <Could not lookup PortalManagerHome
in the JNDI tree using EJB reference java:comp/env/ejb/PortalManager.
javax.naming.NameNotFoundException: Unable to resolve comp/env/ejb/PortalManager
Resolved: 'comp/env' Unresolved:'ejb' ; remaining name 'PortalManager'
at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:802)
at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode.java:209)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:173)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:181)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:181)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:323)
at weblogic.jndi.factories.java.ReadOnlyContextWrapper.lookup(ReadOnlyContextWrapper.java:36)
at weblogic.jndi.internal.AbstractURLContext.lookup(AbstractURLContext.java:124)
at javax.naming.InitialContext.lookup(InitialContext.java:350)
at com.bea.p13n.util.JndiHelper.lookupNarrow(JndiHelper.java:96)
at com.bea.portal.appflow.PortalAppflowHelper.<clinit>(PortalAppflowHelper.java:64)
at com.bea.portal.appflow.servlets.internal.PortalWebflowServlet.init(PortalWebflowServlet.java:78)
at javax.servlet.GenericServlet.init(GenericServlet.java:258)
at weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubImpl.java:700)
at weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStubImpl.java:643)
at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:588)
at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:368)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:242)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:215)
at weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:112)
at jsp_servlet.__index._jspService(__index.java:92)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:304)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2459)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2039)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
>
<Nov 6, 2002 5:37:59 PM IST> <Error> <HTTP> <[WebAppServletContext(19695286,FirstWebApp,/FirstWebApp)]
Servlet failed with Exception
java.lang.NullPointerException:
at com.bea.portal.appflow.PortalAppflowHelper.createPortalManager(PortalAppflowHelper.java:82)
at com.bea.portal.appflow.servlets.internal.PortalWebflowServlet.setupPortalRequest(PortalWebflowServlet.java:187)
at com.bea.portal.appflow.servlets.internal.PortalWebflowServlet.doGet(PortalWebflowServlet.java:99)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:215)
at weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:112)
at jsp_servlet.__index._jspService(__index.java:92)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:304)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2459)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2039)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
When I decompiled the class PortalAppflowHelper, I found a static block in it,
which was as under-
static
debug = Debug.getInstance(com.bea.portal.appflow.PortalAppflowHelper.class);
try
if(debug.ON)
debug.out("Looking up PortalManagerHome using EJB reference java:comp/env/ejb/PortalManager");
portalManagerHome = (PortalManagerHome)JndiHelper.lookupNarrow("java:comp/env/ejb/PortalManager",
com.bea.portal.manager.ejb.PortalManagerHome.class);
if(debug.ON)
debug.out("Successfully retrieved PortalManagerHome " + portalManagerHome);
catch(Exception e)
PortalAppflowLogger.errorFindingPortalManagerHome("java:comp/env/ejb/PortalManager",
e);
I have checked the PortalManager's JNDI name on WLConsole. Its ${APPNAME}.BEA_portal.PortalManager.
Should I change it?
When I tried to change it, I started getting other weird errors.
Thanks
Neeraj Hans

Neeraj -
The Portal framework code (including PortalAppflowHelper) uses ejb
references to find the PortalManager (and other EJBs) from servlets and
taglibs; that is what is signified by the java:comp/env/... name.
Since you built your webapp from scratch (instead of using the portal
wizard), you will need to make sure the you have the appropriate
<ejb-ref> entries in your web.xml, and the corresponding
<ejb-reference-description> entries in your weblogic.xml. By default,
you will need at least mappings for:
- ejb/PortalManager
- ejb/UserManager
- ejb/GroupManager
- ejb/PipelineExecutor
- ejb/EventService
See either the resulting webapp from using the portal wizard or
BEA_HOME/weblogic700/samples/portal/sampleportalDomain/beaApps/sampleportal/sampleportal/WEB-INF
for example syntax.
Greg
Neeraj Hans wrote:
Hi
I am just a starter on WLPortal.
I have created a barebone Application from scratch. I have
synchronized it properly
from EBCC to WLP. But When I am trying to access the home page of my
application,
I am getting from stack trace -
<Nov 6, 2002 5:37:59 PM IST> <Error> <PortalAppflow> <Could not lookup
PortalManagerHome
in the JNDI tree using EJB reference java:comp/env/ejb/PortalManager.
javax.naming.NameNotFoundException: Unable to resolve
comp/env/ejb/PortalManager
Resolved: 'comp/env' Unresolved:'ejb' ; remaining name 'PortalManager'
at <stack trace lines snipped>
When I decompiled the class PortalAppflowHelper, I found a static
block in it,
which was as under-
static
debug =
Debug.getInstance(com.bea.portal.appflow.PortalAppflowHelper.class);
try
if(debug.ON)
debug.out("Looking up PortalManagerHome using EJB
reference java:comp/env/ejb/PortalManager");
portalManagerHome =
(PortalManagerHome)JndiHelper.lookupNarrow("java:comp/env/ejb/PortalManager",
com.bea.portal.manager.ejb.PortalManagerHome.class);
if(debug.ON)
debug.out("Successfully retrieved PortalManagerHome "
+ portalManagerHome);
catch(Exception e)
PortalAppflowLogger.errorFindingPortalManagerHome("java:comp/env/ejb/PortalManager",
e);
I have checked the PortalManager's JNDI name on WLConsole. Its
${APPNAME}.BEA_portal.PortalManager.
Should I change it?
When I tried to change it, I started getting other weird errors.
Thanks
Neeraj Hans

J2EE JNDI-00009 EJB Reference "ejb/SessionEJBCalled" could not be resolved

When load (run) the following EJB (JDev 10.1.3.1.0 embedded server) loads with no problem:
package project2;
import javax.ejb.Stateless;
@Stateless
public class SessionEJBCalledBean implements SessionEJBCalledLocal {
public SessionEJBCalledBean() {    }
public void display() { System.out.println("In called - Project2");   }
When load the following, only difference is name attribute for the @Stateless annotation:
package project2;
import javax.ejb.Stateless;
@Stateless(name="SessionEJBCalled")
public class SessionEJBCalledBean implements SessionEJBCalledLocal {
public SessionEJBCalledBean() {    }
public void display() { System.out.println("In called - Project2");    }
Get the following error message - Why?
2006-08-24 15:48:54.640 WARNING J2EE JNDI-00009 EJB Reference "ejb/SessionEJBCalled" could not be resolved. Allowing J2EEContext creation to continue anyway
Finally - If I specify the name as per the following all is well:
package project2;
import javax.ejb.Stateless;
@Stateless(name="SessionEJBCalledBean")
public class SessionEJBCalledBean implements SessionEJBCalledLocal {
public SessionEJBCalledBean() {    }
public void display() { System.out.println("In called - Project2");   }
Would be appreciated if someone could tell me what is going on?
Thanks - Ken

When load (run) the following EJB (JDev 10.1.3.1.0 embedded server) loads with no problem:
package project2;
import javax.ejb.Stateless;
@Stateless
public class SessionEJBCalledBean implements SessionEJBCalledLocal {
public SessionEJBCalledBean() {    }
public void display() { System.out.println("In called - Project2");   }
When load the following, only difference is name attribute for the @Stateless annotation:
package project2;
import javax.ejb.Stateless;
@Stateless(name="SessionEJBCalled")
public class SessionEJBCalledBean implements SessionEJBCalledLocal {
public SessionEJBCalledBean() {    }
public void display() { System.out.println("In called - Project2");    }
Get the following error message - Why?
2006-08-24 15:48:54.640 WARNING J2EE JNDI-00009 EJB Reference "ejb/SessionEJBCalled" could not be resolved. Allowing J2EEContext creation to continue anyway
Finally - If I specify the name as per the following all is well:
package project2;
import javax.ejb.Stateless;
@Stateless(name="SessionEJBCalledBean")
public class SessionEJBCalledBean implements SessionEJBCalledLocal {
public SessionEJBCalledBean() {    }
public void display() { System.out.println("In called - Project2");   }
Would be appreciated if someone could tell me what is going on?
Thanks - Ken

Why to use EJB Reference

hi all,
when i have an enterprise application with a session bean and a webapp,
i can access the session bean either over an ejb-reference in the webapp or directly access the jndi entry. what is the advantage of using ejb references? here an example of what i mean (both from within a webapp):
ctx.lookup("myBean"); // without ejb ref
ctx.lookup("java:comp/env/ejb/myRef"); // with ejb ref
I get back the same, so whats the difference?
rgds

With ejb-reference a container optimizes access to collocated beans. For example, say you have a deployment where beans A and B are both replicated in two different containers, for performance and/or availability reasons. For optimal use every instance of A in container would use instances of B also in container one. Likewise for container two. An EJB container can enforce this locality constraint using ejb-links, but not always using direct JNDI names.

EJB references

I have a small j2ee app (ear file).. It is working fine with Orion server..
I want to deploy this app on wl6 but I have some problems with the JNDI
context..
I am using the j2ee recomandation (5.3.1.1 Programming interfaces for EJB
references) but my client gets an - javax.naming.NameNotFoundException:
java:comp; remaining name ''
Client.java file
Object homeObject = context.lookup("java:comp/env/ejb/mybean");
weblogic-ejb-jar.xml file
<jndi-name>ejb/mybean</jndi-name>
jndi.properties file (used by the client)
java.naming.provider.url=t3://localhost:7001
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
Bogdan Ghidireac

J2EE clients are components that are deployed much like EJB components. The client deployer is the class weblogic.ClientDeployer. It takes an ear file and the name of the client, say foo, and expects a jar file for that client in the ear file, i.e., foo.jar, and a runtime XML file in the current directory, i.e., foo.runtime.xml. The runtime XML is compatible with the reference implementation. I am including an example.
<resource-ref>
<res-ref-name>jdbc/DB1</res-ref-name>
<jndi-name>oracle/bigbox</jndi-name>
</resource-ref>
<ejb-ref>
<ejb-ref-name>ejb/External</ejb-ref-name>
<jndi-name>my/favorite/bean</jndi-name>
</ejb-ref>
<env-entry>
<env-entry-name>interval</env-entry-name>
<env-entry-value>100</env-entry-value>
</env-entry>
This relates component local names, i.e., java:/comp/jdbc/DB1 and java:/comp/ejb/External, to global JNDI names in the target server for this deployment. It also specifies a binding for java:/comp/env/interval.
The deployment results in a launchable jar file in the current directory, i.e, foo.jar. It is launched with weblogic.j2eeclient.Main, which takes the launchable jar, i.e., foo.jar, and the server URL. Any additional arguments are passed on to the main program of the J2EE client component.
Anno
"Bogdan Ghidireac" <[email protected]> wrote in message news:[email protected]..
I have a small j2ee app (ear file).. It is working fine with Orion server..
I want to deploy this app on wl6 but I have some problems with the JNDI
context..
I am using the j2ee recomandation (5.3.1.1 Programming interfaces for EJB
references) but my client gets an - javax.naming.NameNotFoundException:
java:comp; remaining name ''
Client.java file
Object homeObject = context.lookup("java:comp/env/ejb/mybean");
weblogic-ejb-jar.xml file
<jndi-name>ejb/mybean</jndi-name>
jndi.properties file (used by the client)
java.naming.provider.url=t3://localhost:7001
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
Bogdan Ghidireac
[att1.html]

Passing EJB reference to other Thread

Hi,
If I have EJB reference, can I pass it to other thread safely?
COM had concept of Apartments to handle thread problems and we had to marshal the interfaces if passed to another thread.
What we do in EJB? Is there any concept like apartments that is hidden?
Thanks,
Unmesh

Within the appserver, EJBs should not be doing anything with threads.
If we are talking about an external app (ie: a client GUI) holding references, then yes these can be passed around between threads freely.

EJB Reference Configuration

Hi,
I have 2 ears say Ear1 and Ear2 for my application,which are deployed in clusters.Ear2 is having Ejb which is being called from Ear1. EJB reference is required for communication between Ear2 and Ear1.i am setting the below value to Target Resource JNDI Name: corbaloc::ClusterServer1:2810,:ClusterServer2:2810/cell/clusters/Cluster1/ejb/com/mycompanyName/projectName/ejb/facade/EjbFacadeHome But i am getting the below error
Caused by: javax.naming.ServiceUnavailableException: A communication failure occurred while attempting to obtain an initial context with the provider URL: "corbaloc::mums00100251.in.net.intra:2810,:mums00100392.in.net.intra:2810/cell/clusters/Cluster1/ejb/com/bnpparibas/tradefinance/ejb/facade/EjbFacadeHome". Make sure that any bootstrap address information in the URL is correct and that the target name server is running.
Please help.
Regards:
Akash

Hi,
I have 2 ears say Ear1 and Ear2 for my application,which are deployed in clusters.Ear2 is having Ejb which is being called from Ear1. EJB reference is required for communication between Ear2 and Ear1.i am setting the below value to Target Resource JNDI Name: corbaloc::ClusterServer1:2810,:ClusterServer2:2810/cell/clusters/Cluster1/ejb/com/mycompanyName/projectName/ejb/facade/EjbFacadeHome But i am getting the below error
Caused by: javax.naming.ServiceUnavailableException: A communication failure occurred while attempting to obtain an initial context with the provider URL: "corbaloc::mums00100251.in.net.intra:2810,:mums00100392.in.net.intra:2810/cell/clusters/Cluster1/ejb/com/bnpparibas/tradefinance/ejb/facade/EjbFacadeHome". Make sure that any bootstrap address information in the URL is correct and that the target name server is running.
Please help.
Regards:
Akash

EJB Reference Not In IntitialContext

I have a jsp which accesses a stateless session bean which in turn accesses an entity bean.
The reference to the session bean is in the initial context but the entity bean reference is not (I have printed out the entire initial context to verify this).
When I deploy the application it does say that it is binding both the session bean and the entity bean.
(ie. binding "java:comp/env/ejb/<Name>" for both)
Any ideas as to why the ejb reference doesn't exist in the initial context?
FYI: I am using the J2EE app server and the deploy tool. I have checked the xmls and there is an ejb-ref in it for the entity bean.

You should say wheter the entity bean is referenced by the session bean, that is, in the deploytool:
1) select the session bean.
2) select the EJB Refs tab.
3) enter "ejb/YourEntityBean", "Entity" and the interfaces used. "ejb/YourEntityBean" should be as appears in your session bean code.
4) select the EJB jar. (the beans owner)
5) in the JNDI tab you will see this new entry in "References", here you put the JNDI name of your bean as appears bellow in "EJBs"

Caching EJB references

Hi all,
I was wondering if anyone could give me a conclusive explanation regarding the caching options for EJB objects(SLSB, and Entity Beans), both home/remote and localHome/local.
I have read a lot of various EJB documentations including a fairly thorough look into the spec, and have about 2 years of practical expirience with EJBs.
The matter that is still vague to me after all this time is the matter of caching and reusing EJB references. practical expirience and some documentation lead me to believe that caching an EJB reference of any kind is hazardous. From what I saw the spec never adresses this issue in a straightforward conclusive manner. It does discuss some failover scenarios and the use of EJB handles as both optionally a persistent reference and a "long living" refernce, but never in a context that is "spec mandatory" and "encapsulates" the whole picture.
Now, there is no fundamental difference between caching a reference or using one that is locally scoped in a single method, except the time it is expected to be "alive", which is, by definition, a relative and unmeasurable matter.
Theoretically, I am sure there is no problem implementing references, which are actually client "proxies", stubs, in a way that will not be dependent of an exact instance, but rather on an abstract EJB ID(which may indeed cause a performance overhead).
Anyway, I don't want to get into implementation details, I am simply looking for a clear explanation about the matter of "long living" references, and what is mandatory by EJB specification.
Thanks for any insights....
I also crossposted to EJB forum -> http://forum.java.sun.com/thread.jsp?forum=13&thread=538526&tstart=0&trange=15

A locally scoped reference is only on the stack while the cached reference is on the heapOf course, but in the context of what I'm talking about here, that doesn't really matter. The point is that in both cases there is a reference to an EJB object/home, that is used for a longer/shorter time.
I think the main reason for not caching the references is that is interfere's with the server's ability to manage it's resources. OK, sounds reasonable enough. So why doesn't the specification provide clear rules, even restrective ones that say no caching can be applied? Looks to me as if it would be safe to say that home objects for example are safe to cache working with any EJB server as long as the EJB server isn't restarted. Why isn't it written anywhere?
It always refers to Handles as "long living" references. How can one measure "long"?
Now, I may have gotten the wrong picture. Maybe there are some widely agreed issues on this matter, for example that caching SLSB as you've mentioned, and home objects is always safe in the scope of an EJB server life time(from the point in which it starts to the point it goes down).
The thing is, where ever I looked I saw different strategies, and never it was clear what exactly they came to solve. For instance, an EJBHome service locator that caches the home object as is, vs. a service locator that caches the home handle.

External ejb reference error

Again WLS 8.1 SP1
i write by hand the weblogic.xml descriptor with the reference information for
an external ejb and im sure it's correct, but when i try to compile it with appc
it fails with this exception
Element "<ejb-jar>" with ejb-ref-name "xyz" must either specify a valid ejb-link
element or have corresponding ejb-reference-descriptor element in weblogic.xml
with a valid jndi-name.
This is my reference in weblogic.xml file
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>CnCargaFacade</ejb-ref-name>
<jndi-name>ejb.CnCargaFacade</jndi-name>
</ejb-reference-description>
</reference-descriptor>
of this web.xml
<ejb-ref>
<ejb-ref-name>CnCargaFacade</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>load.ejb.CnCargaFacadeHome</home>
<remote>load.ejb.CnCargaFacade</remote>
</ejb-ref>
This is not only if a try to use appc (which is not really necesary) but the error
is also when i try to deploy the application on my server.
Is this a Bug?? i thik it is, or where i'm wrong
Thanks

I believe it will solve both. In this case, appc and the server are
sharing some common code with a bug.
-- Rob
eric velazquez wrote:
Thanks for your time
Just one more question, this patch will solve too the deployment issue? or just
the appc compiler issue.
Thanks again
Rob Woollen <[email protected]> wrote:
Unfortunately I believe this is an appc bug. You should be able to get
a temporary patch from [email protected] Reference CR112803.
-- Rob
eric velazquez wrote:
Again WLS 8.1 SP1
i write by hand the weblogic.xml descriptor with the reference informationfor
an external ejb and im sure it's correct, but when i try to compileit with appc
it fails with this exception
Element "<ejb-jar>" with ejb-ref-name "xyz" must either specify a validejb-link
element or have corresponding ejb-reference-descriptor element in weblogic.xml
with a valid jndi-name.
This is my reference in weblogic.xml file
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>CnCargaFacade</ejb-ref-name>
<jndi-name>ejb.CnCargaFacade</jndi-name>
</ejb-reference-description>
</reference-descriptor>
of this web.xml
<ejb-ref>
<ejb-ref-name>CnCargaFacade</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>load.ejb.CnCargaFacadeHome</home>
<remote>load.ejb.CnCargaFacade</remote>
</ejb-ref>
This is not only if a try to use appc (which is not really necesary)but the error
is also when i try to deploy the application on my server.
Is this a Bug?? i thik it is, or where i'm wrong
Thanks

Question about using ejb remote home vs ejb reference

hi guys
i am new to EJB and want to understand the difference between these two. i notice that the ejb reference is declared in the ejb-jar.xml so that the calling ejb can get the home object by using
initCtx.lookup("java:comp/env/ejb/CabinHome");which is declared in
<ejb-ref>
<description>Cruise ship cabin</description>
<ejb-ref-name>ejb/CabinHome</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>com.titan.cabin.CabinHome</home>
<remote>com.titan.cabin.Cabin</remote>
<ejb-link>CabinBean</ejb-link>
</ejb-ref>how does this differ from using the JNDI to get the home interface. which one is preferred?
thanks for your help.

Right, portable Java EE applications always access resources via their component environment rather than doing a direct global JNDI lookup. Declaring the ejb dependency provides a level of indirection that allows it to be mapped to the appropriate target ejb in each application server without requiring any code changes. The same principle is used for other kinds of component dependencies such as data sources, queues, etc.
The downside to this in J2EE 1.4 and earlier was the overhead/complexity of declaring the ejb-ref/ejb-local-ref in the deployment descriptor. Java EE 5 improves this by introducing environment annotations such as @EJB that make it easy to declare the dependencies. In Java EE 5, @EJB is equivalent to ejb-ref/ejb-local-ref but doesn't require the use of .xml.
The bottom line is if you're writing code that's running within a Java EE component, always access Java EE resources/dependencies through your component environment or use an environment annotation.
--ken

EJB Reference could not be resolved (javax.naming.NameNotFoundException)

I am new to EJBs and am trying to get a simple Java client to run which I've generated from a EJB3.0 session bean.
The code for the client (LoanAppFacadeClient.java) is
package buslogic;
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
public class LoanAppFacadeClient {
public static void main(String [] args) {
try {
final Context context = getInitialContext();
LoanAppFacade loanAppFacade = (LoanAppFacade)context.lookup("java:comp/env/ejb/LoanAppFacade");
// Call any of the Remote methods below to access the EJB
// System.out.println( loanAppFacade.getLoans( ) );
loanAppFacade.addLoan( "Galactic Loans", 30, "fixed", 6.25 );
String ssn = "123-12-1234";
System.out.println(loanAppFacade.getCreditRating( ssn ));
} catch (Exception ex) {
ex.printStackTrace();
private static Context getInitialContext() throws NamingException {
Hashtable env = new Hashtable();
// Standalone OC4J connection details
env.put( Context.INITIAL_CONTEXT_FACTORY, "oracle.j2ee.naming.ApplicationClientInitialContextFactory" );
env.put( Context.SECURITY_PRINCIPAL, "oc4jadmin" );
env.put( Context.SECURITY_CREDENTIALS, "welcome1" );
env.put(Context.PROVIDER_URL, "ormi://localhost:23791/LoanApp");
return new InitialContext( env );
When the trying to run the client I get a warning:
"WARNING: EJB Reference "ejb/LoanAppFacade" could not be resolved."
followed by the error
"javax.naming.NameNotFoundException: java:comp/env/ejb/LoanAppFacade not found in Lab1_BusinessServices-app-client"
When the client was created I right-clicked on the session bean (LoanAppFacadeBean which implements LoanAppFacade) and chose New Sample Java Client.
This automatically creates the java client and also created the following xml file (application-client.xml)
<?xml version = '1.0' encoding = 'windows-1252'?>
<application-client xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application-client_1_4.xsd" version="1.4" xmlns="http://java.sun.com/xml/ns/j2ee">
<display-name>Lab1_BusinessServices-app-client</display-name>
<ejb-ref>
<ejb-ref-name>ejb/LoanAppFacade</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<remote>buslogic.LoanAppFacade</remote>
<ejb-link>LoanAppFacade</ejb-link>
</ejb-ref>
</application-client>
Could someone please help me to fix these errors?
Thanks,
Andrew

I used windows for years whereby I stored all photos in folders. As macs don't use this concept I am finding it hard to organize my photos.
You can do this on your Mac too. Just don't use iPhoto. But iPhoto is a lot more flexible.
For instance:
I usually sort them by month so when I say move to an album I mean I create an album called for example '2013 March' so I can easily find specific photos/videos.
Click on the Magnifying Glass lower left to reveal the search box. Then click on the magnifying glass in the search box, and select Date. Now you can instantly find all the photos from a particular month, or day.
File -> New Smart Album will allow you to create an automatic album for any date or date range you choose.
Select one of the affected videos in the iPhoto Window and go File -> Reveal in Finder -> Original. A Finder Window should open with the file selected. Does it play?

What is the difference between ejb reference and ejb handle?

Hi:
I am newbie for J2EE.
I want to know what is the difference between ejb reference and ejb handle
from the client view and from the container view?
Very Thanks!
Stive

Hi John,,
1) Ejb Object Handle are nothing but a long lived proxy for the
ejb object, using this handle user can disconnect from the Ejb Server/Container
at any time
and after some time using the same handle he can able to resume the conversational
state
with the server / container where he was been disconnected From.
And there are currently two Handles , HomeHandle and Handle for EjbHomeObject
and EjbObject
Respectively. Both these handles have Persistent reference to the EJB Object
2) Ejb Reference is used to lookup a bean from other Enterprise Bean
Ejb reference is a nickname for the JNDI Location that you want to lookup a bean.
your code will looks up a Home object via using this nickname
and the deployer will bind the
nickname to the JNDI location of its choice
EJb Reference are declared in the deployment descriptor
Regards
Karthikeyan Gangadharan
SIP Technologies, Chennai
E-mail-ID : [email protected]
"John Stive" <[email protected]> wrote:
>
Hi:
I am newbie for J2EE.
I want to know what is the difference between ejb reference and ejb
handle
from the client view and from the container view?
Very Thanks!
Stive

Ejb-reference-description question

I have 2 ejb's , one CALLERejb and another CALLEDejb . Both of them is
deployed in difft weblogic server instances (no cluster , no admin
managed relation) , how can I use "ejb-reference-description" tag in
weblogic-ejb-jar.xml file to call the CALLEDejb from CALLERejb?
further I know that using rmi-iiop one can use the below .
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>someRefName</ejb-ref-name>
<jndi-name>corbaname:iiop:1.2@localhost:8001#JndiNameofEjb</jndi-name>
</ejb-reference-description>
</reference-descriptor>
But how do you do the same thing on plain t3?

Specify a t3 <jndi-name>
t3://<hostName_with_EJB>:<port_number>/JndiNameofEjb
For example:
<jndi-name>t3://localhost:7001/JndiNameofEjb</jndi-name>
[email protected] (xuang) wrote:
I have 2 ejb's , one CALLERejb and another CALLEDejb . Both of them is
deployed in difft weblogic server instances (no cluster , no admin
managed relation) , how can I use "ejb-reference-description" tag in
weblogic-ejb-jar.xml file to call the CALLEDejb from CALLERejb?
further I know that using rmi-iiop one can use the below .
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>someRefName</ejb-ref-name>
<jndi-name>corbaname:iiop:1.2@localhost:8001#JndiNameofEjb</jndi-name>
</ejb-reference-description>
</reference-descriptor>
But how do you do the same thing on plain t3?

Sharing EJB references.

Hi,
I have two JSP pages which use the same EJB. Both pages are doing their own JNDI lookup for the home interface and do a home.create to obtain the remote interface. The two pages are thus not "sharing" the same reference to the EJB.
To speed up EJB access, I would have preferred to be able to share the remote reference in session or application scope (=normal stateless EJB behaviour) but unfortunately Oracle does not support the stateless model.
1) Can I share the same EJB reference between all webserver sessions to avoid the lookup/create penalty? (ie place it in "application" scope)
2) Failing that, can I share the same EJB reference between all requests in the same session (ie place it in "session" scope)?
3) In both cases above (or in any other way), can I prevent blocking if an EJB comes across a locked record (see thread "Preventing blocking: EJBs").
Cheers
Nic
null

I think you might have some fundamental EJB stuff confused. First we would need to know what kind of EJBs you are using. Stateful session, stateless session, entity? With stateless session you need not worry about cleaning up. The client has no control over when the ejbRemove method is called (when the EJB is placed in an inactive state). In fact, it may be called between method calls. In either case, you needn't worry about it. If you are using stateful session beans, I would ask why you are using the HttpSession with them. Stateful session beans provide this functionality for you. If you are using entity beans, there are more things to consider such as CMP/BMP. A short answer without more information is not possible.
If you have a cluster of machines, or plan on it, putting the remote reference in the session may not actually help performance as binding it to the session will cause the remote reference to be replicated around the cluster.
If you check the EJB specification, the container is not required to call the ejbRemove method when a client calls the remove method on the remote interface for a session bean. (I assume you are using session since calling remove on an entity will remove the data from the database.) So I would ask what exactly you are trying to accomplish by that call?
I'll venture a guess that the call, in your case, is unnecessary. If I have assumed something incorrectly, please post more information.
Hope this helps.

EJB reference

Similar Messages

Maybe you are looking for