T Rob Darrough

I have had similiar experiences. If I don't put the directorId field in Movie the container will not generate anything similiar (i.e. a foriegn key in Movie to Director). If I do put directorId into Movie then the container will not manage it.

I think it is a trick question. You never commit your transactions in CMT. You always return before the transaction is committed. So obviously it has to be false.

Taking a que from Head First, say we have two entity beans, Director and Movie, in a CMR. Consider this line of code ...

myDirector.setMovies(myMovieColl);

For each movie in myMovieColl this line of code would change thier director to be myDirector? This change would be made in the database as well, right?

I tried this out and it's not working. Basically getMovies() will give back myMovieColl but that's about all. The movies in myMovieColl still have thier old director. I checked the DD out, and it matches whats in the book.

Any ideas? Can anyone confirm what is supposed to happen?

You don't need any of the following on your classpath.

C:\j2sdk1.4.1_02\bin
C:\j2sdk1.4.1_02\lib
C:\j2sdkee1.3.1\bin

Try ...

CLASSPATH = C:\j2sdkee1.3.1\lib\j2ee.jar;.\classes

With this classpath you should not need to specify a classpath on the command line also. The AdviceAppClient.jar is also not needed, and in fact could cause problems. If anything you might put AdviceApp.jar (because it contains the headfirst package), but thats not needed as long as (1) the headfirst package is in your classes folder, (2) your classes folder is just off of your working folder (advidce) and (3) you compile from your working folder (advice). If you compile from your src folder, then use this instead ...

CLASSPATH = C:\j2sdkee1.3.1\lib\j2ee.jar;..\classes

If it still doesn't work then confirm that your headfirst package has all of the interfaces. They should all be there.

Since he is getting ClassCastException it seems reasonable to assume lookup is finding the remote home.

I had a similiar problem to this and found that there is a window where you specify the JNDI name you are using to look other beans locally. This window exists for each bean and has a tab named something like "Referenced EJBs" (highlight the bean first). This window is different than the window where you give JNDI names that remote clients are using (highlight the jar). Further, the names you give for local clients cannot match the names given for remote clients. I am using the RI but I imagine this is all true for every compliant server.

You were saying something about the DD. I'm not sure how the DD relates to my comments. I think you must have misunderstood me.

I am also still learning, so I don't want to say too much, but I can tell you that you can have both a local and a remote interface for the same bean. I don't think you specify anywhere in the deployment descriptor whether the bean is local or remote.

I am still trying to get my head around EJB.

I understand that having both a local and remote interface is rare. I have heard others on this site say that they could not imagine a reason for having both.

Supposing there are two entity beans and they have a bi directional CMR. Each bean would have to have a local interface for the other to access it through. Of course, at least one of the beans will need a remote interface for clients to access it through. So it seems that at least in this case having both interfaces would be required.

So what's the story? Are bi directional CMRs rare?

Why do you soppose the designers of EJB made it so that entity beans in a CMR must use local interfaces to access each other?

What would happen if I wrote an accessor that was part of a CMR to lookup and return the remote interface? i.e. AccountBean and TransactionBean have a CMR. Suppose in AccountBean.getTransaction() I lookup the remote home for TransactionBean and call findByPrimaryKey on it, returning the results to the client. What would happen? Could I do this without declaring a CMR? If so why have CMRs?

Just a guess ... when you deploy what class is the JNDI name "StudentBean" associated with; the local or remote component interface? I'm guessing the remote and that's why it won't cast to the local. In that case, the fix would be to put the name associated with the local component interface into your lookup call. In simpler terms, I think fix is something like ...

student = (StudentBeanLocalHome)ctx.lookup("StudentBeanLocal");

If you have no home then where would you go to find or create an entity? To JNDI? That would mean every entity in the database would have to have a name in JNDI. The volume would be prohibitive. How would the container manage access, since you are not going to thru the container when you do a lookup in JNDI. How would create methods be implemented; JNDI cannot have a name for every bean that might be created. Besides, JNDI cannot instantiate things.

I suppose JNDI could have a reference for one randomly chosen instance of each entity class. Still records for that randomly chosen class would have to be locked more or less permanently. And what would happen when anyone deleted the entity? What if there were no records for a given table, and therefore no entities for the corresponding entity class?

Think about it this way: the difference between a home and a component is the difference between a automobile factory and an automobile.

Hi,

You said "It's not required in all cases, but it's often a best practice, especially when you're getting results back out of a Collection. It's one of the cases where the spec's a tiny bit fuzzy and vendors interpret the sample code in the spec differently." which leads me to the question, is there ever a case where you should definately not narrow or is narrowing always safe?

Hi,

I am reading "Developing EJB 2.0 Components" by Tulachan and have came across some things I that seem to be false. (Of course, if I knew enough about EJB to know if these things are false I would have no need to read the book.) I was hoping someone could set me straight.

Also, what's the best place(s) for someone who has never written or worked with EJBs to learn how?

Pg 213: "the ejbLoad() method contains the necessary SQL SELECT command and the logic to read and translate the persistent data from the database". I thought ejbLoad was called after the data was loaded?

Pg 217: The whole page is subtitled "Rules for Implementing ejbFinder Methods". I thought the container implemented finder methods?

Pg 217: It states that you have to narrow the results of a finder method.

Pg 217: It states in two different places that finder methods return primary keys. I thought they returned an instance of the remote component?