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