You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Steve Peterson <st...@zpfe.com> on 2003/03/04 23:59:22 UTC
Re: moving to commons-resources: design/implementation
questions
I worked through the showstoppers in my previous email (have to say that a
little sleep helps) and have uploaded revised unit tests and a complete,
working implementation of the commons-resources migration. It has one
outstanding unit test problem that I won't be able to get to until next week.
http://issues.apache.org/bugzilla/show_bug.cgi?id=16792
S
At 10:43 PM 3/1/2003 -0600, Steve Peterson wrote:
>I have a basic version of MessageResources working on top of the
>commons-resources package. There are some things that I want to review
>with the team before I submit patches.
>
>1. implementation approach.
>
>The approach I took for implementation was to implement a new subclass of
>o.a.s.u.MessageResources/MessageResourcesFactory, and change the default
>factory class in MessageResourcesFactory to use the new subclass. This
>allows us to hook in the new class, but allows existing subclasses of
>PropertyMessageResources/PropertyMessageResourcesFactory will continue to
>work without any changes.
>
>Comments?
>
>2. o.a.commons.resource.ResourceFactory.getResources() has a "name"
>parameter that is the "logical name" for the resources. I don't have a
>sense of what sort of name makes sense here, and whether it can be a
>constant or needs a getter/setter (some work involved in that too).
>
>3. I hardcoded my implementation to use the
>o.a.commons.resources.impl.PropertyResourcesFactory, rather than
>discovering it through the ResourcesFactoryFinder. Since this is intended
>to be a plug-in replacement for the current property based resources, is
>this OK?
>
>4. Poking through the code and trying it out, it does not appear that the
>o.a.c.r.impl.PropertyResourcesFactory.createResources() method supports
>the classloader-based approach to locating property files that was
>implemented in o.a.s.u.PropertyMessageResources.loadLocale(). It wants a
>URL really, really bad. This means that
>
>Messages message = Messages.getMessages("org.apache.struts.taglib.bean");
>
>doesn't work. Ideas?
>
>5. When given a null locale, o.a.c.r.Messages.getMessage() tries to
>append en_US to the spec for the properties file, rather than reading the
>"base" property file as the current implementation does. Is that
>something to change in Messages?
>
>6. o.a.c.r.Messages.getMessage() returns an undocumented string when
>can't find a specified resource. To support the returnNull property
>semantics on o.a.s.u.MessageResources, I need to be able to tell when the
>resource isn't found. It seems like one of these options should be selected:
>
>. expose the return string so that it can be tested for (ugh...)
>. add a "messageExists()" method on Messages to allow for a test for a
>"null" return (would have to call it every time through)
>. change the semantics of getMessage() to return null when the underlying
>message resource isn't found
>. implement the returnNull() property on Message to allow the behavior to
>be configured.
>
>I think that's everything on my list right now.
>Steve
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org