Message Boards

text/xml is an unsupported content type

jose fernandez, modified 3 Years ago.

text/xml is an unsupported content type

New Member Posts: 13 Join Date: 3/2/20 Recent Posts
Hello all,
We have a custom portlet developed with  Primefaces 6.2 jsf 2.2 and Liferay DXP 7.1. It has been behaving without any issues until recently that we start seen on the logs the following stacktrace (the complete stacktrace is on the attachment):
java.lang.IllegalArgumentException: text/xml is an unsupported content type
        at com.liferay.portlet.internal.MimeResponseImpl.setContentType(MimeResponseImpl.java:175)
        at javax.portlet.filter.MimeResponseWrapper.setContentType(MimeResponseWrapper.java:213)
        at com.liferay.faces.bridge.context.internal.ExternalContextCompat_2_0_Impl.setResponseContentType(ExternalContextCompat_2_0_Impl.java:564)
        at javax.faces.context.ExternalContextWrapper.setResponseContentType(ExternalContextWrapper.java:809)
        at com.liferay.faces.bridge.context.internal.IncongruityContextCompatImpl.makeCongruousJSF2(IncongruityContextCompatImpl.java:340)
        at com.liferay.faces.bridge.context.internal.IncongruityContextImpl.makeCongruous(IncongruityContextImpl.java:56)
        at com.liferay.faces.bridge.internal.BridgePhaseHeaderRenderCommon.executeRender(BridgePhaseHeaderRenderCommon.java:248)
        at com.liferay.faces.bridge.internal.BridgePhaseRenderCompatImpl.execute(BridgePhaseRenderCompatImpl.java:57)
        at com.liferay.faces.bridge.internal.BridgePhaseRenderImpl.execute(BridgePhaseRenderImpl.java:57)
        at com.liferay.faces.bridge.internal.BridgeImpl.doFacesRequest(BridgeImpl.java:157)
        at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:753)
        at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:397)

Thanks for your hints.José
thumbnail
Neil Griffin, modified 3 Years ago.

RE: text/xml is an unsupported content type

Liferay Legend Posts: 2655 Join Date: 7/27/05 Recent Posts
Hi José,
I spent some time investigating the stacktrace and trying to figure out what circumstances could cause a problem like this, but I wasn't able to think of any.
When you get an opportunity, please post an SSCCE that I can build with Maven or Gradle and reproduces the problem and I'll take a closer look.

Also, what version of Liferay Portal are you using? I also need to know what versions of Liferay Faces dependencies you are using, but I hope to learn that from the pom.xml or build.grade in the SSCCE.
Kind Regards,
Neil
jose fernandez, modified 3 Years ago.

RE: text/xml is an unsupported content type

New Member Posts: 13 Join Date: 3/2/20 Recent Posts
Hi Neil,Thank you for your answer.The error is not reproduced on a simple portlet. We are not sure neither where is the origin of the error as it is happens sometimes when presenting the first view to the user, and sometimes it happens when performing a render after a render url call.For the dependencies we use:
  • com.liferay.ce.portal.bom 7.1.0
  • portlet-api 2.0
  • primefaces 6.2
  • javax.faces 2.2.20
  • javax.faces-api 2.2
  • com.liferay.faces.bridge.ext 5.0.5
  • com.liferay.faces.bridge.impl 4.1.4
We are looking for a clue to start track this issue, then probably we can collect more information or isolate the problem.Best regards.
José Fernandez
thumbnail
Neil Griffin, modified 3 Years ago.

RE: text/xml is an unsupported content type

Liferay Legend Posts: 2655 Join Date: 7/27/05 Recent Posts
Hi José,

The code that is invoking the lifecycle incongruity management is found in BridgePhaseHeaderRendererCommon.java#L243-L249. As you can see from the comments, incongruities are things that happen in the ACTION_PHASE of the portlet lifecycle that can't happen until the subsequent RENDER_PHASE is invoked. If you look at line 241 above, you will see that lifecycle incongruity management can be disabled:

