Bug 901061 (JBPAPP6-1432)
Summary: | Need similar "DeleteWorkDirOnContextDestroy" configuration in EAP 6 Web Subsystem | ||||||
---|---|---|---|---|---|---|---|
Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | dchia | ||||
Component: | Web | Assignee: | Jean-frederic Clere <jclere> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 6.0.0 | CC: | brian.stansberry, dandread, dchia, jason.greene, jclere, jfclere, myarboro, rdickens, rhatlapa, rsvoboda, smumford | ||||
Target Milestone: | ER6 | ||||||
Target Release: | EAP 6.1.0 | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
URL: | http://jira.jboss.org/jira/browse/JBPAPP6-1432 | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: |
JBoss Enterprise Application Platform 6 did not recompile source JSPs on redeployment unless they were newer than the associated java or class files. Earlier versions of JBoss Enterprise Application Platform 6 did not contain the code to remove the java and class files on undeployment. This meant that if a user attempted to restore sources from an older version of a webapp, the `.java` and `.class` files were not removed which prevented the JSPs from being recompiled. The corresponding code has now been added to JBoss Enterprise Application Platform 6 and can be activated through the system property `org.jboss.as.web.deployment.DELETE_WORK_DIR_ONCONTEXTDESTROY`. The default for this property is `false`. JBoss Enterprise Application Platform 6 users can now use this property to remove `.java` and `.class` files to ensure that JSP sources are recompiled.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2013-07-23 18:38:32 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 959100 | ||||||
Attachments: |
|
Description
dchia
2012-10-15 15:46:52 UTC
Docs QE Status: Removed: NEW I have a patch to use a system property to switch the delete. org.jboss.as.web.deployment.DELETE_WORK_DIR_ONCONTEXTDESTROY Created attachment 696145 [details]
possible patch.
This needs to be scheduled for EAP 6.2 We have a patch, we just need a pm ack Still need that PM ack PM ack ? We need blocker flag set to + to process prepared PR - https://github.com/jbossas/jboss-eap/pull/109 Are you the correct owner for this? @John I'm not owner of this, just wanted to push PR in EAP, PR was merged 4 days ago by Jason - https://github.com/jbossas/jboss-eap/pull/109 I have verified that if I set property org.jboss.as.web.deployment.DELETE_WORK_DIR_ONCONTEXTDESTROY=true when starting EAP 6.1.0.ER6 it works as expected (verified by changing timestamp of jsp file and seeing if it recompiles with and without the option on redeployment) According to jboss-as-web_1_4.xsd schema I haven't found a way to configure this as part of web subsystem (I would expect this to be configurable under jsp-configuration element) Is there any better way to configure it than using -Dorg.jboss.as.web.deployment.DELETE_WORK_DIR_ONCONTEXTDESTROY=true when starting EAP6.1? BTW: The option should also be described in documentation for EAP 6.1 but it is not. It can be only configured via the system property. I think it should be also possible to configure it via standalone/domain config file It is like any system properties: /system-property=org.jboss.as.web.deployment.DELETE_WORK_DIR_ONCONTEXTDESTROY:add(value=true) I have created separate RFE bugzilla for the change in configuration: https://bugzilla.redhat.com/show_bug.cgi?id=959100 Functionality verified, waiting for update in documentation. Added draft Release Notes text to the bottom of the Doc Text field. Not sure I fully understood the implications of the function, so technical verification is requested. "Previous versions of JBoss Enterprise Application Platform 6 did not recompile source JSPs in from uncompressed archives on redeployment. This was because the code that allowed JBoss Enterprise Application Platform 5 versions to do this was missing. The DELETE_WORK_DIR_ONCONTEXTDESTROY key/value configuration option has now been added to JBoss Enterprise Application Platform 6 and users can now specify that the work directory be destroyed, ensuring that JSPs are recompiled." That is more tricky :D In the source JSP are only recompiled if they are older than the java or class files. So when restoring sources from an old version of the webapp the JSP are older than the compiled files so they aren't recompiled, in other words the customers can't restore an old version of their exploded webapps. In EAP5 a flag DeleteWorkDirOnContextDestroy allows to remote the java and class when undeploying a webapp. The flag DeleteWorkDirOnContextDestroy of EAP5 has been added back to EAP6 through a system-property named "org.jboss.as.web.deployment.DELETE_WORK_DIR_ONCONTEXTDESTROY" is the default value is false... Thanks for the feedback Jean-fredric One thing though: When you said "remote the java and class", did you mean 'remove the java and class'? Because I can make sense of that in the context of what you were explaining. However, if you did intend to say "remote the java and class", then I'm going to need to ask for clarification as to what you mean by that. oops "allows to remove" sorry for the typo. Thanks for the clarification Jean-frederic. I've rewritten the release note draft with (what I hope is) a better understanding of the change and it's background. Is this version more accurate? "unless they are older" it should be: "unless they are newer" "The DeleteWorkDirOnContextDestroy code" ... "through the system property" it should be: "The corresponding code" ... and can be activated "through the system property". Thanks for the quick response Jean-frederic I've made those changes in the text. If there's no further feedback, I'll arrange to have this bug marked for inclusion in the Release Notes document. |