I'm +1 on the principle of going for the whole enchilada. I haven't had a chance to look over the latest changes to Commons Resources yet, but I'm a committer on Resources, so I can always fix any problems I see. ;-) And you can count me in as a volunteer willing to help maintain it (and +1 the move to Proper and the release).
-- Martin Cooper On Sun, 12 Jan 2003, Craig R. McClanahan wrote: > As we've discussed a couple of times, the last major functionality change > we had discussed for Struts 1.1 was to migrate to dependence on > commons-resources, rather than the proprietary message resource facilities > inside og.apache.struts.util. As you might recall, Michael Schacter took > a first crack at factoring out the Struts resources classes out to create > this commons package, which is currently in the sandbox. > > I've recently gone through it, and did a major refactoring of > commons-resources, to the point where I'm now ready to propose that we > modify Struts to depend on it. I'd like the other committers to evaluate > the current state of commons-resources, and my proposed integration plan > below, to see what they think of this idea. > > The nightly build of commons-resources.jar included in recent Struts > nightly builds is the code that I'm proposing. You can see the Javadocs > for this code at: > > http://jakarta.apache.org/commons/resources/api/ > > and get the sources via either CVS (from jakarta-commons-sandbox) or > nightly snapshots: > > http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/ > > In terms of Struts integration, I propose: > > (1) Most Struts classes declare a static MessageResources instance > for the messages unique to that Struts package. For example, > org.apache.struts.taglib.bean.CookieTag has this: > > protected static MessageResources messages = > MessageResources.getMessageResources > ("org.apache.struts.taglib.bean.LocalStrings"); > > This would be migrated to the new Messages class from commons-resources: > > protected static Messages messages = > Messages.getMessages("org.apache.struts.taglib.bean"); > > The calls to actually retrieve message strings are compatible with > the existing code, as well as the properties files used to acquire > the message strings, so no other changes should be required. > > (2) Convert o.a.s.u.MessageResources (and its friends) to wrappers > around equivalent functionality from commons-resources (much like > GenericDataSource now wraps commons-dbcp), and deprecate them. > This protects existing apps that are customizing these APIs, > but allows us to remove the o.a.s.u classes in a future version. > > (3) Modify the <message-resources> initialization element to allow > the selection and configuration of an appropriate > ResourcesFactory from commons-resources, wrapped by a Messages > instance. This is primarily a change in the interpretation of > the "factory" attribute, and should not affect anyone that uses > the current default. > > (4) Modify all internal uses (including in tag libraries) of > org.apache.struts.util.MessageResources to use > org.apache.commons.resources.Messages instead. This will be > transparent to users that use the standard implementations, but > will require folks who have subclassed the MessageResources > classes to migrate their code as well. > > What do you think? Should we go ahead and do this migration? Is the > commons-resources package as it stands now as complete and functional as > it needs to be (obviously, it'll need to be promoted to a standard Commons > package and released so we can rely on it, which will require a couple of > volunteers willing to help me maintain it). Should we do the entire > migration outlined above, or maybe only part of it? > > Thoughts, please. > > Craig > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
