On May 27, 2009, at 3:51 PM, Tatu Saloranta wrote:
> On Wed, May 27, 2009 at 1:49 PM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>> Hi Jon,
>>
>> On May 27, 2009, at 12:53 PM, Jon Stritar wrote:
>>
>>> Hey,
>>>
>>> We are developing a bunch of services using Jersey. How would you
>>> recommend handling runtime parameters like the location of other
>>> services? For example, in production I can just invoke the live
>>> services
> ...
>
> This is a very common problem, but AFAIK is not adequately solved.
>
Yes.
Specifically for programatic access I am wondering a interface bean
proxy approach to property config files.
@Properties("x.y.z")
public interface XProps {
@Name("...")
int getValue();
}
The "x.y.z" is a virtual name that could be mapped to an actual
location based on deployment requirements.
IIRC GF internals has an interesting approach to getting immutable XML
config information using its underlyng DI framework to help with the
programmatic access.
Paul.
>>
>> You could use a properties file, load it and wrap the data around
>> one or
>> more beans to get the property values.
>>
>> If you are using an IoC framework like Spring or Guice you can
>> inject such
>> beans.
>
> In most enterprises there are systems that pre-process such
> configuration files; either as part of build process (-> separate
> artifacts for different stages), or as part of deployment process (->
> same artifacts from build, but deploy only subset, or choose during
> runtime given stage id of some kind).
> Pre-processing is sometimes done using macro(-like) substitutions; or
> using conventions to indicate variants to be used for different
> stages.
>
> IoC usually does not help much with this part, but if you end up with
> set of config files (properties are good for this, but could be xml
> etc too) they can be used to inject resulting data. But trying to make
> Spring (etc) redirect based on staging id tends to lead to more
> problems than it solves in my opinion.
> IoC is ok for wiring components locally, but not so useful for wiring
> services together.
>
> Interestingly enough I think these deployment systems are things that
> haven't been open sourced commonly, which is a shame, since they often
> the only things that actually work reasonably well, of legacy things
> that corporations build (this only based on 2 of recent companies I
> work for -- both have systems that handle this, albeit in quite
> different ways).
>
> -+ Tatu +-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>