it's a bit more complex and we need an additional marker-interface to keep all benefits we had before, however, +1 for committing it (because it's closer to the base which gets extended).
regards, gerhard 2015-04-30 15:31 GMT+02:00 Gerhard Petracek <gerhard.petra...@gmail.com>: > i've to check some details, however, basically +1 > > regards, > gerhard > > > > 2015-04-30 15:22 GMT+02:00 Ron Smeral <rsme...@apache.org>: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hi again, >> >> here's my proposal for a solution to the slight conf. API mess: >> https://github.com/rsmeral/deltaspike/commit/d270ac0cb6d5ed47a5912365f95 >> 9145b12da0e99 >> <https://github.com/rsmeral/deltaspike/commit/d270ac0cb6d5ed47a5912365f959145b12da0e99> >> >> Main change: a new type-safe fluent API for typed config resolution >> >> Connection conn = ConfigResolver.resolve("db.connection") >> .as(Connection.class, new ConnectionConverter()) >> .parameterizedBy("db.vendor") >> .withCurrentProjectStage(true) >> .strictly() >> .withDefault(whatever) >> .getValue(); >> >> or simply >> >> String conn = ConfigResolver.resolve("db.connection").getValue(); >> >> This would obsolete TypedConfig since ConfigResolver would be >> implicitly type-aware and it brings the type conversion functions from >> DefaultConfigPropertyProducer and TypedConfig into ConfigResolver. >> >> We would also mark the dynamic configurations with some interface >> (currently DeltaSpikeConfig), mark the static ones with another (e.g. >> DeltaSpikeBaseConfig). >> >> Check out the commit (and also DELTASPIKE-885) for more details. >> >> Thanks for any comments, reviews and suggestions :) >> >> R. >> >> On 28.4.2015 12:33, Ron Smeral wrote: >> > Thanks for the clarification. I'll try to answer my own question >> > then, please comment if anything is not right: >> > >> >> * why does PropertyFileConfig implement DeltaSpikeConfig? Doesn't >> >> make sense to me, given the purpose of DeltaSpikeConfig. >> > >> > I guess this was not intentional and is a bug. I'll file an issue >> > for this. >> > >> >> * is there any reason why the ones from the first category >> >> (TransactionConfig and JsfModuleConfig) couldn't be implemented >> >> using the second way (TypedConfig)? >> > >> > They couldn't, synce TypedConfig is for "static" boot-time >> > configuration . >> > >> >> * if none of the above is applicable, then: shouldn't the >> >> TypedConfig ones (CoreBaseConfig, ...) implement DeltaSpikeConfig >> >> as well? >> > >> > I understand that we'd like to keep DeltaSpikeConfig as the marker >> > for all "dynamic" configuration, i.e. the way it's used now. Maybe >> > we could introduce a new interface to expose the TypedConfig-based >> > interfaces, sth. like DeltaSpikeBaseConfig. >> > >> > R. >> > >> > On 27.4.2015 21:36, Mark Struberg wrote: >> >> Hi! >> > >> >> Sorry for brevity. Like to quickly sum up what we discussed on >> >> irc: >> > >> >> .) DeltaSpikeConfig is merely a marker interface for >> >> interfaces/classes which can be used to define the behaviour of >> >> certain DeltaSpike features at runtimy. Since this is a class it >> >> can return different values for each invocation. This is e.g. >> >> useful for the LocaleResoler configuration (each user request >> >> could result in another Locale). Otoh this configuration >> >> mechanism is only available once the CDI container finally got >> >> booted. So it can NOT be used to e.g. configure CDI Extensions >> >> itself. >> > >> >> .) ConfigResolver based configuration. The TypeConfig is >> >> basically a object which contains the config-key + code to >> >> access the value. This mechanism is purely JavaSE and thus can >> >> also be used to configure Extensions itself as well. It’s also >> >> more the kind of a ’static’ configuration. >> > >> >> LieGrue, strub >> > >> > >> >>> Am 27.04.2015 um 19:38 schrieb Ron Smeral >> >>> <rsme...@apache.org>: >> >>> >> >> Hi, >> > >> >> DeltaSpike itself is currently configured in at least 2 different >> >> ways: * using interfaces extending DeltaSpikeConfig: ** >> >> org.apache.deltaspike.jpa.api.transaction.TransactionConfig ** >> >> org.apache.deltaspike.jsf.api.config.JsfModuleConfig (** >> >> PropertyFileConfig (Why? It does not configure just DS itself.)) >> > >> >> * using interfaces with static TypedConfig instances: ** >> >> org.apache.deltaspike.testcontrol.impl.jsf.MyFacesTestBaseConfig >> >> ** org.apache.deltaspike.testcontrol.api.junit.TestBaseConfig ** >> >> org.apache.deltaspike.scheduler.impl.SchedulerBaseConfig ** >> >> org.apache.deltaspike.jsf.api.config.base.JsfBaseConfig ** >> >> org.apache.deltaspike.core.api.config.base.CoreBaseConfig >> > >> >> My questions are: * why does PropertyFileConfig implement >> >> DeltaSpikeConfig? Doesn't make sense to me, given the purpose of >> >> DeltaSpikeConfig. >> > >> >> * is there any reason why the ones from the first category >> >> (TransactionConfig and JsfModuleConfig) couldn't be implemented >> >> using the second way (TypedConfig)? >> > >> >> * if none of the above is applicable, then: shouldn't the >> >> TypedConfig ones (CoreBaseConfig, ...) implement DeltaSpikeConfig >> >> as well? >> > >> >> I hacked up a quick suggestion of how this could look: >> >> https://github.com/rsmeral/deltaspike/commit/b5be1c79b67d6a15b30036ed >> 9 >> > >> >> >> >> >> 0a >> > >> > >> > 7b90fba9b5e00 >> > >> >> Currently, having two ways of configuration defies the purpose >> >> of DeltaSpikeConfig -- that is allowing to find DS configuration >> >> points easily. >> > >> >> WDYT? >> > >> >> Regards, Ron >> > >> > >> > >> > >> >> - -- >> Ron Smeral >> JBoss Quality Engineer >> Brno >> -----BEGIN PGP SIGNATURE----- >> >> iQIcBAEBCgAGBQJVQiyEAAoJEJr1g28gQ1chuRAP/i+gtqFmLjeg17zQrPolUK/o >> 0/ZlGHonIHmMR8+ePWDpJIKMLgXRmj1pOk62sFbpGWDApfj2BLCfn/Lxz1L+6Zqp >> srsOrlQ3dYyy2kwHaPytClx6KNFcaBbK3p+BK5BR1IS2X2mtrRGhCZ7yWDRe6KKI >> JS0veh39NFfojhT/O7cImRqKRzsf6e1FoSRxCH/mFXOO5GBE3g/yPs+5j9kXwWjO >> DQffBl5II4lw4JHIvZeQW/JNC3hfq5Sgmxn3v6DtFnsurjqwkFpvwyD5kJDG6N2V >> LE6jX4QS0qbQB698OTH0efa0cvm19OcCobHvoWLvxtSr53yEdigtuYjcLU5ku5e3 >> Wb1jjS4L6X/RN0c9QjsEm6d9zDJ4jZFbKPNziHezjWKEy/jbSbpft8peCHC9ApUg >> 7JLMT/tOHbAcQTTPYZHgYcJ0J2Ko49riJr0ymFJlfv3OE+LYOJ2R24G5YgDHteAF >> C2DOTjsutcaIRI36VqezjK3o/0kaX1NTM7vMfxtJNEWTJFH9KyDrJ45hat4swleH >> HCbnbt7lOV/nwJKSerylWpwnG+g3uy04r6YLEYipPKeyBgF/o+ILYk31iEkOYwEA >> GDt5Jsmr9rqxVEZgINK9MnT0w6vKcyq9JTq4lDvaWlcBmmBGmLQCttUnzoLNtA5N >> BG3tQ2IZbCamQnnxL0NR >> =ewF+ >> -----END PGP SIGNATURE----- >> > >
