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