RE: [wsrp-interfaces] Applet resources through WSRP

[Rich Thompson <richt2@us.ibm.com>]

It sounds like you are mixing two issues
here:

1. You have validated that applet use has the same issues as any other url, but not a large set of new issues. As a special note; resource urls require full name preservation, whether it be a .gif or a .jar.
2. When Producers use templates for url production and referenced resources also contain urls, the Producer must also use the templates on the relevant urls within the resource. This will become easier with the new getResource operation (important pieces of data are passed on the invocation), but can be also done by providing a resolver and passing any required info on the url (or in cookies, though I would prefer to not explicitly name that option). Note: this includes namespace resolving as well as url rewriting.

Rereading your post, is there also an
issue with not all Consumers rewriting urls within resources (as per the
specs requirements)?

I think a couple of additions to the
FAQ and Primer from this information might be in order.

Rich

"Spector, Artem" <artem.spector@sap.com>

03/23/05 05:03 AM

To	<wsrp-interfaces@lists.oasis-open.org>
cc
Subject	RE: [wsrp-interfaces] Applet resources through WSRP

Yes, we’ve found a solution
(we work together with Avi) and I’d like to share it with you.
 
Actually there are two challenges
when composing consumer-side URLs for producer-side resources:
1.        In
some cases the resource name must be preserved in the consumer-side URL
(like .jar for applets)
2.        Nested
resources – if a css contains URLs, they must be rewritten as well.
 
The solution includes the following
aspects:
1.        The
Consumer modifies the URLs so that they will end up with the resource names.
2.        The
Portlets use a standard API to output resource URLs. In WSRP scenario these
calls are intercepted by the Producer, which does the necessary conversions
(for example, URL writing using templates). 
3.        If
the URL references a resource containing other URLs (like css or js), the
producer replaces the resource URL with a URL pointing to a special producer-side
servlet. This servlet acts as a filter when downloading the resource, and
rewrites all the URLs it contains.
 
For illustration imagine a
Portlet called ExamplePortlet which was deployed with image resource
/images/r1.gif. Its consumer-side URL will look like this:
http://consumer.com/portal/consumer/resources/r1.gif?producerUrl=http://producer.com/portlets/ExamplePortlet/images/r1.gif
 
If the Portlet has a style
sheet resource /css/r2.css, its URL will look like this:
http://consumer.com/portal/consumer/resources/r2.css?producerUrl=http://producer.com/producer/resources/r2.css?resourceUrl=http://producer.com/portlets/ExamplePortlet/css/r2.css
 
Now if r2.css contains a reference
to r1.gif, then the producer-side servlet (producer/resources) will invoke
the Producer URL writing logic for this URL. So eventually the image URL
returned to the client within the style sheet will exactly as in the first
example.
 
Regards,
Artem

---

From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Tuesday, March 22, 2005 9:58 PM
To: wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] Applet resources through WSRP
 

I have been asked this question now by several people ... has anyone tried
referencing an applet in markup from a WSRP portlet? If so, any guidelines
that should be shared with portlet developers?

Rich

Subbu Allamaraju <subbu@bea.com>

01/26/05 08:07 AM

To	wsrp-interfaces@lists.oasis-open.org
cc
Subject	Re: [wsrp-interfaces] Apptel resources through WSRP

 

Is the Producer returning the Content-Type header? I've not tried applet
downloading, but if Content-Type does not work, I would try the
Content-Disposition header, e.g. with a "inline; filename=foo.jar"
value. In any case, the Consumer has to proxy these headers to the browser.

Regards,

Subbu

Klein, Avi wrote:
> Hi,
>
>  
>
> I wonder if someone has dealt with fetching of applet as resource.
>
>  
>
> Whenever rewriting the URL of the applet, the browser fails to fetch it
> since it expects the URL to end with *.jar and not with the consumer URL
> (result of the rewriting).
>
>  
>
>  
>
> Thanks,
>
>  
>
> Avi.
>