Hi Mark just a few inline...
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. *The JSRs main scope will be the API mainly. So core parts are not the essence here ;) But definitively the code base is not production ready (there are even no tests). Nevertheless I think hacking was not that bad as well, since sometimes we also struggled with the English here, so it helps as well to get an understanding of some ideas, though I agree, some confusion would be avoidable as well...* > > 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. > > *Fair enough. * > > 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. > > *Thanks. * > > > 1.) Should the configuration mechanism be String or Object? > *-> the configuration mechanism IMO should strictly based on Strings. Types are very simple adaptors on top of the String values, nothing more. Tamaya should never store non String objects into* *its properties. * > > 2.) Should we have native methods to read and write various ini file > formats, or is this just not our business? *-> I would like to help users here to have code at their fingertipps that helps a lot. The ant-styled resolution of classpath and files has proven to be very handy. URLs are basically syntactic sugar on top. All the rest I would like to have better feedback from users, to see what makes sense. But I definitively do not see anything more as core parts here.* 3.) Should we define any configuration formats, and if so which one? > *-> I would like to see a minimal set of formats in core, so we can provide a minimal dependency version that fits most needs. .properties, .xml(properties) and .ini I think is a good set, but definitively not more.* *-> We can then leverage apache commons config with bridges in the extension modules for suporting additional formats ;). * > > 4.) Do we really need writeable configuration in our API? > *I also struggled a lot with that. I personally never needed writable config, but several people explicitly are asking for mutability. What I did so far, was to try to control the side effects of mutability. I think we should take that topic up with our colluegues here, I am personally open to whatever is the outcome here...* *Anatole* > > > > 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>* > >>> > >>> > > > -- *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*
