Use Cases

[Anatole Tresch]

Hi all

we are already discussing many things, which is great, but I like also to open a thread, where we explicitly focus on the use cases that such a JSR should cover.

My experience is that this helps also to better focus on subsequent more detailed discussions...

Cheers,

Anatole

[nicolas de loof]

One of them :

As an Ops, 

when I have to deploy a java application

I want a standard way to define it's configuration, resources and environment

to integrate with my provisioning tooling

2013/10/22 Anatole Tresch <atst...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "java-config" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-config...@googlegroups.com.
Visit this group at http://groups.google.com/group/java-config.
For more options, visit https://groups.google.com/groups/opt_out.

[Jaromir Hamala]

Hi all,

another use case:

I want standardized way (interface? maybe, but in broader sense of the word) get a configuration for already deployed application.

Jaroimir

[Juven Xu]

As a release engineer, when I have a package which is to be deployed to multiple environments, I want to be able to inject configurations into the package and then deploy.

[nicolas de loof]

+1 on this one.

ability to deploy the same binary on various platforms/environments but just change the injected configuration is a major topic.

2013/10/28 Juven Xu <juve...@gmail.com>

--

[Antonio Goncalves]

As a developper I want to be able to configure something like this :

public MyPojo {

  private String currency;

  private Long currencyRate;

  // complex algorithm based on the currency

}

How do I configure that depending if my app is dealing with dollars or euros ? The DeltaSpike way of doing is something like :

public MyPojo {

  @Inject @Config("myCurrency")

  private String currency;

  @Inject @Config("myCurrencyRate")

  private Long currencyRate;

  // complex algorithm based on the currency

}

The Seam Config way of doing is quite clever. They use a namespace that is relative to the packing. So, without changing the initial code (so, forget about the @Inject above) they have an XML file that is able to override each attribute of any file.

[Arjan Tijms]

I'm still not sure if this is within the scope of this JSR, but just to have mentioned it:

As a Java EE user (developer or devops) I would like to be able to package different versions of deployment descriptor fragments within my Java EE application archive, and be able to select which one is used via a -D command line argument.

E.g. have the following file structure within the application archive (a .war in this case):

WEB-INF

    conf

        dev

            web-fragment.xml

        qa

            web-fragment.xml

        live

            web-fragment.xml

And then either directly be able to say that conf/dev/web-fragment.xml should be used, or do this indirectly via an include directive and a placeholder in the main deployment descriptor for this type of fragment (in this case web.xml):

<web-app> 

    ... 

    <fragment>WEB-INF/conf/${mycompany.staging}/web-fragment.xml</fragment>

</web-app>

On Tuesday, October 22, 2013 10:48:03 PM UTC+2, Anatole Tresch wrote:

[Anatole Tresch]

I completely agree, that we must be able to support different deployment configs. If the solution proposed would be sufficient for all use cases, IMO is arguable, since all files are still packaged with the application, which is exactly one thing, we wanted to prevent with this JSR in the future. I think, we can still do such a thing, but I see a more general concept, which is to create an abstraction how a configuration or deployment descriptor is stored and managed (basically it must be accessible, but the exact location is basically irelevant).

One point, we also have to decide, is, if we should explicitly address how each part of EE (JSR) should support the new config mechanism in detail. My fear is that such a scope will prevent the JSR from being successful, since it implies many dependencies to the other specifications. Therefore I tend to say, lets scope on the mechanisms primarily:

• allow the config JSR to manage/load deployment configuration, descriptors in the format as required by any of the EE parts defining them (basically in any textual format!)
• support a mechanism to allow filtering of the deployment descriptor, or selecting completely different descriptors based on the current environment (stage may be only one filtering aspect!)..
• define a general placeholder mechanism for replacing placeholders, which also can be accessed explicitly by an according API.

In the worst case its similar to the WS specification in EE7, which do not support @Inject, since they were not updated for EE7. But we would be much faster in progressing with this JSR, which would make it easier for being supported also by other JSRs until EE8 is final.

I will also add some comments on SE/EE scope in the other thread....

-Anatole

[nicolas de loof]

2013/10/31 Anatole Tresch <atst...@gmail.com>

