Re: [wsrp-interop] Producer is up again

[Subbu Allamaraju <subbu@bea.com>]

Comments in line.

Regards,

Subbu

>    1. Faults are being sent in the wrong format, so we are not detecting
>       session timeouts, e.g.

That's interesting. We've several Axis test consumers, and Axis does not 
have any problem.

>    2. nativeTaskPortlet, nativeCalendarPortlet, nativeDiscussionPortlet
>       have broken relative image links such as
>       "/producer/collaboration/nativedb/todo/images/p_high.gif" that
>       haven't been output as absolute links or WSRP resource URLs.

As I've mentioned in my original posting, these portlets are fresh from 
the oven, developed by external parties, and we've already noted these 
issues. Some of these portlets also don't rewrite Javascript function 
names and ID attributes.

>    3. The 'native' portlets are also using a non-standard way of passing
>       navigational state and interaction state. They are tacking on
>       extra parameters to the template URL with the namespace prefix on
>       them, e.g.
>       "&273_35292_273_1_1compoze_collaboration_task_sort_property=1&273_35292_273_1_1compoze_collaboration_task_sort_order=1".
>       But unfortunately, our template ends with #{wsrp-fragmentID}, so
>       the extra parameters are seen as part of a 'resource locator'. I
>       don't think the spec allows you to tack on extra parameters to a
>       template. The correct way to pass these parameters is as
>       navigational state or interaction state. E.g.
>       wsrp-navigationalState=compoze_collaboration_task_sort_property%3D1%26compoze_collaboration_task_sort_order%3D1

Thanks. This is a bug.

>    4. The Redirect portlet redirects me to
>       http://portalstandards.oracle.com/index.jsp for some reason
>       (although it redirects to http://www.bea.com in our test environment)

That's interesting. What does the pbia response show?

>    5. Our portal doesn't have access to the secure resource at
>       https://wsrp.avitek.com:7002/producer/rewrite/testSecure.gif

The image exists. What response code do you get when you access this in 
your browser?

>    6. The upload portlet doesn't do anything with the files I upload to
>       it! We're passing it a single upload context with the
>       multipart/form-data mime part posted by the browser. It looks like
>       this. Admittedly we are sending a lot of extra headers, but the
>       important ones are all there.

How about Content-Disposition? The portlet is using Apache commons 
fileupload packages, and if I remember correctly, it fails to recognize 
the parts when this header is missing.

>    7. We still need a solution to the #{wsrp-fragmentID} problem!