Skip to content

Development Gotchas

Jump to bottom
Frantisek Kobzik edited this page Mar 3, 2021 · 3 revisions

"Elaborator NOT BOUND!.." appears in logs

Probably you are using ElaboratorDecorator in your JSP and forgot to call ListHelper.execute().

If you did, then check the return type of your Listable.getResult() method. If it is not a DataResult<T>, for example if it is ArrayList<T>, then ListHelper.execute() will happily skip elaborator binding.

Note that this could possibly NOT show up unless you clear your cookies before logging in! Reason is that bindings get saved in your user session, so you might not notice that they fail for a while.

So when writing code, either return DataResult<T> from Listable.getResult() or avoid ElaboratorDecorator altogether (when that makes sense).

When testing, also try clearing your cookies.

How do I see HTTPs (SSL) traffic for debug reasons?

If you are using Java net's HttpURLConnection, you are in luck!

sudo echo "sun.net.www.protocol.http.HttpURLConnection.level = ALL" >> /usr/share/tomcat6/conf/logging.properties

More information here:

http://www.rgagnon.com/javadetails/java-debug-HttpURLConnection-problem.html

Hibernate gotchas

  1. when you have a one-to-many relationship between classes and you need to disassociate two objects, you don't necessarily need to "cut both sides". Either nullifying the reference from the child object or removing it from the parent's collection is sufficient. That does not change even if the inverse attribute is set in the mapping.
  2. in a one-to-many relationship between classes, if the lifecycle of the child is limited to the parent's (meaning, the child ceases to exist when detached from its parent and thus it should be automatically deleted by Hibernate once the association vanishes) we should use the delete-orphan mapping attribute. This will automatically kill any child which loses the relationship with its parent, as is the case here (see delete-orphan in the reference)
  3. if an object has a Hibernate-mapped collection, you should not swap out the collection itself, because the implementation will not be Hibernate-aware. Use the collection methods instead.

Troubleshooting Github actions interactively

Github actions are run non-interactively, which makes their troubleshooting harder. You typically change the code, push the change, watch it fail, read the logs, rinse and repeat.

What could be useful in your situation, is to spin the tmate console (full info). TL;DR, just add this to your steps (this one is adding the Setup tmate session just after the checkout action, which is most likely already present in your automation file):

    - uses: actions/checkout@v2
    - name: Setup tmate session
      uses: mxschmitt/action-tmate@v3

After the action is run, you can check its log in Github to get the ssh command for connecting to the console.

The action will not proceed with the succeeding steps.

When you're done with the work, just run touch continue or sudo touch /continue in the console and the action will continue.

Running docker containers

Alternatively, you can spin a custom docker container with SSH server and connect to it:

https://github.com/srbarrios/cucumber-ruby-skeleton/packages/218498

https://github.com/srbarrios/cucumber-ruby-skeleton/packages/232698

Clone this wiki locally