I completely agree, that we must be able to support different deployment configs. If the solution proposed would be sufficient for all use cases, IMO is arguable, since all files are still packaged with the application, which is exactly one thing, we wanted to prevent with this JSR in the future. I think, we can still do such a thing, but I see a more general concept, which is to create an abstraction how a configuration or deployment descriptor is stored and managed (basically it must be accessible, but the exact location is basically irelevant).

Fully agree. We have to get rid with the paradigm to "package your config within your WAR" that breaks flexibility to embrace various environments. Some standard way to access a configuration resource let frameworks / other JSR decouple from actual descriptor location, and option to store them externally with a large set of (vendor specific) options. 

 

--

[Antonio Goncalves]

On Thu, Oct 31, 2013 at 11:07 AM, nicolas de loof <nicolas...@gmail.com> wrote:

Fully agree. We have to get rid with the paradigm to "package your config within your WAR" that breaks flexibility to embrace various environments. Some standard way to access a configuration resource let frameworks / other JSR decouple from actual descriptor location, and option to store them externally with a large set of (vendor specific) options. 

@nicolas Always be careful with backward compatibility. We don't want to "get rid", we want to add another one. Packaging config within a war still has to work

@anatole You are right, trying to push JavaConfig to all the other specs in EE 8 will be very risky. Your example is good : SOAP Web Services (JAX-WS) hasn't been updated in EE 7, so injection doesn't work for example. Let's keep it simple and efficient for a v1.0 and try to push it everywhere in EE 9 (I know, a long time to wait for ;o)

--
Antonio Goncalves
Software architect and Java Champion

Web site | Twitter | LinkedIn | Paris JUG | Devoxx France

[nicolas de loof]

2013/10/31 Antonio Goncalves <antonio....@gmail.com>

On Thu, Oct 31, 2013 at 11:07 AM, nicolas de loof <nicolas...@gmail.com> wrote:

Fully agree. We have to get rid with the paradigm to "package your config within your WAR" that breaks flexibility to embrace various environments. Some standard way to access a configuration resource let frameworks / other JSR decouple from actual descriptor location, and option to store them externally with a large set of (vendor specific) options. 

@nicolas Always be careful with backward compatibility. We don't want to "get rid", we want to add another one. Packaging config within a war still has to work

You ask a jenkins guy to be careful with backward compatibility ? ;P

not saying config in a war don't have to be supported, just that config API abstraction gives more flexibility. 

[Antonio Goncalves]

