Mailing-List: contact issues-help@shale.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shale.apache.org
Message-ID: <11355196.1153113681253.JavaMail.jira@brutus>
Date: Sun, 16 Jul 2006 22:21:21 -0700 (PDT)
From: "Craig McClanahan (JIRA)" <jira@apache.org>
To: issues@shale.apache.org
Subject: [jira] Updated: (SHALE-196) Shale should notify me if two beans are
 configured with the same name
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

     [ 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