[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interop] Producer is up again
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]