The configuration system in DeltaSpike uses, what they call, Sources (http://deltaspike.apache.org/configuration.html#configsource). Configuration comes from several Sources : 

• System properties
  
• Environment properties
  
• JNDI values
  
• Properties file values (default filename is "META-INF/apache-deltaspike.properties")
  

These sources have a default priority (System first.... properties file last) that can be changed. So we could easily say "by default, the WEB-INF/classes directory is a source that has a priority higher that an external file". This way, by default, if there is a config file within a war, it will have higher priority, meaning Java EE components will behave as they use too. Get rid of this file from the war, then the following source (external file) will get into account.

And of course, this default behavior can be changed

[Werner Keil]

On Thursday, October 31, 2013 11:16:28 AM UTC+1, nicolas de loof wrote:

2013/10/31 Antonio Goncalves <antonio....@gmail.com>

On Thu, Oct 31, 2013 at 11:07 AM, nicolas de loof <nicolas...@gmail.com> wrote:

Fully agree. We have to get rid with the paradigm to "package your config within your WAR" that breaks flexibility to embrace various environments. Some standard way to access a configuration resource let frameworks / other JSR decouple from actual descriptor location, and option to store them externally with a large set of (vendor specific) options. 

@nicolas Always be careful with backward compatibility. We don't want to "get rid", we want to add another one. Packaging config within a war still has to work

You ask a jenkins guy to be careful with backward compatibility ? ;P

not saying config in a war don't have to be supported, just that config API abstraction gives more flexibility. 

Jenkins is certainly still backward compatible with Hudson in most cases;-D

Werner

[nicolas de loof]

Not really what I had in mind :P

I'm fighting with git-plugin legacy codebase for few weeks to get git-plugin 2.0 released. Makes me crazy

2013/10/31 Werner Keil <werne...@gmail.com>

--

[Arjan Tijms]

On Thursday, October 31, 2013 12:54:51 AM UTC+1, Anatole Tresch wrote:

If the solution proposed would be sufficient for all use cases, IMO is arguable, since all files are still packaged with the application, which is exactly one thing, we wanted to prevent with this JSR in the future.

Of course, and this is certainly not the main idea of the proposal. Sorry that I wasn't more clear before, but the proposal was that choosing between deployment descriptors pre-packaged in the application archive should *also* be supported.

It was absolutely never intended that this should be the only way.

The place holders that I mentioned were already one way to feed external values into the existing deployment descriptors. Such values could come from -D parameters, property files, etc. If Expression Language would be used for those place holders, you'll more or less automatically get the means to build powerful resolvers that can retrieve a value from multiple sources and optionally allow the user to ask that a value comes from a specific source only.

The other way would be that the mentioned deployment fragments should be loadable from both the archive, as well as from an external source.

They address somewhat different use cases, and both are important IMHO.

The first use case is for a potentially small and agile devops team, where in-house developed software is deployed to in-house servers. In that case there's a fixed number of stages to deploy to, and all those stages are known in advance to everyone. Because of devops it's one team and there's no need for operations to hide configuration from engineers (they are the same team, engineers are operators). The existing situation in Java EE doesn't work here, since there's no concept of choosing between the embedded deployment descriptors.

The other use case is that of a potentially bigger and/or less agile team, where there is a separation between engineers and operations, and where operations need to add or change configuration independent from the engineering team. This same use case would apply for applications that are externally obtained and need to be integrated in the local IT infrastructure.

 

In the worst case its similar to the WS specification in EE7, which do not support @Inject, since they were not updated for EE7. But we would be much faster in progressing with this JSR, which would make it easier for being supported also by other JSRs until EE8 is final.

Yes, definitely. 

It would be great if ALL Java EE specs would load their deployment descriptors via a central configuration mechanism, but this should not be mandated. It would already be a major step forward if one or two specs would use such a central mechanism. My guess is that most people would like Servlet to support this, as web.xml is arguably the most important deployment descriptor for many people. Java EE's own application.xml en ejb-jar.xml might be the second most important ones.

Grtz,

Arjan

[Arjan Tijms]

On Thursday, October 31, 2013 11:07:05 AM UTC+1, nicolas de loof wrote:

Fully agree. We have to get rid with the paradigm to "package your config within your WAR" that breaks flexibility to embrace various environments.

I obviously don't agree with this ;)

Package your config within your WAR is a powerful mechanism for creating self-contained applications that have no further dependencies on hidden or proprietary configuration.

In a devops team it makes a lot of sense to put all configuration within the same project where everyone can edit and see it. The version of the configuration is also automatically in sync with the application code. A build can be directly deployed to any AS, without that AS or environment needing to be specially prepared with configuration that matches that stage and the particular version of the application that's going to be deployed.

Of course this is certainly not always possible, so as I mentioned in the other thread it should not be the only paradigm, but "package your config within your WAR" is a very useful and incredibly powerful paradigm that can massively simplify the deployment pipeline and it's definitely not something we should get rid off IMO.

 

[Anatole Tresch]

Hi all

this makes sense. Also here in the bank we have exact the same concept implemented (with an overwhelming complexity of about 20 "sources") - though the implementation is currently hardcoded,

I would also hide these details behind an interface, so clients may provide their own implementations. In combination with some composition mechanisms (add, or, subtract, override) we would have a very flexible

configuration engine, that should be able to cover more most use cases.

-Anatole

[Antonio Goncalves]

An interesting blog about how to inject external configuration using CDI and Expression Language : 

https://weblogs.java.net/blog/mriem/archive/2013/11/01/jsf-tip-31-migrate-your-managedproperty-annotations

--

You received this message because you are subscribed to the Google Groups "java-config" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-config...@googlegroups.com.
Visit this group at http://groups.google.com/group/java-config.
For more options, visit https://groups.google.com/groups/opt_out.

[Arjan Tijms]

On Friday, November 1, 2013 7:32:27 PM UTC+1, Antonio Goncalves wrote:

An interesting blog about how to inject external configuration using CDI and Expression Language : 

https://weblogs.java.net/blog/mriem/archive/2013/11/01/jsf-tip-31-migrate-your-managedproperty-annotations

This is a great example indeed!

It's also not that difficult to attach converters and validators to such an annotation. We did such a thing for a similar kind of annotation in OmniFaces (it's tailored specifically for request parameters while Manfred's example is for general EL expressions). You could use it like this then:

   // Like <f:viewParam name="date" value="#{bean.date}" converterMessage="..."><f:convertDateTime pattern="yyyyMMdd">

    @Inject @Param(

        converterClass = DateTimeConverter.class,

        converterAttributes = @Attribute(name="pattern", value="yyyyMMdd"),

        converterMessage="{1}: \"{0}\" is not the date format we had in mind! Please use the format yyyyMMdd.")

    private ParamValue<Date> date;

See http://showcase.omnifaces.org/cdi/Param for a live example and https://code.google.com/p/omnifaces/source/browse/src/org/omnifaces/cdi/param/RequestParameterProducer.java for the producer.

Because of the type-safeness issue that Manfred mentioned in his blog you cannot create a generic producer directly. You either have to resort to a producer per type, or introduce a generic wrapper as we did for OmniFaces.

Another alternative as I recently learned is to use a CDI extension that scans which injection points there are in the application and dynamically registers producers for each specific type.

[Christian Beikov]

I have an use case where I need a hierarchical/graph model of contexts for configurations. For example there might be some kind of layering:

Layer 0: Default App configuration
Layer 1: Tenant specific configuration
Layer 2: User specific configuration

Configurations made in the tenant or user layer override the default app configuration etc.

Regards,
Christian

[Anatole Tresch]

Hi, 

this makes complete sense and basically is a specification of the general problem of combining different sub-configurations into final (consumable) configurations.

Combination can be basically mapped to operations such as union, subtraction, intersection, override).

