moving to commons-resources: design/implementation questions

[Steve Peterson <st...@zpfe.com>]

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

Re: moving to commons-resources: design/implementation questions

[Steve Peterson <st...@zpfe.com>]

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