You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Lars-Fredrik Smedberg <it...@gmail.com> on 2015/11/16 23:02:25 UTC
Design question
Hi!
I'm curios if anyone have any ideas on how to solve the following scenario:
- The customers environment consists of several servers in test as well as
in production.
- The test and production servers differs in some configuration, e.g. how
to authenticate users depending on wether the server is serving external or
internal users.
Two make the case little more simple than the real case we assume that the
above two variables are the ones that determine if the server is a test
server or a production server and if its an internal or external server.
- We would like to assemble the ear artifact once and be able to use it for
testing as well as for production.
- Some applications (defined here as a jar-file consisting of functionality
placed in WEB-INF/lib in the WAR inside the EAR :)) will have configuration
that depends on the value of the two above mentioned parameters.
One way to solve this would be to override using e.g. environment variables
the properties when deploying the ear. The problem with that approach
however is that one ear can consists of multiple applications (jars) each
having their own responsible person/team. The person responsible for
deploying the ear and the environment where its being deployed would then
need to know the appliations it consists and contact each of the
responsibles.
I know the above aproach might seem a bit weird but its a large company and
not everything related to the organisation can change over night :)
One other way that I thought about was that each application (jar) would
provide the property values for each permutation of configuration that
varies... so lets assume we only have one test environment and one
production environment and only the external and internal server. That
would result in 4 property values for each property that belongs to the
configuration that varies (configuration that not change does of course
need only one value). If the property value does not vary with all the
variables some wildcard notation could perhaps be used...
How would the above best be managed / implemented using Tamaya?
Any other suggestions, I'm sure there are many ways to solve this...
Regards
LF
--
Med vänlig hälsning / Best regards
Lars-Fredrik Smedberg
STATEMENT OF CONFIDENTIALITY:
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information. If
you are not the intended recipient, please notify Lars-Fredrik Smedberg
immediately at itsmeden@gmail.com, and destroy all copies of this
message and any attachments.
Re: Design question
Posted by Lars-Fredrik Smedberg <it...@gmail.com>.
Thanks, some more questions/things inlined below :)
Best regards
LF
On Tue, Nov 17, 2015 at 11:53 PM, Anatole Tresch <at...@gmail.com> wrote:
> ... answers inline...
>
> Best
> Anatole
>
>
> 2015-11-17 21:32 GMT+01:00 Lars-Fredrik Smedberg <it...@gmail.com>:
>
> > Hi Anatole
> >
> > Thanks for taking time to answer.... please some follow ups inlined below
> > (to make sure I understood it) as well as some other questions.
> >
> > Regards
> > Lars-Fredrik
> >
> > On Tue, Nov 17, 2015 at 3:43 PM, Anatole Tresch <at...@gmail.com>
> > wrote:
> >
> > > Hi
> > >
> > > your use case basically matches what also Credit Suisse has in place,
> > which
> > > was one of the use cases Tamaya must be able to cover.
> > > In CS we have several layers of overrides:
> > >
> > > - defaults
> > > - ear config
> > > - war config
> > > - servers
> > > - tiers
> > > - network zones
> > > - products
> > >
> > >
> > Questions on the placement of configuration:
> >
> > 1. I assume that defaults are "hard-coded" in the classes?
> >
> -> Tamaya itself has nothing hardocoded. But the config team in such a
> company typically will hardocde most locations (especially the ones within
> the classpath), also with the objective of having a unified configuration
> policy on the whole company.
>
>
I see, thought you meant application configuration default values if the
configuration was not available...
>
>
> > 2. When you say ear config do you mean configuration stored in the ear
> > files META-INF folder? Same question on war config I suppose?
> >
> -> Not only. Similar to above its a decision, where to store config, about
> its format and its priority. You could also add (arbitrary) additional
> locations, lodable from the classloader as well...
>
>
> > 3. When you say server is that configuration outside the ear? E.g. our
> > server.xml when running IBM WLP? Environment variables? System
> properties?
> > Anything else?
> >
> Possibly, or as an example to the question: A dedicated folder with config
> loaded/written by some external deployment system, or a database, ...
>
>
> > 4. Could you give an example of overrides for tiers, network zones and
> > products? In our case I would assume network zones is where we deploy it,
> > internally or externally accessible for customers? Tiers - test
> > environments or production? Products is that application specific
> overrides
> > or something else?
> >
> -> tiers = business tier / presentation tier
>
Go you there...
> -> I agree network zones and deployment areas may be the same. As before:
> its a architectural decision, what makes sense. Basically if you are not
> sure, if you need it, dont model it. The less overridings and mechanisms in
> place the higher is the chance that the results are traceable and
> understood by the developers.
>
>
In our case I say that we would need 3 parameters (maybe only 2 for the
applications and 3 for the framework itself). One would be the deployment
area (internal, external etc), another one would be the staging (funtional
test, intergration test, pre production/performance test, production etc,
things that might vary is urls for services used etc) and the last one
would be a parameter used by the framework (that has been created and that
the applications uesed) to set the network zone.
Lets assume the following (which is a bit more simple than the real model)
deployment area = external | internal
staging = test | production
network zone = a | b
Do you then mean that STAGE would be a composition of the above 3, e.g.
a-external-test
b-internal-production
etc (of course all combination would not be valid)
and then you mean that one way would be to create folders matching all
above valid combinations as well as defaults for those properties that does
not vary (or for those combinations not found in the structure if any)? OR
prefix the property keys with default or the STAGE / composition in the
example above and do as you propose in your example 2 below?
I assume that if I use the folder approach it would make the handling of
xml files cleaner? Having xml files for e.g. different network zones in
different folders... your thought on this?
>
> >
> > > Just to name the most important ones. Basically there is a policy,
> which
> > > defines the format and locations of configuration.
> > > In Tamaya you would define and register multiple
> ConfigurationProviders.
> > > These providers use either a fixed or predefined ordinal for each
> > > PropertySource they create. As an example
> > > one may define a system classpath provider, reading from
> > > classpath:META-INF/cfg/${STAGE}/**/*.properties. and another provider
> > > reading from classpath:META-INF/cfg/${STAGE}/ear/**/*.properties, one
> > > reading from a server side file directory etc.
> > >
> > >
> > Which values are possible for ${STAGE} in this case? Lets assume that you
> > as an application developer have e.g. 3 network zones, 2 tiers would that
> > result in 6 different setups in 6 folders e.g. named test_internal,
> > test_external, test_common, production_.... and so on?
> >
>
> you can combine and filter configuration sections. Basically you have
> different options:
> 1) you filter configuration on read, e.g. based on the location and the
> current STAGE env. value.
> Advantage: only the matching configuration data is used and visible.
> 2) you define areas (sections) in your config tree and map things to a
> virtual section, e.g.
>
> defaults.a.b.foo=myFooValDef
> test.a.b.foo=myFooValTest
> int-test.a.b.foo=myIntegrationTestEnvValue
> prod.a.b.foo=prodValue
>
> Now cou can map the subsections (defaults, test, int-test) into one new
> aggregated section "cfg", e.g. using the functional operators provided by
> the tamaya-functions module (ConfigurationFunctions singleton).
> Let's assume our configuration policy defines the following hierarchy:
>
> defaults -> test -> int_test -> prod
>
> if the env value STAGE=test, then the final value of
> cfg.a.b.foo=myFooValTest
>
>
>
> > Do you manage to build the war and ear only once and then use the same
> > war/ear througout test and production?
> >
> Yes, e.g. imagine the following structure in the classpath:
>
> META-INF/
> |_cfg/
> |_defaults/...
> |_dev
> |_test
> |_pt
> |_prod
>
> You can have overrides based on stages. This is the mostly used mechanism
> and can be similarly applied to folders, databases, config servers...
>
>
I agree, this is the most appealing for us also I would say...
> Additional features or functions may be added in various ways:
> - using dynamic resolution functions (supported by the tamaya-resolver
> module)
>
So lets say that the configuration for some keys in e.g. the dev folder in
the structure above uses the resolver format ${key} I then assume I could
provide the default value in a properties file in the same folder and then
also be able to override it by setting environment variables, system
properties or others...
Is that would you meant by using the resolver? Any other cases you would
think of here?
> - using special configuration formats that contain configuration for
> multiple ordinal levels (e.g. servers, tier, net zones, cloud provider
> etc). This allows then the PropertySourceProvider that actually creates the
> PropertySources for such a file to perform selection and prioritzation.
> - you also use the same folder concept as above, but add additional folders
> to it.
>
> So basically regardless how complex your configuration need are, you
> should be able to determine a valid configuration depending on a number of
> properties (often env properties). Given that an artifact (eg war) should
> be able being passed through all stages identically.
>
>
We plan to try using env properties and the same war throughout... however
we might need two war artefacts, one with and one without security (se
question below)
>
>
> > Just curios, do you keep all configuration in properties format or do you
> > have other formats such as xml, json etc? We have some configuration that
> > is quiet complex and that we today use XML for.
>
>
> It is quite typical that companies use a custom xml format (Credit Suisse
> and also others e.g. do so). But as outlines above you could also work with
> property files. In many cases I would say there is no need for custom xml
> formats. If properties are not sufficient json/yaml does the job quite
> effectivly.
>
>
Do you do any validation of the json/yaml structure at startup / when
reading, e.g. using json schemas or similar? How to make sure that an
application e.g. provided a valid (syntax and semantic) json file? Using
xml we could hand them a schema to follow and "blow up" at startup if the
xml could not be validated...
>
> > So given the hierarchy of config locations/overrides a similar set of
> > > providers is build upm which themselves emit a PropertySources the by
> its
> > > ordinals reflect the overriding rules. For a big company this can be
> done
> > > by a framework team, so developers only need to know the locations
> where
> > to
> > > store configuration.
> >
> > We have wars that consists of multiple applications and some applications
> > can be deployed in more than one war (e.g. internally and externally). If
> > that application needs override (and different overrides) who is
> > responsible for doing the override at e.g. the server level? I assume
> this
> > person/role would need to understand the applications that are being
> > deployed in the war and then talk to the application responsible to
> > understand what properties to override in which way? Or did I
> misunderstand
> > you there?
> >
> I would say that the person that is responsible for packaging the final
> deployment should be responsible. I would expect this is an engineer,
> which knows the different applications bundled.
Agree, however historically this person did not have this in-depth
knowledege, however that is soemthing that we might need to change.
Again if we follow your suggestion to provide all valid combinations in
e.g. the structure then the work of overriding when deploying should
dissapere or be at least alot easier. Correct?
> If additional configuration
> is needed for operations, I would expect that operations adds it. The
> ladder could be one of the reasons that an environment property can be set
> that targets a local folder on the target machine. This enables operations
> to provide operations specific config independent of the developers.
>
>
True, we might have such cases as well...
> >
> > > The configuration metamodel can be added to the
> > > runtime on system level, or on application level.
> > >
> > >
> > Could you elaborate what you mean with the metamodel and how to apply it?
> >
>
> -> The metamodel defines how exactly configuration is designed:
> - which locations, overrides, formats
> - relevant env and system properties
> - inclusion of env and system props
> - any other customizations and extensions (e.g. filters, type
> converters, resolvers, ...).
>
> All this can be implemented and bundled as a separate jar, since Tamaya is
> loading these things using its ServiceContext SPI (by default the JDK
> ServiceLoader). So given you have a weblogic container template you can add
> Tamaya API, its implementation and supporting libraries AND your metamodel
> to the systemclasspath of WLS. Done so, every WLS/app in your company is
> configurable exactly the same way.
>
Havent looked into this feature of Tamaya, so Tamaya will actually validate
that the model is followed in runtime or?
>
> > In an enterprise context additionally classloading aspects are important
> > as
> > > well. I started in the cp-support module to add code handling some of
> the
> > > challenges. But this is still work in progress. What is there is an
> > > implementation of *ServiceContext* (Tamaya'as service loading SPI),
> which
> > > considers classloader hierarchies. This could probably also used to
> > > implement a classloader aware *ConfigurationProvider* managing a
> > > *ConfigurationContext* e.g. per ear/app.
> > > But I think a much better way is probably to simply delegate the
> > lifecycle
> > > management of app configuration in Java EE to CDI using an
> > > @ApplicationScope levelled bean that can be integrated by a bridging
> > Tamaya
> > > ProprtySource. Globally shared system configuration (loaded on system
> > > classloader level), still may ve globally managed. And app leveled
> config
> > > (and property sources) are managed by CDI. In Credit Suisse this works
> > fine
> > > so far.
> > >
> > > Cheers,
> > > Anatole
> > >
> > >
> > >
> > Another questions (that I understood that might be adressed in the future
> > in Tamaya) is web.xml. Lets assume that we have two test environments and
> > one of them require security and a production environment that of course
> > require security. Using the security-constraint in web.xml to achieve
> this
> > would result in two different web.xml files and we would not have the
> > possibility to use the same war/ear artifact everywhere.
> >
>
> Yes and no. If I need to reconfigure the wex.xml I will not be able to
> have one single war, since
> Java EE does not support config flexibility the way it would be useful here
> (nevertheless mind the
> so called *alt-dd *mechanism,
Haven't tried it before... did google it and did not find any good / easy
understandable example (might be due to the late hour)... but if you have
any pointers to example it would be great
> which allows to achieve at least some of
> these aspects). But activating or deactivating a feature by configuration
> is still possible (in the worst case I would load e.g. a ServletFilter
> class that in a certain environment just does nothing, but is activated by
> config in another context).
So in our case where we would like our security-constraint only for some
test environments and production we could setup a filter that checks the
configuration and decides to use isUserInRole(,,,) of the
HttpServletRequest passed... I guess that could work. We also uses
ServletRequestListeners to sort of bridge between the servlet and CDI worls
in a similar way to Deltaspike so I guess that could also be a place to put
that isUserInRole(...) call....
> So I assume we should get quite far with what
> is already possible. With Java EE 8 especially Security gets much more
> pluggable, so this should solve this kind of scenario here as well.
>
>
Do you know where I can read about this upcoming pluggable security model
now?
> Do you have the same scenario? If so how did you solve it? I've seen that
> > e.g. tomcat (i think) lets you override the web.xml (or part of it) by
> > haveing a second web.xml on the file system external to the war. I did
> not
> > see anything like this on WLP but it might just be something I missed?
>
> -> Look at
>
> https://docs.oracle.com/cd/E13222_01/wls/docs81b/programming/app_xml.html
> for WLS as well....
>
>
> --
> *Anatole Tresch*
> Java Engineer & Architect, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
>
> *Switzerland, Europe Zurich, GMT+1*
> *Twitter: @atsticks*
> *Blogs: **http://javaremarkables.blogspot.ch/
> <http://javaremarkables.blogspot.ch/>*
>
> *Google: atsticksMobile +41-76 344 62 79*
>
--
Med vänlig hälsning / Best regards
Lars-Fredrik Smedberg
STATEMENT OF CONFIDENTIALITY:
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information. If
you are not the intended recipient, please notify Lars-Fredrik Smedberg
immediately at itsmeden@gmail.com, and destroy all copies of this
message and any attachments.
Re: Design question
Posted by Anatole Tresch <at...@gmail.com>.
... answers inline...
Best
Anatole
2015-11-17 21:32 GMT+01:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> Hi Anatole
>
> Thanks for taking time to answer.... please some follow ups inlined below
> (to make sure I understood it) as well as some other questions.
>
> Regards
> Lars-Fredrik
>
> On Tue, Nov 17, 2015 at 3:43 PM, Anatole Tresch <at...@gmail.com>
> wrote:
>
> > Hi
> >
> > your use case basically matches what also Credit Suisse has in place,
> which
> > was one of the use cases Tamaya must be able to cover.
> > In CS we have several layers of overrides:
> >
> > - defaults
> > - ear config
> > - war config
> > - servers
> > - tiers
> > - network zones
> > - products
> >
> >
> Questions on the placement of configuration:
>
> 1. I assume that defaults are "hard-coded" in the classes?
>
-> Tamaya itself has nothing hardocoded. But the config team in such a
company typically will hardocde most locations (especially the ones within
the classpath), also with the objective of having a unified configuration
policy on the whole company.
> 2. When you say ear config do you mean configuration stored in the ear
> files META-INF folder? Same question on war config I suppose?
>
-> Not only. Similar to above its a decision, where to store config, about
its format and its priority. You could also add (arbitrary) additional
locations, lodable from the classloader as well...
> 3. When you say server is that configuration outside the ear? E.g. our
> server.xml when running IBM WLP? Environment variables? System properties?
> Anything else?
>
Possibly, or as an example to the question: A dedicated folder with config
loaded/written by some external deployment system, or a database, ...
> 4. Could you give an example of overrides for tiers, network zones and
> products? In our case I would assume network zones is where we deploy it,
> internally or externally accessible for customers? Tiers - test
> environments or production? Products is that application specific overrides
> or something else?
>
-> tiers = business tier / presentation tier
-> I agree network zones and deployment areas may be the same. As before:
its a architectural decision, what makes sense. Basically if you are not
sure, if you need it, dont model it. The less overridings and mechanisms in
place the higher is the chance that the results are traceable and
understood by the developers.
>
>
> > Just to name the most important ones. Basically there is a policy, which
> > defines the format and locations of configuration.
> > In Tamaya you would define and register multiple ConfigurationProviders.
> > These providers use either a fixed or predefined ordinal for each
> > PropertySource they create. As an example
> > one may define a system classpath provider, reading from
> > classpath:META-INF/cfg/${STAGE}/**/*.properties. and another provider
> > reading from classpath:META-INF/cfg/${STAGE}/ear/**/*.properties, one
> > reading from a server side file directory etc.
> >
> >
> Which values are possible for ${STAGE} in this case? Lets assume that you
> as an application developer have e.g. 3 network zones, 2 tiers would that
> result in 6 different setups in 6 folders e.g. named test_internal,
> test_external, test_common, production_.... and so on?
>
you can combine and filter configuration sections. Basically you have
different options:
1) you filter configuration on read, e.g. based on the location and the
current STAGE env. value.
Advantage: only the matching configuration data is used and visible.
2) you define areas (sections) in your config tree and map things to a
virtual section, e.g.
defaults.a.b.foo=myFooValDef
test.a.b.foo=myFooValTest
int-test.a.b.foo=myIntegrationTestEnvValue
prod.a.b.foo=prodValue
Now cou can map the subsections (defaults, test, int-test) into one new
aggregated section "cfg", e.g. using the functional operators provided by
the tamaya-functions module (ConfigurationFunctions singleton).
Let's assume our configuration policy defines the following hierarchy:
defaults -> test -> int_test -> prod
if the env value STAGE=test, then the final value of
cfg.a.b.foo=myFooValTest
> Do you manage to build the war and ear only once and then use the same
> war/ear througout test and production?
>
Yes, e.g. imagine the following structure in the classpath:
META-INF/
|_cfg/
|_defaults/...
|_dev
|_test
|_pt
|_prod
You can have overrides based on stages. This is the mostly used mechanism
and can be similarly applied to folders, databases, config servers...
Additional features or functions may be added in various ways:
- using dynamic resolution functions (supported by the tamaya-resolver
module)
- using special configuration formats that contain configuration for
multiple ordinal levels (e.g. servers, tier, net zones, cloud provider
etc). This allows then the PropertySourceProvider that actually creates the
PropertySources for such a file to perform selection and prioritzation.
- you also use the same folder concept as above, but add additional folders
to it.
So basically regardless how complex your configuration need are, you
should be able to determine a valid configuration depending on a number of
properties (often env properties). Given that an artifact (eg war) should
be able being passed through all stages identically.
> Just curios, do you keep all configuration in properties format or do you
> have other formats such as xml, json etc? We have some configuration that
> is quiet complex and that we today use XML for.
It is quite typical that companies use a custom xml format (Credit Suisse
and also others e.g. do so). But as outlines above you could also work with
property files. In many cases I would say there is no need for custom xml
formats. If properties are not sufficient json/yaml does the job quite
effectivly.
> So given the hierarchy of config locations/overrides a similar set of
> > providers is build upm which themselves emit a PropertySources the by its
> > ordinals reflect the overriding rules. For a big company this can be done
> > by a framework team, so developers only need to know the locations where
> to
> > store configuration.
>
> We have wars that consists of multiple applications and some applications
> can be deployed in more than one war (e.g. internally and externally). If
> that application needs override (and different overrides) who is
> responsible for doing the override at e.g. the server level? I assume this
> person/role would need to understand the applications that are being
> deployed in the war and then talk to the application responsible to
> understand what properties to override in which way? Or did I misunderstand
> you there?
>
I would say that the person that is responsible for packaging the final
deployment should be responsible. I would expect this is an engineer,
which knows the different applications bundled. If additional configuration
is needed for operations, I would expect that operations adds it. The
ladder could be one of the reasons that an environment property can be set
that targets a local folder on the target machine. This enables operations
to provide operations specific config independent of the developers.
>
> > The configuration metamodel can be added to the
> > runtime on system level, or on application level.
> >
> >
> Could you elaborate what you mean with the metamodel and how to apply it?
>
-> The metamodel defines how exactly configuration is designed:
- which locations, overrides, formats
- relevant env and system properties
- inclusion of env and system props
- any other customizations and extensions (e.g. filters, type
converters, resolvers, ...).
All this can be implemented and bundled as a separate jar, since Tamaya is
loading these things using its ServiceContext SPI (by default the JDK
ServiceLoader). So given you have a weblogic container template you can add
Tamaya API, its implementation and supporting libraries AND your metamodel
to the systemclasspath of WLS. Done so, every WLS/app in your company is
configurable exactly the same way.
> In an enterprise context additionally classloading aspects are important
> as
> > well. I started in the cp-support module to add code handling some of the
> > challenges. But this is still work in progress. What is there is an
> > implementation of *ServiceContext* (Tamaya'as service loading SPI), which
> > considers classloader hierarchies. This could probably also used to
> > implement a classloader aware *ConfigurationProvider* managing a
> > *ConfigurationContext* e.g. per ear/app.
> > But I think a much better way is probably to simply delegate the
> lifecycle
> > management of app configuration in Java EE to CDI using an
> > @ApplicationScope levelled bean that can be integrated by a bridging
> Tamaya
> > ProprtySource. Globally shared system configuration (loaded on system
> > classloader level), still may ve globally managed. And app leveled config
> > (and property sources) are managed by CDI. In Credit Suisse this works
> fine
> > so far.
> >
> > Cheers,
> > Anatole
> >
> >
> >
> Another questions (that I understood that might be adressed in the future
> in Tamaya) is web.xml. Lets assume that we have two test environments and
> one of them require security and a production environment that of course
> require security. Using the security-constraint in web.xml to achieve this
> would result in two different web.xml files and we would not have the
> possibility to use the same war/ear artifact everywhere.
>
Yes and no. If I need to reconfigure the wex.xml I will not be able to
have one single war, since
Java EE does not support config flexibility the way it would be useful here
(nevertheless mind the
so called *alt-dd *mechanism, which allows to achieve at least some of
these aspects). But activating or deactivating a feature by configuration
is still possible (in the worst case I would load e.g. a ServletFilter
class that in a certain environment just does nothing, but is activated by
config in another context). So I assume we should get quite far with what
is already possible. With Java EE 8 especially Security gets much more
pluggable, so this should solve this kind of scenario here as well.
Do you have the same scenario? If so how did you solve it? I've seen that
> e.g. tomcat (i think) lets you override the web.xml (or part of it) by
> haveing a second web.xml on the file system external to the war. I did not
> see anything like this on WLP but it might just be something I missed?
-> Look at
https://docs.oracle.com/cd/E13222_01/wls/docs81b/programming/app_xml.html
for WLS as well....
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: Design question
Posted by Lars-Fredrik Smedberg <it...@gmail.com>.
Hi Anatole
Thanks for taking time to answer.... please some follow ups inlined below
(to make sure I understood it) as well as some other questions.
Regards
Lars-Fredrik
On Tue, Nov 17, 2015 at 3:43 PM, Anatole Tresch <at...@gmail.com> wrote:
> Hi
>
> your use case basically matches what also Credit Suisse has in place, which
> was one of the use cases Tamaya must be able to cover.
> In CS we have several layers of overrides:
>
> - defaults
> - ear config
> - war config
> - servers
> - tiers
> - network zones
> - products
>
>
Questions on the placement of configuration:
1. I assume that defaults are "hard-coded" in the classes?
2. When you say ear config do you mean configuration stored in the ear
files META-INF folder? Same question on war config I suppose?
3. When you say server is that configuration outside the ear? E.g. our
server.xml when running IBM WLP? Environment variables? System properties?
Anything else?
4. Could you give an example of overrides for tiers, network zones and
products? In our case I would assume network zones is where we deploy it,
internally or externally accessible for customers? Tiers - test
environments or production? Products is that application specific overrides
or something else?
> Just to name the most important ones. Basically there is a policy, which
> defines the format and locations of configuration.
> In Tamaya you would define and register multiple ConfigurationProviders.
> These providers use either a fixed or predefined ordinal for each
> PropertySource they create. As an example
> one may define a system classpath provider, reading from
> classpath:META-INF/cfg/${STAGE}/**/*.properties. and another provider
> reading from classpath:META-INF/cfg/${STAGE}/ear/**/*.properties, one
> reading from a server side file directory etc.
>
>
Which values are possible for ${STAGE} in this case? Lets assume that you
as an application developer have e.g. 3 network zones, 2 tiers would that
result in 6 different setups in 6 folders e.g. named test_internal,
test_external, test_common, production_.... and so on?
Do you manage to build the war and ear only once and then use the same
war/ear througout test and production?
Just curios, do you keep all configuration in properties format or do you
have other formats such as xml, json etc? We have some configuration that
is quiet complex and that we today use XML for.
So given the hierarchy of config locations/overrides a similar set of
> providers is build upm which themselves emit a PropertySources the by its
> ordinals reflect the overriding rules. For a big company this can be done
> by a framework team, so developers only need to know the locations where to
> store configuration.
We have wars that consists of multiple applications and some applications
can be deployed in more than one war (e.g. internally and externally). If
that application needs override (and different overrides) who is
responsible for doing the override at e.g. the server level? I assume this
person/role would need to understand the applications that are being
deployed in the war and then talk to the application responsible to
understand what properties to override in which way? Or did I misunderstand
you there?
> The configuration metamodel can be added to the
> runtime on system level, or on application level.
>
>
Could you elaborate what you mean with the metamodel and how to apply it?
> In an enterprise context additionally classloading aspects are important as
> well. I started in the cp-support module to add code handling some of the
> challenges. But this is still work in progress. What is there is an
> implementation of *ServiceContext* (Tamaya'as service loading SPI), which
> considers classloader hierarchies. This could probably also used to
> implement a classloader aware *ConfigurationProvider* managing a
> *ConfigurationContext* e.g. per ear/app.
> But I think a much better way is probably to simply delegate the lifecycle
> management of app configuration in Java EE to CDI using an
> @ApplicationScope levelled bean that can be integrated by a bridging Tamaya
> ProprtySource. Globally shared system configuration (loaded on system
> classloader level), still may ve globally managed. And app leveled config
> (and property sources) are managed by CDI. In Credit Suisse this works fine
> so far.
>
> Cheers,
> Anatole
>
>
>
Another questions (that I understood that might be adressed in the future
in Tamaya) is web.xml. Lets assume that we have two test environments and
one of them require security and a production environment that of course
require security. Using the security-constraint in web.xml to achieve this
would result in two different web.xml files and we would not have the
possibility to use the same war/ear artifact everywhere.
Do you have the same scenario? If so how did you solve it? I've seen that
e.g. tomcat (i think) lets you override the web.xml (or part of it) by
haveing a second web.xml on the file system external to the war. I did not
see anything like this on WLP but it might just be something I missed?
>
>
>
> 2015-11-16 23:02 GMT+01:00 Lars-Fredrik Smedberg <it...@gmail.com>:
>
> > Hi!
> >
> > I'm curios if anyone have any ideas on how to solve the following
> scenario:
> >
> > - The customers environment consists of several servers in test as well
> as
> > in production.
> > - The test and production servers differs in some configuration, e.g. how
> > to authenticate users depending on wether the server is serving external
> or
> > internal users.
> >
> > Two make the case little more simple than the real case we assume that
> the
> > above two variables are the ones that determine if the server is a test
> > server or a production server and if its an internal or external server.
> >
> > - We would like to assemble the ear artifact once and be able to use it
> for
> > testing as well as for production.
> > - Some applications (defined here as a jar-file consisting of
> functionality
> > placed in WEB-INF/lib in the WAR inside the EAR :)) will have
> configuration
> > that depends on the value of the two above mentioned parameters.
> >
> > One way to solve this would be to override using e.g. environment
> variables
> > the properties when deploying the ear. The problem with that approach
> > however is that one ear can consists of multiple applications (jars) each
> > having their own responsible person/team. The person responsible for
> > deploying the ear and the environment where its being deployed would then
> > need to know the appliations it consists and contact each of the
> > responsibles.
> >
> > I know the above aproach might seem a bit weird but its a large company
> and
> > not everything related to the organisation can change over night :)
> >
> > One other way that I thought about was that each application (jar) would
> > provide the property values for each permutation of configuration that
> > varies... so lets assume we only have one test environment and one
> > production environment and only the external and internal server. That
> > would result in 4 property values for each property that belongs to the
> > configuration that varies (configuration that not change does of course
> > need only one value). If the property value does not vary with all the
> > variables some wildcard notation could perhaps be used...
> >
> > How would the above best be managed / implemented using Tamaya?
> >
> > Any other suggestions, I'm sure there are many ways to solve this...
> >
> > Regards
> > LF
> >
> >
> > --
> > Med vänlig hälsning / Best regards
> >
> > Lars-Fredrik Smedberg
> >
> > STATEMENT OF CONFIDENTIALITY:
> > The information contained in this electronic message and any
> > attachments to this message are intended for the exclusive use of the
> > address(es) and may contain confidential or privileged information. If
> > you are not the intended recipient, please notify Lars-Fredrik Smedberg
> > immediately at itsmeden@gmail.com, and destroy all copies of this
> > message and any attachments.
> >
>
>
>
> --
> *Anatole Tresch*
> Java Engineer & Architect, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
>
> *Switzerland, Europe Zurich, GMT+1*
> *Twitter: @atsticks*
> *Blogs: **http://javaremarkables.blogspot.ch/
> <http://javaremarkables.blogspot.ch/>*
>
> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
>
--
Med vänlig hälsning / Best regards
Lars-Fredrik Smedberg
STATEMENT OF CONFIDENTIALITY:
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information. If
you are not the intended recipient, please notify Lars-Fredrik Smedberg
immediately at itsmeden@gmail.com, and destroy all copies of this
message and any attachments.
Re: Design question
Posted by Anatole Tresch <at...@gmail.com>.
Hi
your use case basically matches what also Credit Suisse has in place, which
was one of the use cases Tamaya must be able to cover.
In CS we have several layers ofer overrides:
- defaults
- ear config
- war config
- servers
- tiers
- network zones
- products
Just to name the most important ones. Basically there is a policy, which
defines the format and locations of configuration.
In Tamaya you would define and register multiple ConfigurationProviders.
These providers use either a fixed or predefined ordinal for each
PropertySource they create. As an example
one may define a system classpath provider, reading from
classpath:META-INF/cfg/${STAGE}/**/*.properties. and another provider
reading from classpath:META-INF/cfg/${STAGE}/ear/**/*.properties, one
reading from a server side file directory etc.
So given the hierarchy of config locations/overrides a similar set of
providers is build upm which themselves emit a PropertySources the by its
ordinals reflect the overriding rules. For a big company this can be done
by a framework team, so developers only need to know the locations where to
store configuration. The configuration metamodel can be added to the
runtime on system level, or on application level.
In an enterprise context additionally classloading aspects are important as
well. I started in the cp-support module to add code handling some of the
challenges. But this is still work in progress. What is there is an
implementation of *ServiceContext* (Tamaya'as service loading SPI), which
considers classloader hierarchies. This could probably also used to
implement a classloader aware *ConfigurationProvider* managing a
*ConfigurationContext* e.g. per ear/app.
But I think a much better way is probably to simply delegate the lifecycle
management of app configuration in Java EE to CDI using an
@ApplicationScope levelled bean that can be integrated by a bridging Tamaya
ProprtySource. Globally shared system configuration (loaded on system
classloader level), still may ve globally managed. And app leveled config
(and property sources) are managed by CDI. In Credit Suisse this works fine
so far.
Cheers,
Anatole
2015-11-16 23:02 GMT+01:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> Hi!
>
> I'm curios if anyone have any ideas on how to solve the following scenario:
>
> - The customers environment consists of several servers in test as well as
> in production.
> - The test and production servers differs in some configuration, e.g. how
> to authenticate users depending on wether the server is serving external or
> internal users.
>
> Two make the case little more simple than the real case we assume that the
> above two variables are the ones that determine if the server is a test
> server or a production server and if its an internal or external server.
>
> - We would like to assemble the ear artifact once and be able to use it for
> testing as well as for production.
> - Some applications (defined here as a jar-file consisting of functionality
> placed in WEB-INF/lib in the WAR inside the EAR :)) will have configuration
> that depends on the value of the two above mentioned parameters.
>
> One way to solve this would be to override using e.g. environment variables
> the properties when deploying the ear. The problem with that approach
> however is that one ear can consists of multiple applications (jars) each
> having their own responsible person/team. The person responsible for
> deploying the ear and the environment where its being deployed would then
> need to know the appliations it consists and contact each of the
> responsibles.
>
> I know the above aproach might seem a bit weird but its a large company and
> not everything related to the organisation can change over night :)
>
> One other way that I thought about was that each application (jar) would
> provide the property values for each permutation of configuration that
> varies... so lets assume we only have one test environment and one
> production environment and only the external and internal server. That
> would result in 4 property values for each property that belongs to the
> configuration that varies (configuration that not change does of course
> need only one value). If the property value does not vary with all the
> variables some wildcard notation could perhaps be used...
>
> How would the above best be managed / implemented using Tamaya?
>
> Any other suggestions, I'm sure there are many ways to solve this...
>
> Regards
> LF
>
>
> --
> Med vänlig hälsning / Best regards
>
> Lars-Fredrik Smedberg
>
> STATEMENT OF CONFIDENTIALITY:
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> address(es) and may contain confidential or privileged information. If
> you are not the intended recipient, please notify Lars-Fredrik Smedberg
> immediately at itsmeden@gmail.com, and destroy all copies of this
> message and any attachments.
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*