Prepopulate the Form
Hi, I am wondering about the best way to Pre populate a form. The scenario is : User inputs some values in a Form X Depending on the values in Form X, I need to prepopulate the Form Y (access database thru EJBs and pre populate some fields in Form Y) I was wondering what is the best way to do this. Probably the Constructor of FormY is the right place to prepopulate.However the HttpServletRequest is not available in the Constructor.So the values entered in previous form are not visible. Can anybody suggest a good way of tackling this scenario ? Thanks, Srikanth __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
RE: PATCH: add note in build scripts that they work with Ant 1.3but not with Ant 1.4
On Thu, 3 May 2001, Conor MacNeill wrote: > Craig, > > I suggest you don't apply this patch for a few reasons: > 1. We are going to fix it in Ant CVS so that it is backward compatible. > 2. There is no such thing as Ant 1.4 > That makes sense to me. Thanks for being responsive on this. > I'm sure your crowd will forgive our crowd for this temporary problem :-) > Well, I've caused a few problems like this (with both Struts and Tomcat), so I can certainly be sympathetic :-). > Conor > Craig
cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java
craigmcc01/05/02 20:29:39
Modified:src/share/org/apache/struts/taglib/bean IncludeTag.java
LocalStrings.properties
src/share/org/apache/struts/taglib/html LinkTag.java
LocalStrings.properties
src/share/org/apache/struts/taglib/logic
LocalStrings.properties RedirectTag.java
src/share/org/apache/struts/util RequestUtils.java
Log:
Modify RequestUtils.absoluteURL() to throw a MalformedURLException if one is
encountered while trying to reconstruct a URL from the specified page context
and context-relative path. This will cause tags like ,
, and to throw an exception instead of create
null URLs. In addition, these three tags will log the exception to the servlet
context's log to facilitate further analysis.
These changes are in direct response to Bugzilla #1586, where the main page
of the example application creates bogus hyperlinks that look like this:
Log on to the MailReader Demonstration Application
I suspect that this is due to misconfiguration of the servlet container
being used (WebSphere in the case of the bug report). Throwing the exception,
and logging the details, will prove it one way or the other.
Revision ChangesPath
1.11 +41 -4
jakarta-struts/src/share/org/apache/struts/taglib/bean/IncludeTag.java
Index: IncludeTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/bean/IncludeTag.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- IncludeTag.java 2001/02/12 01:26:57 1.10
+++ IncludeTag.java 2001/05/03 03:29:36 1.11
@@ -1,5 +1,5 @@
/*
- * $Id: IncludeTag.java,v 1.10 2001/02/12 01:26:57 craigmcc Exp $
+ * $Id: IncludeTag.java,v 1.11 2001/05/03 03:29:36 craigmcc Exp $
*
*
* The Apache Software License, Version 1.1
@@ -66,6 +66,7 @@
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLConnection;
+import javax.servlet.ServletContext;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
import javax.servlet.jsp.JspException;
@@ -89,7 +90,7 @@
* wrapped response passed to RequestDispatcher.include().
*
* @author Craig R. McClanahan
- * @version $Revision: 1.10 $ $Date: 2001/02/12 01:26:57 $
+ * @version $Revision: 1.11 $ $Date: 2001/05/03 03:29:36 $
*/
public class IncludeTag extends TagSupport {
@@ -301,14 +302,50 @@
}
HttpServletRequest request =
(HttpServletRequest) pageContext.getRequest();
-href = RequestUtils.absoluteURL(request, forward.getPath());
+try {
+href = RequestUtils.absoluteURL(request, forward.getPath());
+} catch (MalformedURLException mue) {
+RequestUtils.saveException(pageContext, mue);
+ServletContext sc = pageContext.getServletContext();
+sc.log(messages.getMessage("include.url",
+ request.getScheme(),
+ request.getServerName(),
+ "" + request.getServerPort(),
+ forward.getPath()),
+ mue);
+JspException e = new JspException
+(messages.getMessage("include.url",
+ request.getScheme(),
+ request.getServerName(),
+ "" + request.getServerPort(),
+ forward.getPath()));
+throw e;
+}
} else if (this.href != null) {
href = this.href;
includeSession = false;
} else /* if (this.page != null) */ {
HttpServletRequest request =
(HttpServletRequest) pageContext.getRequest();
-href = RequestUtils.absoluteURL(request, this.page);
+try {
+href = RequestUtils.absoluteURL(request, this.page);
+} catch (MalformedURLException mue) {
+RequestUtils.saveException(pageContext, mue);
+ServletContext sc = pageContext.getServletContext();
+sc.log(messages.getMessage("include.url",
+ request.getScheme(),
+ request.getServerName(),
+ "" + request.getServerPort(),
+ this.page),
+ mue);
+
RE: PATCH: add note in build scripts that they work with Ant 1.3 but not with Ant 1.4
Craig, I suggest you don't apply this patch for a few reasons: 1. We are going to fix it in Ant CVS so that it is backward compatible. 2. There is no such thing as Ant 1.4 I'm sure your crowd will forgive our crowd for this temporary problem :-) Conor > -Original Message- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 3 May 2001 2:33 AM > To: '[EMAIL PROTECTED]' > Subject: Re: PATCH: add note in build scripts that they work with Ant > 1.3 but not with Ant 1.4 > > > > > On Wed, 2 May 2001, Colin Sampaleanu wrote: > > > I spent an hour or so scratching my head trying to figure out why Struts > > builds ok with Ant 1.3, but with 1.4 fails to copy over > struts.jar into the > > distributables. It is because the build scripts use the > "available" task to > > check for the existence of directories, and whereas Ant 1.3 had one > > attribute, "file", that worked for both files and dirs, Ant 1.4 > expects you > > to use "file" and "dir" respectively. > > > > The patches below simply make a note of the incompatibility... > > > > I'm going to go ahead and apply these, but I've heard that the Ant crowd > is going to fix this by re-enabling backwards compatibility on the > available task. Thanks to GUMP, we found out that they broke a *lot* of > build scripts when they made that change :-). > > Personally, I'm going to stick with released versions of Ant -- I do > enough bleeding edge stuff already. > > Craig > >
cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html LinkTag.java
craigmcc01/05/02 18:13:55
Modified:src/share/org/apache/struts/taglib/html LinkTag.java
Log:
Correct the previous patch for generating elements. The
tests should really be for the "linkName" attribute, not the "name"
attribute.
PR: Bugzilla #1581
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.11 +7 -7
jakarta-struts/src/share/org/apache/struts/taglib/html/LinkTag.java
Index: LinkTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/LinkTag.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- LinkTag.java 2001/04/29 00:38:04 1.10
+++ LinkTag.java 2001/05/03 01:13:54 1.11
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/LinkTag.java,v 1.10
2001/04/29 00:38:04 craigmcc Exp $
- * $Revision: 1.10 $
- * $Date: 2001/04/29 00:38:04 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/LinkTag.java,v 1.11
2001/05/03 01:13:54 craigmcc Exp $
+ * $Revision: 1.11 $
+ * $Date: 2001/05/03 01:13:54 $
*
*
*
@@ -86,7 +86,7 @@
* Generate a URL-encoded hyperlink to the specified URI.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.10 $ $Date: 2001/04/29 00:38:04 $
+ * @version $Revision: 1.11 $ $Date: 2001/05/03 01:13:54 $
*/
public class LinkTag extends BaseHandlerTag {
@@ -438,7 +438,7 @@
n++;
if (href != null)
n++;
-if (name != null)
+if (linkName != null)
n++;
if (page != null)
n++;
@@ -480,8 +480,8 @@
href = RequestUtils.absoluteURL(request, forward.getPath());
}
-// If "name" was specified, return null
-else if (name != null) {
+// If "linkName" was specified, return null (not making an href)
+else if (linkName != null) {
return (null);
}
cvs commit: jakarta-struts build.xml
craigmcc01/05/02 18:05:48 Modified:.build.xml Log: Put xerces.jar in the correct place when using "deploy.catalina". Revision ChangesPath 1.50 +5 -5 jakarta-struts/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-struts/build.xml,v retrieving revision 1.49 retrieving revision 1.50 diff -u -r1.49 -r1.50 --- build.xml 2001/04/29 00:37:00 1.49 +++ build.xml 2001/05/03 01:05:48 1.50 @@ -286,7 +286,7 @@ - @@ -298,28 +298,28 @@ - - - -
RE: More File upload problems
> -Original Message- > From: Azariah Jeyakumar > Sent: Tuesday, May 01, 2001 2:32 PM > To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' > Subject: More File upload problems > > Hi, > > I have found three more problems with file upload using the > nightly build (20010430): > > 1. File upload does not work (see exception stack trace > below) with IE 5.0 but works with IE 5.5, Netscape 4.76, Netscape 6. This problem happens only when I upload .txt files from IE 5.0. The exception does not happen when I upload other binary files such as .p7c extension from IE 5.0. Thanks Azariah > 2. Cleanup of temp files on empty upload > If I submit the form without choosing the file to > upload, the tmp file does not get cleaned up. I have checked > that I am calling FormFile.destroy() > 3. temp dir is not taken from javax.servlet.context.tempDir > I am using resin and it correctly sets the attribute > javax.servlet.context.tempDir to the directory > ...\WEB-INF\tmp. But the ActionServlet continues to have the > tempDir property as null. When I explicitly create the > directory (whose path is returned in the File object in the > javax.servlet.context.tempDir attribute) and then set its > path in ActionServlet, then the upload correctly happens in > this directory. > > Thanks > Azariah > > 500 Servlet Exception > javax.servlet.ServletException: MultipartIterator: no > multipart request data sent > at > org.apache.struts.upload.MultipartIterator.parseRequest(Multip > artIterator.java:337) > at > org.apache.struts.upload.MultipartIterator.(MultipartIte > rator.java:152) > at > org.apache.struts.upload.DiskMultipartRequestHandler.handleReq > uest(DiskMultipartRequestHandler.java:59) > at > org.apache.struts.util.RequestUtils.populate(RequestUtils.java:454) > at > org.apache.struts.action.ActionServlet.processPopulate(ActionS > ervlet.java:2020) > at > org.apache.struts.action.ActionServlet.process(ActionServlet.j > ava:1535) > at > org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:489) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:102) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:83) > at > com.caucho.server.http.Invocation.service(Invocation.java:291) > at > com.caucho.server.http.CacheInvocation.service(CacheInvocation > .java:121) > at > com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:238) > at > com.caucho.server.http.HttpRequest.handleConnection(HttpReques > t.java:157) > at com.caucho.server.TcpConnection.run(TcpConnection.java:140) > at java.lang.Thread.run(Thread.java:484) > >
BUG: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html FormTag.java
Running Struts from 5/1/01 cvs I get the following error from the form tag.
I am using IBM VAJ 3.5.3 with the Web Sphere Test environment set to JSP
level 1.1
java.lang.IllegalArgumentException: cant remove
Attributes from request scope
java.lang.Throwable(java.lang.String)
java.lang.Exception(java.lang.String)
java.lang.RuntimeException(java.lang.String)
java.lang.IllegalArgumentException(java.lang.String)
void
org.apache.jasper.runtime.PageContextImpl.removeAttribute(java.lang.String,
int)
int org.apache.struts.taglib.html.FormTag.doEndTag()
I am not sure why the doEndTag needs to remove the object but jasper doesn't
let it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 28, 2001 8:12 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-struts/src/share/org/apache/struts/taglib/html FormTag.java
craigmcc01/04/28 20:11:40
Modified:src/share/org/apache/struts/taglib/html FormTag.java
Log:
Migrate the attributes created by the tag (the form tag
instance itself, and a reference to the form bean itself) from page scope
to request scope. Among other things, this change enables the use of a
separate JSP page (accessed by or the template tag library)
to contain the input fields, nested inside an tag instance.
PR: Bugzilla #932
Submitted by: Lajos Incze <[EMAIL PROTECTED]>
Revision ChangesPath
1.11 +12 -8
jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.java
Index: FormTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.jav
a,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- FormTag.java 2001/04/19 22:58:40 1.10
+++ FormTag.java 2001/04/29 03:11:39 1.11
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.jav
a,v 1.10 2001/04/19 22:58:40 craigmcc Exp $
- * $Revision: 1.10 $
- * $Date: 2001/04/19 22:58:40 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.jav
a,v 1.11 2001/04/29 03:11:39 craigmcc Exp $
+ * $Revision: 1.11 $
+ * $Date: 2001/04/29 03:11:39 $
*
*
*
@@ -87,7 +87,7 @@
* properties correspond to the various fields of the form.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.10 $ $Date: 2001/04/19 22:58:40 $
+ * @version $Revision: 1.11 $ $Date: 2001/04/29 03:11:39 $
*/
public class FormTag extends TagSupport {
@@ -512,7 +512,8 @@
ResponseUtils.write(pageContext, results.toString());
// Store this tag itself as a page attribute
- pageContext.setAttribute(Constants.FORM_KEY, this);
+ pageContext.setAttribute(Constants.FORM_KEY, this,
+ PageContext.REQUEST_SCOPE);
// Locate or create the bean associated with our form
int scope = PageContext.SESSION_SCOPE;
@@ -535,7 +536,8 @@
}
pageContext.setAttribute(name, bean, scope);
}
- pageContext.setAttribute(Constants.BEAN_KEY, bean);
+ pageContext.setAttribute(Constants.BEAN_KEY, bean,
+ PageContext.REQUEST_SCOPE);
// Continue processing this page
return (EVAL_BODY_INCLUDE);
@@ -551,8 +553,10 @@
public int doEndTag() throws JspException {
// Remove the page scope attributes we created
- pageContext.removeAttribute(Constants.BEAN_KEY);
- pageContext.removeAttribute(Constants.FORM_KEY);
+ pageContext.removeAttribute(Constants.BEAN_KEY,
+PageContext.REQUEST_SCOPE);
+ pageContext.removeAttribute(Constants.FORM_KEY,
+PageContext.REQUEST_SCOPE);
// Render a tag representing the end of our current form
StringBuffer results = new StringBuffer("");
IllegalArgumentException: cant remove Attributes from request scope
Running Struts from 5/1/01 cvs I get the following error from the form tag. I am using IBM VAJ 3.5.3 with the Web Sphere Test environment set to JSP level 1.1 java.lang.IllegalArgumentException: cant remove Attributes from request scope java.lang.Throwable(java.lang.String) java.lang.Exception(java.lang.String) java.lang.RuntimeException(java.lang.String) java.lang.IllegalArgumentException(java.lang.String) void org.apache.jasper.runtime.PageContextImpl.removeAttribute(java.lang.String, int) int org.apache.struts.taglib.html.FormTag.doEndTag() The following patch fixes the problem. Index: src/share/org/apache/struts/taglib/html/FormTag.java===RCS file: /home/cvspublic/jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.java,vretrieving revision 1.11diff -r1.11 FormTag.java516c516< PageContext.REQUEST_SCOPE);---> PageContext.PAGE_SCOPE);540c540< PageContext.REQUEST_SCOPE);---> PageContext.PAGE_SCOPE);557c557< PageContext.REQUEST_SCOPE);---> PageContext.PAGE_SCOPE);559c559< PageContext.REQUEST_SCOPE);---> PageContext.PAGE_SCOPE);
tools that realize code
The struts framework is constructed in a way that lends itself to some type of designer tool. It would be feasible to have a visual editor for "struts-config.xml", then when an action is selected the "perform" event is opened in an editor just like clicking on a button in a VB form. That's just a simple example of what could be done. Does anyone else envision something like this? Taylor
PATCH: fix Digester classloading to use current context classloader
As per recent messages about classloading in the Digester, below is a patch for the Digester... One other possible effect that has not been discussed is that there may be a few environments where Class.forname() would work, but the context classloader loadclass() variant would not, due to security restrictions on obtaining the context classloader. This is a common operation and should not be an issue, but if it is, the could could try the context classloader approach, and simply try the Class.forName approach on any SecurityException caught... PATCH: --- Index: CallMethodRule.java === RCS file: /home/cvspublic/jakarta-struts/src/share/org/apache/struts/digester/CallMeth odRule.java,v retrieving revision 1.10 diff -r1.10 CallMethodRule.java 130c130 < this.paramTypes[i] = Class.forName(paramTypes[i]); --- > this.paramTypes[i] = Thread.currentThread().getContextClassLoader().loadClass(paramTypes[i]); Index: ObjectCreateRule.java === RCS file: /home/cvspublic/jakarta-struts/src/share/org/apache/struts/digester/ObjectCr eateRule.java,v retrieving revision 1.3 diff -r1.3 ObjectCreateRule.java 152c152 < Class clazz = Class.forName(realClassName); --- > Class clazz = Thread.currentThread().getContextClassLoader().loadClass(realClassName); Index: SetNextRule.java === RCS file: /home/cvspublic/jakarta-struts/src/share/org/apache/struts/digester/SetNextR ule.java,v retrieving revision 1.4 diff -r1.4 SetNextRule.java 153c153 < paramTypes[0] = Class.forName(paramType); --- > paramTypes[0] = Thread.currentThread().getContextClassLoader().loadClass(paramType); Index: SetTopRule.java === RCS file: /home/cvspublic/jakarta-struts/src/share/org/apache/struts/digester/SetTopRu le.java,v retrieving revision 1.5 diff -r1.5 SetTopRule.java 152c152 < paramTypes[0] = Class.forName(paramType); --- > paramTypes[0] = Thread.currentThread().getContextClassLoader().loadClass(paramType);
Re: PATCH: add note in build scripts that they work with Ant 1.3but not with Ant 1.4
On Wed, 2 May 2001, Colin Sampaleanu wrote: > I spent an hour or so scratching my head trying to figure out why Struts > builds ok with Ant 1.3, but with 1.4 fails to copy over struts.jar into the > distributables. It is because the build scripts use the "available" task to > check for the existence of directories, and whereas Ant 1.3 had one > attribute, "file", that worked for both files and dirs, Ant 1.4 expects you > to use "file" and "dir" respectively. > > The patches below simply make a note of the incompatibility... > I'm going to go ahead and apply these, but I've heard that the Ant crowd is going to fix this by re-enabling backwards compatibility on the available task. Thanks to GUMP, we found out that they broke a *lot* of build scripts when they made that change :-). Personally, I'm going to stick with released versions of Ant -- I do enough bleeding edge stuff already. Craig
RE: Bad classloading in Digester
On Wed, 2 May 2001, Colin Sampaleanu wrote: > Should I still upload the patches here, I was just going to in a few > minutes, actaully? > You can go ahead ... but I was going to copy what Scott checked in (after he fixes a potential NPE problem first :-). Craig
PATCH: add note in build scripts that they work with Ant 1.3 but not with Ant 1.4
I spent an hour or so scratching my head trying to figure out why Struts builds ok with Ant 1.3, but with 1.4 fails to copy over struts.jar into the distributables. It is because the build scripts use the "available" task to check for the existence of directories, and whereas Ant 1.3 had one attribute, "file", that worked for both files and dirs, Ant 1.4 expects you to use "file" and "dir" respectively. The patches below simply make a note of the incompatibility... Index: build.xml === RCS file: /home/cvspublic/jakarta-struts/build.xml,v retrieving revision 1.49 diff -r1.49 build.xml 12a13,20 > > This script is known to work with Ant 1.3. It is know to fail with > Ant 1.4 due to changes in the "available" task (this build file and/or > build files it depends on checks the availability of both files and > directories with available's "file" attribute, whereas available in > Ant 1.4 has separate "file" and "dir" attributes to check for files > and dirs respectively). > Index: build-webapp.xml === RCS file: /home/cvspublic/jakarta-struts/build-webapp.xml,v retrieving revision 1.4 diff -r1.4 build-webapp.xml 25a26,32 > This script is known to work with Ant 1.3. It is know to fail with > Ant 1.4 due to changes in the "available" task (this build file and/or > build files it depends on checks the availability of both files and > directories with available's "file" attribute, whereas available in > Ant 1.4 has separate "file" and "dir" attributes to check for files > and dirs respectively). > Index: build-webapps.xml === RCS file: /home/cvspublic/jakarta-struts/build-webapps.xml,v retrieving revision 1.3 diff -r1.3 build-webapps.xml 7a8,15 > > This script is known to work with Ant 1.3. It is know to fail with > Ant 1.4 due to changes in the "available" task (this build file and/or > build files it depends on checks the availability of both files and > directories with available's "file" attribute, whereas available in > Ant 1.4 has separate "file" and "dir" attributes to check for files > and dirs respectively). >
RE: Bad classloading in Digester
Should I still upload the patches here, I was just going to in a few minutes, actaully? > -Original Message- > From: Scott Sanders [mailto:[EMAIL PROTECTED]] > Sent: May 1, 2001 10:38 PM > To: [EMAIL PROTECTED] > Subject: Re: Bad classloading in Digester > > > Done in Digester in commons. Thanks for the heads up Colin. > > Scott > > Craig R. McClanahan wrote: > > > > > On Tue, 1 May 2001, Scott Sanders wrote: > > > > > >> I can apply the patch to the code in > jakarta-commons-sandbox as well. > >> > >> I would assume that a dependency on JDK 1.2 is not a > problem. Someone > >> will speak up if it is not. > >> > > > > > > No, it's not a problem. Struts requires 1.2 or later. > > > > > >> Scott > >> > > > > > > Cragi > > > > > > > >> Colin Sampaleanu wrote: > >> > >> > >>> There was never any reply to this message (below) I sent > a few months ago > >>> about a problem with the method used by the Digestor for > class loading. > >>> > >>> In a number of places, it uses the old style > >>> class.forName(name); > >>> instead of the proper > >>> Thread.getCurrentThread.getContextClassLoader.loadClass(name); > >>> > >>> The second form is _much_ preferred to the first, because > the first will > >>> potentially fail in any situation where there are > multiple classloaders (one > >>> owning the other), and the Digester is used in code loaded by both > >>> classloaders (please see my original message for more details). > >>> > >>> This kind of situation is very common any time you have > something like a > >>> server (web, etc.) with containers in it, each container > having its own > >>> classloader associated with it in order to handle code > visibility and > >>> versioning. Using the digester in this situation is not > possible without > >>> modifying the code to use the second form. > >>> > >>> I am quite willing and able to upload patches to 4 > digester files to fix > >>> this, assuming they will be checked in by somebody. The > only implication is > >>> that the code will no longer run under JDK 1.1, but > Struts already needs 1.2 > >>> in any case... > >>> > >>> For more details on classloading issues in Java, here are > a couple of > >>> excellent white papers: > >>> Understanclind Class.forName(); > >>> http://www.develop.com/downloads/DynLoad.zip > >>> Exploiting the Java Virtual Machine: > >>> http://www.develop.com/downloads/DevWPJav.pdf > >>> > >>> > >>> > >>> > >>> > -Original Message- > From: Colin Sampaleanu [mailto:[EMAIL PROTECTED]] > Sent: February 22, 2001 10:06 PM > To: '[EMAIL PROTECTED]' > Subject: ClassLoader used in Digester > > > We are currently using the digester in a server we build that > uses custom > classloaders for some containers within it, which load > custom apps. > > We use the Digester in the server itself, and some of the > apps being loaded > in the containers also want to use the Digester. The problem > is that when an > app creates a Digester instance, it is created by the > parent (system) > classloader that loaded the server, since the server had > already used the > Digester and that classloader knows about it. When the > Digester then does a > Class.forName in one of its rules to create an object, it > knows nothing > about the container's ClassLoader and the classes within it. > The class is > only withing the app, and so can't be found. > > Is there any downside to changing the Digester to always use: > Thread.getCurrentThread.getContextClassLoader.loadClass(name); > instead of > class.forName(name); > > The code would no longer work in JDK 1.1, but that is already > the case... > > >>> > >> > >> > >
possible contributions to struts? code attached!
I've been developing some custom tags for our framework that runs with
Struts. Eventually, we would like to see this OR some similar functionality
incorporated into Struts. THE SOURCE CODE IS IN mslv-shared.jar. Jakarta-ORO
is also required
The tags provide the following functionality:
o Ability to store application/user state in the page and pass from page to
page using NO server state. (metabean)
o Field validation based on regular expressions. Based on Thor
Kristmundsson's excellent article at JavaWorld, but changed to store state
in the page using the metabean instead of in the session.
(http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts.html)
o Scrolling tables via javascript. Wrap this around the tables you create
with and you can create a table that scrolls entirely within
the page. This only works in IE right now, but can easily be enhanced to
work with NS4 & NS6.
To use the mslv-shared library:
1) Copy mslv-shared.jar to your \WEB-INF\lib folder.
2) Add mslv-shared.jar to your required library list.
3) Extract the .tld from the .jar & place in your WEB-INF folder.
4) Get jakarta-oro from http://jakarta.apache.org/oro/ and place the
jakarta-oro*.jar in your \WEB-INF\lib folder.
I've attached some modified pages & classes from the struts-example that
show how to use the stuff. I made the following changes to these components
of struts-example.
registration.jsp
o added tld reference
o changed to
o changed to for fullName and added pattern
validation
o Wrapped around subscription table
o Added markers to identify header and each row.
EditRegistrationAction.java
o added username to the metabean on regform.
o Once registration.jsp displays, do a view-source and you'll see the
username value in the metabean along with the validation rules for the page.
(do a search for metabean)
RegistrationForm.java
o changed to extend MetaActionForm
o added call to super.validate()
o removed fullName validation since it is validated by the ancestor using
the pattern stored in the metabean
Here's a description of each item in the mslv-shared.jar library. The source
code & compiled classes are included.
MetaTextTag
o descendant of com.mslv.webapp.tag.MetaBaseFieldTag
o replace with
o generates HTML
o named pattern -
o dynamic pattern -
MetaBaseFieldTag
o ancestor object - never instantiated directly
o descendant of org.apache.struts.taglib.html.BaseFieldTag
o added "pattern" attribute to define the validation based on a perl match
o supports "named patterns" defined by @somepattern that maps to
named.pattern.somepattern in com.mslv.webapp.res.WebApplicationResources.
o added "errorMessage" attribute to define the error message if a validation
fails - error messages are read from the APPLICATION resource file. (not the
same place the patterns are stored)
o uses MetaBean to store the pattern & errorMessage attributes (no server
state required)
o perl regular expressions are covered at http://www.perl.com
o the expression "/^[0-9]{1,5}$/" matches 0-9 (positive integers with
length between 1 & 5)
ScrollingRegionTag
o multiple scrolling regions per page are supported
o turns a table into a scrolling table.
o descendant of javax.servlet.jsp.tagext.BodyTagSupport
o place begin & end tags around an iterate tag (or any long
html table)
o use the id attribute to identify the scrolling region - id must be unique
within a page (including included pages)
o use the rows attribute to set how many rows per page
o use the string "" to separate the table header from the
table body (between & )
o use the string "" to separate the table footer from the
table body (between & )
o data is cached on the client browser
MetaBean
o use to store a hashtable of String name/value pairs as XML in a page.
o passed from page to page by framework.
MetaActionForm
o moved MetaBean generation to doEndTag() so that other tags within a form
can modify the MetaBean
o added support for validation based on perl patterns
o descendant of org.apache.struts.action.ActionForm
o change your form beans to extend this instead of ActionForm.
o allows for easy manipulation of the MetaBean.
MetaFormTag
o descendant of org.apache.struts.taglib.html.FormTag.
o replace with in .jsp
o use to suppress generation of
the hidden metabean field.
o the "metabean" attribute is optional. Any value other than "false" will
include the metabean.
o if the "metabean" attribute is not defined, the hidden metabean field will
be generated.
mslv-shared.tld
o The mslv-shared.tld file is in the META-INF\tlds folder. Use "shared" as
the prefix.
o Include syntax is <%@ taglib uri="/WEB-INF/mslv-shared.tld"
prefix="shared" %>
Notes:
o Jakarta-ORO is required. http://jakarta.apache.org/oro/
o There is still much to be done. But I thought if these were released now,
people might have ideas for improvement.
o Add a bunch of mail accounts for a user to see the scrolling table work.
I've got the rows="2", of course you can change it to p
html:options collection attribute
I'm not if this has ben pointed out before (way too much email at the moment)
but I find that the tag has some discrepency in the collection
attribute. At the moment I do this:
<% pageContext.setAttribute("catalog", ((SystemManager)
application.getAttribute(SystemManager.THIS)).getCatalog("skill_catalog_user_years").entrySet());
%>
">
Sorry about the long property value, I have fairly heavily nested structures at the
moment,
(A subject for a longer email).
I would expect the html:options collection to be more like the logic:iterate
collection and
take something like
so I didn't have to set a pageContext as I do now before the html:select tag.
Any comments?
--
Kumera - a new Open Source Content Management System
for small to medium web sites written in Perl and using XML
http://www.cyber4.org/kumera/index.html
