[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    RE: [resources] Proposed changes and enhancements
From:       "SCHACHTER,MICHAEL (HP-NewJersey,ex2)" <mschachter () hp ! com>
Date:       2001-10-16 17:35:06
[Download RAW message or body]

Martin,


>I would like to make some changes and enhancements to the 'resources'
>project in the sandbox. Before I do so, I'd like to make sure people
>(especially the listed committers, since I'm not one of them) are OK with
>these, so here's the list:

>* Rename the Resource class to Resources, and make equivalent changes to
>other class names. This makes the naming consistent,without having
>MessageResources as an exception, and, I believe, makes it more
descriptive.

+1

>* Rename the getData() method to getBytes(). This is more descriptive, and
>more consistent with other Java packages such as java.sql. It also
addresses
>a concern raised by Rob Leland some time ago.

+1

>* Rename the getStream() method to getInputStream() for the same reasons as
>above.

+1

>* Rename AbstractResource to ResourcesBase, since that more accurately
>reflects its purpose as a base class for other Resources implementations.

+1

>* Rename WebappResource to ServletResources, since that more clearly
>reflects its purpose. It is more generally applicable to servlets than web
>apps. Similar changes to other Webapp* classes.

+1

>* Provide an abstraction for ResourceManager, with more flexibility than
the
>existing class. The current implementation assumes applications will use a
>special purpose XML configuration file. While this may be OK for some apps,
>others will want to provide their configuration from their own location, or
>even dynamically.

Maybe the abstraction could be in ConfigurationReader?  Like, the
constructor
for ResourceManager could take an instance of ConfigurationReader, which
would be changed to be an abstract class or an interface.  How would
your abstraction work?

>* Add support for XMLMessageResources. This would use a mechanism almost
>identical to that used by PropertyMessageResources, but read the messages
>from an XML file instead of a properties file. (I posted this as a proposal
>on struts-dev, and it was suggested that I head on over here with it, which
>is why I'm here in the first place!)

+1

>In addition, there are some points I'm uncertain of:

>* Are init() and destroy() necessary and./or desirable? The only existing
>implementation is init() in FileResource, where the code could exist
equally
>well in the constructor. In general I have a preference for avoiding
>two-stage initialization, but if we want to keep them, that's fine.

I like the idea of a resource having a defined lifecycle, being as some
potential resources, for instance, one that connects to a database, needs
to initialize and disconnect it's connections (that is, if it's not using
a pre-existing DataSource).  I wouldn't go so far as to say they're
absolutely necessary, however to some people they may be useful.

>* How is the TimeZone parameter to the get*() methods expected to be used?
>It seemed out of place when I saw it there, but I assume there's an
>advantage to having it. I'm just curious as to what that is, particularly
>when it must be passed on every get*() call (although it may be null).

I initially added the ability to define a time zone as a part of the key
because I thought it'd be neat to have the option of doing time zone
specific
key lookups along with locale and language.  I see no harm in it, but if
it's
a problem feel free to make it known.  For instance, in FileResource, you
can look up files with the naming convention
filename_language_locale_timezone.extension.  This may not be a necessary or
even a well implemented idea.  I'm open to any better suggestions, or
getting rid of it all together if it poses a problem.

>* I'm a little uncomfortable with the way the Webapp* classes fit in. It
>doesn't seem very natural. This might mean that we have the wrong
>abstraction in general, or it might be just the way things have to be, or
it
>might just be that I haven'g got used to it yet. ;-)

I did it that way because I didn't want to make it so you needed a Servlet
container to run some of the resources I considered useful,
such as MessageResources and FileResource.  So I put them in a different
package
and just added the ability to set a ServletContext so that resource
implementations
that want that kind of access could have it at the cost of not being able
to run outside of a webapp.

An example of this is WebappFileResource, which
is in the awkward org.apache.commons.resources.file.web package, which 
implements WebappResource and extends FileResource to
get the caching functionality it provides, but does it in a context-path
relative
way.

>Comments and feedback are welcome. Assuming I get the go-ahead, I'll be
>ready to check in the changes very shortly.

Cool, thanks

 - mike

[prev in list] [next in list] [prev in thread] [next in thread]