yes and no - the initial situation for "main (args)" isn't the same. once you create the same initial situation as a thought experiment, it is an example against your statement.
the following is a >thought experiment< to get a comparable case we would need to assume that all jvms support proprietary config-files >instead< of parameters (for the main-method). furthermore, there is just one which supports both (proprietary config-files as well as parameters). -> you wouldn't use the method which is just provided by one of them, >if< you like to provide a >portable< app-starter. translate it to our discussion: CdiContainer#boot(Map) does not work the same way for all containers, because all containers (we support) except openejb ignore whatever you pass in. -> CdiContainer#boot(Map) is controversial, but that doesn't mean that other parts of deltaspike should start to ignore portability as well. we could move ContainerAwareTestContext to the spi which would allow to customize different areas. then you can decide on your own if you would like to use an implementation which isn't portable. regards, gerhard 2014-09-20 16:47 GMT+02:00 Karl Kildén <karl.kil...@gmail.com>: > The contract resides in Deltaspike: CdiContainer. Offering the > implementations a way to receive properties is a general thing. It is > countless times in countless apis - you know "main (args)" I assume... Any > api that boots something should take args (imo). That some of the > underlying apis does not want properties is not the same is "not portable". > Since that extra boot(Properties p) does not break those who do not care > for properties. > > Sounds almost like someone suggested removing boot() and only having > boot(Properties p) > > Anyways I am done discussing this and I am fine with using my fork. > > I agree that not using test-control is a good idea and I will migrate away > from it. > > On 20 September 2014 16:30, Gerhard Petracek <gerhard.petra...@gmail.com> > wrote: > > > it's just not portable since only tomee supports it. > > tomee provides something very similar to our test-control, but specific > to > > features provided by tomee. > > imo it doesn't make sense to add something only for one container (to the > > api) which is supported by the test-module of that container already. > > > > regards, > > gerhard > > > > > > > > 2014-09-20 16:24 GMT+02:00 Karl Kildén <karl.kil...@gmail.com>: > > > > > FYI Gerhard said on the list that the boot(Properties p) in > CdiContainer > > > was a mistake and supporting it in test-control is thus wrong. > > > > > > I disagree and will branch test-control over n out > > > > > > On 20 September 2014 16:15, Karl Kildén <karl.kil...@gmail.com> wrote: > > > > > > > All those suggestions use properties so I am not sure what to say ;) > > > > > > > > On 20 September 2014 16:07, Gerhard Petracek < > > gerhard.petra...@gmail.com > > > > > > > > wrote: > > > > > > > >> hi karl, > > > >> > > > >> it sounds better than DELTASPIKE-577, however, please provide the > > > >> use-case/s which can't be done with [1]. > > > >> (the other implementations we support right now don't support such > > > >> properties anyway). > > > >> > > > >> regards, > > > >> gerhard > > > >> > > > >> [1] http://tomee.apache.org/alternate-descriptors.html > > > >> > > > >> > > > >> > > > >> 2014-09-20 15:28 GMT+02:00 Karl Kildén <karl.kil...@gmail.com>: > > > >> > > > >> > Hello, > > > >> > > > > >> > Test-Control will bootstrap the CdiContainer for me using the > > #boot() > > > >> > constructor. However I want it to use #boot(Properties p) > > > >> > > > > >> > This seems logical since CdiContainer contract has that boot > method. > > > My > > > >> > suggestion is: > > > >> > > > > >> > public interface PropertiesProvider { > > > >> > > > > >> > Properties properties(); > > > >> > } > > > >> > > > > >> > @TestControl(propertiesProvider=PropertiesProviderImpl.class) > > > >> > > > > >> > > > > >> > Class<? extends PropertiesProvider> providerClazz = > > > >> > this.testControl.propertiesProvider(); > > > >> > if (providerClazz != null) { > > > >> > Properties properties = > providerClazz.newInstance().properties(); > > > >> > } > > > >> > > > > >> > > > > >> > All user have to do is implement that interface PropertiesProvider > > > and > > > >> > assign it to the test. > > > >> > > > > >> > This would save me a lot of trouble... > > > >> > > > > >> > cheers > > > >> > > > > >> > > > > > > > > > > > > > >