I could also image to define some kind of definition language, such as

"('company:myCompany'+'net:intranet'+'runtime:wls')>server:123.111.111.001>app:myApp>tenant:tenant1>user:johndoe"

, whereas

• + = union
• > add/override

The above in words would mean:

Access a configuration which is

• a union of company:myCompany, net:intranetand runtime:wls
• extended/overriden by server:123.111.111.001
• extended/overriden by app:myApp
• extended/overriden by tenant:tenant1
• extended/overriden by user:johndoe

Regards,

Anatole

[Leon Rosenberg]

On Sunday, January 26, 2014 2:52:00 AM UTC+1, Christian Beikov wrote:

I have an use case where I need a hierarchical/graph model of contexts for configurations. For example there might be some kind of layering:

Hello Christian,

I don't want to make advertisement here, but ConfigureMe does exactly that (and was designed for it):

https://confluence.opensource.anotheria.net/display/CONFIGUREME/Environments

regards

Leon

[Anatole Tresch]

Hi Leon/all

Basically we need the capabilities of combining arbitrary 'configuration levels'. Looking at tools like chef this is obvious but also when analyting what big companies run inside you have levels for different
- config types (eg weak defaults vs strong administrative overrides)
- tiers
- servers
- network zones
- shared or dedicated instances
- runtime platform releases
- products/modules/plugins deployed
- ear and war levelled config
- special runtime config eg used in case of error analysis
- ...

Of course, not many companies have this level of complexity. But it is crucial that we will be able to cover it, as well as the more simpler cases. Additionally each company will have different requirements on the optimal granularuty, so I assume we will also provide some kind of metamodel....
So I the basic concepts of configureme seem go in the same direction ;-)

Regards,
Anatole

[Christian Beikov]

I looked into it, but it doesn't look like it covers everything I need. I just mention the thing in my post that weren't posted by others.
The configuration datasource should be pluggable(I need a database) and the configuration should also be changeable at runtime.
I got even more requirements, but I think these have already been discussed here. I already implemented most of that myself, but of course I would like a standard more. :)

