1.0 beta 2 released

[gavin.king]

Last night JBoss AS 4.0.4 went out:

http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=16942

So I've just released Seam 1.0 beta 2 to sourceforge:

http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=163777

New features include:

* jPDL-based page flow language
* Nested conversation model @Begin(nested=true)
* PAGE context
* Redesigned and enhanced jBPM integration
* Workspace management via conversation switcher, conversation list and breadcrumbs
* Support for non-JSF invocation (Ajax/SOAP/etc)
* @Factory for handling non-faces requests
* Support for multiple @DataModels per component
* @BeginIf/@EndIf were merged into @Begin/@End
* Added @Begin(join=true|false)
* @ResumeTask/@CompleteTask were renamed to @BeginTask/@EndTask
* Conversations now propagate across redirects
* Added @RequestParameter
* Added @Rollback
* Added @IfInvalid(refreshEntities=true)
* Added @Role/@Roles
* Added resourceBundle component
* Conversation timeout now settable programmatically
* Support for login by challenge
* No longer need to specify SeamVariableResolver in faces-config.xml
* Added Seam Debug Page
* New examples
* Most examples not run on Tomcat

Thanks to everyone who helped make this release possible.

Thanks also to all the patient people here who've put up with trying to work against an in-flux set of APIs for the last few months. My intent is that beta 2 will form a good, stable platform for development, and that I won't be breaking a lot of stuff in 1.0.

Please try this release out and let me know if there are any hiccups before I do a more general announcement.

[rdewell]

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

[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.

[rdewell]

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

[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.

[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 ;)

[rdewell]

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

[gavin.king]

Hmmm. This *should* have been fixed. I will ask Bill about it.

[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.)

[rdewell]

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

[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.

[rdewell]

I'd definitely give a +1 vote for:

"... @Component annotation that implies the @Name from the EJB name."

Ryan

[gavin.king]

Official announcement:

http://blog.hibernate.org/cgi-bin/blosxom.cgi/2006/02/09#seambeta2