This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Two scenarios: 1. I build an ejb-jar and deploy it to a container. I now have 1 home. I then re-deploy the the same jar (effectively 'updating' it). I cause the original stuff to be replaced with the new stuff and when all is done I still have 1 home. 2. I build an ejb-jar and deploy it to a container. I now have 1 home. I then create a new ejb-jar with a different ejb-jar.xml file giving the beans new JNDI names. I deploy the second ejb-jar file, thus having "deployed twice" (in the sense of having used the same Java files but in a second, different way, perhaps with different env-entry values). I now have 2 homes.
Session or Entity Bean can have two home - remote and local, and two component interface - remote and local. So you can have 5 files for an EJB - two home, two component interface and one bean class. DD will have info accordingly. Correct me if I am wrong
Howdy -- I think we're talking about two different things here... As Reid says, the *same* bean files can be redployed more than once (although you need new JNDI names, and there is nothing in the spec that says what will happen if you try to deploy with the SAME names as an already-deployed bean, so BE CAREFUL... chances are, you will simply not be able to locate the beans deployed first under that name). This *deployed twice* (or more than twice) can be an important feature, because it means you can reuse the same bean files (interfaces and classes), but by changing the deployment descriptor information, have a completely different application that behaves differently from the same files deployed with *different* choices in the deployment descriptor. It's just another form of reuse... by customizing the deployment descriptors, you can have the same bean files acting in very different ways. Ali makes an important, but completely different, point--that if a bean has both a local and remote interface, then the bean (session or entity) will have two different homes... one for the local home and one for the remote home. But for that, you can deploy a single ejb-jar; the deployment descriptor allows you to specify both a local and remote interface for a bean within the same ejb-jar (but on deployment you must still provide two different JNDI names, one for the local and one for the remote home). cheers, Kathy