--
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.
--
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.
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
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 workYou ask a jenkins guy to be careful with backward compatibility ? ;Pnot saying config in a war don't have to be supported, just that config API abstraction gives more flexibility.
--
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.
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.
Fully agree. We have to get rid with the paradigm to "package your config within your WAR" that breaks flexibility to embrace various environments.
--
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.
An interesting blog about how to inject external configuration using CDI and Expression Language :
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:
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
Hi ChritianI 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
--
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.
--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.
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.
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>
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
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/829F6D07-C66B-42A0-B82F-3A2FD6129860%40gmail.com.
> "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
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/93eb45ae-3877-4ff1-a3a6-7ffb42f28861%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/93eb45ae-3877-4ff1-a3a6-7ffb42f28861%40googlegroups.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.
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.