----------------------- Alexandre Neubert Edifixio [EMAIL PROTECTED] -----Message d'origine----- De : Elliot Metsger [mailto:[EMAIL PROTECTED] Envoyé : mercredi 8 août 2007 06:05 À : [email protected] Objet : Re: RE : Questions on WSRP features and their WSRP4J implementation
Hi again Elliot, Hi Alex, All these are good questions, you're making my brain hurt :-) As I'm just getting started with the code, I'm reading along in the spec just like you are, trying to figure this stuff out. As you sayed, as we are both trying to understand, it may be easier if we understand the spec and the code the same way :) > 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? In practice, completely forbidding portlet cloning probably it wouldn't make for a very useful portal (although there are probably some use cases supporting such a configuration). In section 6.3.2, page 43 ln 25 the spec discusses the use of the 'portletStateChange' flag to prevent state changes (and by extension, cloning) for unauthorized users. So you could expose the portlet management interface and support cloning, but only for authorized users. Yeah, I read this section very carefully and understood the sense of portlet cloning, but, for the moment, unfortunately, my configuration tells a user to clone a portlet each time a performBlockingInteraction is required. I thought that once the portlet would have been cloned for a particular user, this user would use the same cloned instance for the rest of his navigation (what would make sense). In my configuration though, I get tonnes of clones for the same user on the same portlet (which is a problem; my resistration files keep growing exponentially). Should a portlet instance, once cloned for a particular user, be reused (flag PortletStateChange would then be set to readWrite) or is the behaviour to clone the portlet for each performBlockingInteraction request right (from the spec I think not, but I may be wrong)? One could also use information in the RegistrationContext or UserContext to selectively prevent cloning (the parameters to the performBlockingInteraction call). That interests me (related to the previous point). How can I do that? Whi is in charge of this (consulmer or producer)? If it is the producer, which configuration file in WSRP4J is to edit? > 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 > second? I haven't examined every line of code in WSRP4J, but I believe that the portlet won't be cloned until an End User clicks on a link that executes a blockingInteraction call, with the Consumer setting a 'portletStateChange' field to 'cloneBeforeWrite' or 'readWrite' > * 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? Assuming that one or both of your End-Users has clicked on a link which executed a blockingInteraction, as described above, then no. Each user would have to clone the portlet. OK, so it confirms what I think. > 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). Yes I agree. > Is there a mechanism in wsrp4j which allows to delete this portlet instance > once the user logs out? No, not that I know of, but I could be wrong. I assume (but haven't verified) the WSRP4J producer will honor the specification and destroy portlet scopes and registration scopes upon request. So, if I understand right what you say here, is that for every request which requires a performBlockingInteraction, the portlet instance should be cloned, then the request is treated and the cloned portlet instance is destroyed on the next request requirering a performBlockingInteraction. This would be another way of functioning (I thought, as sayed above, a cloned instance of the portlet would be attached to one user and be reused by this user on his whole navigation; but since the consumer uses a handle to address the portlet which could be used by everyone, I could be wrong). So if the Consumer requests the destruction of a RegistrationContext or PortletContext (say on an End-User logout from your portal) then the WSRP4J producer will destroy them (and remove any persisted data). I don't see how to configure the consumer to do so ... > If yes, how am I able to configure it ans where > (consumer or producer)? (I saw something like this in the specification) The producer, AFAIK, must be told to destroy RegistrationContexts or PortletContexts. It could be told by the Consumer, or by some out-of-band mechanism like an administration tool. So I don't have any other choice to find out how to configure the consumer to do so. :(( > 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? No. I don't think the WSRP4J producer tracks whether or not a cloned portlet is stale. > 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. No apology needed. Unfortunately, I don't know that I have a solution for you. I've wondered myself how to manage the cloned portlets when they are no longer used. I've decided it isn't much different than a more traditional web application that saves user state in a database. In a traditional webapp, users will login over time, maybe some will only login once. Users will perform some actions in the application, resulting in some state being recorded in the database. Then the user logs out; they may never come back. Now you're left with a few rows in your database that will probably never be referenced again. As I sayed before, my problem is that portlets are cloned on every PBI and never destroyed, so I grows more and more, no to mention when several user are on the same site ... So, to summarize I have to figure out: * Either a portlet instance is cloned for one user and used upon his whole navigation --> In that case I have to find out how to prevent cloning portlets on every PBI call * Or, portlet instances are cloned only upon a particular navigation state, cloned for every PBI and destroyed when they are themselves cloned (next step of the navigation). In that case I have to figure out how to destroy the portlet instances left, since my consumer won't do it as it is right now The more I talk about it, the more I think the second solution is the right one. What do you think? Thanks for the dialog, you've definitely stimulated my thinking. Hopefully you're getting something out of this as well :-) I surely will; I appreciate the dialog also, it's always easier to understand when more than one person is trying to; especially since documents like the specification can be interpreted (and of course misunderstood). Thanks again, Regards Alex Best regards, Elliot > > Thanks for your time and your answers, > > Regards > > Alex > >> 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. > > Thanks, > Elliot