Regards,
Christian

[Leon Rosenberg]

Hello Christian,

actually both are supported (runtime reload) or supportable (different configuration sources), but this is not configureme support forum, so if you interested feel free to msg me directy.

(rosenbe...@gmail.com) 

regards

Leon

[Christian Beikov]

Of course it must also be possible to only have a immutable configuration. If a configuration is contained in a deployable archive it can't be changed obviously. So at least the EE case requires that kind of functionality.
Still, in my opinion configuration should be changable at runtime too.

Mit freundlichen Grüßen,

---

Christian Beikov

Am 17.02.2014 12:46, schrieb Anatole Tresch:

Hi Chritian

I agree with both of them. Question is how to implement mutability. When i look at the sybchronization hell eg in the Preferences API I tend to immutable objects with some event mechanisms propagated the updated instances. The granularity hereby imo could also be smaller than the full config valid in some context, so partial updates can coexist with more static configuration. This may also be relevant for covering security aspects, where you may want some configuration explicitly not be mutable .

Wdyt?

Regards

Anatole

-

Anatole Tresch

Glärnischweg 10

8620 Wetzikon

Tel +41 (43) 317 05 30

-

Send from Mobile

--

You received this message because you are subscribed to the Google Groups "java-config" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-config...@googlegroups.com.
Visit this group at http://groups.google.com/group/java-config.

To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/b78282a8-9abb-494d-9ddd-ab27fc3035e7%40googlegroups.com.

[Mark Struberg]

Hi Antonio!

It's actually the other way around.

The property (file) based ConfigSources have a default config_ordinal which is lower than anything configured via JNDI or system environment. 

This allows you to configure sensitive defaults inside your application but override it on each container from 'external'. 

We also mix this with the ProjectStage and provide configuration which has a level of 'indirection':

public static String ConfigSource#getProjectStageAwarePropertyValue(String key) 

This version first checks the ProjectStage (http://deltaspike.apache.org/projectstage.html http://deltaspike.apache.org/core.html#type-safe-projectstage) and you can provide different a different configuration for each ProjectStage. If you didn't configure something 'special' for a certain ProjectStage then it falls back to the generic configuration.

public static String ConfigSource#getPropertyAwarePropertyValue(String key, String property)

Ok, the name is not the best ;) but aside from this it provides different configuration based on another config setting. Let's e.g. assume the following code 

String jdbcUrl = ConfigSource.getPropertyAwarePropertyValue("database.url", "dbvendor");

The first thing it does internally is to resolve the value behind the 'dbvendor'. As usually it uses the whole ConfigSource chain to find it's value. And it also leverages the ProjectStage of course.

Let's say we did set the dbvendor to 'oracle' and on another box it resolves to 'mysql'. I guess you get the idea, right?

LieGrue,

strub

Am Donnerstag, 31. Oktober 2013 11:31:02 UTC+1 schrieb Antonio Goncalves:

[Werner Keil]

Mark/Anatole/all,

I know the GitHub repo is more or less a concept draft, but if the JSR gets created, it may well become its home (see JSR 107, or lots of others including 354 or 363)

May I suggest, to rename the somewhat ugly-sounding "javax.config.annot" to "javax.config,annotation"?

Every JSR or part of Java SE and EE defining an annotation package calls it "javax.annotation" or "java.lang.annotation", it seems more consistent.

WDYT?

Werner

--

You received this message because you are subscribed to a topic in the Google Groups "java-config" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/java-config/FrgH9_O1qkU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to java-config...@googlegroups.com.

Visit this group at http://groups.google.com/group/java-config.

To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/da912d43-c3f8-4d6d-bd2b-ab8998f946ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Anatole Tresch]

Hi all,

Of course, this makes sense!

Cheers

Anatole

-

Anatole Tresch

Glärnischweg 10

8620 Wetzikon

Tel +41 (43) 317 05 30

-

Send from Mobile

Am 07.05.2014 um 19:21 schrieb Werner Keil <werne...@gmail.com>:

Mark/Anatole/all,

I know the GitHub repo is more or less a concept draft, but if the JSR gets created, it may well become its home (see JSR 107, or lots of others including 354 or 363)

