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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
