g which prevents you from registering an own
> > > ThreadLocalTestConfigSource which you add as to your tomee,
> right?
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > >
> > > - Original Message -
&
r tomee, right?
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > - Original Message -
> > > From: Romain Manni-Bucau
> > > To: dev@deltaspike.apache.org
> > > Cc:
> > > Sent: Wednesday, 25 September 2013, 21:49
> >
revents you from registering an own
> ThreadLocalTestConfigSource which you add as to your tomee, right?
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
> > From: Romain Manni-Bucau
> > To: dev@deltaspike.apache.org
> > Cc:
> > Sent: Wednes
you add as to your tomee, right?
LieGrue,
strub
- Original Message -
> From: Romain Manni-Bucau
> To: dev@deltaspike.apache.org
> Cc:
> Sent: Wednesday, 25 September 2013, 21:49
> Subject: Re: ConfigSource using ThreadLocal
>
>T he point is my webservice cli
The point is my webservice client is part of my app and then need app
config. The design cant change cause of tests. I can isolate it and mock ut
through cdi but using config source is nicer
Le 25 sept. 2013 20:39, "John D. Ament" a écrit :
> Yeah... the target path of the deployment isn't availa
Yeah... the target path of the deployment isn't available at
deployment creation. It's only available after.
When I was doing some webservice testing, i simply instantiated using
the URL param, not injection of the webservice (I honestly find
webservice injection to be a bit difficult since endpo
Ah, okay. Now I see.
On Wed, Sep 25, 2013 at 12:12 PM, Romain Manni-Bucau
wrote:
> Yep but the app doesnt know it and arquillian doesnt have it in packaging
> phase (@deployment)
> Le 25 sept. 2013 19:51, "Jason Porter" a écrit :
>
> > In that particular example, in the test, Arquillian knows t
Yep but the app doesnt know it and arquillian doesnt have it in packaging
phase (@deployment)
Le 25 sept. 2013 19:51, "Jason Porter" a écrit :
> In that particular example, in the test, Arquillian knows the URL of the
> server, so the port should already be there, right? Maybe I'm missing
> somet
In that particular example, in the test, Arquillian knows the URL of the
server, so the port should already be there, right? Maybe I'm missing
something.
On Wed, Sep 25, 2013 at 10:51 AM, Romain Manni-Bucau
wrote:
> It would be a contextual config so in the case of arquillian you'd set it
> in t
It would be a contextual config so in the case of arquillian you'd set it
in the beginning of your test method.
The point is not if it works but if we can/should support it.
typically how to configure a webservice client url when the port is random?
*Romain Manni-Bucau*
*Twitter: @rmannibucau <
Also, couldn't you deploy an application scoped config source, and set
the value (assuming you're InSequence).
Also, you don't need to use @InSequence if you use JUnit ordering Name
Ascending: https://github.com/junit-team/junit/wiki/Test-execution-order
John
On Wed, Sep 25, 2013 at 12:47 PM, Ja
I'm not sure what good a ThreadLocal is going to give you. Unless you're
using @InSequence in your tests you're not guaranteed when the tests will
run and if that ThreadLocal variable will be set. Simply having Arquillian
inject the URL should be fine. Also if depending on the forking parameter
wit
Hi,
I have the following use case: a config is dynamic (typically the url of
the server using arquillian - @ArquillianResource URL url). I need this url
in a config. In prod i use apache-deltaspike.properties or a custom
ConfigSource. I see an easy solution being a ThreadLocal (or a global Map)
ba
13 matches
Mail list logo
