Regarding ENTITY bean local interfaces

Hi all,
I have a component session bean - containing a number of service methods for creating, retrieving, updating & deleting instances of a related entity bean. This session bean is used by another session facade bean, which invokes the various service methods in some sequence to complete a major task.
In the component session bean, the retireve methods return the local interface of the entity bean - on which it operates. The update methods accespt local interfaces of entity bean which can be directly updated.
My question is : Is it a right approach to pass the entity bean instances between method calls.
Thanks in advance,
Baskar

Your pointers regarding pt 2 was nice. Thanks.
This being my first J2ee design, I'am just collecting as much information as possible to stay confident.
Later, I started thinking a bit more regarding pt 1.
Where, I decided using individual session beans for different components(representing unique functionalities).
i.e,, I'am just thinking, should I use individual session beans for each of these different components.
What if I use standard java classes - implementing pre-defined interfaces for each of these components & use the components through these interfaces in session facade.
Now, I'll be using entity bean creates/retrieves/updates/deletes from inside normal java classes.
I thought, this would obviate the need for JNDI lookups - each time I want to use the components in my session facade.
But, I'am not sure of where this will impact..As far as I can visualize, this seems to be normal. Please share ...your thoughts regarding this. (something regarding transactions ??)

Similar Messages

EJB 3.0 Session bean local interface NullPointerException

I am trying a very simple test of a Stateless EJB 3.0 bean called from a servlet.
The bean has a local interface, annotated with @Local. The bean implements that interface and is annotated with @Stateless.
I have a servlet with a variable of the local interface type, annotated with @EJB. The servlet's doGet method invokes the bean's one method using that interface and it works fine.
BUT if I put the same variable, annotated with @EJB into another class in the web container, it is not injected correctly and I get a NullPointerException on the variable. This class is in WEB-INF/classes with the servlet class, so I assume it is loaded by the same classloader.
I don't understand why the servlet can instantiate the EJB local interface successfully but another class in the web container can't. I get the same result in OC4J standalone 10.1.3.1 and 10.1.3.3.

Only managed classes like servlets, filters etc. will have context and EJB references injected into them, and only with servlet version 2.5. A work colleague found the answer in Debu Panda's blog:
http://debupanda.blogspot.com/2006_10_01_archive.html#116184543992078773
This behaviour appears to be part of the EJB 3.0 standard.
The solution is to use JNDI lookup in the client class (POJO) and declare an ejb-local-ref in web.xml.

Using a CMP Entity Bean local stub as a field of another CMP Entity Bean

Hello,
Is it possible to implement a field of a CMP Entity bean as another CMP Entity bean and how is it done?
I've seen a pseudo code for this in Ed Roman's Mastering EJBs, second edition, but I can't seem to get it to work (pages: 330 - 1:1 using CMP and 339 - fake M:N using CMP).
I'm using SUN ONE Application Sever 7. Is this server capable of this?
I'm trying to implement a fake M:N relationship using 3 beans: 2 for each side of the relationship and one as the "bridge" table.
For example, the two beans on each side of the relationship are SubscriberBean, SubscriptionBean and the "bridge: bean is SubscriberSubscriptionBean. The SubscriberSubscriptionBean has two fields: SubscriberLocal stub and SubscriptionLocal stub.
Please let me know if you need more information to answer this question.
Thanks.
Nikola

