Dave
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Proposal] Migrate to Dependency on commons-resources
Date: Sun, 12 Jan 2003 18:34:12 -0800 (PST)
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]>
_________________________________________________________________
MSN 8: advanced junk mail protection and 2 months FREE*. http://join.msn.com/?page=features/junkmail
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