via WEB-INF/web.xml:

<!-- Disable for all portlets defined in the WAR module -->
<context-param>
	<param-name>com.liferay.faces.bridge.manageIncongruities</param-name>
	<param-value>false</param-value>
</context-param>


via WEB-INF/portlet.xml:

<!-- Disable for an individual portlet -->
<init-param>
	<name>com.liferay.faces.bridge.manageIncongruities</name>
	<value>false</value>
</init-param>


So as a workaround, you can disable the feature.

But as I think through what might be causing this, I am wondering if you have request.shared.attributes=true in your portal-ext.properties file, or <private-request-attributes>false</private-request-attributes in your WEB-INF/liferay-portlet.xml descriptor? If so, that is not supported for JSF portlets. For more info, see FACES-264 and FACES-280.

Kind Regards,

Neil
jose fernandez, modified 3 Years ago.

RE: text/xml is an unsupported content type

New Member Posts: 13 Join Date: 3/2/20 Recent Posts
<p>Hi Neil,</p>

<p>&nbsp;</p>

<p>Thank you for your advise, but none of them worked. We are aware of the issues and all the jsf portlets are on the same war.</p>

<p>We are not using any action urls on the portlets</p>

<p>We observed a very strange behavior of the portlets when using&nbsp;&nbsp;&nbsp;<cite>request.shared.attributes=true in your portal-ext.properties file&nbsp; The portlets we not loading correctly. Most of the time&nbsp; Primefaces was not loaded.&nbsp;&nbsp;</cite>We&nbsp; have the<cite>&nbsp;&lt;private-request-attributes&gt;false&lt;/private-request-attributes in your WEB-INF/liferay-portlet.xml </cite>in all the portlets&nbsp;</p>

<p>&nbsp;</p>

<p>Cheers.</p>

<p>Jos&eacute;</p>
thumbnail
Neil Griffin, modified 3 Years ago.

RE: text/xml is an unsupported content type

Liferay Legend Posts: 2655 Join Date: 7/27/05 Recent Posts
Hi José,

If you have <private-request-attributes>false</private-request-attributes> in your WEB-INF/liferay-portlet.xml then that can cause problems. As I mentioned, that setting is not supported for JSF portlets. For more info, see FACES-264 and FACES-280.

Kind Regards,
Neil
jose fernandez, modified 3 Years ago.

RE: text/xml is an unsupported content type

New Member Posts: 13 Join Date: 3/2/20 Recent Posts
Hi Neil,Thanks for you reply.this is the declaration for the portlets on the liferay-portlet.xml       
&nbsp; &nbsp;<portlet-name>name</portlet-name>
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;<show-portlet-access-denied>false</show-portlet-access-denied>
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;<instanceable>false</instanceable>
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;<requires-namespaced-parameters>false</requires-namespaced-parameters>
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;<render-weight>1</render-weight>
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;<ajaxable>false</ajaxable>
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;<add-default-resource>true</add-default-resource>

We are thinking on implementing our own portlet class, but we are not sure that this would solve the problem: when we modify the "standard" setting we get other issues as the mentioned that PrimeFaces is not loaded.
We wrote a filter for the specific URL and here are the logs before the error happens:
2020-04-30 06:57:47.813 ERROR [http-nio-8080-exec-3][VppMimeTypeFilter:76] [b]Content type: application/x-www-form-urlencoded[/b]
06:57:47,853 ERROR [ExceptionHandlerBridgeImpl:78] application/xhtml+xml is an unsupported content type
java.lang.IllegalArgumentException: application/xhtml+xml is an unsupported content type

Best regards,
José
thumbnail
Neil Griffin, modified 3 Years ago.

RE: text/xml is an unsupported content type

Liferay Legend Posts: 2655 Join Date: 7/27/05 Recent Posts
Hi José,

You wrote:

We have the &lt;private-request-attributes&gt;false&lt;&#047;private-request-attributes&gt; in your WEB-INF&#047;liferay-portlet.xml in all the portlets.


