Hi all
I start commenting here in between. Even staged default configuration can be
deployed with the application (I neclect any security conerns as of now), e.g.
for application config in Credit Suisse we have the following defined classpath
structure:
cfg/${STAGE}/config/**/*.xml
cfg/GLOBAL/config/**/*.xml
Dpenending on the current stage, which is managed by an Environment component
(called ContextManager), the configuration manager can easily pick up the
configuration matching your current stage.
GLOBAL hereby are global defaults, that may be overridden by stage specific
defaults...
Additionally we have different priorities for config loaded on the system
classloader (lowest prio), the ear classloader (medium) and the web app
classloader (highest).
Hereby we maintain a list of files already read from earlier classloader (we
can go down the list of classloaders starting by the current, to prevent a
resource is loaded twice).
File configuration is there as well and is deployed controlled by the
centralized deployment engine.
Other details I will omit here, but as you see you can provide stage specific
defaults easily and even have them overridable by default.
-----Original Message-----
From: Mark Struberg [mailto:[email protected]]
Sent: Mittwoch, 7. Januar 2015 10:55
To: [email protected]
Subject: Re: ConfigurationContext -> Configuration
only the default databaseIP/url should be part of the 'internal' config. Or
none at all!
You can still override this configuration via -D, env and probably we also come
back to add JNDI by default... All those ConfigSources are 'external' to your
application.
LieGrue,
strub
> On Wednesday, 7 January 2015, 10:48, Romain Manni-Bucau
> <[email protected]> wrote:
> >T hink you didnt get it, you packaged the database IP, it changes and
> you dont repackage reading from inside the app? Give me the formula :p
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
>
> 2015-01-07 10:42 GMT+01:00 Mark Struberg <[email protected]>:
>> no it's not useless because ALL the property files with this name will
> get picked up. And the programmer is in full charge!
>> And no, there is no code change required for the case you mentioned.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>> On Wednesday, 7 January 2015, 10:30, Romain Manni-Bucau
> <[email protected]> wrote:
>>> > sure but classpath config = hardcoded config so it is quite
> useless.
>>> Config makes sense when it is outside the app. All bundled config will
>>> imply to modify the app/package if the environment changes -> this
> is
>>> code not config
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>>
>>> 2015-01-07 10:27 GMT+01:00 Mark Struberg <[email protected]>:
>>>> we can do both. But how do you ship your application and what is
> always
>>> there? Exactly, the ClassPath.
>>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Wednesday, 7 January 2015, 9:49, Romain Manni-Bucau
>>> <[email protected]> wrote:
>>>>> > @Mark: read it from file system and not jars :p
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>>
>>>>>
>>>>>
>>>>> 2015-01-07 9:29 GMT+01:00 Mark Struberg
> <[email protected]>:
>>>>>> Do you know the locations of your JSON files or do you
> need
>>> anything which
>>>>> is not available during the app boot (e.g. CDI or EJB)? In
> that case
>>> you
>>>>> don't even need to touch the ConfigurationContext.
>>>>>>
>>>>>>
>>>>>> Simply create a new class
>>>>>>
>>>>>> public class MyAppJsonPropertySourceProvider implements
>>>>> PropertySourceProvider {
>>>>>> List<PropertySource> jsonSources = new
>>> ArrayList<>();
>>>>>>
>>>>>> iterator over
>>>>> classLoader.getResources("myownjsonconfigfile.json")
> {
>>>>>> jsonSources.add(new JSONPropertySource(jsonFileUrl);
>>>>>>
>>>>>> }
>>>>>> return jsonSources;
>>>>>> }
>>>>>>
>>>>>> and then create a file
>>>>>>
> META-INF/services/org.apache.tamaya.spi.PropertySourceProvider
>>>>>>
>>>>>>
>>>>>>
>>>>>> and write your fully qualified
> MyAppJsonPropertySourceProvider
>>> class name
>>>>> into it.
>>>>>>
>>>>>>
>>>>>> That's it.
>>>>>>
>>>>>> But to be honest. The JSON configuration is nice but what
> benefit
>>> does it
>>>>> have over a property file which you get out of the box?
>>>>>>
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Wednesday, 7 January 2015, 9:07, Oliver B. Fischer
>>>>> <[email protected]> wrote:
>>>>>>> > Because I am unable to see how to turn this
>>>>>>>
>>>>>>> JSONPropertySource source
> =newJSONPropertySource(...);
>>>>>>>
>>>>>>> ConfigurationContext context =
> ConfigurationContext.context();
>>>>>>>
>>>>>>> context.addPropertySources(source);
>>>>>>>
>>>>>>>
>>>>>>> in a Configuration...
>>>>>>>
>>>>>>> Oliver
>>>>>>>
>>>>>>> Am 07.01.15 um 08:53 schrieb Romain Manni-Bucau:
>>>>>>>> Did I miss the reason in this thread or why a
> provider
>>> doesnt
>>>>> solve it?
>>>>>>>>
>>>>>>>>
>>>>>>>> Romain Manni-Bucau
>>>>>>>> @rmannibucau
>>>>>>>> http://www.tomitribe.com
>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>> https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015-01-07 8:49 GMT+01:00 Oliver B. Fischer
>>>>>>> <[email protected]>:
>>>>>>>>> This is the scenario for huge classic
> enterprises.
>>> There are
>>>>> many
>>>>>>> companies
>>>>>>>>> working in a more agile fashion there with
> not such
>>> and strict
>>>>>>> destinction
>>>>>>>>> between these roles. And I am not willing to
> leave
>>> them
>>>>> behind.
>>>>>>>>>
>>>>>>>>> Oliver
>>>>>>>>>
>>>>>>>>> Am 07.01.15 um 00:41 schrieb Anatole Tresch:
>>>>>>>>>
>>>>>>>>>> No. Configuratipn is the api for end
> users. Users
>>> that
>>>>> provide app
>>>>>>> config
>>>>>>>>>> and consume it are not the same than the
> one that
>>> define
>>>>> how
>>>>>>> apps/solutions
>>>>>>>>>> have to be configured. The ladder may be
> lead
>>> engineers ,
>>>>> or in
>>>>>>> case you
>>>>>>>>>> have a platform the platform and
> technical
>>> srchitects...
>>>>>>>>>>
>>>>>>>>>> -
>>>>>>>>>> Anatole Tresch
>>>>>>>>>> Glärnischweg 10
>>>>>>>>>> 8620 Wetzikon
>>>>>>>>>> Tel +41 (43) 317 05 30
>>>>>>>>>> -
>>>>>>>>>> Send from Mobile
>>>>>>>>>>
>>>>>>>>>>> Am 06.01.2015 um 23:58 schrieb
> "Oliver
>>> B.
>>>>> Fischer"
>>>>>>>>>>> <[email protected]>:
>>>>>>>>>>>
>>>>>>>>>>> I think a lot of user will use
>>> ConfigurationContext to
>>>>>>> configure their
>>>>>>>>>>> configuration system. I think it is
> easier to
>>> put some
>>>>> files
>>>>>>> into the
>>>>>>>>>>> filesystem and to read this files
> then to
>>> deal with
>>>>> the SPI
>>>>>>> stuff.
>>>>>>>>>>>
>>>>>>>>>>> Sometimes I have the impression that
> many of
>>> us have a
>>>>> very
>>>>>>> biased view
>>>>>>>>>>> on configuration by coming from a
> Java EE
>>> environment.
>>>>> This is
>>>>>>> ok and I miss
>>>>>>>>>>> my GlassFish sometimes but think of
> dumb
>>> programmer
>>>>> who wants
>>>>>>> to read a file
>>>>>>>>>>> simply from /etc/service/config.ext
> and
>>> override these
>>>>> defaults
>>>>>>> with
>>>>>>>>>>> ~/.config.ext and so on.
>>>>>>>>>>>
>>>>>>>>>>> Oliver
>>>>>>>>>>>
>>>>>>>>>>>> Am 06.01.15 um 23:47 schrieb
> Reinhard
>>> Sandtner:
>>>>>>>>>>>> my first idea was to add the
> method
>>> getContext()
>>>>> to
>>>>>>> Configuration but i
>>>>>>>>>>>> think if someone is able to use
> the SPI,
>>> they can
>>>>> do it on
>>>>>>> their own.
>>>>>>>>>>>> i think a 'normal‘ user
> should not
>>> see the
>>>>>>> configurationContext at all
>>>>>>>>>>>>
>>>>>>>>>>>> lg
>>>>>>>>>>>> reini
>>>>>>>>>>>>
>>>>>>>>>>>>> Am 06.01.2015 um 23:43
> schrieb Oliver
>>> B.
>>>>> Fischer
>>>>>>>>>>>>>
> <[email protected]>:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Guys, I missed somehow how
> to get a
>>>>> Configuration from
>>>>>>> the
>>>>>>>>>>>>> ConfigurationContext.
>>>>>>>>>>>>>
>>>>>>>>>>>>> BTW: I will add this method
> to
>>>>> ConfigurationContext:
>>>>>>>>>>>>>
>>>>>>>>>>>>> public static
>>> ConfigurationContext
>>>>> current(){
>>>>>>>>>>>>> return
>>>>>>>>>>>>>
>>>>>>>
>>>>>
>>>
> ServiceContext.getInstance().getService(ConfigurationContext.class).get();
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Oliver
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> N Oliver B. Fischer
>>>>>>>>>>>>> A Schönhauser Allee 64,
> 10437 Berlin,
>>>>>>> Deutschland/Germany
>>>>>>>>>>>>> P +49 30 44793251
>>>>>>>>>>>>> M +49 178 7903538
>>>>>>>>>>>>> E [email protected]
>>>>>>>>>>>>> S oliver.b.fischer
>>>>>>>>>>>>> J
> [email protected]
>>>>>>>>>>>>> X http://xing.to/obf
>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> N Oliver B. Fischer
>>>>>>>>>>> A Schönhauser Allee 64, 10437
> Berlin,
>>>>> Deutschland/Germany
>>>>>>>>>>> P +49 30 44793251
>>>>>>>>>>> M +49 178 7903538
>>>>>>>>>>> E [email protected]
>>>>>>>>>>> S oliver.b.fischer
>>>>>>>>>>> J [email protected]
>>>>>>>>>>> X http://xing.to/obf
>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> N Oliver B. Fischer
>>>>>>>>> A Schönhauser Allee 64, 10437 Berlin,
>>> Deutschland/Germany
>>>>>>>>> P +49 30 44793251
>>>>>>>>> M +49 178 7903538
>>>>>>>>> E [email protected]
>>>>>>>>> S oliver.b.fischer
>>>>>>>>> J [email protected]
>>>>>>>>> X http://xing.to/obf
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> N Oliver B. Fischer
>>>>>>> A Schönhauser Allee 64, 10437 Berlin,
> Deutschland/Germany
>>>>>>> P +49 30 44793251
>>>>>>> M +49 178 7903538
>>>>>>> E [email protected]
>>>>>>> S oliver.b.fischer
>>>>>>> J [email protected]
>>>>>>> X http://xing.to/obf
>>>>>>>
>>>>>
>>>
>