May I suggest, to rename the somewhat ugly-sounding "javax.config.annot" to "javax.config,annotation"?<35F.gif>

[Anatole Tresch]

Hi all

I think even, when external configuration overrules internal configuration behavior is backward compatible, given no external config is available. If you would deploy your apps without any external configuration source setup, I would expect the same behaviour as before. We can discuss, what would be a reasonable default, I tend to see the default as with external override being active, since you still must configure your external config sources to make it override. Without that I see a similar situation as with CDI in EE 6, where you can write and deploy managed beans, but still you have to activate CDI to make use of them (by adding an empty beans.xml)...

Cheers

Anatole

-

Anatole Tresch

Glärnischweg 10

8620 Wetzikon

Tel +41 (43) 317 05 30

-

Send from Mobile

[Werner Keil]

Hi,

I guess if you look at external configuration sources, some JSRs or other Open Source efforts with their own configuration sub system are worth taking a look at. JSR 107 which is final so far: https://github.com/jsr107/jsr107spec/tree/master/src/main/java/javax/cache/configuration or 350 (https://www.java.net/project/java-state-management) which is still heading towards EDR are two good examples. They show quite a few similarities when you look at the config interfaces or classes. 

Ideally at least non-final JSRs could leverage something created here, unless it is entirely for EE? JSR 350 has at least 2 roles, maybe more, one the "container", the other is "capabilities" or those using them, including downstream applications. With regards to 107, given it may either directly or indirectly (via the Data Grid JSR) be used by EE 8, the need to find synergies and ways these could interact are certainly a challenge. 107 is fairly incomplete, e.g. left out transactions, so it'll require at least a bigger MR, probably even whole new JSR to be EE 8 ready. That could be the Data Grid JSR or a new version of JCache.

Cheers,

Werner

Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer

Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps

Skype werner.keil | Google+ gplus.to/wernerkeil

* EclipseCon France WG Unconference: 17 Jun 2014, Toulouse, France. Werner Keil and Jean-Marie Dautelle, JSR 363 Spec Leads will present "JSR 363 and the Quantified Self"

* Developer Week: 14/15 Jul 2014, Nürnberg, Germany. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class Continuous Delivery", "JSR 363 and IoT" (GER)

* Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache DeviceMap" (GER)

--
You received this message because you are subscribed to a topic in the Google Groups "java-config" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/java-config/FrgH9_O1qkU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to java-config...@googlegroups.com.

Visit this group at http://groups.google.com/group/java-config.

To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/829F6D07-C66B-42A0-B82F-3A2FD6129860%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Oliver B. Fischer]

Hi all,

may we should consider to keep this behavior configurable.

I like the way of the Jersey team. You can register components and given
them a priority. This approach would allow us to provide a default chain
of sources of configuration properties and to allow the user to specify
his own chain.

Bye,

Oliver

Am 08.05.14 09:54, schrieb Anatole Tresch:

> Hi all
> I think even, when external configuration overrules internal
> configuration behavior is backward compatible, given no external config
> is available. If you would deploy your apps without any external
> configuration source setup, I would expect the same behaviour as before.
> We can discuss, what would be a reasonable default, I tend to see the
> default as with external override being active, since you still must
> configure your external config sources to make it override. Without that
> I see a similar situation as with CDI in EE 6, where you can write and
> deploy managed beans, but still you have to activate CDI to make use of
> them (by adding an empty beans.xml)...
>
> Cheers
> Anatole
>
> -
> Anatole Tresch
> Glärnischweg 10
> 8620 Wetzikon
> Tel +41 (43) 317 05 30
> -
> Send from Mobile
>
> Am 07.05.2014 um 08:15 schrieb Mark Struberg <markst...@gmail.com

> <mailto:markst...@gmail.com>>:

>> <http://deltaspike.apache.org/configuration.html#configsource>).

>> Configuration comes from several Sources :
>>

