Hi Mark I must say I am totally surprised of your mails. Obviously you know things better than all the other people and experts i have talked so far. You even know what all users think and what all companies need. And you know that all code here is completely legacy, historically grown, ugly, outdated and more. You obviously have a crystal ball, i am just wondering
I will not reply in detail on the last mail. It is full of fuzzy arguments. Nothing concrete. Just claims how things should be iyo. Just claims that you can do the same in 1/10, but you even struggle with the basic api, which is quite small compared to most other apis in that area. You write about concerns about memory leaks though the facts we have more than enough mechanisms to manage weak refs and we have a couple of experts in our team that know well both se as well as ee both in theory and in practice. Additionally, even your first interface has a dep on the Typed annotation for example, so I struggle to take this kind of feedback seriously. Its not constructive, its not precise, I think it is respectless to the people working here, and even worse it stops us foing our work and imo it matches not what I expected from the Apache Brand, especially a project mentor. Sorry to say it so frankly. Other opinions are welcome. - Anatole Tresch Glärnischweg 10 8620 Wetzikon Tel +41 (43) 317 05 30 - Send from Mobile > Am 23.12.2014 um 15:33 schrieb 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. > > >> * - 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>* >> >>
