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