shale-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SHALE-196) Shale should notify me if two beans are configured with the same name
Date Mon, 17 Jul 2006 05:21:21 GMT
     [ http://issues.apache.org/struts/browse/SHALE-196?page=all ]

Craig McClanahan updated SHALE-196:
-----------------------------------

    Issue Type: New Feature  (was: Bug)

Switching the issue type to "new feature", as the right long term approach to this is some
sort of auditing capabilities that detects this particular problem (two managed beans with
the same name) as well as a host of other potential configuration problems that could be detected
by a static analysis of the entire web application.


> 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
>          Issue Type: New Feature
>          Components: Tiger
>    Affects 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

        

Mime
View raw message