You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsrp4j-dev@portals.apache.org by Richard Jacob <ja...@apache.org> on 2003/12/17 15:35:17 UTC

Announcement: wsrp4j proxyportlet

Hi,

first of all sorry for crossposting, but I think this might be 
interesting for all addressed communities.
I woud suggest to continue discussions on the wsrp4j-dev list.

I committed the wsrp4j proxyportlet implementation.
The generic proxyportlet is a JSR168 portlet which can be deployed in 
JSR168 conformant conainer environments.
I added examples on how to run the proxyportlet on the pluto example 
portal implementation (you need to edit the portletentityregistry.xml 
and the pageregistry.xml files accordingly).
The default configuration files set up a page with proxyportlet entities 
which consume remote portlets provided by the default wsrp4j 
pluto-provider configuration. (Note: the setup points to port 8081 
instead of the default 8080 for debugging purposes, you must either 
change the config, use a tcp monitor or change the tomcat ports).

Basicly the portlet is a generic proxy which can be put on a page and 
"pointed to" a remote wsrp portlet, it translates the container calls to 
wsrp calls and allows to retrieve and interact with markup from remote 
portlets.
This way a JSR168 container/portal can act as a WSRP Consumer capable of 
using any user-facing, visual web services conformant to the WSRP spec 
(completly platform and language independant).
So far we enabled JSR168 containers/portals to act as WSRP Producers 
enabling us to provide standard JSR168 portlets as remote visual, 
user-facing web services.

I tested the portlet with pluto and wsrp4j (on one tomcat and also on 
two designated tomcats).
However as always there is still a lot of work left ;-)

-cheers
Richard