Christian,
I just found out, that adding <protocol type="Servlet 3.0" /> to the
<container> element in arquillian.xml only configures (does not select)
an already selected protocol. If no protocol is selected using
<defaultProtocol>, then the container's default is used. And the default
for AS7 is, sadly, "jmx-as7", which is intended for internal testing of
the container and makes tests unstable.
What could be done, is to create arquillian-owb.xml in test-utils, and
add <arquillian.xml>arquillian-owb.xml</arquillian.xml> to the
<systemProperties> in OWB profile. Or the other way around for JBoss.
Ron
On 3.2.2014 17:23, Christian Kaltepoth wrote:
@Ron
I just tried that. The result is this:
java.lang.IllegalArgumentException: No
org.jboss.arquillian.container.spi.client.protocol.metadata.HTTPContext
found in
org.jboss.arquillian.container.spi.client.protocol.metadata.ProtocolMetaData.
Servlet protocol can not be used
at
org.jboss.arquillian.protocol.servlet.BaseServletProtocol.getExecutor(BaseServletProtocol.java:64)
at
org.jboss.arquillian.protocol.servlet.BaseServletProtocol.getExecutor(BaseServletProtocol.java:35)
at
org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.getContainerMethodExecutor(RemoteTestExecuter.java:136)
at
org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:119)
What if we just add *<protocol type="Servlet 3.0" />* to all the AS7 and
Wildfly profiles? Wouldn't this fix all our problems?
Christian
2014-02-03 Ron Smeral <[email protected]>:
Hi Christian,
the reason for this could be, that in parent/code/pom.xml, the
'org.jboss.arquillian.protocol:arquillian-protocol-servlet' dependency is
not declared for any non-JBoss profile (OWB, tomee, glassfish, ..).
Could you try it with the dependency declared?
Ron
On 3.2.2014 10:51, Christian Kaltepoth wrote:
@gerhard:
I was getting this when running the build:
Caused by: java.lang.IllegalStateException: Defined default protocol
Servlet 3.0 can not be found on classpath
at
org.jboss.arquillian.container.test.impl.client.protocol.
ProtocolRegistryCreator.createRegistry(ProtocolRegistryCreator.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(
EventContextImpl.java:99)
The weird thing is that Maven simply doesn't run the tests in this case
which leads to a successful build.
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
Full log of running "mvn clean -POWB -Dowb.version=1.1.8" on core-impl
with
the default protocol entry:
http://pastebin.com/raw.php?i=1hk9nxmZ
Christian
2014-02-02 Gerhard Petracek <[email protected]>:
@christian:
locally i've tested the owb-, weld- and some build-managed-profiles with
the defaultProtocol you removed and everything is working on my machine.
-> please provide further details.
regards,
gerhard
2014-02-01 Christian Kaltepoth <[email protected]>:
@Ron & @Jason
The defaultProtocol was only used in a single arquillian.xml file of the
8
different ones we had before. I had to remove it because the plain Weld
+
OWB integration tests started to fail with it (at least for me) for some
reason.
Christian
2014-01-31 Jason Porter <[email protected]>:
The JMX protocol for Wildfly / AS is horrible and for any sort of
application or framework the servlet adaptor should be used. Yes, it's
a
little slower, but it will give you the full environment you're used to
using when you develop.
On Fri, Jan 31, 2014 at 1:59 PM, Ron Smeral <[email protected]>
wrote:
Hi Christian,
I see you recently removed defaultProtocol from arquillian.xml. Is
there
any reason not to have it there? The now default JMX protocol seems
to
be
causing test stability issues, I can't succesfully run for example
the
Data
module tests. I'm not sure why this happens. Have you maybe
encountered
this too?
Also, just FYI, we now have a job 'DeltaSpike-wildfly-daily' at
hudson.jboss.org which tests the wildfly-build-managed profile. It
will
be sending mails to commits@deltaspike.
Ron
On 25.1.2014 08:36, Christian Kaltepoth wrote:
Hey Gerhard,
yeah, I wasn't aware that the Glassfish jobs have already been
added.
But
Wildfly is still missing.
Christian
2014/1/24 Gerhard Petracek <[email protected]>
hi christian,
the jenkins-jobs should be in place already.
regards,
gerhard
2014/1/24 Christian Kaltepoth <[email protected]>
Hey all,
I pushed out all the changes of the "build-managed" integration
test
Maven
profiles which I suggested.
You can now run the integration test suite against the different
containers
like this:
$ mvn clean install -Ptomee-build-managed
$ mvn clean install -Pjbossas-build-managed-7
$ mvn clean install -Pwildfly-build-managed
$ mvn clean install -Pglassfish-build-managed-3
$ mvn clean install -Pglassfish-build-managed-4
Each profiles will automatically download, unpack and configure
the
corresponding container. All TCP ports are changed so that they
differ
from
this default ones. This way we should be able to run them on the
CI
server
without any problems.
Could anyone with the required permissions add corresponding jobs
in
Jenkins?
Christian
2014/1/11 Christian Kaltepoth <[email protected]>
Hey Ron,
yeah, I also thought about using "user.dir", but this could point
to
some
weird locations depending on from where you start the build. So
let's
go
with "java.io.tmpdir" for now.
Christian
2014/1/8 Ron Smeral <[email protected]>
Hey Christian,
you're right, I haven't realized that. Also, if some module
needed a
custom arquillian conf, Arquillian reads a system property named
"arquillian.xml" which defines the name of the configuration
file.
The last thing I can think of for the testsuite root is the
Maven
property "user.dir" - the working directory from which mvn was
executed.
Ron
On 7.1.2014 17:20, Christian Kaltepoth wrote:
Hey Ron,
I don't think unpacking is necessary. If arquillian.xml is
located
in
deltaspike/test-utils/src/main/resources, it will be on the
classpath
for
all integration tests. That's basically the setup we are using
for
Rewrite
since quite some time and it is working fine. See [1].
I guess you are right regarding the merging of poms and that
${basedir}
won't work because of this. Too bad. So perhaps we should use
java.io.tmpdir for now until we find a better way (if there is
any).
Christian
[1]
https://github.com/ocpsoft/rewrite/blob/master/test-
harness/src/main/resources/arquillian.xml
2014/1/7 Ron Smeral <[email protected]>
Hi Christian,
the test-utils is in the parent/code/pom.xml as a dependency,
but
then
still, to get to the arquillian.xml file in the test-utils.jar,
it
would
need to be unpacked using e.g. dependency:unpack plugin goal.
Regarding basedir, because POMs are merged in Maven to form
the
Effective
POM, the basedir property always points to the current
project,
regardless
of the POM in which you reference it.
For example, if -- as you suggest -- there's project P and C,
where
P
is
parent of C, and P contains <root>${basedir}</root>, then for C,
the
${root} will contain the base dir of C anyway, not that of P.
The least hacky (but still ugly) way that comes to mind is to
pass
the
property an absolute path from the shell, as in "mvn clean test
-Droot=$(pwd)". The root property could have a default value
of
${java.io.tmpdir}.
Ron
On 7.1.2014 07:51, Christian Kaltepoth wrote:
Hey Ron,
I don't think we will have to copy arquillian.xml using the
resources-plugin. If we add it to src/main/resources of the
test-utils
module, it will be on the test classpath for all other
modules.
I
think
this should work fine.
Regarding the testsuite root directory. I think we could use
Maven's
${basedir} in the parent pom and store it in a system
property.
Thoughts?
Christian
2014/1/3 Ron Smeral <[email protected]>
Hi Christian,
looking at the arquillian.xml files, they are 99% the same,
the
only
one
that actually differs (other than whitespace, comments and
missing
cdicontainer.version property) is the one in the data
module,
containing
a
testDatabase configuration for tomee. So, we could have just
one
arquillian.xml file somewhere in the testsuite root, copy it
over
using
resources-plugin, and override it only when necessary.
One minor problem is -- and this is for the container
unpacking
too
--
that to point to the testsuite root, every pom would need to
keep
a
relative reference to it (e.g. <testsuite.root>../../..</
testsuite.root>),
which is ugly, but doable.
On 3.1.2014 06:26, Christian Kaltepoth wrote:
Hey Ron,
yeah, there are differences between arquillian.xml files.
But
why?
I
don't
see any reason for having different arquillian.xml files
between
modules.
Actually the integration test Maven profiles are also
located
in
a
single
parent pom and not in each individual module pom. IMHO we
should
treat
arquillian.xml the same way. Unless there is a good reason
for
having
multiple ones.
I agree that we should unpack the container only once. I'm
not
sure I
like
to use java.io.tmpdir though. It would be nice to have it
in
the
top-level
"target" directory or something like that. That would
ensure
that
running
"mvn clean" would also remove the unpacked container.
Christian
2014/1/2 Ron Smeral <[email protected]>
On 2.1.2014 17:55, Christian Kaltepoth wrote:
Hey all,
there are two things I would like to address regarding
our
integration
test
suite.
1. Currently each module has its own arquillian.xml file.
IMHO
this
doesn't
make sense. What about using a single arquillian.xml and
placing
it in
the
test-utils module?
+0, there are minor differences among them currently
(though
not
sure
if
necessary), and it would make it more difficult to make
an
individual
modification if there was single arquillian.xml.
2. We have both "managed" and "remote" profiles for
some
containers.
But
the "managed" profiles (especially Wildfly + Glassfish)
require
you to
manually download and setup the corresponding container
which I
would
like
to avoid. I think it would be nicer if the "managed"
profiles
could do
this
automatically. This would simplify the process of running
the
tests
locally
before committing and it would also be easier to create
CI
jobs
for
them.
See [1] for an example of a profile which sets up the
container
automatically and therefore runs out of the box even in
transient
CI
environments like Travis [2].
There already is such profile at least for JBoss AS7
(jbossas-build-managed-7) and at this very moment I'm
adding
such
profile
for WildFly. However, currently there is a minor drawback
to
the
current
approach -- the container is unpacked for every module and
so
almost 5
GB
of diskspace is required to run the whole testsuite, which
is
quite
impractical. It would be nice to have the container
unpacked to
a
shared
location, e.g. ${java.io.tmpdir}, just as in the ocpsoft
rewrite
pom
you
linked. I'll try that in the AS7 and WF8 profiles.
Thoughts?
[1]
https://github.com/ocpsoft/rewrite/blob/master/pom.xml#
L706
[2] https://travis-ci.org/ocpsoft/rewrite/builds/16192940
Christian
--
Ron Smeral
JBoss Quality Engineer
Brno
--
Ron Smeral
JBoss Quality Engineer
Brno
--
Ron Smeral
JBoss Quality Engineer
Brno
--
Ron Smeral
JBoss Quality Engineer
Brno
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
--
Ron Smeral
JBoss Quality Engineer
Brno
--
Jason Porter
http://en.gravatar.com/lightguardjp
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
--
Ron Smeral
JBoss Quality Engineer
Brno
--
Ron Smeral
JBoss Quality Engineer
Brno
