Confluence Plugin Development – Troubleshooting

Posted by admin on May 3rd, 2014 filed in Development, Java, Wiki

When I develop a Java project, I rely heavily on IDE tools for refactoring, syntactic and semantic highlighting, debgugging, profiling… I also clean, build, and run the app often to test workflows and spot whether a change broke something.

When I develop Confluence Plugins however, I have the added factor of rebuilding and installing the plugin into the confluence server. Even worse, IDEs won’t recognize the Confluence project structure and won’t know how to refactor it. So you are facing weird plugin behaviour that doesn’t go away by pressing F5 really hard. What happened?

Maybe FastDev did not reload the plugin – maybe you didn’t save one of the files before rebuilding – maybe you used a wrong key – maybe you never truly told the project to link that Javascript or SOY file – maybe you made a typo in the POM – maybe your IDE “helpfully” modified the POM behind your back… What ever the problem is, the Confluence log output is not very explicit about the source of the issue.

Here’s some generic tips for troubleshooting Confluence Plugin development:

  • Use you Atlassian ID to search, and ask and search questions on https://answers.atlassian.com/
  • Browse a search documentation on https://support.atlassian.com/customer/home
  • If you notice a large jump in disk usage in the target directory, or if atlas-run or atlas-package suddenly take, say, half an hour instead of 2 mins, something is awry.
    For example, for the main Confluence dependency in your POM.xml, the scope must be “provided”, because Confluence is provided in the SDK. No need to download it every time! Your IDE might mess with this setting, so keep an eye on it.

    <dependency>
        <groupId>com.atlassian.confluence</groupId>
        <artifactId>confluence</artifactId>
        <version>${confluence.version}</version>
        <scope>provided</scope>
    </dependency>
  • Do not use the standard Java logger (nor println…) for debug output. If you do, the output doesn’t go anywhere. Use the slf4j logger instead (as shown in the Confluence skeleton code), slf4j routes the output into the terminal and log files.
    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;
    ...
      private static final Logger LOGGER = LoggerFactory.getLogger(MyJavaClass.class);
      LOGGER.error("I haz a problem", e);
  • Find logs for the Confluence main installation here:
    C:\Program Files\Atlassian\Confluence\logs
    C:\Program Files\Atlassian\Application Data\Confluence\logs
  • Find logs for your plugin’s temporary Confluence instance here (…not useful?):
    C:\Users\YOURHOME\Documents\AtlassianProjects\kbarticle\target\container\tomcat6x\cargo-confluence-home\logs 
    C:\Users\YOURHOME\Documents\AtlassianProjects\kbarticle\target\container\tomcat6x\apache-tomcat-6.0.20\logs
    
  • You can create a remote debug target in most IDEs so you can debug Confluence. — I haven’t tried that yet, but I’ll report back how it went. :)

I’ll add more tips as I discover them.

Comments are closed.