Re: [wsrp-interop] Producer is up again

[Subbu Allamaraju <subbu@bea.com>]

1. Fault handling: I tested fault deserialization with JAX-RPC RI today, 
and the reason it was not able to raise a typed fault is because it was 
expecting a fault child element in the detail. I updated our producer to 
include the fault in the detail, and JAX-RPC should now be able to raise 
the expected fault. I verified this with a test JAX-RPC client.

However, since the detail element itself is optional, our consumer 
checks the faultcode in case the stack is unable to raise an exception.

2. Resource over SSL: We had similar problems with one of test clients 
trying to access a resource over SSL. It turned out that the default 
HostnameVerifier was rejecting the demo certificate deployed on the 
producer, and we ended up setting a dummy HostnameVerifier on the 
connection. This could possibly explain the response you noticed. Could 
you verify this?

3. Upload: Our producer does not yet support multiple parts packed into 
a single UploadContext. Currently, it only supports one UploadContext 
per part. This is in our TODO list.

Regards,

Subbu

David Ward wrote:
> 
> 
> Subbu Allamaraju wrote:
> 
>> 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. 
> 
> But I'm telling you the JAX-RPC RI does (as it recognizes faults by the 
> detail element), and it's clear you are generating the detail element in 
> a non-standard format! In the interests of interoperability, it would 
> help if you only had a single detail element. That way we can recognize 
> your faults. I don't feel like hacking JAX-RPC any further!
> 
>>
>>
>>>    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? 
> 
> I know it exists but it is currently protected.  I get the "Forbidden" 
> response code.
> 
>>
>>
>>>    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. 
> 
> There are Content-Disposition headers on each mime part within the 
> multipart message. You  have to parse the multipart message to get them. 
> We have a sample portlet (not available on line) that can handle this 
> request without any problems.
> 
>>
>>
>>>    7. We still need a solution to the #{wsrp-fragmentID} problem!
>>
>>
>>
>>
>>
>> To unsubscribe from this mailing list (and be removed from the roster 
>> of the OASIS TC), go to 
>> http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php. 
>>
>>
> 
> -- 
> ------------------------------------------------------------------------
> 
> *David Ward*
> Principal Software Engineer
> Portlet Technologies
> Oracle Portal
> 	Oracle European Development Centre
> 520 Oracle Parkway
> Thames Valley Park
> Reading
> Berkshire RG6 1RA
> UK 	
> *Email:* 	david.ward@oracle.com <mailto:david.ward@oracle.com>
> *Tel:* 	+44 118 924 5079
> *Fax:* 	+44 118 924 5005
> 
>