*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/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
