I don't quite get it. All your source pointers to deltaspike did concern the CdiCtrl module. Of course this has CDI dependencies...
What I was talking about are the following classes https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigResolver.java https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigFilter.java https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSourceProvider.java None of them has any CDI dependency. All the CDI functionality is built on top of that. >*About what? Please, please, please give us the concrete use cases, you >think Deltaspike supports, or supports better and tamaya does, with as much >details possible. I already gave one. See my first mail. The point is actually the other way around. I'm absolutely sure that we can do the same functionality that Tamaya has today in 1/10 of the code. And having less code usually also means having a much clearer and more flexible system at the end. It's just too bloated and I did read javadocs for two days and had so many wtf moments that all alarm bells did ring. I understand that the current code is a organically grown system which is tried and proofed in some cases - but that is also it's problem. It's not lean and elegant anymore but just some historically grown piece it seems. I guess that many use cases which are possible within this framework are just not legit anymore. >*1) I always stated to have a simple API, just providing a COMPLETE SE API* Agree >* - config, config templates* Agree with config. But ConfigTemplates are just syntactic sugar. I would not add it. It's just slower and not so easy to grasp for users. >* - injection (also in SE)* Disagree. What for? And how? Let's keep this as easy as possible. >* - meta information* TOTALLY over engineered. really! >* - support for reacting to config changes.* That's trickier. There are 2 ways. Push or Pull. .) Push means -> sending out an event so config consumers know when to update. The problem is to make this reliable. You e.g. cannot use CDI as this only works with ThreadLocals. You also cannot use Observable as this would cause issues with mem leaks. .) Pull means -> config consumers who are interested in changed values just call ConfigResolver#getProperty over again. This doesn't cause any performance issues if the config system is well done. >* - and support for non String types. * We've discussed this in length many times. Every time we started again it became clear pretty quickly that there is such a thing already: JNDI. And that's exactly why it does NOT work. It really sucks. >* - reading config from the classpath, from files and URLs, * That's the problem. The user is not interested in reading this and that file usually. Like with DI he is usually only interested in the final outcome. >* - using properties, xml-properties and ini as file format,* Why? The user doesn't care where the values did come from. We should really do this via a pluggable SPI. Probably defining a few defaults (which could really include properties, etc). But it's more that we provide a SPI with a few impls of it out of the box. The emphasis is on the SPI and not on those 'sample' impls. >* - implementing the type support mentioned, also including collection >support (not yet supported)* Collections support could be interesting >* - and providing configuration combination features.* What do you understand by that? >* By default a configuration model is provided, so people can just put >their config files at the right locations and start to work. Easy and >intuititve. What is wrong here I ask again?* Currently we don't provide that. It's just not easy and intuitive right now. >*3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI integration,Environment >management, more complex configuration models, remote support etc., >remoting, JMX, JAX-RS * I agree. LieGrue, strub On Tuesday, 23 December 2014, 14:37, Anatole Tresch <[email protected]> wrote: >Hi Romain/all > >just a few additions inline... > >2014-12-23 11:04 GMT+01:00 Romain Manni-Bucau <[email protected]>: > >> About Environment and distirbuted system: the issue is the same with >> or without. You always need a local config vs the global one but I >> strongly think a system property, jndi entry or anything else can be >> enough and don't need to be in tamaya itself to start. >> >> 2014-12-23 10:31 GMT+01:00 Mark Struberg <[email protected]>: >> >> so you can ask the config server for the right config. >> > Gosh, that scares me a bit! Don't even think about config servers. Such >> things must be totally up to the vendor. We must allow making such things >> possible with our API but we shall NOT support such things out of the box! >> > The best would be to make our API in a way that even the user >> (application programmer) could add such a mechanism to it himself. >> >*I would not rule that completely out, this is a use case. We should >discuss that once we are ready for it (all the basics are in place) how >much we can go for it (meaning how much we can support things OOTB).. >Definitively it is not part of the core delivery, but could be an optional >module to be added.* > > > >> >> For me SE comes first. EE builds on top not the other way round! >> > >> > >> > Totally agree with that. >> Fine. >> > > >> >> But it (DeltaSpike) is inheritly connected to CDI and >> > >> > That's just not true. > >*Why, there is a cmpile time depoendency to cdictl-se, >see >https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD ><https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/pom.xml;hb=HEAD>* > >*As a code example people here on the list my have a look at >https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD ><https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/cdictrl/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;hb=HEAD>* >** >*Or they look at the @ConfiguredPropertyx annotation: >https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD ><https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob_plain;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java;hb=HEAD>* > >*and they see:* > >*import javax.enterprise.util.Nonbinding; >import javax.inject.Qualifier;* > > >And it's tried and used successfully in many big projects (including my own >> which deals with 50 bn EUR, german stock exchange, UK stock exchange, big >> swiss banks, etc). >> > I'm not saying the DS api is the best, but it is able to do all that and >> is 1/20th of the complexity and size of Tamaya right now. And still being >> more powerful. >> > >*About what? Please, please, please give us the concrete use cases, you >think Deltaspike supports, or supports better and tamaya does, with as much >details possible. That is the only way we* >*a) can bullet.proof our considerations and also see, where our use cases >differ.* >*b) really compare concepts, instead of just arguing that things are much >more complex.* >*c) help also to get a better understanding of the concepts in place so far >and see how things can be improved.* > > > >> It is Mark, at least in term of dependencies, I asked months ago to >> explode core part but it was not the moment I guess ;) >> >> > >> >>> things not working out of the box: distributed configs >> > >> > For which distributed system? >> > * Ehcache? >> > >> > * Terracotty? >> > * Hadoop like clustering? >> > * a simple shared file store? >> > Where to put the meta-configuration for it? Where to define which one to >> use? >> > What fallback strategies to choose? >> > >> >> >> Never spoke of any technology. Spoke in term of use case: I have 5 >> machines which need to read the same config. Constraint I'd like to >> respet is: don't force a "complicated" config like hazelcast one for >> instance. >> >> > All that HEAVILY depends on the situation and scenario you have in your >> project. There is just nothing we can decide for the customer. All we can >> do is to make it VERY EASY to implement it yourself. >> > >> > For example: In DeltaSpike adding a ConfigSource for a config file on a >> shared folder is a mere 7 lines of code.. >> In Tamaya, it will be about one line ;) >> > > >> Here the is issue: it needs you to code. This is not a feature of the >> framework. >> >> > Please don't let us go down the (old) Spring route to have miles of >> configuration for stuff which you could hack in just a few lines of code. >> > >> >> In practise you don't always have the choice > > >*It all about options. I did never state that all features must end up in >core:* >*1) I always stated to have a simple API, just providing a COMPLETE SE API* > >* - config, config templates* >* - injection (also in SE)* >* - meta information* >* - support for reacting to config changes.* >* - and support for non String types. * > >* There is no more there, so I ask what is really wrong here? If its OK, >let's go ahead and focus on core.* > >*2) In core I would expect to have a minimal runtime implementation that >provides all features needed to cover most of the needs, meaning* > >* - reading config from the classpath, from files and URLs, * >* - using properties, xml-properties and ini as file format,* >* - implementing the type support mentioned, also including collection >support (not yet supported)* >* - and providing configuration combination features.* > >* By default a configuration model is provided, so people can just put >their config files at the right locations and start to work. Easy and >intuititve. What is wrong here I ask again?* > >*3) ALL THE REST are OPTIONAL EXTENSIONS, like CDI integration,Environment >management, more complex configuration models, remote support etc., >remoting, JMX, JAX-RS * >* support and * >*whatever we (and users) think would be useful. When users are happy with >the module provided (we will hopefully have lots of discussions in the >next months and years to do it right), they may * >*use it OOTB. If not they can still write their own. It's all about >options, like in Java EE (Arun Gupta) ;)* >* * > >>>> we can start as >> >>> easy as reading a database >> > >> > We discussed this in DeltaSpike and deliberately did NOT add it. It's >> really really easy to implement a ConfigSource which goes into the DB >> yourself in 30 minutes. >> > >> > If we would provide this feature out of the box, then how would you do >> that? >> > * which database would you address? >> > >> > * JPA or JDBC native? again: what about the db vendor? >> > * how to configure your db user, your schema, etc? >> > * what about update and caching policies? >> > We would need some jar with JPA or whatever as dependency. Would need >> meta-configuration, yada yada yada. And all to avoid 100 lines of code? >> That just doesn't pay off! >> > >> >> That's why I spoke about a "push" system. Then we just use java 7 file >> system watch solution. > >*That is modelled by the ConfigChangeSet, which contains a reference to >the current configuration and infos on the properties changed. This change >set can be applied to a config (pull scenario) or * >*published based on changes in the backenbd (push scenario).* > > >> > Probably add some sample code somewhere. It must be easily doable within >> our API but we should not try to implement that by default in our core jar. >> > >*As mentioned it was never targeting core ;)* > > > >> >>> it include crud >> > >> >>> api but also a GUI - and listeners/update events. >> > >> > Totally overengineered imo. How should a GUI look like which might >> change configuration in a Haddop Cluster or in a Docker installation? Or >> whatever comes around the corner next year... Just DON'T DO IT. >> > >*Basically, what is possible is to provide introsepction in existing >configuration. This is helpful for error analysis. More details here are to >be discussed. I don't see this as a core feature, but we must have it in >mind. Discussions will show, what is possible, But as before, don't rule >out everything, just before you are scared about it. If there is a need, >there must be at least a discussion. First things perhaps for @all: always >think if a use case should be part of the API, the core minimal >implementation, or an optional extension.* > > > > >> > There is of course an important very basic underlying design question: >> How to treat configured values which are non-mutable and might get cached >> vs ones which might change during the application lifetime? >> > Also: Do we like to introduce an own API for value-reload or do we >> leverage JMX? >> > >> > THOSE are the things I like to get clarified before we touch ANY code! >> > >> > >> >> JMX is mandatory IMO but JAXRS as well. >> >> *+1 * > >-- >*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>* > >
