> -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > 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 -------------------------------------------------------------------------- The ResourceFactory implementation. Would it affect how the messages are retrieved? For example if you have a merged resources that does the following DBResources (1) Boot strap read properties from a flat file (2) Reads some JDBC properties from (1) if any uses them open a connection to data database. (2a) Read properties from database, these overwrite any flat file properties. (3) Repeat for any extra databases. Presumably one would need to write a new `ResourceFactory' implementation and that would be it. Thought? -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-5642 *********************************************************************** Visit our Internet site at http://www.rbsmarkets.com This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority *********************************************************************** -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>