Actually, it wasn't my decision to change the tld's uri - all I've done is correct the inconsitency that eight were changed (bean, html, logic, nested, tiles, bean-el, html-el and logic-el) and two were not (tiles-el and faces). The original changes were done four months ago and no one objected then. Whatever the argument for or against doing this, they should be consistent.
Having said it wasn't my decision - I agree with it though with Struts moving out of jakarta to a TLP. Its not like this is going to happen regularly (probably won't ever need to change again) and as you said adding resolution entries to web.xml will resolve this - and that isn't exactly difficult to do for someone upgrading if they happen to have used auto-discovery. Niall ----- Original Message ----- From: "Deadman, Hal" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, September 01, 2004 10:17 PM Subject: RE: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp The auto-discovery mechanism for tld files depends on the uri in the tld so changing it can break applications that upgrade if they depend on the auto-discovery of tlds. (They don't need a mapping in web.xml). Since the uri is just a meaningless string (that should be globally unique), there is very little reason to change it. Since you have changed the uri, someone who relied on auto-discovery would either have to change all their jsps that import taglibs or add resolution entries to web.xml. I have used auto-discovery in Weblogic 8.1 but ended up mapping uri-tld location in web.xml when an Eclipse JSP plugin didn't support the auto-discovery. The auto-discovery will be a nice feature once it's widely supported and the uris stay constant. ________________________________ From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Wed 9/1/2004 3:07 PM To: Struts Developers List Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp I didn't change anything that referenced Struts 1.1 or Struts 1.2 - just the struts-faces tld and the referencs in the struts-faces jsps for that tld. Just means that struts-faces now reflects the Strut's TLP status. If it causes a problem I'm happy for the changes to be reversed, but I can't see why it would. Niall ----- Original Message ----- From: "Craig McClanahan" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, September 01, 2004 6:16 PM Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp > On 1 Sep 2004 11:34:00 -0000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > niallp 2004/09/01 04:34:00 > > > > Modified: contrib/struts-faces/web/example logon.jsp mainMenu.jsp > > registration.jsp subscription.jsp > > contrib/struts-faces/web/example2 footer.jsp header.jsp > > layout.jsp layout1.jsp loggedoff.jsp loggedon.jsp > > logon.jsp mainMenu.jsp registration.jsp > > subscription.jsp > > contrib/struts-faces/web/systest context.jsp context1.jsp > > logon.jsp logon1.jsp simple.jsp > > Log: > > Change jsp taglib URIs to struts.apache.org - thanks to Matthias Wessendorf for spotting this > > > > Doesn't this mean that the apps would not run in a Struts 1.1 > environment? If so, that's not acceptable, and I'm -1 on this change. > (Struts 1.2.x should recognize both the old and new tag library URIs, > but shouldn't require applications to switch.) > > Craig > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---------------------------------------------------------------------------- ---- > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
