Re: [OS-webwork] XWork, Webwork and reloading xml
Jason Carreira wrote:
Do you know if there's a way to tell if it's in a jar file?
Not reliably, AFAIK. While you could get the CodeSource for a Class, a file is a different matter.
My solution would be even simpler. If a file cannot be read or written, it should not be able to
change, at least in the normal operation of the VM. Simply excluding such files from a reload check
would achieve the desired result.
I have attached a small patch against the current oscore CVS to illustrate this.
-craig
-Original Message-
From: Hani Suleiman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 09, 2004 12:40 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] XWork, Webwork and reloading xml
In this case I'd say xwork is broken. The solution is for it to not
bother monitoring files that are in jars.
On Mar 9, 2004, at 11:53 AM, Craig Raw wrote:
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Index: FileManager.java
===
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 FileManager.java
--- FileManager.java22 May 2003 05:26:34 - 1.1.1.1
+++ FileManager.java10 Mar 2004 07:23:16 -
@@ -20,6 +20,7 @@
/**
* FileManager
* @author Jason Carreira
+ * @author Craig Raw
* Created May 7, 2003 8:44:26 PM
*/
public class FileManager {
@@ -51,6 +52,10 @@
return true;
}
+if (revision.getLastModified() == 0) {
+return false;
+}
+
return revision.getLastModified() < revision.getFile().lastModified();
}
@@ -84,10 +89,8 @@
long lastModified = 0;
if (!file.exists() || !file.canRead()) {
-file = null;
-}
-
-if (file != null) {
+files.put(fileName, new FileRevision(file, 0));
+} else {
lastModified = file.lastModified();
files.put(fileName, new FileRevision(file, lastModified));
}
Re: [OS-webwork] XWork, Webwork and reloading xml
Each redeployment does get its own classloader. I am using Jboss' separate loader repositories feature to acheive this. While I fully support what you are going to do in removing the static singleton configuration ( I filed the issue for that one :) ), it will unfortunately not help here. FileManager will still attempt to check the timestamp on unreachable files and reload them with every request. This is actually not centrally a repdeployment issue, redeployment is just the original cause for using the xml.reload flag. Jason Carreira wrote: Well, that code is really there for the case where you do have exploded war files, you're editing them, and you want the changes to be picked up... Tell me, will each redeployment get its own classloader? I'm planning on refactoring so that the configuration is not a singleton, but is instead kept in a Map of classloader -> configuration... Would that help? -Original Message----- From: Craig Raw [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 11:54 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] XWork, Webwork and reloading xml Hi, After spending some time with the xwork/oscore code, I find that what you say is not wrong, but it is broken in this case. The problem is in FileManager, which stores a reference to the file and its last modified timestamp as you say, to check if it needs reloading later. Before storing this however, FileManager checks if the file exists and is readable (reasonably so, since it needs to obtain the last modified timestamp). However, in the case of deployment on JBoss and sharing the xwork/oscore libs, the file does not exist. JBoss does not explode its shared libs, and the file url that FileManager obtains looks something like /jboss/server/default/lib/webwork-2.0.jar!/webwork-default.xml. Since this doesn't exist, webwork-default.xml is never added to FileManagers references, XmlConfigurationProvider.needsReload() always returns true and thus every request to the site means all the configuration files are reloaded. Note that this only happens with the type references in xwork.xml, not xwork.xml itself, but XmlConfigurationProvider checks all of its referenced files for reloading. I don't whether jboss or xwork/oscore is broken here, but I'd appreciate any suggestions. Thanks, Craig Jason Carreira wrote: It doesn't actually re-parse the configuration XML file every time. The ConfigurationManager calls provider.needsReload() on every ConfigurationProvider to see if that config provider thinks it needs to reload (so any custom ConfigurationProvider can implement this in its own way). The XmlConfigurationProvider, which parses xwork.xml or any file using that DTD, uses the FileManager from OSCore which I wrote (stole from some of Hani's code :-) )... That utility maintains a reference to the file and checks its timestamp vs. the time stamp the last time we read it to see if the file timestamp has changed. Note that if you set this flag the same check will be done for all validation files and conversion property files, although not for text bundles (complain to Sun, it's their PropertyResourceBundle). Jason -Original Message- From: Craig Raw [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 7:37 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] XWork, Webwork and reloading xml Hi, I have run into issues surrounding xwork and the reloading of classes using hot deploy. My deployment environment is JBoss, where I am sharing the webwork/xwork libraries between ears (to keep the ear file size down) and using a separate loader repository for each ear (to keep the configurations separated by classloader namespace). The problem comes with the flag, webwork.configuration.xml.reload. When set to false, xwork holds on the xwork.xml file (loaded by a classloader) even after a hot redeploy. This causes all the classes loaded by that classloader to remain accessible as well, and the hot redeploy fails in the sense that the deployed classes do not change, and neither does the xwork configuration. (This would not happen if I bundled the xwork/webwork libraries into the ear/war, at the cost of a much larger ear file size.) If the flag is true, hot redeploy works fine, but com.opensymphony.work.config.ConfigurationManager reloads xwork.xml on every request to the server. I would like to be in a situation where I can hot deploy to a production server, to avoid having to drop all the deployments and restart the server just to update one. However, I am concerned as to the additional load caused by constantly reloading xwork.xml. I see that there is a comment in the class mentioned above, on line 127: @todo it currently appears that the reload strategy is to check on each call to getConfiguration(). this seems extremely burdensome. a caching mechanism should be implemented Is it possible to have
Re: [OS-webwork] XWork, Webwork and reloading xml
Hi, After spending some time with the xwork/oscore code, I find that what you say is not wrong, but it is broken in this case. The problem is in FileManager, which stores a reference to the file and its last modified timestamp as you say, to check if it needs reloading later. Before storing this however, FileManager checks if the file exists and is readable (reasonably so, since it needs to obtain the last modified timestamp). However, in the case of deployment on JBoss and sharing the xwork/oscore libs, the file does not exist. JBoss does not explode its shared libs, and the file url that FileManager obtains looks something like /jboss/server/default/lib/webwork-2.0.jar!/webwork-default.xml. Since this doesn't exist, webwork-default.xml is never added to FileManagers references, XmlConfigurationProvider.needsReload() always returns true and thus every request to the site means all the configuration files are reloaded. Note that this only happens with the type references in xwork.xml, not xwork.xml itself, but XmlConfigurationProvider checks all of its referenced files for reloading. I don't whether jboss or xwork/oscore is broken here, but I'd appreciate any suggestions. Thanks, Craig Jason Carreira wrote: It doesn't actually re-parse the configuration XML file every time. The ConfigurationManager calls provider.needsReload() on every ConfigurationProvider to see if that config provider thinks it needs to reload (so any custom ConfigurationProvider can implement this in its own way). The XmlConfigurationProvider, which parses xwork.xml or any file using that DTD, uses the FileManager from OSCore which I wrote (stole from some of Hani's code :-) )... That utility maintains a reference to the file and checks its timestamp vs. the time stamp the last time we read it to see if the file timestamp has changed. Note that if you set this flag the same check will be done for all validation files and conversion property files, although not for text bundles (complain to Sun, it's their PropertyResourceBundle). Jason -----Original Message- From: Craig Raw [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 7:37 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] XWork, Webwork and reloading xml Hi, I have run into issues surrounding xwork and the reloading of classes using hot deploy. My deployment environment is JBoss, where I am sharing the webwork/xwork libraries between ears (to keep the ear file size down) and using a separate loader repository for each ear (to keep the configurations separated by classloader namespace). The problem comes with the flag, webwork.configuration.xml.reload. When set to false, xwork holds on the xwork.xml file (loaded by a classloader) even after a hot redeploy. This causes all the classes loaded by that classloader to remain accessible as well, and the hot redeploy fails in the sense that the deployed classes do not change, and neither does the xwork configuration. (This would not happen if I bundled the xwork/webwork libraries into the ear/war, at the cost of a much larger ear file size.) If the flag is true, hot redeploy works fine, but com.opensymphony.work.config.ConfigurationManager reloads xwork.xml on every request to the server. I would like to be in a situation where I can hot deploy to a production server, to avoid having to drop all the deployments and restart the server just to update one. However, I am concerned as to the additional load caused by constantly reloading xwork.xml. I see that there is a comment in the class mentioned above, on line 127: @todo it currently appears that the reload strategy is to check on each call to getConfiguration(). this seems extremely burdensome. a caching mechanism should be implemented Is it possible to have the best of both worlds, and have the xwork.xml reloaded only on redeploy? TIA, Craig --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email i
[OS-webwork] XWork, Webwork and reloading xml
Hi, I have run into issues surrounding xwork and the reloading of classes using hot deploy. My deployment environment is JBoss, where I am sharing the webwork/xwork libraries between ears (to keep the ear file size down) and using a separate loader repository for each ear (to keep the configurations separated by classloader namespace). The problem comes with the flag, webwork.configuration.xml.reload. When set to false, xwork holds on the xwork.xml file (loaded by a classloader) even after a hot redeploy. This causes all the classes loaded by that classloader to remain accessible as well, and the hot redeploy fails in the sense that the deployed classes do not change, and neither does the xwork configuration. (This would not happen if I bundled the xwork/webwork libraries into the ear/war, at the cost of a much larger ear file size.) If the flag is true, hot redeploy works fine, but com.opensymphony.work.config.ConfigurationManager reloads xwork.xml on every request to the server. I would like to be in a situation where I can hot deploy to a production server, to avoid having to drop all the deployments and restart the server just to update one. However, I am concerned as to the additional load caused by constantly reloading xwork.xml. I see that there is a comment in the class mentioned above, on line 127: @todo it currently appears that the reload strategy is to check on each call to getConfiguration(). this seems extremely burdensome. a caching mechanism should be implemented Is it possible to have the best of both worlds, and have the xwork.xml reloaded only on redeploy? TIA, Craig --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] [OT] Sitemesh and GZIP Compression
What order are your filters listed in web.xml? The gzip filter should be listed before sitemesh in web.xml so it performs its compression after page decoration. hth, Craig Samuel Mota wrote: Hi, This is a little OT but I hope someone from Opensymphony can help me on this. I'm testing the Gzip filter compression bundled as an example with Tomcat 4 (but running it on Tomcat 5) on my app ... If sitemesh is disabled everything is compressed and correctly displayed but with sitemesh I get only a blank screen. (actually the decorator only put the page contents on a table structure) Any ideas? Thanks + Samuel G. Mota + [EMAIL PROTECTED] + 55 (11) 4417 7093 + Business Application Dpt. + Netset Serviços em Tecnologia + a Hypercom Company + http://www.hypercom.com --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: Spam:[OS-webwork] Xwork and hot redeploy
Petri Wessman wrote: On Friday 05 December 2003 17:53, Jason Carreira wrote: Actually, there is a way to do that. With JBoss 3.2.x, if you package your war inside an .ear and place the following as jboss-app.xml in the ear META-INF directory, JBoss will use a separate classloader for the application (instead of the default flat classloader). Thanks for all your help on this issue. I have filed a JIRA issue at http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-139 I have done the following as a workaround for the meantime: 1) Added webwork.configuration.xml.reload=true to webwork.properties 2) Packaged my .war as a .ear with the jboss-app.xml specifying a unique classloader repository in JBoss. This seems to work, but I need to perform further testing to be sure. I am, I admit, confused as to the reason of the reload property. Why would you not want to reload the configuration. Performance reasons? Thanks again, Craig --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Xwork and hot redeploy
Hi, I have encountered what is to me a serious usability issue with XWork. I am using it deployed in a .war in Jboss, where hot redeploy greatly reduces update times during the development process. To reduce the size of the created .war files, I store the xwork/webwork jars in the JBoss server lib configuration. The problem I have encountered is that Xwork seems to store its configuration information from xwork.xml in as static attribute in a class. Thus, if this class is not redeployed, the configuration does not change. The only way to get around this is to include the xwork jar, the webwork jar and the velocity jar in WEB-INF/lib for every .war I create. This boosts the size of each .war from a few kb to almost a Mb. It also seems rather wasteful, given that I try to componentize my webapp into several smaller .wars. Have I got this right? If so, and there's no workaround, I may have to go back to Struts. Great framework otherwise. Craig PS The static attribute seems to be configurationInstance in ConfigurationManager. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
