DO NOT REPLY [Bug 18269] New: - Another Struts tutorial to add
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18269. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18269 Another Struts tutorial to add Summary: Another Struts tutorial to add Product: Struts Version: Nightly Build Platform: Other OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Added another tutorial. --- tutorials-old.xml Mon Mar 24 01:09:53 2003 +++ tutorials.xml Mon Mar 24 01:09:53 2003 @@ -4,6 +4,7 @@ authorMike Schachter/author authorTed Husted/author authorJames Holmes/author +authorI-Shen Leong/author titleResources - Tutorials - Jakarta Struts/title /properties @@ -38,6 +39,7 @@ pa href=http://www.jspinsider.com/tutorials/jsp/struts/strutsintro.html;b An Introduction to Struts/b/a by Casey Kochmer./p pa href=http://husted.com/struts/resources/uml-jps.pdf;bStruts UML Diagr ams/b/a (PDF) by Jean-Pierre Schnyder./p pa href=http://husted.com/struts/example-spec.html;bBlueprinting a Strut s Application/b/a by Ted Husted - Sample specification and API for the Strut s Example application./p +pa href=http://www.isabelle-hurbain.com/repository/docs/struts-onefile/;b Jakarta Struts: A Beginner's Tutorial/b/a by Isabelle Hurbain - For people who want to learn Struts from scratch. /p /section /chapter/body/document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18270] New: - [PATCH] Fixed a broken link in helping.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18270 [PATCH] Fixed a broken link in helping.xml Summary: [PATCH] Fixed a broken link in helping.xml Product: Struts Version: Nightly Build Platform: Other OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] --- helping-old.xml Mon Mar 24 01:09:34 2003 +++ helping.xml Mon Mar 24 01:09:35 2003 @@ -378,7 +378,7 @@ If an issue on your ballot doesn't include a patch, feel free to try coding one yourself. (At Jakarta, patches are the only votes that truly count.) - Well over a href=volunteers.htmlthirty developers/a have contributed + Well over a href=../volunteers.htmlthirty developers/a have contributed code or documentation to the product. You can too =:0) /li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18270] - [PATCH] Fixed a broken link in helping.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18270 [PATCH] Fixed a broken link in helping.xml --- Additional Comments From [EMAIL PROTECTED] 2003-03-24 09:20 --- Created an attachment (id=5473) Updated helping.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18269] - [PATCH] Another Struts tutorial to add
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18269. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18269 [PATCH] Another Struts tutorial to add [EMAIL PROTECTED] changed: What|Removed |Added Summary|Another Struts tutorial to |[PATCH] Another Struts |add |tutorial to add --- Additional Comments From [EMAIL PROTECTED] 2003-03-24 09:21 --- Forgot to add [PATCH]. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18227] - ConfigRuleSet should use Digester's class loader
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18227. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18227 ConfigRuleSet should use Digester's class loader [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER Target Milestone|--- |1.2 Family --- Additional Comments From [EMAIL PROTECTED] 2003-03-24 11:51 --- Tag for 1.2 family. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17977] - nested:iterate loses index with jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17977. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17977 nested:iterate loses index with jsp:include [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-03-24 13:26 --- Used the supplied tests and ran it against the latest nested taglib, and couldn't reproduce the error, even adding arbitrarily more complex nesting/inclusion scenarios. Thanks Chris for the supplied JSP's to test against. Pick up the new tags as linked or wait for the impending RC2 when it happens. If the problem does indeed persist, feel free to reopen the bug. For now, marking it as fixed by the last update of the nested tags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles beans package?
The reason I asked is because a package with 2 classes isn't too useful unless there are plans to add more beans. Thanks for the info on the item tag. David From: Cedric Dumoulin [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Tiles beans package? Date: Mon, 24 Mar 2003 09:51:38 +0100 Hi, This two classes are part of the Tiles API, so they should NOT be moved. The MenuItem interface is used in association with the item ... tag in the tiles config file. The SimpleMenuItem is its default implementation. Cedric David Graham wrote: There is a o.a.s.tiles.beans package with 2 classes in it: MenuItem and SimpleMenuItem. The only references to these classes is in the Tiles example webapp. Should this package be moved to the webapp instead of in the Tiles public interface? Dave _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Close to RC2?
Ted == Ted Husted [EMAIL PROTECTED] writes: Ted A frequent comment about RC1 is that it did not use the released versions of Ted the Commons packages. Ted I think for RC2 to be a likely release candidate and enable us to go from Ted there to a final release, we will need to lock down the Commons dependencies Ted first. Ted Otherwise, I believe we would just be preordaining a RC3 that deployed the Ted final versions of the Commons packages. Ted So, I would say that as soon as the requisite Commons packages are released, we Ted would be good to go to RC2 (assuming that we have kept our own tickets trimmed, Ted as we have so far). +1 on that amendment. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles beans package?
David Graham wrote: The reason I asked is because a package with 2 classes isn't too useful unless there are plans to add more beans. There were plans to add more kind of beans related to the definitions. For now, there is only one kind of interface and its implementation ;-(. Cedric Thanks for the info on the item tag. David From: Cedric Dumoulin [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Tiles beans package? Date: Mon, 24 Mar 2003 09:51:38 +0100 Hi, This two classes are part of the Tiles API, so they should NOT be moved. The MenuItem interface is used in association with the item ... tag in the tiles config file. The SimpleMenuItem is its default implementation. Cedric David Graham wrote: There is a o.a.s.tiles.beans package with 2 classes in it: MenuItem and SimpleMenuItem. The only references to these classes is in the Tiles example webapp. Should this package be moved to the webapp instead of in the Tiles public interface? Dave _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17502] - tiles:insert in jsp called from DefinitionDispatcherAction not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17502. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17502 tiles:insert in jsp called from DefinitionDispatcherAction not working --- Additional Comments From [EMAIL PROTECTED] 2003-03-24 17:51 --- I am having the problem also, Any suggested work arounds Struts 1.1rc1 tomcat 4.1.18 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17502] - tiles:insert in jsp called from DefinitionDispatcherAction not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17502. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17502 tiles:insert in jsp called from DefinitionDispatcherAction not working --- Additional Comments From [EMAIL PROTECTED] 2003-03-24 18:19 --- I've been using this JSP as work around for a while now: %@ page language=java % %@ taglib uri=struts-tiles.tld prefix=tiles % %@ taglib uri=struts-bean.tld prefix=bean % %@ taglib uri=struts-logic.tld prefix=logic % logic:present parameter=def bean:parameter id=toDef name=def / tiles:insert definition=%= toDef % flush=true / /logic:present You can use it like this: /path/dispatchDef.jsp?def=.empleado, or you can create a servlet mapping for this jsp under the same name you have been using for the DefinitionDispatcherAction, so you don't need to update the rest of your source/config files. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug 16108 - Why is ActionForm a base class rather than aninterface?
On Fri, 21 Mar 2003, Ted Husted wrote: Date: Fri, 21 Mar 2003 08:49:36 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Bug 16108 - Why is ActionForm a base class rather than an interface? It's a high priority for another milestone. It is not slated for the current iteration. Though, when I did that, I didn't know if there would be another RC, so I marked it ahead. But at this point, there's no reason not to go ahead and do it this weekend. Just to clarify, we're simply docuementing the design rationale. There are not any plans to change how the ActionForm works right now. And you're really going to have to break both of my arms and/or kick me out of Struts development if you want ActionForm *ever* changed to an interface again -- in *any* future Struts release. I think it's an absolutely horrible idea, for reasons that have been documented way too many times to count. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug 16108 - Why is ActionForm a base class rather than aninterface?
On Mon, 2003-03-24 at 14:20, Craig R. McClanahan wrote: On Fri, 21 Mar 2003, Ted Husted wrote: Date: Fri, 21 Mar 2003 08:49:36 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Bug 16108 - Why is ActionForm a base class rather than an interface? It's a high priority for another milestone. It is not slated for the current iteration. Though, when I did that, I didn't know if there would be another RC, so I marked it ahead. But at this point, there's no reason not to go ahead and do it this weekend. Just to clarify, we're simply docuementing the design rationale. There are not any plans to change how the ActionForm works right now. And you're really going to have to break both of my arms and/or kick me out of Struts development if you want ActionForm *ever* changed to an interface again -- in *any* future Struts release. I think it's an absolutely horrible idea, for reasons that have been documented way too many times to count. Come on Craig, tell us how you *really* feelLOL!! Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Mitchell Software Developer/Struts Evangelist http://www.open-tools.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18289] New: - Dynamic Message Resources
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18289.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18289
Dynamic Message Resources
Summary: Dynamic Message Resources
Product: Struts
Version: 1.1 RC1
Platform: All
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: Utilities
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Attached code provides a subclass of MessageResources which dynamically reloads
as changes are made.
==
Consists of 5 files which follow:
DynamicResourceBundle.java - A resource bundle which refreshes itself as the
underlying file(s) change
ResourceLoader.java - A subclass of ClassLoader which loads property bundles
ResourceLocation.java - A wrapper which encapsulates the location of a property
bundle either in a property file or a jar file
BundleMessageResources.java - Subclass of MessageResources which uses an
underlying DynamicResourceBundle to handle resource requests.
BundleMessageResourcesFactory.java
=
package org.apache.struts.util;
import java.util.*;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* pTitle: DynamicResourceBundle/p
* pDescription: Takes care of monitoring underlying bundle locations for
* changes and reloads (by creating a new ResourceLoader) if necessary/p
* pCopyright: None/p
* pCompany: CoLinx/p
* @author Richard Lawson
* @version 1.0
* @todo we need to move this to a more general package
*/
public abstract class DynamicResourceBundle {
/**
* The codeLog/code instance for this class.
*/
protected static final Log log = LogFactory.getLog
(DynamicResourceBundle.class);
/**
* Maximum length of one branch of the resource search path tree.
* Used in getBundle.
*/
protected static final int MAX_BUNDLES_SEARCHED = 3;
/**
* Cache of locales
*/
protected static HashMap locales = new HashMap();
/**
* How often do we check the underlying resource for changes ?
*/
protected static long checkInterval = 6;
/**
*
* @param interval ms between checks
*/
public static synchronized void setCheckInterval(long interval) {
checkInterval = interval;
}
/**
*
* @return ms between checks
*/
public static long getCheckInterval() {
return checkInterval;
}
/**
*
* @param baseName fully qualified base name of the resource
* @param locale locale for messages
* @return key
*/
protected static String getKey(String baseName, Locale locale) {
return baseName + , + locale.toString();
}
public static ResourceBundle getBundle(String baseName, Locale locale) {
return getBundle(baseName, locale, null);
}
/**
*
* @param baseName
* @param locale
* @return
*/
public static ResourceBundle getBundle(String baseName, Locale locale,
ResourceLoader loader) {
BundleMetaData meta = null;
String key = getKey(baseName, locale);
List locationList = null;
synchronized (locale) {
meta = (BundleMetaData) locales.get(key);
if (meta == null) {
if (loader == null) {
loader = new ResourceLoader();
}
locationList = calculateBundleLocations(baseName, locale,
loader);
meta = new BundleMetaData(locationList);
locales.put(key, meta);
log.info(Caching locations for bundle - + key + | Cache
size = + locales.size());
}
if (bundleFilesHaveChanged(meta)) {
log.warn(Underlying resources for bundle + baseName + ,
+ locale + have changed, reloading);
meta.refreshLoader();
}
}
// Resource bundle just returns a bundle from cache if already
// loaded with this loader
return ResourceBundle.getBundle(baseName, locale, meta.loader);
}
/**
* Calculate the bundles along the search path from the base bundle to the
* bundle specified by baseName and locale. Heavily based on the
implementation
* in ResourceBundle
* @param baseName the base bundle name
* @param locale the locale
* the search path.
* @return List of ResourceLocations for the bundle
*
*/
protected static List calculateBundleLocations(String baseName, Locale
locale, ResourceLoader loader) {
final ArrayList result = new
Re: Close to RC2?
On Mon, 24 Mar 2003, David Graham wrote: Date: Mon, 24 Mar 2003 07:41:18 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Close to RC2? I was thinking that 1.1 final would come after RC2 with the final versions of dependent jars. Do we have a direct dependency on commons-pool or is that included to support DBCP? I would like to remove the dependency on those packages for 1.2 as they won't be needed to support the deprecated GenericDataSource. The commons-pool dependency is indeed inherited from commons-dbcp. We can't actually remove GenericDataSource (in 1.1), because it wasn't deprecated in 1.0 -- we'll be able to clean that up next time around if we want (but we should warn people in the struts-config DTD that the whole data-sources element will go away, if that's really what we want to do). David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
digester
I am looking into the various methods of processing xml files and was wondering why digester was used as opposed to jaxb. Thanks in advance. Edgar
Re: Close to RC2?
On Mon, 24 Mar 2003, David Graham wrote: Date: Mon, 24 Mar 2003 12:38:01 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Close to RC2? The commons-pool dependency is indeed inherited from commons-dbcp. We can't actually remove GenericDataSource (in 1.1), because it wasn't deprecated in 1.0 -- we'll be able to clean that up next time around if we want (but we should warn people in the struts-config DTD that the whole data-sources element will go away, if that's really what we want to do). Why would the data-sources element have to go away just because GenericDataSource is removed? What would we use instead to implement the data sources? The original question (as I understood it) was how to get rid of commons-pool, which would also require getting rid of commons-dbcp and therefore eliminating the org.apache.commons.dbcp.BasicDataSource implementation class. Craig David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: digester
On Mon, 24 Mar 2003, Edgar Dollin wrote: Date: Mon, 24 Mar 2003 15:46:53 -0500 From: Edgar Dollin [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: digester I am looking into the various methods of processing xml files and was wondering why digester was used as opposed to jaxb. Struts was created three years ago, before JAXB was even a glimmer in anyone's eye. JAXB has only been around in final form for a few days :-). Thanks in advance. Edgar Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Close to RC2?
Actually, my original thought was to get rid of DBCP because it's a problem child dependency and not everyone needs it. We could leave the data-sources element because it's useful to those who need it but they would have to provide the implementation class (change the type attribute to required). But we could just leave everything how it is and only use released versions of DBCP after they get the next release of it out. Dave On Mon, 24 Mar 2003, David Graham wrote: Date: Mon, 24 Mar 2003 12:38:01 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Close to RC2? The commons-pool dependency is indeed inherited from commons-dbcp. We can't actually remove GenericDataSource (in 1.1), because it wasn't deprecated in 1.0 -- we'll be able to clean that up next time around if we want (but we should warn people in the struts-config DTD that the whole data-sources element will go away, if that's really what we want to do). Why would the data-sources element have to go away just because GenericDataSource is removed? What would we use instead to implement the data sources? The original question (as I understood it) was how to get rid of commons-pool, which would also require getting rid of commons-dbcp and therefore eliminating the org.apache.commons.dbcp.BasicDataSource implementation class. Craig David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18293] New: - Loading language files does not use Resource Bundle
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18293. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18293 Loading language files does not use Resource Bundle Summary: Loading language files does not use Resource Bundle Product: Struts Version: 1.1 RC1 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] PropertyMessageResources.java does not use ResourceBundle.getBundle to retrieve language properties files. Currently properties are loaded using ClassLoader.getResourceAsStream by constructing the path to the properties file based on the fully qualified class name and appending .properties. ResourceBundle can use a class or a properties file. This allows much better flexibility. A class can load the language file from any resource ie database. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
forms tag ? serialaizable
AFAIK we can't specify the type of class that the form bean is in, in struts config. (not formbean, but form-beans ) For example, form-beans type= myserilazableformbeanbase This would allow me to implement session fail over of session beans. AFAIK, this was depercated in 1.1. Yes, this can be miss-used but So can someone educate me that this works, else it's a feature request. Easy way to test is to add this to resin, for example: session-config file-storeWEB-INF/session/file-store /session-config This give me exception that formbean is not seriazable (concreate class is, ie form-bean name=userBean type=org.apache.scaffoldingLib.beans.UserBean/ is, but the base class is not. This is true of Collections as well) tia, Vic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: forms tag ? serialaizable
Your form beans should be serializable if you are keeping them in session scope. I am not familiar with scaffoldingLib but AFAIK the straight struts ActionForm and derivatives all serialize OK. Obviously, everything you throw in an ActionForm must be serializable as well. There are a few classes in the jdk which are not serializable, each of which is listed in the javadoc. Hope that helps Edgar -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Vic Cekvenich Sent: Monday, March 24, 2003 5:03 PM To: '[EMAIL PROTECTED]' Subject: forms tag ? serialaizable AFAIK we can't specify the type of class that the form bean is in, in struts config. (not formbean, but form-beans ) For example, form-beans type= myserilazableformbeanbase This would allow me to implement session fail over of session beans. AFAIK, this was depercated in 1.1. Yes, this can be miss-used but So can someone educate me that this works, else it's a feature request. Easy way to test is to add this to resin, for example: session-config file-storeWEB-INF/session/file-store /session-config This give me exception that formbean is not seriazable (concreate class is, ie form-bean name=userBean type=org.apache.scaffoldingLib.beans.UserBean/ is, but the base class is not. This is true of Collections as well) tia, Vic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18299] New: - html:rewrite should include attribute for action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18299. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18299 html:rewrite should include attribute for action Summary: html:rewrite should include attribute for action Product: Struts Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I find the missing action attribute in html:rewrite inconsistent. An effort was made to include an action attribute in html:link so that the mapping information could be referenced in the struts-config.xml. The html:rewrite, an extention of the html:link tag overlooks this attribute even though its use can be equally as important since the html:rewrite is simply the href rendering of the html:link tag extracted for purposes when the html anchor tag is inappropriate. After reviewing the code, this field already belongs to LinkTag which RewriteTag extends so adding this would be 1 line change in RewriteTag (calling the updated RequestUtils.computeURL() and add the attribute to the struts-html.tlddone. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18299] - html:rewrite should include action attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18299. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18299 html:rewrite should include action attribute [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Summary|html:rewrite should include |html:rewrite should |attribute for action |include action attribute - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: forms tag ? serialaizable
SNIP
If your UserBean class declares implements Serializable, this means that
UserBean also takes responsibility for saving and restoring the instance
variables of the base class as well. If it doesn't, then your UserBean
class is broken. The only thing the container should need to do is an
instanceof Serializable test.
public class UserBean extends ValidatorForm
implements Serializable, Collection { // class }
My concreate does. But the container I think sees is as
ValidatorForm which it tags as not Serializable and throws an
exception. I could test by making ActionForm implement Seriazable, see
if that fixes it.
tia,
.V
The servlet spec requires that a container disallow setting a session
attribute that is not Serializable if you use the distributable element
in your web.xml file. Tomcat implements this behavior, and it should be
portable to any other container that conforms to the spec.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18293] - Loading language files does not use Resource Bundle
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18293. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18293 Loading language files does not use Resource Bundle --- Additional Comments From [EMAIL PROTECTED] 2003-03-25 00:03 --- Michael, I am unclear as to why this bug was filed. MessageResources uses a similar algorithm for findng and loading i18n'd files. There is already an implementation of MessageResources that pulls from a database (using OJB), and I'm about to release another (using Hibernate). The OJBMessageResources is Open Source and licensed under the Apache Software License. It is freely available for download at: http://sourceforge.net/projects/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18299] - html:rewrite should include action attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18299. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18299 html:rewrite should include action attribute [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-03-25 01:00 --- *** This bug has been marked as a duplicate of 16296 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16296] - Add action Attribute to html:rewrite Tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16296. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16296 Add action Attribute to html:rewrite Tag [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-03-25 01:00 --- *** Bug 18299 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: forms tag ? serialaizable
On Mon, 24 Mar 2003, Vic Cekvenich wrote:
Date: Mon, 24 Mar 2003 18:55:00 -0500
From: Vic Cekvenich [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: forms tag ? serialaizable
SNIP
If your UserBean class declares implements Serializable, this means that
UserBean also takes responsibility for saving and restoring the instance
variables of the base class as well. If it doesn't, then your UserBean
class is broken. The only thing the container should need to do is an
instanceof Serializable test.
public class UserBean extends ValidatorForm
implements Serializable, Collection { // class }
My concreate does. But the container I think sees is as
ValidatorForm which it tags as not Serializable and throws an
exception. I could test by making ActionForm implement Seriazable, see
if that fixes it.
What the container should do (and Tomcat in particular does) is an
instanceof Serializable check, which will return true if the base class
says implements Serializable (which is already true for ActionForm, and
therefore DynaActionForm) or whether the concrete class itself does (as in
your example above).
If you still have a serialization problem with a UserBean declared as you
indicate above, it's likely that one of the instance variables inside
UserBean (or its superclass) cannot actually be serialized. For example,
if you've got an instance variable of type java.sql.Connection, you'd
definitely run into problems.
tia,
.V
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: forms tag ? serialaizable
Craig:
I am using struts and am pretty impressed with the way you good ppl have
comeup with such a generic and helpful framework. I will like to contribute
in the development efforts, can any one tell me how can I contribute in this
great work.
Regards
Chetan
- Original Message -
From: Craig R. McClanahan [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Tuesday, March 25, 2003 10:49 AM
Subject: Re: forms tag ? serialaizable
On Mon, 24 Mar 2003, Vic Cekvenich wrote:
Date: Mon, 24 Mar 2003 18:55:00 -0500
From: Vic Cekvenich [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: forms tag ? serialaizable
SNIP
If your UserBean class declares implements Serializable, this means
that
UserBean also takes responsibility for saving and restoring the
instance
variables of the base class as well. If it doesn't, then your
UserBean
class is broken. The only thing the container should need to do is an
instanceof Serializable test.
public class UserBean extends ValidatorForm
implements Serializable, Collection { // class }
My concreate does. But the container I think sees is as
ValidatorForm which it tags as not Serializable and throws an
exception. I could test by making ActionForm implement Seriazable, see
if that fixes it.
What the container should do (and Tomcat in particular does) is an
instanceof Serializable check, which will return true if the base class
says implements Serializable (which is already true for ActionForm, and
therefore DynaActionForm) or whether the concrete class itself does (as in
your example above).
If you still have a serialization problem with a UserBean declared as you
indicate above, it's likely that one of the instance variables inside
UserBean (or its superclass) cannot actually be serialized. For example,
if you've got an instance variable of type java.sql.Connection, you'd
definitely run into problems.
tia,
.V
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: forms tag ? serialaizable
On Tue, 25 Mar 2003, Chetan Sahasrabudhe wrote: Date: Tue, 25 Mar 2003 11:00:06 +0530 From: Chetan Sahasrabudhe [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: forms tag ? serialaizable Craig: I am using struts and am pretty impressed with the way you good ppl have comeup with such a generic and helpful framework. I will like to contribute in the development efforts, can any one tell me how can I contribute in this great work. The short answer on getting involved in any Jakarta project starts at: http://jakarta.apache.org/site/getinvolved.html For Struts in particular, we're trying to wrap up the 1.1 final release, so looking at the outstanding bug reports: http://nagoya.apache.org/bugzilla/ for either Struts 1.1, or the Commons packages we rely on (beanutils, collections, dbcp, digester, fileupload, lang, logging, pool, and validator), and post suggested patches as an attachment to the bug report. We'll also start discussing the next generation here on STRUTS-DEV, so feel free to participate in the discussions with your own thoughts about where Struts should go. Eventually, a combination of code contributions (patches and/or proposed enhancements) and contributions on STRUTS-DEV will likely get you nominated as a committer -- besides having direct commit access to the CVS repository, that also means you would have binding votes on the future of Struts. Regards Chetan Craig PS: it's considered rude on mailing lists to hijack someone elses thread to talk about something different ... you should really start a new thread instead :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: forms tag ? serialaizable
I will like to contribute in the development efforts, can any one tell me how can I contribute in this great work. We really need people to work on the commons packages we're dependent on, specifically DBCP and Logging. We finally got Struts itself down to 0 bugs (for now) and are now working on the commons stuff. David _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Thanks for Information.
Thanks Craig, and sorry for breaking the thread. will go through mentioned information. Regards Chetan - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 11:18 AM Subject: Re: forms tag ? serialaizable On Tue, 25 Mar 2003, Chetan Sahasrabudhe wrote: Date: Tue, 25 Mar 2003 11:00:06 +0530 From: Chetan Sahasrabudhe [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: forms tag ? serialaizable Craig: I am using struts and am pretty impressed with the way you good ppl have comeup with such a generic and helpful framework. I will like to contribute in the development efforts, can any one tell me how can I contribute in this great work. The short answer on getting involved in any Jakarta project starts at: http://jakarta.apache.org/site/getinvolved.html For Struts in particular, we're trying to wrap up the 1.1 final release, so looking at the outstanding bug reports: http://nagoya.apache.org/bugzilla/ for either Struts 1.1, or the Commons packages we rely on (beanutils, collections, dbcp, digester, fileupload, lang, logging, pool, and validator), and post suggested patches as an attachment to the bug report. We'll also start discussing the next generation here on STRUTS-DEV, so feel free to participate in the discussions with your own thoughts about where Struts should go. Eventually, a combination of code contributions (patches and/or proposed enhancements) and contributions on STRUTS-DEV will likely get you nominated as a committer -- besides having direct commit access to the CVS repository, that also means you would have binding votes on the future of Struts. Regards Chetan Craig PS: it's considered rude on mailing lists to hijack someone elses thread to talk about something different ... you should really start a new thread instead :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug 16108 - Why is ActionForm a base class rather than an interface?
And you're really going to have to break both of my arms and/or kick me out of Struts development if you want ActionForm *ever* changed to an interface again -- in *any* future Struts release. I think it's an absolutely horrible idea, for reasons that have been documented way too many times to count. My plan was to document the reasons for why ActionForm was changed from an interface to a base class into the Newbie FAQ. I had submitted a patch to bug 16108 which contains two reasons listed below. I learned these mostly from reading both lists. 1. Extensibility: If it were still an interface, applications that used an earlier version of Struts would break if the developers decided to modify ActionForm in the next release. 2. Correct usage: Struts was designed to follow the Model-View-Controller (MVC) paradigm and ActionForms were intended to be part of the view. The purpose of an ActionForm is to represent user input data on the server-side. It allows you to validate the user data in the view layer before passing the data to the model. By making ActionForm an interface, a model object can implement ActionForm which would be convenient at first but the model would also have to do validation. By doing this, you would have combined the model and view together whereas the goal of MVC is to keep these separate. So by making ActionForm a base class, this forces you to do the right thing. Any comments? If I got this wrong, please let me know. I know that I've left out other reasons but I didn't fully understand them. I-Shen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
