-
1. Re: Beta 2: Names vs JNDI, jndiPattern, etc
gavin.king Feb 8, 2006 10:54 PM (in response to rdewell)I think it is *extremely* uncommon to have to session beans with the same EJB name in the same EAR.
-
2. Re: Beta 2: Names vs JNDI, jndiPattern, etc
gavin.king Feb 8, 2006 10:55 PM (in response to rdewell)Note that I asked for this change in EJB3 because we had a major problem where Seam apps would not deploy alongside each other because the same local interface existed in multiple EARs.
So the old way was much more broken. -
3. Re: Beta 2: Names vs JNDI, jndiPattern, etc
jay_stramel Feb 8, 2006 11:19 PM (in response to rdewell)Although I can see how it was broken for that particular case, the JNDI change has made things much more difficult for many other cases.
The application I'm working on is comprised of many different deployables and each one has a version number that changes over time. I'm not even sure how to use the new EJB3 look ups to make our application work anymore. I certainly don't want to have to make a new version of every module because the version of one of the modules changed (which I would have to do if I have to start hard-coding the version numbers in the JNDI look ups). I'm guessing that we're going to have to re-name every deployable so that it doesn't have a version. That pretty much sucks.
The remote vs local change is less disruptive, but even then it seems like the container should be the one to decide if the call needs a remote or local bean.
Is there something I'm missing with this change? Am I making things too hard for myself some way? -
4. Re: Beta 2: Names vs JNDI, jndiPattern, etc
gavin.king Feb 8, 2006 11:23 PM (in response to rdewell)huh? So different "versions" lived in different packages?
This is a very, very strange thing, surely?
What is so hard about
@Stateful(name="qualifiedName")
in these kind of strange cases? -
5. Re: Beta 2: Names vs JNDI, jndiPattern, etc
jay_stramel Feb 9, 2006 1:53 AM (in response to rdewell)Does that mean that if you specify the name with the annotation that the jar name isn't needed to look it up?
-
6. Re: Beta 2: Names vs JNDI, jndiPattern, etc
gavin.king Feb 9, 2006 8:13 AM (in response to rdewell)You always need the name of the EAR. That is because it is perfectly valid and indeed common to have the same bean in multiple EARs.
-
7. Re: Beta 2: Names vs JNDI, jndiPattern, etc
jay_stramel Feb 9, 2006 12:21 PM (in response to rdewell)So is there any way around hard coding ear names into our look ups?
-
8. Re: Beta 2: Names vs JNDI, jndiPattern, etc
rdewell Feb 9, 2006 12:29 PM (in response to rdewell)I guess I always (incorrectly) assumed that JNDI lookups were automatically isolated to the EAR that I'm "in" -- by nature preventing any conflicts across EARs...
It's weird to me that by default multiple EARs share the same class / name lookup space. -
9. Re: Beta 2: Names vs JNDI, jndiPattern, etc
gavin.king Feb 9, 2006 1:25 PM (in response to rdewell)"jay_stramel" wrote:
So is there any way around hard coding ear names into our look ups?
Sure. You can define a mapping of the global JNDI name into the ENC. (This requires vendor specific metadata, unfortunately; something that needs to be fixed in a future rev of EJB.)
But actually, with Seam, you are using org.jboss.seam.core.init.jndiPattern, which means that the JNDI name does not need to be hardcoded anywhere... -
10. Re: Beta 2: Names vs JNDI, jndiPattern, etc
gavin.king Feb 9, 2006 1:25 PM (in response to rdewell)"rdewell" wrote:
I guess I always (incorrectly) assumed that JNDI lookups were automatically isolated to the EAR that I'm "in" -- by nature preventing any conflicts across EARs...
ENC lookups are isolated. Not global JNDI lookups."rdewell" wrote:
It's weird to me that by default multiple EARs share the same class / name lookup space.
If you define ENC bindings, the don't.