2014-12-23 23:52 GMT+01:00 Mark Struberg <[email protected]>: > 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? >
core should be String only IMO, then integrations can coerce as they want - most of frameworks will have their own coercing logic and we'd need to be aligned on them. > 2.) Should we have native methods to read and write various ini file formats, > or is this just not our business? > This is no more the raw API but I see it as a "tamaya-extras" nice feature > 3.) Should we define any configuration formats, and if so which one? > same > 4.) Do we really need writeable configuration in our API? > I'd like a write-api but clearly not with the main (read)core-api - can be postpone if it adds to much complexity to bootstrap tamaya IMO. Globally I think we should maybe branch tamaya current code base and create an empty master. From my point of view we could start from a "DS light" - ie a ConfigProvider + a ConfigManager/ConfigAggregator able to order ConfigProvider and merge them. Nothing static until it is mandatory! These 2-3 classes should be enough to start. Then we can add other features in separated modules like cdi, mapping/binding, writing, gui... or enrich core if needed. Main goal is to start from a trivial impl everybody can understand in 5mn then add on top of this basis what we miss. wdyt? > > > 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>* >>>> >>>> >>
