> 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
> <[email protected]> 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" <[email protected]> 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 <
>> [email protected]> 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"
> <[email protected]> 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 <
>> >> [email protected]> 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"
>> > <[email protected]> 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
> <
>> >> [email protected]> wrote:
>> >> >>
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> >Hi Mark
>> >> >> >
>> >> >> >
>> >> >> >2014-12-27 12:56 GMT+01:00 Mark Struberg
>> > <[email protected]>:
>> >> >> >
>> >> >> >> 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
>> > <
>> >> [email protected]> wrote:
>> >> >> >>> > *See inline...*
>> >> >> >>>
>> >> >> >>> 2014-12-27 11:42 GMT+01:00 Mark Struberg
>> > <[email protected]>:
>> >> >> >>>
>> >> >> >>>> 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
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >
>>
>
