[ http://issues.apache.org/jira/browse/JS2-210?page=comments#action_60032 ] Ate Douma commented on JS2-210: -------------------------------
A reply I've given to questions of David Sean Taylor on the dev mailing list: David Sean Taylor wrote: > A few quick questions: > > * why are the method names changing from register to start I guess you are referring to the PortletApplicationManagement interface? Register and start(PortletApplication) are two different functionalities now. The start method invokes the (Registry) register method if a PA hasn't been registered before or if its portlet.xml checksum has changed. Furthermore, it invokes the PortletFactory register method, indicating the web application has started and thereby signaling the portal can access/invoke the portlets from this PA. Maybe I should change the "start" and "stop" method names to "init" and "destroy". I have thought about that before but just forgot to do. I'm not stuck on method names though so if you prefer something else please be my guest. You can change it yourself. Which brings me to an important issue for the whole Team: don't think I see this as *my* branch! If you find bugs, see something clearly wrong or stupid, or need changes for whatever reason: please take action. I hope we can commit this branch very soon but I also know there is still work to do to bring back *lost* features. Although branches are very easy to create and certainly the best solution for creating and presenting an alternative solution, I *hate* merging when there are many conflicting changes. Getting this done ASAP helps reducing conflicting changes. So, please lets all try to decide ASAP - if this branch is going to be merged - what needs to be done before the merge Any help with that I'd appreciate very much. > * why don't we support the registerAtInit option in the deployTool anymore Because it is required now. This is the primary functionality, already introduced as optional feature by Randy, needed for the new deployment and Portlet container interaction. Only after a Portlet Application has signaled "start" to the PortletApplicationManager it becomes available to the Portal for usage. Without it, its "not available", so "start" at init really must be "true". > Resolving all deployment classloader problems > --------------------------------------------- > > Key: JS2-210 > URL: http://issues.apache.org/jira/browse/JS2-210 > Project: Jetspeed 2 > Type: Improvement > Components: Container, Deployment, Portlet Factory > Versions: 2.0-dev/cvs, 2.0-M2, 2.0-FINAL > Reporter: Ate Douma > Assignee: Ate Douma > > The current implementation of handling deployment, redeployment and > undeployment of Portlet Applications (PAs) contains > several workarounds to prevent file locking of jars and classes on Windows > and to allow layout portlets to run under > the Jetspeed-2 context. > After almost a day debugging and testing I found the real cause of all the > problems we try to fix: > our own URLClassLoaders we create to be able to access the portlet and > portlet resource bundles in the PA. > As a test, I replaced our own URLClassLoaders with the contextClassLoader > from the PA, retrieved during the init > of the JetspeedServletContainer. And viola, no more problem! > I'm going to drastically refactor the whole deployment implementation to be > able to *only* use the PA contextClassLoaders. > The autodeployment from the deploy folder will be changed to infuse the PA > war (if needed) and *move* it to the webapps > folder so the autodeployment of the application server will handle the real > deployment. > Thus: the undeployment from the deploy folder for PAs will be gone! > Redeployment will still work as expected though. > For undeployment, an new undeployment feature in the PAM Portlet will be > added. > Additionally, other PA management features like upload/start/stop/reload/ > should be added soon too. We need a separate > issue for that though. > Decorators (and soon layouts too) will still be handled as is done right now > (they don't involve classloaders). > For deployment of layout portlets I want to make the following changes: > - must be deployed as jar, *not* as war > - can *only* contain classes, no resources > - resources required by a layout portlet must be deployed separately with a > decorators or layouts jar > - will *not* be deployed as web app but the jar *will* be loaded with a > URLClassloader with the portal classloader > as parent: the portlets will be invoked through a JetspeedContainerServlet > from the portal itself. > These changes will also fix the outstanding problem with running Jetspeed-2 > under a different context! > (see JS2-172 and JS2-182) > I'm going to need several days to perform this refactoring so if anyone has > problems with this plan please do comment within the next few days! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