Im sorry but i dont know about the example you are talking about. I kinda learn
all those techniques from forums, articles and tutorials because book often suffer from
not having the information im mostly looking for.
As far as i understand you, you want to implement a bridge been, which is representing a row in a join table. So that if one side of the relation is deleted the join-table entry (your bridge-CMP-Bean) is cascaded. Right?
First of all the simple part: (My approach)
- The joint table is foreign keys only - without a relation description. -
In this case you dont have to implement a bridge bean. Because it just wouldnt represent anything of sense.
Lets think of an entity/table USER whith the columns name (PRIMARY KEY), and prename.
Our second entity/table is ADDRESS with the columns road (PRIMARY KEY) and housenr.
The join table is simply: USER_ADDRESS with fk_name (FOREIGN KEY) and fk_road (FOREIGN KEY) both on CASCADE DELETE. So if the address is deleted the mapping entry is deleted, too same for the user part:
USER -> USER_ADDRESS <- ADDRESS.
Our entity Beans are called User and Address in class-names JNDI-names and names.
Now we want to create the CMR mapping so we can access the addresses of a user from the user bean directly. The methods on the user side are:
public abstract Collection getAddresses();
and
public abstract void setAddresses(Collection new_addresses);
the xdoclet comments on the User side are (for the getter only)
* @ejb.interface-method
* @ejb.relation
*                name = "User-has-Addresses"
*                role-name = "User-Addresses"
*                target-ejb = "Address"
*                target-multiple = "true"
* @sunone.relation
*                column="USER_ADDRESS.fk_name"
*                target="USER_ADDRESS.fk_road"
public abstract Collection getAddresses();
for the other side of the relation we define in the Address-Entity
public abstract Collection getUsers();
and
public void setUsers(Collection users);
the xdoclet comments on the Address side are (for the getter only)
* @ejb.interface-method
* @ejb.relation
*                name = "User-has-Addresses"
*                role-name = "Address-User"
*                target-ejb = "User"
*                target-multiple = "true"
* @sunone.relation
*                target="USER_ADDRESS.fk_road"
*                column="USER_ADDRESS.fk_name"
As we dont want the user or address to be deleted if the other side of the relation is deleted we dont specify cascade-delete="yes" in the ejb.relation namespace.
The sun-cmp-mappings.xml should now look like this:
(For the User - side)

<cmr-field-mapping>
<cmr-field-name>addresses</cmr-field-name>
<column-pair>
<column-name>USER_ADDRESS.fk_name</column-name>
<column-name>USER_ADDRESS.fk_road</column-name>
</column-pair>
</cmr-field-mapping>
and similar on the Address-Side:
<cmr-field-mapping>
<cmr-field-name>users</cmr-field-name>
<column-pair>
<column-name>USER_ADDRESS.fk_road</column-name>
<column-name>USER_ADDRESS.fk_name>/column-name>
</column-pair>
</cmr-field-mapping>
Dont forget that all elements in the Collection must be of the right Interface-type.
First of all the harder part:
Now what you might want is when the relation has some information specified like user live at address and is tenant or facility manager.
The, in the first step you will have to implement the UserAddressRelation entity which will have to CMR fields of the 1:N type.(Just as you wish)
Lets think of the example above extended by the relation type. Our relation bean is named UserAddressRelation.
Now User has the methods as above but the classes in the Collection must now be of the UserAddressRelationLocal/Remote interface and not AddressLocal/Remote-interface.
You will have to change the xdoclet comment to:
* @ejb.interface-method
* @ejb.relation
*                name = "User-has-Addresses"
*                role-name = "User-Address"
*                target-ejb = "UserAddressRelation"
*                target-multiple = "true"
* @sunone.relation
*                target="USER_ADDRESS.fk_name"
*                column="USER.name"
So we now dont reference the other side bean directly. We reference the relation EntityBean. Do the similar changes on the other side.
In particular you will have to specify 4 CMR mappings now:
1. User to UserAddressRelation 1:N
2. UserAddressRelation N:1
3. Address to UserAddressRelation 1:N
4. UserAddressRelation N:1
Which i dont want to explain in detail now because its kinda all the same as above.
Now you cann access the Addresses of a user in the way.
UserLocal.getAddresses(); <- !you get the mappings!
UserLocal.getAddresses().item(0).getAddress() <- you get the address (this is dirty coding just for understanding)
UserLocal.getAddresses().item(0).getUserRole() <. you get the role of the user at this address.
Hope this helped you. You are welcome to ask any detailed question.

