Confluence 6 throws XStream error when Bandana is used in Add-On?

[Felix Grund (Scandio)]

Hi,

I'm not sure if this is the correct place for this. I think this is actually an issue with Confluence 6 that makes it impossible for add-on developers to use XStream/Bandana without setting a specific system property.

I just installed Confluence 6 and tested my own add-on with it that makes use of Bandana. When I try to save an object to Bandana, I get this exception:

2016-09-21 14:56:24,833 ERROR [http-nio-8090-exec-10] [atlassian.confluence.servlet.ConfluenceServletDispatcher] sendError Could not execute action
 -- referer: http://localhost:8090/myaddon/myaction.action | url: /myaddon/myaction.action | traceId: 5a4d5e742ef20be1 | userName: admin
com.thoughtworks.xstream.converters.ConversionException: XStream error: Class mypackage.MyObject has not been whitelisted
---- Debugging information ----
-------------------------------
    at com.atlassian.confluence.setup.xstream.XStreamSecurityClassFilter.canConvert(XStreamSecurityClassFilter.java:93)
    at com.thoughtworks.xstream.core.DefaultConverterLookup.lookupConverterForType(DefaultConverterLookup.java:44)
    at com.thoughtworks.xstream.core.ReferenceByXPathMarshaller.convertAnother(ReferenceByXPathMarshaller.java:23)
    at com.thoughtworks.xstream.core.TreeMarshaller.start(TreeMarshaller.java:46)
    at com.thoughtworks.xstream.core.ReferenceByXPathMarshallingStrategy.marshal(ReferenceByXPathMarshallingStrategy.java:17)
    at com.thoughtworks.xstream.XStream.marshal(XStream.java:489)
    at com.thoughtworks.xstream.XStream.marshal(XStream.java:479)
...

I researched for a bit and found that the class XStreamSecurityClassFilter is instantiated by default in Confluence 6 which it wasn't in Confluence 5. See com.atlassian.confluence.setup.xstream.XStreamManager:

Confluence 5.x:

if (Boolean.getBoolean("xstream.whitelist.enable")) {
    xstream.registerConverter(new XStreamSecurityClassFilter(), Integer.MAX_VALUE);
}

Confluence 6.x:

if (Boolean.parseBoolean(System.getProperty("xstream.whitelist.enable", "true"))) {
    xstream.registerConverter(new XStreamSecurityClassFilter(), Integer.MAX_VALUE);
}

It works for me if I set one of these flags in setenv.sh:

• -Dxstream.whitelist.enable=false
• -Dxstream.whitelist.extra=mypackage.

In XStreamSecurityClassFilter I found this code:

private final static Set<String> ALLOWED_PACKAGES = ImmutableSet.of(
        "com.atlassian.confluence.",
        "java.util.concurrent.atomic.",
        // Used by the Inbound Email plugin's ReceivedEmail class,
        "javax.mail.internet.InternetAddress",
        // Cloud 3rd party P2 plugins
        "com.gliffy.plugin.confluence.",
        "com.balsamiq.mockups.",
        "com.adaptavist.confluence.",
        "org.swift.confluence."
);

If I'm correct, this allows explicitly only allows a few add-on vendors to use Bandana/XStream without explicitly setting a system property. This can't be intended?!

I'd be very happy if some Atlassian investigated in this issue.

Regards, Felix (Scandio)

[Remo Siegwart]

I've already reported this here: https://jira.atlassian.com/browse/CONF-43832

Also I've found the following workaround: You can define your own BandanaContext and implement the BandanaSerializerFactory interface. Then you can override the serialize/deserialize methods by using a custom XStream instance:

...
// init custom xstream instance
final XStream xStream = new XStream();
xStream.setClassLoader(getClass().getClassLoader());
...
// define custom bandana context
public class CustomBandanaContext extends ConfluenceBandanaContext implements BandanaSerializerFactory {
    @Override
    public BandanaSerializer getSerializer() {
        return new BandanaSerializer() {
            @Override
            public void serialize(Object obj, Writer writer) throws IOException {
                xStream.toXML(obj, writer);
            }
            @Override
            public Object deserialize(Reader reader) throws IOException {
                return xStream.fromXML(reader);
            }
        };
    }
}
...
// use custom bandana context to prevent conversion exception
(CustomJavaObject) bandanaManager.getValue(new CustomBandanaContext(), <bandana-key>);
...

Hope this helps

Cheers
Remo

[Tim]

This happens also for the just released Confluence 5.10.6 Version. Worked fine with 5.10.5, now all addons using Bandana are throwing the ConversionException. So I guess I am wating for 5.10.7...

[Felix Grund (Scandio)]

Yes, the error is only thrown for custom objects.

[Manuel Kummerländer]

We test our plugins as well and didn't get this error on Confluence 6 beta-3 so far (our packages are not whitelisted ). However, we didn't test the saving of full custom objects but just Strings:

bandanaManager.setValue(customBandanaContext, BANDANA_KEY, value);

This works fine.

Regards
Manuel 

[Aron Gombas _Midori_]

Felix, is this a strong requirement to use Bandana in your use case?

We have an add-on started years ago, when there was nothing else available, therefore relying on Bandana, but we are completely moving away from Bandana toward ActiveObjects. AO is fairly simple to use, comes with migration and other features, and is cluster-safe.

[Felix Grund (Scandio)]

Hi Aron! Thanks for getting in touch. I have developed several add-ons using ActiveObjects myself and I can clearly see cases where I'd prefer a simple key-value store like Bandana. We have several add-ons that save custom objects using Bandana and I assume there are many other add-on vendors who do so. Should all add-ons now be migrated to ActiveObjects? I don't think so. Bandana proved very stable and reliable over the years. Also, I couldn't find any resources by Atlassian that predicted deprecation of Bandana or anything similar. In contrary, I believe there was a time when Atlassian predicted deprecation of ActiveObjects which was rejected later on.

[Aron Gombas _Midori_]

Felix, besides being unstructured key-value entries (which may be an advantage), my biggest problem is that Bandana is auto-replicated in a Confluence Data Center setup. Or... is it?