@ron: i've created DELTASPIKE-892 for it. regards, gerhard
2015-05-01 18:12 GMT+02:00 Gerhard Petracek <gerhard.petra...@gmail.com>: > 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----- >>> >> >> >
