|
Ate Douma made changes - 02/Apr/05 12:42 AM
Michael Lipp made changes - 31/Oct/05 09:25 PM
I mean it is important feature. We can't use jetspeed for portlet app development without this feature.
When I change deployment descriptor (which is not a rare case in development), I have to rename the application to be able to deploy it, because redeployment doesn't work due this bug. btw, I'm going to check it and maybe provide a fix:] do you have any idea where to begin? i'm new in jetspeed dev.
Ate Douma made changes - 24/May/06 10:02 AM
I've written a implementation for this using a background monitor thread, which will check web.xml, portlet.xml and (if available) jetspeed-portlet.xml for changes.
If changes are found, the portlet application will be unregistered and subsequently re-registered. Furthermore, if the portlet application cannot be loaded because of errors in the xml definitions, the monitor thread will keep on checking for changes. Thus, when the errors are corrected, the portlet application will automatically be registered (again). The implementation is contained within the PortletApplicationManager which now has a new property, descriptorChangeMonitorInterval, through which you can configure the interval (in seconds) for the monitor to check for changes. The default interval is 10 seconds, but you can disable the monitor all together by specifying a value <= 0. As the PortletApplicationManager needs to startup the monitor *after* it is created, it now requires the init-method "start" (as well as the destroy-method "stop") to be defined in the deployment.xml assembly configuration. Warning: This is a new *requirement*. Failing to do so will prevent portlet applications being registered !!! The updated deployment.xml contains a commented out example of setting this new descriptorChangeMonitorInterval property, but as already said: by default it is set to 10 seconds so the monitor is now also active by default.
Ate Douma made changes - 24/May/06 10:34 AM
Additional clarification:
Changing the portlet.xml (or jetspeed-portlet.xml) will *only* trigger reloading the registry, not a full application reload. Now, if you change the web.xml, the usual behavior of web servers like Tomcat *will* result in a reload of the application, but this will *not* be triggered by Jetspeed. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I agree this would be a nice feature but don't think it is a requirement.
But, if you don't agree, just set it back to a Bug (and maybe provide a fix ;-))