10:39 a.m.
WSRP - Markup String / Binary handling - fail correctly
-------------------------------------------------------
Key: JBPORTAL-1784
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1784
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal WSRP
Affects Versions: 2.6.2 Final
Environment: Oracle OC4J 10.1.3.3.0, Jboss 2.6.2
Reporter: Dave Rowe
Assigned To: Chris Laprun
When JBoss checks the Markup response, it only checks if the byte array is not null. It
needs an additional check to validate that the length is greater than zero.
This is in org.jboss.portal.wsrp.consumer.RenderHandler (line 102, as of rev. 7792). Add
in an additional check that binary.length > 0.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3 p.m.
New subject: [JBoss JIRA] Resolved: (JBPORTAL-1784) WSRP - Markup String / Binary handling - fail correctly
[ http://jira.jboss.com/jira/browse/JBPORTAL-1784?page=all ]
Chris Laprun resolved JBPORTAL-1784.
------------------------------------
Resolution: Won't Fix
As per the specification, section 6.1.10, it is a producer error to sent both a markup
string and markup binary, as markupString and markupBinary are mutually exclusive. Empty
contents are semantically different from null content. I consider the current behavior
proper on the JBoss Portal side, and a defect of Oracle's WSRP producer. Please file
an appropriate bug report with them if you have a support contract.
WSRP - Markup String / Binary handling - fail correctly
-------------------------------------------------------
Key: JBPORTAL-1784
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1784
Project: JBoss Portal
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Portal WSRP
Affects Versions: 2.6.2 Final
Environment: Oracle OC4J 10.1.3.3.0, Jboss 2.6.2
Reporter: Dave Rowe
Assigned To: Chris Laprun
When JBoss checks the Markup response, it only checks if the byte array is not null. It
needs an additional check to validate that the length is greater than zero.
This is in org.jboss.portal.wsrp.consumer.RenderHandler (line 102, as of rev. 7792). Add
in an additional check that binary.length > 0.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:19 p.m.
New subject: [JBoss JIRA] Commented: (JBPORTAL-1784) WSRP - Markup String / Binary handling - fail correctly
[ http://jira.jboss.com/jira/browse/JBPORTAL-1784?page=comments#action_1238... ]
Dave Rowe commented on JBPORTAL-1784:
-------------------------------------
Hi Chris. While I agree with you that the specification states the two fields are
mutually exclusive, I would say the specification still allows for the existence of the
field with empty content. The only time the specification states the field should not
exist at all is in the case where 'useCachedMarkup' is 'true'. Otherwise,
I would interpret the spec to allow for the field to exist with empty content. This is
why I suggest the zero length check. The specification doesn't state the fields
themselves are mutually exclusive, only that the markupString field is "mutually
exclusive with the returning of the markup of the markupBinary field".
in summary, I would say it's a producer error to send a _value_ for both markupString
and markupBinary.
WSRP - Markup String / Binary handling - fail correctly
-------------------------------------------------------
Key: JBPORTAL-1784
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1784
Project: JBoss Portal
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Portal WSRP
Affects Versions: 2.6.2 Final
Environment: Oracle OC4J 10.1.3.3.0, Jboss 2.6.2
Reporter: Dave Rowe
Assigned To: Chris Laprun
When JBoss checks the Markup response, it only checks if the byte array is not null. It
needs an additional check to validate that the length is greater than zero.
This is in org.jboss.portal.wsrp.consumer.RenderHandler (line 102, as of rev. 7792). Add
in an additional check that binary.length > 0.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:25 p.m.
New subject: [JBoss JIRA] Commented: (JBPORTAL-1784) WSRP - Markup String / Binary handling - fail correctly
[ http://jira.jboss.com/jira/browse/JBPORTAL-1784?page=comments#action_1238... ]
Chris Laprun commented on JBPORTAL-1784:
----------------------------------------
But an empty value IS a value... as opposed to null which is not. Depending on the
portlet, an empty value could be meaningful, whereas null always means absence of value.
The specification is once again rather vague... but I think that the current strict
interpretation is correct and that Oracle's producer should be fixed.
WSRP - Markup String / Binary handling - fail correctly
-------------------------------------------------------
Key: JBPORTAL-1784
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1784
Project: JBoss Portal
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Portal WSRP
Affects Versions: 2.6.2 Final
Environment: Oracle OC4J 10.1.3.3.0, Jboss 2.6.2
Reporter: Dave Rowe
Assigned To: Chris Laprun
When JBoss checks the Markup response, it only checks if the byte array is not null. It
needs an additional check to validate that the length is greater than zero.
This is in org.jboss.portal.wsrp.consumer.RenderHandler (line 102, as of rev. 7792). Add
in an additional check that binary.length > 0.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6262
days inactive
6262
days old
3 comments
2 participants
participants (2)
-
Chris Laprun (JIRA) -
Dave Rowe (JIRA)