Hi all,
I agree with you Anatole. There is no standard way there to place your
configuration data. And we must not restrict the user in that ways that
we decide how to solve this problem.
From my point of view we must provide a framework which helps the user
to solve his problem. And not the other way around.
Olive
Am 07.01.15 um 11:14 schrieb Anatole Tresch:
Hi all
I remember a long discussion on where configuration should be and where
not. In short:
- Configuration that is more related to you concrete application internals,
especially the one that is not deployment dependent, should be packaged
with your code. It has a strong cohesion with the code and there is no need
admins should have control over it.
- Configuration that is only deployment dependent and no reasonable
defaults are present should only provided externally. The application
should check its availabiolity during startup and ceed to function if parts
are missing (deployment error).
- Configuration that has resonable defaults, and may be tailored depedent
the runtime environment, should have defaults in the classpath, but being
overridable from external sources.
- There always might be exception that require overriding things
(especially thrid party integration), so the possibility of overriding
things by applications is always a good way and gives developers
flexibility. On the down side, there might be security concerns, that app
devs should not be able to change everything (in a pragrammtic approach,
leave SecurityManager off as of now).
How configuration is added from external depends on the concrete target
runtime. Could be a simple external folder on the file system (which could
be a distributed one, NFS share or whatever), or be stored and managed more
explicitly, e.g. in database (SQL, or nosql doesn't matter).
So thinking all is always external or files only is a chosen approach, it
is by far not the only valid one. It doesn't depend either of the size of
your company, it more driven by the configuration requirements and the
functionality of the tool chain around it...
Cheers,
Anatole
2015-01-07 10:55 GMT+01:00 Mark Struberg <[email protected]>:
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
--
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
