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>*
