2014-12-23 15:33 GMT+01:00 Mark Struberg <[email protected]>: > 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. >
binding is nice even in SE but I would start with standard injection cases before to have a common usage. > >>* - 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. > Not sure I follow you, normally not at all. When using it you have a "ConfigurationManager" which is just an observer/listener updating the conf accordingly. Of course its scope should be >= to the conf one...but if you need this update feature then I'm pretty sure you are @AppScoped so it is the case. > .) 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. > This is worse IMO cause it causes refreshing even when not needed and it impacts directly the app. > > >>* - 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>* >> >>