Is there a better way of doing this? (regards Entity Beans, CMP, J2EE5...)

Hello everyone,
So I'm going to blurt out two classes of code. First is a plain entity bean and the second is a helper class with two static methods to help me to convert Object into byte[] and vice versa without much worrying.
Now the problem is, how to persist this entity bean and it's two Objects (two Lists) in a more "J2EE5 way". I just need to store these two Objects, or any Serializable Object, into persistent storage. So how to avoid this serialization by-hand that I'm doing... ?
Thank you for your interest - and help :),
Samuli
Maybe using a @Lob notation or such? I've tried, but I can't get it workign. @Lob itself is not enough since it results in casting problems when retrieveing the data back from the persistent storage.
And oh, I'm just using the simple CMP with this.. EJB using EntityManager's persist method to store and so on..
EntityBean class (imports and packages excluded)
@Entity
public class MessageHandlerChain implements java.io.Serializable {
    @TableGenerator(
        name="messageHandlerChainIDGenerator",
        allocationSize=1,
        initialValue=1
    @GeneratedValue(
        generator="messageHandlerChainIDGenerator",
        strategy=GenerationType.TABLE
    @Id
    private Integer messageHandlerChainID;
    @Lob
    private byte[] messageHandlers;
    @Lob
    private byte[] messageHandlerProperties;
    @Transient
    private List<String> messageHandlersObj = new ArrayList<String>();
    @Transient
    private List<Map<String,String>> messageHandlerPropertiesObj = new ArrayList<Map<String,String>>();
     * Constructs an empty instance of <code>MessageHandlerChain</code> without any properties.
    public MessageHandlerChain() {
    public Integer getMessageHandlerChainID() {
        return messageHandlerChainID;
    public void setMessageHandlerChainID(Integer messageHandlerChainID) {
        this.messageHandlerChainID = messageHandlerChainID;
    public List<String> getMessageHandlers() {
        return messageHandlersObj;
    public void setMessageHandlers(List<String> messageHandlersObj) {
        if (messageHandlersObj == null) {
            System.out.println("[MessageHandlerChain] setMessageHandlers() can't be given a null value.");
            return;
        this.messageHandlersObj = messageHandlersObj;
    public List<Map<String,String>> getMessageHandlerProperties() {
        return messageHandlerPropertiesObj;
    public void setMessageHandlerProperties(List<Map<String,String>> messageHandlerPropertiesObj) {
        if (messageHandlerPropertiesObj == null) {
            System.out.println("[MessageHandlerChain] setMessageHandlerProperties() can't be given a null value.");
            return;
        this.messageHandlerPropertiesObj = messageHandlerPropertiesObj;
    @PrePersist
     * This method is invoked by the persistence provider prior to every persist operation.
     * This is needed because we need to convert, serialize, our <code>@Transient</code> annotated objects into <code>byte[]</code> streams
     * so that they can be written into the database.
    public void prePersist() {
        System.out.println("[MessageHandlerChain] prePersist()");
        if (messageHandlerPropertiesObj != null)
            messageHandlerProperties = BlobConverter.objectToBytes(messageHandlerPropertiesObj);
        if (messageHandlersObj != null)
            messageHandlers = BlobConverter.objectToBytes(messageHandlersObj);
    @PostLoad
     * This method is invoked by the persistence provider after every load operation.
     * This is needed because we need to convert, deserialize, <code>byte[]</code> streams back to our <code>@Transient</code> annotated objects.
    public void postLoad() {
        System.out.println("[MessageHandlerChain] postLoad()");
        try {
            if (messageHandlerProperties != null)
                messageHandlerPropertiesObj = (List<Map<String,String>>)BlobConverter.bytesToObject(messageHandlerProperties);
            if (messageHandlers != null)
                messageHandlersObj = (List<String>)BlobConverter.bytesToObject(messageHandlers);
        } catch (ClassCastException e) {
            System.out.println("[MessageHandlerChain] postLoad() Class Cast Exception: "+e);
    public String toString() {
        return "[MessageHandlerChain] messageHandlerChainID="+getMessageHandlerChainID()+", messageHandlers="+getMessageHandlers()+", messageHandlerProperties="+getMessageHandlerProperties();
The helper class
* <code>BlobConverter</code> is a simple helper class to encode and decode classes as byte[] so that they can be stored into persistent storage.
* @author Samuli Piela
public class BlobConverter {
    public static byte[] objectToBytes(Object o) {
        ByteArrayOutputStream baos = new ByteArrayOutputStream(512);
        ObjectOutputStream oos = null;
        try {
            oos = new ObjectOutputStream(baos);
            oos.writeObject(o);
            return baos.toByteArray();
        } catch (InvalidClassException e) {
            System.out.println("objectToBytes("+o+"): Invalid Class: "+e);
        } catch (NotSerializableException e) {
            System.out.println("objectToByte("+o+"): Object not serializable: "+e);
        } catch (Exception e) {
            System.out.println("objectToBytes("+o+"): Exception: "+e);
        } finally {
            if (oos != null) {
                try {
                    oos.close();
                } catch (IOException e) {
                    System.out.println("objectToBytes(): Stream could not be closed: "+e);
            if (baos != null) {
                try {
                    baos.close();
                } catch (IOException e) {
                    System.out.println("objectToBytes(): Stream could not be closed: "+e);
            oos = null;
            baos = null;
        return null;
    public static Object bytesToObject(byte[] byteArray) {
        ByteArrayInputStream bais = new ByteArrayInputStream(byteArray);
        ObjectInputStream ois = null;
        try {
            ois = new ObjectInputStream(bais);
            Object o = ois.readObject();
            return o;
        } catch (ClassNotFoundException e) {
            System.out.println("bytesToObject(): Class not found: "+e);
        } catch (InvalidClassException e) {
            System.out.println("bytesToObject(): Invalid Class: "+e);
        } catch (IOException e) {
            System.out.println("bytesToObject(): IOException: "+e);
        } catch (Exception e) {
            System.out.println("bytesToObject(): Exception: "+e);
        } finally {
            if (ois != null) {
                try {
                    ois.close();
                } catch (IOException e) {
                    System.out.println("bytesToObject(): Stream could not be closed: "+e);
            if (bais != null) {
                try {
                    bais.close();
                } catch (IOException e) {
                    System.out.println("bytesToObject(): Stream could not be closed: "+e);
            ois = null;
            bais = null;
        return null;
}

anyone?

Regarding Entity bean

Does new version of OAS 4.0.8.1 or
JDeveloper 3.0 support Entity Bean .
Can anyone help me?
from Prashant

That blows. I've been really counting on Oracle to come through on at least the EJB 1.1 spec for OAS is not for 8.1.6. At the iSeminar I was informed it was available in beta with the release. This is getting disheartening as IBM has good all-around integrated support for the full standard but I've committed alot of time and energy to the Oracle platform.
Now I need to re-think that decision? That sucks.
Will :-\

Multiple instances of the same entity bean?

I am designing a J2EE application that is made up of a number of separate components that each have a well-defined responsibility. Each component is made up of one or more J2EE components (web clients and EJBs). I want to design the application such that it is easy in the future to deploy each component (or a group of components) on different servers. In order to do this I need to make sure that the interfaces between each component are exposed as remote interfaces (but I will use local interfaces inside each component). However, there are a number of entity beans that need to be accessed by more than one component. I am wondering how best to expose these entity beans. I believe there are a number of options:
1. Expose remote interfaces on each of the shared entity beans. The disadvantage of this approach is that it is inefficient and that I will not be able to take advantage of container managed relationships. (I am intending to use container managed persistence.)
2. Create a facade object (stateful session bean) for each of the entity beans which exposes a remote interface and in turn accesses the shared entity beans locally. The disadvantage of this approach is that I have to create some extra EJBs and that I cannot directly make use of container managed relationships etc from the client component.
3. I don't know if this is an option but I am wondering whether I can deploy a copy of each shared entity bean with each application component. The advantage of this approach is that the component would access the entity locally and could make use of container managed relationships. However, I don't know what the issues are with having more than one instance (per primary-key) of an entity in the same application. I don't know whether this would cause errors of whether they would get out of sync (because different instances with the same primary key would be updated by different clients). Initially each component would be deployed in the same server but later they would be deployed in different servers. In both cases with this option each component (JAR) would have copies of the shared entity bean classes.
Any suggestions as to the best approach and whether the last option is feasible would be much appreciated.
Thanks.

I think 2 beats 1. The main reason being to minimise the number of network calls. You're basically asking, are fascades a good idea? and the answer is yes.
You can obviously do 3 in different app servers. However you'll need to configure your app servers so they can handle the fact that they're not the only ones updating the database. This is to handle concurrency as you mentioned. How you do this will depend on your app server and will affect performance, but shouldn't be a problem.
I think you should definately decide up front what's going in different app servers, I dunno if 3 would work in the same app server.
Why do you would want to use multiple app servers?
Why not have everything in the same app?
Is is just the 1 database?
You can use clustering for scalability.

Setting composite key in Container Managed Entity Bean

In my database table i set primary key to two columns making them as composite key. how do i set that in my container managed entity bean home interface findByPrimaryKey() method and in deployment descriptor file.

1. create another class (say CompositePK) that will embed the two fields keyA and keyB corresponding to the two pk of your table (declare them public) .
2. in your Bean declare keyA and keyB public.
3. in the dd declare your bean primary-key-class as CompositePK and the primary-key-field as keyA and keyB.
this is the method i use (with BAS) even if the key is simple (such as Integer).

How to make a session bean interact with a entity bean?

hi,
An entity bean has been created and tested successfully. Values entered into the test app are successfully entered into the pointbase db.
Now trying to create the same feature through session beans. when the method is invoked, it appears ok, but when the database is queried the values have not been entered. Is there anything that could have been missed or incorrect?
the steps to setting up session bean
1)add code to create for JNDI lookup
public void ejbCreate() {
System.out.println("Entering oneManagerEJB.ejbCreate()");
Context c = null;
Object result = null;
if (this.myoneHome == null) {
try {
c = new InitialContext();
result =
c.lookup("java:comp/env/ejb/one");
myoneHome =
(oneHome)javax.rmi.PortableRemoteObject.narrow(result,
oneHome.class);
catch (Exception e) {System.out.println("Error: "+
e); }
2) add business method to enter values into entity bean
public void createone(int number) {
System.out.println("Entering ");
try {
one oneinfo =
myoneHome.create(number);
} catch (Exception e) {
// Join the following two lines in the Source Editor
System.out.println("Error in " + e);
// Join the following two lines in the Source Editor
System.out.println("Leaving ");
3) declare variables and namings
import javax.naming.*;
private oneHome myoneHome;
4) add reference to logical session bean
ejb/one
5) create test app and add entity bean "one" to module. check mappings.
run app

I would do several things which will help track down the problem:
1. Where you have println statements you may want to change these to exceptions, the session bean won't really work if these problems occur and may silently fail. For example, throw a runtime exeption or EJBException to indicate that the entity bean home interface cannot be found.
2. When you create the test application you should replace the ejb module which is automatically created with the ejb module or module(s) containing both of the ejb's. This will ensure that the configuration is preserved. The test application is a standard J2EE application, so modules can be added (you could even have multiple test applications each testing a different ejb, make sure that you use different context roots).
Chris

Database access using Entity Beans

How does it work? In the examples I've seen, there is no SQL statement
being generated, and I no code establishing the JDBC bridge...
What am I missing? How do I look up a record in a database using an
entity bean?
Thanks!!!
-Dan

The Entity Bean remote interface methods access the database.
InitialContext ic=new InitialContext();
EntityBHome eh = (EntityBHome)ic.lookup("com.ejb.EntityBHome");
EntityB entityB=eh.findByPrimaryKey(primarykey pk);
[email protected] (Dan M) wrote:
How does it work? In the examples I've seen, there is no SQL statement
being generated, and I no code establishing the JDBC bridge...
What am I missing? How do I look up a record in a database using an
entity bean?
Thanks!!!
-Dan

Entity Beans not getting garbage collected

Hi,
I am developing an application that is using EJBs utilizing several common design patterns (i.e. Session Facade, DAO, and Fast Lane Reader). All of the patterns used have come from books by Sun Microsystems Press.
As I have understood the pattern, the Session Facade pattern uses Stateless Session Beans (SLSB) to implement a desired functionality and accesses the entity beans locally. The results from the entity beans are placed into Value Objects and passed back to the client separating any direct access with the entity beans from the client. In my case, I am using BMP for my entity beans.
The problem I am seeing with Optimizeit is that none of my entity beans are getting garbage collected despite no references to them. The SLSB creates what entities it needs to perform a task at the local level, puts the data into a value object and goes out of scope.
Shouldn't the entity beans get removed if the object that references them has gone away or am I missing something?
Is there a proper way to set an entity bean (or any EJB for that matter) for garbage collection.
thanks in advance for any help...

You might even discover that entity beans can get created even before you use them.
Your application server creates "pools" of bean instances that it can use when it needs to. It is part of this role, and is done in order to optimize performances.
You cannot force them to be garbage collected. Even if you stop referencing them, the app server will.
When your create references to a bean, it (usually) won't create an instance. It will take an existing one, and load data into it, using ejbCreate or ejbActivate.
Hope this helps.
/Stephane

CMP Entity beans using local interfaces

Why CMP entity beans with CMR relation ship using local interfaces only?
Why we should not use remote interface to get the CMR field relationship?
Pls give me the solutions

"Local interfaces provide the foundation for container-managed relationships among entity beans and session beans. The bean uses the local interface to maintain its references to other beans. For example, an entity bean uses its local interfaces to maintain relationships to other entity beans. Using local interfaces, beans can also expose their state and use pass-by-reference to pass their state between related bean instances. "
http://java.sun.com/developer/technicalArticles/ebeans/EJB20CMP/

Do I need to Create Primary Key Class for Entity beans with Local interface

Do I need to Create Primary Key Class for Entity beans with Local interface?
I have created my entity bean with the wizard in Sun One Studio and it does not create a primary key class for you.
I thought that the primary key class was required. My key is made up of only one field.
Anyone know the answer.
Jim

u dont need to create a primary key class for a entity bean.if ur table's primary key feild(int ,float) is a built in or primitive data type,then u dont need one.But if ur table has a primary key field which is non primitive (for example StudentID,ItemID etc)then u have to create a primary key class.
hope this helps :-)

Problems deploying entity beans with local interfaces on Jboss?

I'm trying to deploy a simple entity bean using local interfaces on Jboss 3.2.1 and I obtain the following exception:
19:08:51,875 WARN [verifier] EJB spec violation:
Bean : UsersEJB
Section: 9.2.2
Warning: The entity bean class must not be defined as abstract.
19:08:51,875 WARN [verifier] EJB spec violation:
Bean : UsersEJB
Section: 9.4.7.1
Warning: The primkey-field element must name a public field in the bean implemen
tation class.
Any idea?
Thanks,
Marco

I guess you are missing <cmp-version>2.x</cmp-version> for your first warning and <primkey-field>primary key field </primkey-field> for you second warning in your ejb-jar.xml

Deploying entity beans with Local interfaces on Jboss

Hi, I'm trying to deploying a simple entity bean on Jboss. The EJB has been developed with Local Interfaces because then I want to access it with a session bean facade.
I get the following error:

23:41:25,984 WARN [verifier] EJB spec violation:
Bean : UsersEJB
Section: 9.2.2
Warning: The entity bean class must not be defined as abstract.
23:41:25,984 WARN [verifier] EJB spec violation:
Bean : UsersEJB
Section: 9.4.7.1
Warning: The primkey-field element must name a public field in the bean implemen
tation class.

I'm following what is wrote in the Professional EJB editeb by wrox?
Is it possible to deploy an entity bean alone with Local interfaces? Is there something I'm missing? It's true that I defined the implementation class as abstract, but because there are abstract getter/setter methods.
Thanks for any help,
Marco

Greetings,
Hi, I'm trying to deploying a simple entity bean on
Jboss. The EJB has been developed with Local
23:41:25,984 WARN [verifier] EJB spec violation:
Bean : UsersEJB
Section: 9.2.2
Warning: The entity bean class must not be defined as abstract.
23:41:25,984 WARN [verifier] EJB spec violation:
Bean : UsersEJB
Section: 9.4.7.1
Warning: The primkey-field element must name a public field in
the bean implementation class.What version of JBoss are you using? These errors indicate container compliance with EJB spec 1.1, not 2.0 to which your CMP beans are written. Download the latest JBoss release version - 3.2.1 - and you should not see this problem.
Is it possible to deploy an entity bean alone with
Local interfaces? Is there something I'm missing? It'sYes it is (no, you are not "missing something" ;). In fact, this is recommended practice in most cases under CMP 2.0 - CMR having been a major impetus to the development of Local interfaces in the specification. ;)
true that I defined the implementation class as
abstract, but because there are abstract getter/setter
methods.No problems. You are "right on track" for CMP 2.0. :)
Thanks for any help,
MarcoRegards,
Tony "Vee Schade" Cook

Calling Local Entity Beans from another Application

Hi,
I packaged all my Local entity Beans in 1 single Application (APP1.EAR).
I then I have another Application (APP2.EAR) which is made of Session Beans which require access to the APP1 application.
I'm using this code to achieve this:
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
env.put(Context.SECURITY_PRINCIPAL, "admin");
env.put(Context.SECURITY_CREDENTIALS, "manager");
env.put(Context.PROVIDER_URL, "ormi://<host>/APP1");
context = new InitialContext(env);
... (BeanLocalHome)context.lookup("java:comp/env/ejb/BeanLocal");
I get the Following Exception:
javax.naming.NameNotFoundException: java:comp/env/ejb/BeanLocal not found
1) is there any problem with this code?
2) can local interfaces be accessed by another Application (or can they be accessed only by the same application) ?
Regards.
giuseppe.

Hi ,
thank you for your answer.
I'm still in trouble:
these are the steps:
App1.jar entity beans.
App2.jar Session bean.
I embedded the App1.jar into the App2.ear
dir :
App1.jar
App2.jar
application.xml (added the App1.jar)
then I added this in the ejb-jar.xml deployment descriptor for App2.jar
<ejb-link>../App1.jar#BeanName</ejb-link>
for each entity bean.
But I still get :
javax.naming.NameNotFoundException: java:comp/env/ejb/BeanNameLocal not found
java.lang.Object com.evermind.server.ApplicationContext.lookup(java.lang.String, boolean)
ApplicationContext.java:110
java.lang.Object com.evermind.server.ApplicationContext.lookup(java.lang.String)
ApplicationContext.java:66
java.lang.Object javax.naming.InitialContext.lookup(java.lang.String)
What am I missing ??
Thanks.
giuseppe.

Regarding ENTITY bean local interfaces

Similar Messages

Maybe you are looking for