But then you showed the contents of your liferay-portlet.xml descriptor as the following, which does not contain <private-request-attributes>false</private-request-attributes>:


<portlet-name>name</portlet-name>
&nbsp; &nbsp; <show-portlet-access-denied>false</show-portlet-access-denied>
&nbsp; &nbsp; <instanceable>false</instanceable>
&nbsp; &nbsp; <requires-namespaced-parameters>false</requires-namespaced-parameters>
&nbsp; &nbsp; <render-weight>1</render-weight>
&nbsp; &nbsp; <ajaxable>false</ajaxable>
&nbsp; &nbsp; <add-default-resource>true</add-default-resource>
&nbsp; &nbsp; 


So my first question would be, which is it? Is  <private-request-attributes>false</private-request-attributes> there or not?

Second, what is the specific name of the "standard" setting that causes PrimeFaces to not load?

Third, it is fine to extend GenericFacesPortlet, but what method would you override in order to solve the problem?

Kind Regards,

Neil
jose fernandez, modified 3 Years ago.

RE: text/xml is an unsupported content type

New Member Posts: 13 Join Date: 3/2/20 Recent Posts
Hi Neil,

Thank you for the reply, sorry for not being precise.
1- The text you quote is not complete and what I wanted to state is that when you use that setting [
<private-request-attributes>false</private-request-attributes> 
] on the portlet, it does not work as expected. We don't have that setting  on the portlet. The settings  we have are these that you quote on the message:
<portlet-name>name</portlet-name>
[code]&nbsp; &nbsp; <show-portlet-access-denied>false</show-portlet-access-denied>
[code]&nbsp; &nbsp; <instanceable>false</instanceable>
[code]&nbsp; &nbsp; <requires-namespaced-parameters>false</requires-namespaced-parameters>
[code]&nbsp; &nbsp; <render-weight>1</render-weight>
[code]&nbsp; &nbsp; <ajaxable>false</ajaxable>
[code]&nbsp; &nbsp; <add-default-resource>true</add-default-resource>

There are no other settings for the portlets on the liferay-portlet.xml
2- The standard entry on the portal-ext.properties, that I was referring to is:
 -
[code]request.shared.attributes=LIFERAY_SHARED_

So when changing this value to false there are problems on the portlets too. Thus we have removed  this from the portal-ext.properties file.
3- We were thinking to start with the doView, or the view method as the stacktrace prints this call on the logs:
[code] at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:753) 
The intention is not to solve the problem if not to see if we can find the origin.  As we think that must be something causing this issue. We have the same stack jsf/PF/liferay/Java on another project and we are not experiencing this problem at all.
Best regards.
José
jose fernandez, modified 3 Years ago.

RE: text/xml is an unsupported content type

New Member Posts: 13 Join Date: 3/2/20 Recent Posts
Hi Neil,
Finally the error does not appear any longer. We are not sure why  we cannot  reproduce it anymore.  However the "solution" was:There is an Abstract controller that holds a flag with the status of the process (view, edit, ad so on) The transition from view to edit was done on this abstract class. The error has disappear when the call to make the transition from view to edit was moved to the controller declared  as the managed bean for the view. We are totally lost  on this, as the same code that was on the parent abstract class is now on the managed bean. Also there other portlets using the same abstract class, but those portlets are not on the same page. If you know  what may the origin be, it would be great if  you share it with us. Thank you for your help Neil.José
thumbnail
Neil Griffin, modified 3 Years ago.

RE: text/xml is an unsupported content type

Liferay Legend Posts: 2655 Join Date: 7/27/05 Recent Posts
Hi José,
Thank you for replying -- I am not sure why moving the code from the abstract class to the managed bean would fix the problem. Another thing I am curious about, is why setting com.liferay.faces.bridge.manageIncongruities=false did not fix the problem.

But regardless, I am glad to learn that the problem no longer appears.
Kind Regards,
Neil