portals-wsrp4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandre-Michael Neubert" <alexandre-michael.neub...@edifixio.com>
Subject RE : Questions on WSRP features and their WSRP4J implementation
Date Tue, 07 Aug 2007 14:29:39 GMT

Alexandre Neubert

-----Message d'origine-----
De : Elliot Metsger [mailto:emetsger@jhu.edu] 
Envoyé : mardi 7 août 2007 15:43
À : wsrp4j-user@portals.apache.org
Objet : Re: Questions on WSRP features and their WSRP4J implementation

Hi Elliot,
Thank you so much for all your answers; you've been a great help. I have
some more questions though you might be able to answer ;) (see inline).

Hi Alex,

I'll try to answer some of these questions...

Alexandre-Michael Neubert wrote:
> *	What is the difference between a POP (Producer offered portlet) and
> a CCP (Consumer configured portlet)?

CCP's are "instances", if you will, of a POP.  Each CCP can have its own 
unique configuration associated with it.  CCP's are created when a 
consumer requests a POP to be cloned.

> But, how can I choose to make portlets available to all customers? Is this
> configured in the producer?  In the portlet itself ? Is there a property
> wsrp4j-producer to set (and if yes which one and where)?

Portlets are "made available" by being exposed by the producer's Service 
Description.  In WSRP4J, the consumer must register with the producer 
first, prior to accessing the service description.

If you want the service descriptions to be exposed to all users without 
requiring registration, you have to edit:

and modify requiresRegistration attribute to "true".

You mean "false", right?

> Can I forbid cloning of my portlets simply by not exposing the Portlet
> Management interface?


But, if I forbid cloning by no exposing this interface, my POP portlet can
never become a CCP, right? Is this going to work? Can I completely forbid
portlet cloning?

> We did some tests on WSRP4J and it appears that:
> *	Before the first request, all exposed portlets are POP
> *	After the first request on a portlet, this portlet becomes CCP
> Is this correct?

IIRC, yes.

> *	We have some trouble with the <portletStateChange> attribute in the
> SOAP message. We want to have it positioned to "readWrite", but sometimes
> the passed attribute is "cloneBeforeWrite" or "ReadOnly".
> Can we ourselves set this attribute? If yes, who is in charge of doing so
> (producer or consumer)? And where does it have to be done?

Section 6.3.2 of the spec addresses this.  The portletStateChange 
attribute is set by the consumer, specifically:

Request time: 

PortletStateChange is only sent on blockingAction's (JSR-168 action 
requests).  You can see the diagram on page 43 of the spec (6.3.2)

OK, unfortunately, we don't use WSRP4J as consumer, just as producer, so ...

> *	Finally, I wonder about the signification of the term "Portlet
> preferences". In the JSR 168 portlet specification, portlet preferences
> attributes which can be set and manipulated by the portlet itself.
> In the WSRP specification though, portlet preferences are manipulated by
> consumer and producer each time the portlet needs to change its persistent
> state.

Can't help you here, I haven't reached this point in my development... 
I'd have to dig into the spec and code a bit more.

> We also did some tests on sample WSRP portlets and it seems that each time
> form is submitted, the persistent state of the portlet needs to be

If you are submitting a JSR-168 action url, then yes, each time the form 
is submitted a state change could be happening.  If your form submission 
isn't going to change state (that would be weird), then use render urls.

> What is exactly this persistent state and where is it stored? 

This is dependent on your portlet.

Well, by default WSRP4J uses an xml file persistency mecanism I think and
since we did not customize this part, this is what we are currently using.
I ha d a look in wsrp4j-producer/WEB-INF/persistence and I saw all the
registration handles, but no information about the persistent state of any
portlet ...

> Does this automatically mean that the portlet has to be cloned if several
> users access it at the same time?

Yes, I think so.

Ok, I have hard time to understand the utility of cloning portlets here, so
let's take an example:
* Let's suppose I have one portlet exposed by the producer and consumed by
the consumer.
* Let's also suppose, the consumer instantiates this portlet only once on
one and only one portal page (to access it you have to be authentified
though; no guest)
* Since I use a portal as client, it will take over the authentification
* Now, suppose I have two customers who identify themselves on the portal
using their login/password (each user has it's own login/password) and both
access the page where the consumer instantiated the exposed remote portlet

How would WSRP handle this case? :
* Would the portlet be cloned for the first user and then again for the
* Would the users be able to both access the portlet (which is of course, in
a different state for both of them) without having to clone it?

Last question, lets suppose that the wsrp clones the portlet for the first
and then again for the second user to keep their navigation state separated
(this is what I think should happen).
Is there a mechanism in wsrp4j which allows to delete this portlet instance
once the user logs out? If yes, how am I able to configure it ans where
(consumer or producer)? (I saw something like this in the specification)
Finally, if this is possible, when would this happen (how is wsrp4j able to
say that the cloned instance in not used any more)? Is there some sort of
timeout to configure like for web sessions?

I apologize to ask so many questions, but I trying to get a whole picture
and this ain't easy for the moment. I think it would help a lot to have the
above scenario solved.

Thanks for your time and your answers,



> I know these are a lot of questions, but I couldn't get more information
> from the specification and I have hard time to understand all these
> concepts.

I hope this helps.  I'm certainly not an expert, but I have been digging 
around in the code and the spec the last couple weeks.  Others should 
feel free to chime in if I'm spreading mis-information.


View raw message