I think this is an excellent idea and I will help support it any way I can.
-- James Mitchell > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Sunday, January 12, 2003 9:34 PM > To: [EMAIL PROTECTED] > Subject: [Proposal] Migrate to Dependency on commons-resources > > > 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/commo > ns-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:struts-dev-> [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]>
