You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Mark Struberg <st...@yahoo.de> on 2014/12/27 11:42:00 UTC
[DISCUSS] core concepts - to merge or not to merge
Hi!
1.1)
I think we agree that having a PropertySource/ConfigSource SPI with MANY implementations is the way to go?
Any objections?
1.2)
Where should it belong to? Is it an API or rather an SPI?
I think it's more the later. A end user just likes to get the 'final' configured values and does NOT deal with the PropertySources himself. It is really just for extending the system -> SPI.
1.3)
Merging.
Option (1.3.a) Do we like to do 'implicit' merging (aka the ordinal stuff).
Option (1.3.b) Or do we like 'explicit' (the merge function). What benefit does this add in practice?
Ad 1.3.a 'explicit' merging: This is basically the DeltaSpike mode: EACH ConfigSource (PropertySource) has an ordinal which it can set itself. The higher the configuration ordinal of the ConfigSource, the more important it is and it will override values from ConfigSources with lower ordinal.
That way it is possible to have a kind of 'default configuration' e.g. in a property file inside your project and later overwrite it via -Dxxx=yyy, JNDI, or some container provided MyCountainerAdminConfigSource etc later.
Ad 1.3.b 'implicit' merging: Well, actually I don't got this. There was merge(String key, PropertySource s1, s2), but that would mean that every user needs to deal with that himself? Could you please elaborate on that option? I didn't get it...
LieGrue,
strub
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 28 déc. 2014 14:05, "Mark Struberg" <st...@yahoo.de> a écrit :
>
> Romain, I can barely parse your sentences. So I hope to interpret them
correctly.
>
> > > If you dont manage see them at all for merging (or their key-value
> > pairs if not them directly) then you cant merge correctly.
>
> This is just not true. One can even mathematically prove this.
>
Do it, you just cant cause the merge logic depends can depend the key
valueS.
> You might have missed that it is possible to even 'blacklist' properties
in some higher level ConfigSource.
>
>
>
> > Issue is: if system is too complex or doesnt solve it then Properties
> > (or more exactly Map<String, String>) is clearly more efficient
>
> But a ConfigSource IS a Map<String, String>...
>
>
Agree
> LieGrue,
> strub
>
>
>
>
>
> > On Sunday, 28 December 2014, 13:22, Romain Manni-Bucau <
rmannibucau@gmail.com> wrote:
> > > If you dont manage see them at all for merging (or their key-value
> > pairs if not them directly) then you cant merge correctly. I saw it
> > several times and finally bypassed something very close to DS - enough
> > time to care about it.
> >
> > Issue is: if system is too complex or doesnt solve it then Properties
> > (or more exactly Map<String, String>) is clearly more efficient: no
> > abstraction, can be changed easily when aggregating apps etc...
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-12-28 12:47 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> >>> I m fully ok to remove PropertySource from the API
> >>
> >> I think we've lost each other.
> >>
> >> Tamaya PropertySource == DeltaSpike ConfigSource basically.
> >> You just cannot remove this without ditching the whole project.
> >>
> >> The point is that a USER never operates directly with the
ConfigSources.
> > They are a hidden detail. IF you manually manage them in your
application then
> > you end up with exactly your problem - you are doomed and cannot simply
enhance
> > your system but you really need to rework all the applications.
> >>
> >> If you just say ConfigResolver#getPropertyValue("mykey") and rely
> > on the ordinal mechanism then you can just add such a
FilteringConfigSource as
> > JAR without having to touch any of your code. If you did
manage/merge/etc your
> > PropertySources manually then you are doomed. That's why I don't like
> > that approach.
> >>
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >>
> >>> On Sunday, 28 December 2014, 12:22, Romain Manni-Bucau
> > <rm...@gmail.com> wrote:
> >>> > Would have been the same since the app is PropertySource aware.
> > Can also
> >>> mean we dont have PropertySource in a default impl and then it is
true
> > it
> >>> is easy. I m fully ok to remove PropertySource from the API and make
it
> > an
> >>> impl detail.
> >>> Le 28 déc. 2014 11:59, "Mark Struberg"
> > <st...@yahoo.de> a
> >>> écrit :
> >>>
> >>>> But if you would have had this container wide
> > 'AdminConfigSource'
> >>> with the
> >>>> nice gui, or a installation wide DatabaesConfigSource then it
> > would not
> >>>> have been a problem, right?
> >>>>
> >>>> I mean you would have to add this filter to all the 100 apps in
> > the 1 day
> >>>> as well, right? So it would be the exact same effort to just add 1
> >>>> FilteringConfigSource (hacky but works) with a high priority
> > either, right?
> >>>> That would be just adding a single jar to all your lib folders...
> >>>>
> >>>>
> >>>> Sometimes we tend to add new mechanisms out of blindness. But the
> > problem
> >>>> often can be solved easily with existing tools - we just often
> > don't
> >>> see
> >>>> them. This happens to me as well, but I'm glad to have really
> > brilliant
> >>>> co-workers which often stop me from doing overly complicated crazy
> > things.
> >>>> Happens more often than I like it ;)
> >>>>
> >>>>
> >>>> Of course sometimes we really need to add a new mechanism. But
> > this should
> >>>> only be the (almost) last resort if there is no other acceptable
> > way.
> >>>>
> >>>> There are just sooo many weirdo cases out there. Of course they
> > are often
> >>>> needed in production. But for such huge installations you will
> > barely find
> >>>> 2 companies with the exact same situation...
> >>>>
> >>>>
> >>>>
> >>>> Maybe I'm alone here but my goal is to make the 90-95%
> >>> 'standard' use
> >>>> cases as easy as possible out of the box. And _additionally_ have
> > an SPI
> >>>> layer which is very deep down to the metal and as flexible as
> > possible to
> >>>> allow solving more complex edge cases.
> >>>>
> >>>> And I honestly don't care if a programmer does need to write
> > 50 lines
> >>> more
> >>>> for such a seldom case. It's just impossible to solve every
> > problem out
> >>> of
> >>>> the box. That would blow up Tamaya 10x times (or even more). And
> > that would
> >>>> make it unfriendly (if not even 'unusable') for the 95%
> > standard
> >>> cases...
> >>>>
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> > On Sunday, 28 December 2014, 11:41, Romain Manni-Bucau <
> >>>> rmannibucau@gmail.com> wrote:
> >>>> > >T hat is exactly the difference between real life and
> > theory. You
> >>> cant
> >>>> ask
> >>>> > to change 100 apps in 1 day...you have to live with
> >>>> >
> >>>> > Le 28 déc. 2014 10:33, "Mark Struberg"
> >>> <st...@yahoo.de> a
> >>>> > écrit :
> >>>> >
> >>>> >> I don't get your samples Romain.
> >>>> >>
> >>>> >> In v1 you have configured keys A,B,C
> >>>> >> In v2 you have D. So what?
> >>>> >>
> >>>> >> Just remove A,B,C and use D instead. That's exactly
> > the same
> >>> like
> >>>> > changing
> >>>> >> a table structure.
> >>>> >>
> >>>> >> Doing some 'translation' just because the ops
> > guys
> >>> don't want
> >>>> > to change
> >>>> >> configuration is a total dead end and will end up being
> > a
> >>> maintenance
> >>>> >> nightmare in v3++. Your filter mechanism is just an
> > utter ugly
> >>> hack
> >>>> and if
> >>>> >> I would be the manager of this project then I'd call
> > you
> >>> names ;)
> >>>> >>
> >>>> >> That's like arguing that maven is not usable because
> > it makes
> >>> scripting
> >>>> >> hard. This is a FEATURE and not a bug!. People should
> > not script
> >>>> builds! If
> >>>> >> they like to do complicated stuff then it's very
> > easy to
> >>> write plugins.
> >>>> > In
> >>>> >> our case it's very easy to write ConfigSources.
> >>>> >>
> >>>> >>
> >>>> >> Remember the old saying "dirty remains, while quick
> > is long
> >>>> > forgotten"
> >>>> >>
> >>>> >>
> >>>> >> > Some config can conflict
> >>>> >>
> >>>> >> No. That's the same like with JNDI, JMX etc. Just
> > tell them
> >>> to use
> >>>> > their
> >>>> >> own namespaces and you are done.
> >>>> >> That's like saying Java is not good because if I
> > have
> >>> multiple JARs
> >>>> > which
> >>>> >> contain the same ClassName then it doesn't work.
> > JUST USE
> >>> NAMESPACES.
> >>>> > You
> >>>> >> don't need any explicit merging.
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> Oki, that was 2 arguments and both of them are actually
> >>> non-problems.
> >>>> >>
> >>>> >> Cmon folks, give me more use cases and examples. I'm
> > ready to
> >>> solve
> >>>> > them ;)
> >>>> >>
> >>>> >>
> >>>> >> LieGrue,
> >>>> >> strub
> >>>> >>
> >>>> >> On Sunday, 28 December 2014, 9:54, Romain Manni-Bucau
> > <
> >>>> >> rmannibucau@gmail.com> wrote:
> >>>> >> >Well more I read more I think there is a real need
> > but we are
> >>> all
> >>>> wrong
> >>>> >> so instead of fighting please help us finding a
> > solution.
> >>>> >> >@Mark: priorities or ordinal are great while you
> > completely
> >>> own the
> >>>> app
> >>>> >> and its config + it is a single technical version. I
> > guess you
> >>> know it
> >>>> is
> >>>> >> not always (rarely?) The case in medium and big
> > projects.
> >>>> >> >A sample can be: v1 you configure an url with host,
> > port
> >>> propertkes
> >>>> and
> >>>> >> in v2 it is directly the url cause you added a path. Can
> > be the
> >>> same
> >>>> for
> >>>> >> datasource and business config etc...
> >>>> >> >What I did in practise was to use a filter mecanism
> > but it
> >>> was an ugly
> >>>> >> hack.
> >>>> >> >For such cases you can maybe use PropertySource
> > translators
> >>> or things
> >>>> >> like that to ensure the config is in the right format
> > and then
> >>> merge
> >>>> with
> >>>> >> ordinal.
> >>>> >> >Now let take the case where you package together
> > several sub
> >>> apps
> >>>> > coming
> >>>> >> with their config. How do you do? Some config can
> > conflict and
> >>> the
> >>>> >> selection is not ordinal based - let me guess it will be
> > the
> >>> same.
> >>>> Best is
> >>>> >> to have both property sources and merge them into a
> > single one.
> >>> Kind of
> >>>> >> Properties merge(Properties current, PropertySource
> > next).
> >>>> >> >I am not happy with these solutions but the needs
> > are here
> >>> and not
> >>>> >> something thought but really met - even if I dont have
> > your
> >>>> experiences.
> >>>> >> >Point is we cant assume config will be perfect so
> > let our
> >>> future users
> >>>> >> make errors and be able to fix it easily.
> >>>> >> >Le 27 déc. 2014 14:50, "Mark Struberg"
> >>>> > <st...@yahoo.de> a écrit :
> >>>> >> >>
> >>>> >> >> No Anatole, I DO get it, but I really think it
> > is a bad
> >>> idea.
> >>>> > Because
> >>>> >> it adds way too much complexity or a very limited
> > benefit.
> >>>> >> >>
> >>>> >> >>
> >>>> >> >> Think about it in an analogy to the
> > ExpressionLanguage
> >>> ELResolver
> >>>> >> chain. Of course this is a sorted lookup chain. And this
> > list is
> >>> fixed!
> >>>> >> >>
> >>>> >> >> And at runtime you cannot change the order and
> > the user
> >>> also does
> >>>> > not
> >>>> >> care!
> >>>> >> >> All he cares is that #{user.name} does the
> > right
> >>> thing. He
> >>>> > does not
> >>>> >> have to express an 'evaluator' and the chain
> > ordering for
> >>> each and
> >>>> > every EL
> >>>> >> invocation. It just does not make any sense from a users
> >>> perspective.
> >>>> >> >>
> >>>> >> >>
> >>>> >> >>
> >>>> >> >> LieGrue,
> >>>> >> >> strub
> >>>> >> >>
> >>>> >> >>
> >>>> >> >>
> >>>> >> >>
> >>>> >> >> On Saturday, 27 December 2014, 14:17, Anatole
> > Tresch
> >>> <
> >>>> >> atsticks@gmail.com> wrote:
> >>>> >> >>
> >>>> >> >>
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >Hi Mark
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >2014-12-27 12:56 GMT+01:00 Mark Struberg
> >>>> > <st...@yahoo.de>:
> >>>> >> >> >
> >>>> >> >> >> The mechanism is clumsy and implies
> >>>> >> >> >>> constraints that are already known
> > as of
> >>> now not
> >>>> > matching all use
> >>>> >> cases.
> >>>> >> >> >>
> >>>> >> >> >>Tell me some limitations. Never had
> > one. So just
> >>> enlist
> >>>> > them here and
> >>>> >> now.
> >>>> >> >> >>
> >>>> >> >> >And I am working since decades as well in
> > the
> >>> industry. I
> >>>> > will not
> >>>> >> argue about use cases. I gave you same examples. You
> > have the
> >>> stand my
> >>>> >> opinion, unless you feel your opinion counts more than
> > mine.
> >>>> >> >> >
> >>>> >> >> >> On top of it the priority leaks into
> > the
> >>> PropertySource
> >>>> > API
> >>>> >> >> >>
> >>>> >> >> >>
> >>>> >> >> >>Because it IS part of the
> > PropertySource!
> >>>> >> >> >>
> >>>> >> >> >
> >>>> >> >> >But it shoud not. I want to have my
> > property
> >>> sources and I
> >>>> > want to
> >>>> >> combine them they way I want it. I want the concern of
> > assembly
> >>> being
> >>>> >> separated from the source itself.
> >>>> >> >> >It is like you write a Java program like
> > this:
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >2: {
> >>>> >> >> >4: }
> >>>> >> >> >
> >>>> >> >> >3: System.out.println();
> >>>> >> >> >1: for(int i=0;i<10;i11)
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >Shows pretty much the nonsense of your
> >>> argumentation. For
> >>>> > priorizing
> >>>> >> the loading of components in CDI priorities are great
> > and
> >>> sufficient,
> >>>> here
> >>>> >> they are not.
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >> Finally functions is the
> >>>> >> >> >>
> >>>> >> >> >>> modern way of modelling such an
> > operation.
> >>>> >> >> >>
> >>>> >> >> >>If you have a hammer...
> >>>> >> >> >>I'm not interested in style if it
> >>> doesn't add any
> >>>> > real benefit.
> >>>> >> >> >>
> >>>> >> >> >>
> >>>> >> >> >If the hammer is more elegant and powerful
> > but
> >>> still easy
> >>>> > than you
> >>>> >> outstyled solution, let it be a hammer!
> >>>> >> >> >
> >>>> >> >> >>> different or
> >>>> >> >> >>
> >>>> >> >> >>> partial overridings (common in
> > complex
> >>> environments)
> >>>> >> >> >>
> >>>> >> >> >>Never came across this need and I did
> > very
> >>> complex
> >>>> > projects. It's
> >>>> >> always a trade off between an easy straight forward
> > algorigthm
> >>> which
> >>>> are
> >>>> >> easy to understand but sometimes you have to bend em a
> > bit or
> >>> program
> >>>> your
> >>>> >> own (PropertySource). The other option is to have hugely
> > complex
> >>> base
> >>>> >> mechanism which noone can use in practice because it is
> > 'too
> >>>> > flexible' -
> >>>> >> means not clear and straight enough.
> >>>> >> >> >>
> >>>> >> >> >>
> >>>> >> >> >>> you will never get one solution,
> > which a
> >>> special type
> >>>> > of
> >>>> >> >> >>
> >>>> >> >> >>> overridings that matches all
> > users.
> >>>> >> >> >>Oh sure we do. By having the
> > ConfigSource define
> >>> their
> >>>> > ordinal
> >>>> >> themselves and it being really easy for a programmer to
> > add own
> >>>> >> ConfigSources we have all of that!
> >>>> >> >> >>
> >>>> >> >> >>
> >>>> >> >> >>
> >>>> >> >> >>> A solution should NEVER constraint
> > users in
> >>> doing the
> >>>> > stuff
> >>>> >> >> >>> they want!*
> >>>> >> >> >>
> >>>> >> >> >>Having the sorting via Ordinal
> > doesn't
> >>> impose any
> >>>> > restriction on the
> >>>> >> user. Because he can easily overwrite those values.
> >>>> >> >> >>We are talking about a simple straight
> > forward
> >>> config
> >>>> > mechanism and
> >>>> >> not about alien rocket science and time travelling.
> >>>> >> >> >>
> >>>> >> >> >>
> >>>> >> >> >>>You are not on green field here!
> >>>> >> >> >>
> >>>> >> >> >>
> >>>> >> >> >>Oh boy, we are! We just need to fulfil
> > user
> >>> needs,
> >>>> > that's all.
> >>>> >> >> >I am not a boy. I am an adult with 44 years
> > on
> >>> track.... !
> >>>> >> >> >And BTW you seem to have lost every kind of
> > reality
> >>> contact.
> >>>> > Do you
> >>>> >> really think companies will change their internal
> > systems
> >>> completely
> >>>> >> because just a few guys think they know
> >>>> >> >> >how the world is rouling...? NO!
> >>>> >> >> >
> >>>> >> >> >>
> >>>> >> >> >>> *Of course not! (despite the fact
> > that is
> >>> trivial
> >>>> > for the ones
> >>>> >> used the
> >>>> >> >> >>> functional style of Java 8).
> >>>> >> >> >>Of course I know Map#merge, but what do
> > you use
> >>> it for? To
> >>>> > me it
> >>>> >> seems like an overkill.
> >>>> >> >> >Seems that your mindis still stick on Java
> > 7.,,,
> >>>> >> >> >
> >>>> >> >> >> You can still provide a singleton with
> >>>> >> >> >>> constants, where you*
> >>>> >> >> >>> *provide the most common
> > combinations, see
> >>>> > AggregationPolicy in my
> >>>> >> the
> >>>> >> >> >>> current tree.*
> >>>> >> >> >>
> >>>> >> >> >>Again: I don't see the benefit. If
> > I'm
> >>> in an EAR
> >>>> > and like to get my
> >>>> >> "documentarchive.endpoint.url" then WHY would
> > I like to
> >>> manually
> >>>> > change the
> >>>> >> aggregation? Makes no sense to me. And this increases
> > the
> >>> complexity
> >>>> quite
> >>>> >> impressively.
> >>>> >> >> >>
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >Perhaps one day you realize that we are
> > talking
> >>> about a
> >>>> > general
> >>>> >> configuration soultion. EE is a sepcial case, not the
> > other way
> >>> round.
> >>>> It
> >>>> >> is NOT like Deltaspike, which benefits the mechanism
> > provided by
> >>> CDI.
> >>>> It is
> >>>> >> not and if it will, it gets Deltaspike 2, which is
> > useless. There
> >>> is
> >>>> >> already one, which for its purposes on this level, I
> > agree, works
> >>>> well. But
> >>>> >> for a general solution it lacks so much on
> > functionality-
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >I personally really think you still do not
> > get the
> >>>> > difference! It
> >>>> >> drives me crazy.
> >>>> >> >> >
> >>>> >> >> >LieGrue,
> >>>> >> >> >>strub
> >>>> >> >> >>
> >>>> >> >> >>
> >>>> >> >> >>
> >>>> >> >> >>
> >>>> >> >> >>> On Saturday, 27 December 2014,
> > 12:28,
> >>> Anatole Tresch
> >>>> > <
> >>>> >> atsticks@gmail.com> wrote:
> >>>> >> >> >>> > *See inline...*
> >>>> >> >> >>>
> >>>> >> >> >>> 2014-12-27 11:42 GMT+01:00 Mark
> > Struberg
> >>>> > <st...@yahoo.de>:
> >>>> >> >> >>>
> >>>> >> >> >>>> Hi!
> >>>> >> >> >>>>
> >>>> >> >> >>>> 1.1)
> >>>> >> >> >>>>
> >>>> >> >> >>>> I think we agree that having
> > a
> >>>> > PropertySource/ConfigSource SPI
> >>>> >> with MANY
> >>>> >> >> >>>> implementations is the way to
> > go?
> >>>> >> >> >>>> Any objections?
> >>>> >> >> >>>>
> >>>> >> >> >>> *+1 The way to go.*
> >>>> >> >> >>>
> >>>> >> >> >>>
> >>>> >> >> >>> 1.2)
> >>>> >> >> >>>>
> >>>> >> >> >>>> Where should it belong to? Is
> > it an
> >>> API or
> >>>> > rather an SPI?
> >>>> >> >> >>>> I think it's more the
> > later. A end
> >>> user just
> >>>> > likes to get the
> >>>> >> >> >>> 'final'
> >>>> >> >> >>>> configured values and does
> > NOT deal
> >>> with the
> >>>> > PropertySources
> >>>> >> himself. It is
> >>>> >> >> >>>> really just for extending the
> > system
> >>> -> SPI.
> >>>> >> >> >>>>
> >>>> >> >> >>> *+1 for PropertySource being an
> > SPI.
> >>> Configuration
> >>>> > must be the
> >>>> >> API.*
> >>>> >> >> >>>
> >>>> >> >> >>>
> >>>> >> >> >>> 1.3)
> >>>> >> >> >>>> Merging.
> >>>> >> >> >>>> Option (1.3.a) Do we like to
> > do
> >>>> > 'implicit' merging (aka the
> >>>> >> >> >>> ordinal
> >>>> >> >> >>>> stuff).
> >>>> >> >> >>>>
> >>>> >> >> >>> *It's not a question of taste.
> > The
> >>> mechanism is
> >>>> > clumsy and implies
> >>>> >> >> >>> constraints that are already known
> > as of
> >>> now not
> >>>> > matching all use
> >>>> >> cases. On
> >>>> >> >> >>> top of it the priority leaks into
> > the
> >>> PropertySoiurce
> >>>> > API (as an
> >>>> >> additional
> >>>> >> >> >>> method, which is a very ugly mix
> > of
> >>> concerns),
> >>>> > Finally functions is
> >>>> >> the
> >>>> >> >> >>> modern way of modelling such an
> > operation.*
> >>>> >> >> >>>
> >>>> >> >> >>>
> >>>> >> >> >>>> Option (1.3.b) Or do we like
> >>> 'explicit'
> >>>> > (the merge function). What
> >>>> >> >> >>> benefit
> >>>> >> >> >>>> does this add in practice?
> >>>> >> >> >>>>
> >>>> >> >> >>>
> >>>> >> >> >>> *See above and as outlined
> > multiple times.
> >>> Adding
> >>>> > additional
> >>>> >> functionality
> >>>> >> >> >>> for audit (e.g. logging of the
> >>> configuration
> >>>> > overriding), different
> >>>> >> or
> >>>> >> >> >>> partial overridings (common in
> > complex
> >>> environments).
> >>>> > Please stop
> >>>> >> >> >>> discussion on this priority thing,
> > it's
> >>> simply
> >>>> > not enough! By the
> >>>> >> way the
> >>>> >> >> >>> priority thing can still be
> > implemented,
> >>> when the
> >>>> > rest of the
> >>>> >> design is
> >>>> >> >> >>> done in a modular way. My proposed
> > solution
> >>> gave you
> >>>> > the
> >>>> >> abtrsaction of a
> >>>> >> >> >>> ConfigProvider BTW, where you
> > could do this
> >>> easily,
> >>>> > but also the
> >>>> >> other
> >>>> >> >> >>> stuff. What you do depends on the
> > use case,
> >>> and to
> >>>> > some extent your
> >>>> >> >> >>> personal taste. A solution should
> > NEVER
> >>> constraint
> >>>> > users in doing
> >>>> >> the stuff
> >>>> >> >> >>> they want!*
> >>>> >> >> >>>
> >>>> >> >> >>> Ad 1.3.a 'explicit'
> > merging: This
> >>> is
> >>>> > basically the DeltaSpike mode:
> >>>> >> EACH
> >>>> >> >> >>>> ConfigSource (PropertySource)
> > has an
> >>> ordinal
> >>>> > which it can set
> >>>> >> itself. The
> >>>> >> >> >>>> higher the configuration
> > ordinal of
> >>> the
> >>>> > ConfigSource, the more
> >>>> >> important it
> >>>> >> >> >>>> is and it will override
> > values from
> >>>> > ConfigSources with lower
> >>>> >> ordinal.
> >>>> >> >> >>>>
> >>>> >> >> >>>> That way it is possible to
> > have a kind
> >>> of
> >>>> > 'default configuration'
> >>>> >> >> >>> e.g. in
> >>>> >> >> >>>> a property file inside your
> > project
> >>> and later
> >>>> > overwrite it via
> >>>> >> -Dxxx=yyy,
> >>>> >> >> >>>> JNDI, or some container
> > provided
> >>>> > MyCountainerAdminConfigSource
> >>>> >> etc later.
> >>>> >> >> >>>>
> >>>> >> >> >>> *No Mark. The fact of having a
> > default
> >>> configuration
> >>>> > does not
> >>>> >> interconnect
> >>>> >> >> >>> how this is evaluated and
> > composed. You are
> >>> wrong!
> >>>> > And on top,
> >>>> >> when I look
> >>>> >> >> >>> at your ideas: you will never get
> > one
> >>> solution, which
> >>>> > a special
> >>>> >> type of
> >>>> >> >> >>> overridings that matches all
> > users. You
> >>> have to
> >>>> > provide building
> >>>> >> blocks
> >>>> >> >> >>> (one more) that helps the users
> > (companies)
> >>> to model
> >>>> > their
> >>>> >> functionality
> >>>> >> >> >>> with it. You are not on green
> > field here!*
> >>>> >> >> >>>
> >>>> >> >> >>> Ad 1.3.b 'implicit'
> > merging: Well,
> >>> actually I
> >>>> > don't got this. There
> >>>> >> >> >>> was
> >>>> >> >> >>>> merge(String key,
> > PropertySource s1,
> >>> s2), but
> >>>> > that would mean
> >>>> >> that every
> >>>> >> >> >>>> user needs to deal with that
> > himself?
> >>> Could you
> >>>> > please elaborate
> >>>> >> on that
> >>>> >> >> >>>> option? I didn't get it..
> >>>> >> >> >>>
> >>>> >> >> >>> *Of course not! (despite the fact
> > that is
> >>> trivial
> >>>> > for the ones
> >>>> >> used the
> >>>> >> >> >>> functional style of Java 8). You
> > can still
> >>> provide a
> >>>> > singleton with
> >>>> >> >> >>> constants, where you*
> >>>> >> >> >>> *provide the most common
> > combinations, see
> >>>> > AggregationPolicy in my
> >>>> >> the
> >>>> >> >> >>> current tree.*
> >>>> >> >> >>>
> >>>> >> >> >>> *-Anatole*
> >>>> >> >> >>>
> >>>> >> >> >>>
> >>>> >> >> >>>>
> >>>> >> >> >>>>
> >>>> >> >> >>>
> >>>> >> >> >>>> LieGrue,
> >>>> >> >> >>>> strub
> >>>> >> >> >>>>
> >>>> >> >> >>>
> >>>> >> >> >>>
> >>>> >> >> >>>
> >>>> >> >> >>> --
> >>>> >> >> >>> *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*
> >>>> >> >> >>
> >>>> >> >> >>>
> >>>> >> >> >>
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >--
> >>>> >> >> >
> >>>> >> >> >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/
> >>>> >> >> >Google: atsticks
> >>>> >> >> >Mobile +41-76 344 62 79
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >>
> >>>> >
> >>>>
> >>>
> >
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Mark Struberg <st...@yahoo.de>.
Romain, I can barely parse your sentences. So I hope to interpret them correctly.
> > If you dont manage see them at all for merging (or their key-value
> pairs if not them directly) then you cant merge correctly.
This is just not true. One can even mathematically prove this.
You might have missed that it is possible to even 'blacklist' properties in some higher level ConfigSource.
> Issue is: if system is too complex or doesnt solve it then Properties
> (or more exactly Map<String, String>) is clearly more efficient
But a ConfigSource IS a Map<String, String>...
LieGrue,
strub
> On Sunday, 28 December 2014, 13:22, Romain Manni-Bucau <rm...@gmail.com> wrote:
> > If you dont manage see them at all for merging (or their key-value
> pairs if not them directly) then you cant merge correctly. I saw it
> several times and finally bypassed something very close to DS - enough
> time to care about it.
>
> Issue is: if system is too complex or doesnt solve it then Properties
> (or more exactly Map<String, String>) is clearly more efficient: no
> abstraction, can be changed easily when aggregating apps etc...
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-28 12:47 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>>> I m fully ok to remove PropertySource from the API
>>
>> I think we've lost each other.
>>
>> Tamaya PropertySource == DeltaSpike ConfigSource basically.
>> You just cannot remove this without ditching the whole project.
>>
>> The point is that a USER never operates directly with the ConfigSources.
> They are a hidden detail. IF you manually manage them in your application then
> you end up with exactly your problem - you are doomed and cannot simply enhance
> your system but you really need to rework all the applications.
>>
>> If you just say ConfigResolver#getPropertyValue("mykey") and rely
> on the ordinal mechanism then you can just add such a FilteringConfigSource as
> JAR without having to touch any of your code. If you did manage/merge/etc your
> PropertySources manually then you are doomed. That's why I don't like
> that approach.
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>> On Sunday, 28 December 2014, 12:22, Romain Manni-Bucau
> <rm...@gmail.com> wrote:
>>> > Would have been the same since the app is PropertySource aware.
> Can also
>>> mean we dont have PropertySource in a default impl and then it is true
> it
>>> is easy. I m fully ok to remove PropertySource from the API and make it
> an
>>> impl detail.
>>> Le 28 déc. 2014 11:59, "Mark Struberg"
> <st...@yahoo.de> a
>>> écrit :
>>>
>>>> But if you would have had this container wide
> 'AdminConfigSource'
>>> with the
>>>> nice gui, or a installation wide DatabaesConfigSource then it
> would not
>>>> have been a problem, right?
>>>>
>>>> I mean you would have to add this filter to all the 100 apps in
> the 1 day
>>>> as well, right? So it would be the exact same effort to just add 1
>>>> FilteringConfigSource (hacky but works) with a high priority
> either, right?
>>>> That would be just adding a single jar to all your lib folders...
>>>>
>>>>
>>>> Sometimes we tend to add new mechanisms out of blindness. But the
> problem
>>>> often can be solved easily with existing tools - we just often
> don't
>>> see
>>>> them. This happens to me as well, but I'm glad to have really
> brilliant
>>>> co-workers which often stop me from doing overly complicated crazy
> things.
>>>> Happens more often than I like it ;)
>>>>
>>>>
>>>> Of course sometimes we really need to add a new mechanism. But
> this should
>>>> only be the (almost) last resort if there is no other acceptable
> way.
>>>>
>>>> There are just sooo many weirdo cases out there. Of course they
> are often
>>>> needed in production. But for such huge installations you will
> barely find
>>>> 2 companies with the exact same situation...
>>>>
>>>>
>>>>
>>>> Maybe I'm alone here but my goal is to make the 90-95%
>>> 'standard' use
>>>> cases as easy as possible out of the box. And _additionally_ have
> an SPI
>>>> layer which is very deep down to the metal and as flexible as
> possible to
>>>> allow solving more complex edge cases.
>>>>
>>>> And I honestly don't care if a programmer does need to write
> 50 lines
>>> more
>>>> for such a seldom case. It's just impossible to solve every
> problem out
>>> of
>>>> the box. That would blow up Tamaya 10x times (or even more). And
> that would
>>>> make it unfriendly (if not even 'unusable') for the 95%
> standard
>>> cases...
>>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>
>>>> > On Sunday, 28 December 2014, 11:41, Romain Manni-Bucau <
>>>> rmannibucau@gmail.com> wrote:
>>>> > >T hat is exactly the difference between real life and
> theory. You
>>> cant
>>>> ask
>>>> > to change 100 apps in 1 day...you have to live with
>>>> >
>>>> > Le 28 déc. 2014 10:33, "Mark Struberg"
>>> <st...@yahoo.de> a
>>>> > écrit :
>>>> >
>>>> >> I don't get your samples Romain.
>>>> >>
>>>> >> In v1 you have configured keys A,B,C
>>>> >> In v2 you have D. So what?
>>>> >>
>>>> >> Just remove A,B,C and use D instead. That's exactly
> the same
>>> like
>>>> > changing
>>>> >> a table structure.
>>>> >>
>>>> >> Doing some 'translation' just because the ops
> guys
>>> don't want
>>>> > to change
>>>> >> configuration is a total dead end and will end up being
> a
>>> maintenance
>>>> >> nightmare in v3++. Your filter mechanism is just an
> utter ugly
>>> hack
>>>> and if
>>>> >> I would be the manager of this project then I'd call
> you
>>> names ;)
>>>> >>
>>>> >> That's like arguing that maven is not usable because
> it makes
>>> scripting
>>>> >> hard. This is a FEATURE and not a bug!. People should
> not script
>>>> builds! If
>>>> >> they like to do complicated stuff then it's very
> easy to
>>> write plugins.
>>>> > In
>>>> >> our case it's very easy to write ConfigSources.
>>>> >>
>>>> >>
>>>> >> Remember the old saying "dirty remains, while quick
> is long
>>>> > forgotten"
>>>> >>
>>>> >>
>>>> >> > Some config can conflict
>>>> >>
>>>> >> No. That's the same like with JNDI, JMX etc. Just
> tell them
>>> to use
>>>> > their
>>>> >> own namespaces and you are done.
>>>> >> That's like saying Java is not good because if I
> have
>>> multiple JARs
>>>> > which
>>>> >> contain the same ClassName then it doesn't work.
> JUST USE
>>> NAMESPACES.
>>>> > You
>>>> >> don't need any explicit merging.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Oki, that was 2 arguments and both of them are actually
>>> non-problems.
>>>> >>
>>>> >> Cmon folks, give me more use cases and examples. I'm
> ready to
>>> solve
>>>> > them ;)
>>>> >>
>>>> >>
>>>> >> LieGrue,
>>>> >> strub
>>>> >>
>>>> >> On Sunday, 28 December 2014, 9:54, Romain Manni-Bucau
> <
>>>> >> rmannibucau@gmail.com> wrote:
>>>> >> >Well more I read more I think there is a real need
> but we are
>>> all
>>>> wrong
>>>> >> so instead of fighting please help us finding a
> solution.
>>>> >> >@Mark: priorities or ordinal are great while you
> completely
>>> own the
>>>> app
>>>> >> and its config + it is a single technical version. I
> guess you
>>> know it
>>>> is
>>>> >> not always (rarely?) The case in medium and big
> projects.
>>>> >> >A sample can be: v1 you configure an url with host,
> port
>>> propertkes
>>>> and
>>>> >> in v2 it is directly the url cause you added a path. Can
> be the
>>> same
>>>> for
>>>> >> datasource and business config etc...
>>>> >> >What I did in practise was to use a filter mecanism
> but it
>>> was an ugly
>>>> >> hack.
>>>> >> >For such cases you can maybe use PropertySource
> translators
>>> or things
>>>> >> like that to ensure the config is in the right format
> and then
>>> merge
>>>> with
>>>> >> ordinal.
>>>> >> >Now let take the case where you package together
> several sub
>>> apps
>>>> > coming
>>>> >> with their config. How do you do? Some config can
> conflict and
>>> the
>>>> >> selection is not ordinal based - let me guess it will be
> the
>>> same.
>>>> Best is
>>>> >> to have both property sources and merge them into a
> single one.
>>> Kind of
>>>> >> Properties merge(Properties current, PropertySource
> next).
>>>> >> >I am not happy with these solutions but the needs
> are here
>>> and not
>>>> >> something thought but really met - even if I dont have
> your
>>>> experiences.
>>>> >> >Point is we cant assume config will be perfect so
> let our
>>> future users
>>>> >> make errors and be able to fix it easily.
>>>> >> >Le 27 déc. 2014 14:50, "Mark Struberg"
>>>> > <st...@yahoo.de> a écrit :
>>>> >> >>
>>>> >> >> No Anatole, I DO get it, but I really think it
> is a bad
>>> idea.
>>>> > Because
>>>> >> it adds way too much complexity or a very limited
> benefit.
>>>> >> >>
>>>> >> >>
>>>> >> >> Think about it in an analogy to the
> ExpressionLanguage
>>> ELResolver
>>>> >> chain. Of course this is a sorted lookup chain. And this
> list is
>>> fixed!
>>>> >> >>
>>>> >> >> And at runtime you cannot change the order and
> the user
>>> also does
>>>> > not
>>>> >> care!
>>>> >> >> All he cares is that #{user.name} does the
> right
>>> thing. He
>>>> > does not
>>>> >> have to express an 'evaluator' and the chain
> ordering for
>>> each and
>>>> > every EL
>>>> >> invocation. It just does not make any sense from a users
>>> perspective.
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> LieGrue,
>>>> >> >> strub
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> On Saturday, 27 December 2014, 14:17, Anatole
> Tresch
>>> <
>>>> >> atsticks@gmail.com> wrote:
>>>> >> >>
>>>> >> >>
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >Hi Mark
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >2014-12-27 12:56 GMT+01:00 Mark Struberg
>>>> > <st...@yahoo.de>:
>>>> >> >> >
>>>> >> >> >> The mechanism is clumsy and implies
>>>> >> >> >>> constraints that are already known
> as of
>>> now not
>>>> > matching all use
>>>> >> cases.
>>>> >> >> >>
>>>> >> >> >>Tell me some limitations. Never had
> one. So just
>>> enlist
>>>> > them here and
>>>> >> now.
>>>> >> >> >>
>>>> >> >> >And I am working since decades as well in
> the
>>> industry. I
>>>> > will not
>>>> >> argue about use cases. I gave you same examples. You
> have the
>>> stand my
>>>> >> opinion, unless you feel your opinion counts more than
> mine.
>>>> >> >> >
>>>> >> >> >> On top of it the priority leaks into
> the
>>> PropertySource
>>>> > API
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>Because it IS part of the
> PropertySource!
>>>> >> >> >>
>>>> >> >> >
>>>> >> >> >But it shoud not. I want to have my
> property
>>> sources and I
>>>> > want to
>>>> >> combine them they way I want it. I want the concern of
> assembly
>>> being
>>>> >> separated from the source itself.
>>>> >> >> >It is like you write a Java program like
> this:
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >2: {
>>>> >> >> >4: }
>>>> >> >> >
>>>> >> >> >3: System.out.println();
>>>> >> >> >1: for(int i=0;i<10;i11)
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >Shows pretty much the nonsense of your
>>> argumentation. For
>>>> > priorizing
>>>> >> the loading of components in CDI priorities are great
> and
>>> sufficient,
>>>> here
>>>> >> they are not.
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >> Finally functions is the
>>>> >> >> >>
>>>> >> >> >>> modern way of modelling such an
> operation.
>>>> >> >> >>
>>>> >> >> >>If you have a hammer...
>>>> >> >> >>I'm not interested in style if it
>>> doesn't add any
>>>> > real benefit.
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >If the hammer is more elegant and powerful
> but
>>> still easy
>>>> > than you
>>>> >> outstyled solution, let it be a hammer!
>>>> >> >> >
>>>> >> >> >>> different or
>>>> >> >> >>
>>>> >> >> >>> partial overridings (common in
> complex
>>> environments)
>>>> >> >> >>
>>>> >> >> >>Never came across this need and I did
> very
>>> complex
>>>> > projects. It's
>>>> >> always a trade off between an easy straight forward
> algorigthm
>>> which
>>>> are
>>>> >> easy to understand but sometimes you have to bend em a
> bit or
>>> program
>>>> your
>>>> >> own (PropertySource). The other option is to have hugely
> complex
>>> base
>>>> >> mechanism which noone can use in practice because it is
> 'too
>>>> > flexible' -
>>>> >> means not clear and straight enough.
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>> you will never get one solution,
> which a
>>> special type
>>>> > of
>>>> >> >> >>
>>>> >> >> >>> overridings that matches all
> users.
>>>> >> >> >>Oh sure we do. By having the
> ConfigSource define
>>> their
>>>> > ordinal
>>>> >> themselves and it being really easy for a programmer to
> add own
>>>> >> ConfigSources we have all of that!
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>> A solution should NEVER constraint
> users in
>>> doing the
>>>> > stuff
>>>> >> >> >>> they want!*
>>>> >> >> >>
>>>> >> >> >>Having the sorting via Ordinal
> doesn't
>>> impose any
>>>> > restriction on the
>>>> >> user. Because he can easily overwrite those values.
>>>> >> >> >>We are talking about a simple straight
> forward
>>> config
>>>> > mechanism and
>>>> >> not about alien rocket science and time travelling.
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>>You are not on green field here!
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>Oh boy, we are! We just need to fulfil
> user
>>> needs,
>>>> > that's all.
>>>> >> >> >I am not a boy. I am an adult with 44 years
> on
>>> track.... !
>>>> >> >> >And BTW you seem to have lost every kind of
> reality
>>> contact.
>>>> > Do you
>>>> >> really think companies will change their internal
> systems
>>> completely
>>>> >> because just a few guys think they know
>>>> >> >> >how the world is rouling...? NO!
>>>> >> >> >
>>>> >> >> >>
>>>> >> >> >>> *Of course not! (despite the fact
> that is
>>> trivial
>>>> > for the ones
>>>> >> used the
>>>> >> >> >>> functional style of Java 8).
>>>> >> >> >>Of course I know Map#merge, but what do
> you use
>>> it for? To
>>>> > me it
>>>> >> seems like an overkill.
>>>> >> >> >Seems that your mindis still stick on Java
> 7.,,,
>>>> >> >> >
>>>> >> >> >> You can still provide a singleton with
>>>> >> >> >>> constants, where you*
>>>> >> >> >>> *provide the most common
> combinations, see
>>>> > AggregationPolicy in my
>>>> >> the
>>>> >> >> >>> current tree.*
>>>> >> >> >>
>>>> >> >> >>Again: I don't see the benefit. If
> I'm
>>> in an EAR
>>>> > and like to get my
>>>> >> "documentarchive.endpoint.url" then WHY would
> I like to
>>> manually
>>>> > change the
>>>> >> aggregation? Makes no sense to me. And this increases
> the
>>> complexity
>>>> quite
>>>> >> impressively.
>>>> >> >> >>
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >Perhaps one day you realize that we are
> talking
>>> about a
>>>> > general
>>>> >> configuration soultion. EE is a sepcial case, not the
> other way
>>> round.
>>>> It
>>>> >> is NOT like Deltaspike, which benefits the mechanism
> provided by
>>> CDI.
>>>> It is
>>>> >> not and if it will, it gets Deltaspike 2, which is
> useless. There
>>> is
>>>> >> already one, which for its purposes on this level, I
> agree, works
>>>> well. But
>>>> >> for a general solution it lacks so much on
> functionality-
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >I personally really think you still do not
> get the
>>>> > difference! It
>>>> >> drives me crazy.
>>>> >> >> >
>>>> >> >> >LieGrue,
>>>> >> >> >>strub
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>> On Saturday, 27 December 2014,
> 12:28,
>>> Anatole Tresch
>>>> > <
>>>> >> atsticks@gmail.com> wrote:
>>>> >> >> >>> > *See inline...*
>>>> >> >> >>>
>>>> >> >> >>> 2014-12-27 11:42 GMT+01:00 Mark
> Struberg
>>>> > <st...@yahoo.de>:
>>>> >> >> >>>
>>>> >> >> >>>> Hi!
>>>> >> >> >>>>
>>>> >> >> >>>> 1.1)
>>>> >> >> >>>>
>>>> >> >> >>>> I think we agree that having
> a
>>>> > PropertySource/ConfigSource SPI
>>>> >> with MANY
>>>> >> >> >>>> implementations is the way to
> go?
>>>> >> >> >>>> Any objections?
>>>> >> >> >>>>
>>>> >> >> >>> *+1 The way to go.*
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>> 1.2)
>>>> >> >> >>>>
>>>> >> >> >>>> Where should it belong to? Is
> it an
>>> API or
>>>> > rather an SPI?
>>>> >> >> >>>> I think it's more the
> later. A end
>>> user just
>>>> > likes to get the
>>>> >> >> >>> 'final'
>>>> >> >> >>>> configured values and does
> NOT deal
>>> with the
>>>> > PropertySources
>>>> >> himself. It is
>>>> >> >> >>>> really just for extending the
> system
>>> -> SPI.
>>>> >> >> >>>>
>>>> >> >> >>> *+1 for PropertySource being an
> SPI.
>>> Configuration
>>>> > must be the
>>>> >> API.*
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>> 1.3)
>>>> >> >> >>>> Merging.
>>>> >> >> >>>> Option (1.3.a) Do we like to
> do
>>>> > 'implicit' merging (aka the
>>>> >> >> >>> ordinal
>>>> >> >> >>>> stuff).
>>>> >> >> >>>>
>>>> >> >> >>> *It's not a question of taste.
> The
>>> mechanism is
>>>> > clumsy and implies
>>>> >> >> >>> constraints that are already known
> as of
>>> now not
>>>> > matching all use
>>>> >> cases. On
>>>> >> >> >>> top of it the priority leaks into
> the
>>> PropertySoiurce
>>>> > API (as an
>>>> >> additional
>>>> >> >> >>> method, which is a very ugly mix
> of
>>> concerns),
>>>> > Finally functions is
>>>> >> the
>>>> >> >> >>> modern way of modelling such an
> operation.*
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>>> Option (1.3.b) Or do we like
>>> 'explicit'
>>>> > (the merge function). What
>>>> >> >> >>> benefit
>>>> >> >> >>>> does this add in practice?
>>>> >> >> >>>>
>>>> >> >> >>>
>>>> >> >> >>> *See above and as outlined
> multiple times.
>>> Adding
>>>> > additional
>>>> >> functionality
>>>> >> >> >>> for audit (e.g. logging of the
>>> configuration
>>>> > overriding), different
>>>> >> or
>>>> >> >> >>> partial overridings (common in
> complex
>>> environments).
>>>> > Please stop
>>>> >> >> >>> discussion on this priority thing,
> it's
>>> simply
>>>> > not enough! By the
>>>> >> way the
>>>> >> >> >>> priority thing can still be
> implemented,
>>> when the
>>>> > rest of the
>>>> >> design is
>>>> >> >> >>> done in a modular way. My proposed
> solution
>>> gave you
>>>> > the
>>>> >> abtrsaction of a
>>>> >> >> >>> ConfigProvider BTW, where you
> could do this
>>> easily,
>>>> > but also the
>>>> >> other
>>>> >> >> >>> stuff. What you do depends on the
> use case,
>>> and to
>>>> > some extent your
>>>> >> >> >>> personal taste. A solution should
> NEVER
>>> constraint
>>>> > users in doing
>>>> >> the stuff
>>>> >> >> >>> they want!*
>>>> >> >> >>>
>>>> >> >> >>> Ad 1.3.a 'explicit'
> merging: This
>>> is
>>>> > basically the DeltaSpike mode:
>>>> >> EACH
>>>> >> >> >>>> ConfigSource (PropertySource)
> has an
>>> ordinal
>>>> > which it can set
>>>> >> itself. The
>>>> >> >> >>>> higher the configuration
> ordinal of
>>> the
>>>> > ConfigSource, the more
>>>> >> important it
>>>> >> >> >>>> is and it will override
> values from
>>>> > ConfigSources with lower
>>>> >> ordinal.
>>>> >> >> >>>>
>>>> >> >> >>>> That way it is possible to
> have a kind
>>> of
>>>> > 'default configuration'
>>>> >> >> >>> e.g. in
>>>> >> >> >>>> a property file inside your
> project
>>> and later
>>>> > overwrite it via
>>>> >> -Dxxx=yyy,
>>>> >> >> >>>> JNDI, or some container
> provided
>>>> > MyCountainerAdminConfigSource
>>>> >> etc later.
>>>> >> >> >>>>
>>>> >> >> >>> *No Mark. The fact of having a
> default
>>> configuration
>>>> > does not
>>>> >> interconnect
>>>> >> >> >>> how this is evaluated and
> composed. You are
>>> wrong!
>>>> > And on top,
>>>> >> when I look
>>>> >> >> >>> at your ideas: you will never get
> one
>>> solution, which
>>>> > a special
>>>> >> type of
>>>> >> >> >>> overridings that matches all
> users. You
>>> have to
>>>> > provide building
>>>> >> blocks
>>>> >> >> >>> (one more) that helps the users
> (companies)
>>> to model
>>>> > their
>>>> >> functionality
>>>> >> >> >>> with it. You are not on green
> field here!*
>>>> >> >> >>>
>>>> >> >> >>> Ad 1.3.b 'implicit'
> merging: Well,
>>> actually I
>>>> > don't got this. There
>>>> >> >> >>> was
>>>> >> >> >>>> merge(String key,
> PropertySource s1,
>>> s2), but
>>>> > that would mean
>>>> >> that every
>>>> >> >> >>>> user needs to deal with that
> himself?
>>> Could you
>>>> > please elaborate
>>>> >> on that
>>>> >> >> >>>> option? I didn't get it..
>>>> >> >> >>>
>>>> >> >> >>> *Of course not! (despite the fact
> that is
>>> trivial
>>>> > for the ones
>>>> >> used the
>>>> >> >> >>> functional style of Java 8). You
> can still
>>> provide a
>>>> > singleton with
>>>> >> >> >>> constants, where you*
>>>> >> >> >>> *provide the most common
> combinations, see
>>>> > AggregationPolicy in my
>>>> >> the
>>>> >> >> >>> current tree.*
>>>> >> >> >>>
>>>> >> >> >>> *-Anatole*
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>
>>>> >> >> >>>> LieGrue,
>>>> >> >> >>>> strub
>>>> >> >> >>>>
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>> --
>>>> >> >> >>> *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*
>>>> >> >> >>
>>>> >> >> >>>
>>>> >> >> >>
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >--
>>>> >> >> >
>>>> >> >> >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/
>>>> >> >> >Google: atsticks
>>>> >> >> >Mobile +41-76 344 62 79
>>>> >> >> >
>>>> >> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >>
>>>> >
>>>>
>>>
>
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Romain Manni-Bucau <rm...@gmail.com>.
If you dont manage see them at all for merging (or their key-value
pairs if not them directly) then you cant merge correctly. I saw it
several times and finally bypassed something very close to DS - enough
time to care about it.
Issue is: if system is too complex or doesnt solve it then Properties
(or more exactly Map<String, String>) is clearly more efficient: no
abstraction, can be changed easily when aggregating apps etc...
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-28 12:47 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>> I m fully ok to remove PropertySource from the API
>
> I think we've lost each other.
>
> Tamaya PropertySource == DeltaSpike ConfigSource basically.
> You just cannot remove this without ditching the whole project.
>
> The point is that a USER never operates directly with the ConfigSources. They are a hidden detail. IF you manually manage them in your application then you end up with exactly your problem - you are doomed and cannot simply enhance your system but you really need to rework all the applications.
>
> If you just say ConfigResolver#getPropertyValue("mykey") and rely on the ordinal mechanism then you can just add such a FilteringConfigSource as JAR without having to touch any of your code. If you did manage/merge/etc your PropertySources manually then you are doomed. That's why I don't like that approach.
>
>
>
> LieGrue,
> strub
>
>
>
>
>
>> On Sunday, 28 December 2014, 12:22, Romain Manni-Bucau <rm...@gmail.com> wrote:
>> > Would have been the same since the app is PropertySource aware. Can also
>> mean we dont have PropertySource in a default impl and then it is true it
>> is easy. I m fully ok to remove PropertySource from the API and make it an
>> impl detail.
>> Le 28 déc. 2014 11:59, "Mark Struberg" <st...@yahoo.de> a
>> écrit :
>>
>>> But if you would have had this container wide 'AdminConfigSource'
>> with the
>>> nice gui, or a installation wide DatabaesConfigSource then it would not
>>> have been a problem, right?
>>>
>>> I mean you would have to add this filter to all the 100 apps in the 1 day
>>> as well, right? So it would be the exact same effort to just add 1
>>> FilteringConfigSource (hacky but works) with a high priority either, right?
>>> That would be just adding a single jar to all your lib folders...
>>>
>>>
>>> Sometimes we tend to add new mechanisms out of blindness. But the problem
>>> often can be solved easily with existing tools - we just often don't
>> see
>>> them. This happens to me as well, but I'm glad to have really brilliant
>>> co-workers which often stop me from doing overly complicated crazy things.
>>> Happens more often than I like it ;)
>>>
>>>
>>> Of course sometimes we really need to add a new mechanism. But this should
>>> only be the (almost) last resort if there is no other acceptable way.
>>>
>>> There are just sooo many weirdo cases out there. Of course they are often
>>> needed in production. But for such huge installations you will barely find
>>> 2 companies with the exact same situation...
>>>
>>>
>>>
>>> Maybe I'm alone here but my goal is to make the 90-95%
>> 'standard' use
>>> cases as easy as possible out of the box. And _additionally_ have an SPI
>>> layer which is very deep down to the metal and as flexible as possible to
>>> allow solving more complex edge cases.
>>>
>>> And I honestly don't care if a programmer does need to write 50 lines
>> more
>>> for such a seldom case. It's just impossible to solve every problem out
>> of
>>> the box. That would blow up Tamaya 10x times (or even more). And that would
>>> make it unfriendly (if not even 'unusable') for the 95% standard
>> cases...
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>> > On Sunday, 28 December 2014, 11:41, Romain Manni-Bucau <
>>> rmannibucau@gmail.com> wrote:
>>> > >T hat is exactly the difference between real life and theory. You
>> cant
>>> ask
>>> > to change 100 apps in 1 day...you have to live with
>>> >
>>> > Le 28 déc. 2014 10:33, "Mark Struberg"
>> <st...@yahoo.de> a
>>> > écrit :
>>> >
>>> >> I don't get your samples Romain.
>>> >>
>>> >> In v1 you have configured keys A,B,C
>>> >> In v2 you have D. So what?
>>> >>
>>> >> Just remove A,B,C and use D instead. That's exactly the same
>> like
>>> > changing
>>> >> a table structure.
>>> >>
>>> >> Doing some 'translation' just because the ops guys
>> don't want
>>> > to change
>>> >> configuration is a total dead end and will end up being a
>> maintenance
>>> >> nightmare in v3++. Your filter mechanism is just an utter ugly
>> hack
>>> and if
>>> >> I would be the manager of this project then I'd call you
>> names ;)
>>> >>
>>> >> That's like arguing that maven is not usable because it makes
>> scripting
>>> >> hard. This is a FEATURE and not a bug!. People should not script
>>> builds! If
>>> >> they like to do complicated stuff then it's very easy to
>> write plugins.
>>> > In
>>> >> our case it's very easy to write ConfigSources.
>>> >>
>>> >>
>>> >> Remember the old saying "dirty remains, while quick is long
>>> > forgotten"
>>> >>
>>> >>
>>> >> > Some config can conflict
>>> >>
>>> >> No. That's the same like with JNDI, JMX etc. Just tell them
>> to use
>>> > their
>>> >> own namespaces and you are done.
>>> >> That's like saying Java is not good because if I have
>> multiple JARs
>>> > which
>>> >> contain the same ClassName then it doesn't work. JUST USE
>> NAMESPACES.
>>> > You
>>> >> don't need any explicit merging.
>>> >>
>>> >>
>>> >>
>>> >> Oki, that was 2 arguments and both of them are actually
>> non-problems.
>>> >>
>>> >> Cmon folks, give me more use cases and examples. I'm ready to
>> solve
>>> > them ;)
>>> >>
>>> >>
>>> >> LieGrue,
>>> >> strub
>>> >>
>>> >> On Sunday, 28 December 2014, 9:54, Romain Manni-Bucau <
>>> >> rmannibucau@gmail.com> wrote:
>>> >> >Well more I read more I think there is a real need but we are
>> all
>>> wrong
>>> >> so instead of fighting please help us finding a solution.
>>> >> >@Mark: priorities or ordinal are great while you completely
>> own the
>>> app
>>> >> and its config + it is a single technical version. I guess you
>> know it
>>> is
>>> >> not always (rarely?) The case in medium and big projects.
>>> >> >A sample can be: v1 you configure an url with host, port
>> propertkes
>>> and
>>> >> in v2 it is directly the url cause you added a path. Can be the
>> same
>>> for
>>> >> datasource and business config etc...
>>> >> >What I did in practise was to use a filter mecanism but it
>> was an ugly
>>> >> hack.
>>> >> >For such cases you can maybe use PropertySource translators
>> or things
>>> >> like that to ensure the config is in the right format and then
>> merge
>>> with
>>> >> ordinal.
>>> >> >Now let take the case where you package together several sub
>> apps
>>> > coming
>>> >> with their config. How do you do? Some config can conflict and
>> the
>>> >> selection is not ordinal based - let me guess it will be the
>> same.
>>> Best is
>>> >> to have both property sources and merge them into a single one.
>> Kind of
>>> >> Properties merge(Properties current, PropertySource next).
>>> >> >I am not happy with these solutions but the needs are here
>> and not
>>> >> something thought but really met - even if I dont have your
>>> experiences.
>>> >> >Point is we cant assume config will be perfect so let our
>> future users
>>> >> make errors and be able to fix it easily.
>>> >> >Le 27 déc. 2014 14:50, "Mark Struberg"
>>> > <st...@yahoo.de> a écrit :
>>> >> >>
>>> >> >> No Anatole, I DO get it, but I really think it is a bad
>> idea.
>>> > Because
>>> >> it adds way too much complexity or a very limited benefit.
>>> >> >>
>>> >> >>
>>> >> >> Think about it in an analogy to the ExpressionLanguage
>> ELResolver
>>> >> chain. Of course this is a sorted lookup chain. And this list is
>> fixed!
>>> >> >>
>>> >> >> And at runtime you cannot change the order and the user
>> also does
>>> > not
>>> >> care!
>>> >> >> All he cares is that #{user.name} does the right
>> thing. He
>>> > does not
>>> >> have to express an 'evaluator' and the chain ordering for
>> each and
>>> > every EL
>>> >> invocation. It just does not make any sense from a users
>> perspective.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> LieGrue,
>>> >> >> strub
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Saturday, 27 December 2014, 14:17, Anatole Tresch
>> <
>>> >> atsticks@gmail.com> wrote:
>>> >> >>
>>> >> >>
>>> >> >> >
>>> >> >> >
>>> >> >> >Hi Mark
>>> >> >> >
>>> >> >> >
>>> >> >> >2014-12-27 12:56 GMT+01:00 Mark Struberg
>>> > <st...@yahoo.de>:
>>> >> >> >
>>> >> >> >> The mechanism is clumsy and implies
>>> >> >> >>> constraints that are already known as of
>> now not
>>> > matching all use
>>> >> cases.
>>> >> >> >>
>>> >> >> >>Tell me some limitations. Never had one. So just
>> enlist
>>> > them here and
>>> >> now.
>>> >> >> >>
>>> >> >> >And I am working since decades as well in the
>> industry. I
>>> > will not
>>> >> argue about use cases. I gave you same examples. You have the
>> stand my
>>> >> opinion, unless you feel your opinion counts more than mine.
>>> >> >> >
>>> >> >> >> On top of it the priority leaks into the
>> PropertySource
>>> > API
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>Because it IS part of the PropertySource!
>>> >> >> >>
>>> >> >> >
>>> >> >> >But it shoud not. I want to have my property
>> sources and I
>>> > want to
>>> >> combine them they way I want it. I want the concern of assembly
>> being
>>> >> separated from the source itself.
>>> >> >> >It is like you write a Java program like this:
>>> >> >> >
>>> >> >> >
>>> >> >> >2: {
>>> >> >> >4: }
>>> >> >> >
>>> >> >> >3: System.out.println();
>>> >> >> >1: for(int i=0;i<10;i11)
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >Shows pretty much the nonsense of your
>> argumentation. For
>>> > priorizing
>>> >> the loading of components in CDI priorities are great and
>> sufficient,
>>> here
>>> >> they are not.
>>> >> >> >
>>> >> >> >
>>> >> >> >> Finally functions is the
>>> >> >> >>
>>> >> >> >>> modern way of modelling such an operation.
>>> >> >> >>
>>> >> >> >>If you have a hammer...
>>> >> >> >>I'm not interested in style if it
>> doesn't add any
>>> > real benefit.
>>> >> >> >>
>>> >> >> >>
>>> >> >> >If the hammer is more elegant and powerful but
>> still easy
>>> > than you
>>> >> outstyled solution, let it be a hammer!
>>> >> >> >
>>> >> >> >>> different or
>>> >> >> >>
>>> >> >> >>> partial overridings (common in complex
>> environments)
>>> >> >> >>
>>> >> >> >>Never came across this need and I did very
>> complex
>>> > projects. It's
>>> >> always a trade off between an easy straight forward algorigthm
>> which
>>> are
>>> >> easy to understand but sometimes you have to bend em a bit or
>> program
>>> your
>>> >> own (PropertySource). The other option is to have hugely complex
>> base
>>> >> mechanism which noone can use in practice because it is 'too
>>> > flexible' -
>>> >> means not clear and straight enough.
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>> you will never get one solution, which a
>> special type
>>> > of
>>> >> >> >>
>>> >> >> >>> overridings that matches all users.
>>> >> >> >>Oh sure we do. By having the ConfigSource define
>> their
>>> > ordinal
>>> >> themselves and it being really easy for a programmer to add own
>>> >> ConfigSources we have all of that!
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>> A solution should NEVER constraint users in
>> doing the
>>> > stuff
>>> >> >> >>> they want!*
>>> >> >> >>
>>> >> >> >>Having the sorting via Ordinal doesn't
>> impose any
>>> > restriction on the
>>> >> user. Because he can easily overwrite those values.
>>> >> >> >>We are talking about a simple straight forward
>> config
>>> > mechanism and
>>> >> not about alien rocket science and time travelling.
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>>You are not on green field here!
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>Oh boy, we are! We just need to fulfil user
>> needs,
>>> > that's all.
>>> >> >> >I am not a boy. I am an adult with 44 years on
>> track.... !
>>> >> >> >And BTW you seem to have lost every kind of reality
>> contact.
>>> > Do you
>>> >> really think companies will change their internal systems
>> completely
>>> >> because just a few guys think they know
>>> >> >> >how the world is rouling...? NO!
>>> >> >> >
>>> >> >> >>
>>> >> >> >>> *Of course not! (despite the fact that is
>> trivial
>>> > for the ones
>>> >> used the
>>> >> >> >>> functional style of Java 8).
>>> >> >> >>Of course I know Map#merge, but what do you use
>> it for? To
>>> > me it
>>> >> seems like an overkill.
>>> >> >> >Seems that your mindis still stick on Java 7.,,,
>>> >> >> >
>>> >> >> >> You can still provide a singleton with
>>> >> >> >>> constants, where you*
>>> >> >> >>> *provide the most common combinations, see
>>> > AggregationPolicy in my
>>> >> the
>>> >> >> >>> current tree.*
>>> >> >> >>
>>> >> >> >>Again: I don't see the benefit. If I'm
>> in an EAR
>>> > and like to get my
>>> >> "documentarchive.endpoint.url" then WHY would I like to
>> manually
>>> > change the
>>> >> aggregation? Makes no sense to me. And this increases the
>> complexity
>>> quite
>>> >> impressively.
>>> >> >> >>
>>> >> >> >
>>> >> >> >
>>> >> >> >Perhaps one day you realize that we are talking
>> about a
>>> > general
>>> >> configuration soultion. EE is a sepcial case, not the other way
>> round.
>>> It
>>> >> is NOT like Deltaspike, which benefits the mechanism provided by
>> CDI.
>>> It is
>>> >> not and if it will, it gets Deltaspike 2, which is useless. There
>> is
>>> >> already one, which for its purposes on this level, I agree, works
>>> well. But
>>> >> for a general solution it lacks so much on functionality-
>>> >> >> >
>>> >> >> >
>>> >> >> >I personally really think you still do not get the
>>> > difference! It
>>> >> drives me crazy.
>>> >> >> >
>>> >> >> >LieGrue,
>>> >> >> >>strub
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>> On Saturday, 27 December 2014, 12:28,
>> Anatole Tresch
>>> > <
>>> >> atsticks@gmail.com> wrote:
>>> >> >> >>> > *See inline...*
>>> >> >> >>>
>>> >> >> >>> 2014-12-27 11:42 GMT+01:00 Mark Struberg
>>> > <st...@yahoo.de>:
>>> >> >> >>>
>>> >> >> >>>> Hi!
>>> >> >> >>>>
>>> >> >> >>>> 1.1)
>>> >> >> >>>>
>>> >> >> >>>> I think we agree that having a
>>> > PropertySource/ConfigSource SPI
>>> >> with MANY
>>> >> >> >>>> implementations is the way to go?
>>> >> >> >>>> Any objections?
>>> >> >> >>>>
>>> >> >> >>> *+1 The way to go.*
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>> 1.2)
>>> >> >> >>>>
>>> >> >> >>>> Where should it belong to? Is it an
>> API or
>>> > rather an SPI?
>>> >> >> >>>> I think it's more the later. A end
>> user just
>>> > likes to get the
>>> >> >> >>> 'final'
>>> >> >> >>>> configured values and does NOT deal
>> with the
>>> > PropertySources
>>> >> himself. It is
>>> >> >> >>>> really just for extending the system
>> -> SPI.
>>> >> >> >>>>
>>> >> >> >>> *+1 for PropertySource being an SPI.
>> Configuration
>>> > must be the
>>> >> API.*
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>> 1.3)
>>> >> >> >>>> Merging.
>>> >> >> >>>> Option (1.3.a) Do we like to do
>>> > 'implicit' merging (aka the
>>> >> >> >>> ordinal
>>> >> >> >>>> stuff).
>>> >> >> >>>>
>>> >> >> >>> *It's not a question of taste. The
>> mechanism is
>>> > clumsy and implies
>>> >> >> >>> constraints that are already known as of
>> now not
>>> > matching all use
>>> >> cases. On
>>> >> >> >>> top of it the priority leaks into the
>> PropertySoiurce
>>> > API (as an
>>> >> additional
>>> >> >> >>> method, which is a very ugly mix of
>> concerns),
>>> > Finally functions is
>>> >> the
>>> >> >> >>> modern way of modelling such an operation.*
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>>> Option (1.3.b) Or do we like
>> 'explicit'
>>> > (the merge function). What
>>> >> >> >>> benefit
>>> >> >> >>>> does this add in practice?
>>> >> >> >>>>
>>> >> >> >>>
>>> >> >> >>> *See above and as outlined multiple times.
>> Adding
>>> > additional
>>> >> functionality
>>> >> >> >>> for audit (e.g. logging of the
>> configuration
>>> > overriding), different
>>> >> or
>>> >> >> >>> partial overridings (common in complex
>> environments).
>>> > Please stop
>>> >> >> >>> discussion on this priority thing, it's
>> simply
>>> > not enough! By the
>>> >> way the
>>> >> >> >>> priority thing can still be implemented,
>> when the
>>> > rest of the
>>> >> design is
>>> >> >> >>> done in a modular way. My proposed solution
>> gave you
>>> > the
>>> >> abtrsaction of a
>>> >> >> >>> ConfigProvider BTW, where you could do this
>> easily,
>>> > but also the
>>> >> other
>>> >> >> >>> stuff. What you do depends on the use case,
>> and to
>>> > some extent your
>>> >> >> >>> personal taste. A solution should NEVER
>> constraint
>>> > users in doing
>>> >> the stuff
>>> >> >> >>> they want!*
>>> >> >> >>>
>>> >> >> >>> Ad 1.3.a 'explicit' merging: This
>> is
>>> > basically the DeltaSpike mode:
>>> >> EACH
>>> >> >> >>>> ConfigSource (PropertySource) has an
>> ordinal
>>> > which it can set
>>> >> itself. The
>>> >> >> >>>> higher the configuration ordinal of
>> the
>>> > ConfigSource, the more
>>> >> important it
>>> >> >> >>>> is and it will override values from
>>> > ConfigSources with lower
>>> >> ordinal.
>>> >> >> >>>>
>>> >> >> >>>> That way it is possible to have a kind
>> of
>>> > 'default configuration'
>>> >> >> >>> e.g. in
>>> >> >> >>>> a property file inside your project
>> and later
>>> > overwrite it via
>>> >> -Dxxx=yyy,
>>> >> >> >>>> JNDI, or some container provided
>>> > MyCountainerAdminConfigSource
>>> >> etc later.
>>> >> >> >>>>
>>> >> >> >>> *No Mark. The fact of having a default
>> configuration
>>> > does not
>>> >> interconnect
>>> >> >> >>> how this is evaluated and composed. You are
>> wrong!
>>> > And on top,
>>> >> when I look
>>> >> >> >>> at your ideas: you will never get one
>> solution, which
>>> > a special
>>> >> type of
>>> >> >> >>> overridings that matches all users. You
>> have to
>>> > provide building
>>> >> blocks
>>> >> >> >>> (one more) that helps the users (companies)
>> to model
>>> > their
>>> >> functionality
>>> >> >> >>> with it. You are not on green field here!*
>>> >> >> >>>
>>> >> >> >>> Ad 1.3.b 'implicit' merging: Well,
>> actually I
>>> > don't got this. There
>>> >> >> >>> was
>>> >> >> >>>> merge(String key, PropertySource s1,
>> s2), but
>>> > that would mean
>>> >> that every
>>> >> >> >>>> user needs to deal with that himself?
>> Could you
>>> > please elaborate
>>> >> on that
>>> >> >> >>>> option? I didn't get it..
>>> >> >> >>>
>>> >> >> >>> *Of course not! (despite the fact that is
>> trivial
>>> > for the ones
>>> >> used the
>>> >> >> >>> functional style of Java 8). You can still
>> provide a
>>> > singleton with
>>> >> >> >>> constants, where you*
>>> >> >> >>> *provide the most common combinations, see
>>> > AggregationPolicy in my
>>> >> the
>>> >> >> >>> current tree.*
>>> >> >> >>>
>>> >> >> >>> *-Anatole*
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>>>
>>> >> >> >>>>
>>> >> >> >>>
>>> >> >> >>>> LieGrue,
>>> >> >> >>>> strub
>>> >> >> >>>>
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>> --
>>> >> >> >>> *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*
>>> >> >> >>
>>> >> >> >>>
>>> >> >> >>
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >--
>>> >> >> >
>>> >> >> >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/
>>> >> >> >Google: atsticks
>>> >> >> >Mobile +41-76 344 62 79
>>> >> >> >
>>> >> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >
>>>
>>
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Mark Struberg <st...@yahoo.de>.
> I m fully ok to remove PropertySource from the API
I think we've lost each other.
Tamaya PropertySource == DeltaSpike ConfigSource basically.
You just cannot remove this without ditching the whole project.
The point is that a USER never operates directly with the ConfigSources. They are a hidden detail. IF you manually manage them in your application then you end up with exactly your problem - you are doomed and cannot simply enhance your system but you really need to rework all the applications.
If you just say ConfigResolver#getPropertyValue("mykey") and rely on the ordinal mechanism then you can just add such a FilteringConfigSource as JAR without having to touch any of your code. If you did manage/merge/etc your PropertySources manually then you are doomed. That's why I don't like that approach.
LieGrue,
strub
> On Sunday, 28 December 2014, 12:22, Romain Manni-Bucau <rm...@gmail.com> wrote:
> > Would have been the same since the app is PropertySource aware. Can also
> mean we dont have PropertySource in a default impl and then it is true it
> is easy. I m fully ok to remove PropertySource from the API and make it an
> impl detail.
> Le 28 déc. 2014 11:59, "Mark Struberg" <st...@yahoo.de> a
> écrit :
>
>> But if you would have had this container wide 'AdminConfigSource'
> with the
>> nice gui, or a installation wide DatabaesConfigSource then it would not
>> have been a problem, right?
>>
>> I mean you would have to add this filter to all the 100 apps in the 1 day
>> as well, right? So it would be the exact same effort to just add 1
>> FilteringConfigSource (hacky but works) with a high priority either, right?
>> That would be just adding a single jar to all your lib folders...
>>
>>
>> Sometimes we tend to add new mechanisms out of blindness. But the problem
>> often can be solved easily with existing tools - we just often don't
> see
>> them. This happens to me as well, but I'm glad to have really brilliant
>> co-workers which often stop me from doing overly complicated crazy things.
>> Happens more often than I like it ;)
>>
>>
>> Of course sometimes we really need to add a new mechanism. But this should
>> only be the (almost) last resort if there is no other acceptable way.
>>
>> There are just sooo many weirdo cases out there. Of course they are often
>> needed in production. But for such huge installations you will barely find
>> 2 companies with the exact same situation...
>>
>>
>>
>> Maybe I'm alone here but my goal is to make the 90-95%
> 'standard' use
>> cases as easy as possible out of the box. And _additionally_ have an SPI
>> layer which is very deep down to the metal and as flexible as possible to
>> allow solving more complex edge cases.
>>
>> And I honestly don't care if a programmer does need to write 50 lines
> more
>> for such a seldom case. It's just impossible to solve every problem out
> of
>> the box. That would blow up Tamaya 10x times (or even more). And that would
>> make it unfriendly (if not even 'unusable') for the 95% standard
> cases...
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> > On Sunday, 28 December 2014, 11:41, Romain Manni-Bucau <
>> rmannibucau@gmail.com> wrote:
>> > >T hat is exactly the difference between real life and theory. You
> cant
>> ask
>> > to change 100 apps in 1 day...you have to live with
>> >
>> > Le 28 déc. 2014 10:33, "Mark Struberg"
> <st...@yahoo.de> a
>> > écrit :
>> >
>> >> I don't get your samples Romain.
>> >>
>> >> In v1 you have configured keys A,B,C
>> >> In v2 you have D. So what?
>> >>
>> >> Just remove A,B,C and use D instead. That's exactly the same
> like
>> > changing
>> >> a table structure.
>> >>
>> >> Doing some 'translation' just because the ops guys
> don't want
>> > to change
>> >> configuration is a total dead end and will end up being a
> maintenance
>> >> nightmare in v3++. Your filter mechanism is just an utter ugly
> hack
>> and if
>> >> I would be the manager of this project then I'd call you
> names ;)
>> >>
>> >> That's like arguing that maven is not usable because it makes
> scripting
>> >> hard. This is a FEATURE and not a bug!. People should not script
>> builds! If
>> >> they like to do complicated stuff then it's very easy to
> write plugins.
>> > In
>> >> our case it's very easy to write ConfigSources.
>> >>
>> >>
>> >> Remember the old saying "dirty remains, while quick is long
>> > forgotten"
>> >>
>> >>
>> >> > Some config can conflict
>> >>
>> >> No. That's the same like with JNDI, JMX etc. Just tell them
> to use
>> > their
>> >> own namespaces and you are done.
>> >> That's like saying Java is not good because if I have
> multiple JARs
>> > which
>> >> contain the same ClassName then it doesn't work. JUST USE
> NAMESPACES.
>> > You
>> >> don't need any explicit merging.
>> >>
>> >>
>> >>
>> >> Oki, that was 2 arguments and both of them are actually
> non-problems.
>> >>
>> >> Cmon folks, give me more use cases and examples. I'm ready to
> solve
>> > them ;)
>> >>
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >> On Sunday, 28 December 2014, 9:54, Romain Manni-Bucau <
>> >> rmannibucau@gmail.com> wrote:
>> >> >Well more I read more I think there is a real need but we are
> all
>> wrong
>> >> so instead of fighting please help us finding a solution.
>> >> >@Mark: priorities or ordinal are great while you completely
> own the
>> app
>> >> and its config + it is a single technical version. I guess you
> know it
>> is
>> >> not always (rarely?) The case in medium and big projects.
>> >> >A sample can be: v1 you configure an url with host, port
> propertkes
>> and
>> >> in v2 it is directly the url cause you added a path. Can be the
> same
>> for
>> >> datasource and business config etc...
>> >> >What I did in practise was to use a filter mecanism but it
> was an ugly
>> >> hack.
>> >> >For such cases you can maybe use PropertySource translators
> or things
>> >> like that to ensure the config is in the right format and then
> merge
>> with
>> >> ordinal.
>> >> >Now let take the case where you package together several sub
> apps
>> > coming
>> >> with their config. How do you do? Some config can conflict and
> the
>> >> selection is not ordinal based - let me guess it will be the
> same.
>> Best is
>> >> to have both property sources and merge them into a single one.
> Kind of
>> >> Properties merge(Properties current, PropertySource next).
>> >> >I am not happy with these solutions but the needs are here
> and not
>> >> something thought but really met - even if I dont have your
>> experiences.
>> >> >Point is we cant assume config will be perfect so let our
> future users
>> >> make errors and be able to fix it easily.
>> >> >Le 27 déc. 2014 14:50, "Mark Struberg"
>> > <st...@yahoo.de> a écrit :
>> >> >>
>> >> >> No Anatole, I DO get it, but I really think it is a bad
> idea.
>> > Because
>> >> it adds way too much complexity or a very limited benefit.
>> >> >>
>> >> >>
>> >> >> Think about it in an analogy to the ExpressionLanguage
> ELResolver
>> >> chain. Of course this is a sorted lookup chain. And this list is
> fixed!
>> >> >>
>> >> >> And at runtime you cannot change the order and the user
> also does
>> > not
>> >> care!
>> >> >> All he cares is that #{user.name} does the right
> thing. He
>> > does not
>> >> have to express an 'evaluator' and the chain ordering for
> each and
>> > every EL
>> >> invocation. It just does not make any sense from a users
> perspective.
>> >> >>
>> >> >>
>> >> >>
>> >> >> LieGrue,
>> >> >> strub
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Saturday, 27 December 2014, 14:17, Anatole Tresch
> <
>> >> atsticks@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> >Hi Mark
>> >> >> >
>> >> >> >
>> >> >> >2014-12-27 12:56 GMT+01:00 Mark Struberg
>> > <st...@yahoo.de>:
>> >> >> >
>> >> >> >> The mechanism is clumsy and implies
>> >> >> >>> constraints that are already known as of
> now not
>> > matching all use
>> >> cases.
>> >> >> >>
>> >> >> >>Tell me some limitations. Never had one. So just
> enlist
>> > them here and
>> >> now.
>> >> >> >>
>> >> >> >And I am working since decades as well in the
> industry. I
>> > will not
>> >> argue about use cases. I gave you same examples. You have the
> stand my
>> >> opinion, unless you feel your opinion counts more than mine.
>> >> >> >
>> >> >> >> On top of it the priority leaks into the
> PropertySource
>> > API
>> >> >> >>
>> >> >> >>
>> >> >> >>Because it IS part of the PropertySource!
>> >> >> >>
>> >> >> >
>> >> >> >But it shoud not. I want to have my property
> sources and I
>> > want to
>> >> combine them they way I want it. I want the concern of assembly
> being
>> >> separated from the source itself.
>> >> >> >It is like you write a Java program like this:
>> >> >> >
>> >> >> >
>> >> >> >2: {
>> >> >> >4: }
>> >> >> >
>> >> >> >3: System.out.println();
>> >> >> >1: for(int i=0;i<10;i11)
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >Shows pretty much the nonsense of your
> argumentation. For
>> > priorizing
>> >> the loading of components in CDI priorities are great and
> sufficient,
>> here
>> >> they are not.
>> >> >> >
>> >> >> >
>> >> >> >> Finally functions is the
>> >> >> >>
>> >> >> >>> modern way of modelling such an operation.
>> >> >> >>
>> >> >> >>If you have a hammer...
>> >> >> >>I'm not interested in style if it
> doesn't add any
>> > real benefit.
>> >> >> >>
>> >> >> >>
>> >> >> >If the hammer is more elegant and powerful but
> still easy
>> > than you
>> >> outstyled solution, let it be a hammer!
>> >> >> >
>> >> >> >>> different or
>> >> >> >>
>> >> >> >>> partial overridings (common in complex
> environments)
>> >> >> >>
>> >> >> >>Never came across this need and I did very
> complex
>> > projects. It's
>> >> always a trade off between an easy straight forward algorigthm
> which
>> are
>> >> easy to understand but sometimes you have to bend em a bit or
> program
>> your
>> >> own (PropertySource). The other option is to have hugely complex
> base
>> >> mechanism which noone can use in practice because it is 'too
>> > flexible' -
>> >> means not clear and straight enough.
>> >> >> >>
>> >> >> >>
>> >> >> >>> you will never get one solution, which a
> special type
>> > of
>> >> >> >>
>> >> >> >>> overridings that matches all users.
>> >> >> >>Oh sure we do. By having the ConfigSource define
> their
>> > ordinal
>> >> themselves and it being really easy for a programmer to add own
>> >> ConfigSources we have all of that!
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>> A solution should NEVER constraint users in
> doing the
>> > stuff
>> >> >> >>> they want!*
>> >> >> >>
>> >> >> >>Having the sorting via Ordinal doesn't
> impose any
>> > restriction on the
>> >> user. Because he can easily overwrite those values.
>> >> >> >>We are talking about a simple straight forward
> config
>> > mechanism and
>> >> not about alien rocket science and time travelling.
>> >> >> >>
>> >> >> >>
>> >> >> >>>You are not on green field here!
>> >> >> >>
>> >> >> >>
>> >> >> >>Oh boy, we are! We just need to fulfil user
> needs,
>> > that's all.
>> >> >> >I am not a boy. I am an adult with 44 years on
> track.... !
>> >> >> >And BTW you seem to have lost every kind of reality
> contact.
>> > Do you
>> >> really think companies will change their internal systems
> completely
>> >> because just a few guys think they know
>> >> >> >how the world is rouling...? NO!
>> >> >> >
>> >> >> >>
>> >> >> >>> *Of course not! (despite the fact that is
> trivial
>> > for the ones
>> >> used the
>> >> >> >>> functional style of Java 8).
>> >> >> >>Of course I know Map#merge, but what do you use
> it for? To
>> > me it
>> >> seems like an overkill.
>> >> >> >Seems that your mindis still stick on Java 7.,,,
>> >> >> >
>> >> >> >> You can still provide a singleton with
>> >> >> >>> constants, where you*
>> >> >> >>> *provide the most common combinations, see
>> > AggregationPolicy in my
>> >> the
>> >> >> >>> current tree.*
>> >> >> >>
>> >> >> >>Again: I don't see the benefit. If I'm
> in an EAR
>> > and like to get my
>> >> "documentarchive.endpoint.url" then WHY would I like to
> manually
>> > change the
>> >> aggregation? Makes no sense to me. And this increases the
> complexity
>> quite
>> >> impressively.
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >Perhaps one day you realize that we are talking
> about a
>> > general
>> >> configuration soultion. EE is a sepcial case, not the other way
> round.
>> It
>> >> is NOT like Deltaspike, which benefits the mechanism provided by
> CDI.
>> It is
>> >> not and if it will, it gets Deltaspike 2, which is useless. There
> is
>> >> already one, which for its purposes on this level, I agree, works
>> well. But
>> >> for a general solution it lacks so much on functionality-
>> >> >> >
>> >> >> >
>> >> >> >I personally really think you still do not get the
>> > difference! It
>> >> drives me crazy.
>> >> >> >
>> >> >> >LieGrue,
>> >> >> >>strub
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>> On Saturday, 27 December 2014, 12:28,
> Anatole Tresch
>> > <
>> >> atsticks@gmail.com> wrote:
>> >> >> >>> > *See inline...*
>> >> >> >>>
>> >> >> >>> 2014-12-27 11:42 GMT+01:00 Mark Struberg
>> > <st...@yahoo.de>:
>> >> >> >>>
>> >> >> >>>> Hi!
>> >> >> >>>>
>> >> >> >>>> 1.1)
>> >> >> >>>>
>> >> >> >>>> I think we agree that having a
>> > PropertySource/ConfigSource SPI
>> >> with MANY
>> >> >> >>>> implementations is the way to go?
>> >> >> >>>> Any objections?
>> >> >> >>>>
>> >> >> >>> *+1 The way to go.*
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> 1.2)
>> >> >> >>>>
>> >> >> >>>> Where should it belong to? Is it an
> API or
>> > rather an SPI?
>> >> >> >>>> I think it's more the later. A end
> user just
>> > likes to get the
>> >> >> >>> 'final'
>> >> >> >>>> configured values and does NOT deal
> with the
>> > PropertySources
>> >> himself. It is
>> >> >> >>>> really just for extending the system
> -> SPI.
>> >> >> >>>>
>> >> >> >>> *+1 for PropertySource being an SPI.
> Configuration
>> > must be the
>> >> API.*
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> 1.3)
>> >> >> >>>> Merging.
>> >> >> >>>> Option (1.3.a) Do we like to do
>> > 'implicit' merging (aka the
>> >> >> >>> ordinal
>> >> >> >>>> stuff).
>> >> >> >>>>
>> >> >> >>> *It's not a question of taste. The
> mechanism is
>> > clumsy and implies
>> >> >> >>> constraints that are already known as of
> now not
>> > matching all use
>> >> cases. On
>> >> >> >>> top of it the priority leaks into the
> PropertySoiurce
>> > API (as an
>> >> additional
>> >> >> >>> method, which is a very ugly mix of
> concerns),
>> > Finally functions is
>> >> the
>> >> >> >>> modern way of modelling such an operation.*
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>> Option (1.3.b) Or do we like
> 'explicit'
>> > (the merge function). What
>> >> >> >>> benefit
>> >> >> >>>> does this add in practice?
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>> *See above and as outlined multiple times.
> Adding
>> > additional
>> >> functionality
>> >> >> >>> for audit (e.g. logging of the
> configuration
>> > overriding), different
>> >> or
>> >> >> >>> partial overridings (common in complex
> environments).
>> > Please stop
>> >> >> >>> discussion on this priority thing, it's
> simply
>> > not enough! By the
>> >> way the
>> >> >> >>> priority thing can still be implemented,
> when the
>> > rest of the
>> >> design is
>> >> >> >>> done in a modular way. My proposed solution
> gave you
>> > the
>> >> abtrsaction of a
>> >> >> >>> ConfigProvider BTW, where you could do this
> easily,
>> > but also the
>> >> other
>> >> >> >>> stuff. What you do depends on the use case,
> and to
>> > some extent your
>> >> >> >>> personal taste. A solution should NEVER
> constraint
>> > users in doing
>> >> the stuff
>> >> >> >>> they want!*
>> >> >> >>>
>> >> >> >>> Ad 1.3.a 'explicit' merging: This
> is
>> > basically the DeltaSpike mode:
>> >> EACH
>> >> >> >>>> ConfigSource (PropertySource) has an
> ordinal
>> > which it can set
>> >> itself. The
>> >> >> >>>> higher the configuration ordinal of
> the
>> > ConfigSource, the more
>> >> important it
>> >> >> >>>> is and it will override values from
>> > ConfigSources with lower
>> >> ordinal.
>> >> >> >>>>
>> >> >> >>>> That way it is possible to have a kind
> of
>> > 'default configuration'
>> >> >> >>> e.g. in
>> >> >> >>>> a property file inside your project
> and later
>> > overwrite it via
>> >> -Dxxx=yyy,
>> >> >> >>>> JNDI, or some container provided
>> > MyCountainerAdminConfigSource
>> >> etc later.
>> >> >> >>>>
>> >> >> >>> *No Mark. The fact of having a default
> configuration
>> > does not
>> >> interconnect
>> >> >> >>> how this is evaluated and composed. You are
> wrong!
>> > And on top,
>> >> when I look
>> >> >> >>> at your ideas: you will never get one
> solution, which
>> > a special
>> >> type of
>> >> >> >>> overridings that matches all users. You
> have to
>> > provide building
>> >> blocks
>> >> >> >>> (one more) that helps the users (companies)
> to model
>> > their
>> >> functionality
>> >> >> >>> with it. You are not on green field here!*
>> >> >> >>>
>> >> >> >>> Ad 1.3.b 'implicit' merging: Well,
> actually I
>> > don't got this. There
>> >> >> >>> was
>> >> >> >>>> merge(String key, PropertySource s1,
> s2), but
>> > that would mean
>> >> that every
>> >> >> >>>> user needs to deal with that himself?
> Could you
>> > please elaborate
>> >> on that
>> >> >> >>>> option? I didn't get it..
>> >> >> >>>
>> >> >> >>> *Of course not! (despite the fact that is
> trivial
>> > for the ones
>> >> used the
>> >> >> >>> functional style of Java 8). You can still
> provide a
>> > singleton with
>> >> >> >>> constants, where you*
>> >> >> >>> *provide the most common combinations, see
>> > AggregationPolicy in my
>> >> the
>> >> >> >>> current tree.*
>> >> >> >>>
>> >> >> >>> *-Anatole*
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>>> LieGrue,
>> >> >> >>>> strub
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> *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*
>> >> >> >>
>> >> >> >>>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >--
>> >> >> >
>> >> >> >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/
>> >> >> >Google: atsticks
>> >> >> >Mobile +41-76 344 62 79
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >
>>
>
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Would have been the same since the app is PropertySource aware. Can also
mean we dont have PropertySource in a default impl and then it is true it
is easy. I m fully ok to remove PropertySource from the API and make it an
impl detail.
Le 28 déc. 2014 11:59, "Mark Struberg" <st...@yahoo.de> a écrit :
> But if you would have had this container wide 'AdminConfigSource' with the
> nice gui, or a installation wide DatabaesConfigSource then it would not
> have been a problem, right?
>
> I mean you would have to add this filter to all the 100 apps in the 1 day
> as well, right? So it would be the exact same effort to just add 1
> FilteringConfigSource (hacky but works) with a high priority either, right?
> That would be just adding a single jar to all your lib folders...
>
>
> Sometimes we tend to add new mechanisms out of blindness. But the problem
> often can be solved easily with existing tools - we just often don't see
> them. This happens to me as well, but I'm glad to have really brilliant
> co-workers which often stop me from doing overly complicated crazy things.
> Happens more often than I like it ;)
>
>
> Of course sometimes we really need to add a new mechanism. But this should
> only be the (almost) last resort if there is no other acceptable way.
>
> There are just sooo many weirdo cases out there. Of course they are often
> needed in production. But for such huge installations you will barely find
> 2 companies with the exact same situation...
>
>
>
> Maybe I'm alone here but my goal is to make the 90-95% 'standard' use
> cases as easy as possible out of the box. And _additionally_ have an SPI
> layer which is very deep down to the metal and as flexible as possible to
> allow solving more complex edge cases.
>
> And I honestly don't care if a programmer does need to write 50 lines more
> for such a seldom case. It's just impossible to solve every problem out of
> the box. That would blow up Tamaya 10x times (or even more). And that would
> make it unfriendly (if not even 'unusable') for the 95% standard cases...
>
>
> LieGrue,
> strub
>
>
>
>
> > On Sunday, 28 December 2014, 11:41, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
> > >T hat is exactly the difference between real life and theory. You cant
> ask
> > to change 100 apps in 1 day...you have to live with
> >
> > Le 28 déc. 2014 10:33, "Mark Struberg" <st...@yahoo.de> a
> > écrit :
> >
> >> I don't get your samples Romain.
> >>
> >> In v1 you have configured keys A,B,C
> >> In v2 you have D. So what?
> >>
> >> Just remove A,B,C and use D instead. That's exactly the same like
> > changing
> >> a table structure.
> >>
> >> Doing some 'translation' just because the ops guys don't want
> > to change
> >> configuration is a total dead end and will end up being a maintenance
> >> nightmare in v3++. Your filter mechanism is just an utter ugly hack
> and if
> >> I would be the manager of this project then I'd call you names ;)
> >>
> >> That's like arguing that maven is not usable because it makes scripting
> >> hard. This is a FEATURE and not a bug!. People should not script
> builds! If
> >> they like to do complicated stuff then it's very easy to write plugins.
> > In
> >> our case it's very easy to write ConfigSources.
> >>
> >>
> >> Remember the old saying "dirty remains, while quick is long
> > forgotten"
> >>
> >>
> >> > Some config can conflict
> >>
> >> No. That's the same like with JNDI, JMX etc. Just tell them to use
> > their
> >> own namespaces and you are done.
> >> That's like saying Java is not good because if I have multiple JARs
> > which
> >> contain the same ClassName then it doesn't work. JUST USE NAMESPACES.
> > You
> >> don't need any explicit merging.
> >>
> >>
> >>
> >> Oki, that was 2 arguments and both of them are actually non-problems.
> >>
> >> Cmon folks, give me more use cases and examples. I'm ready to solve
> > them ;)
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >> On Sunday, 28 December 2014, 9:54, Romain Manni-Bucau <
> >> rmannibucau@gmail.com> wrote:
> >> >Well more I read more I think there is a real need but we are all
> wrong
> >> so instead of fighting please help us finding a solution.
> >> >@Mark: priorities or ordinal are great while you completely own the
> app
> >> and its config + it is a single technical version. I guess you know it
> is
> >> not always (rarely?) The case in medium and big projects.
> >> >A sample can be: v1 you configure an url with host, port propertkes
> and
> >> in v2 it is directly the url cause you added a path. Can be the same
> for
> >> datasource and business config etc...
> >> >What I did in practise was to use a filter mecanism but it was an ugly
> >> hack.
> >> >For such cases you can maybe use PropertySource translators or things
> >> like that to ensure the config is in the right format and then merge
> with
> >> ordinal.
> >> >Now let take the case where you package together several sub apps
> > coming
> >> with their config. How do you do? Some config can conflict and the
> >> selection is not ordinal based - let me guess it will be the same.
> Best is
> >> to have both property sources and merge them into a single one. Kind of
> >> Properties merge(Properties current, PropertySource next).
> >> >I am not happy with these solutions but the needs are here and not
> >> something thought but really met - even if I dont have your
> experiences.
> >> >Point is we cant assume config will be perfect so let our future users
> >> make errors and be able to fix it easily.
> >> >Le 27 déc. 2014 14:50, "Mark Struberg"
> > <st...@yahoo.de> a écrit :
> >> >>
> >> >> No Anatole, I DO get it, but I really think it is a bad idea.
> > Because
> >> it adds way too much complexity or a very limited benefit.
> >> >>
> >> >>
> >> >> Think about it in an analogy to the ExpressionLanguage ELResolver
> >> chain. Of course this is a sorted lookup chain. And this list is fixed!
> >> >>
> >> >> And at runtime you cannot change the order and the user also does
> > not
> >> care!
> >> >> All he cares is that #{user.name} does the right thing. He
> > does not
> >> have to express an 'evaluator' and the chain ordering for each and
> > every EL
> >> invocation. It just does not make any sense from a users perspective.
> >> >>
> >> >>
> >> >>
> >> >> LieGrue,
> >> >> strub
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Saturday, 27 December 2014, 14:17, Anatole Tresch <
> >> atsticks@gmail.com> wrote:
> >> >>
> >> >>
> >> >> >
> >> >> >
> >> >> >Hi Mark
> >> >> >
> >> >> >
> >> >> >2014-12-27 12:56 GMT+01:00 Mark Struberg
> > <st...@yahoo.de>:
> >> >> >
> >> >> >> The mechanism is clumsy and implies
> >> >> >>> constraints that are already known as of now not
> > matching all use
> >> cases.
> >> >> >>
> >> >> >>Tell me some limitations. Never had one. So just enlist
> > them here and
> >> now.
> >> >> >>
> >> >> >And I am working since decades as well in the industry. I
> > will not
> >> argue about use cases. I gave you same examples. You have the stand my
> >> opinion, unless you feel your opinion counts more than mine.
> >> >> >
> >> >> >> On top of it the priority leaks into the PropertySource
> > API
> >> >> >>
> >> >> >>
> >> >> >>Because it IS part of the PropertySource!
> >> >> >>
> >> >> >
> >> >> >But it shoud not. I want to have my property sources and I
> > want to
> >> combine them they way I want it. I want the concern of assembly being
> >> separated from the source itself.
> >> >> >It is like you write a Java program like this:
> >> >> >
> >> >> >
> >> >> >2: {
> >> >> >4: }
> >> >> >
> >> >> >3: System.out.println();
> >> >> >1: for(int i=0;i<10;i11)
> >> >> >
> >> >> >
> >> >> >
> >> >> >Shows pretty much the nonsense of your argumentation. For
> > priorizing
> >> the loading of components in CDI priorities are great and sufficient,
> here
> >> they are not.
> >> >> >
> >> >> >
> >> >> >> Finally functions is the
> >> >> >>
> >> >> >>> modern way of modelling such an operation.
> >> >> >>
> >> >> >>If you have a hammer...
> >> >> >>I'm not interested in style if it doesn't add any
> > real benefit.
> >> >> >>
> >> >> >>
> >> >> >If the hammer is more elegant and powerful but still easy
> > than you
> >> outstyled solution, let it be a hammer!
> >> >> >
> >> >> >>> different or
> >> >> >>
> >> >> >>> partial overridings (common in complex environments)
> >> >> >>
> >> >> >>Never came across this need and I did very complex
> > projects. It's
> >> always a trade off between an easy straight forward algorigthm which
> are
> >> easy to understand but sometimes you have to bend em a bit or program
> your
> >> own (PropertySource). The other option is to have hugely complex base
> >> mechanism which noone can use in practice because it is 'too
> > flexible' -
> >> means not clear and straight enough.
> >> >> >>
> >> >> >>
> >> >> >>> you will never get one solution, which a special type
> > of
> >> >> >>
> >> >> >>> overridings that matches all users.
> >> >> >>Oh sure we do. By having the ConfigSource define their
> > ordinal
> >> themselves and it being really easy for a programmer to add own
> >> ConfigSources we have all of that!
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>> A solution should NEVER constraint users in doing the
> > stuff
> >> >> >>> they want!*
> >> >> >>
> >> >> >>Having the sorting via Ordinal doesn't impose any
> > restriction on the
> >> user. Because he can easily overwrite those values.
> >> >> >>We are talking about a simple straight forward config
> > mechanism and
> >> not about alien rocket science and time travelling.
> >> >> >>
> >> >> >>
> >> >> >>>You are not on green field here!
> >> >> >>
> >> >> >>
> >> >> >>Oh boy, we are! We just need to fulfil user needs,
> > that's all.
> >> >> >I am not a boy. I am an adult with 44 years on track.... !
> >> >> >And BTW you seem to have lost every kind of reality contact.
> > Do you
> >> really think companies will change their internal systems completely
> >> because just a few guys think they know
> >> >> >how the world is rouling...? NO!
> >> >> >
> >> >> >>
> >> >> >>> *Of course not! (despite the fact that is trivial
> > for the ones
> >> used the
> >> >> >>> functional style of Java 8).
> >> >> >>Of course I know Map#merge, but what do you use it for? To
> > me it
> >> seems like an overkill.
> >> >> >Seems that your mindis still stick on Java 7.,,,
> >> >> >
> >> >> >> You can still provide a singleton with
> >> >> >>> constants, where you*
> >> >> >>> *provide the most common combinations, see
> > AggregationPolicy in my
> >> the
> >> >> >>> current tree.*
> >> >> >>
> >> >> >>Again: I don't see the benefit. If I'm in an EAR
> > and like to get my
> >> "documentarchive.endpoint.url" then WHY would I like to manually
> > change the
> >> aggregation? Makes no sense to me. And this increases the complexity
> quite
> >> impressively.
> >> >> >>
> >> >> >
> >> >> >
> >> >> >Perhaps one day you realize that we are talking about a
> > general
> >> configuration soultion. EE is a sepcial case, not the other way round.
> It
> >> is NOT like Deltaspike, which benefits the mechanism provided by CDI.
> It is
> >> not and if it will, it gets Deltaspike 2, which is useless. There is
> >> already one, which for its purposes on this level, I agree, works
> well. But
> >> for a general solution it lacks so much on functionality-
> >> >> >
> >> >> >
> >> >> >I personally really think you still do not get the
> > difference! It
> >> drives me crazy.
> >> >> >
> >> >> >LieGrue,
> >> >> >>strub
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>> On Saturday, 27 December 2014, 12:28, Anatole Tresch
> > <
> >> atsticks@gmail.com> wrote:
> >> >> >>> > *See inline...*
> >> >> >>>
> >> >> >>> 2014-12-27 11:42 GMT+01:00 Mark Struberg
> > <st...@yahoo.de>:
> >> >> >>>
> >> >> >>>> Hi!
> >> >> >>>>
> >> >> >>>> 1.1)
> >> >> >>>>
> >> >> >>>> I think we agree that having a
> > PropertySource/ConfigSource SPI
> >> with MANY
> >> >> >>>> implementations is the way to go?
> >> >> >>>> Any objections?
> >> >> >>>>
> >> >> >>> *+1 The way to go.*
> >> >> >>>
> >> >> >>>
> >> >> >>> 1.2)
> >> >> >>>>
> >> >> >>>> Where should it belong to? Is it an API or
> > rather an SPI?
> >> >> >>>> I think it's more the later. A end user just
> > likes to get the
> >> >> >>> 'final'
> >> >> >>>> configured values and does NOT deal with the
> > PropertySources
> >> himself. It is
> >> >> >>>> really just for extending the system -> SPI.
> >> >> >>>>
> >> >> >>> *+1 for PropertySource being an SPI. Configuration
> > must be the
> >> API.*
> >> >> >>>
> >> >> >>>
> >> >> >>> 1.3)
> >> >> >>>> Merging.
> >> >> >>>> Option (1.3.a) Do we like to do
> > 'implicit' merging (aka the
> >> >> >>> ordinal
> >> >> >>>> stuff).
> >> >> >>>>
> >> >> >>> *It's not a question of taste. The mechanism is
> > clumsy and implies
> >> >> >>> constraints that are already known as of now not
> > matching all use
> >> cases. On
> >> >> >>> top of it the priority leaks into the PropertySoiurce
> > API (as an
> >> additional
> >> >> >>> method, which is a very ugly mix of concerns),
> > Finally functions is
> >> the
> >> >> >>> modern way of modelling such an operation.*
> >> >> >>>
> >> >> >>>
> >> >> >>>> Option (1.3.b) Or do we like 'explicit'
> > (the merge function). What
> >> >> >>> benefit
> >> >> >>>> does this add in practice?
> >> >> >>>>
> >> >> >>>
> >> >> >>> *See above and as outlined multiple times. Adding
> > additional
> >> functionality
> >> >> >>> for audit (e.g. logging of the configuration
> > overriding), different
> >> or
> >> >> >>> partial overridings (common in complex environments).
> > Please stop
> >> >> >>> discussion on this priority thing, it's simply
> > not enough! By the
> >> way the
> >> >> >>> priority thing can still be implemented, when the
> > rest of the
> >> design is
> >> >> >>> done in a modular way. My proposed solution gave you
> > the
> >> abtrsaction of a
> >> >> >>> ConfigProvider BTW, where you could do this easily,
> > but also the
> >> other
> >> >> >>> stuff. What you do depends on the use case, and to
> > some extent your
> >> >> >>> personal taste. A solution should NEVER constraint
> > users in doing
> >> the stuff
> >> >> >>> they want!*
> >> >> >>>
> >> >> >>> Ad 1.3.a 'explicit' merging: This is
> > basically the DeltaSpike mode:
> >> EACH
> >> >> >>>> ConfigSource (PropertySource) has an ordinal
> > which it can set
> >> itself. The
> >> >> >>>> higher the configuration ordinal of the
> > ConfigSource, the more
> >> important it
> >> >> >>>> is and it will override values from
> > ConfigSources with lower
> >> ordinal.
> >> >> >>>>
> >> >> >>>> That way it is possible to have a kind of
> > 'default configuration'
> >> >> >>> e.g. in
> >> >> >>>> a property file inside your project and later
> > overwrite it via
> >> -Dxxx=yyy,
> >> >> >>>> JNDI, or some container provided
> > MyCountainerAdminConfigSource
> >> etc later.
> >> >> >>>>
> >> >> >>> *No Mark. The fact of having a default configuration
> > does not
> >> interconnect
> >> >> >>> how this is evaluated and composed. You are wrong!
> > And on top,
> >> when I look
> >> >> >>> at your ideas: you will never get one solution, which
> > a special
> >> type of
> >> >> >>> overridings that matches all users. You have to
> > provide building
> >> blocks
> >> >> >>> (one more) that helps the users (companies) to model
> > their
> >> functionality
> >> >> >>> with it. You are not on green field here!*
> >> >> >>>
> >> >> >>> Ad 1.3.b 'implicit' merging: Well, actually I
> > don't got this. There
> >> >> >>> was
> >> >> >>>> merge(String key, PropertySource s1, s2), but
> > that would mean
> >> that every
> >> >> >>>> user needs to deal with that himself? Could you
> > please elaborate
> >> on that
> >> >> >>>> option? I didn't get it..
> >> >> >>>
> >> >> >>> *Of course not! (despite the fact that is trivial
> > for the ones
> >> used the
> >> >> >>> functional style of Java 8). You can still provide a
> > singleton with
> >> >> >>> constants, where you*
> >> >> >>> *provide the most common combinations, see
> > AggregationPolicy in my
> >> the
> >> >> >>> current tree.*
> >> >> >>>
> >> >> >>> *-Anatole*
> >> >> >>>
> >> >> >>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>
> >> >> >>>> LieGrue,
> >> >> >>>> strub
> >> >> >>>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> --
> >> >> >>> *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*
> >> >> >>
> >> >> >>>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >--
> >> >> >
> >> >> >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/
> >> >> >Google: atsticks
> >> >> >Mobile +41-76 344 62 79
> >> >> >
> >> >> >
> >> >
> >> >
> >> >
> >>
> >
>
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Mark Struberg <st...@yahoo.de>.
But if you would have had this container wide 'AdminConfigSource' with the nice gui, or a installation wide DatabaesConfigSource then it would not have been a problem, right?
I mean you would have to add this filter to all the 100 apps in the 1 day as well, right? So it would be the exact same effort to just add 1 FilteringConfigSource (hacky but works) with a high priority either, right? That would be just adding a single jar to all your lib folders...
Sometimes we tend to add new mechanisms out of blindness. But the problem often can be solved easily with existing tools - we just often don't see them. This happens to me as well, but I'm glad to have really brilliant co-workers which often stop me from doing overly complicated crazy things. Happens more often than I like it ;)
Of course sometimes we really need to add a new mechanism. But this should only be the (almost) last resort if there is no other acceptable way.
There are just sooo many weirdo cases out there. Of course they are often needed in production. But for such huge installations you will barely find 2 companies with the exact same situation...
Maybe I'm alone here but my goal is to make the 90-95% 'standard' use cases as easy as possible out of the box. And _additionally_ have an SPI layer which is very deep down to the metal and as flexible as possible to allow solving more complex edge cases.
And I honestly don't care if a programmer does need to write 50 lines more for such a seldom case. It's just impossible to solve every problem out of the box. That would blow up Tamaya 10x times (or even more). And that would make it unfriendly (if not even 'unusable') for the 95% standard cases...
LieGrue,
strub
> On Sunday, 28 December 2014, 11:41, Romain Manni-Bucau <rm...@gmail.com> wrote:
> >T hat is exactly the difference between real life and theory. You cant ask
> to change 100 apps in 1 day...you have to live with
>
> Le 28 déc. 2014 10:33, "Mark Struberg" <st...@yahoo.de> a
> écrit :
>
>> I don't get your samples Romain.
>>
>> In v1 you have configured keys A,B,C
>> In v2 you have D. So what?
>>
>> Just remove A,B,C and use D instead. That's exactly the same like
> changing
>> a table structure.
>>
>> Doing some 'translation' just because the ops guys don't want
> to change
>> configuration is a total dead end and will end up being a maintenance
>> nightmare in v3++. Your filter mechanism is just an utter ugly hack and if
>> I would be the manager of this project then I'd call you names ;)
>>
>> That's like arguing that maven is not usable because it makes scripting
>> hard. This is a FEATURE and not a bug!. People should not script builds! If
>> they like to do complicated stuff then it's very easy to write plugins.
> In
>> our case it's very easy to write ConfigSources.
>>
>>
>> Remember the old saying "dirty remains, while quick is long
> forgotten"
>>
>>
>> > Some config can conflict
>>
>> No. That's the same like with JNDI, JMX etc. Just tell them to use
> their
>> own namespaces and you are done.
>> That's like saying Java is not good because if I have multiple JARs
> which
>> contain the same ClassName then it doesn't work. JUST USE NAMESPACES.
> You
>> don't need any explicit merging.
>>
>>
>>
>> Oki, that was 2 arguments and both of them are actually non-problems.
>>
>> Cmon folks, give me more use cases and examples. I'm ready to solve
> them ;)
>>
>>
>> LieGrue,
>> strub
>>
>> On Sunday, 28 December 2014, 9:54, Romain Manni-Bucau <
>> rmannibucau@gmail.com> wrote:
>> >Well more I read more I think there is a real need but we are all wrong
>> so instead of fighting please help us finding a solution.
>> >@Mark: priorities or ordinal are great while you completely own the app
>> and its config + it is a single technical version. I guess you know it is
>> not always (rarely?) The case in medium and big projects.
>> >A sample can be: v1 you configure an url with host, port propertkes and
>> in v2 it is directly the url cause you added a path. Can be the same for
>> datasource and business config etc...
>> >What I did in practise was to use a filter mecanism but it was an ugly
>> hack.
>> >For such cases you can maybe use PropertySource translators or things
>> like that to ensure the config is in the right format and then merge with
>> ordinal.
>> >Now let take the case where you package together several sub apps
> coming
>> with their config. How do you do? Some config can conflict and the
>> selection is not ordinal based - let me guess it will be the same. Best is
>> to have both property sources and merge them into a single one. Kind of
>> Properties merge(Properties current, PropertySource next).
>> >I am not happy with these solutions but the needs are here and not
>> something thought but really met - even if I dont have your experiences.
>> >Point is we cant assume config will be perfect so let our future users
>> make errors and be able to fix it easily.
>> >Le 27 déc. 2014 14:50, "Mark Struberg"
> <st...@yahoo.de> a écrit :
>> >>
>> >> No Anatole, I DO get it, but I really think it is a bad idea.
> Because
>> it adds way too much complexity or a very limited benefit.
>> >>
>> >>
>> >> Think about it in an analogy to the ExpressionLanguage ELResolver
>> chain. Of course this is a sorted lookup chain. And this list is fixed!
>> >>
>> >> And at runtime you cannot change the order and the user also does
> not
>> care!
>> >> All he cares is that #{user.name} does the right thing. He
> does not
>> have to express an 'evaluator' and the chain ordering for each and
> every EL
>> invocation. It just does not make any sense from a users perspective.
>> >>
>> >>
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>
>> >>
>> >>
>> >> On Saturday, 27 December 2014, 14:17, Anatole Tresch <
>> atsticks@gmail.com> wrote:
>> >>
>> >>
>> >> >
>> >> >
>> >> >Hi Mark
>> >> >
>> >> >
>> >> >2014-12-27 12:56 GMT+01:00 Mark Struberg
> <st...@yahoo.de>:
>> >> >
>> >> >> The mechanism is clumsy and implies
>> >> >>> constraints that are already known as of now not
> matching all use
>> cases.
>> >> >>
>> >> >>Tell me some limitations. Never had one. So just enlist
> them here and
>> now.
>> >> >>
>> >> >And I am working since decades as well in the industry. I
> will not
>> argue about use cases. I gave you same examples. You have the stand my
>> opinion, unless you feel your opinion counts more than mine.
>> >> >
>> >> >> On top of it the priority leaks into the PropertySource
> API
>> >> >>
>> >> >>
>> >> >>Because it IS part of the PropertySource!
>> >> >>
>> >> >
>> >> >But it shoud not. I want to have my property sources and I
> want to
>> combine them they way I want it. I want the concern of assembly being
>> separated from the source itself.
>> >> >It is like you write a Java program like this:
>> >> >
>> >> >
>> >> >2: {
>> >> >4: }
>> >> >
>> >> >3: System.out.println();
>> >> >1: for(int i=0;i<10;i11)
>> >> >
>> >> >
>> >> >
>> >> >Shows pretty much the nonsense of your argumentation. For
> priorizing
>> the loading of components in CDI priorities are great and sufficient, here
>> they are not.
>> >> >
>> >> >
>> >> >> Finally functions is the
>> >> >>
>> >> >>> modern way of modelling such an operation.
>> >> >>
>> >> >>If you have a hammer...
>> >> >>I'm not interested in style if it doesn't add any
> real benefit.
>> >> >>
>> >> >>
>> >> >If the hammer is more elegant and powerful but still easy
> than you
>> outstyled solution, let it be a hammer!
>> >> >
>> >> >>> different or
>> >> >>
>> >> >>> partial overridings (common in complex environments)
>> >> >>
>> >> >>Never came across this need and I did very complex
> projects. It's
>> always a trade off between an easy straight forward algorigthm which are
>> easy to understand but sometimes you have to bend em a bit or program your
>> own (PropertySource). The other option is to have hugely complex base
>> mechanism which noone can use in practice because it is 'too
> flexible' -
>> means not clear and straight enough.
>> >> >>
>> >> >>
>> >> >>> you will never get one solution, which a special type
> of
>> >> >>
>> >> >>> overridings that matches all users.
>> >> >>Oh sure we do. By having the ConfigSource define their
> ordinal
>> themselves and it being really easy for a programmer to add own
>> ConfigSources we have all of that!
>> >> >>
>> >> >>
>> >> >>
>> >> >>> A solution should NEVER constraint users in doing the
> stuff
>> >> >>> they want!*
>> >> >>
>> >> >>Having the sorting via Ordinal doesn't impose any
> restriction on the
>> user. Because he can easily overwrite those values.
>> >> >>We are talking about a simple straight forward config
> mechanism and
>> not about alien rocket science and time travelling.
>> >> >>
>> >> >>
>> >> >>>You are not on green field here!
>> >> >>
>> >> >>
>> >> >>Oh boy, we are! We just need to fulfil user needs,
> that's all.
>> >> >I am not a boy. I am an adult with 44 years on track.... !
>> >> >And BTW you seem to have lost every kind of reality contact.
> Do you
>> really think companies will change their internal systems completely
>> because just a few guys think they know
>> >> >how the world is rouling...? NO!
>> >> >
>> >> >>
>> >> >>> *Of course not! (despite the fact that is trivial
> for the ones
>> used the
>> >> >>> functional style of Java 8).
>> >> >>Of course I know Map#merge, but what do you use it for? To
> me it
>> seems like an overkill.
>> >> >Seems that your mindis still stick on Java 7.,,,
>> >> >
>> >> >> You can still provide a singleton with
>> >> >>> constants, where you*
>> >> >>> *provide the most common combinations, see
> AggregationPolicy in my
>> the
>> >> >>> current tree.*
>> >> >>
>> >> >>Again: I don't see the benefit. If I'm in an EAR
> and like to get my
>> "documentarchive.endpoint.url" then WHY would I like to manually
> change the
>> aggregation? Makes no sense to me. And this increases the complexity quite
>> impressively.
>> >> >>
>> >> >
>> >> >
>> >> >Perhaps one day you realize that we are talking about a
> general
>> configuration soultion. EE is a sepcial case, not the other way round. It
>> is NOT like Deltaspike, which benefits the mechanism provided by CDI. It is
>> not and if it will, it gets Deltaspike 2, which is useless. There is
>> already one, which for its purposes on this level, I agree, works well. But
>> for a general solution it lacks so much on functionality-
>> >> >
>> >> >
>> >> >I personally really think you still do not get the
> difference! It
>> drives me crazy.
>> >> >
>> >> >LieGrue,
>> >> >>strub
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>> On Saturday, 27 December 2014, 12:28, Anatole Tresch
> <
>> atsticks@gmail.com> wrote:
>> >> >>> > *See inline...*
>> >> >>>
>> >> >>> 2014-12-27 11:42 GMT+01:00 Mark Struberg
> <st...@yahoo.de>:
>> >> >>>
>> >> >>>> Hi!
>> >> >>>>
>> >> >>>> 1.1)
>> >> >>>>
>> >> >>>> I think we agree that having a
> PropertySource/ConfigSource SPI
>> with MANY
>> >> >>>> implementations is the way to go?
>> >> >>>> Any objections?
>> >> >>>>
>> >> >>> *+1 The way to go.*
>> >> >>>
>> >> >>>
>> >> >>> 1.2)
>> >> >>>>
>> >> >>>> Where should it belong to? Is it an API or
> rather an SPI?
>> >> >>>> I think it's more the later. A end user just
> likes to get the
>> >> >>> 'final'
>> >> >>>> configured values and does NOT deal with the
> PropertySources
>> himself. It is
>> >> >>>> really just for extending the system -> SPI.
>> >> >>>>
>> >> >>> *+1 for PropertySource being an SPI. Configuration
> must be the
>> API.*
>> >> >>>
>> >> >>>
>> >> >>> 1.3)
>> >> >>>> Merging.
>> >> >>>> Option (1.3.a) Do we like to do
> 'implicit' merging (aka the
>> >> >>> ordinal
>> >> >>>> stuff).
>> >> >>>>
>> >> >>> *It's not a question of taste. The mechanism is
> clumsy and implies
>> >> >>> constraints that are already known as of now not
> matching all use
>> cases. On
>> >> >>> top of it the priority leaks into the PropertySoiurce
> API (as an
>> additional
>> >> >>> method, which is a very ugly mix of concerns),
> Finally functions is
>> the
>> >> >>> modern way of modelling such an operation.*
>> >> >>>
>> >> >>>
>> >> >>>> Option (1.3.b) Or do we like 'explicit'
> (the merge function). What
>> >> >>> benefit
>> >> >>>> does this add in practice?
>> >> >>>>
>> >> >>>
>> >> >>> *See above and as outlined multiple times. Adding
> additional
>> functionality
>> >> >>> for audit (e.g. logging of the configuration
> overriding), different
>> or
>> >> >>> partial overridings (common in complex environments).
> Please stop
>> >> >>> discussion on this priority thing, it's simply
> not enough! By the
>> way the
>> >> >>> priority thing can still be implemented, when the
> rest of the
>> design is
>> >> >>> done in a modular way. My proposed solution gave you
> the
>> abtrsaction of a
>> >> >>> ConfigProvider BTW, where you could do this easily,
> but also the
>> other
>> >> >>> stuff. What you do depends on the use case, and to
> some extent your
>> >> >>> personal taste. A solution should NEVER constraint
> users in doing
>> the stuff
>> >> >>> they want!*
>> >> >>>
>> >> >>> Ad 1.3.a 'explicit' merging: This is
> basically the DeltaSpike mode:
>> EACH
>> >> >>>> ConfigSource (PropertySource) has an ordinal
> which it can set
>> itself. The
>> >> >>>> higher the configuration ordinal of the
> ConfigSource, the more
>> important it
>> >> >>>> is and it will override values from
> ConfigSources with lower
>> ordinal.
>> >> >>>>
>> >> >>>> That way it is possible to have a kind of
> 'default configuration'
>> >> >>> e.g. in
>> >> >>>> a property file inside your project and later
> overwrite it via
>> -Dxxx=yyy,
>> >> >>>> JNDI, or some container provided
> MyCountainerAdminConfigSource
>> etc later.
>> >> >>>>
>> >> >>> *No Mark. The fact of having a default configuration
> does not
>> interconnect
>> >> >>> how this is evaluated and composed. You are wrong!
> And on top,
>> when I look
>> >> >>> at your ideas: you will never get one solution, which
> a special
>> type of
>> >> >>> overridings that matches all users. You have to
> provide building
>> blocks
>> >> >>> (one more) that helps the users (companies) to model
> their
>> functionality
>> >> >>> with it. You are not on green field here!*
>> >> >>>
>> >> >>> Ad 1.3.b 'implicit' merging: Well, actually I
> don't got this. There
>> >> >>> was
>> >> >>>> merge(String key, PropertySource s1, s2), but
> that would mean
>> that every
>> >> >>>> user needs to deal with that himself? Could you
> please elaborate
>> on that
>> >> >>>> option? I didn't get it..
>> >> >>>
>> >> >>> *Of course not! (despite the fact that is trivial
> for the ones
>> used the
>> >> >>> functional style of Java 8). You can still provide a
> singleton with
>> >> >>> constants, where you*
>> >> >>> *provide the most common combinations, see
> AggregationPolicy in my
>> the
>> >> >>> current tree.*
>> >> >>>
>> >> >>> *-Anatole*
>> >> >>>
>> >> >>>
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>> LieGrue,
>> >> >>>> strub
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> *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*
>> >> >>
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >--
>> >> >
>> >> >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/
>> >> >Google: atsticks
>> >> >Mobile +41-76 344 62 79
>> >> >
>> >> >
>> >
>> >
>> >
>>
>
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Romain Manni-Bucau <rm...@gmail.com>.
That is exactly the difference between real life and theory. You cant ask
to change 100 apps in 1 day...you have to live with
Le 28 déc. 2014 10:33, "Mark Struberg" <st...@yahoo.de> a écrit :
> I don't get your samples Romain.
>
> In v1 you have configured keys A,B,C
> In v2 you have D. So what?
>
> Just remove A,B,C and use D instead. That's exactly the same like changing
> a table structure.
>
> Doing some 'translation' just because the ops guys don't want to change
> configuration is a total dead end and will end up being a maintenance
> nightmare in v3++. Your filter mechanism is just an utter ugly hack and if
> I would be the manager of this project then I'd call you names ;)
>
> That's like arguing that maven is not usable because it makes scripting
> hard. This is a FEATURE and not a bug!. People should not script builds! If
> they like to do complicated stuff then it's very easy to write plugins. In
> our case it's very easy to write ConfigSources.
>
>
> Remember the old saying "dirty remains, while quick is long forgotten"
>
>
> > Some config can conflict
>
> No. That's the same like with JNDI, JMX etc. Just tell them to use their
> own namespaces and you are done.
> That's like saying Java is not good because if I have multiple JARs which
> contain the same ClassName then it doesn't work. JUST USE NAMESPACES. You
> don't need any explicit merging.
>
>
>
> Oki, that was 2 arguments and both of them are actually non-problems.
>
> Cmon folks, give me more use cases and examples. I'm ready to solve them ;)
>
>
> LieGrue,
> strub
>
> On Sunday, 28 December 2014, 9:54, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
> >Well more I read more I think there is a real need but we are all wrong
> so instead of fighting please help us finding a solution.
> >@Mark: priorities or ordinal are great while you completely own the app
> and its config + it is a single technical version. I guess you know it is
> not always (rarely?) The case in medium and big projects.
> >A sample can be: v1 you configure an url with host, port propertkes and
> in v2 it is directly the url cause you added a path. Can be the same for
> datasource and business config etc...
> >What I did in practise was to use a filter mecanism but it was an ugly
> hack.
> >For such cases you can maybe use PropertySource translators or things
> like that to ensure the config is in the right format and then merge with
> ordinal.
> >Now let take the case where you package together several sub apps coming
> with their config. How do you do? Some config can conflict and the
> selection is not ordinal based - let me guess it will be the same. Best is
> to have both property sources and merge them into a single one. Kind of
> Properties merge(Properties current, PropertySource next).
> >I am not happy with these solutions but the needs are here and not
> something thought but really met - even if I dont have your experiences.
> >Point is we cant assume config will be perfect so let our future users
> make errors and be able to fix it easily.
> >Le 27 déc. 2014 14:50, "Mark Struberg" <st...@yahoo.de> a écrit :
> >>
> >> No Anatole, I DO get it, but I really think it is a bad idea. Because
> it adds way too much complexity or a very limited benefit.
> >>
> >>
> >> Think about it in an analogy to the ExpressionLanguage ELResolver
> chain. Of course this is a sorted lookup chain. And this list is fixed!
> >>
> >> And at runtime you cannot change the order and the user also does not
> care!
> >> All he cares is that #{user.name} does the right thing. He does not
> have to express an 'evaluator' and the chain ordering for each and every EL
> invocation. It just does not make any sense from a users perspective.
> >>
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >> On Saturday, 27 December 2014, 14:17, Anatole Tresch <
> atsticks@gmail.com> wrote:
> >>
> >>
> >> >
> >> >
> >> >Hi Mark
> >> >
> >> >
> >> >2014-12-27 12:56 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> >> >
> >> >> The mechanism is clumsy and implies
> >> >>> constraints that are already known as of now not matching all use
> cases.
> >> >>
> >> >>Tell me some limitations. Never had one. So just enlist them here and
> now.
> >> >>
> >> >And I am working since decades as well in the industry. I will not
> argue about use cases. I gave you same examples. You have the stand my
> opinion, unless you feel your opinion counts more than mine.
> >> >
> >> >> On top of it the priority leaks into the PropertySource API
> >> >>
> >> >>
> >> >>Because it IS part of the PropertySource!
> >> >>
> >> >
> >> >But it shoud not. I want to have my property sources and I want to
> combine them they way I want it. I want the concern of assembly being
> separated from the source itself.
> >> >It is like you write a Java program like this:
> >> >
> >> >
> >> >2: {
> >> >4: }
> >> >
> >> >3: System.out.println();
> >> >1: for(int i=0;i<10;i11)
> >> >
> >> >
> >> >
> >> >Shows pretty much the nonsense of your argumentation. For priorizing
> the loading of components in CDI priorities are great and sufficient, here
> they are not.
> >> >
> >> >
> >> >> Finally functions is the
> >> >>
> >> >>> modern way of modelling such an operation.
> >> >>
> >> >>If you have a hammer...
> >> >>I'm not interested in style if it doesn't add any real benefit.
> >> >>
> >> >>
> >> >If the hammer is more elegant and powerful but still easy than you
> outstyled solution, let it be a hammer!
> >> >
> >> >>> different or
> >> >>
> >> >>> partial overridings (common in complex environments)
> >> >>
> >> >>Never came across this need and I did very complex projects. It's
> always a trade off between an easy straight forward algorigthm which are
> easy to understand but sometimes you have to bend em a bit or program your
> own (PropertySource). The other option is to have hugely complex base
> mechanism which noone can use in practice because it is 'too flexible' -
> means not clear and straight enough.
> >> >>
> >> >>
> >> >>> you will never get one solution, which a special type of
> >> >>
> >> >>> overridings that matches all users.
> >> >>Oh sure we do. By having the ConfigSource define their ordinal
> themselves and it being really easy for a programmer to add own
> ConfigSources we have all of that!
> >> >>
> >> >>
> >> >>
> >> >>> A solution should NEVER constraint users in doing the stuff
> >> >>> they want!*
> >> >>
> >> >>Having the sorting via Ordinal doesn't impose any restriction on the
> user. Because he can easily overwrite those values.
> >> >>We are talking about a simple straight forward config mechanism and
> not about alien rocket science and time travelling.
> >> >>
> >> >>
> >> >>>You are not on green field here!
> >> >>
> >> >>
> >> >>Oh boy, we are! We just need to fulfil user needs, that's all.
> >> >I am not a boy. I am an adult with 44 years on track.... !
> >> >And BTW you seem to have lost every kind of reality contact. Do you
> really think companies will change their internal systems completely
> because just a few guys think they know
> >> >how the world is rouling...? NO!
> >> >
> >> >>
> >> >>> *Of course not! (despite the fact that is trivial for the ones
> used the
> >> >>> functional style of Java 8).
> >> >>Of course I know Map#merge, but what do you use it for? To me it
> seems like an overkill.
> >> >Seems that your mindis still stick on Java 7.,,,
> >> >
> >> >> You can still provide a singleton with
> >> >>> constants, where you*
> >> >>> *provide the most common combinations, see AggregationPolicy in my
> the
> >> >>> current tree.*
> >> >>
> >> >>Again: I don't see the benefit. If I'm in an EAR and like to get my
> "documentarchive.endpoint.url" then WHY would I like to manually change the
> aggregation? Makes no sense to me. And this increases the complexity quite
> impressively.
> >> >>
> >> >
> >> >
> >> >Perhaps one day you realize that we are talking about a general
> configuration soultion. EE is a sepcial case, not the other way round. It
> is NOT like Deltaspike, which benefits the mechanism provided by CDI. It is
> not and if it will, it gets Deltaspike 2, which is useless. There is
> already one, which for its purposes on this level, I agree, works well. But
> for a general solution it lacks so much on functionality-
> >> >
> >> >
> >> >I personally really think you still do not get the difference! It
> drives me crazy.
> >> >
> >> >LieGrue,
> >> >>strub
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>> On Saturday, 27 December 2014, 12:28, Anatole Tresch <
> atsticks@gmail.com> wrote:
> >> >>> > *See inline...*
> >> >>>
> >> >>> 2014-12-27 11:42 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> >> >>>
> >> >>>> Hi!
> >> >>>>
> >> >>>> 1.1)
> >> >>>>
> >> >>>> I think we agree that having a PropertySource/ConfigSource SPI
> with MANY
> >> >>>> implementations is the way to go?
> >> >>>> Any objections?
> >> >>>>
> >> >>> *+1 The way to go.*
> >> >>>
> >> >>>
> >> >>> 1.2)
> >> >>>>
> >> >>>> Where should it belong to? Is it an API or rather an SPI?
> >> >>>> I think it's more the later. A end user just likes to get the
> >> >>> 'final'
> >> >>>> configured values and does NOT deal with the PropertySources
> himself. It is
> >> >>>> really just for extending the system -> SPI.
> >> >>>>
> >> >>> *+1 for PropertySource being an SPI. Configuration must be the
> API.*
> >> >>>
> >> >>>
> >> >>> 1.3)
> >> >>>> Merging.
> >> >>>> Option (1.3.a) Do we like to do 'implicit' merging (aka the
> >> >>> ordinal
> >> >>>> stuff).
> >> >>>>
> >> >>> *It's not a question of taste. The mechanism is clumsy and implies
> >> >>> constraints that are already known as of now not matching all use
> cases. On
> >> >>> top of it the priority leaks into the PropertySoiurce API (as an
> additional
> >> >>> method, which is a very ugly mix of concerns), Finally functions is
> the
> >> >>> modern way of modelling such an operation.*
> >> >>>
> >> >>>
> >> >>>> Option (1.3.b) Or do we like 'explicit' (the merge function). What
> >> >>> benefit
> >> >>>> does this add in practice?
> >> >>>>
> >> >>>
> >> >>> *See above and as outlined multiple times. Adding additional
> functionality
> >> >>> for audit (e.g. logging of the configuration overriding), different
> or
> >> >>> partial overridings (common in complex environments). Please stop
> >> >>> discussion on this priority thing, it's simply not enough! By the
> way the
> >> >>> priority thing can still be implemented, when the rest of the
> design is
> >> >>> done in a modular way. My proposed solution gave you the
> abtrsaction of a
> >> >>> ConfigProvider BTW, where you could do this easily, but also the
> other
> >> >>> stuff. What you do depends on the use case, and to some extent your
> >> >>> personal taste. A solution should NEVER constraint users in doing
> the stuff
> >> >>> they want!*
> >> >>>
> >> >>> Ad 1.3.a 'explicit' merging: This is basically the DeltaSpike mode:
> EACH
> >> >>>> ConfigSource (PropertySource) has an ordinal which it can set
> itself. The
> >> >>>> higher the configuration ordinal of the ConfigSource, the more
> important it
> >> >>>> is and it will override values from ConfigSources with lower
> ordinal.
> >> >>>>
> >> >>>> That way it is possible to have a kind of 'default configuration'
> >> >>> e.g. in
> >> >>>> a property file inside your project and later overwrite it via
> -Dxxx=yyy,
> >> >>>> JNDI, or some container provided MyCountainerAdminConfigSource
> etc later.
> >> >>>>
> >> >>> *No Mark. The fact of having a default configuration does not
> interconnect
> >> >>> how this is evaluated and composed. You are wrong! And on top,
> when I look
> >> >>> at your ideas: you will never get one solution, which a special
> type of
> >> >>> overridings that matches all users. You have to provide building
> blocks
> >> >>> (one more) that helps the users (companies) to model their
> functionality
> >> >>> with it. You are not on green field here!*
> >> >>>
> >> >>> Ad 1.3.b 'implicit' merging: Well, actually I don't got this. There
> >> >>> was
> >> >>>> merge(String key, PropertySource s1, s2), but that would mean
> that every
> >> >>>> user needs to deal with that himself? Could you please elaborate
> on that
> >> >>>> option? I didn't get it..
> >> >>>
> >> >>> *Of course not! (despite the fact that is trivial for the ones
> used the
> >> >>> functional style of Java 8). You can still provide a singleton with
> >> >>> constants, where you*
> >> >>> *provide the most common combinations, see AggregationPolicy in my
> the
> >> >>> current tree.*
> >> >>>
> >> >>> *-Anatole*
> >> >>>
> >> >>>
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>> LieGrue,
> >> >>>> strub
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> *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*
> >> >>
> >> >>>
> >> >>
> >> >
> >> >
> >> >
> >> >
> >> >--
> >> >
> >> >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/
> >> >Google: atsticks
> >> >Mobile +41-76 344 62 79
> >> >
> >> >
> >
> >
> >
>
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Mark Struberg <st...@yahoo.de>.
I don't get your samples Romain.
In v1 you have configured keys A,B,C
In v2 you have D. So what?
Just remove A,B,C and use D instead. That's exactly the same like changing a table structure.
Doing some 'translation' just because the ops guys don't want to change configuration is a total dead end and will end up being a maintenance nightmare in v3++. Your filter mechanism is just an utter ugly hack and if I would be the manager of this project then I'd call you names ;)
That's like arguing that maven is not usable because it makes scripting hard. This is a FEATURE and not a bug!. People should not script builds! If they like to do complicated stuff then it's very easy to write plugins. In our case it's very easy to write ConfigSources.
Remember the old saying "dirty remains, while quick is long forgotten"
> Some config can conflict
No. That's the same like with JNDI, JMX etc. Just tell them to use their own namespaces and you are done.
That's like saying Java is not good because if I have multiple JARs which contain the same ClassName then it doesn't work. JUST USE NAMESPACES. You don't need any explicit merging.
Oki, that was 2 arguments and both of them are actually non-problems.
Cmon folks, give me more use cases and examples. I'm ready to solve them ;)
LieGrue,
strub
On Sunday, 28 December 2014, 9:54, Romain Manni-Bucau <rm...@gmail.com> wrote:
>Well more I read more I think there is a real need but we are all wrong so instead of fighting please help us finding a solution.
>@Mark: priorities or ordinal are great while you completely own the app and its config + it is a single technical version. I guess you know it is not always (rarely?) The case in medium and big projects.
>A sample can be: v1 you configure an url with host, port propertkes and in v2 it is directly the url cause you added a path. Can be the same for datasource and business config etc...
>What I did in practise was to use a filter mecanism but it was an ugly hack.
>For such cases you can maybe use PropertySource translators or things like that to ensure the config is in the right format and then merge with ordinal.
>Now let take the case where you package together several sub apps coming with their config. How do you do? Some config can conflict and the selection is not ordinal based - let me guess it will be the same. Best is to have both property sources and merge them into a single one. Kind of Properties merge(Properties current, PropertySource next).
>I am not happy with these solutions but the needs are here and not something thought but really met - even if I dont have your experiences.
>Point is we cant assume config will be perfect so let our future users make errors and be able to fix it easily.
>Le 27 déc. 2014 14:50, "Mark Struberg" <st...@yahoo.de> a écrit :
>>
>> No Anatole, I DO get it, but I really think it is a bad idea. Because it adds way too much complexity or a very limited benefit.
>>
>>
>> Think about it in an analogy to the ExpressionLanguage ELResolver chain. Of course this is a sorted lookup chain. And this list is fixed!
>>
>> And at runtime you cannot change the order and the user also does not care!
>> All he cares is that #{user.name} does the right thing. He does not have to express an 'evaluator' and the chain ordering for each and every EL invocation. It just does not make any sense from a users perspective.
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> On Saturday, 27 December 2014, 14:17, Anatole Tresch <at...@gmail.com> wrote:
>>
>>
>> >
>> >
>> >Hi Mark
>> >
>> >
>> >2014-12-27 12:56 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>> >
>> >> The mechanism is clumsy and implies
>> >>> constraints that are already known as of now not matching all use cases.
>> >>
>> >>Tell me some limitations. Never had one. So just enlist them here and now.
>> >>
>> >And I am working since decades as well in the industry. I will not argue about use cases. I gave you same examples. You have the stand my opinion, unless you feel your opinion counts more than mine.
>> >
>> >> On top of it the priority leaks into the PropertySource API
>> >>
>> >>
>> >>Because it IS part of the PropertySource!
>> >>
>> >
>> >But it shoud not. I want to have my property sources and I want to combine them they way I want it. I want the concern of assembly being separated from the source itself.
>> >It is like you write a Java program like this:
>> >
>> >
>> >2: {
>> >4: }
>> >
>> >3: System.out.println();
>> >1: for(int i=0;i<10;i11)
>> >
>> >
>> >
>> >Shows pretty much the nonsense of your argumentation. For priorizing the loading of components in CDI priorities are great and sufficient, here they are not.
>> >
>> >
>> >> Finally functions is the
>> >>
>> >>> modern way of modelling such an operation.
>> >>
>> >>If you have a hammer...
>> >>I'm not interested in style if it doesn't add any real benefit.
>> >>
>> >>
>> >If the hammer is more elegant and powerful but still easy than you outstyled solution, let it be a hammer!
>> >
>> >>> different or
>> >>
>> >>> partial overridings (common in complex environments)
>> >>
>> >>Never came across this need and I did very complex projects. It's always a trade off between an easy straight forward algorigthm which are easy to understand but sometimes you have to bend em a bit or program your own (PropertySource). The other option is to have hugely complex base mechanism which noone can use in practice because it is 'too flexible' - means not clear and straight enough.
>> >>
>> >>
>> >>> you will never get one solution, which a special type of
>> >>
>> >>> overridings that matches all users.
>> >>Oh sure we do. By having the ConfigSource define their ordinal themselves and it being really easy for a programmer to add own ConfigSources we have all of that!
>> >>
>> >>
>> >>
>> >>> A solution should NEVER constraint users in doing the stuff
>> >>> they want!*
>> >>
>> >>Having the sorting via Ordinal doesn't impose any restriction on the user. Because he can easily overwrite those values.
>> >>We are talking about a simple straight forward config mechanism and not about alien rocket science and time travelling.
>> >>
>> >>
>> >>>You are not on green field here!
>> >>
>> >>
>> >>Oh boy, we are! We just need to fulfil user needs, that's all.
>> >I am not a boy. I am an adult with 44 years on track.... !
>> >And BTW you seem to have lost every kind of reality contact. Do you really think companies will change their internal systems completely because just a few guys think they know
>> >how the world is rouling...? NO!
>> >
>> >>
>> >>> *Of course not! (despite the fact that is trivial for the ones used the
>> >>> functional style of Java 8).
>> >>Of course I know Map#merge, but what do you use it for? To me it seems like an overkill.
>> >Seems that your mindis still stick on Java 7.,,,
>> >
>> >> You can still provide a singleton with
>> >>> constants, where you*
>> >>> *provide the most common combinations, see AggregationPolicy in my the
>> >>> current tree.*
>> >>
>> >>Again: I don't see the benefit. If I'm in an EAR and like to get my "documentarchive.endpoint.url" then WHY would I like to manually change the aggregation? Makes no sense to me. And this increases the complexity quite impressively.
>> >>
>> >
>> >
>> >Perhaps one day you realize that we are talking about a general configuration soultion. EE is a sepcial case, not the other way round. It is NOT like Deltaspike, which benefits the mechanism provided by CDI. It is not and if it will, it gets Deltaspike 2, which is useless. There is already one, which for its purposes on this level, I agree, works well. But for a general solution it lacks so much on functionality-
>> >
>> >
>> >I personally really think you still do not get the difference! It drives me crazy.
>> >
>> >LieGrue,
>> >>strub
>> >>
>> >>
>> >>
>> >>
>> >>> On Saturday, 27 December 2014, 12:28, Anatole Tresch <at...@gmail.com> wrote:
>> >>> > *See inline...*
>> >>>
>> >>> 2014-12-27 11:42 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>> >>>
>> >>>> Hi!
>> >>>>
>> >>>> 1.1)
>> >>>>
>> >>>> I think we agree that having a PropertySource/ConfigSource SPI with MANY
>> >>>> implementations is the way to go?
>> >>>> Any objections?
>> >>>>
>> >>> *+1 The way to go.*
>> >>>
>> >>>
>> >>> 1.2)
>> >>>>
>> >>>> Where should it belong to? Is it an API or rather an SPI?
>> >>>> I think it's more the later. A end user just likes to get the
>> >>> 'final'
>> >>>> configured values and does NOT deal with the PropertySources himself. It is
>> >>>> really just for extending the system -> SPI.
>> >>>>
>> >>> *+1 for PropertySource being an SPI. Configuration must be the API.*
>> >>>
>> >>>
>> >>> 1.3)
>> >>>> Merging.
>> >>>> Option (1.3.a) Do we like to do 'implicit' merging (aka the
>> >>> ordinal
>> >>>> stuff).
>> >>>>
>> >>> *It's not a question of taste. The mechanism is clumsy and implies
>> >>> constraints that are already known as of now not matching all use cases. On
>> >>> top of it the priority leaks into the PropertySoiurce API (as an additional
>> >>> method, which is a very ugly mix of concerns), Finally functions is the
>> >>> modern way of modelling such an operation.*
>> >>>
>> >>>
>> >>>> Option (1.3.b) Or do we like 'explicit' (the merge function). What
>> >>> benefit
>> >>>> does this add in practice?
>> >>>>
>> >>>
>> >>> *See above and as outlined multiple times. Adding additional functionality
>> >>> for audit (e.g. logging of the configuration overriding), different or
>> >>> partial overridings (common in complex environments). Please stop
>> >>> discussion on this priority thing, it's simply not enough! By the way the
>> >>> priority thing can still be implemented, when the rest of the design is
>> >>> done in a modular way. My proposed solution gave you the abtrsaction of a
>> >>> ConfigProvider BTW, where you could do this easily, but also the other
>> >>> stuff. What you do depends on the use case, and to some extent your
>> >>> personal taste. A solution should NEVER constraint users in doing the stuff
>> >>> they want!*
>> >>>
>> >>> Ad 1.3.a 'explicit' merging: This is basically the DeltaSpike mode: EACH
>> >>>> ConfigSource (PropertySource) has an ordinal which it can set itself. The
>> >>>> higher the configuration ordinal of the ConfigSource, the more important it
>> >>>> is and it will override values from ConfigSources with lower ordinal.
>> >>>>
>> >>>> That way it is possible to have a kind of 'default configuration'
>> >>> e.g. in
>> >>>> a property file inside your project and later overwrite it via -Dxxx=yyy,
>> >>>> JNDI, or some container provided MyCountainerAdminConfigSource etc later.
>> >>>>
>> >>> *No Mark. The fact of having a default configuration does not interconnect
>> >>> how this is evaluated and composed. You are wrong! And on top, when I look
>> >>> at your ideas: you will never get one solution, which a special type of
>> >>> overridings that matches all users. You have to provide building blocks
>> >>> (one more) that helps the users (companies) to model their functionality
>> >>> with it. You are not on green field here!*
>> >>>
>> >>> Ad 1.3.b 'implicit' merging: Well, actually I don't got this. There
>> >>> was
>> >>>> merge(String key, PropertySource s1, s2), but that would mean that every
>> >>>> user needs to deal with that himself? Could you please elaborate on that
>> >>>> option? I didn't get it..
>> >>>
>> >>> *Of course not! (despite the fact that is trivial for the ones used the
>> >>> functional style of Java 8). You can still provide a singleton with
>> >>> constants, where you*
>> >>> *provide the most common combinations, see AggregationPolicy in my the
>> >>> current tree.*
>> >>>
>> >>> *-Anatole*
>> >>>
>> >>>
>> >>>>
>> >>>>
>> >>>
>> >>>> LieGrue,
>> >>>> strub
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> *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*
>> >>
>> >>>
>> >>
>> >
>> >
>> >
>> >
>> >--
>> >
>> >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/
>> >Google: atsticks
>> >Mobile +41-76 344 62 79
>> >
>> >
>
>
>
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ok
Maybe read too much mails in batch ;)
Le 28 déc. 2014 09:57, "Anatole Tresch" <at...@gmail.com> a écrit :
> Hi Romain
> I think we are not fighting anymore. Currently I see an open discussion on
> the heart of the overall config modularity topic.
>
> Cheers
> Anatole
>
> Ps: will join later again, now first a ice hockey match with my boys... ;)
> Romain Manni-Bucau <rm...@gmail.com> schrieb am So., 28. Dez. 2014
> um 09:54:
>
>> Well more I read more I think there is a real need but we are all wrong
>> so instead of fighting please help us finding a solution.
>>
>> @Mark: priorities or ordinal are great while you completely own the app
>> and its config + it is a single technical version. I guess you know it is
>> not always (rarely?) The case in medium and big projects.
>>
>> A sample can be: v1 you configure an url with host, port propertkes and
>> in v2 it is directly the url cause you added a path. Can be the same for
>> datasource and business config etc...
>>
>> What I did in practise was to use a filter mecanism but it was an ugly
>> hack.
>>
>> For such cases you can maybe use PropertySource translators or things
>> like that to ensure the config is in the right format and then merge with
>> ordinal.
>>
>> Now let take the case where you package together several sub apps coming
>> with their config. How do you do? Some config can conflict and the
>> selection is not ordinal based - let me guess it will be the same. Best is
>> to have both property sources and merge them into a single one. Kind of
>> Properties merge(Properties current, PropertySource next).
>>
>> I am not happy with these solutions but the needs are here and not
>> something thought but really met - even if I dont have your experiences.
>>
>> Point is we cant assume config will be perfect so let our future users
>> make errors and be able to fix it easily.
>>
>> Le 27 déc. 2014 14:50, "Mark Struberg" <st...@yahoo.de> a écrit :
>>
>>
>> >
>> > No Anatole, I DO get it, but I really think it is a bad idea. Because
>> it adds way too much complexity or a very limited benefit.
>> >
>> >
>> > Think about it in an analogy to the ExpressionLanguage ELResolver
>> chain. Of course this is a sorted lookup chain. And this list is fixed!
>> >
>> > And at runtime you cannot change the order and the user also does not
>> care!
>> > All he cares is that #{user.name} does the right thing. He does not
>> have to express an 'evaluator' and the chain ordering for each and every EL
>> invocation. It just does not make any sense from a users perspective.
>> >
>> >
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >
>> >
>> > On Saturday, 27 December 2014, 14:17, Anatole Tresch <
>> atsticks@gmail.com> wrote:
>> >
>> >
>> > >
>> > >
>> > >Hi Mark
>> > >
>> > >
>> > >2014-12-27 12:56 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>> > >
>> > >> The mechanism is clumsy and implies
>> > >>> constraints that are already known as of now not matching all use
>> cases.
>> > >>
>> > >>Tell me some limitations. Never had one. So just enlist them here and
>> now.
>> > >>
>> > >And I am working since decades as well in the industry. I will not
>> argue about use cases. I gave you same examples. You have the stand my
>> opinion, unless you feel your opinion counts more than mine.
>> > >
>> > >> On top of it the priority leaks into the PropertySource API
>> > >>
>> > >>
>> > >>Because it IS part of the PropertySource!
>> > >>
>> > >
>> > >But it shoud not. I want to have my property sources and I want to
>> combine them they way I want it. I want the concern of assembly being
>> separated from the source itself.
>> > >It is like you write a Java program like this:
>> > >
>> > >
>> > >2: {
>> > >4: }
>> > >
>> > >3: System.out.println();
>> > >1: for(int i=0;i<10;i11)
>> > >
>> > >
>> > >
>> > >Shows pretty much the nonsense of your argumentation. For priorizing
>> the loading of components in CDI priorities are great and sufficient, here
>> they are not.
>> > >
>> > >
>> > >> Finally functions is the
>> > >>
>> > >>> modern way of modelling such an operation.
>> > >>
>> > >>If you have a hammer...
>> > >>I'm not interested in style if it doesn't add any real benefit.
>> > >>
>> > >>
>> > >If the hammer is more elegant and powerful but still easy than you
>> outstyled solution, let it be a hammer!
>> > >
>> > >>> different or
>> > >>
>> > >>> partial overridings (common in complex environments)
>> > >>
>> > >>Never came across this need and I did very complex projects. It's
>> always a trade off between an easy straight forward algorigthm which are
>> easy to understand but sometimes you have to bend em a bit or program your
>> own (PropertySource). The other option is to have hugely complex base
>> mechanism which noone can use in practice because it is 'too flexible' -
>> means not clear and straight enough.
>> > >>
>> > >>
>> > >>> you will never get one solution, which a special type of
>> > >>
>> > >>> overridings that matches all users.
>> > >>Oh sure we do. By having the ConfigSource define their ordinal
>> themselves and it being really easy for a programmer to add own
>> ConfigSources we have all of that!
>> > >>
>> > >>
>> > >>
>> > >>> A solution should NEVER constraint users in doing the stuff
>> > >>> they want!*
>> > >>
>> > >>Having the sorting via Ordinal doesn't impose any restriction on the
>> user. Because he can easily overwrite those values.
>> > >>We are talking about a simple straight forward config mechanism and
>> not about alien rocket science and time travelling.
>> > >>
>> > >>
>> > >>>You are not on green field here!
>> > >>
>> > >>
>> > >>Oh boy, we are! We just need to fulfil user needs, that's all.
>> > >I am not a boy. I am an adult with 44 years on track.... !
>> > >And BTW you seem to have lost every kind of reality contact. Do you
>> really think companies will change their internal systems completely
>> because just a few guys think they know
>> > >how the world is rouling...? NO!
>> > >
>> > >>
>> > >>> *Of course not! (despite the fact that is trivial for the ones
>> used the
>> > >>> functional style of Java 8).
>> > >>Of course I know Map#merge, but what do you use it for? To me it
>> seems like an overkill.
>> > >Seems that your mindis still stick on Java 7.,,,
>> > >
>> > >> You can still provide a singleton with
>> > >>> constants, where you*
>> > >>> *provide the most common combinations, see AggregationPolicy in my
>> the
>> > >>> current tree.*
>> > >>
>> > >>Again: I don't see the benefit. If I'm in an EAR and like to get my
>> "documentarchive.endpoint.url" then WHY would I like to manually change the
>> aggregation? Makes no sense to me. And this increases the complexity quite
>> impressively.
>> > >>
>> > >
>> > >
>> > >Perhaps one day you realize that we are talking about a general
>> configuration soultion. EE is a sepcial case, not the other way round. It
>> is NOT like Deltaspike, which benefits the mechanism provided by CDI. It is
>> not and if it will, it gets Deltaspike 2, which is useless. There is
>> already one, which for its purposes on this level, I agree, works well. But
>> for a general solution it lacks so much on functionality-
>> > >
>> > >
>> > >I personally really think you still do not get the difference! It
>> drives me crazy.
>> > >
>> > >LieGrue,
>> > >>strub
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>> On Saturday, 27 December 2014, 12:28, Anatole Tresch <
>> atsticks@gmail.com> wrote:
>> > >>> > *See inline...*
>> > >>>
>> > >>> 2014-12-27 11:42 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>> > >>>
>> > >>>> Hi!
>> > >>>>
>> > >>>> 1.1)
>> > >>>>
>> > >>>> I think we agree that having a PropertySource/ConfigSource SPI
>> with MANY
>> > >>>> implementations is the way to go?
>> > >>>> Any objections?
>> > >>>>
>> > >>> *+1 The way to go.*
>> > >>>
>> > >>>
>> > >>> 1.2)
>> > >>>>
>> > >>>> Where should it belong to? Is it an API or rather an SPI?
>> > >>>> I think it's more the later. A end user just likes to get the
>> > >>> 'final'
>> > >>>> configured values and does NOT deal with the PropertySources
>> himself. It is
>> > >>>> really just for extending the system -> SPI.
>> > >>>>
>> > >>> *+1 for PropertySource being an SPI. Configuration must be the
>> API.*
>> > >>>
>> > >>>
>> > >>> 1.3)
>> > >>>> Merging.
>> > >>>> Option (1.3.a) Do we like to do 'implicit' merging (aka the
>> > >>> ordinal
>> > >>>> stuff).
>> > >>>>
>> > >>> *It's not a question of taste. The mechanism is clumsy and implies
>> > >>> constraints that are already known as of now not matching all use
>> cases. On
>> > >>> top of it the priority leaks into the PropertySoiurce API (as an
>> additional
>> > >>> method, which is a very ugly mix of concerns), Finally functions is
>> the
>> > >>> modern way of modelling such an operation.*
>> > >>>
>> > >>>
>> > >>>> Option (1.3.b) Or do we like 'explicit' (the merge function). What
>> > >>> benefit
>> > >>>> does this add in practice?
>> > >>>>
>> > >>>
>> > >>> *See above and as outlined multiple times. Adding additional
>> functionality
>> > >>> for audit (e.g. logging of the configuration overriding), different
>> or
>> > >>> partial overridings (common in complex environments). Please stop
>> > >>> discussion on this priority thing, it's simply not enough! By the
>> way the
>> > >>> priority thing can still be implemented, when the rest of the
>> design is
>> > >>> done in a modular way. My proposed solution gave you the
>> abtrsaction of a
>> > >>> ConfigProvider BTW, where you could do this easily, but also the
>> other
>> > >>> stuff. What you do depends on the use case, and to some extent your
>> > >>> personal taste. A solution should NEVER constraint users in doing
>> the stuff
>> > >>> they want!*
>> > >>>
>> > >>> Ad 1.3.a 'explicit' merging: This is basically the DeltaSpike mode:
>> EACH
>> > >>>> ConfigSource (PropertySource) has an ordinal which it can set
>> itself. The
>> > >>>> higher the configuration ordinal of the ConfigSource, the more
>> important it
>> > >>>> is and it will override values from ConfigSources with lower
>> ordinal.
>> > >>>>
>> > >>>> That way it is possible to have a kind of 'default configuration'
>> > >>> e.g. in
>> > >>>> a property file inside your project and later overwrite it via
>> -Dxxx=yyy,
>> > >>>> JNDI, or some container provided MyCountainerAdminConfigSource
>> etc later.
>> > >>>>
>> > >>> *No Mark. The fact of having a default configuration does not
>> interconnect
>> > >>> how this is evaluated and composed. You are wrong! And on top,
>> when I look
>> > >>> at your ideas: you will never get one solution, which a special
>> type of
>> > >>> overridings that matches all users. You have to provide building
>> blocks
>> > >>> (one more) that helps the users (companies) to model their
>> functionality
>> > >>> with it. You are not on green field here!*
>> > >>>
>> > >>> Ad 1.3.b 'implicit' merging: Well, actually I don't got this. There
>> > >>> was
>> > >>>> merge(String key, PropertySource s1, s2), but that would mean
>> that every
>> > >>>> user needs to deal with that himself? Could you please elaborate
>> on that
>> > >>>> option? I didn't get it..
>> > >>>
>> > >>> *Of course not! (despite the fact that is trivial for the ones
>> used the
>> > >>> functional style of Java 8). You can still provide a singleton with
>> > >>> constants, where you*
>> > >>> *provide the most common combinations, see AggregationPolicy in my
>> the
>> > >>> current tree.*
>> > >>>
>> > >>> *-Anatole*
>> > >>>
>> > >>>
>> > >>>>
>> > >>>>
>> > >>>
>> > >>>> LieGrue,
>> > >>>> strub
>> > >>>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> --
>> > >>> *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*
>> > >>
>> > >>>
>> > >>
>> > >
>> > >
>> > >
>> > >
>> > >--
>> > >
>> > >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/
>> > >Google: atsticks
>> > >Mobile +41-76 344 62 79
>> > >
>> > >
>>
>
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Anatole Tresch <at...@gmail.com>.
Hi Romain
I think we are not fighting anymore. Currently I see an open discussion on
the heart of the overall config modularity topic.
Cheers
Anatole
Ps: will join later again, now first a ice hockey match with my boys... ;)
Romain Manni-Bucau <rm...@gmail.com> schrieb am So., 28. Dez. 2014 um
09:54:
> Well more I read more I think there is a real need but we are all wrong so
> instead of fighting please help us finding a solution.
>
> @Mark: priorities or ordinal are great while you completely own the app
> and its config + it is a single technical version. I guess you know it is
> not always (rarely?) The case in medium and big projects.
>
> A sample can be: v1 you configure an url with host, port propertkes and in
> v2 it is directly the url cause you added a path. Can be the same for
> datasource and business config etc...
>
> What I did in practise was to use a filter mecanism but it was an ugly
> hack.
>
> For such cases you can maybe use PropertySource translators or things like
> that to ensure the config is in the right format and then merge with
> ordinal.
>
> Now let take the case where you package together several sub apps coming
> with their config. How do you do? Some config can conflict and the
> selection is not ordinal based - let me guess it will be the same. Best is
> to have both property sources and merge them into a single one. Kind of
> Properties merge(Properties current, PropertySource next).
>
> I am not happy with these solutions but the needs are here and not
> something thought but really met - even if I dont have your experiences.
>
> Point is we cant assume config will be perfect so let our future users
> make errors and be able to fix it easily.
>
> Le 27 déc. 2014 14:50, "Mark Struberg" <st...@yahoo.de> a écrit :
>
>
> >
> > No Anatole, I DO get it, but I really think it is a bad idea. Because it
> adds way too much complexity or a very limited benefit.
> >
> >
> > Think about it in an analogy to the ExpressionLanguage ELResolver chain.
> Of course this is a sorted lookup chain. And this list is fixed!
> >
> > And at runtime you cannot change the order and the user also does not
> care!
> > All he cares is that #{user.name} does the right thing. He does not
> have to express an 'evaluator' and the chain ordering for each and every EL
> invocation. It just does not make any sense from a users perspective.
> >
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > On Saturday, 27 December 2014, 14:17, Anatole Tresch <at...@gmail.com>
> wrote:
> >
> >
> > >
> > >
> > >Hi Mark
> > >
> > >
> > >2014-12-27 12:56 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> > >
> > >> The mechanism is clumsy and implies
> > >>> constraints that are already known as of now not matching all use
> cases.
> > >>
> > >>Tell me some limitations. Never had one. So just enlist them here and
> now.
> > >>
> > >And I am working since decades as well in the industry. I will not
> argue about use cases. I gave you same examples. You have the stand my
> opinion, unless you feel your opinion counts more than mine.
> > >
> > >> On top of it the priority leaks into the PropertySource API
> > >>
> > >>
> > >>Because it IS part of the PropertySource!
> > >>
> > >
> > >But it shoud not. I want to have my property sources and I want to
> combine them they way I want it. I want the concern of assembly being
> separated from the source itself.
> > >It is like you write a Java program like this:
> > >
> > >
> > >2: {
> > >4: }
> > >
> > >3: System.out.println();
> > >1: for(int i=0;i<10;i11)
> > >
> > >
> > >
> > >Shows pretty much the nonsense of your argumentation. For priorizing
> the loading of components in CDI priorities are great and sufficient, here
> they are not.
> > >
> > >
> > >> Finally functions is the
> > >>
> > >>> modern way of modelling such an operation.
> > >>
> > >>If you have a hammer...
> > >>I'm not interested in style if it doesn't add any real benefit.
> > >>
> > >>
> > >If the hammer is more elegant and powerful but still easy than you
> outstyled solution, let it be a hammer!
> > >
> > >>> different or
> > >>
> > >>> partial overridings (common in complex environments)
> > >>
> > >>Never came across this need and I did very complex projects. It's
> always a trade off between an easy straight forward algorigthm which are
> easy to understand but sometimes you have to bend em a bit or program your
> own (PropertySource). The other option is to have hugely complex base
> mechanism which noone can use in practice because it is 'too flexible' -
> means not clear and straight enough.
> > >>
> > >>
> > >>> you will never get one solution, which a special type of
> > >>
> > >>> overridings that matches all users.
> > >>Oh sure we do. By having the ConfigSource define their ordinal
> themselves and it being really easy for a programmer to add own
> ConfigSources we have all of that!
> > >>
> > >>
> > >>
> > >>> A solution should NEVER constraint users in doing the stuff
> > >>> they want!*
> > >>
> > >>Having the sorting via Ordinal doesn't impose any restriction on the
> user. Because he can easily overwrite those values.
> > >>We are talking about a simple straight forward config mechanism and
> not about alien rocket science and time travelling.
> > >>
> > >>
> > >>>You are not on green field here!
> > >>
> > >>
> > >>Oh boy, we are! We just need to fulfil user needs, that's all.
> > >I am not a boy. I am an adult with 44 years on track.... !
> > >And BTW you seem to have lost every kind of reality contact. Do you
> really think companies will change their internal systems completely
> because just a few guys think they know
> > >how the world is rouling...? NO!
> > >
> > >>
> > >>> *Of course not! (despite the fact that is trivial for the ones used
> the
> > >>> functional style of Java 8).
> > >>Of course I know Map#merge, but what do you use it for? To me it seems
> like an overkill.
> > >Seems that your mindis still stick on Java 7.,,,
> > >
> > >> You can still provide a singleton with
> > >>> constants, where you*
> > >>> *provide the most common combinations, see AggregationPolicy in my
> the
> > >>> current tree.*
> > >>
> > >>Again: I don't see the benefit. If I'm in an EAR and like to get my
> "documentarchive.endpoint.url" then WHY would I like to manually change the
> aggregation? Makes no sense to me. And this increases the complexity quite
> impressively.
> > >>
> > >
> > >
> > >Perhaps one day you realize that we are talking about a general
> configuration soultion. EE is a sepcial case, not the other way round. It
> is NOT like Deltaspike, which benefits the mechanism provided by CDI. It is
> not and if it will, it gets Deltaspike 2, which is useless. There is
> already one, which for its purposes on this level, I agree, works well. But
> for a general solution it lacks so much on functionality-
> > >
> > >
> > >I personally really think you still do not get the difference! It
> drives me crazy.
> > >
> > >LieGrue,
> > >>strub
> > >>
> > >>
> > >>
> > >>
> > >>> On Saturday, 27 December 2014, 12:28, Anatole Tresch <
> atsticks@gmail.com> wrote:
> > >>> > *See inline...*
> > >>>
> > >>> 2014-12-27 11:42 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> > >>>
> > >>>> Hi!
> > >>>>
> > >>>> 1.1)
> > >>>>
> > >>>> I think we agree that having a PropertySource/ConfigSource SPI
> with MANY
> > >>>> implementations is the way to go?
> > >>>> Any objections?
> > >>>>
> > >>> *+1 The way to go.*
> > >>>
> > >>>
> > >>> 1.2)
> > >>>>
> > >>>> Where should it belong to? Is it an API or rather an SPI?
> > >>>> I think it's more the later. A end user just likes to get the
> > >>> 'final'
> > >>>> configured values and does NOT deal with the PropertySources
> himself. It is
> > >>>> really just for extending the system -> SPI.
> > >>>>
> > >>> *+1 for PropertySource being an SPI. Configuration must be the
> API.*
> > >>>
> > >>>
> > >>> 1.3)
> > >>>> Merging.
> > >>>> Option (1.3.a) Do we like to do 'implicit' merging (aka the
> > >>> ordinal
> > >>>> stuff).
> > >>>>
> > >>> *It's not a question of taste. The mechanism is clumsy and implies
> > >>> constraints that are already known as of now not matching all use
> cases. On
> > >>> top of it the priority leaks into the PropertySoiurce API (as an
> additional
> > >>> method, which is a very ugly mix of concerns), Finally functions is
> the
> > >>> modern way of modelling such an operation.*
> > >>>
> > >>>
> > >>>> Option (1.3.b) Or do we like 'explicit' (the merge function). What
> > >>> benefit
> > >>>> does this add in practice?
> > >>>>
> > >>>
> > >>> *See above and as outlined multiple times. Adding additional
> functionality
> > >>> for audit (e.g. logging of the configuration overriding), different
> or
> > >>> partial overridings (common in complex environments). Please stop
> > >>> discussion on this priority thing, it's simply not enough! By the
> way the
> > >>> priority thing can still be implemented, when the rest of the design
> is
> > >>> done in a modular way. My proposed solution gave you the abtrsaction
> of a
> > >>> ConfigProvider BTW, where you could do this easily, but also the
> other
> > >>> stuff. What you do depends on the use case, and to some extent your
> > >>> personal taste. A solution should NEVER constraint users in doing
> the stuff
> > >>> they want!*
> > >>>
> > >>> Ad 1.3.a 'explicit' merging: This is basically the DeltaSpike mode:
> EACH
> > >>>> ConfigSource (PropertySource) has an ordinal which it can set
> itself. The
> > >>>> higher the configuration ordinal of the ConfigSource, the more
> important it
> > >>>> is and it will override values from ConfigSources with lower
> ordinal.
> > >>>>
> > >>>> That way it is possible to have a kind of 'default configuration'
> > >>> e.g. in
> > >>>> a property file inside your project and later overwrite it via
> -Dxxx=yyy,
> > >>>> JNDI, or some container provided MyCountainerAdminConfigSource etc
> later.
> > >>>>
> > >>> *No Mark. The fact of having a default configuration does not
> interconnect
> > >>> how this is evaluated and composed. You are wrong! And on top, when
> I look
> > >>> at your ideas: you will never get one solution, which a special type
> of
> > >>> overridings that matches all users. You have to provide building
> blocks
> > >>> (one more) that helps the users (companies) to model their
> functionality
> > >>> with it. You are not on green field here!*
> > >>>
> > >>> Ad 1.3.b 'implicit' merging: Well, actually I don't got this. There
> > >>> was
> > >>>> merge(String key, PropertySource s1, s2), but that would mean that
> every
> > >>>> user needs to deal with that himself? Could you please elaborate
> on that
> > >>>> option? I didn't get it..
> > >>>
> > >>> *Of course not! (despite the fact that is trivial for the ones used
> the
> > >>> functional style of Java 8). You can still provide a singleton with
> > >>> constants, where you*
> > >>> *provide the most common combinations, see AggregationPolicy in my
> the
> > >>> current tree.*
> > >>>
> > >>> *-Anatole*
> > >>>
> > >>>
> > >>>>
> > >>>>
> > >>>
> > >>>> LieGrue,
> > >>>> strub
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> *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*
> > >>
> > >>>
> > >>
> > >
> > >
> > >
> > >
> > >--
> > >
> > >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/
> > >Google: atsticks
> > >Mobile +41-76 344 62 79
> > >
> > >
>
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Well more I read more I think there is a real need but we are all wrong so
instead of fighting please help us finding a solution.
@Mark: priorities or ordinal are great while you completely own the app and
its config + it is a single technical version. I guess you know it is not
always (rarely?) The case in medium and big projects.
A sample can be: v1 you configure an url with host, port propertkes and in
v2 it is directly the url cause you added a path. Can be the same for
datasource and business config etc...
What I did in practise was to use a filter mecanism but it was an ugly hack.
For such cases you can maybe use PropertySource translators or things like
that to ensure the config is in the right format and then merge with
ordinal.
Now let take the case where you package together several sub apps coming
with their config. How do you do? Some config can conflict and the
selection is not ordinal based - let me guess it will be the same. Best is
to have both property sources and merge them into a single one. Kind of
Properties merge(Properties current, PropertySource next).
I am not happy with these solutions but the needs are here and not
something thought but really met - even if I dont have your experiences.
Point is we cant assume config will be perfect so let our future users make
errors and be able to fix it easily.
Le 27 déc. 2014 14:50, "Mark Struberg" <st...@yahoo.de> a écrit :
>
> No Anatole, I DO get it, but I really think it is a bad idea. Because it
adds way too much complexity or a very limited benefit.
>
>
> Think about it in an analogy to the ExpressionLanguage ELResolver chain.
Of course this is a sorted lookup chain. And this list is fixed!
>
> And at runtime you cannot change the order and the user also does not
care!
> All he cares is that #{user.name} does the right thing. He does not have
to express an 'evaluator' and the chain ordering for each and every EL
invocation. It just does not make any sense from a users perspective.
>
>
>
> LieGrue,
> strub
>
>
>
>
> On Saturday, 27 December 2014, 14:17, Anatole Tresch <at...@gmail.com>
wrote:
>
>
> >
> >
> >Hi Mark
> >
> >
> >2014-12-27 12:56 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> >
> >> The mechanism is clumsy and implies
> >>> constraints that are already known as of now not matching all use
cases.
> >>
> >>Tell me some limitations. Never had one. So just enlist them here and
now.
> >>
> >And I am working since decades as well in the industry. I will not
argue about use cases. I gave you same examples. You have the stand my
opinion, unless you feel your opinion counts more than mine.
> >
> >> On top of it the priority leaks into the PropertySource API
> >>
> >>
> >>Because it IS part of the PropertySource!
> >>
> >
> >But it shoud not. I want to have my property sources and I want to
combine them they way I want it. I want the concern of assembly being
separated from the source itself.
> >It is like you write a Java program like this:
> >
> >
> >2: {
> >4: }
> >
> >3: System.out.println();
> >1: for(int i=0;i<10;i11)
> >
> >
> >
> >Shows pretty much the nonsense of your argumentation. For priorizing the
loading of components in CDI priorities are great and sufficient, here they
are not.
> >
> >
> >> Finally functions is the
> >>
> >>> modern way of modelling such an operation.
> >>
> >>If you have a hammer...
> >>I'm not interested in style if it doesn't add any real benefit.
> >>
> >>
> >If the hammer is more elegant and powerful but still easy than you
outstyled solution, let it be a hammer!
> >
> >>> different or
> >>
> >>> partial overridings (common in complex environments)
> >>
> >>Never came across this need and I did very complex projects. It's
always a trade off between an easy straight forward algorigthm which are
easy to understand but sometimes you have to bend em a bit or program your
own (PropertySource). The other option is to have hugely complex base
mechanism which noone can use in practice because it is 'too flexible' -
means not clear and straight enough.
> >>
> >>
> >>> you will never get one solution, which a special type of
> >>
> >>> overridings that matches all users.
> >>Oh sure we do. By having the ConfigSource define their ordinal
themselves and it being really easy for a programmer to add own
ConfigSources we have all of that!
> >>
> >>
> >>
> >>> A solution should NEVER constraint users in doing the stuff
> >>> they want!*
> >>
> >>Having the sorting via Ordinal doesn't impose any restriction on the
user. Because he can easily overwrite those values.
> >>We are talking about a simple straight forward config mechanism and not
about alien rocket science and time travelling.
> >>
> >>
> >>>You are not on green field here!
> >>
> >>
> >>Oh boy, we are! We just need to fulfil user needs, that's all.
> >I am not a boy. I am an adult with 44 years on track.... !
> >And BTW you seem to have lost every kind of reality contact. Do you
really think companies will change their internal systems completely
because just a few guys think they know
> >how the world is rouling...? NO!
> >
> >>
> >>> *Of course not! (despite the fact that is trivial for the ones used
the
> >>> functional style of Java 8).
> >>Of course I know Map#merge, but what do you use it for? To me it seems
like an overkill.
> >Seems that your mindis still stick on Java 7.,,,
> >
> >> You can still provide a singleton with
> >>> constants, where you*
> >>> *provide the most common combinations, see AggregationPolicy in my the
> >>> current tree.*
> >>
> >>Again: I don't see the benefit. If I'm in an EAR and like to get my
"documentarchive.endpoint.url" then WHY would I like to manually change the
aggregation? Makes no sense to me. And this increases the complexity quite
impressively.
> >>
> >
> >
> >Perhaps one day you realize that we are talking about a general
configuration soultion. EE is a sepcial case, not the other way round. It
is NOT like Deltaspike, which benefits the mechanism provided by CDI. It is
not and if it will, it gets Deltaspike 2, which is useless. There is
already one, which for its purposes on this level, I agree, works well. But
for a general solution it lacks so much on functionality-
> >
> >
> >I personally really think you still do not get the difference! It
drives me crazy.
> >
> >LieGrue,
> >>strub
> >>
> >>
> >>
> >>
> >>> On Saturday, 27 December 2014, 12:28, Anatole Tresch <
atsticks@gmail.com> wrote:
> >>> > *See inline...*
> >>>
> >>> 2014-12-27 11:42 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> >>>
> >>>> Hi!
> >>>>
> >>>> 1.1)
> >>>>
> >>>> I think we agree that having a PropertySource/ConfigSource SPI with
MANY
> >>>> implementations is the way to go?
> >>>> Any objections?
> >>>>
> >>> *+1 The way to go.*
> >>>
> >>>
> >>> 1.2)
> >>>>
> >>>> Where should it belong to? Is it an API or rather an SPI?
> >>>> I think it's more the later. A end user just likes to get the
> >>> 'final'
> >>>> configured values and does NOT deal with the PropertySources
himself. It is
> >>>> really just for extending the system -> SPI.
> >>>>
> >>> *+1 for PropertySource being an SPI. Configuration must be the API.*
> >>>
> >>>
> >>> 1.3)
> >>>> Merging.
> >>>> Option (1.3.a) Do we like to do 'implicit' merging (aka the
> >>> ordinal
> >>>> stuff).
> >>>>
> >>> *It's not a question of taste. The mechanism is clumsy and implies
> >>> constraints that are already known as of now not matching all use
cases. On
> >>> top of it the priority leaks into the PropertySoiurce API (as an
additional
> >>> method, which is a very ugly mix of concerns), Finally functions is
the
> >>> modern way of modelling such an operation.*
> >>>
> >>>
> >>>> Option (1.3.b) Or do we like 'explicit' (the merge function). What
> >>> benefit
> >>>> does this add in practice?
> >>>>
> >>>
> >>> *See above and as outlined multiple times. Adding additional
functionality
> >>> for audit (e.g. logging of the configuration overriding), different or
> >>> partial overridings (common in complex environments). Please stop
> >>> discussion on this priority thing, it's simply not enough! By the
way the
> >>> priority thing can still be implemented, when the rest of the design
is
> >>> done in a modular way. My proposed solution gave you the abtrsaction
of a
> >>> ConfigProvider BTW, where you could do this easily, but also the other
> >>> stuff. What you do depends on the use case, and to some extent your
> >>> personal taste. A solution should NEVER constraint users in doing the
stuff
> >>> they want!*
> >>>
> >>> Ad 1.3.a 'explicit' merging: This is basically the DeltaSpike mode:
EACH
> >>>> ConfigSource (PropertySource) has an ordinal which it can set
itself. The
> >>>> higher the configuration ordinal of the ConfigSource, the more
important it
> >>>> is and it will override values from ConfigSources with lower
ordinal.
> >>>>
> >>>> That way it is possible to have a kind of 'default configuration'
> >>> e.g. in
> >>>> a property file inside your project and later overwrite it via
-Dxxx=yyy,
> >>>> JNDI, or some container provided MyCountainerAdminConfigSource etc
later.
> >>>>
> >>> *No Mark. The fact of having a default configuration does not
interconnect
> >>> how this is evaluated and composed. You are wrong! And on top, when
I look
> >>> at your ideas: you will never get one solution, which a special type
of
> >>> overridings that matches all users. You have to provide building
blocks
> >>> (one more) that helps the users (companies) to model their
functionality
> >>> with it. You are not on green field here!*
> >>>
> >>> Ad 1.3.b 'implicit' merging: Well, actually I don't got this. There
> >>> was
> >>>> merge(String key, PropertySource s1, s2), but that would mean that
every
> >>>> user needs to deal with that himself? Could you please elaborate on
that
> >>>> option? I didn't get it..
> >>>
> >>> *Of course not! (despite the fact that is trivial for the ones used
the
> >>> functional style of Java 8). You can still provide a singleton with
> >>> constants, where you*
> >>> *provide the most common combinations, see AggregationPolicy in my the
> >>> current tree.*
> >>>
> >>> *-Anatole*
> >>>
> >>>
> >>>>
> >>>>
> >>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> *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*
> >>
> >>>
> >>
> >
> >
> >
> >
> >--
> >
> >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/
> >Google: atsticks
> >Mobile +41-76 344 62 79
> >
> >
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Mark Struberg <st...@yahoo.de>.
No Anatole, I DO get it, but I really think it is a bad idea. Because it adds way too much complexity or a very limited benefit.
Think about it in an analogy to the ExpressionLanguage ELResolver chain. Of course this is a sorted lookup chain. And this list is fixed!
And at runtime you cannot change the order and the user also does not care!
All he cares is that #{user.name} does the right thing. He does not have to express an 'evaluator' and the chain ordering for each and every EL invocation. It just does not make any sense from a users perspective.
LieGrue,
strub
On Saturday, 27 December 2014, 14:17, Anatole Tresch <at...@gmail.com> wrote:
>
>
>Hi Mark
>
>
>2014-12-27 12:56 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>
>> The mechanism is clumsy and implies
>>> constraints that are already known as of now not matching all use cases.
>>
>>Tell me some limitations. Never had one. So just enlist them here and now.
>>
>And I am working since decades as well in the industry. I will not argue about use cases. I gave you same examples. You have the stand my opinion, unless you feel your opinion counts more than mine.
>
>> On top of it the priority leaks into the PropertySource API
>>
>>
>>Because it IS part of the PropertySource!
>>
>
>But it shoud not. I want to have my property sources and I want to combine them they way I want it. I want the concern of assembly being separated from the source itself.
>It is like you write a Java program like this:
>
>
>2: {
>4: }
>
>3: System.out.println();
>1: for(int i=0;i<10;i11)
>
>
>
>Shows pretty much the nonsense of your argumentation. For priorizing the loading of components in CDI priorities are great and sufficient, here they are not.
>
>
>> Finally functions is the
>>
>>> modern way of modelling such an operation.
>>
>>If you have a hammer...
>>I'm not interested in style if it doesn't add any real benefit.
>>
>>
>If the hammer is more elegant and powerful but still easy than you outstyled solution, let it be a hammer!
>
>>> different or
>>
>>> partial overridings (common in complex environments)
>>
>>Never came across this need and I did very complex projects. It's always a trade off between an easy straight forward algorigthm which are easy to understand but sometimes you have to bend em a bit or program your own (PropertySource). The other option is to have hugely complex base mechanism which noone can use in practice because it is 'too flexible' - means not clear and straight enough.
>>
>>
>>> you will never get one solution, which a special type of
>>
>>> overridings that matches all users.
>>Oh sure we do. By having the ConfigSource define their ordinal themselves and it being really easy for a programmer to add own ConfigSources we have all of that!
>>
>>
>>
>>> A solution should NEVER constraint users in doing the stuff
>>> they want!*
>>
>>Having the sorting via Ordinal doesn't impose any restriction on the user. Because he can easily overwrite those values.
>>We are talking about a simple straight forward config mechanism and not about alien rocket science and time travelling.
>>
>>
>>>You are not on green field here!
>>
>>
>>Oh boy, we are! We just need to fulfil user needs, that's all.
>I am not a boy. I am an adult with 44 years on track.... !
>And BTW you seem to have lost every kind of reality contact. Do you really think companies will change their internal systems completely because just a few guys think they know
>how the world is rouling...? NO!
>
>>
>>> *Of course not! (despite the fact that is trivial for the ones used the
>>> functional style of Java 8).
>>Of course I know Map#merge, but what do you use it for? To me it seems like an overkill.
>Seems that your mindis still stick on Java 7.,,,
>
>> You can still provide a singleton with
>>> constants, where you*
>>> *provide the most common combinations, see AggregationPolicy in my the
>>> current tree.*
>>
>>Again: I don't see the benefit. If I'm in an EAR and like to get my "documentarchive.endpoint.url" then WHY would I like to manually change the aggregation? Makes no sense to me. And this increases the complexity quite impressively.
>>
>
>
>Perhaps one day you realize that we are talking about a general configuration soultion. EE is a sepcial case, not the other way round. It is NOT like Deltaspike, which benefits the mechanism provided by CDI. It is not and if it will, it gets Deltaspike 2, which is useless. There is already one, which for its purposes on this level, I agree, works well. But for a general solution it lacks so much on functionality-
>
>
>I personally really think you still do not get the difference! It drives me crazy.
>
>LieGrue,
>>strub
>>
>>
>>
>>
>>> On Saturday, 27 December 2014, 12:28, Anatole Tresch <at...@gmail.com> wrote:
>>> > *See inline...*
>>>
>>> 2014-12-27 11:42 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>>>
>>>> Hi!
>>>>
>>>> 1.1)
>>>>
>>>> I think we agree that having a PropertySource/ConfigSource SPI with MANY
>>>> implementations is the way to go?
>>>> Any objections?
>>>>
>>> *+1 The way to go.*
>>>
>>>
>>> 1.2)
>>>>
>>>> Where should it belong to? Is it an API or rather an SPI?
>>>> I think it's more the later. A end user just likes to get the
>>> 'final'
>>>> configured values and does NOT deal with the PropertySources himself. It is
>>>> really just for extending the system -> SPI.
>>>>
>>> *+1 for PropertySource being an SPI. Configuration must be the API.*
>>>
>>>
>>> 1.3)
>>>> Merging.
>>>> Option (1.3.a) Do we like to do 'implicit' merging (aka the
>>> ordinal
>>>> stuff).
>>>>
>>> *It's not a question of taste. The mechanism is clumsy and implies
>>> constraints that are already known as of now not matching all use cases. On
>>> top of it the priority leaks into the PropertySoiurce API (as an additional
>>> method, which is a very ugly mix of concerns), Finally functions is the
>>> modern way of modelling such an operation.*
>>>
>>>
>>>> Option (1.3.b) Or do we like 'explicit' (the merge function). What
>>> benefit
>>>> does this add in practice?
>>>>
>>>
>>> *See above and as outlined multiple times. Adding additional functionality
>>> for audit (e.g. logging of the configuration overriding), different or
>>> partial overridings (common in complex environments). Please stop
>>> discussion on this priority thing, it's simply not enough! By the way the
>>> priority thing can still be implemented, when the rest of the design is
>>> done in a modular way. My proposed solution gave you the abtrsaction of a
>>> ConfigProvider BTW, where you could do this easily, but also the other
>>> stuff. What you do depends on the use case, and to some extent your
>>> personal taste. A solution should NEVER constraint users in doing the stuff
>>> they want!*
>>>
>>> Ad 1.3.a 'explicit' merging: This is basically the DeltaSpike mode: EACH
>>>> ConfigSource (PropertySource) has an ordinal which it can set itself. The
>>>> higher the configuration ordinal of the ConfigSource, the more important it
>>>> is and it will override values from ConfigSources with lower ordinal.
>>>>
>>>> That way it is possible to have a kind of 'default configuration'
>>> e.g. in
>>>> a property file inside your project and later overwrite it via -Dxxx=yyy,
>>>> JNDI, or some container provided MyCountainerAdminConfigSource etc later.
>>>>
>>> *No Mark. The fact of having a default configuration does not interconnect
>>> how this is evaluated and composed. You are wrong! And on top, when I look
>>> at your ideas: you will never get one solution, which a special type of
>>> overridings that matches all users. You have to provide building blocks
>>> (one more) that helps the users (companies) to model their functionality
>>> with it. You are not on green field here!*
>>>
>>> Ad 1.3.b 'implicit' merging: Well, actually I don't got this. There
>>> was
>>>> merge(String key, PropertySource s1, s2), but that would mean that every
>>>> user needs to deal with that himself? Could you please elaborate on that
>>>> option? I didn't get it..
>>>
>>> *Of course not! (despite the fact that is trivial for the ones used the
>>> functional style of Java 8). You can still provide a singleton with
>>> constants, where you*
>>> *provide the most common combinations, see AggregationPolicy in my the
>>> current tree.*
>>>
>>> *-Anatole*
>>>
>>>
>>>>
>>>>
>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>
>>>
>>>
>>> --
>>> *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*
>>
>>>
>>
>
>
>
>
>--
>
>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/
>Google: atsticks
>Mobile +41-76 344 62 79
>
>
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Anatole Tresch <at...@gmail.com>.
*Hi Mark*
2014-12-27 12:56 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> > The mechanism is clumsy and implies
> > constraints that are already known as of now not matching all use cases.
>
> Tell me some limitations. Never had one. So just enlist them here and now.
>
*And I am working since decades as well in the industry. I will not argue
about use cases. I gave you same examples. You have the stand my opinion,
unless you feel your opinion counts more than mine.*
> > On top of it the priority leaks into the PropertySource API
>
>
> Because it IS part of the PropertySource!
>
*But it shoud not. I want to have my property sources and I want to
combine them they way I want it. I want the concern of assembly being
separated from the source itself.*
*It is like you write a Java program like this:*
*2: {*
*4: }*
*3: System.out.println();*
*1: for(int i=0;i<10;i11)*
*Shows pretty much the nonsense of your argumentation. For priorizing the
loading of components in CDI priorities are great and sufficient, here they
are not.*
> Finally functions is the
>
> > modern way of modelling such an operation.
>
> If you have a hammer...
> I'm not interested in style if it doesn't add any real benefit.
>
> *If the hammer is more elegant and powerful but still easy than you
outstyled solution, let it be a hammer! *
>
> > different or
>
> > partial overridings (common in complex environments)
>
> Never came across this need and I did very complex projects. It's always a
> trade off between an easy straight forward algorigthm which are easy to
> understand but sometimes you have to bend em a bit or program your own
> (PropertySource). The other option is to have hugely complex base mechanism
> which noone can use in practice because it is 'too flexible' - means not
> clear and straight enough.
>
>
> > you will never get one solution, which a special type of
>
> > overridings that matches all users.
> Oh sure we do. By having the ConfigSource define their ordinal themselves
> and it being really easy for a programmer to add own ConfigSources we have
> all of that!
>
>
>
> > A solution should NEVER constraint users in doing the stuff
> > they want!*
>
> Having the sorting via Ordinal doesn't impose any restriction on the user.
> Because he can easily overwrite those values.
> We are talking about a simple straight forward config mechanism and not
> about alien rocket science and time travelling.
>
>
> >You are not on green field here!
>
>
>
>
> Oh boy, we are! We just need to fulfil user needs, that's all.
*I am not a boy. I am an adult with 44 years on track.... !*
*And BTW you seem to have lost every kind of reality contact. Do you really
think companies will change their internal systems completely because just
a few guys think they know*
*how the world is rouling...? NO!*
>
>
> > *Of course not! (despite the fact that is trivial for the ones used the
> > functional style of Java 8).
> Of course I know Map#merge, but what do you use it for? To me it seems
> like an overkill.
*Seems that your mindis still stick on Java 7.,,, *
> > You can still provide a singleton with
> > constants, where you*
> > *provide the most common combinations, see AggregationPolicy in my the
> > current tree.*
>
> Again: I don't see the benefit. If I'm in an EAR and like to get my
> "documentarchive.endpoint.url" then WHY would I like to manually change the
> aggregation? Makes no sense to me. And this increases the complexity quite
> impressively.
>
Perhaps one day you realize that we are talking about a general
configuration soultion. EE is a sepcial case, not the other way round. It
is NOT like Deltaspike, which benefits the mechanism provided by CDI. It is
not and if it will, it gets Deltaspike 2, which is useless. There is
already one, which for its purposes on this level, I agree, works well. But
for a general solution it lacks so much on functionality-
*I personally really think you still do not get the difference! It drives
me crazy.*
LieGrue,
> strub
>
>
>
>
> > On Saturday, 27 December 2014, 12:28, Anatole Tresch <at...@gmail.com>
> wrote:
> > > *See inline...*
> >
> > 2014-12-27 11:42 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> >
> >> Hi!
> >>
> >> 1.1)
> >>
> >> I think we agree that having a PropertySource/ConfigSource SPI with
> MANY
> >> implementations is the way to go?
> >> Any objections?
> >>
> > *+1 The way to go.*
> >
> >
> > 1.2)
> >>
> >> Where should it belong to? Is it an API or rather an SPI?
> >> I think it's more the later. A end user just likes to get the
> > 'final'
> >> configured values and does NOT deal with the PropertySources himself.
> It is
> >> really just for extending the system -> SPI.
> >>
> > *+1 for PropertySource being an SPI. Configuration must be the API.*
> >
> >
> > 1.3)
> >> Merging.
> >> Option (1.3.a) Do we like to do 'implicit' merging (aka the
> > ordinal
> >> stuff).
> >>
> > *It's not a question of taste. The mechanism is clumsy and implies
> > constraints that are already known as of now not matching all use cases.
> On
> > top of it the priority leaks into the PropertySoiurce API (as an
> additional
> > method, which is a very ugly mix of concerns), Finally functions is the
> > modern way of modelling such an operation.*
> >
> >
> >> Option (1.3.b) Or do we like 'explicit' (the merge function). What
> > benefit
> >> does this add in practice?
> >>
> >
> > *See above and as outlined multiple times. Adding additional
> functionality
> > for audit (e.g. logging of the configuration overriding), different or
> > partial overridings (common in complex environments). Please stop
> > discussion on this priority thing, it's simply not enough! By the way
> the
> > priority thing can still be implemented, when the rest of the design is
> > done in a modular way. My proposed solution gave you the abtrsaction of a
> > ConfigProvider BTW, where you could do this easily, but also the other
> > stuff. What you do depends on the use case, and to some extent your
> > personal taste. A solution should NEVER constraint users in doing the
> stuff
> > they want!*
> >
> > Ad 1.3.a 'explicit' merging: This is basically the DeltaSpike mode: EACH
> >> ConfigSource (PropertySource) has an ordinal which it can set itself.
> The
> >> higher the configuration ordinal of the ConfigSource, the more
> important it
> >> is and it will override values from ConfigSources with lower ordinal.
> >>
> >> That way it is possible to have a kind of 'default configuration'
> > e.g. in
> >> a property file inside your project and later overwrite it via
> -Dxxx=yyy,
> >> JNDI, or some container provided MyCountainerAdminConfigSource etc
> later.
> >>
> > *No Mark. The fact of having a default configuration does not
> interconnect
> > how this is evaluated and composed. You are wrong! And on top, when I
> look
> > at your ideas: you will never get one solution, which a special type of
> > overridings that matches all users. You have to provide building blocks
> > (one more) that helps the users (companies) to model their functionality
> > with it. You are not on green field here!*
> >
> > Ad 1.3.b 'implicit' merging: Well, actually I don't got this. There
> > was
> >> merge(String key, PropertySource s1, s2), but that would mean that
> every
> >> user needs to deal with that himself? Could you please elaborate on
> that
> >> option? I didn't get it..
> >
> > *Of course not! (despite the fact that is trivial for the ones used the
> > functional style of Java 8). You can still provide a singleton with
> > constants, where you*
> > *provide the most common combinations, see AggregationPolicy in my the
> > current tree.*
> >
> > *-Anatole*
> >
> >
> >>
> >>
> >
> >> LieGrue,
> >> strub
> >>
> >
> >
> >
> > --
> > *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*
> >
>
--
*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*
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Mark Struberg <st...@yahoo.de>.
> The mechanism is clumsy and implies
> constraints that are already known as of now not matching all use cases.
Tell me some limitations. Never had one. So just enlist them here and now.
> On top of it the priority leaks into the PropertySource API
Because it IS part of the PropertySource!
> Finally functions is the
> modern way of modelling such an operation.
If you have a hammer...
I'm not interested in style if it doesn't add any real benefit.
> different or
> partial overridings (common in complex environments)
Never came across this need and I did very complex projects. It's always a trade off between an easy straight forward algorigthm which are easy to understand but sometimes you have to bend em a bit or program your own (PropertySource). The other option is to have hugely complex base mechanism which noone can use in practice because it is 'too flexible' - means not clear and straight enough.
> you will never get one solution, which a special type of
> overridings that matches all users.
Oh sure we do. By having the ConfigSource define their ordinal themselves and it being really easy for a programmer to add own ConfigSources we have all of that!
> A solution should NEVER constraint users in doing the stuff
> they want!*
Having the sorting via Ordinal doesn't impose any restriction on the user. Because he can easily overwrite those values.
We are talking about a simple straight forward config mechanism and not about alien rocket science and time travelling.
>You are not on green field here!
Oh boy, we are! We just need to fulfil user needs, that's all.
> *Of course not! (despite the fact that is trivial for the ones used the
> functional style of Java 8).
Of course I know Map#merge, but what do you use it for? To me it seems like an overkill.
> You can still provide a singleton with
> constants, where you*
> *provide the most common combinations, see AggregationPolicy in my the
> current tree.*
Again: I don't see the benefit. If I'm in an EAR and like to get my "documentarchive.endpoint.url" then WHY would I like to manually change the aggregation? Makes no sense to me. And this increases the complexity quite impressively.
LieGrue,
strub
> On Saturday, 27 December 2014, 12:28, Anatole Tresch <at...@gmail.com> wrote:
> > *See inline...*
>
> 2014-12-27 11:42 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>
>> Hi!
>>
>> 1.1)
>>
>> I think we agree that having a PropertySource/ConfigSource SPI with MANY
>> implementations is the way to go?
>> Any objections?
>>
> *+1 The way to go.*
>
>
> 1.2)
>>
>> Where should it belong to? Is it an API or rather an SPI?
>> I think it's more the later. A end user just likes to get the
> 'final'
>> configured values and does NOT deal with the PropertySources himself. It is
>> really just for extending the system -> SPI.
>>
> *+1 for PropertySource being an SPI. Configuration must be the API.*
>
>
> 1.3)
>> Merging.
>> Option (1.3.a) Do we like to do 'implicit' merging (aka the
> ordinal
>> stuff).
>>
> *It's not a question of taste. The mechanism is clumsy and implies
> constraints that are already known as of now not matching all use cases. On
> top of it the priority leaks into the PropertySoiurce API (as an additional
> method, which is a very ugly mix of concerns), Finally functions is the
> modern way of modelling such an operation.*
>
>
>> Option (1.3.b) Or do we like 'explicit' (the merge function). What
> benefit
>> does this add in practice?
>>
>
> *See above and as outlined multiple times. Adding additional functionality
> for audit (e.g. logging of the configuration overriding), different or
> partial overridings (common in complex environments). Please stop
> discussion on this priority thing, it's simply not enough! By the way the
> priority thing can still be implemented, when the rest of the design is
> done in a modular way. My proposed solution gave you the abtrsaction of a
> ConfigProvider BTW, where you could do this easily, but also the other
> stuff. What you do depends on the use case, and to some extent your
> personal taste. A solution should NEVER constraint users in doing the stuff
> they want!*
>
> Ad 1.3.a 'explicit' merging: This is basically the DeltaSpike mode: EACH
>> ConfigSource (PropertySource) has an ordinal which it can set itself. The
>> higher the configuration ordinal of the ConfigSource, the more important it
>> is and it will override values from ConfigSources with lower ordinal.
>>
>> That way it is possible to have a kind of 'default configuration'
> e.g. in
>> a property file inside your project and later overwrite it via -Dxxx=yyy,
>> JNDI, or some container provided MyCountainerAdminConfigSource etc later.
>>
> *No Mark. The fact of having a default configuration does not interconnect
> how this is evaluated and composed. You are wrong! And on top, when I look
> at your ideas: you will never get one solution, which a special type of
> overridings that matches all users. You have to provide building blocks
> (one more) that helps the users (companies) to model their functionality
> with it. You are not on green field here!*
>
> Ad 1.3.b 'implicit' merging: Well, actually I don't got this. There
> was
>> merge(String key, PropertySource s1, s2), but that would mean that every
>> user needs to deal with that himself? Could you please elaborate on that
>> option? I didn't get it..
>
> *Of course not! (despite the fact that is trivial for the ones used the
> functional style of Java 8). You can still provide a singleton with
> constants, where you*
> *provide the most common combinations, see AggregationPolicy in my the
> current tree.*
>
> *-Anatole*
>
>
>>
>>
>
>> LieGrue,
>> strub
>>
>
>
>
> --
> *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*
>
Re: [DISCUSS] core concepts - to merge or not to merge
Posted by Anatole Tresch <at...@gmail.com>.
*See inline...*
2014-12-27 11:42 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> Hi!
>
> 1.1)
>
> I think we agree that having a PropertySource/ConfigSource SPI with MANY
> implementations is the way to go?
> Any objections?
>
*+1 The way to go.*
1.2)
>
> Where should it belong to? Is it an API or rather an SPI?
> I think it's more the later. A end user just likes to get the 'final'
> configured values and does NOT deal with the PropertySources himself. It is
> really just for extending the system -> SPI.
>
*+1 for PropertySource being an SPI. Configuration must be the API.*
1.3)
> Merging.
> Option (1.3.a) Do we like to do 'implicit' merging (aka the ordinal
> stuff).
>
*It's not a question of taste. The mechanism is clumsy and implies
constraints that are already known as of now not matching all use cases. On
top of it the priority leaks into the PropertySoiurce API (as an additional
method, which is a very ugly mix of concerns), Finally functions is the
modern way of modelling such an operation.*
> Option (1.3.b) Or do we like 'explicit' (the merge function). What benefit
> does this add in practice?
>
*See above and as outlined multiple times. Adding additional functionality
for audit (e.g. logging of the configuration overriding), different or
partial overridings (common in complex environments). Please stop
discussion on this priority thing, it's simply not enough! By the way the
priority thing can still be implemented, when the rest of the design is
done in a modular way. My proposed solution gave you the abtrsaction of a
ConfigProvider BTW, where you could do this easily, but also the other
stuff. What you do depends on the use case, and to some extent your
personal taste. A solution should NEVER constraint users in doing the stuff
they want!*
Ad 1.3.a 'explicit' merging: This is basically the DeltaSpike mode: EACH
> ConfigSource (PropertySource) has an ordinal which it can set itself. The
> higher the configuration ordinal of the ConfigSource, the more important it
> is and it will override values from ConfigSources with lower ordinal.
>
> That way it is possible to have a kind of 'default configuration' e.g. in
> a property file inside your project and later overwrite it via -Dxxx=yyy,
> JNDI, or some container provided MyCountainerAdminConfigSource etc later.
>
*No Mark. The fact of having a default configuration does not interconnect
how this is evaluated and composed. You are wrong! And on top, when I look
at your ideas: you will never get one solution, which a special type of
overridings that matches all users. You have to provide building blocks
(one more) that helps the users (companies) to model their functionality
with it. You are not on green field here!*
Ad 1.3.b 'implicit' merging: Well, actually I don't got this. There was
> merge(String key, PropertySource s1, s2), but that would mean that every
> user needs to deal with that himself? Could you please elaborate on that
> option? I didn't get it..
*Of course not! (despite the fact that is trivial for the ones used the
functional style of Java 8). You can still provide a singleton with
constants, where you*
*provide the most common combinations, see AggregationPolicy in my the
current tree.*
*-Anatole*
>
>
> LieGrue,
> strub
>
--
*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*