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)
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,
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
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
rmannibu...@gmail.comwrote:
It would be a contextual config so in the case of
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
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 john.d.am...@gmail.com a écrit :
Yeah... the target path of the
I think a ThreadLocal ConfigSource is kind of an anti-pattern.
Even in your case it looks like this only would work if you start the container
inplace. But it will not work with remote containers.
But there is nothing which prevents you from registering an own
ThreadLocalTestConfigSource which
I was looking for something more portable, in tomee my test passes as you
can guess ;)
But ok, you join my thought: this case shows a limitation of
arquillian...that said not sure why url can be passed as @deployment
parameter, it should work in the arq lifecycle imo
Le 26 sept. 2013 06:58, Mark
