users@jersey.java.net

Re: [Jersey] Invoking other Jersey services

From: Tatu Saloranta <tsaloranta_at_gmail.com>
Date: Wed, 27 May 2009 15:51:50 -0700

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.

>
> 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 +-