-----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 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-----
