Re: Unify internal configuration
@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
Re: Unify internal configuration
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
Re: Unify internal configuration
-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
Re: Unify internal configuration
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
Re: Unify internal configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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/b5be1c79b67d6a15b30036ed9 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- iQIcBAEBCgAGBQJVP2ISAAoJEJr1g28gQ1chkMoP/2vKSSiAqx5SX5/pf5EFF1Hf nEIaRzwonioWF8nlaGy7uIBw6u3mHc0SaZXNCoQztqpMG7zmmjh3rSaWOj81dOH5 XW5V6eFsPLTWGtzyXLbSSiTswSrLPGd/OVX4romsuLHwtOIbb8ftmixmObjDL0Ge bvbEV4Aw6HyQCXJM9Rah+qhKf2Bc/CEKx/I8hZ0VIqOP3mJSPYke2yTbnD81VrUU W3MGpas3xfg2YZf5dqeIYYDinS7johY0SWocp61kq/lTDZZHx89fLXyz1HFhR87C SX5W8EFCmtEO8DPn0+fKQJGIIRya9iV1TFZTVQrQ8e0YkJXIfzZE3ltiS/4Bagq4 Nv/fcs9qISpEpK49jP/UXIk63Yj2WiG4xCpaLOzR09XDx9+iRRIty/QsPfkEfloh kAFoX7YQ3o0sBw3UR16dGacRaldKIF/IoyGxRv9irFz1OVmdBp5TA1qJg17rDpyU BgSy3LP1k8GZG0+PRf+LNTN3xwQjZ41n3t79j86w4xVuJjFa0mOdXfb+mmtcOp9p CKbEBNwCVund1A/E/2lhGJSX35Yw7OQtPcW4eNVwL9dr9EgMeFpqDNRNztBj02LB U46HXMdGxF3sAGZ2mYfPfuxVEWxXC01Vudw0R2fdtYxchcouVEQzOhIrEFV3C/Aj TRQNKzxADXw8xuw6ZPhG =gCYU -END PGP SIGNATURE-
Re: Unify internal configuration
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: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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/b5be1c79b67d6a15b30036ed90a 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 Red Hat Brno -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVPnQmAAoJEJr1g28gQ1chzXQP/1FGjbYZlU80PsDPcjPROMEZ w5K/Rl/PTrHqzBsqnrFfN3qDVagXgGasRUKphV/r9Dk88G1+1I6ENWv2u6XZy8rh yat3kJmNsCJJvAzaq7I66vAk4kfTR+VNkKc1SdeaR/JgP4Iamyi9kF5cU7j4FMmY JngHT8qQJiS+Zli9f8l3FZ+1IzDVWAyBGoYgmrKJKpkc3bZiHpaFiXIrpWDzI3JA vJ8mlbz8SCpEUsd2/cZzAaO9MhUnI47j6cDMzQaLnriXkPeajU/GRB/h50cFjuYS smD0ezHdnrq1YMr5yk0rLNd2SXSXaMLESGuh6yg0kNqsQOtySS11ruyl4/b4rbXc deouS/eO0aokr4QgXJEenBKjQU6SZwswenuQvpEDpWjnQxtJRbnIIa9jvctjV3F0 H72kWo8lxTZpCfWh2E55xGc8GfeLvYJoeAKtHwGzxISNB6u1IOJEwudr3KSqp1Ag 88aIy0CFM0dMjhm62785DOYmYbWHGbrxwMN0/2s2SYfWPq0jfVLxmBRE0L+EC7uZ 2JV26jpt9gD19EOl/qU9pO371mHdOUeTo5uXMnHDzX3q4cBFJGovVw0+tgyxGaEq B3X1nHt7QBMVNTYGvxanxy9xxVmwxUqqL76dUTFN7U3Q1kmIpg1sSV2hRwNYAEwk ZPVUbLjKwIPTEQbPbFXn =VGY0 -END PGP SIGNATURE-
