OK I found out a way to get at the Configurations without it, so yes, it is
OK to remove again:
Configurations config =
((TurbineResourceService)((TurbineServices)TurbineServices.getInstance())
.getResources("InfoPointIPSyncService"))
.getConfig();
But on the other hand, as I believe Rafael was noting, the fact that one
should get another instance
of ResourceService each time one wants a subset of it, seems to me not very
intuitive
(the getService(), and getResources() have the same return type).
My preferred way of looking at it is that a generic config class (be it
Configurations or something else)
shoud be available in a ResourceService, via a
getConfigurations()/getResources() method. All other
get methods in ResourceService should merely be shortcuts.
This would mean that ResourceService would be defined as an abstract class,
with merely one
abstract method, that is getConfigurations(), in much the same way as
InputStream has only
one abstract method, that is: int read(void).
That might upset some people :)
MT
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rafal Krzewski
> Sent: 31. janúar 2001 09:58
> To: Turbine
> Subject: Re: Where did TurbineResources.getConfig() go?
>
>
> Jon Stevens wrote:
> >
> > on 1/30/01 9:20 AM, "Magnús Ţór Torfason" <[EMAIL PROTECTED]> wrote:
> >
> > > Sorry if this exposes my out-of-dated-ness, but where did
> > > TurbineResources.getConfig() go, and why?
> > >
> > > (I may still send other posts, wow how much has changed in
> four weeks).
> >
> > Ok, I added it back, however, it isn't as clean of an API because now
> > ResourceService has to import Configurations. We should discuss this...
> >
> > You have access to the object through TurbineResourceService, but not
> > TurbineResources...therefore, I would like to see it in the API, but i'm
> > worried Rafal will yell at me. :-)
>
> FOO! :-)
>
> We don't want the ResourceService interface depend on
> Configurations/ExtendedProperties
> implemntation.
> Instead, there is a method in ResourceService, called
> getResources(String prefix)
> that allows you to extract nested Resources set with a given prefix.
> This has well defined meaning across all implemntations that I can think
> of now:
> ExtendedProperties, XML file and JNDI environment.
>
> I hope that this will work for you, and we can remove getConfig() from
> the interface.
> (which I am strongly +1 on)
>
> On the other hand, someone suggested that Configurations is generic and
> it may take
> advantage of different storage implementations (and ExtendedProperties
> is one of them).
> This would mean that we have duplication of functionality between
> Configurations
> and ResourceService to some extent. I'm not sure how should we proceed:
> 1) We may ignore the situation, treat Configurations/ExtendedProperties
> as a black box
> and continue to use it to implement ResourceService.
> 2) We might skip Configurations as an extra level of indirection and use
> ExtendedProperties
> directly to implement ResourceService
> 3) We might try to replace ResourceService with Configurations or merge
> these two together.
>
> Opinions?
>
> Rafal
>
> --
> Rafal Krzewski
> Senior Internet Developer
> mailto:[EMAIL PROTECTED]
> +48 22 8534830 http://e-point.pl
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