>> * System properties
>> * Environment properties
>> * JNDI values
>> * Properties file values (default filename is

>> "META-INF/apache-deltaspike.properties")
>>
>> These sources have a default priority (System first.... properties
>> file last) that can be changed. So we could easily say "by
>> default, the WEB-INF/classes directory is a source that has a
>> priority higher that an external file". This way, by default, if
>> there is a config file within a war, it will have higher priority,
>> meaning Java EE components will behave as they use too. Get rid of
>> this file from the war, then the following source (external file)
>> will get into account.
>>
>> And of course, this default behavior can be changed
>>
>>
>>
>> On Thu, Oct 31, 2013 at 11:16 AM, nicolas de loof

>> <nicolas...@gmail.com <javascript:>> wrote:
>>
>>
>>
>>
>> 2013/10/31 Antonio Goncalves <antonio....@gmail.com <javascript:>>

>>
>> On Thu, Oct 31, 2013 at 11:07 AM, nicolas de loof
>> <nicolas...@gmail.com <javascript:>> wrote:
>>
>>
>> Fully agree. We have to get rid with the paradigm to

>> "/package your config within your WAR/" that breaks

>> flexibility to embrace various environments. Some
>> standard way to access a configuration resource let
>> frameworks / other JSR decouple from actual descriptor
>> location, and option to store them externally with a
>> large set of (vendor specific) options.
>>
>>
>> @nicolas Always be careful with backward compatibility. We
>> don't want to "get rid", we want to add another one.
>> Packaging config within a war still has to work
>>
>>
>> You ask a jenkins guy to be careful with backward
>> compatibility ? ;P
>> not saying config in a war don't have to be supported, just
>> that config API abstraction gives more flexibility.
>>
>>
>> @anatole You are right, trying to push JavaConfig to all
>> the other specs in EE 8 will be very risky. Your example
>> is good : SOAP Web Services (JAX-WS) hasn't been updated
>> in EE 7, so injection doesn't work for example. Let's keep
>> it simple and efficient for a v1.0 and try to push it
>> everywhere in EE 9 (I know, a long time to wait for ;o)
>>
>>
>> --
>> Antonio Goncalves
>> Software architect and Java Champion
>>

>> Web site <http://www.antoniogoncalves.org> | Twitter
>> <http://twitter.com/agoncal> | LinkedIn
>> <http://www.linkedin.com/in/agoncal> | Paris JUG
>> <http://www.parisjug.org> | Devoxx France
>> <http://www.devoxx.fr>

>>
>>
>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect and Java Champion
>>

>> Web site <http://www.antoniogoncalves.org> | Twitter
>> <http://twitter.com/agoncal> | LinkedIn
>> <http://www.linkedin.com/in/agoncal> | Paris JUG
>> <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>

>
> --
> You received this message because you are subscribed to the Google
> Groups "java-config" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to java-config...@googlegroups.com

> <mailto:java-config...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/java-config.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/java-config/829F6D07-C66B-42A0-B82F-3A2FD6129860%40gmail.com

> <https://groups.google.com/d/msgid/java-config/829F6D07-C66B-42A0-B82F-3A2FD6129860%40gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.f...@swe-blog.net
S oliver.b.fischer
J oliver.b...@jabber.org

[Mark Struberg]

> "by default, the WEB-INF/classes directory is a source that has a priority higher that an external file". 

This is WRONG. I already explained it on 2014-05-07.

I'm getting the feeling my mails don't come through....

BY DEFAULT everything no the classpath has lower priority than things which come from external. 

The idea is that you define your _default_ behavior inside your application - but let 'tweak' it from outside

http://deltaspike.apache.org/configuration.html

https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java#

Of course every ConfigSource can define it's own ordinal. Even in the properties file you can define that one of them has higher ordinal by simply adding a special property

deltaspike_ordinal=500

It is also very easy to register your own ConfigSources. In a big $$dayjob project I e.g. wrote a ConfigSource which looks in a PROPERTIES table in the database.

Hope that clarifies at least a bit...

I started using a similar system about 7 years ago now and it works fine in big projects. 

You really have to look at the benefits of making it fancy versus making it more complicated to handle. There is no perfect way, the trick is to find the right tradeoff.

Regarding dynamic configurat: is doable, but is a performance tradeoff. It's a question whether the ConfigResolver or the single ConfigSources should handle the caching.

