Error(decomporess GZip,Base 64 decoding) when getting DCP on DD4T Java version2

Question

On DD4T Java version2, following error occured when getting DCP by getComponentPresentation method(org.dd4t.core.factories.ComponentPresentationFactory). It is related to BaseBrokerProvider class.

2015-07-13 06:16:51,843 ERROR CompressionUtils - Decompression failed.
java.util.zip.ZipException: Not in GZIP format

So on dispatcher-servlet.xml, I changed property "contentIsCompressed" to false, then another error occured.

2015-07-13 06:31:54,594 ERROR JsonDataBinder - com.fasterxml.jackson.core.JsonParseException: Illegal character ((CTRL-CHAR, code 31)): only regular white space (\r, \n, \t) is allowed between tokens
at [Source: �\x00\x00\x00\x00\x00\x00�S�j�0��F�K�ؽ��M�$&-�>h�ɮRYZlm�!~��

According to the message, JSON seems to be corrupted.So I modify source code of BaseBrokerProvider class, not to do Base 64 decoding.

protected boolean contentIsBase64Encoded = true;

    public void setContentIsBase64Encoded(final String contentIsBase64Encoded) {
        this.contentIsBase64Encoded = Boolean.parseBoolean(contentIsBase64Encoded);
    }

And I modified dispatcher-servlet.xml like following.

<bean id="componentPresentationProvider" scope="singleton" class="org.dd4t.providers.impl.BrokerComponentPresentationProvider">
    <property name="contentIsCompressed" value="false" />
    <property name="contentIsBase64Encoded" value="false" />
    <property name="concreteComponentPresentation" value="org.dd4t.contentmodel.impl.ComponentPresentationImpl" />
    <property name="concreteComponentTemplateImpl" value="org.dd4t.contentmodel.impl.ComponentTemplateImpl" />
</bean>

Finally, error disappered.

My questions are following.

1. What kind of case should I decomporess GZip(set "contentIsCompressed" true).
2. Is there any problem caused by disabling Base 64 decoding?

Regards,

UPDATE

Following configuration and modification of DD4T's source code are required.

• Add TBB "Compress Output" to PT and set "true" to bean pageProvider's contentIsCompressed property in dispatcher-servlet.xml(it's on Java Web application)
• Add TBB "Compress Output" to dynamic CT and set "true" to bean componentPresentationProvider's contentIsCompressed property in dispatcher-servlet.xml.
• Modify source code of org.dd4t.core.util.CompressionUtils, decompressGZip method like following. Otherwise, multibyte characters are corrupted.

Original:

result = (String) IOUtils.toString(gis);

Modified:

result = (String) IOUtils.toString(gis,"UTF-8");

Answer 1

Check the settings in your DD4T templates. Whatever you set there as 'BASE64 encoding' or 'GZIP compression' must of course match your DD4T 'dispatch-servlet.xml' definitions.

My guess is that you didn't enable 'BASE64 encoding' or 'GZIP compression' in your DD4T templates in Tridion, but you are attempting to decode/decompress them in DD4T web-app.

Also worth checking that you are indeed publishing JSon and not XML --- again, check your DD4T templates in Template Builder.

I would suggest you disable BASE64 and GZIP in the first place in your templates. Do the same in your DD4T web-app, just so you get a working setup. Then re-enable them one by one.

Also please remember to publish your Pages & Component Presentations again after you made changes to the templates.

== EDIT ==

DD4T models tend to become quite big if you have many CPs on a page, if you have large metadata fields or if your linking levels are set high (greater than 3 for example). XML tends to be extra-verbose, but JSON can become large as well.

In such cases it makes sense to enable GZIP compression on the models. This will reduce their size drastically... up to 95% gain, so your CD DB will be less and your 'trafficked' bytes will be less. You don't have to do this, but it's an improvement point. I heard of Page models in XML format of 2MB size!

You can also enabled BASE64 encoding on the GZIPped model so that it still looks like a string, and not like a binary stream. Otherwise, you might run into trouble trying to store and traffic binary data as ASCII strings.