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