Also keep in mind that @Inject of native java types cannot get proxies and thus they are always @Dependent scoped -> no dynamic refresh for injected configuration anyway.

LieGrue,

strub

Am Donnerstag, 31. Oktober 2013 11:31:02 UTC+1 schrieb Antonio Goncalves:

[Mark Struberg]

Hi Oliver!

The DeltaSpike ConfigSource has a getOrdinal() which is also freely configurable. 

E.g. for the ConfigSources for property files you can simply put a 'deltaspike_ordinal=123' in there to define it's 'importance'.

So it's basically the same thing..

One important note. All this is perfect for 'property like' configuration where you only like to override single values. Having a higher ConfigSource does not override all of the values from the less important ones, but ONLY the properties which are set in this very ConfigSource!.

The algorithm is basically:

Properties props = new Properties();

for (ConfigSource configSouce : sortedConfigSourcesFromLowToHigh) {

  props.addAllValues(configSource);

}

LieGrue,

strub 

[Leon Rosenberg]

On Sun, Jun 1, 2014 at 9:41 PM, Mark Struberg <markst...@gmail.com> wrote:

> "by default, the WEB-INF/classes directory is a source that has a priority higher that an external file". 

This is WRONG. I already explained it on 2014-05-07.

I'm getting the feeling my mails don't come through....

BY DEFAULT everything no the classpath has lower priority than things which come from external. 

The idea is that you define your _default_ behavior inside your application - but let 'tweak' it from outside

Hello,

I don't quite understand why you separate classpath and external source? As long as external is a directory, why can't it be part of the classpath? 

You can modify the classpath in most modern containers, and then simply adding something as /etc/configuration as part of the classpath, but fill it differently from published artifact does the trick and the framework itself doesn't need to care for different type of sources.

regards

Leon

[Mark Struberg]

Actually we do not separate. 

We pick up each registered property file we find on the classpath and register an own ConfigSource for each of them. That way each of them can have it's own ordinal ;)

The default value only applies if you don't add one in the property file yourself.

LieGrue,

strub

[Mark Struberg]

Oh and with 'external' I did more mean JNDI, System, env, etc...

Actually there is no need anymore to add a property file to some arbitrarily added ClassPath. 

LieGrue,

strub

[Anatole Tresch]

The system in Credit Suisse basically can also read in several files into one config source, e.g. using ant-styled path expressions like classpath*:META-INF/cfg/blabla/**/*.properties

So priorities can be on single files, or on single file expressions...

--
You received this message because you are subscribed to the Google Groups "java-config" group.

To unsubscribe from this group and stop receiving emails from it, send an email to java-config...@googlegroups.com.

Visit this group at http://groups.google.com/group/java-config.

To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/93eb45ae-3877-4ff1-a3a6-7ffb42f28861%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Anatole Tresch

Java Lead Engineer, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

Switzerland, Europe Zurich, GMT+1

Twitter:  @atsticks

Blogs: http://javaremarkables.blogspot.ch/

Google: atsticks
Mobile  +41-76 344 62 79

[Anatole Tresch]

External for me explicitly can also mean a configuration server accessed with a Restful API or a database or a sftp connection or ...

2014-06-01 22:48 GMT+02:00 Mark Struberg <markst...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "java-config" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-config...@googlegroups.com.
Visit this group at http://groups.google.com/group/java-config.

To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/93eb45ae-3877-4ff1-a3a6-7ffb42f28861%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Werner Keil]

Leon/all,

Some of the ideas Mike Keith described earlier may be called slightly different here now, but an idea of the "external source" is that it could be deployed into a container for a particular tenant or application.

So even if you got a classpath there it usually won't be the same.
If you want to ensure that "tenant specific" source overrides a built in default you often don't get to control this order even in modern app servers.

Werner

--
You received this message because you are subscribed to a topic in the Google Groups "java-config" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/java-config/FrgH9_O1qkU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to java-config...@googlegroups.com.

Visit this group at http://groups.google.com/group/java-config.

To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/CAE2_di0Kj-3q%2BqYY3JehGYgRhhVtd1%2BTCTx7aFYGvOS%3DbPPbbw%40mail.gmail.com.