How to debug Arquillian persistence activity

[johann.schweigl]

Hi,

is there any way to see the SQL executed by e.g. @UsingDataSet-annotated tests or get any other kind of insight into failed persistence tests? I couldn't find any configuration parameters to achieve that.

My problem is that I often get NPEs from test runs which are caused by some data type or constraint violation in the test data sets, but the stack trace never gives a hint about the root cause.

And, btw, I never got @ApplyScript[Before|After] to perform anything but throwing a NPE, also without any hint what could have happened.

I'm using Arquillian 1.1.5 with persistence extension 1.0.0.Alpha7 in JBoss EAP 6.1.1.

Best regards

Johann

[nicoschl]

Hi Johan,

I agree, DBUnit doesn't provide anything useful in their exceptions.

How are you configuring DBUnit in your arquillian.xml?

If you have it like mine below configured via a datasource, then the you can enable SQL logging in your persistence.xml

<extension qualifier="persistence">
  <property name="defaultDataSource">java:jboss/datasources/PostgresLocalXADS</property>
  <!-- your other settings -->
</extension>

Add the following two properties to your persistence.xml that you include in your deployment. I used it this way to see the sql that is run, but I can't remember now whether it was showing the parameter bind values or not.

<property name="hibernate.show_sql" value="false" />
<property name="hibernate.format_sql" value="true" />

If that doesn't give you what you need, maybe also try to enable DEBUG logging for DBUnit. In your standalone.xml file add these lines to the logging subsystem:

<logger category="org.dbunit">
  <level name="DEBUG"/>
</logger>

And you can always redirect the logging to a separate file if you don't want it in your server.log file.

Hope this helps

Nico

[johann.schweigl]

Nico,

thanks a lot and please excuse my late reply. I already had the first two settings in place, but the dbunit logger was not on DEBUG level.  This was quite interesting: it pointed me to the cause of anoter NPE (having not explicitly specified a schema, strange tables were processed during test Startup and caused dbunit to throw up), but it does not give a hint in case of constraint violations when loading data sets.

However, a problem has been solved.

Best regards

Johann

[bmajsak]

Hi guys,

If you have some certain ideas what you would like to have logged from APE on top of DBUnit please file a feature request in our JIRA so I can work on that in the nearest future.

Cheers,

Bartosz

[nicoschl]

Hi Bartosz,

I don't know DBUnit at all and I'm not sure what information they expose via Exceptions. The one thing that comes to mind is the underlying SQLExceptions. If you can get hold of those, it would be helpful. Is is possible for you to get hold of the underlying SQLExceptions? I don't want to log an issue in JIRA if you can't get the information.

Thanks

Nico

[bmajsak]

I will have a look at it and see what can be enhanced from APE perspective.

[kwintesencja]

i think it has something to do with transactions, cause if i disable transaction in my test i can se the real cause:

    @Test
    @UsingDataSet("conference.yml")
    @Cleanup(phase=TestExecutionPhase.BEFORE)
    @Transactional(value=TransactionMode.DISABLED)
    public void shouldFailToInsertConferenceWithDuplicateName(){}

maybe it helps