Oh, I didn't know that..
Still having the debugger attached to the remote container offers some benefits:
* 4-5 seconds of AS7 startup shaved off each test run (the deployment needs to
be done anyway and this could only be helped by jsanda's modularization of the
server/jar (and I am not convinced we'd see much reduction there given the
number of inter-deps amongst our SLSBs - but I certainly hope John will prove
all of us skeptics wrong))
* No need to re-attach the debugger each time you run the test
But these are not something I'd call major...
On Wednesday, December 19, 2012 10:12:06 Jay Shaughnessy wrote:
For eclipse users we already have a test debug configuration for this
in
the drop down list. You can use -Dtest.debug and -Ditest.debug to set
breaks in the code creating the deployment, and the actual
deployment/tests, respectively.
On 12/19/2012 7:47 AM, John Mazzitelli wrote:
> -Ditest.debug will run the arquillian stuff such that you can attach a
> debugger to it over port 8798 (I think that's the port number).
>
> ----- Original Message -----
>
>> On Tuesday, December 18, 2012 14:49:04 Jay Shaughnessy wrote:
>>
>> ... snip ...
>>
>>>> 2) Use remote container instead of managed container
>>>> Arquillian handles starting and stopping a managed container
>>>> whereas
>>>> the lifecycle of a remote container is not handled by Arquillian.
>>>> I
>>>> kept my AS 7 instance running. Maybe Jay and/or Mazz have some
>>>> insights into whether or not there might be issues with using a
>>>> remote
>>>> container.
>>>
>>> Certainly using a running remote server can speed things up since
>>> it
>>> avoids that setup/teardown, although I suspect it can affect a lot
>>> of
>>> the tests as written today, given that many freely perform
>>> transaction
>>> management and interact with the entitymanager.
>>>
>>> I have nothing against doing this when it make sense. Perhaps you
>>> could
>>> give us some instructions if you have this working for certain
>>> tests.
>>>
>>> From the perspective of jenkins CI runs the managed container
>>> certainly
>>>
>>> makes sense.
>>
>>
http://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/integration-
>> tests/jndi-access/jndi-access-test/pom.xml#n152
>>
>> E.g. Jenkins does "mvn clean install" and gets the managed server.
>> You as a
>> developer do "mvn clean install -Premote-test-server" and run your
>> test on the
>> pre-started AS7 with a debugger attached. There are 2 pros to this:
>> 1) you
>> don't get the overhead of starting and stopping the full server for a
>> single
>> test run, 2) You can actually debug your test code ;)
>>
>> I tried a similar approach in itests-2 module and for some reason it
>> didn't
>> work that well - but I didn't spend too much time on it since I knew
>> we were
>> making big changes in the module and its pom at that time so I kinda
>> let it be
>> and concentrated on other things.
>>
>> But given how small those profiles are and how much utitility they
>> provide I'd
>> be very much for including something like this more "globally" in the
>> build
>> (if we manage to make it work everywhere)...
>>
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel(a)lists.fedorahosted.org
>>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel