On 7/19/01 11:48 AM, "Diethelm Guallar, Gonzalo"
<[EMAIL PROTECTED]> wrote:
>>> Ok, thanks for the hints. Now, how should I access the same
>>> property from a class that is not the service itself? For example
>>> from a class that is a utility for the service?
>>
>> You have to get hold of the service from the service broker and
>> than get the configuration value. Use the code in the static helper
>> of any of the services to see how to do this. Once you have the
>> service than you use getConfiguration() again.
>>
>> Either way you have to reference a service in your utility code:
>> TurbineResources, or the ServiceBroker to get hold of the singleton
>> instance of the service so that you can get the value from there.
>
> Ok, what I did was to add a static getConfiguration() method to each
> of my service facade classes. That seems to work fine. However, to
> my surprise, Configuration is really
>
> org.apache.velocity.runtime.configuration.Configuration
>
> Why velocity? And what's more, this class is deprecated (but used
> throughout Turbine's own services). Should I be using something else?
> I believe I should, if not for anything else, because I fail to see
> why a service should be coupled to Velocity. Besides, if the class
> is deprecated, it surely was replaced with something else, right?
> If yes, what exactly should I be using?
In 2.1 it's the right class, it is still in 3.0 as well. Not ideal,
I fully realize. The Configuration class in velocity moved to
the ExtendedProperties class in the commons.
But I didn't want to replace one concrete implementation with
another, I think simply replacing Configuration from Velocity with
ExtendedProperties from the commons-collections is a waste of time.
What we need is a Configuration interface, then we can make a wrapper
for ExtendedProperties that implements Configuration. With the
Configuration interface we can make the configuration mechanism
pluggable. I would like to get a Configuration interface going
with ExtendedProperties and the Resources classes in the commons.
I realize there is similar code in Avalon but I would like to
go with the commons for any of our components.
> By the way, I have come to understand a little more about your
> pain in decoupling things for Turbine 3.0... Thanks,
It's natural that it happened, and the decoupling has allowed
me to see every last nook and cranny of Turbine. Hasn't been
that bad.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
