-
1. Re: 1.0 beta 2 released
rdewell Feb 8, 2006 10:48 PM (in response to gavin.king)To preface, I appreciate the hard work and effort on this important project.
I hate to be abrupt, but this new JNDI name resolution behavior versus beta 1 is unusable for large applications. (Actually, in my opinion, even error prone for small applications).
Beta 1 was simple, straightforward, and safe. Beta 2 is a recipe for naming conflicts.
What I'd like to see is Seam return to the beta 1 behavior that resolved using fully qualified class names. Seam beta 1 discovered JNDI names using:
return localInterfaces.iterator().next().getName();
Beta 2 on the other hand now purposefully unqualifies class names to do JNDI resolution:
unqualifyClassName(clazz);
What was wrong with resolving by fully qualified class name? It requires far less safety precautions and duplicated effort on the part of the programmer. This new unqualfiied resolution approach is going to cause one to either write far more annotations to avoid JNDI naming conflicts, OR rename same-named classes that are in different packages. Package structures naturally resolve naming conflicts all by themselves, why throw that away?
Please see this topic for more information and examples:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77039 -
2. Re: 1.0 beta 2 released
gavin.king Feb 8, 2006 10:57 PM (in response to gavin.king)The old behavior was worse broken because multiple EARs conflicted with each other.
I suppose we *could* use fqns, but really it seems quite ugly to have qualified names in a JNDI name. Seems to me that the current behavior is pretty great in 99% of cases. -
3. Re: 1.0 beta 2 released
rdewell Feb 8, 2006 11:24 PM (in response to gavin.king)I suppose it's ultimately a matter of aesthetics and it does have workarounds. However, it is just one more thing I and others are going to have to keep in mind while developing: "Does this unqualified class name conflict with a class name in another *package*. If so, then I have to give it a different JNDI name, etc." Honestly I have enough stuff to keep in the back of mind, and I'll hate to have this lurking back there as well.
I did already run into this problem on multiple beans (Login, Home, Support, and undetermined others), in two different web applications, existing in two different package prefixes. IMO, the fully qualified class names should be enough to isolate the beans, period. These two web applications most certainly belong in the same EAR as they share entities and other core classes.
To solve the old problem and this new problem, why not use a combination approach like "EAR Name / FQ Class Name / local"? It's your project and I'm currently one user with this problem, but looking ahead it just feels like an unnecessary and avoidable source of potential conflict.
Ryan -
4. Re: 1.0 beta 2 released
gavin.king Feb 8, 2006 11:29 PM (in response to gavin.king)No, you don't need to keep it in mind because EJB3 will throw an exception if you have to EJBs with the same EJB name in the same EAR.
So you will know immediately if you did something wrong. -
5. Re: 1.0 beta 2 released
gavin.king Feb 8, 2006 11:32 PM (in response to gavin.king)"rdewell" wrote:
To solve the old problem and this new problem, why not use a combination approach like "EAR Name / FQ Class Name / local"? It's your project and I'm currently one user with this problem, but looking ahead it just feels like an unnecessary and avoidable source of potential conflict.
We are very interested in feedback on JBoss EJB3, and if this is really a problem we can change it. But I'm just not convinced that it is at all common to have two bean classes with the same name in the same EAR.
My intuition is that this shows up as an issue more because something has *changed* than because it was a bad idea. My feeling is that if this was how it had always been, you would not really have noticed ;) -
6. Re: 1.0 beta 2 released
rdewell Feb 9, 2006 12:51 AM (in response to gavin.king)Re: "EJB3 will throw an exception if you have to EJBs with the same EJB name in the same EAR."
Not currently. Instead, the application starts up perfectly -- without exception, error, or warning. Two beans with the *same* JNDI are printed in the log:18:36:27,841 INFO [Component] Component: ManagerLogin, scope: CONVERSATION, type: STATEFUL_SESSION_BEAN, class: com.removed.web.manager.LoginImpl, JNDI: hh-test/LoginImpl/local 18:36:27,903 INFO [Component] Component: CommerceLogin, scope: CONVERSATION, type: STATEFUL_SESSION_BEAN, class: com.removed.web.commerce.LoginImpl, JNDI: hh-test/LoginImpl/local
The application starts up fine. The above logged conflict is ONLY revealed at runtime when Seam throws: "value found for In attribute has the wrong type: LoginImpl".Re: "You would not really have noticed"
Well, it would have been coded differently to be sure.
I can come up with a naming convention to work around this but it has to be better than constantly duplicating the name:
@Stateful(name="ManagerLogin")
@Name("ManagerLogin")
I was already using a prefixing convention on @Name to avoid duplication, and that's fine. It's very similar conceptually to avoiding duplication in @Entity.
However, with this new resolution method I have to avoid duplication by convention *twice*.
If Seam could allow an empty @Name() and resolve the name from @Stateful/Stateless, that would at least allow convention to continue in a similar fashion.
Not withstanding any of the above suggestions, an exception or prominent warning does need to get raised if a Component with the same JNDI path as another Component is registered. This would at least allow me to catch the conflicts at startup rather than runtime, and I wouldn't feel like I was potentially creating a bunch of runtime-only exceptions.
Thanks for hearing this out.
Ryan -
7. Re: 1.0 beta 2 released
gavin.king Feb 9, 2006 1:00 AM (in response to gavin.king)Hmmm. This *should* have been fixed. I will ask Bill about it.
-
8. Re: 1.0 beta 2 released
gavin.king Feb 9, 2006 8:16 AM (in response to gavin.king)I think the disconnect here is the idea that multiple beans would have the same EJB name. The EJB spec says:
(1) The EJB name must be unique in an EJB jar
(2) The EJB name defaults to the unqualified bean class name
So, it seems to me that this potential for conflicts is more a problem with the EJB spec itself than with our implementation. (Yes, sure, I understand that you could have them packaged in multiple ejb jars inside the same ear, but this still seems like a very uncommon case.) -
9. Re: 1.0 beta 2 released
rdewell Feb 9, 2006 11:37 AM (in response to gavin.king)So, it seems to me that this potential for conflicts is more a problem with the EJB spec itself than with our implementation.
True enough. Here's a suggestion for Seam, then. Given the built in naming capacity of EJB via Entity/Stateful/Stateless(name=""), what I'd like to see Seam do is use the EJB name if the Seam name is empty: @Name().
In other words, I'd at least like to have the possibility of using one kind of naming convention / definition. I have no problem defining names for all of my Session beans -- I already do it as a defensive practice for my Entity beans. But as a defensive convention, having to define the same name twice for my Seam session beans is going to be annoying. In my opinion, there will be very few situations where I'll want a different Stateful/Stateless name versus the Seam name, and in that case I'd certainly like to defer to the EJB name.
For lazy programmers everywhere :),
Ryan -
10. Re: 1.0 beta 2 released
gavin.king Feb 9, 2006 1:34 PM (in response to gavin.king)Jacob has also been arguing for an @Component annotation that implies the @Name from the EJB name. I'm not against this, but I wanted to see how popular it would be first.
But let me just point out that it is not as if you are writing something totally redundant here. You shouldn't be writing:@Stateful(name="ManagerLogin") @Name("ManagerLogin")
Rather, it would be:@Stateful(name="ManagerLogin") @Name("managerLogin")
Or even, potentially:@Stateful(name="ManagerLoginBean") @Name("managerLogin")
And again, @Stateful(name="...') is only there in the rare case where we have two beans with the same classname in the same EAR.
Still, I will continue to think about an @Component annotation. -
11. Re: 1.0 beta 2 released
rdewell Feb 9, 2006 1:46 PM (in response to gavin.king)I'd definitely give a +1 vote for:
"... @Component annotation that implies the @Name from the EJB name."
Ryan -
12. Re: 1.0 beta 2 released
gavin.king Feb 9, 2006 4:10 PM (in response to gavin.king)Official announcement:
http://blog.hibernate.org/cgi-bin/blosxom.cgi/2006/02/09#seambeta2