[ http://issues.apache.org/struts/browse/SHALE-196?page=comments#action_37566 ]
Craig McClanahan commented on SHALE-196: ---------------------------------------- That's an interesting idea. It's complicated, however, by the fact that it is actually legitimate to spread the definition of a managed bean across multiple <managed-bean> elements (the info is merged), so it is not guaranteed that this is an error situation (warning would be appropriate ... and the RI at least does complain about merging configuration entries). In particular relation to Tiger, though, there is a valid use case for *wanting* what looks like duplication -- you declare a managed bean with annotations, and then want to override the expressions used on a @Value (oops ... now @Property :-) annotation. It was designed this way to be philosophically consistent with Java EE cases that support configuration with annotations .. .in basically every case, you can override the annotation-based stuff with a traditional deployment descriptor. More broadly than just this case, though, I've been thinking it would be very useful to have an "audit" type tool that could examine an entire Shale based applicaton (after buiding), and try to find as many problems like this as possible before you end up discovering them at runtime. That would be a pretty neat value add for the framework, especially if it were packaged so it could be run from the command line, from an Ant or Maven2 build, or from your favorite IDE. > Shale should notify me if two beans are configured with the same name > --------------------------------------------------------------------- > > Key: SHALE-196 > URL: http://issues.apache.org/struts/browse/SHALE-196 > Project: Shale > Type: Bug > Components: Tiger > Versions: 1.0.3 > Reporter: Adam Brod > > Shale-Tiger should throw an error if multiple beans are configured with the > same name. Twice I have had very frustrating problems where I thought my > changes weren't being picked up. It turned out this was because two beans > had the same name and the second one was being silently ignored. > I can't imagine that anyone would ever want two beans with the same name > since they won't both work, so an error at startup would be a great > resolution. If not that, then at least a severe warning to let the developer > know that (s)he could be in for a surprise would be very helpful. > I guess this really should be in the JSF impl of the managed beans facility; > however, this problem is more likely to occur with the managed bean > definitions being spread through the classpath. > Note: this happened because I use Weblogic/Tomcat autodeploy features. When > I rename a class (or move it), the old class isn't always deleted. So the > old class is still in the autodeploy directory, even though my editor says > the file is deleted. I'm sure this isn't too uncommon for other developers > to run into the same problem... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
