Again: I already gave you a use case, please solve it with Tamaya. Then tell me your use cases and we gonna do ping pong until we find a common understanding and view. That's nothing personal, it's just technically trying to deduct the code and slice it down to the minimum necessary parts. We did the same in CDI and nowadays most people are happy that we e.g. didn't leave all the xml configuration stuff in there but instead introduced modularity and extensions ...
I also don't have much to do with the Apache Brand (besides being an ASF member). I'm here as an individual PMC member like every other. My mentorship also has not much impact. What does have an impact is that I'm reaching for nothing less than the best solution. > 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 wonderin. At the very beginning we all agreed to first discuss the basic principals. But right after that you instead imported your old code base and started to hack on it. I had expected that this is just or reviewing pieces and 'cherry-pick' parts of it which fit. But instead it was taken 1:1 and just 'enhanced'. From the ideas this is basically the same like it used to be 2 years ago. So yes, this is not new code (you btw said this yourself a dozen times). Of course we just blame ourselves that we didn't reach out earlier. It's also not all bad, but there are parts which I really think are way out of scope to later become a JSR. > Additionally, even your first interface has a dep on the Typed annotation for > example The @Typed is only to make really old Weld impls not blow up when scanning this class. It's really not needed anymore today. We need to finally start with a few very basic decisions and work through them. I already enlisted a few of them but I'm happy to enumerate them again. 1.) Should the configuration mechanism be String or Object? 2.) Should we have native methods to read and write various ini file formats, or is this just not our business? 3.) Should we define any configuration formats, and if so which one? 4.) Do we really need writeable configuration in our API? LieGrue, strub > On Tuesday, 23 December 2014, 18:37, Anatole Tresch <[email protected]> > wrote: > > 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>* >>> >>> >
