[ https://issues.jboss.org/browse/GTNPC-76?page=com.atlassian.jira.plugin.s... ] Dimitri BAELI updated GTNPC-76: ------------------------------- Attachment: PortletServletLoadOrder.zip PortletAndServletLoadOrderTest.war Source code and usable war -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/GTNPC-76?page=com.atlassian.jira.plugin.s... ] Dimitri BAELI commented on GTNPC-76: ------------------------------------ So you continue to study or we should move the issue ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/GTNPC-76?page=com.atlassian.jira.plugin.s... ] Matt Wringe commented on GTNPC-76: ---------------------------------- we should probably move the issue, its most likely wci (looking at it right now) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/GTNPC-76?page=com.atlassian.jira.plugin.s... ] Matt Wringe commented on GTNPC-76: ---------------------------------- The issue is pretty simple and WCI was never designed to handle the situation where a portlet would require a servlet to be initialized first (nor do I think the portlet spec has anything to say about this). Its not a bug, its just not designed to work this way. During a normal startup, the servlet gets initialized first, because we are waiting for the portlet container to start and then we initialize all the available portlets (so during normal startup, the portlet is available first to wci, but the pc is not ready for it yet, so the servlet gets a chance to start while the pc initializes itself). During a hot deploy, the pc is already up and running and can start the portlet right away. This is why there is a difference in the order of the initializations. We could handle this situation if we were to use the WCI generic setup instead of the jboss/tomcat implementation (since this uses a servlet to do the deploy, and we can set the load-on-start of this servlet), but this requires all portlet wars to be modified to include this special servlet. The best approach might be to look at supporting both the WCI generic and native setups at the same time, but this gets a bit tricky with callbacks and such. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/GTNPC-76?page=com.atlassian.jira.plugin.s... ] Matt Wringe commented on GTNPC-76: ---------------------------------- "Still it seems fair to keep the same loading order, no ?" we can't keep the order the same because its different things which are starting, we have wci, pc, the portlet and the servlet. When the server is started: - wci starts up - wci get notified that a new war is available and it gets put into a list waiting for PC to come along and read it - the servlet starts up - PC get initialized, reads through the list of wars, finds all available portlets and initializes them. Hot Deploy - PC and WCI are already started - WCI gets notified that a new war is available, and PC get notified of this new war and looks into the war for any new portlets - PC initializes the new portlet - the servlet gets inialized The order is the same here, the portlet gets retrieve first and then the servlet. The reason things act differently is because of when PC gets initialized and when it can initialize the portlets. Portlets shouldn't depend on servlets to be initialized, its not designed for this situation (nor do we say we can do this in the documentation). "When you say "this requires all portlet wars to be modified to include this special servlet" that would be for portlets we want to hotdeploy, or really all portlets ?" All wars which contain portlets, since WCI will no longer be integrated into the web container and will require a servlet to register each and every war (if the web.xml doesn't contain the servlet, WCI (and therefore PC) will not know about it). If they use this approach, when the portlet gets deployed is dependent on a servlet, and therefore can use a load-on-startup value to determine when it should be loaded with respect to other servlets. The way to properly support this would actually be to allow for both the generic (ie no web container integration) and native (ie web container integration) wci implementations to be used at the same time. It would work something as follows: when the server is started - wci is initialized and becomes a listener for new wars to be deployed in the web container - wci get notified that a new war is available, it checks to see if the war contains the GateInServlet (the generic implementation). If the war contains the GateInServlet, it skips this war. If it does not contain this servlet, it add the war to the list of available wars to be used by PC. So, in this case, the sample war is not added to the list. - the servlet starts up (the servlet load-on-startup = 0) - wci get notified of the new war (the GateInServlet load-on-startup = 1) - pc starts up and searches the WCI list of wars for portlets - the portlet gets initialized [NOTE: its a bit more tricky, but we can also configure the setup to load the portlet first instead of the servlet if needed] hot deploy - WCI and PC are already initialized and running - the sample war is deployed, WCI see that its using the GateInServlet and doesn't notify PC about it - the servlet starts (load-on-startup = 0) - the GateIn servlet starts (load-on-startup = 1) and notifies WCI that a new war is available. WCI then notifies PC - PC initializes the portlet For this to work I need to update WCI to be able to use both configurations at the same time, which makes things a bit more tricky. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/GTNPC-76?page=com.atlassian.jira.plugin.s... ] Matt Wringe updated GTNPC-76: ----------------------------- Attachment: wci-disable-and-manual-native-registration.patch Including a patch which changes the WCI behaviour in 2 ways 1) a web application can specify it doesn't want to be picked up by the native registration [for generic, an application is defaulted to not being registered. The GateInServlet has to be added to the web.xml for registration to occur] 2) we can now manually register a webapp in WCI. By using the two behaviours specified above we can get the desired behaviour: - disable the webapp's registration so that the native implementation doesn't pick it up. - use the GateInServlet to manually add in the webapp. By using the load-on-startup option in the web.xml we can control when the webapp gets registered with regards to other servlets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira