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
Re: Spam:[OS-webwork] Xwork and hot redeploy
On Dec 8, 2003, at 6:12 AM, Craig Raw wrote: 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? Yep, enabling this causes the timestamp of a file to be checked on every request. --- 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
Re: Spam:[OS-webwork] Xwork and hot redeploy
On Friday 05 December 2003 17:53, Jason Carreira wrote: As far as being able to have the one Xwork.jar and have multiple configurations, that's a good idea... Please add a Jira issue. I've always hated that Singleton, so we can look at how to get rid of it. In the meantime, is it possible to have the one xwork.jar file and have Jboss load it individually in the classloader of each web app (instead of just once in the server classloader)? 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). ?xml version=1.0 encoding=ISO-8859-1? jboss-app loader-repository:loader=xxx.ear/loader-repository /jboss-app The xxx.ear can be anything as far as I know, as long as each ear has a different string - afaik it's just an id for the classloader. I usually just use the same name as the .ear file. Works fine for me :). //Petri --- 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
RE: Spam:[OS-webwork] Xwork and hot redeploy
You can set webwork.configuration.xml.reload=true In your webwork.properties to tell it to check and automatically reload XML configuration files (this includes the xwork.xml file and any other included xwork configuration files, validation.xml files, and type conversion .properties files right now). As far as being able to have the one Xwork.jar and have multiple configurations, that's a good idea... Please add a Jira issue. I've always hated that Singleton, so we can look at how to get rid of it. In the meantime, is it possible to have the one xwork.jar file and have Jboss load it individually in the classloader of each web app (instead of just once in the server classloader)? Also, any hints on how Struts implements this? I know how I'd like to implement it (refactor all of our internal pieces into IoC components instead of having singletons for each other to look up), but this would be a major undertaking. Jason -Original Message- From: Craig Raw [mailto:[EMAIL PROTECTED] Sent: Friday, December 05, 2003 9:53 AM To: [EMAIL PROTECTED] Subject: Spam:[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 --- 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
Re: Spam:[OS-webwork] Xwork and hot redeploy
Jason Carreira wrote:
webwork.configuration.xml.reload=true
In your webwork.properties to tell it to check and automatically reload
XML configuration files (this includes the xwork.xml file and any other
included xwork configuration files, validation.xml files, and type
conversion .properties files right now).
As far as being able to have the one Xwork.jar and have multiple
configurations, that's a good idea... Please add a Jira issue. I've
always hated that Singleton, so we can look at how to get rid of it. In
the meantime, is it possible to have the one xwork.jar file and have
Jboss load it individually in the classloader of each web app (instead
of just once in the server classloader)?
No, but you can have it appear as one singleton while it really is many
by doing a classloader switch internally.
E.g.:
Map clSettings = new HashMap();
String getFoo(String bar)
{
Map settings =
(Map)clSettings.get(Thread.currentThread().getContextClassloader());
if (settings == null)
...
return (String)settings.get(bar);
}
This at least gives you one singleton per deployment. If you use a
WeakHashmap for clSettings you can even have the stated be garbage
collected properly.
/Rickard
---
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
