Re: make template content classes serializable

[Craig R. McClanahan]

It is on my list (if nobody beats me to it).  Got stuck in an all
day meeting today.
Craig
 
"Deadman, Hal" wrote:
Sorry
to resubmit this request and excuse me if there hasn't been time to address
this. Is
there a reason that the Content and ContentMap classes can't be made Serializable?
They are stored in the PageContext in the request scope by ContentMapStack.
I don't know why Weblogic 6.0 tries to serialize objects in the request
scope when it re-compiles JSPs but I don't really understand the issues
that well. Making
the classes implement Serializable in my struts build allows me to modify
JSPs that use templates and have weblogic re-compile them without bouncing
the server. Let
me know if this doesn't make sense or if it might be a problem. -Original
Message-
From: Hal Deadman [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 14,
2001 8:11 PM
To: 'Struts Dev List'
Subject: make template content
classes serializable
 
Can
someone make org\apache\struts\taglib\template\util\Content.java and org\apache\struts\taglib\template\util\ContentMap.java
implement Serializable? Otherwise, when I modify a JSP that uses templates
the auto re-compiling of a modified JSP in weblogic 6.0 doesn't work. It
doesn't look like there are any members of those classes that aren't Serializable. 

Re: cvs commit: jakarta-struts/src/share/org/apache/struts/util MessageResources.java MessageResourcesFactory.java

[Craig R. McClanahan]

Johan Compagner wrote:

> What about the GenericDataSource printwriter?
>
> Isn't it possible to have somewhere a static method that returns the printwriter
> like this:
>
> public static PrintWriter getLogWriter()
> {
> if(logWriter == null)
> {
> // Create the LogWriter
> }
> return logWriter;
> }
>
> Then you can call to that methods from all the locations you want and
> don't need to worry about serialization.
>

For GenericDataSource itself, I was not planning on changing anything -- the
remainder of the class cannot be serialized because of the
Connections themselves cannot be serialized.

For MessageResources this approach would work OK, but I'm not sure it is enough
of a "value add" to really worry about for debugging
messages.

>
> johan
>

Craig


>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, January 16, 2001 4:52 AM
> Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/util 
>MessageResources.java MessageResourcesFactory.java
>
> > craigmcc01/01/15 19:52:58
> >
> >   Modified:src/share/org/apache/struts/action ActionServlet.java
> >src/share/org/apache/struts/util MessageResources.java
> > MessageResourcesFactory.java
> >   Log:
> >   Desupport the concept of a configurable PrintWriter for logging messages
> >   from a MessageResources implementation.  This is the short term fix for
> >   the problem of MessageResources not being Serializable.
> >
> >   Revision  ChangesPath
> >   1.55  +4 -7  
>jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
> >
> >   Index: ActionServlet.java
> >   ===
> >   RCS file: 
>/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v
> >   retrieving revision 1.54
> >   retrieving revision 1.55
> >   diff -u -r1.54 -r1.55
> >   --- ActionServlet.java 2001/01/07 22:39:06 1.54
> >   +++ ActionServlet.java 2001/01/16 03:52:57 1.55
> >   @@ -1,7 +1,7 @@
> >/*
> >   - * $Header: 
>/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v 1.54 
>2001/01/07 22:39:06 craigmcc
> Exp $
> >   - * $Revision: 1.54 $
> >   - * $Date: 2001/01/07 22:39:06 $
> >   + * $Header: 
>/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v 1.55 
>2001/01/16 03:52:57 craigmcc
> Exp $
> >   + * $Revision: 1.55 $
> >   + * $Date: 2001/01/16 03:52:57 $
> > *
> > * 
> > *
> >   @@ -90,7 +90,6 @@
> >import org.apache.struts.util.MessageResources;
> >import org.apache.struts.util.MessageResourcesFactory;
> >import org.apache.struts.util.RequestUtils;
> >   -import org.apache.struts.util.ServletContextWriter;
> >import org.xml.sax.AttributeList;
> >import org.xml.sax.SAXException;
> >
> >   @@ -229,7 +228,7 @@
> > * 
> > *
> > * @author Craig R. McClanahan
> >   - * @version $Revision: 1.54 $ $Date: 2001/01/07 22:39:06 $
> >   + * @version $Revision: 1.55 $ $Date: 2001/01/16 03:52:57 $
> > */
> >
> >public class ActionServlet
> >   @@ -955,8 +954,6 @@
> >if (debug >= 1)
> >log(internal.getMessage("applicationLoading", value));
> >try {
> >   -MessageResourcesFactory.setDefaultWriter
> >   -(new ServletContextWriter(getServletContext()));
> >String oldFactory =
> >MessageResourcesFactory.getFactoryClass();
> >if (factory != null)
> >
> >
> >
> >   1.8   +10 -18
>jakarta-struts/src/share/org/apache/struts/util/MessageResources.java
> >
> >   Index: MessageResources.java
> >   ===
> >   RCS file: 
>/home/cvs/jakarta-struts/src/share/org/apache/struts/util/MessageResources.java,v
> >   retrieving revision 1.7
> >   retrieving revision 1.8
> >   diff -u -r1.7 -r1.8
> >   --- MessageResources.java 2001/01/10 22:06:55 1.7
> >   +++ MessageResources.java 2001/01/16 03:52:57 1.8
> >   @@ -1,7 +1,7 @@
> >/*
> >   - * $Header: 
>/home/cvs/jakarta-struts/src/share/org/apache/struts/util/MessageResources.java,v 1.7 
>2001/01/10 22:06:55 craigmcc
> Exp $
> >   - * $Revision: 1.7 $
> &

Latest and Greatest 1.0 User's Guide

[Craig R. McClanahan]

I've just posted the most recent version of the Struts documentation on the
Struts web site at:

http://jakarta.apache.org/struts/

The User's Guide pages have had the XSLT stylesheet used to create them spruced
up a bit, so that the visual appearance is similar to the rest of the Struts
documentation.

Craig McClanahan

Re: Latest and Greatest 1.0 User's Guide

[Craig R. McClanahan]

[EMAIL PROTECTED] wrote:

> Hi Craig and lists,
>
> Is there are requirement NOT to use Frames? When viewing stuff that has a
> nice TOC, it is easier to relate to the 'Quick Links' if they gave you a
> sense of context. For example, I can't easily go from 'Controller
> Components' to  the Digester Guide...
>
> Using frames typically means smaller page sizes and easier navigability,
> although the same effect can be achieved without them.
>
> I'm happy to do a prototype with the current style sheets...

I personally don't have strong opinions one way or the other about frames
(although I know many web designers who do :-.  However, since we're using
stylesheets anyway, maybe we could set things up to render *both* ways so that
users can have their choice?

I'd welcome the help of someone who is better at XSLT stylesheets than I am to
set this kind of stuff up.

>
> --
> dIon Gillard, Multitask Consulting

Craig

Re: Latest and Greatest 1.0 User's Guide

[Craig R. McClanahan]

Ted Husted wrote:

> Very, very kewl.
>
> Short Term Plan
>
> I'm about through the Users Guide, and will refresh my CVS and post
> some very minor  fixes.
>
> I'll also update the struts.xls to reflect a 2001 copyright (forward
> into the present!)
>
> Meanwhile,
>
> Any thoughts on a better approach to formatting the example code. I've
> seen the same problem with other subprojects.
>

The most important issue is to use spaces rather than tabs inside a 
block.  The whitespace you use is copied verbatim.

In the page source, I typically left justify my  blocks, and use four
spaces of indent in front of the code lines.

>
> Also (extremely nitty but), The chapter title (2. Building Model
> Components) is not  displayed over the first section (2.1 Overview).
>

It's the title of the HTML document -- isn't that good enough?  If not, that is
a pretty straightforward change.

>
> Don't know enough about XML/XLS to even think about messing with the
> stylesheet to address either concern.
>
> -Ted.

Craig

Re: cvs commit: jakarta-struts/src/doc/stylesheets struts.xsl

[Craig R. McClanahan]

Ted Husted wrote:

> Please note that I made another commit this morning, but apparently the
> message did not go through. (Too long?)
>

Commit messages (or any messages, for that matter) > 100k will be bounced back
to the original sender.  When this has happened to me, I've been able to cut and
paste just the commentary out of the commit message, and post that separately to
the mailing list for posterity.

>
> I committed several minor changes to the user guide, and fixed some of
> the links.
>
> Unforutnately, I deleted my notes after posting the commit, so can't be
> more specific.
>
> -T.
>

Craig

Re: cvs commit: jakarta-struts/src/doc/stylesheets struts.xsluserGuide.xsl

[Craig R. McClanahan]

Ted Husted wrote:

> The three forms that are specified by law are the circled c, "Copyr.",
> or "Copyright", which must then be followed by the date and the name of
> the Copyright holder. The symbol is not required if "Copyr." or
> "Copyright" is used. There is probably no harm with injecting (c) so
> long as Copyright or Copyr. is also present. (Especially for us, since
> it is set forth that way in the ASL License.)
>

IANAL, but the (c) version has been used in all of the ASCII based source files
I have ever seen.  With Ted's comments above, I'm fine with switching to "(c)"
in the HTML versions as well, since we do have the word "Copyright" present.

Craig


>
> *** REPLY SEPARATOR  ***
>
> On 1/22/2001 at 10:02 AM Michael Westbay wrote:
>
> Husted-san wrote:
>
> > (c) isn't actually legal. Though, Copyright with the date is just as
> > good as the symbol.
>
> Isn't legal?  That's an odd one.  Is a small, half-pitched katakana "u"
> in its place legal?  That's what I used to see back when I used
> Windows.
> Now I see either a "?" or nothing at all due to different font sets on
> UNIX.
>
> If a circled "c" is the only allowable gliph, then I guess an image
> would
> be necessary for the highest international appeal.
>
> (Japanese sites tend to either use "(c)" or "(C)".  Does that mean that
> none of them are actually being protected by copyright?)
>
> --
> Michael Westbay
> Work: Beacon-IT http://www.beacon-it.co.jp/
> Home:   http://www.seaple.icc.ne.jp/~westbay
> Commentary: http://www.japanesebaseball.com/
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/about/struts/

Re: Printing issue with 1.0 User's Guide

[Craig R. McClanahan]

"Steven D. Wilkinson" wrote:

> It's not just the code it's the documentation.  It even runs off the page in
> landscape mode.  You really need to print out section 4 and see what I'm talking
> about.
>

The reason this happens is that browsers format pages based on the width of the
widest section of the page.  In the case of Section 4, that is the  sections
that include the code examples -- because they are wide (all the tab characters),
the browser formats the rest of the page at the same width.

Correcting the tabs will correct this.

Craig

>
> Ted Husted wrote:
> >
> > It's probably embedded tabs in the examples. I'll run them through my
> > text editor tonight, and convert everything to spaces.
> >
> > *** REPLY SEPARATOR  ***
> >
> > On 1/21/2001 at 7:30 PM Steven D. Wilkinson wrote:
> >
> > When I try printing the User's Guide in portrait mode the text runs off
> > the
> > page.  If I change to landscape it's ok.  Was this fixed in the "Latest
> > and
> > Greatest" changes?  If not can someone look into it?
> >
> > Thanks in advance,
> > Steve
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Custom Software ~ Technical Services.
> > -- Tel 716 425-0252; Fax 716 223-2506.
> > -- http://www.husted.com/about/struts/
>
> --
> -
> Steven D. Wilkinson, [EMAIL PROTECTED]

Re: PROPOSAL: a User implementation Option for getting and setting property's with PropertyUtils

[Craig R. McClanahan]

Johan Compagner wrote:

> Hi,
>
> I myself really need this implementation so i am hoping that it can be inserted in 
>Struts 1.0.
> If not then i must alway's use a slightly altered struts version :-(
>

Johan, it is not clear to me what you're trying to accomplish with these changes.  Is 
it just that you only want
a subset of the properties available to be retrieved or set through PropertyUtils?  If 
so, you might investigate
using a BeanInfo class along with your form bean.  This allows you to customize the 
set of properties available
-- and even change method names if you want to.  The Java introspection logic fully 
supports this, so it will get
used automatically by PropertyUtils.

See the JavaBeans specification for more info, at:

http://java.sun.com/products/javabeans/docs/spec.html

Craig


>
> What i want:
>
> I want to control my own implementation of getting and setting property's for a 
>specifiek bean of mine
> when using struts. The bean i want to control the setting and getting of properties 
>is a Form bean of mine
> so i need to alter struts it self  because struts uses PropertyUtils for this. I 
>can't have a get and set for
> every property.
>
> What i altered:
>
> I inserted a Interface in the struts.util package:
>
> public interface Property
> {
> public Object getProperty(String);
> public void setProperty(String,object);
> }
>
> So if a bean wants to control it's own property's it must implement that interface.
>
> PropertyUtils.getSimpleProperty(Object bean, String name){
>  if(bean instanceof Property) {
>   return ((Property)bean).getProperty(name);
>  }
>  else {
> // CURRENT IMPLEMENTATION.
>   }
> }
>
> and
>
> PropertyUtils.setSimpleProperty(Object bean, String name, Object value){
>  if(bean instanceof Property) {
>   ((Property)bean).setProperty(name, value);
>  }
>  else {
> // CURRENT IMPLEMENTATION.
>  }
> }
>
> I only implemented the SimpleProperty at this time, maybe the same should be done 
>with indexed.
> But if a bean implements the Property Interface the PropertyUtils class is relaying 
>this to
> the bean it self.
>
> Also the BeanUtils.populate(Object bean, Map properties) had to change a bit because
> that method is trying to get the PropertyDescriptor for a given name and it none is 
>found
> it won't call the PropertyUtils.setProperty(bean, name, parameters[0]);
>
> the method:
>
>  // Loop through the property name/value pairs to be set
>  Iterator names = properties.keySet().iterator();
>
>  if(bean instanceof Property) {
>   while (names.hasNext())  {
>String name = (String) names.next();
>if (name == null) continue;
>Object value = properties.get(name); // String or String[]
>Object parameters[] = new Object[1];
>if (value instanceof String[])   {
> parameters[0] = ((String[])value)[0];
>}
>else {
> parameters[0] = value;
>}
>try{
> PropertyUtils.setProperty(bean, name, parameters[0]);
>}
>catch (NoSuchMethodException e) {
> if (debug >= 1) {
>  System.out.println("CANNOT HAPPEN: " + e);
>  e.printStackTrace(System.out);
> }
>}
>   }
>  }
>  else{
>   while (names.hasNext()) {
> // CURRENT IMPLEMENTATION
>  }
> }
>
> I attached all the files.
>
> Johan Compagner
>
>   
>  Name: PropertyUtils.java
>PropertyUtils.javaType: unspecified type (application/octet-stream)
>  Encoding: quoted-printable
>
> Name: Property.java
>Property.javaType: unspecified type (application/octet-stream)
> Encoding: 7bit
>
>  Name: BeanUtils.java
>BeanUtils.javaType: unspecified type (application/octet-stream)
>  Encoding: quoted-printable

Re: release()

[Craig R. McClanahan]

Wong Kok Wai wrote:

> A general question:
>
> I've noticed in the implementation of release method in the tags, there
> is always a call to super.release(). The exception being the template
> tags. My question is: is calling super.release() a best practise and
> why? If so, should the template tags also follow this practise?
>

If your class is a subclass of another, and you want to execute the superclass's
functionality along with your own (which is usually the case on release() in a
custom tag), then you should call super.release().

The template tags all extend TagSupport or BodyTagSupport, which *currently*
have do-nothing release() methods, but it would be good form to call
super.release() in these cases just in case functionality gets added there
later.  David, do you want to go ahead and make those changes?

>
> TIA!

Craig

Re: Printing issue with 1.0 User's Guide

[Craig R. McClanahan]

Ted Husted wrote:

> As of the 1/22 build, the User Guide should print well in landscape
> mode.
>

How about portrait mode?  If need be, we can wrap the code lines of the examples
so that they don't extend so far (just like we align code to 80 column width).

Craig


>
> *** REPLY SEPARATOR  ***
>
> On 1/22/2001 at 10:43 AM Craig R. McClanahan wrote:
>
> "Steven D. Wilkinson" wrote:
>
> > It's not just the code it's the documentation.  It even runs off the
> page in
> > landscape mode.  You really need to print out section 4 and see what
> I'm talking
> > about.
> >
>
> The reason this happens is that browsers format pages based on the
> width of the
> widest section of the page.  In the case of Section 4, that is the
>  sections
> that include the code examples -- because they are wide (all the tab
> characters),
> the browser formats the rest of the page at the same width.
>
> Correcting the tabs will correct this.
>
> Craig
>
> >
> > Ted Husted wrote:
> > >
> > > It's probably embedded tabs in the examples. I'll run them through
> my
> > > text editor tonight, and convert everything to spaces.
> > >
> > > *** REPLY SEPARATOR  ***
> > >
> > > On 1/21/2001 at 7:30 PM Steven D. Wilkinson wrote:
> > >
> > > When I try printing the User's Guide in portrait mode the text runs
> off
> > > the
> > > page.  If I change to landscape it's ok.  Was this fixed in the
> "Latest
> > > and
> > > Greatest" changes?  If not can someone look into it?
> > >
> > > Thanks in advance,
> > > Steve
> > >
> > > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > > -- Custom Software ~ Technical Services.
> > > -- Tel 716 425-0252; Fax 716 223-2506.
> > > -- http://www.husted.com/about/struts/
> >
> > --
> > -
> > Steven D. Wilkinson, [EMAIL PROTECTED]
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/about/struts/

Re: PROPOSAL: a User implementation Option for getting and setting property's with PropertyUtils

[Craig R. McClanahan]

Support for the whole concept of "dynamic" beans (i.e. beans where the properties are 
looked up from an internal collection
rather than having explicit getters and setters) is high on my list for 1.1.  Having 
thought a little about this, there are
*lots* of changes needed to add this concept seamlessly, and I'd prefer to wait until 
then before starting to add capabilities
piecemeal.  Does that sound reasonable?

Craig


Johan Compagner wrote:

> - Original Message -----
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, January 22, 2001 7:47 PM
> Subject: Re: PROPOSAL: a User implementation Option for getting and setting 
>property's with PropertyUtils
>
> > Johan Compagner wrote:
> >
> > > Hi,
> > >
> > > I myself really need this implementation so i am hoping that it can be inserted 
>in Struts 1.0.
> > > If not then i must alway's use a slightly altered struts version :-(
> > >
> >
> > Johan, it is not clear to me what you're trying to accomplish with these changes.  
>Is it just that you only want
> > a subset of the properties available to be retrieved or set through PropertyUtils? 
> If so, you might investigate
> > using a BeanInfo class along with your form bean.  This allows you to customize 
>the set of properties available
> > -- and even change method names if you want to.  The Java introspection logic 
>fully supports this, so it will get
> > used automatically by PropertyUtils.
>
> I looked at the source of PropertyUtils a bit more. (BeanInfo in my mind)
> but this doesn't work,
> because PropertyUtils does this when getting a property from a bean.
>   Object value = readMethod.invoke(bean, new Object[0]);
>
> See the new Object[0] (so no arguments!!)
>
> And that doesn't work because the argument of getting a property is a String (the 
>property name)
>
> Look this is my Form Bean (a bit cut down)
>
> class DynamicFormBean {
> private Hashmap _hmValues;
>
> // Setting a property. The name of the property must exists
> public setProperty(String sName, Object value) {
> if(_hm.get(sName) != null) {
> _hm.put(sName, value)
> }
> }
>
> // getting a property
> public Object getProperty(String sName) {
> return _hm.get(sName);
> }
>
> // Called by the database loader.
> // The Hashmap is has all the attributes of this Form
> // Those attributes are loaded from the database (and the values if a object 
>exits for that request are filled in)
> public void setBeginValues(Hashmap hm) {
> _hmValues = hm;
> }
> }
>
> So the a database has the description of what properties a specifiek form (object) 
>has
> So when i want another value i only have to add another attribute in the database 
>form description
> and that value can be entered or asked in the jsp file of that form!
>
> Everything is completly dynamic. I don't know nothing about the properties a 
>specifiek form will have
> at compile time. Only at runtime the database will define what kind of properties a 
>specifiek form has
> (can ask and store back in the database)
>
> So you see that using the BeanInfo or whatever won't work!
> The PropertyUtil methods must just relay all the getProperty(String sName) and 
>setProperty(String sName, Object value)
> to the DynamicForm. No introspection can be used because the properties get's and 
>set's aren't there.
>
> I must have this abillity because i want to/must make a financial theme 'generator'
> (not really a generator because there won't be any code generated)
>
> Every object, attribute, flow, rule must be declerative.
>
> Johan C.

Re: Adding roles to the action-mappings?

[Craig R. McClanahan]

[EMAIL PROTECTED] wrote:

> Hello!
>
> Has anyone considered whether it would be valuable to have roles defined
> against the action definitions within struts-config.xml, and have the
> controller servlet automatically validate whether the user is in the
> necessary roles to execute the action prior to calling it? Has this been
> proposed for 1.1?
>

I assume you're talking about the roles associated with security constraints in
the web.xml file, right?  If so, that's a pretty interesting idea.  I will add
it to the 1.1 TODO list.

In the mean time, you can define security constraints in web.xml that protect
each action individually (for example, a URL pattern of "/saveCustomer.do"), but
it's pretty tedious.

>
> Regards,
> James W.
>

Craig

Re: PROPOSAL: Token Tag

[Craig R. McClanahan]

Rob Leland wrote:

> Since I haven't seen the TokenTag material that I submitted
> in October 10th, make it into struts I am assuming it won't be in 1.0.
>
> Could we place that on the TODO list for 1.1 ?
> It is definately a valuable utility.

>
> Craig, what was your thinking on it ?
>
> A) Was it going to remain a tag.
> B) Make use of filters ala tomcat 4.0.
> C) Be incorporated into a struts base class.
> D) Be included in the struts user supplied extensions.

This actually did get integrated, although not (solely) as a tag.

My thinking, after looking at the various approaches and use cases, was that it
is really up to an Action to decide when to impose tokens, and to check them.
Therefore, some additional methods got added to the Action base class to support
it:
protected String generateToken(HttpServletRequest request);
protected boolean isTokenValid(HttpServletRequest request);
protected void resetToken(HttpServletRequest request);
protected void saveToken(HttpServletRequest request);

These methods are used in the Struts example application to protect against
double posting the "Save" transaction -- see the code in EditRegistrationAction
that sets the token, and in SaveRegistrationAction that checks and then resets
it.  The  tag automatically creates a hidden variable for the token
if it has been set, so no changes in the JSP pages themselves are required.

Craig

Re: Could Struts manage InitialContext's as well as DataSources?

[Craig R. McClanahan]

[EMAIL PROTECTED] wrote:

> Hello all,
>
> Currently, Struts has the capability to manage javax.sql.DataSources for
> accessing JDBC connections... I was pondering whether it might also be
> useful to have it manage InitialContext's...
>

Some of the considerations you identify below are why managing the JNDI
InitialContext is really the job of the container.  All J2EE-compliant
containers already do this for you, and many other containers (such as Tomcat
4.0) are adding support for it as well.  In all such cases, trying to manage the
initial context at the application level (which is where Struts lives) would
interfere with the container-provided support, and/or be prevented by security
managers employed by the container anyway.

If you are running in an app server environment that allows you to identify data
sources in the web.xml file, and access them through a JNDI InitialContext (in
the standard J2EE manner), I would suggest that you use that approach.

Craig


>
> Consider the following fragment of XML that might be taken from a
> struts-config.xml...
>
> 
> initialContextFactory="your.factory.class.here"
>   providerUrl="jndi:/some/url/here"
>   securityPrincipal="username"
>   securityCredentials="password"
>   (+ other attributes to support the standard JNDI properties as
> defined by javax.naming.Context)>
>   value
>   value
>  
> ...
>  
> 
>
> Similar to findDataSource(String), ActionServlet would have a
> javax.naming.Context findNamingContext(String) method.
>
> The issues are primarily these:
>
> 1. findNamingContext() would probably (???) need to return Contexts on a
> per user session basis.

In most environments, the context is actually per-webapp.  This gets really
interesting to implement when there is no a priori association with a particular
request thread to a particular app.

>
> 2. Whilst forcing all Contexts returned to use the same principal and
> credentials (as in the above example) is fine for some circumstances
> (looking up records on an LDAP server) it is definately not for others
> (such as connecting to an EJB container) where you want to propagate the
> identity of the user in some fashion.

This is one of the main reasons that EJB servers are doing their own
integrations with a servlet container (such as the way that EBoss uses Tomcat
3.2).

> I guess if you chose to omit the
> securityPrincipal and securityCredentials from the specific naming-context,
> then depending on which container you are using (as an example, Weblogic
> which is both a servlet and EJB container) it will probably figure out
> which user it is and whether they are sufficiently authenticated. If
> however the servlet and EJB containers are separate products (for example,
> Tomcat and JBoss), and possibly running different JVMs (for whatever
> reason), then this is all complicated some what. Is there still some way
> though, of solving this generically within Struts in a reasonably
> satisfactory manner? Possibly JAAS comes into play here, but I believe the
> way in which JAAS integrates with the Servlet model is still a bit unclear.

I would picture the relationship like this:

Application <--ServletAPI--> Servlet Container <--JAAS API-->Security Realm

In other words, how the servlet container looks up usernames and passwords is
totally invisible to the application -- all you do is define what security roles
you want to use to protect the various URIs in your application.

Many servlet containers today provide a proprietary API in the spot where JAAS
is shown in the above picture.  For example, in Tomcat 4.0, you can create your
own implementation of org.apache.catalina.Realm to interface to any source of
usernames and passwords that you want.  But it is all "behind the curtain" from
the viewpoint of the web application.


>

>
> Thoughts?
>
> Regards,
> James W.
>

Craig

Re: cvs commit: jakarta-struts/src/share/org/apache/struts/util MessageResourcesFactory.java

[Craig R. McClanahan]

"Deadman, Hal" wrote:

> Thanks, this will make Weblogic users very happy. I am curious why the Class
> variable had to be made transient since it implements Serializable. It would
> be nice to know for future reference. Does it have to do with it storing a
> reference to a Class loaded by a different class loader?
>

That was definitely the motivation.

Consider that many servlet containers support automatic reloading of a webapp
when you change a class.  Normally, this is done by throwing away the class
loader that loaded this class, and reloading everything with a new one.  In that
manner, any changes to the classes will be picked up.

Now, what would happen if this variable had been left non-transient?  The *old*
version of the class would be saved and restored, and any change you made to it
would not be visible!  That's not what you want in this scenario.

Proper serialization behavior isn't just a matter of declaring things
Serializable.  You also have to ensure that serializing and then deserializing
your object tree does not violate other assumptions you have made -- this is
why, for example, I cannot simply make the pseudo-database in the example app
Serializable -- when it's reloaded, the assumption that there is only one root
of the tree would now be violated.

>
> Thanks, Hal
>

Craig


>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 24, 2001 12:26 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/util
> MessageResourcesFactory.java
>
> craigmcc01/01/24 09:25:37
>
>   Modified:src/share/org/apache/struts/util
> MessageResourcesFactory.java
>   Log:
>   Make MessageResourcesFactory (and therefore subclasses of it)
>   Serializable.
>
>   Revision  ChangesPath
>   1.3   +9 -6
> jakarta-struts/src/share/org/apache/struts/util/MessageResourcesFactory.java
>
>   Index: MessageResourcesFactory.java
>   ===
>   RCS file:
> /home/cvs/jakarta-struts/src/share/org/apache/struts/util/MessageResourcesFa
> ctory.java,v
>   retrieving revision 1.2
>   retrieving revision 1.3
>   diff -u -r1.2 -r1.3
>   --- MessageResourcesFactory.java  2001/01/16 03:52:57 1.2
>   +++ MessageResourcesFactory.java  2001/01/24 17:25:36 1.3
>   @@ -1,7 +1,7 @@
>/*
>   - * $Header:
> /home/cvs/jakarta-struts/src/share/org/apache/struts/util/MessageResourcesFa
> ctory.java,v 1.2 2001/01/16 03:52:57 craigmcc Exp $
>   - * $Revision: 1.2 $
>   - * $Date: 2001/01/16 03:52:57 $
>   + * $Header:
> /home/cvs/jakarta-struts/src/share/org/apache/struts/util/MessageResourcesFa
> ctory.java,v 1.3 2001/01/24 17:25:36 craigmcc Exp $
>   + * $Revision: 1.3 $
>   + * $Date: 2001/01/24 17:25:36 $
> *
> * 
> *
>   @@ -63,6 +63,9 @@
>package org.apache.struts.util;
>
>   +import java.io.Serializable;
>   +
>   +
>/**
> * Factory for MessageResources instances.  The general
> usage
> * pattern for this class is:
>   @@ -78,10 +81,10 @@
> * 
> *
> * @author Craig R. McClanahan
>   - * @version $Revision: 1.2 $ $Date: 2001/01/16 03:52:57 $
>   + * @version $Revision: 1.3 $ $Date: 2001/01/24 17:25:36 $
> */
>
>   -public abstract class MessageResourcesFactory {
>   +public abstract class MessageResourcesFactory implements Serializable {
>
>//  Instance
> Properties
>   @@ -121,7 +124,7 @@
> * The Java class to be used for
> * MessageResourcesFactory instances.
> */
>   -protected static Class clazz = null;
>   +protected static transient Class clazz = null;
>
>/**

Re: cvs commit: jakarta-struts/src/doc installation.xml

[Craig R. McClanahan]

Colin Sampaleanu wrote:

> care to clarify the rationale for this? (I'm just curious, I've always set
> up my projects so anything under /src lives in source control)
>

Yes .. you're likely to see similar changes on other Jakarta subprojects as
well.  (Modifying files outside your source directory is highly offensive to
some developers, and I'm starting to see the light about why :-).

Consider the fact that we're about to release Struts 1.0, and happily start
working on Struts 1.1 (in a branch of the jakarta-struts repository).  Now, it
is quite likely that any post-release bug found in 1.0 will also affect 1.1, so
I'm going to want to keep both versions checked out.  No problem, I can do that,
by renaming my source directories "jakarta-struts-1.0" and "jakarta-struts-1.1".

But now, when I go do a build, the output from one version steps on the
"../build/struts" and "../dist/struts" directories of the other version :-(.

This could be fixed by maintaining version numbers in the build directory names
(by changing the "build.home" value to "../build/struts-1.1" for example), but
it just seems cleaner to keep everything localized.  The "build" and "dist"
directories will automatically be version-specific, with no chance for
corrupting each other.

NOTE:  Even though the "build" and "dist" directories will be wtihin the source
directory, they will *not* be checked in to CVS.  As soon as the server lets me
back in, I've got a ".cvsignore" file to add that will keep CVS from whining
about unregistered directories.

Craig


>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: January 24, 2001 4:57 PM
> > To: [EMAIL PROTECTED]
> > Subject: cvs commit: jakarta-struts/src/doc installation.xml
> >
> >
> > craigmcc01/01/24 13:57:27
> >
> >   Modified:.build.xml
> >src/doc  installation.xml
> >   Log:
> >   Change the Struts build process to place the "build" and "dist"
> >   directories *inside* the source directory, rather than up and over
> >   ("../build/struts" and "../dist/struts") as they are now.  Tweak the
> >   installation documentation to reflect this.
> >
> >   Revision  ChangesPath
> >   1.33  +2 -2  jakarta-struts/build.xml
> >
> >   Index: build.xml
> >   ===
> >   RCS file: /home/cvs/jakarta-struts/build.xml,v
> >   retrieving revision 1.32
> >   retrieving revision 1.33
> >   diff -u -r1.32 -r1.33
> >   --- build.xml   2001/01/20 00:32:43 1.32
> >   +++ build.xml   2001/01/24 21:57:26 1.33
> >   @@ -2,11 +2,11 @@
> >
> >  
> >  
> >   -  
> >   +  
> >  
> >  
> >  
> >   -  
> >   +  
> >  
> >  
> >  
> >
> >
> >
> >   1.8   +5 -4  jakarta-struts/src/doc/installation.xml
> >
> >   Index: installation.xml
> >   ===
> >   RCS file: /home/cvs/jakarta-struts/src/doc/installation.xml,v
> >   retrieving revision 1.7
> >   retrieving revision 1.8
> >   diff -u -r1.7 -r1.8
> >   --- installation.xml2001/01/12 05:24:58 1.7
> >   +++ installation.xml2001/01/24 21:57:27 1.8
> >   @@ -101,9 +101,10 @@
> >
> >
> >This command will create a binary distribution of
> > Struts, in a
> >   -directory named ../dist/struts (relative
> > to where you
> >   +directory named dist (relative to where you
> >are compiling from).  This directory contains an exact
> > replica of the
> >   -files included in a binary distribution of Struts.
> >   +files included in a binary distribution of Struts, as described
> >   +in the following section.
> >
> >  
> >
> >   @@ -138,13 +139,13 @@
> >You can install this web application on any
> > servlet container
> >compatible with the Servlet 2.2 (or later) and JSP
> > 1.1 (or later)
> >specifications.
> >   +webapps/struts-template.war -
> > This web application
> >   +both introduces and demonstrates the Struts
> > template tags.
> >webapps/struts-test.war - This
> > web application
> >contains test pages for the various custom tags
> > supported by Struts.
> >It is primarily of use to developers who are
> > enhancing the Struts
> >custom tag libraries, but may also be useful as
> > simple examples of
> >the usage of various Struts tags.
> >   -webapps/struts-template.war -
> > This web application
> >   -both introduces and demonstrates the Struts
> > template tags.
> >webapps/struts-upload.war - This
> > web application
> >is a quick example of uploading files using the
> > Struts framework.
> >
> >
> >
> >
> >

Re: Struts installation notes for Resin

[Craig R. McClanahan]

Ted Husted wrote:

> +1 -- just tested this and it works like a charm.
>
> Before adding it to install -- do you think we should add
>
> --
>
> * Resin will unpack the war to $RESIN_HOME/work/_war/$ID and the
> application folder will not appear under docs.
>
> * When developing your own applications, you can create a new folder
> under $RESIN_HOME/doc and modify the file "$RESIN_HOME/conf/resin.conf"
> to recognize your application, for example:
>
> 
>
>Resin will then read your application's configuration from
> WEB-INF/web.xml
>
> --
>
> Or is that getting that too far into the specifics of a container's
> implementation?
>

I think a few hints about how to organize your own application development on a
given platform, as with your proposed text above, would be useful.  We don't
want to reproduce the Developer Docs for every platform :-), but an initial
pointer in the right direction makes a lot of sense.

Craig

Re: Adding roles to the action-mappings?

[Craig R. McClanahan]

Taylor Cowan wrote:

> I might not understand the context well enough to comment, but before anyone
> starts writing new "pluggable security adapters" isn't that what JAAS is?
>

Yes, if you're running JDK 1.3 or later.

As I pointed out in my earlier response, I view pluggable security adapters as
in the realm of a container, not in the realm of an application.

>
> Taylor
>

Craig


>
> - Original Message -
> From: "Alec Bau" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, January 25, 2001 3:44 PM
> Subject: Re: Adding roles to the action-mappings?
>
> > I'm also very strongly in favor of this idea! Moreover, imo, Struts should
> include
> > some simple  pluggable security (Tomcat realm based perhaps)  adapter with
> default
> > implementation that wraps Tomcat's realms. I'm sure community will donate
> > implementations specific to other containers (WebSphere, WebLogic, etc.).
> This way
> > Struts app becomes more independent and portable between various
> containers so one
> > can develop and test his app including security stuff, for example, on
> Tomcat on his
> > personal box and then deploy the app with minimal hassle to shared
> test/production
> > servers that run, in our case, WebSphere & ServletExec. I'm sure a big
> chunk of
> > current Tomcat realm api's & implementation can be used as a base.
> >
> > "Craig R. McClanahan" wrote:
> >
> > > [EMAIL PROTECTED] wrote:
> > >
> > > > Hello!
> > > >
> > > > Has anyone considered whether it would be valuable to have roles
> defined
> > > > against the action definitions within struts-config.xml, and have the
> > > > controller servlet automatically validate whether the user is in the
> > > > necessary roles to execute the action prior to calling it? Has this
> been
> > > > proposed for 1.1?
> > > >
> > >
> > > I assume you're talking about the roles associated with security
> constraints in
> > > the web.xml file, right?  If so, that's a pretty interesting idea.  I
> will add
> > > it to the 1.1 TODO list.
> > >
> > > In the mean time, you can define security constraints in web.xml that
> protect
> > > each action individually (for example, a URL pattern of
> "/saveCustomer.do"), but
> > > it's pretty tedious.
> > >
> > > >
> > > > Regards,
> > > > James W.
> > > >
> > >
> > > Craig

Re: ConvertUtils

[Craig R. McClanahan]

Ralph Schaer wrote:

> Hello
>
> Short comment about the ConvertUtils.convert... Methods.
> All convert methods returns zero when the String is not a valid value.
>
> Isn't this very dangerous, because zero can be a reasonable value in an
> application?
>

I'm open to suggestion on alternatives.

The problem is that there is nothing in the range of most of the primitive types
(byte, char, int, long) that corresponds to a "null" value for an object
reference.  The only thing we can do is:
* Pick one particular value to be ambiguous ("did the user
  really type a zero or not?").
* Throw a conversion exception, which just throws the
  same decision back up a level.

>
> Ralph

Craig

Re: LinkTag

[Craig R. McClanahan]

Howard Moore wrote:

> Another tag modification for consideration.
>
> I've modified the LinkTag so that if both name and linkName are specified a
> link to a target on a page is built. For example this;
>
> 
>
> now produces this;
>
> 
>

Is there a particular reason that doing it this way would be better than:



?  I'm concerned about making it hard to understand what the linkName attribute
is for.

>
> ---
> Howard Moore

Craig

Re: ErrorsTag

[Craig R. McClanahan]

Howard Moore wrote:

> I've modified the ErrorsTag (based on the 2001/01/25 19:18:17 version) to
> support only displaying errors for a given property. It takes an additional
> optional attribute 'property' which identifies which errors to display. If
> 'property' is not specified all errors are displayed.
>
> Any chance of including it?
>

Thanks Howard, as a matter of fact there is :-).  It will be in tonight's
nightly build.

For people who want to submit patches to existing source files, it would be
really helpful if you could create a "unified diff" of the changes between your
proposed code and the current version.  Instructions for doing this are on the
web site at:

http://jakarta.apache.org/site/bugs.html

(On Windows systems, the "diff" command is available from many public domain
sources, including the CYGWIN environment which includes a large subset of the
standard Unix shell tools configured to work on a Win32 based system.)

>
> ---
> Howard Moore
>

Craig

Re: ConvertUtils

[Craig R. McClanahan]

Elod Horvath wrote:

> craig,
>
> i have efficiency questions about ConvertUtils.convert...
> isn't it true that the vm loads these class object once:
> java.lang.Boolean, java.lang.String, Boolean.TYPE, etc.
>
> isn't it more efficient to just compare class objects rather playing
> with their string representations?
>

Yep ... good idea.  I just submitted a patch that implements both of your
suggestions (comparing class types and ordering the if/else chain)..

Craig

Re: Automatic Form filing

[Craig R. McClanahan]

Frederic BAGES wrote:

> I'm just starting using Struts and i don't know if the problem has been
> raised already (no archive ?), but i was very surprised when i've tried the
> strut-example application : as the tour suggested i've tried to log with a
> bad login/password. The automatic filing functionality is wonderful but it
> is also introducing a security problem when running on password fields : the
> response HTML was containing my password !
>
>value="toto">
>
> Shouldn't this automatic filing functionality be disabled on password
> fields, or does the dev team decided that it's up to each web site maker to
> chose to implement an empty getPassword() function in the corresponding Form
> ?
>

I don't believe that this issue has been discussed in the past.  It certainly was
not a deliberate decision -- the password tag just followed the same convention as
all of the other input tags.

Is it really a security risk, though?  Remember that the password displayed here
did *not* work (otherwise, the user would have been logged in), so a potential
attacker is not learning anything new.  After all, they can just try various
username and password combinations on your login screen, and find out exactly the
same thing, even if the password text were not echoed.

>
> Sorry for my poor english.
>
> Frederic.

Craig McClanahan

Re: Automatic Form filing

[Craig R. McClanahan]

Incze Lajos wrote:

> On Wed, Jan 31, 2001 at 01:55:46PM -0800, Joerg Beekmann wrote:
> >
> >
> > > Is it really a security risk, though?  Remember that the
> > > password displayed here
> > > did *not* work (otherwise, the user would have been logged
> > > in), so a potential
> > > attacker is not learning anything new.  After all, they can
> > > just try various
> > > username and password combinations on your login screen, and
> > > find out exactly the
> > > same thing, even if the password text were not echoed.
> > >
> > I don't understand, seems to me the attacker is learning something.
> > Two likely reasons for a failed login are:
> > - simple typo; in this case trying a few variations or in many cases
> > correcting the spelling will get the attacker in.
> > - the user has multiple passwords and typed the wrong one. This
> > might compromise other systems
> >
> > Joerg
>
> I fully understand to Joerg. Refrain the password (which can be seen
> in hte HTML source view) is a bug.
>
> 1. As any sysadmin can tell you, users - if they can - will select
>meaningful passwords. I sight enough somtimes to know what the typo
>was, and what the real passowrd is.
>
> 2. Another issue is privacy. Users think what they type TOTALLY ENCRYPTED
>and you can get very inconvenient situations when something thought
>to be secret will be unveiled in clear text. So, it's simply HURTING
>A CONTRACT (that's why I'm calling it bug, not risk).
>incze

These arguments make sense ... I just checked in a patch.

Note that doing this breaks a different contract ("all Struts form tags
redisplay the previous values from the corresponding form bean property"),
but in the case of conflicting goals security needs to win.

Craig

Re: Nightly Build

[Craig R. McClanahan]

Sorry ... that's due to problems on my build server (plus a couple of ISP
hassles).  I will try to get this resolved today.

Craig


"Simon Oldeboershuis, outermedia" wrote:

> Hi,
>
> is there any reason that there is no nightly build for February neither
> src nor binary?
> I am a kind of waiting for the fixed array property.
>
> jakarta-struts/src/share/org/apache/struts/util ConvertUtils.java
>
> thanks!
> simon

Re: Change for BaseTag - don't generate port num if :80

[Craig R. McClanahan]

Good catch, Chris.  I'm going to slightly generalize this so that it doesn't
generate :443 when the scheme is "https" either.

Craig


Chris Smith wrote:

> ---
> /usr/java/jakarta-struts/src/share/org/apache/struts/taglib/html/BaseTag
> .java   Mon Jan 15 12:30:42 2001
> +++
> /home/chriss/struts-build/jakarta-struts/src/share/org/apache/struts/tag
> lib/html/BaseTag.java   Thu Feb  1 16:57:34 2001
> @@ -102,8 +102,11 @@
>  buf.append(request.getScheme());
>  buf.append("://");
>  buf.append(request.getServerName());
> -buf.append(":");
> -buf.append(request.getServerPort());
> +if (request.getServerPort() != 80)
> +{
> +buf.append(":");
> +buf.append(request.getServerPort());
> +}
>  buf.append(request.getRequestURI());
>  buf.append("\">");
>  JspWriter out = pageContext.getOut();
>
> This is based on revision 1.1 of BaseTag.java.
>
> The change is to avoid generating the port number in the base tag if it
> is the default port, i.e. avoid generating ":80".
>
> This is to solve problems with session handling.  When you start to use
> the base tag, your url contains ":80", but your session remains mapped
> against the non-":80" url.
>
> I hope I've supplied the diff in an appropriate format.
>
> Chris Smith

[ANNOUNCEMENT] New Bug Tracking System

[Craig R. McClanahan]

All of the Jakarta projects, including Struts, have recently migrated to
use a BugZilla installation, which you can reach at:

http://nagoya.apache.org/bugzilla

All existing opened bugs that had been entered in BugRat have been
forwarded automatically, but all new bugs should be entered at the
address above.  I will be updating the Struts web site information about
this shortly.

Committers, I would in particular like you to create yourselves Bugzilla
accounts so that bugs can be assigned to you :-).  In addition, if you
would like to be the default assignee for bugs in a certain category,
please let me know.

Craig McClanahan

Re: [ANNOUNCEMENT] New Bug Tracking System

[Craig R. McClanahan]

Ted Husted wrote:

> Cool.
>
> So I'm doing this right, we have 3 bugs logged (513, 505, 502)?
>

As of a second ago, there are 18 bugs with a state of NEW, ASSIGNED, or
REOPENED related to Struts.  The ones you mention are the ones that have
been entered directly into Bugzilla (and are thus assigned to me) -- the
others are the result of conversion from BugRat and must be getting
excluded by some filter criteria you are specifying.

>
> Do these include the showstoppers mentioned from time to time?
>

Only if they were entered into the bugtracking system -- I'm going
through the email lists to clean up remaining issues as well.

>
> You can put me down for the documentation bugs.
>

Will do.

>
> I'll also work on the platform installation notes this weekend.
>

Cool -- that will be a *big* help in answering startup questions.

>
> -T.

Craig

Re: Struts and WebSphere Appserver 3.5.2

[Craig R. McClanahan]

[EMAIL PROTECTED] wrote:

> I've spent most of this afternoon getting a struts app to work on WebSphere
> 3.5.2.
>
> The bottom line is that even under "Servlet 2.2/JSP 1.1 Compliance mode".
> getServletContext().getResourceAsStream() will fail and return null.
>
> I've worked around this getServletContext().getRealPath() and this works. I
> will try to raise this through our official IBM channels.
>
> The relevant section of the servlet spec appears to be 4.4.
>
> Can anyone else (Craig?) confirm that this is indeed a bug in the
> container, and getResource or getResourceAsStream are required for 2.2
> compliance?
>

Yes, ServletContext.getResource() and ServletContext.getResourceAsStream() are
required to operate as described in the Servlet 2.2 specification and
associated Javadocs.

> --
> dIon Gillard, Multitask Consulting
> Work:  http://www.multitask.com.au
> NetRexx: http://www.multitask.com.au/NetRexx.nsf

Craig

Re: [VOTE] Interim FAQ-o-Matic

[Craig R. McClanahan]

Ted Husted wrote:

> The shared FAQ-o-Matic at Jakarta is still busted, but the person
> working on it (Alex McLintok) has offered to host a Struts FAQ for us
> at < www.OWAL.co.uk:8090  >.
>

I would be a little hesitant about this, unless it covered all the Jakarta
subprojects (so we could point the web site FAQ link there instead of where
it is).

If the Jakarta FAQ problems are short term, we could probably get by just
building an HTML page or pages of FAQ questions and answers for Struts, and
include it in the docs application.  If the Jakarta FAQ problems are major
and/or long term, it would probably be better to discuss this on
[EMAIL PROTECTED] and come to a community wide consensus about
what to do.  What is the current status?

Craig


>
> Do we want to take Alex up on this?
>
> He has superuser privledges with the Jakarta Jyve, so should be able to
> point people from there to this one, until Jakarta's is fixed.
>
> Of course, I could seed this with the kickstart FAQ to get us going.
>
> There are other Apache FAQs there already, so we would fit right in.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/about/struts/

Re: Xalan Prerequisite for Build from Source

[Craig R. McClanahan]

IMHO several of the xml.apache.org packages have triggered grief w.r.t.
backwards compatibility.  It's probably time to think about a different
infrastructure for XML->HTML conversions, although I would *really* like
to finish a Struts 1.0 release first.

Options to consider and/or think about for Struts docs (not exclusive,
just the one's I have heard about so far):

* Grin and bear it, and hope that Ant's 

Re: building_controller.html#actionmapping

[Craig R. McClanahan]

Ted Husted wrote:

> Is this still true? Aren't we doing this all with forwards now?
>
>  "http://jakarta.apache.org/struts/userGuide/building_controller.html#actionmapping"
> >
>

You are right -- the language you quote below is obsolete, and should be removed.  The
stuff above it is still correct, though.

Craig


>
> In the example application included with Struts, this feature is used to
> define two
> additional properties:
>
> failure - The context-relative URI to which control should be forwarded
> if the
> Action class detects some sort of problem with the input fields it
> received. This
> will typically be the name of the JSP page from which the request was
> sent,
> which will cause the form to be redisplayed (with the error messages set
> by the
> Action Class and the most recent input values from the ActionForm bean).
>
> success - The context-relative URI to which control should be forwarded
> if the
> Action class successfully performs the required function. This will
> typically be the
> name of a JSP page that prepares the next page of the conversation flow
> for this
> application.
>
> Using these two extra properties, the Action classes in the example
> application are
> almost totally independent of the actual names of the JSP pages that are
> used by the
> page designers. The pages can be renamed (for example) during a
> redesign, with
> negligible impact on the Action classes themselves. If the names of the
> "next" JSP
> pages were hard coded into the Action classes, all of these classes
> would also need to
> be modified.
>
> 
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/about/struts/

Re: cvs commit: jakarta-struts/web/blank - New directory

[Craig R. McClanahan]

Ted Husted wrote:

> The message here should have been:
>
> Add source folder for struts-blank.war - Ready-to-rename application
> starter WAR.
>
> ? - What configuration files do I need to update to add a new sample
> application (struts-blank)?
>

Each webapp is basically self contained, with sources in two places:

src/x <-- Java source files in this tree
web/x <-- Web source files in this tree

In addition, the top-level build.xml needs to be updated -- I can do that
for you, if you like.

>
> ? - What about providing the source for each sample application under <
> WEBINF/src >, so that everything is together?
>

You mean include the webapp sources in the WEB-INF itself?  That wouldn't
be too hard, but seems somewhat redundant because they are all in the
Struts source distro anyway.

>
> -T.

Craig

Re: Documentation Roundup

[Craig R. McClanahan]

Ted Husted wrote:

> Short Term Plan
>
> As a preliminary to finally writing the HTML Developers Guide, I'm going
> through the documentation, and the CVS posts, looking for other fixes.

I'm going through the LICENSE text at the top of the sources ... I see that
I neglected to change "Tomcat" to "Struts" originally, and the year range on
the copyright needs to be updated.

In addition, you will see some refactoring of common code in several of the
tags into RequestUtils and ResponseUtils methods.

Craig

Re: VAJ Tomcat Test Environment/WS Test Environment serializable error

[Craig R. McClanahan]

[EMAIL PROTECTED] wrote:

> FYI anyone working in VAJ with the WTE (EJBs etc), passing ActionForms to
> EJB methods. We are hoping to find the actual either VAJ error or
> non-serializable object details.
>

Could you try an experiment?  Does making the "servlet" variable in ActionForm 
transient solve this?  (I imagine
the same issue would come up if the multipartRequestHandler variable was non-null.

Craig


>
> The workaround for this at the moment is to save the ActionServlet object
> from the form bean and then set it to null, send the form bean off to the
> ejb then when the ejb has finished with it put the saved ActionServlet back
> into the form bean. Like so:
>
> ActionServlet as = form.getServlet();
> form.setServlet(null);
>
> and then at the end of your try/catch you need a finally:
>
> finally
> {
>  form.setServlet(as);
> }
>
> Internal Servlet Error:
> java.io.IOException: Serializable readObject method failed internally
>java.lang.Throwable(java.lang.String)
>java.lang.Exception(java.lang.String)
>java.io.IOException(java.lang.String)
>void
> com.ibm.rmi.io.IIOPOutputStream.throwExceptionType(java.lang.Class,
> java.lang.String)
>void
> com.ibm.rmi.io.IIOPOutputStream.simpleWriteObject(java.lang.Object)
>void
> com.ibm.rmi.io.ValueHandlerImpl.writeValueInternal(com.ibm.rmi.io.IIOPOutputStream,
>
> org.omg.CORBA_2_3.portable.OutputStream, java.io.Serializable)
>void
> com.ibm.rmi.io.ValueHandlerImpl.writeValue(org.omg.CORBA.portable.OutputStream,
>
> java.io.Serializable)
>void
> com.ibm.rmi.iiop.CDROutputStream.write_value(java.io.Serializable)
>void
> com.ibm.rmi.iiop.CDROutputStream.write_value(java.io.Serializable,
> java.lang.Class)
>com.ibm.tricon.User com.ibm.tricon.userprofile.ejb.
> _User_BaseStub.updateUser(au.com.tricon.web.UserPageForm)
>com.ibm.tricon.User com.ibm.tricon.userprofile.ejb.
> _User_Stub.updateUser(au.com.tricon.web.UserPageForm)
>com.ibm.tricon.User
> 
>com.ibm.tricon.userprofile.ejb.UserAccessBean.updateUser(au.com.tricon.web.UserPageForm)
>
>org.apache.struts.action.ActionForward
> au.com.tricon.web.ModifyUserAction.perform(org.apache.struts.action.ActionMapping,
>
> org.apache.struts.action.ActionForm, javax.servlet.http.HttpServletRequest,
> javax.servlet.http.HttpServletResponse)
>org.apache.struts.action.ActionForward
> 
>org.apache.struts.action.ActionServlet.processActionPerform(org.apache.struts.action.Action,
>
> org.apache.struts.action.ActionMapping,
> org.apache.struts.action.ActionForm, javax.servlet.http.HttpServletRequest,
> javax.servlet.http.HttpServletResponse)
>void
> org.apache.struts.action.ActionServlet.process(javax.servlet.http.HttpServletRequest,
>
> javax.servlet.http.HttpServletResponse)
>void
> org.apache.struts.action.ActionServlet.doPost(javax.servlet.http.HttpServletRequest,
>
> javax.servlet.http.HttpServletResponse)
>void
> javax.servlet.http.HttpServlet.service(javax.servlet.http.HttpServletRequest,
>
> javax.servlet.http.HttpServletResponse)
>void
> javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest,
> javax.servlet.ServletResponse)
>void
> org.apache.tomcat.core.ServletWrapper.handleRequest(org.apache.tomcat.core.Request,
>
> org.apache.tomcat.core.Response)
>void
> org.apache.tomcat.core.ContextManager.service(org.apache.tomcat.core.Request,
>
> org.apache.tomcat.core.Response)
>void
> 
>org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(org.apache.tomcat.service.TcpConnection,
>
> java.lang.Object [])
>void org.apache.tomcat.service.TcpConnectionThread.run()
>void java.lang.Thread.run()
>
> --
> dIon Gillard, Multitask Consulting
> Work:  http://www.multitask.com.au
> NetRexx: http://www.multitask.com.au/NetRexx.nsf

Re: Asynchronous request processing

[Craig R. McClanahan]

Rey Francois wrote:

> We are currently investigating the possibility to service HTTP requests with
> an asynchronous model. The idea is to retrieve the dynamic content from the
> back-end using asynchronous calls. The motivations are:
> *   Sometimes the existing backend systems already have an asynchronous
> interface
> *   The increased response time when building a page which dynamic
> content is retrieved from multiple calls to the backend: these calls can be
> executed concurrently.
> *   Better scalability: the web server does not need to wait idly for
> the results
> The difficulty to implement such a mechanism is due to the Servlet spec
> itself: once the service() method returns, container can assume that the
> servicing of the request is finished and the response object should be
> closed. This means that while waiting for the results of the operations in
> the backend, we cannot just simply return the control to the container.
> Rather then having the servicing thread actively wait for the results, we're
> thinking about putting it to sleep and awake it when the results are ready.
> One way to achieve this is the use of the Object.wait() and Object.notify()
> methods. The code in the ActionForm.perform() would look more or less like
> this:
> Action.perform() {
> ResultHandler resultHandler = new
> ResultHandler(request, response) {
> handleResult(command) {
> // process results
> // when all results have
> arrived, call notify()
> }
> };
> Command c1 = Command.getCommand("COMMAND1");
> c1.execute(resultHandler); // async. call
> Command c2 = Command.getCommand("COMMAND2");
> c.execute(resultHandler); // async call
> Try {
> resultHandler.acceptResults(long timeout) ;
> } catch (TimeOutException) {
> // time out error handling
> }
> // from here all results have been returned.
> ...
> return new ActionForward(...) ;
> }
> The ResultHandler class would look somehow like this:
>
> public class ResultHandler {
> synchronized void acceptResults(long timeout) throws
> TimeOutException {
> wait(timeout);
> if (!areAllCommandFinished) {
> throw new TimeOutException(...);
> }
> }
> // Method called internally in order to register the commands
> // this handler is waiting for
> void registerCommand(Command command) {...}
>
> // Return true if all registered commands have terminated
> boolean areAllCommandFinished() {...}
>
> // Method called internally when results arrive
> void internalHandleResults(Command command) {
> // Check if the command is registered and mark it as
> terminated
> // then call the user's logic for processing results
> handleResults(command);
> // If all commands are finished, awake servicing thread
> if (areAllCommandFinished) {
> synchronize(this) {
> notify();
> }
> }
> }
>
> // Method to be overridden by the user
> abstract synchronized void handleResults(Command command);
> }
> The code above is just indicative and may contains syntax or design errors,
> but I think the idea is well illustrated.
> Does anybody have any comments on this approach? I'm also particularly
> interested in your comments regarding the fact that the servicing thread is
> put to "sleep": is there any risk in doing this? Can this have any conflict
> with the container and the way it manages its threads?
>

This approach looks like it should be safe -- from the perspective of the
servlet container, the call is still synchronous.  Where you get into trouble is
trying to reference the request and response objects of a particular request
after the service() method has returned, which does not happen in your scenario.

One caveat is that some servlet containers might run your web apps under a
SecurityManager that does not allow asynchronous threads at all, so you will
want to make sure that this is allowed.

An alternative approach to asynchronous processing is to remember that the user
might want to see some intermediate feedback while the asynchronous commands are
executing.  You might think about an Action designed (in general) like this:

if (background-commands-not-started) {
start-ba

Re: forms, formbeans and JavaScript

[Craig R. McClanahan]

Mike Dewhirst wrote:

> As a lot of forms may have JavaScript in them to dynamically rebuild menus, etc. Is 
>it possible to combine this with the Struts tag-styled form design?
>

The challenge with doing this is that the JSP tags run on the server (as the page is 
being generated), while the JavaScript runs on the client side.  To integrate the two, 
you need your tags (and other JSP code) to dynamically generate the JavaScript 
functions themselves -- sort of having a program write a program --
so that the JavaScript is customized to your particular need on this particular page.

A very trivial example is the way that the  tag deals with the "focus" 
attribute.  If you specify it, a dynamically generated bit of JavaScript is created to 
set the input focus, which includes the name of the field you want initial focus 
assigned to.

For a more comprehensive scenario, consider that for most menuing systems you will 
need to configure the list of available options into a JavaScript array or something.  
You could use the  tag to render the elements that get set in the 
array's initialization expression.

>
> Thanks in advance for your help,
>
> Mike
>

Craig

Last Call for Struts 1.0 Bugs

[Craig R. McClanahan]

The few remaining Struts bug reports are feeling kind of lonely.  Do you
have any more bugs that you would like to see fixed before Struts 1.0 is
released?  If so, please post them to the bug tracking system at:

http://nagoya.apache.org/bugzilla/

under product "Struts".  Even if the bug has been reported to a Struts
mailing list, this is the best way to ensure that your bug does not get
missed in the final rush towards release.

Feature requests are welcome as well, of course, but the focus right at
the moment is on identifying and squashing any remaining bugs so that
1.0 comes out of the box as an extremely solid platform for building web
applications.

Craig McClanahan

Re: Contribution

[Craig R. McClanahan]

Craig Tataryn wrote:

> Hi there, I was wondering if anyone has taking ownership of the
> "Workflow Processing" TODO?  If not, would I be able to start this
> project and get all interested parties involved?
>

Welcome, Craig!  I have added your name to the TODO list for this topic.

By the way, I don't see a problem if more than one person wants to sign up
on particular topics.  These are the people that are primarily interested,
and I expect they would spearhead the conversations on STRUTS-DEV as we
decide what to build and how to build it.  Over time, I would hope many
would also desire to become committers on Struts, so that we can accelerate
the overall development.

Anyone else interested in signing on the dotted line?  :-)

>
> Also, I did a presentation of Struts at an e-business SIG, I was
> wondering if I could get the presentation added to "Resources" section
> of the User Guide?
>
> The address where the presentation can be viewed is:
> http://www.computer-programmer.org/articles/struts/
>

I look forward to seeing this.  There will be some other published
information about Struts in the next few months as well -- I'll post the
ones I'm aware of as they become published.

>
> Thanks,
>
> Craig.
>

Craig


>
> --
> I've been trying to change the world for years, but they just won't give
> me the source code

Re: web-app_2.2.dtd - how get a local copy?

[Craig R. McClanahan]

Maya Muchnik wrote:

> Hello, all,
>
> Maybe this question for Tomcat developers.
>

That's true, although there is overlap here ... :-)

>
> As you know we are all using web.xml file for a servlet container. This
> file has the following lines :
>
>  PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
> "http://java.sun.com/j2ee/dtds/web-app_2.2.dtd">
>
> Every time when you start Tomcat, for example, you are getting the file
> web-app_2.2.dtd from java.sun.com site. Tomcat does not have this file
> itself.

Check inside "webserver.jar" -- you'll see a resource file named
"org/apache/tomcat/resources/web.dtd" that contains this text.  Otherwise,
Tomcat would not be able to start and run on an offline computer.  Tomcat
registers this resource file within the XML parser it uses, in effect saying
"when you see this public identifier, use my local copy instead of going out
across the network."

> When I have got it from java.sun.com, the file has the following
> a Copyright:

That's an oversight when the original Tomcat code was published.


>
> Maya

Craig

Re: html:password

[Craig R. McClanahan]

Frederic BAGES wrote:

> I haven't try since the changes were made but i think it's because of the
> way the session object is managed. You don't lose session information (your
> form) until a timeout occur. It's the same on many web sites. If you close
> your browser you won't be able to log in without your password. It's better
> than seeing the password in plain text in the html source. But i don't know
> why the password is not set to an empty string if you don't fill the
> password field.
>

This got changed about a week ago -- the password field no longer echoes the previous
contents into the source of the page.  Try a recent nightly build.

>
> I forward this message in the dev list before the 1.0 release of struts.
>
> Frederic.
>

Craig

Re: cvs commit: jakarta-struts/src/conf struts-config_1_0.dtd

[Craig R. McClanahan]

Martin Cooper wrote:

> Just curious - in what situations might I want to use a class other than
> ActionFormBean to represent  entries?
>

There is not much need for this in a standard Struts application, but consider
what would happen if you wanted to attach some additional configuration
information to a form (such as what fields should be edited in what way), and
you wanted to configure that stuff in the "struts-config.xml" file.  One way
would be to define your own ActionFormBean class, which Struts would use instead
of the standard one, and which would pick up additional properties that you set
with a  element nested inside the  element.

Same basic philosophy would apply to overriding the default classes for
ActionForward and ActionMapping as well.

>
> --
> Martin Cooper
> Tumbleweed Communications
>

Craig

RE: feature request bug 6477

[Craig R. McClanahan]

On Fri, 15 Feb 2002, Frederic Simard wrote:

> Date: Fri, 15 Feb 2002 15:17:44 -0500
> From: Frederic Simard <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: feature request bug 6477
>
> No, but I dont want you to duplicate it, I want you to use it.
>

Adding such a feature to Struts itself would go directly against the grain
of what Struts encourages for application design patterns.

However, nothing stops *you* from using other tag libraries in JSP pages
that also include Struts tags.  If *you* want to use them, go for it.

Craig McClanahan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Logging mess

[Craig R. McClanahan]

On Sat, 16 Feb 2002, B.Gorkem ERCAN wrote:

> Date: Sat, 16 Feb 2002 01:16:02 +0200
> From: B.Gorkem ERCAN <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Logging mess
>
> Hi,
> On my daytime job I have to manage several J2EE applications
> developed by several development teams. Recently our administrator
> complained that these applications all use different logging mechanisms
> which is creating a mess :). In order to avoid I have decided to advise
> on the use of just one common loggin API. I am going to to use
> commons-logging but I want to add the possibility to control the logging
> behaviour of all the applications running on the same JVM so that I can
> set some of the logging properties on individual applications centrally.
> What I have in mind is to have a LoggingManager structure somehow like
> the SecurityManager.  I want to be able to code in some of the
> properties so that they are not easilly changeable but in the mean time
> allow easy to edit cofiguration files on other properties. Do you think
> this is a right approach? Is it interesting to have these in the
> commons-logging?
>

Well, you might want to join in the discussions on the design of the
commons logging API, which is happening on the COMMONS-DEV mailing list.

The current code (thanks to some updates from Costin) allows you to
install commons-logging.jar in a shared repository (like the "lib"
directory in Tomcat), but still allow each webapp to define their own
logging configuration if you want to (they would default to the global
settings).  Alternatively, you could put a copy in each webapp, and they
would be totally insulated.

Since you can accomplish any reasonable combination already, I don't
personally see any need to make commons-logging any more complicated --
it's *only* purpose in life is to allow you to write your application
components to a single API, and then make a choice at deployment time on
which logging technology will actually be used underneath.

> Thanks
> B. Gorkem ERCAN
>

Craig



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Modular Applications (the BIG checkin) [LONG]

[Craig R. McClanahan]

On Wed, 20 Feb 2002, David Winterfeldt wrote:

> Date: Wed, 20 Feb 2002 08:39:22 -0800 (PST)
> From: David Winterfeldt <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: [PROPOSAL] Modular Applications (the BIG checkin) [LONG]
>
> I may have missed this discussion, but was there ever
> talk about switching to Commons Logging for the Struts
> 1.1 release.  I've been using Commons Logging with
> log4j and I've had no problems.  I think everyone
> would appreciate the improved logging control.
>

We've become dependent on it implicitly (because digester uses it).
Commons logging is also (finally :-) about to go 1.0 -- so I'm +1 on using
it in Struts components as well.

> David
>

Craig


> --- Ted Husted <[EMAIL PROTECTED]> wrote:
> > I agree that a beta based on the current nightly
> > build is a reasonable
> > course of action for now.
> >
> > My real regret is that we did not get a chance to
> > cut a 1.1 release
> > before the last wave of improvements came done the
> > pipeline. My concern
> > is that either the release-cycle will now be
> > extended, while we absorb
> > the new features, or will be rushed, just to move
> > things along.
> >
> > Of course, Craig's work is consistently excellent,
> > and the likelihood of
> > any actual problems is slight to none.
> >
> > My underlying goal is to remind us that Struts is
> > being used by some
> > very serious teams on some very serious projects.
> > These teams rely on
> > the "#.#" release stamp to tell them that the
> > codebase is ready for
> > primetime, and it is our responsibility to ensure
> > that it is.
> >
> > I would usually expect changes this significant to
> > live in the nightly
> > build for several months before release. But,
> > keeping the other features
> > out the hands of production teams is now bordering
> > on cruelty.
> >
> > So, I guess, it comes down to "in for a penny, in
> > for a pound"; are we
> > ready to cut a beta?
> >
> > -Ted.
> >
> >
> >
> > "Deadman, Hal" wrote:
> > >
> > > I assume there will be at least one beta release
> > of Struts 1.1 and a release
> > > candidate after that. That will provide ample time
> > to identify any specific
> > > incompatibilities and address them. At least we
> > will be able to identify the
> > > exact cause of the incompatibility and then we can
> > discuss a specific
> > > problem rather than unidentified issues.
> > >
> > > It's too early to give up on the ideal solution
> > which is not adding a second
> > > package. A second package will cause grief similar
> > to the struts-form.tld.
> > > The periodic bug reports of people trying to use
> > that taglib are annoying
> > > but imagine the time the bug reporters wasted
> > trying to use that taglib. It
> > > probably would have saved the world some time if
> > it had been removed prior
> > > to 1.0. People using pre-1.0 Struts or pre-1.1
> > nightly builds should expect
> > > to make some minor changes if they upgrade.
> > Especially when the changes will
> > > save them time in the long run.
> > >
> > > People moving from 1.0 to 1.1 are already in for
> > some global search and
> > > replace due to the commons stuff. They are also
> > going to have to do some
> > > extensive testing because a great deal of changes
> > have been made, aside from
> > > the Big check-in.
> > >
> > > Nobody needs to upgrade an application that is
> > well underway with a
> > > particular version of Struts. If they do upgrade
> > then they need to examine
> > > the migration issues and weigh the migration cost
> > against benefits of the
> > > new features. Hopefully there won't be any known
> > migration issues that
> > > aren't resolved during a beta release.
> > >
> > > Hal
> >
> > --
> > To unsubscribe, e-mail:
> > 
> > For additional commands, e-mail:
> > 
> >
>
>
> __
> Do You Yahoo!?
> Yahoo! Sports - Coverage of the 2002 Olympic Games
> http://sports.yahoo.com
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Modular Applications (the BIG checkin) [LONG]

[Craig R. McClanahan]

On Wed, 20 Feb 2002, Ted Husted wrote:

> Date: Wed, 20 Feb 2002 07:52:03 -0500
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: [PROPOSAL] Modular Applications (the BIG checkin) [LONG]
>
> I agree that a beta based on the current nightly build is a reasonable
> course of action for now.
>

There's one more thing on my "gotta have it" list -- integrating the setup
of services from struts-config.xml (although I'm not 100% happy with the
current commons-services APIs, I will converse about that on commons-dev).
This will remove the most common reason that people have to subclass
ActionServlet, and will thus insulate them from internal changes to that
implementation.

> My real regret is that we did not get a chance to cut a 1.1 release
> before the last wave of improvements came done the pipeline. My concern
> is that either the release-cycle will now be extended, while we absorb
> the new features, or will be rushed, just to move things along.
>
> Of course, Craig's work is consistently excellent, and the likelihood of
> any actual problems is slight to none.
>

So far, so good ... :-)

> My underlying goal is to remind us that Struts is being used by some
> very serious teams on some very serious projects. These teams rely on
> the "#.#" release stamp to tell them that the codebase is ready for
> primetime, and it is our responsibility to ensure that it is.
>
> I would usually expect changes this significant to live in the nightly
> build for several months before release. But, keeping the other features
> out the hands of production teams is now bordering on cruelty.
>

I'm thinking we want to clearly differentiate between a "beta" (features
could still change, we could even yank the BIG check-in if it causes more
compatibility problems than we currently anticipate) and a "release
candidate" (critical bugfixes only).  I hope we go through at least a
couple of release candidates before final release.

> So, I guess, it comes down to "in for a penny, in for a pound"; are we
> ready to cut a beta?
>

Subject to adding services (I will be able to work on it this weekend),
+1.

> -Ted.
>

Craig


>
>
> "Deadman, Hal" wrote:
> >
> > I assume there will be at least one beta release of Struts 1.1 and a release
> > candidate after that. That will provide ample time to identify any specific
> > incompatibilities and address them. At least we will be able to identify the
> > exact cause of the incompatibility and then we can discuss a specific
> > problem rather than unidentified issues.
> >
> > It's too early to give up on the ideal solution which is not adding a second
> > package. A second package will cause grief similar to the struts-form.tld.
> > The periodic bug reports of people trying to use that taglib are annoying
> > but imagine the time the bug reporters wasted trying to use that taglib. It
> > probably would have saved the world some time if it had been removed prior
> > to 1.0. People using pre-1.0 Struts or pre-1.1 nightly builds should expect
> > to make some minor changes if they upgrade. Especially when the changes will
> > save them time in the long run.
> >
> > People moving from 1.0 to 1.1 are already in for some global search and
> > replace due to the commons stuff. They are also going to have to do some
> > extensive testing because a great deal of changes have been made, aside from
> > the Big check-in.
> >
> > Nobody needs to upgrade an application that is well underway with a
> > particular version of Struts. If they do upgrade then they need to examine
> > the migration issues and weigh the migration cost against benefits of the
> > new features. Hopefully there won't be any known migration issues that
> > aren't resolved during a beta release.
> >
> > Hal
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Date for 1.1 beta release

[Craig R. McClanahan]

On Wed, 20 Feb 2002, SCHACHTER,MICHAEL (HP-NewJersey,ex2) wrote:

> Date: Wed, 20 Feb 2002 16:08:50 -0500
> From: "SCHACHTER,MICHAEL (HP-NewJersey,ex2)" <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: Date for 1.1 beta release
>
> Hey,
>
> Sorry I haven't been really reading any emails pertaining
> to this subject... but when is the planned release time
> for 1.1 beta?

Ted proposed March 4, which seems feasible from my perspective.

>  If it's kinda soon (2-3 weeks) I'll make time
> to finish off commons-resources and outstanding file upload
> stuff ASAP. Apologies for my lack of participation in all this.
>

Craig



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DynaActionFormClass & set-property

[Craig R. McClanahan]

On Wed, 20 Feb 2002, Roy Porter wrote:

> Date: Wed, 20 Feb 2002 22:05:44 -
> From: Roy Porter <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: DynaActionFormClass & set-property
>
> If you extend the DynaActionFormClass to add your own properties, the
> current code doesn't seem to copy these properties to the DynaActionForm
> class when it creates it.
>

By "add your own properties", do you mean adding your own *dynamic*
properties, or regular JavaBeans style properties?  Only the former are
used in DynaActionFormClass.

> In tracing the code through, the DynaActionFormClass gets initialized
> correctly with the properties form the struts-config file, but there
> doesn't seem to be any code to copy these over into the Form.
>

PropertyUtils (which is what the form tags use underneath the covers)
understands what to do with DynaBeans -- could you supply an example of
what you are trying to do?

> Is there any specific way the properties should be created, or has this
> code just not been written yet ?
>

I guess I've been assuming that people would just define what they need in
struts-config.xml and not have to subclass for this purpose.  The only
time you should need to subclass would be to implement a custom reset() or
validate() method.

> Roy.
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: DynaActionFormClass & set-property

[Craig R. McClanahan]

On Thu, 21 Feb 2002, Porter, Roy wrote:

> Date: Thu, 21 Feb 2002 09:03:02 -
> From: "Porter, Roy" <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: DynaActionFormClass & set-property
>
> I'm trying to add regular Javabean style properties, as well as dynamic
> properties.
>

Ah ... then you're not going to like the current implementations of
DynaBeans very much.  They currently represent themselves as having *only*
the set of dynamic properties that are defined.

> an excerpt from the struts-config would be something like:
>
>  dynamic="true" className="com.x.struts.config.XXFormBeanConfig" >
>value="com.x.AddressTypeVO"/>
>value="com.x.AddressType"/>
>   
>   
>   
> 
>
> So in effect, the XXDynaActionForm class simply adds 2 properties to the
> standard DynaActionForm, and likewise for the XXFormBeanConfig class.
>

What makes voClassName and converterClassName any different than any other
dynamic property?  Why can't you just declare them with 
elements like "add1", "add2", and "add3"?

> According the 1.1 dtd this is allowable.
>
> If it's not obvious from the above, what I'm trying to do is to write as
> little code as possible 
> there'll be the one ActionFormClass, using dynamic properties. As the
> project is using EJB, the Action class will convert the dynamic properties
> to the relevant Value Object type using the specifined converter, before
> invoking the required business object.
>
> I could have the voClassName, and converterClassName as form-property's with
> an initial value. But, would these not then get cleared on calling the reset
> method ?
>

If you declared them as standard dynamic properties (with
), they would get initialized (and cleared) to null.

> Roy.
>

Craig


> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: 21 February 2002 00:14
> To: Struts Developers List
> Subject: Re: DynaActionFormClass & set-property
>
>
>
>
> On Wed, 20 Feb 2002, Roy Porter wrote:
>
> >
> > If you extend the DynaActionFormClass to add your own properties, the
> > current code doesn't seem to copy these properties to the DynaActionForm
> > class when it creates it.
> >
>
> By "add your own properties", do you mean adding your own *dynamic*
> properties, or regular JavaBeans style properties?  Only the former are
> used in DynaActionFormClass.
>
> > In tracing the code through, the DynaActionFormClass gets initialized
> > correctly with the properties form the struts-config file, but there
> > doesn't seem to be any code to copy these over into the Form.
> >
>
> PropertyUtils (which is what the form tags use underneath the covers)
> understands what to do with DynaBeans -- could you supply an example of
> what you are trying to do?
>
> > Is there any specific way the properties should be created, or has this
> > code just not been written yet ?
> >
>
> I guess I've been assuming that people would just define what they need in
> struts-config.xml and not have to subclass for this purpose.  The only
> time you should need to subclass would be to implement a custom reset() or
> validate() method.
>
> > Roy.
> >
>
> Craig
>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: DynaActionFormClass & set-property

[Craig R. McClanahan]

On Thu, 21 Feb 2002, Porter, Roy wrote:

> Date: Thu, 21 Feb 2002 17:49:03 -
> From: "Porter, Roy" <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: DynaActionFormClass & set-property
>
> Answer in line ...
>
> > > I'm trying to add regular Javabean style properties, as
> > well as dynamic
> > > properties.
> > >
> >
> > Ah ... then you're not going to like the current implementations of
> > DynaBeans very much.  They currently represent themselves as
> > having *only*
> > the set of dynamic properties that are defined.
> >
> > > an excerpt from the struts-config would be something like:
> > >
> > >  > > dynamic="true"
> > className="com.x.struts.config.XXFormBeanConfig" >
> > >> > value="com.x.AddressTypeVO"/>
> > >> > value="com.x.AddressType"/>
> > >   
> > >   
> > >   
> > > 
> > >
> > > So in effect, the XXDynaActionForm class simply adds 2
> > properties to the
> > > standard DynaActionForm, and likewise for the
> > XXFormBeanConfig class.
> > >
> >
> > What makes voClassName and converterClassName any different
> > than any other
> > dynamic property?  Why can't you just declare them with
> > 
> > elements like "add1", "add2", and "add3"?
>
> The voClassName etc. are set in the struts config file so that we can
> determine what type value object to create from each form. In effect, they
> are static fields.
>

You can use the "initial" attribute on  for things like
this, as long as the underlying properties are Strings or primitives.  The
reset() method sets everything back to the specified initial value.

> >
> > > According the 1.1 dtd this is allowable.
> > >
> > > If it's not obvious from the above, what I'm trying to do
> > is to write as
> > > little code as possible 
> > > there'll be the one ActionFormClass, using dynamic
> > properties. As the
> > > project is using EJB, the Action class will convert the
> > dynamic properties
> > > to the relevant Value Object type using the specifined
> > converter, before
> > > invoking the required business object.
> > >
> > > I could have the voClassName, and converterClassName as
> > form-property's with
> > > an initial value. But, would these not then get cleared on
> > calling the reset
> > > method ?
> > >
> >
> > If you declared them as standard dynamic properties (with
> > ), they would get initialized (and cleared) to null.
>
> According to the dtd there's an initial attribute on the form-property tag,
> I take it I could use this property, and then override the reset method to
> ensure that my 'static' fields remain at their initial values ?
>

You don't even have to override ... the standard reset() method in
DynaActionForm does this for you.

> I'm not an expert with dtd's, but am wondering if it is possible to not
> allow set-property tag's under the form-bean tag, if the form-bean is set to
> dynamic ? As it seems they are not supported, this would make sense, if
> possible ?
>

DTDs don't give you that sort of expressive power, unfortunately.  If/when
we ever get to using an XML Schema for validation, this would be possible.

> Roy.
>

Craig


> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: PropertyUtils with added PropertyEditor support

[Craig R. McClanahan]

On Fri, 22 Feb 2002, Mathieu Frenette wrote:

> Date: Fri, 22 Feb 2002 12:52:36 -0500
> From: Mathieu Frenette <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Cc: 'Paul Speed' <[EMAIL PROTECTED]>,
>  'Martin Cooper' <[EMAIL PROTECTED]>
> Subject: RE: PropertyUtils with added PropertyEditor support
>
> I read your threads and I can say I fully agree.
>
> My only concern is that even if PropertyEditor is too heavy for using it
> solely for type conversion, we still need some kind of converter.  And in my
> opinion that should not be the form bean's business.  In my case, I have
> tens of properties scattered in various bean which have the same type (ie.
> NumberKey) and they all need to be converted the same way.  I could
> encapsulate the conversion code in a helper class or base class and use it
> for all my getter/setters, but that still represents a lot of (unnecessary)
> house-keeping coding.  Whereas, with PropertyEditor, I simply had to
> register the editor once, and MAGIC! everything communicates perfectly.
> Don't you think there should be a cleaner way of achieving type conversion
> within Struts?
>

On my list of "good things that really need to be done" is letting you
plug Converters into the BeanUtils class (in commons-beanutils, and
therefore useful in the HEAD branch of Struts) instead of the mandated use
of ConvertUtils static methods.  As usual, this needs to be done in a way
that is fully backwards compatible with the existing functionality, but it
should be feasible.

> -- Mathieu
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts vs. Java Faces (aka JSR 127)

[Craig R. McClanahan]

On Fri, 22 Feb 2002, Tim W Wilson wrote:

> Date: Fri, 22 Feb 2002 14:34:12 -0500
> From: Tim W Wilson <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Struts vs. Java Faces (aka JSR 127)
>
> Is there any opinion in the Structs development community about whether or
> not the Java Faces work
> from sun obviates the need for struts?  JSR 127 spends a lot of time on tag
> libraries but it apparently will
> also tackle the page flow control issue as well.
>

I'm on the expert group for JavaServer Faces (JSR-127), and am very
familiar with the internal design discussions going on around this issue
(where does a UI components library leave off and an application framework
start?).  How Faces is going to deal with it is not yet clear -- but, no
matter what happens, I strongly believe that there is a need for higher
level application control flows (such as what Actions do for you in a way
that is basically independent of the UI technology you select) even with
whatever Faces ends up with.

That being said, I would not be at all surprised to see Faces be the
preferred UI implementation technology (as opposed to the Struts tag
libraries) once it is standardized and available.  I'm committed to make
sure that this is very conveniently accomplished with Struts.

> Cheers
>
> Tim W Wilson
> Eclipse WSED Architecture & Development
> internet: [EMAIL PROTECTED]
> (919) 254-0029 (TL 444-0029)
>
>

Craig McClanahan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Commons Logging

[Craig R. McClanahan]

On Mon, 25 Feb 2002, David Winterfeldt wrote:

> Date: Mon, 25 Feb 2002 19:49:05 -0800 (PST)
> From: David Winterfeldt <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Commons Logging
>
> I checked in what I've done so far.  Commons Logging
> issues.
>
> 1. Do we want to just add console logging to the
> example web apps or log to a file?

I'm adding this for struts-example (along with updating the architecture
to reflect modern Struts design patterns, like using a DAO for the
database access).

>  Are you still
> running the nightly build Craig?

Yes.

>  Log4J would need to
> be added to the properties file so it can be included
> in the webapps for the binary distribution.  Or we can
> activate the console logging in the Commons Logging
> pacakge.
>

I'm not opposed to including Log4J, but doesn't that mean we need to
preconfigure it as well?  It seems simpler to just accept the
commons-logging defaults and let users configure their own environment
differently if they need it.

> 2. I left the log(msg) method in ActionServlet,
> ActionServletWrapper, and RequestProcessor.  I
> deprecated the log method to the logWriter in
> GenericDataSource and switched the class itself to use
> Commons Logging.  MessageResources log method logs to
> Commons Logging.  That method was logging to
> System.out, but since other people are calling the
> other log methods and they are at least being written
> to a file I wasn't sure if they should be changed to
> Commons Logging.
>

OK, although I don't really think log() needs to be deprecated, since it
just passes the message on to a feature that is part of the standard
Servlet API.

> 3. appConfig.getServlet().getDebug()
>I didn't change this.  I'm not sure how this fits
> in with adding Commons Logging.  I left this as the
> conditional, but change the logging inside to
> log.debug.
>

Part of the same issue.

> Files updated.
> src/share/org/apache/struts/action/ActionServlet.java
> src/share/org/apache/struts/action/RequestProcessor.java
> src/share/org/apache/struts/actions/DispatchAction.java
> src/share/org/apache/struts/upload/DiskMultipartRequestHandler.java
> src/share/org/apache/struts/util/GenericDataSource.java
> src/share/org/apache/struts/util/MessageResources.java
> src/share/org/apache/struts/util/MessageResourcesFactory.java
> src/share/org/apache/struts/util/RequestUtils.java
>
> Another sidenote is that commons-services.jar and
> commons-validator.jar are in the build.xml, but not in
> the build.properties.sample file.  I was going to fix
> this, but I didn't want to break the nightly build.
>

Go ahead ... build.properties.sample is just that -- a sample -- it's not
actually used in the nightly build process.  I've got these JAR files
defined in my ${user.home}/build.properties file anyway.

> David
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Another 1.1 TODO

[Craig R. McClanahan]

Something we should include on the 1.1 TODO list is to ensure that you can
put struts.jar (and the appropriate commons-*.jar files it depends on)
into a container-provided shared class loader (such as the "lib" directory
in Tomcat 4.0.x) instead of requiring that they be included in the
/WEB-INF/lib directory.  This will provide more flexibility for those
deploying multiple Struts-based apps on the same container.

Principally, this means that whenever the Struts code does a
Class.forName() on an application-provided class, it should be modified to
look in the webapp class loader first:

  ClassLoader webappClassLoader =
Thread.currentThread().getContextClassLoader();

which is guaranteed to work correctly on Servlet 2.3 containers (required
in the spec), and in practice seems to work correctly on all containers
that matter.  (If we're creating objects with Digester, this probably
means using the factory create rule rather than the object create rule so
that the object creation factory can do the right thing.)

I will put this on my list unless someone else wants to take a crack at
it.

Craig



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Struts at JavaOne (US) 2002

[Craig R. McClanahan]

JavaOne is coming up quickly this year -- it's March 25-29 at Moscone
Center in San Francisco.  Struts will again be well-represented in talks
at the show:


Monday (03/25) -10:30pm - BOF-2775

  "Custom Tag Libraries: Designing for Reuse"
  Ed Hill


Wednesday (03/27) -  8:00pm - BOF-1820

  "The Struts Framework Community"
  Craig McClanahan (I'm hosting this one)


Thursday (03/28) -   2:45pm - TS-2540

  "Multiface Coding:  Efficient Programming Techniques for the
  Java(TM) 2 Platform, Enterprise Edition (J2EE TM) Framework"
  Nathan Abramson


Thursday (03/28) -   8:00pm - BOF-2293:

  "Coupled and Decoupled Design Strategies Using Struts"
  Christine Eckstein, Jason Gola


Thursday (03/28) -   9:00pm - BOF-3166:

  "Building an MVC Type-II (Model 2) Architecture for the
  Sun(TM) Open Net Environment (Sun ONE) Web Services Platform"
  Kartik Ganeshan



I will also be participating in two "Ask The Expert" BOFs (BOF-1803,
BOF-1804), as well as a frequent participant in Sun's "Ask The Expert"
booths in the Show Pavillion.

Hope to meet many of you in San Francisco!

Craig McClanahan



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Strange behavior at plugin's config loading

[Craig R. McClanahan]

On Mon, 4 Mar 2002, Oleg V Alexeev wrote:

> Date: Mon, 4 Mar 2002 20:09:48 +0300
> From: Oleg V Alexeev <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  Oleg V Alexeev <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Strange behavior at  plugin's config loading
>
> Hello Struts,
>
>   Now I try to use plugins in Struts - write my plugin, add a lot of
>   strings to the struts-config.xml -
>

Like the DTD for web.xml, the DTD for struts-config.xml is sensitive to
the order of the supplied elements:



Move your plug-ins to the end and it should be fine.

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: The missing release plan

[Craig R. McClanahan]

Let's propose a (revised) plan and go forth from there.  Martin, I didn't
get my deliverables done on time either, so don't feel *too* bad.

Craig


On Tue, 5 Mar 2002, Arron Bates wrote:

> Date: Tue, 05 Mar 2002 17:35:52 +1100
> From: Arron Bates <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: The missing release plan
>
> 2
>
> That way there's less room for people feeling their intended effort
> missed the boat.
>
> Arron.
>
> Martin Cooper wrote:
>
> >Through informal discussion, we decided to go to Struts 1.1 Beta 1 on March
> >4th, which is today. However, I've realised that I dropped the ball, and did
> >not produce a release plan, to be voted on by the committers. So the
> >question is, how should I best recover?
> >
> >Here are a couple of options:
> >
> >1) Continue with a Beta 1 release in the next day or so, regardless of a
> >vote on the release plan, but depending on when the crucial fixes are
> >checked in.
> >
> >2) Post a release plan ASAP, and await a "go" vote before proceeding with
> >the Beta 1 release.
> >
> >Other suggestions are welcome.
> >
> >Committers, please let me know what you would like me to do in this respect.
> >
> >--
> >Martin Cooper
> >
> >
> >
> >--
> >To unsubscribe, e-mail:   
> >For additional commands, e-mail: 
> >
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Logger in ActionServlet

[Craig R. McClanahan]

On Tue, 5 Mar 2002, Oleg V Alexeev wrote:

> Date: Tue, 5 Mar 2002 10:43:15 +0300
> From: Oleg V Alexeev <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  Oleg V Alexeev <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Logger in ActionServlet
>
> Hello Struts,
>
>   Log variable in ActionServlet is private and get method to obtain it
>   not exist - is it a part of some ideology or a partial solution?
>
>   So what is the best way to use commons-logging - use one logger
>   instance from base class (so make log in ActionServlet protected and
>   add get method for it) or retrieve logger instance for every class
>   (so for extended version of the ActionServlet it would be another
>   logger for another classname)?
>

Although I agree with you that the ActionServlet's notion of a Log
instance should be available somehow (probably through a public getter
method), my current preference has been to have a separate named Log
instance per Struts sub-application.  That means that sub-apps (and, by
extension of the same philosophy, add-on components) should define their
own logger names.

One non-obvious facet of the SimpleLog implementation in commons-logging
1.0 (and, I *think*, in Log4J and JDK 1.4 logging as well) is that logging
level setting is hierarchical -- if a level is not set for a particular
logger name, then SimpleLog will start chopping off "." delimited
components before it uses the default level.  Therefore, you can configure
a logging level for "org.apache.struts" that applies to *all* loggers
whose names start with this, unless they are explicity set to some other
value.

>
> --
> Best regards,
>  Oleg  mailto:[EMAIL PROTECTED]
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: - property tag required?

[Craig R. McClanahan]

On Fri, 8 Mar 2002, Matt Read wrote:

> Date: Fri, 8 Mar 2002 20:52:18 -
> From: Matt Read <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject:  - property tag required?
>
> Could anyone explain why the property tag on  (and all tags
> that subclass BaseFieldTag) is required (according to struts-html.tld)? I'm
> trying to do the following:
>
> 
> 
>   
> 
>

The "property" attribute defines the name of the input field that will be
sent along when the form is submitted (i.e. it ends up in the "name"
attribute of the generated  element).  It is named "property" here
(and on all the other HTML tags) for consistency with the way that
property names are referenced in the bean and logic tag libraries.

> This should explain the problem, but to elaborate, I want to include a
> hidden value in my form that comes from a bean other than the ActionForm
> bean for the form, i.e. from the parameter itself.
>
> If I change struts-html.told to required=false then the above code writes
> this:
> 
>
> If I change the above code to:
> 
>
> Then I get an error saying that there's no getGid() property on my gid
> bean... which is correct. But the general trend seems to be that property is
> optional where the bean can be evaluated as a String.
>
> Am I misunderstanding something?
>

You can use a runtime expression to accomplish what you're after:

  

  


> Matt.
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] MessageTag that returns the key instead of an exceptionwhen key not found.

[Craig R. McClanahan]

On Fri, 8 Mar 2002, Joachim Gjesdal wrote:

> Date: Fri, 08 Mar 2002 13:24:21 +0100
> From: Joachim Gjesdal <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: struts dev <[EMAIL PROTECTED]>
> Subject: [PATCH]  MessageTag that returns the key instead of an exception
> when key not found.
>
> Since others also have requested this, I'll propose this tiny change.

A better way to handle this (without breaking backwards compatibility with
the current functionality) is to set the "null" initialization parameter
on the controller servlet to "false".  This tells the message resources
module to return a message string like "??? foo ???" for an unknown
message key "foo".  This will cause the  tag to always get a
non-null value back, and thus never throw this exception.

>
> joachim gjesdal
>

Craig


> Index:
> jakarta-struts/src/share/org/apache/struts/taglib/bean/MessageTag.java
> ===
> RCS file:
> 
>/home/cvspublic/jakarta-struts/src/share/org/apache/struts/taglib/bean/MessageTag.java,v
> retrieving revision 1.6
> diff -u -r1.6 MessageTag.java
> ---
> jakarta-struts/src/share/org/apache/struts/taglib/bean/MessageTag.java
>  13 Jan 2002 00:25:36 -1.6
> +++
> jakarta-struts/src/share/org/apache/struts/taglib/bean/MessageTag.java
>  8 Mar 2002 12:14:36 -
> @@ -295,10 +295,7 @@
>  String message = RequestUtils.message(pageContext, this.bundle,
>this.localeKey, key, args);
>  if (message == null) {
> -JspException e = new JspException
> -(messages.getMessage("message.message", key));
> -RequestUtils.saveException(pageContext, e);
> -throw e;
> +message = key;
>  }
>
>  // Print the retrieved message to our output writer
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DynaActionFormClass : possible bug / request for enhancement

[Craig R. McClanahan]

On Thu, 7 Mar 2002, Laurent Farcy wrote:

> Date: Thu, 7 Mar 2002 16:50:10 +0100
> From: Laurent Farcy <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: "'Struts Developer's List (E-mail)'" <[EMAIL PROTECTED]>
> Subject: DynaActionFormClass : possible bug / request for enhancement
>
> Hi all,
>
> I 'm trying to use the last great struts 1.1 feature, aka dynabeans, for my
> application. I wasn't able to use it as is because DynaActionForm supposes
> the form bean properties (and so the form fields) are known at configuration
> time.
>
> In my case, the form bean properties are only known at runtime and I want
> the same form bean to handle totally different forms. I don't want the form
> developer to have to declare a new form bean in struts-config for each form.

Sheesh ... I already saved you having to write all the form bean classes
... some people are just never satisfied :-) :-).

> The 'business logic' I'm working upon is able to provide me with an object
> (let's name its class FormProperties) describing both the form properties
> and their initial values. The form page (ie jsp url) to use is also
> retrieved from the FormProperties object.
>
> So, I wrote a DynaActionForm subclass (let's say RuntimeDynaActionForm)
> which embeds the FormProperties object which is similar to an hashtable,
> except it also carries out property type information and is able to handle
> indexed properties by itself. Notice the FormProperties instance may change
> at every request depending on which form is selected by the user. A specific
> action is in charge of adding the FormProperties object in the http session
> and the DynaActionFormClass bound to the RuntimeDynaActionForm bean is
> redefined at each request by building the right form bean config from this
> http session attribute. This takes place in
> RuntimeDynaActionForm.reset(mapping, request).
>
> And you know what, it works ! It has to be enhanced like, for instance, form
> description object in the http session prevents concurrent form handling. My
> idea is very to reuse the maximum of struts (like validation, taglib, ...)
> starting from a slight different assumption.
>
> Now, the bug I think I found out. I had to change a little
> DynaActionFormClass. Apparently, it intends to double check the dynabean
> class is a sub-class of DynaActionForm when creating a new bean but does the
> opposite. Here is the patch I'm proposing.
>
>
> Index: DynaActionFormClass.java
> ===
> RCS file:
> /home/cvspublic/jakarta-struts/src/share/org/apache/struts/action/DynaAction
> FormClass.java,v
> retrieving revision 1.2
> diff -r1.2 DynaActionFormClass.java
> 326c326
> < if (!beanClass.isAssignableFrom(DynaActionForm.class)) {
> ---
> > if (!DynaActionForm.class.isAssignableFrom(beanClass)) {
>

Good catch ... I just committed the fix for this.

>
> Moreover, since my DynaActionFormClass object changes at every request, I
> have to clear all the already-registered DynaActionFormClass by calling
> DynaActionFormClass.clear() and create a new one by calling
> DynaActionFormClass.createDynaActionFormClass(config) to assign it to
> DynaActionForm dynaClass protected member. This is the only way I can
> replace the DynaActionFormClass associated with my special dynabean.
>
> It would be nice to have a static
> DynaActionFormClass.replaceDynaActionFormClass(config). I can code and
> submit it if you think it is meaningful.
>
> Perhaps, there was another way to do what i'm trying. Like modifying
> struts-config at runtime to add new FormBeanConfigs. But, I understood the
> application config is frozen... Let me know.
>

I can foresee a possible problem with implementing the
replaceDynaActionFormClass() method that you are proposing.  It would
cause the set of current properties to change for *all* of the form beans
created from this particular DynaActionFormClass, not just the new
instance you are creating.  This will break the actual DynaActionForm
beans themselves, becuse there is no way to go find them all and update
their internal hashmaps of propety values.

Essentially, you are wanting to create a new DynaActionFormClass
dynamically for every single bean.  I suppose you could accomplish that by
passing a unique name for the "name" property of each FormBeanConfig that
you pass, but that isn't going to scale very well -- you'll be creating
lots of these instances, but they won't get GC'd unless you call
DynaActionFormClass.clear() periodically.  This problem would not be as
bad if you cached the DynaActionFormClass instances you created, and
reused them when the same set of properties was required again later.

It might be feasible to create an implementation of DynaBean and DynaClass
that behaves in the manner you are visualizing (each DynaBean has a unique
set of properties even though they share the same DynaClass), but that
goes pretty

Re: Exception creating bean ...

[Craig R. McClanahan]

On Wed, 6 Mar 2002, Anthony Martin wrote:

> Date: Wed, 6 Mar 2002 15:34:17 -0800
> From: Anthony Martin <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: "Struts Developer's List (E-mail)" <[EMAIL PROTECTED]>
> Subject: Exception creating bean ...
>
> This one is a little hard to describe due to how it manifests.  I'd
> appreciate any suggestions.
>

One scenario that would cause this exception (but it wouldn't go away on a
restart, it would be repeatable) is if you had struts.jar in Tomcat's
"lib" directory, instead of /WEB-INF/lib of your webapp.  I just committed
a fix (will show up in the 20020310 nightly build) that makes this
particular scenario work -- but it won't help your problem ;-(.

> >From time to time when we start our server, we get a JspException that
> doesn't go away until we restart the server.  So it comes and goes *without*
> making changes to code or configuration files, and we're not sure what the
> root cause is.  In one place, the JspException reads:
>
> javax.servlet.jsp.JspException: Exception creating bean of class
> com.trams.struts.LoginForm: {1}
>   at
> org.apache.struts.taglib.html.FormTag.doStartTag(FormTag.java:610)
>   at org.apache.jsp.login$jsp._jspService(login$jsp.java:357)
>   at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>   .
>   .
>   .
>
> I've traced it down to the org.apache.struts.util.RequestUtil, on or about
> line 557 of the nightly build where it reads:
>
>   try {
> // FIXME - thread context class loader?
> Class clazz = Class.forName(config.getType());
> instance = (ActionForm) clazz.newInstance();
>   } catch (Throwable t) {
> LOG.error(servlet.getInternal().getMessage
> ("formBean", config.getType()), t);
> return (null);
>   }
>
> It throws a ClassNotFound exception on the forName line, and indeed returns
> a null value and adds an ERROR log entry as it's coded to do in case a
> Throwable is thrown.  It's interesting that just doing a restart fixes it.
> This happens even on our production server.  When it does, I just restart
> the Apache Tomcat service, and it's fine again.
>
> We're on Struts Nightly Build, Apache Tomcat 4.0.3, JDK 1.3.1, Windows 2000.
>

There has been a recently discovered problem in the Tomcat class loader --
if you have a JAR file that doesn't have the intervening directory levels
in the JAR, the class would not be recognized as being present, although
other classes could be loaded.  It's been fixed in the most recent Tomcat
nightly builds, and will be fixed in 4.0.4-beta-2 for the current
production branch.  But, again, this kind of thing should happen or not
happen consistently ... the sporadic nature is definitely mysterious.

>
> Anthony
>

Craig


> "Were it not for my little jokes, I could not bear the burdens of this
> office." - Abraham Lincoln
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Struts-Dev] Multi-App support and using actions across applications

[Craig R. McClanahan]

On Sat, 2 Mar 2002, Martin Cooper wrote:

> Date: Sat, 2 Mar 2002 15:47:47 -0800
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> Subject: Re: [Struts-Dev] Multi-App support and using actions across
> applications
>
> Yes, I expect that the multiple module support will remain essentially as is
> for Struts 1.1. (Unless Craig has any more nice surprises for us, that is!)
> This would be the first step in the scenario I described. Essentially, this
> provides the support many people have requested for hosting multiple Struts
> applications within a single web app.
>

This is my current thinking ... multiple application support has been
highly requested, and I think it's going to take a while to consider how
to do hierarchical things correctly, or even if we want it at all (yes,
Martin, I know you do :-).

In the mean time, my design goal was to make it possible to load multiple
independent Struts applications into a single webapp, for the following
purposes:

* An individual Struts app should be able to be packaged in a WAR
  by itself, or in combination with other Struts apps, with *no*
  changes to the code, pages, resources, or the struts-config.xml
  file.

* There should be no restrictions on using the same name for actions,
  form beans, forwards, and other configurable items across Struts
  apps -- in effect, each app gets its own "namespace".

* The Struts app that is used to handle a particular request is based
  on prefix mapping of the request URI (in a manner similar to the way
  a servlet container uses prefix mapping against the various context
  paths to choose which webapp to execute.

That being said, nothing stops you from sharing Java classes (actions,
form beans, utilities, and so no) between the individual applications that
are included together.  You cannot directly share JSP pages (although it
is easy to set up build processes that make multiple copies from a single
source repository at deployment time, if you need them shared).  The thing
that is definitely not shared in the current design is the configuration
information -- each Struts app has to be configured completely
independently to meet the goals described above.  IMHO, that's a Good
Thing -- sharing increases complexity and fragility of a large scale
application, by re-introducing cross dependencies that multiple app
support is striving to eliminate.

But we'll have to see how that all works out at some future point when a
solid design for hierarchical sharing is proposed.


> As Ted mentioned, we don't really have an official name yet. At some point
> in the discussions, Ted suggested that "modules" might be a good term for
> the sub-apps. Since then, I have adopted that terminology in the big app I
> am developing, so I, for one, would be happy if we selected that terminology
> for Struts itself. ;-) (At one point, we were calling them plug-ins within
> my team at work. I'm glad we didn't stick with that, since Craig has
> recently introduced to Struts a different feature with that name!)
>

In the internal comments, I've been calling these things sub-applications,
which is at least technically accurate, but not very cool sounding.  We've
been laughing off the idea of a Struts-let, but ...

> --
> Martin Cooper
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Struts 1.1 Beta 1 Release Plan

[Craig R. McClanahan]

On Sat, 9 Mar 2002, Martin Cooper wrote:

> Date: Sat, 9 Mar 2002 22:44:08 -0800
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: [VOTE] Struts 1.1 Beta 1 Release Plan
>
> Many new features have been added to Struts since the 1.0 release, and many
> bugs have been fixed. Therefore, I propose that we release the tip of the
> main trunk in CVS as Beta 1 for a Struts 1.1 release. I have checked in a
> proposed release plan, which is available for review on the Struts web site:
>
> http://jakarta.apache.org/struts/proposals/release-plan-1.1b1.html
>
> Release plans must pass by a majority vote of committers on the project, but
> all other interested parties are welcome to cast their votes (and/or make
> comments or suggestions on the plan) as well.
>
> --
> Vote:  Struts 1.1b1 Release Plan
> [X] +1  I am in favor of the release, and will help support it
> [ ] +0  I am in favor of the release, but am unable to help support it
> [ ] -0  I am not in favor of the release
> [ ] -1  I am against this proposal (must include a reason).
> --
>

One of the things we have found helpful on Tomcat releases lately is to
include an up-to-the-minute list of the bugs we are talking about that
need to be dealt with.  As bugs are dealt with, the release plan is
updated on the web site, so people can see what's left.

I volunteer to accumulate an initial list of target bugs later this
afternoon, and update the release plan doc accordingly.

> --
> Martin Cooper
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Progress on bugs

[Craig R. McClanahan]

FYI, I have cleaned up all the outstanding bug reports for Commons
components that the HEAD branch of Struts relies on except for:

3893 - Digester -   Enhancement to handling for body text that is
intermixed with nested elements (not relevant
for Struts use)

6685 - Validator -  Forces Digester debugging to level 1, which causes
lots of output with lots of rules.

I'm working on the list of ouststanding Struts bugs that I think we need
to deal with in a 1.1 time frame, but it's not done yet.

Craig



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Progress on bugs

[Craig R. McClanahan]

On Sun, 10 Mar 2002, Martin Cooper wrote:

> Date: Sun, 10 Mar 2002 22:44:14 -0800
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Progress on bugs
>
> Sounds good.
>
> A related question: Which Commons components do we need to be officially
> released so that Struts 1.1 depends only on released versions (and not
> nightly builds)? The ones I am aware of are beanutils, dbcp and pool. Are
> there others?
>

Here's the "must have" list from my perspective:

  beanutils
  collections (required by beanutils)
  dbcp (I'm going to make GenericDataSource a wrapper around this
so we don't have to maintain two pools, plus it eliminates
our current problem compiling under 1.4)
  digester
  logging
  pool (required by dbcp)

Features that we currently offer as internal-to-Struts and commons (need
to pick one or the other):

  services
  validator

Features we've talked a lot about supporting but haven't finished yet
(and maybe should leave for later?):

  resources (this would probably be easy to switch to if its done)
  workflow (this should probably wait -- I've got some thoughts on a
different approach to the Step definitions)

Also, isn't it time for "struts-tiles.jar" instead of "tiles.jar"?


> Should we try to get the Resources project out of the sandbox and released,
> so that we can use it for Struts 1.1, or should we leave that for a later
> release?
>
> --
> Martin Cooper
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Deprecations and Struts

[Craig R. McClanahan]

On Sun, 10 Mar 2002, Martin Cooper wrote:

> Date: Sun, 10 Mar 2002 22:31:43 -0800
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Deprecations and Struts
>
> I've cleaned up a bunch of deprecations in the web apps that are part of
> Struts. The remaining deprecation warnings fall into three groups:
>
> 1) Deprecations related to the differences between the Servlets 2.2 and
> Servlets 2.3 APIs. We cannot do anything about these, since we have to
> remain compatible with Servlets 2.2, at least until Servlets 2.3 has "taken
> over".
>

There's lots of cool stuff in 2.3 :-).  But we should definitely stay 2.2
compliant for this round.

> 2) Deprecations in Tiles. I did not attempt to deal with these, since Tiles
> has a life of its own, independent of Struts. Cedric is in the best position
> to know if any changes are appropriate here.
>
> 3) Digester related deprecations. I know how to fix the Digester.log()
> problem, but I wasn't sure what to do with the Digester.setDebug() calls.
> The current implementation does nothing, but it wasn't clear to me what we
> should be calling instead, given that the deprecation comment indicates that
> it is logging-implementation-dependent. Suggestions appreciated. ;-)
>

I'd suggest we just dump the Digester.setDebug() calls, since Digester
itself now uses commons-logging internally so the setting is ignored (at
least by the version we'll need to ship in 1.1).

> --
> Martin Cooper
>
Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Deprecations and Struts

[Craig R. McClanahan]

On Mon, 11 Mar 2002, Cedric Dumoulin wrote:

> Date: Mon, 11 Mar 2002 11:30:51 +0100
> From: Cedric Dumoulin <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Deprecations and Struts
>
>
>   I can deal / try to clean  deprecations from Tiles ;-)
>
>   But what versions of servlet, ant, jdk, xml parser should we
> officially use ?
>

My votes:
- Servlet 2.2 (and therefore JSP 1.1), but we should test under
  at least Tomcat 4 and the J2EE RI 1.3 as well for compatibility
- Ant 1.4.1
- JDK 1.3.1 (until I remove the JDBC-related compile time problem,
  then we should ensure that we also run under 1.4.0)
- Use only JAXP/1.1 APIs, but test with Xerces 1.4.x and Xerces 2.0.x
  (note that JAXP/1.2 uses Xerces 2 code as its default parser,
  so this protects the future as well).

XML parsers inside some J2EE containers have caused us some issues in the
past -- it would be really good to get some beta testers signed up on the
most common platforms (WebLogic, WebSphere, and so on) in addition to
Tomcat and the stand-alone pieces.  Ideally we'll cover both J2EE 1.2 and
J2EE 1.3 based platforms in this testing.

> Cedric
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Patch] DynaActionFormClass.

[Craig R. McClanahan]

Yarg, I botched this when fixing a Bugzilla bug against the old
"assignable from" test that didn't really allow subclassing.

I just checked in this fix.  Martin, you'll really want to update the
beta1 tag to include it -- otherwise DynaActionForms (including the login
page of the struts example) won't work.

This is also the cause of the humorous self-contradictory error message
that Matt pointed out.

Craig

On Wed, 13 Mar 2002, Porter, Roy wrote:

> Date: Wed, 13 Mar 2002 15:12:51 -
> From: "Porter, Roy" <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: [Patch] DynaActionFormClass.
>
> >From introspect method in DynaActionFormClass
>
>  if (DynaActionForm.class.isAssignableFrom(beanClass)) {
>
> this should be
>
>  if (!DynaActionForm.class.isAssignableFrom(beanClass)) {
>
> I raised this a couple of weeks ago (the whole line was the other way round
> then). I was ignored 
>
> It was raised again by somebody else last week, but there's still a problem
> with the latest version on CVS, i.e. the ! is missing.
>
> Can somebody please put this right ?
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: FormTag problem with VisualAge

[Craig R. McClanahan]

On Wed, 13 Mar 2002, Porter, Roy wrote:

> Date: Wed, 13 Mar 2002 15:24:07 -
> From: "Porter, Roy" <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: FormTag problem with VisualAge
>
> Whenever I get a new copy of the Struts Source, I have to go in and make the
> following change to the FormTag java code:
>
>
> >From doEndTag:
>
> Remove:
>   pageContext.removeAttribute(Constants.BEAN_KEY,
> PageContext.REQUEST_SCOPE);
>   pageContext.removeAttribute(Constants.FORM_KEY,
> PageContext.REQUEST_SCOPE);
> Add:
>   pageContext.getRequest().removeAttribute(Constants.BEAN_KEY);
>   pageContext.getRequest().removeAttribute(Constants.FORM_KEY);
>
> I realise this is probably only affecting VisualAge (& possibly WebSphere
> ?), but could this change be made to the base code ?
>

I'm a little hesitant to do this, because the JSP spec does *not* require
that they do exactly the same thing.  It's legal for a container to cache
the current state of the attributes and then sync up at certain defined
points.

To be fair, the JSP code that WebSphere is using for this originally came
from a bug in Tomcat 3.0, which incorrectly disallowed removing attributes
from request scope.  That was more than a couple of years ago, though;
it's really time for IBM to have fixed this by now.

> Roy.
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DynaActionForm questions

[Craig R. McClanahan]

Hi Bryan,

On 15 Mar 2002, Bryan Field-Elliot wrote:

> Date: 15 Mar 2002 13:33:05 -0700
> From: Bryan Field-Elliot <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: DynaActionForm questions
>
> Hi,
>
> I'm just today getting around to having a peek at the new
> DynaActionForm. I'm slightly confused as to how useful this is, in a
> setting in which you don't know at compile-time what fields you're going
> to need to ask for.
>

Interesting that this has come up twice in the last week.

The current DynaActionForm implementation is indeed aimed at the case
where you know ahead of time which properties you need the bean to
represent, so that you can configure them in the struts-config.xml file.
The basic idea is to avoid the need to create custom ActionForm bean
classes for all the simple cases.

Right now, you would still need to create your own bean if you needed a
custom validate method, but even there we can look at adding declartive
ways to define simple validations (required fields, date formats, and so
on) so that even those don't require any custom Java code.

Since form beans are really part of the view tier in the Struts
implementation of MVC, one of the benefits of this will be that
responsibility for designing and configuring form beans can now be
migrated to the page designer that understands enough XML to code the
appropriate struts-config settings, instead of requiring a Java developer
to do this.  And, since creating form bean classes is pretty boring, the
Java developer gets to stay focused on the fun stuff.

> Let's say for example I'm introspecting a JDBC table for a list of
> columns and types, and want to dynamically build a form for CRUD
> operations on this table. Or, instead of a JDBC table, maybe I want to
> assemble a form out of an XML DTD or Schema.

DynaActionForm doesn't help you do either of these without custom Java
form bean classes.  Of course, neither did the original-style form beans
...

Doing this kind of form creation dynamically, though, is going to require
more than just "DynaDynaActionForm" classes.  You'll also need to figure
out how to decide what field prompts to create, what data types and
formats are valid, and other stuff like that.

>
> I see that I can build an ActionForm class to hold values for this
> table, out of DynaClasses (I'm basically already doing this in the
> Simper project).
>
> Where I'm missing something is, are there new Struts JSP tags for
> building an HTML form out of a DynaActionForm? I don't see them, but
> perhaps I'm missing the obvious.
>

You don't see them because they aren't needed :-)

> If the answer is, "There are no new JSP tags for building HTML forms out
> of DynaActionForms", then I'm wondering just how useful DynaActionForm
> is without it... What's a typical use case for it?
>

The existing Struts tags work fine because they use BeanUtils and
PropertyUtils underneath.  These two classes have been made smart about
the bean object they are manipulating -- if you pass them a DynaBean, they
use the dynamic getters and setters.  Otherwise they use the Java
reflection mechanism as before.

So, you can even change your mind about whether a particular form bean is
a DynaActionForm, or a plain old-style form bean, without affecting your
pages at all -- just change the  declaration and you are all
set.  Pretty slick, huh?  :-)

> Thanks,
>
> Bryan
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: DynaActionForm questions

[Craig R. McClanahan]

On Fri, 15 Mar 2002, Heath Chiavettone wrote:

> Date: Fri, 15 Mar 2002 15:56:42 -0800
> From: Heath Chiavettone <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: DynaActionForm questions
>
> Hello all,
>
> I'm looking for more information related to this thread.  I can see the
> javadoc for the class, but I can't seem to find any real documentation on
> how to configure things in the struts-config.xml file.  If someone can point
> me to where this information is, I'd appreciate it.
>

It's not heavily covered in the docs yet.  The places I would look first:

* The "lib/struts-config_1_1.dtd" file (the DTD for struts-config.xml
  files) documents the new attributes of the  and nested
   elements).

* The struts-config.xml for the Struts example app uses a dynamic form
  bean for the login form, configured like this:


  
  


Both of these are available in the recent nightly builds (which run from
the HEAD branch).

You might also download the commons-beanutils package (and associated
docs) from the Jakarta web site.  The Javadocs cover some of the general
concepts of programming DynaBeans:

  http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-beanutils/

While you're there, Struts 1.1 will use several other Commons packages as
enhanced features or as replacements for code from org.apache.struts.util
- you might want to grab the packages for the collections, dbcp, digester,
pool, services, and validator packages as well.

> TIA,
> Heath
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Validator move to main distribution

[Craig R. McClanahan]

I'm +1 with the proposal, but I'd also be ok with using
org.apache.struts.validator instead of org.apache.struts.action for the
five main classes.

I will update the nightly builds to include jakarta-regexp (which we'll
also need to ship in the "lib" directory), and tell Gump about it as well,
once I see the check-ins.

Craig


On Sun, 17 Mar 2002, David Winterfeldt wrote:

> Date: Sun, 17 Mar 2002 16:56:29 -0800 (PST)
> From: David Winterfeldt <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Validator move to main distribution
>
> I'm going to check this in later tonight if there are
> no objections to the packages I've placed things
> under.  I'll add the webapp example and documentation
> next.  The Jakarta Regexp jar will need to get added
> to the properties file for the nightly builds.
>
> added to org.apache.struts.action
> (ValidatorServlet was not brought over since it is
> replaced by ValidatorPlugIn.  ValidatorServlet is
> deprecated in the contrib/validator directory though.)
> src/share/org/apache/struts/action/DynaValidatorActionForm.java
> src/share/org/apache/struts/action/DynaValidatorForm.java
> src/share/org/apache/struts/action/ValidatorActionForm.java
> src/share/org/apache/struts/action/ValidatorForm.java
> src/share/org/apache/struts/action/ValidatorPlugIn.java
>
> added to org.apache.struts.taglib.html
> src/share/org/apache/struts/taglib/html/JavascriptValidatorTag.java
>
> added to org.apache.struts.util
> src/share/org/apache/struts/util/StrutsValidator.java
> src/share/org/apache/struts/util/StrutsValidatorUtil.java
>
> wasn't sure where to put this, but it seemed like a
> good spot
> conf/share/validator-rules.xml
>
> The Jakarata regexp package was added to
> build.properties.sample.
>
> Jakarata regexp package was added to the classpath and
> validator-rules.xml is now moved to dist/lib.
> build.xml
>
> JavascriptValidatorTag was added this.
> doc/userGuide/struts-html.xml
>
> David
>
> __
> Do You Yahoo!?
> Yahoo! Sports - live college hoops coverage
> http://sports.yahoo.com/
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DynaActionForm questions

[Craig R. McClanahan]

On Mon, 18 Mar 2002, Johan Compagner wrote:

> Date: Mon, 18 Mar 2002 09:42:49 +0100
> From: Johan Compagner <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: DynaActionForm questions
>
> The Bean en PropertyUtils should also be completely working with dynbean
> interface. for example PropertyUtils.copyProperties(object,object)
> doesn't work right now
>

It does for my test cases ... can you be more specific?  (Doing this on
COMMONS-DEV is probably better than here.)

> I see that they want to do something with PropertyDescriptors? I think
> that is a dead end. Because property descripters are completely
> different they are really for get and set methods.
>

I just checked in an enhancement to commons-beanutils that makes all of
the Converters, pluggable, and adds the ability to plug your own in.  This
will be much more efficient than using PropertyDescriptors for the typical
way that Struts programs do conversions.  (Default behavior is backwards
compatible, of course :-).

> johan
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Unnecessary multiple URLEncoder.encode() in RequestUtils

[Craig R. McClanahan]

On Mon, 18 Mar 2002, Johannes Carlén wrote:

> Date: Mon, 18 Mar 2002 14:48:41 +0100 (CET)
> From: Johannes Carlén <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Unnecessary multiple URLEncoder.encode() in RequestUtils
>
> Hi,
> I was running our application with JProbe and
> discovered that some pages with many html:links
> consumed a whole lot of memory. I did some research
> and found the computeURL() method in
> org.apache.struts.util.RequestUtils. In computeURL()
> *every* single key and value is url encoded by itself
> and then appended to the url string.
>

This is necessary, for example, to avoid URL-encoding the "=" sign between
the name and the value -- if we encoded that, the server won't recognize
it as having special meaning.  Same with the "&" character that separates
the multiple parameters.

> When trying a very simple test page with only one
> html:link tag on it and only one parameter (key/value)
> this increased the memory consumption by nearly
> 200kb's, and this consumption is linear by the number
> of parameters added!!! When changing the code,
> suddenly the memory consumed by some of our pages went
> down from 7-8MB's to 1.5MB. A real gain there...
>
> When the url encoding takes place, some memory is used
> every time and I think this method should be used with
> care and only when needed. In this case, on the whole
> url string at the end of the method.
>

It sounds appealling to do this, but can you provide a patch that does
what you propose, without destroying the ability of the server to parse
the query string correctly once we send it?

> Will any of you guys take care of this or would you
> like some help? I have the modified source code by
> hand if you'd like it (however this should be a quick
> fix anyhow).
>
> Best regards
> /Johannes
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Beta 1 update

[Craig R. McClanahan]

+1, but if you can wait until after midnight (Pacific Time) tonight, I'll
be able to get some more bug fixes done.

I also did some fixes/enhancements in commons-beanutils over the weekend,
which raises a point -- it would also be good to tag the specific bits of
the Commons packages that you include in the beta with the same tag.
Since Martin has commit access on jakarta-commons, this shouldn't be a
problem.  And, nobody should complain since CVS doesn't give a rip how
many tags there are (just don't create branch tags).

Craig


On Sun, 17 Mar 2002, Martin Cooper wrote:

> Date: Sun, 17 Mar 2002 21:41:22 -0800
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Beta 1 update
>
> First of all, I sincerely apologise to you all for the length of time it is
> taking to get Beta 1 out the door. Unfortunately, I managed to get sick, and
> still haven't quite got back to full strength yet.
>
> A few things have happened since I tagged the CVS tree for Beta 1.
>
> 1) Craig has made a boatload of bug fixes to the code base.
>
> 2) Arron made some changes to the nested taglib which he requested be
> included in Beta 1.
>
> 3) David made many changes to Validator and the way it hooks into Struts. He
> also updated some of the files in CVS to tag them as part of Beta 1.
>
> 4) Rob is checking in UML diagrams as I write this.
>
> Given these changes, and especially given the already-updated tags in CVS, I
> think it would make sense at this point to retag the entire tree to pick up
> the latest of everything as Beta 1. This would give us a better, stronger,
> first beta. I promise to complete the beta release process in one phase this
> time, to avoid a repeat of the current situation.
>
> Is everyone OK with this approach?
>
> --
> Martin Cooper
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Beta 1 update

[Craig R. McClanahan]

On Mon, 18 Mar 2002, Couball, James wrote:

> Date: Mon, 18 Mar 2002 09:59:38 -0800
> From: "Couball, James" <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Beta 1 update
>
> Craig,
>
> Some ideas for tracking dependant components...
>
> I must admit to some confusion about what version of the jakarta-commons and
> other components to use with the nightly struts builds because (1) sometimes
> the last release of the dependent component no longer works with the struts
> or (2) the latest nightly build of the dependent component either does not
> work or is considered too experimental to use.  Would it be beneficial for
> everyone if we determined the what version (or build #/date) of the
> dependant components was the one to use with each nightly build?
>

Nightly builds of Struts follow the GUMP philosophy
(http://jakarta.apache.org/gump) -- latest and greatest of everything.
They also include all of the exact JAR files that they are built against,
and should be used that way.  This is necessary because new features in
Struts often depend on new features of the component libraries.  Because
these builds all take place on my machine, they also correspond to the
nightly build (of the same date) for each of the Commons components in
question.

For releases, a prerequisite for a Struts 1.1 final release will be final
releases of the component libraries so that users can depend on a stable
version.

> I know that there is some online documentation to this effect, but it
> doesn't appear that this is updated except at major releases.  Am I wrong in
> asserting that this documentation is not correct for the latest nightly
> build?
>

The only docs that are accurate for a nightly build are those inside that
nightly build (and even then only if the developers update the docs :-).

It would be nice if the online version of the docs could also be updated
auto-magically.  There are some Jakarta-wide initiatives in that direction
that Struts (and Tomcat, and Commons, ...) will be able to take advantage
of

> Also, seems to me that labeling the component depended upon
> (jakarta-commons) is backwards.  Shouldn't we just document in
> jakarta-struts the version (or build #/date) of each component used?  Are
> the nightly builds of these components already automatically tagged in CVS
> for quick recoverly?
>

Nightly builds of Struts are dependent on nightly builds (of the same
date) of all the commons components).  Tagging on a daily basis is
overkill, IMHO.

> Sincerely,
> James.
>

Craig


> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 18, 2002 9:24 AM
> To: Struts Developers List
> Subject: Re: Beta 1 update
>
> +1, but if you can wait until after midnight (Pacific Time) tonight, I'll
> be able to get some more bug fixes done.
>
> I also did some fixes/enhancements in commons-beanutils over the weekend,
> which raises a point -- it would also be good to tag the specific bits of
> the Commons packages that you include in the beta with the same tag.
> Since Martin has commit access on jakarta-commons, this shouldn't be a
> problem.  And, nobody should complain since CVS doesn't give a rip how
> many tags there are (just don't create branch tags).
>
> Craig
>
>
> On Sun, 17 Mar 2002, Martin Cooper wrote:
>
> > Date: Sun, 17 Mar 2002 21:41:22 -0800
> > From: Martin Cooper <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Beta 1 update
> >
> > First of all, I sincerely apologise to you all for the length of time it
> is
> > taking to get Beta 1 out the door. Unfortunately, I managed to get sick,
> and
> > still haven't quite got back to full strength yet.
> >
> > A few things have happened since I tagged the CVS tree for Beta 1.
> >
> > 1) Craig has made a boatload of bug fixes to the code base.
> >
> > 2) Arron made some changes to the nested taglib which he requested be
> > included in Beta 1.
> >
> > 3) David made many changes to Validator and the way it hooks into Struts.
> He
> > also updated some of the files in CVS to tag them as part of Beta 1.
> >
> > 4) Rob is checking in UML diagrams as I write this.
> >
> > Given these changes, and especially given the already-updated tags in CVS,
> I
> > think it would make sense at this point to retag the entire tree to pick
> up
> > the latest of everything as Beta 1. This would give us a better, stronger,
> > fir

RE: Beta 1 update

[Craig R. McClanahan]

On Mon, 18 Mar 2002, Immanuel, Gidado-Yisa wrote:

> Date: Mon, 18 Mar 2002 14:46:06 -0500
> From: "Immanuel, Gidado-Yisa" <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Beta 1 update
>
> Just trying to get an idea of the proposed (minimum)
> version of the various commons packages needed to
> build struts 1.1.  Here's what I've got so far:
>
>   COMPONENTVERSION/CVS-TAG  NEEDED TO BUILD
>   commons-beanutils1.3  struts-core
>   commons-digester 1.1.1struts-core
>   commons-collections  2.0? struts-core
>   commons-logging  1.0  struts-core
>   commons-pool STRUTS_11?   struts-example?
>   commons-dbcp STRUTS_11?   struts-example?
>   commons-validatorSTRUTS_11?   struts-example?
>   commons-sandbox-services STRUTS_11?   struts-example?
>

The basic rules are very simple:

- Nightly builds of Struts depend on the corresponding nightly builds
  of Commons components.  All the required ones are included with the
  Struts distro, so this should be no big deal.  This is stuff that is
  in active development, so there's no assurance that everything at any
  particular point in time has received any overall testing.

- Beta builds of Struts will tag the precise snapshot of the Commons
  components they are built with, but will not require formal releases.
  Doing so would just slow down the development process with no benefits.

commons-pool and commons-dbcp are required for Struts 1.1 now --
GenericDataSource is just a wrapper around the DBCP-provided
functionality.  Among other things, this removes the only reason you could
not compile Struts on a JDK 1.4 system.

commons-validator is getting integrated into the core, so it will also be
required.

Oleg has wanted to integrate commons-services -- the simplest way to do
this would be to write an org.apache.struts.action.PlugIn to pull in
whatever services are needed.  I haven't had time to do such a thing
myself.

> My personal preference is to only use released components
> (i.e. ones with version numbers).  But I understand that
> it may not be possible considering that some components
> are not yet released (and some are even in the sandbox).
>

As I said before, a prerequisite for a Struts 1.1 release is an official
release of the commons components it depends on.  Making this a constraint
for day-to-day development, or even alpha/beta releases would only slow
things down.

> - Gidado
>

Craig


> > -Original Message-
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, March 18, 2002 12:24 PM
> > To: Struts Developers List
> > Subject: Re: Beta 1 update
> >
> >
> > +1, but if you can wait until after midnight (Pacific Time)
> > tonight, I'll
> > be able to get some more bug fixes done.
> >
> > I also did some fixes/enhancements in commons-beanutils over
> > the weekend,
> > which raises a point -- it would also be good to tag the
> > specific bits of
> > the Commons packages that you include in the beta with the same tag.
> > Since Martin has commit access on jakarta-commons, this shouldn't be a
> > problem.  And, nobody should complain since CVS doesn't give a rip how
> > many tags there are (just don't create branch tags).
> >
> > Craig
> >
> >
> > On Sun, 17 Mar 2002, Martin Cooper wrote:
> >
> > > Date: Sun, 17 Mar 2002 21:41:22 -0800
> > > From: Martin Cooper <[EMAIL PROTECTED]>
> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > > To: Struts Developers List <[EMAIL PROTECTED]>
> > > Subject: Beta 1 update
> > >
> > > First of all, I sincerely apologise to you all for the
> > length of time it is
> > > taking to get Beta 1 out the door. Unfortunately, I managed
> > to get sick, and
> > > still haven't quite got back to full strength yet.
> > >
> > > A few things have happened since I tagged the CVS tree for Beta 1.
> > >
> > > 1) Craig has made a boatload of bug fixes to the code base.
> > >
> > > 2) Arron made some changes to the nested taglib which he
> > requested be
> > > included in Beta 1.
> > >
> > > 3) David made many changes to Validator and the way it
> > hooks into Struts. He
> > > also updated some of the files in CVS to tag them as part of Beta 1.
> > >
> > > 4) Rob is checking in UML diagrams as I write this.
> > >
>

Re: NestedFormTag in cvs head

[Craig R. McClanahan]

Everything compiles for me, but only after I built all of the commons
packages from current CVS code as well.

Craig

On Tue, 19 Mar 2002, Arron Bates wrote:

> Date: Tue, 19 Mar 2002 13:55:53 +1100
> From: Arron Bates <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: NestedFormTag in cvs head
>
> It fails to compile here consistently?...
>
> Compiles fine for me. The NestedIterate does the same thing with its
> super.doAfterBody() method use also, it's a surprise that it would only
> fail on this one.
>
>
> Arron.
>
> David Winterfeldt wrote:
>
> >v1.3 of
> >src/share/org/apache/struts/taglib/nested/html/NestedFormTag.java
> >won't compile for me.
> >
> >[javac] symbol  : method doAfterBody  ()
> >[javac] location: class
> >org.apache.struts.taglib.html.FormTag
> >[javac] int temp = super.doAfterBody();
> >
> >Anyone else having this problem?
> >
> >David
> >
> >__
> >Do You Yahoo!?
> >Yahoo! Sports - live college hoops coverage
> >http://sports.yahoo.com/
> >
> >--
> >To unsubscribe, e-mail:   
> >For additional commands, e-mail: 
> >
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Beta 1 update

[Craig R. McClanahan]

On Mon, 18 Mar 2002, Martin Cooper wrote:

> Date: Mon, 18 Mar 2002 20:24:34 -0800
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Beta 1 update
>
> OK, that's fine. I can do the build either Tuesday or Wednesday. Let's shoot
> for code freeze at midnight tonight (i.e. 12:00 Pacific time on Monday).
> David (and Craig), if you need more time, let me know and we can extend the
> deadline to midnight on Tuesday instead.
>
> I'll make sure I tag the appropriate parts of Commons with the same tag.
> However, let me make sure what I have in mind matches what you have in mind,
> Craig. My plan is to build Beta 1 with the Release versions of Commons
> projects that we *can* build against, and CVS versions of those projects
> that don't have Release versions that we can use. This would mean Release
> versions of Collections (1.0), Digester (1.1.1) and Logging (1.0), and CVS
> versions of the rest. I would only tag the non-release project trees. Is
> this also what you had in mind?
>

I've only tested the Struts 1.1 code against the current HEAD branch of
Digester.  This is also important in order to be able to put struts.jar in
a shared repository (like common/lib in Tomcat 4).

The 1.0 version of collections should be fine -- we only use FastHashMap.

> One more thing. Craig, there is one file that you removed after I previously
> tagged CVS, so I need to, uh, update the repository to remove the tag so
> that the file is not included in Beta 1. The file I need access to is:
>
> /home/cvs/jakarta-struts/src/share/org/apache/struts/util/Attic/GenericConne
> ction.java,v
>
> If you could chown the file to me, or allow group write access, I can make
> the change. Thanks.
>

Unfortunately, only root can chown files to someone else.  I'd suggest we
just create a new "beta 1" tag instead.

> --
> Martin Cooper
>

Craig


>
> - Original Message -
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Monday, March 18, 2002 9:23 AM
> Subject: Re: Beta 1 update
>
>
> > +1, but if you can wait until after midnight (Pacific Time) tonight, I'll
> > be able to get some more bug fixes done.
> >
> > I also did some fixes/enhancements in commons-beanutils over the weekend,
> > which raises a point -- it would also be good to tag the specific bits of
> > the Commons packages that you include in the beta with the same tag.
> > Since Martin has commit access on jakarta-commons, this shouldn't be a
> > problem.  And, nobody should complain since CVS doesn't give a rip how
> > many tags there are (just don't create branch tags).
> >
> > Craig
> >
> >
> > On Sun, 17 Mar 2002, Martin Cooper wrote:
> >
> > > Date: Sun, 17 Mar 2002 21:41:22 -0800
> > > From: Martin Cooper <[EMAIL PROTECTED]>
> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > > To: Struts Developers List <[EMAIL PROTECTED]>
> > > Subject: Beta 1 update
> > >
> > > First of all, I sincerely apologise to you all for the length of time it
> is
> > > taking to get Beta 1 out the door. Unfortunately, I managed to get sick,
> and
> > > still haven't quite got back to full strength yet.
> > >
> > > A few things have happened since I tagged the CVS tree for Beta 1.
> > >
> > > 1) Craig has made a boatload of bug fixes to the code base.
> > >
> > > 2) Arron made some changes to the nested taglib which he requested be
> > > included in Beta 1.
> > >
> > > 3) David made many changes to Validator and the way it hooks into
> Struts. He
> > > also updated some of the files in CVS to tag them as part of Beta 1.
> > >
> > > 4) Rob is checking in UML diagrams as I write this.
> > >
> > > Given these changes, and especially given the already-updated tags in
> CVS, I
> > > think it would make sense at this point to retag the entire tree to pick
> up
> > > the latest of everything as Beta 1. This would give us a better,
> stronger,
> > > first beta. I promise to complete the beta release process in one phase
> this
> > > time, to avoid a repeat of the current situation.
> > >
> > > Is everyone OK with this approach?
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Declarative Exception Handling - Any Documentation?

[Craig R. McClanahan]

On Wed, 20 Mar 2002, Matt Raible wrote:

> Date: Wed, 20 Mar 2002 17:18:45 -0700
> From: Matt Raible <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Declarative Exception Handling - Any Documentation?
>
> I *think* declarative exception handling has been added to the 1.1 beta
> 1 - correct me if I'm wrong.  If so, where can I find good documentation
> and examples on how to use it?  This is all I found:
>
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg04150.html
>

It has.

To use it, you have to use the (new) execute() method in your Actions,
instead of perform() -- the signature includes "throws Exception" so that
you can throw any kind of exception you wish, and then have the controller
catch it.

To configure usage, use the  elements inside a
 section for global definitions, or inside an 
element for local overrides, analogous to the way forwards work.

A contrived use of this is in the Struts example webapp -- if you enter
the username "arithmetic", LogonAction will throw an ArithmeticException.
Likewise, if you enter the username "expired" it will throw an
ExpiredPasswordException (a business logic exception unique to this
webapp).  Only the business logic exception has a defined handler:

  

  

> Also, will Tiles be adapted as a Plug In?
>

Makes sense to me ... but I'm not going to have a chance to do it.

> I upgraded my app using 1.1 beta 1 with Tiles & Validator this afternoon
> - took me about 10 minutes.  Mostly validator changes.  Nice work!
>

Cool!

> Matt
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html/doc-files- New directory

[Craig R. McClanahan]

On 21 Mar 2002 [EMAIL PROTECTED] wrote:

> Date: 21 Mar 2002 05:51:06 -
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: cvs commit:
> jakarta-struts/src/share/org/apache/struts/taglib/html/doc-files - New
> directory
>
> rleland 02/03/20 21:51:06
>
>   jakarta-struts/src/share/org/apache/struts/taglib/html/doc-files - New directory
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [GUMP] Build Failure - Struts

[Craig R. McClanahan]

On Thu, 21 Mar 2002, Couball, James wrote:

> Date: Thu, 21 Mar 2002 13:16:10 -0800
> From: "Couball, James" <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: [GUMP] Build Failure - Struts
>
> I think the gump build failed because the jakarta-struts.xml project file
> does not list jakarta-regexp as a dependency.  This dependency was
> introduced with the Validator integration.
>
> I think this could be solved with the following line added after the 
> line:
>
> 
>
> Please correct me if I am wrong as I am new to gump.
>

That was my fault ... I promised to add this.  Now it's done, but I hope
it's right (jakarta-regexp's build process is pretty different from the
others, so I don't know if more is necessary to match up the property name
and the output JAR that is created).

> Sincerely,
> James.

Craig


>
> -Original Message-
> From: Craig McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 21, 2002 5:10 AM
> To: [EMAIL PROTECTED]
> Subject: [GUMP] Build Failure - Struts
>
> 
> This email is autogenerated from the output from:
> 
> 
>
> Buildfile: build.xml
>
> init:
>  [echo] - jakarta-struts 1.1-b1 -
>  [echo]
>  [echo] java.class.path =
> /home/rubys/jakarta/xml-commons/java/external/build/xml-apis.jar:/home/rubys
> /jakarta/xml-xalan/java/build/xalan.jar:.:/usr/java/jdk1.3.1_02/lib/tools.ja
> r:/usr/java/jdk1.3.1_02/jre/lib/rt.jar:/usr/java/jdk1.3.1_02/lib/tools.jar:/
> home/rubys/jakarta/jakarta-struts/target/library/classes:/home/rubys/jakarta
> /jakarta-struts/target/tiles/library/classes:/home/rubys/jakarta/jakarta-ant
> /dist/lib/ant.jar:/home/rubys/jakarta/jakarta-ant/dist/lib/optional.jar:/opt
> /jdbc2_0/jdbc2_0-stdext.jar:/home/rubys/jakarta/jakarta-servletapi-4/lib/ser
> vlet.jar:/home/rubys/jakarta/xml-xerces2/java/build/xercesImpl.jar:/home/rub
> ys/jakarta/xml-xerces2/java/build/xmlParserAPIs.jar:/home/rubys/jakarta/jaka
> rta-commons/beanutils/dist/commons-beanutils.jar:/home/rubys/jakarta/jakarta
> -commons/collections/dist/commons-collections.jar:/home/rubys/jakarta/jakart
> a-commons/digester/dist/commons-digester.jar:/home/rubys/jakarta/jakarta-com
> mons/logging/dist/commons-logging.jar:/home/rub!
> ys/jakarta/jakarta-commons/pool/dist/commons-pool.jar:/home/rubys/jakarta/ja
> karta-commons/dbcp/dist/commons-dbcp.jar:/home/rubys/jakarta/jakarta-commons
> -sandbox/services/dist/commons-services.jar:/home/rubys/jakarta/jakarta-comm
> ons/validator/dist/commons-validator.jar
>  [echo] java.home = /usr/java/jdk1.3.1_02/jre
>  [echo] user.home = /home/rubys
>
> prepare.dist:
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/dist
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/dist/lib
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/dist/webapps
>
> prepare.library:
> [mkdir] Created dir:
> /home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF
> [mkdir] Created dir:
> /home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF/tlds
> [mkdir] Created dir:
> /home/rubys/jakarta/jakarta-struts/target/library/classes/org/apache/struts/
> resources
>  [copy] Copying 1 file to
> /home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF
>  [copy] Copying 4 files to
> /home/rubys/jakarta/jakarta-struts/target/library/classes/org/apache/struts/
> resources
>  [copy] Copying 1 file to
> /home/rubys/jakarta/jakarta-struts/target/library
>  [copy] Copying 1 file to
> /home/rubys/jakarta/jakarta-struts/target/library
>  [copy] Copying 1 file to
> /home/rubys/jakarta/jakarta-struts/target/library
>  [copy] Copying 1 file to
> /home/rubys/jakarta/jakarta-struts/target/library
>  [copy] Copying 1 file to
> /home/rubys/jakarta/jakarta-struts/target/library
>  [copy] Copying 1 file to
> /home/rubys/jakarta/jakarta-struts/target/library
>  [copy] Copying 1 file to
> /home/rubys/jakarta/jakarta-struts/target/library
>  [copy] Copying 1 file to
> /home/rubys/jakarta/jakarta-struts/target/library
>  [copy] Copying 1 file to
> /home/rubys/jakarta/jakarta-struts/target/library
>
> compile.library:
> [javac] Compiling 193 source files to
> /home/rubys/jakarta/jakarta-struts/target/library/classes
> [javac]
> /home/rubys/jakarta/jakarta-struts/src/share/org/apache/struts/util/StrutsVa
> lidator.java:68: cannot resolve symbol
> [javac] symbol  : class RESyntaxException
> [javac] location: package regexp
> [javac] import org.apache.regexp.RESyntaxException;
> [javac]  ^
> [javac]
> /home/rubys/jakarta/jakarta-struts/src/share/org/apache/struts/util/StrutsVa
> lidator.java:145: cannot resolve symbol
> [javac] symbol  : clas

RE: Declarative Exception Handling - Any Documentation?

[Craig R. McClanahan]

See intermixed.

On Wed, 20 Mar 2002, Matt Raible wrote:

> Date: Wed, 20 Mar 2002 20:21:20 -0700
> From: Matt Raible <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Declarative Exception Handling - Any Documentation?
>
> After investigating the PasswordExpiredException, I'm a little confused.
> This class uses the following code:
>
> 
> public ExpiredPasswordException(String username) {
> super("error.password.expired", username);
> }
> 
>
> But there is no key "error.password.expired" in
> ApplicationResources.properties.

This was an oversight that has just been corrected.  This key is used to
localize the exception message (since in this particular case we are
extending org.apache.struts.util.AppException for precisely that
capability).  Whether or not the exception is logged is up to the
exception handler you map to handle it.

>  In struts-config.xml there is
>
>  type="org.apache.struts.webapp.example.ExpiredPasswordException"
> path="/changePassword.jsp"/>
>
> And I found an "expired.password" key, but this is never used. How are
> each designed to be used - simply for logging?  There are no messages
> that show up in the log for either of these.
>

The default exception handler (org.apache.struts.action.ExceptionHandler
uses this key to create an ActionError that is stored in request or
session scope, as identified by the "scope" attribute.  Override exception
handlers can do whatever they want.

> Here's how I would expect these to be used.
>
> 1.  If no key is specified in struts-config, then the key
> "error.password.expired" would be used.

At the moment, the "key" attribute is marked required in the DTD, so this
won't happen.

> 2.  This message would be attainable with the following JSP code:
>
> <%-- Error Messages --%>
> 
> 
> 
> 
> 
>

This will work if you're using the default exception handler.  If you
override, things, it depends on what your override class does.

> Is this correct?  Also, is it possible to have a separate .properties
> file for Exception messages?
>
> This stuff is great, as well as the rest of Struts - awesome to work
> with this stuff.  You all do an awesome job - makes my life a lot
> easier.
>
> Matt
>

Craig


>
> > -Original Message-
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 20, 2002 5:55 PM
> > To: Struts Developers List; [EMAIL PROTECTED]
> > Subject: Re: Declarative Exception Handling - Any Documentation?
> >
> >
> >
> >
> > On Wed, 20 Mar 2002, Matt Raible wrote:
> >
> > > Date: Wed, 20 Mar 2002 17:18:45 -0700
> > > From: Matt Raible <[EMAIL PROTECTED]>
> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> > >  [EMAIL PROTECTED]
> > > To: [EMAIL PROTECTED]
> > > Subject: Declarative Exception Handling - Any Documentation?
> > >
> > > I *think* declarative exception handling has been added to the 1.1
> > > beta 1 - correct me if I'm wrong.  If so, where can I find good
> > > documentation and examples on how to use it?  This is all I found:
> > >
> > >
> > http://www.mail-archive.com/struts->
> [EMAIL PROTECTED]/msg04150.htm
> > > l
> > >
> >
> > It has.
> >
> > To use it, you have to use the (new) execute() method in your
> > Actions, instead of perform() -- the signature includes
> > "throws Exception" so that you can throw any kind of
> > exception you wish, and then have the controller catch it.
> >
> > To configure usage, use the  elements inside a
> >  section for global definitions, or inside
> > an  element for local overrides, analogous to the way
> > forwards work.
> >
> > A contrived use of this is in the Struts example webapp -- if
> > you enter the username "arithmetic", LogonAction will throw
> > an ArithmeticException. Likewise, if you enter the username
> > "expired" it will throw an ExpiredPasswordException (a
> > business logic exception unique to this webapp).  Only the
> > business logic exception has a defined handler:
> >
> >   
> >  >
> > type="org.apache.struts.webapp.example.ExpiredPasswordException"
> >   path="/changePassword.jsp"/>
> >   
> >
> > > Also, will Tiles be adapted as a Plug In?
> > >
> >
> > Makes sense to me ... but I'm not going to have a chance to do it.
> >
> > > I upgraded my app using 1.1 beta 1 with Tiles & Validator this
> > > afternoon
> > > - took me about 10 minutes.  Mostly validator changes.  Nice work!
> > >
> >
> > Cool!
> >
> > > Matt
> > >
> >
> > Craig
> >
>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Declarative Exception Handling - Any Documentation?

[Craig R. McClanahan]

On Wed, 20 Mar 2002, Matt Raible wrote:

> Date: Wed, 20 Mar 2002 20:27:39 -0700
> From: Matt Raible <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Declarative Exception Handling - Any Documentation?
>
> A little best-practices question...
>
> If I have the following 3 errors that can occur when uploading files in
> my UploadAction:
>
> errors.invalid.transcriptFile=The transcript file \"{0}\" doesn't appear
> to be a text file. Please convert it to a text file.
> errors.reading.file=An error occurred reading the file \"{0}\", please
> try uploading the file again.
> errors.file.exists=File \"{0}\" already exists in the asset repository.
> Select the \"Replace if Exists\" checkbox to overwrite.
>
> What is the best way to use Declarative Exception handling for these -
> should I have three different exceptions, or is it possible to have 1
> FileUploadException class that can render all 3 error messages?
>

I think this really depends on what you want to have happen next.  If
you're going to go back to the input form again in all three cases, it's
probably just as easy to use a single exception handler for all three
scenarios -- if you want to take different actions, you can use different
ones.

Of course, you also have the choice of not throwing an exception at all --
you can do a forward directly from UploadAction to the appropriate place
as well.  Using an exception lets you decouple the detection of a problem
with the decision of what to do next.  If you already know (in
UploadAction) where you want to go next, it's probably just as easy to go
there directly.

> Sorry for all the questions - maybe I can help with documentation once I
> get this all figured out.  Point me in the right direction to do this.
>
> Matt
>

Craig


> > -Original Message-
> > From: Matt Raible [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 20, 2002 8:21 PM
> > To: 'Struts Developers List'
> > Subject: RE: Declarative Exception Handling - Any Documentation?
> >
> >
> > After investigating the PasswordExpiredException, I'm a
> > little confused. This class uses the following code:
> >
> > 
> > public ExpiredPasswordException(String username) {
> > super("error.password.expired", username);
> > }
> > 
> >
> > But there is no key "error.password.expired" in
> > ApplicationResources.properties.  In struts-config.xml there is
> >
> >  > type="org.apache.struts.webapp.example.ExpiredPasswordExceptio
> > n" path="/changePassword.jsp"/>
> >
> > And I found an "expired.password" key, but this is never
> > used. How are each designed to be used - simply for logging?
> > There are no messages that show up in the log for either of these.
> >
> > Here's how I would expect these to be used.
> >
> > 1.  If no key is specified in struts-config, then the key
> > "error.password.expired" would be used. 2.  This message
> > would be attainable with the following JSP code:
> >
> > <%-- Error Messages --%>
> > 
> > 
> > 
> > 
> > 
> >
> > Is this correct?  Also, is it possible to have a separate
> > .properties file for Exception messages?
> >
> > This stuff is great, as well as the rest of Struts - awesome
> > to work with this stuff.  You all do an awesome job - makes
> > my life a lot easier.
> >
> > Matt
> >
> >
> > > -Original Message-
> > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, March 20, 2002 5:55 PM
> > > To: Struts Developers List; [EMAIL PROTECTED]
> > > Subject: Re: Declarative Exception Handling - Any Documentation?
> > >
> > >
> > >
> > >
> > > On Wed, 20 Mar 2002, Matt Raible wrote:
> > >
> > > > Date: Wed, 20 Mar 2002 17:18:45 -0700
> > > > From: Matt Raible <[EMAIL PROTECTED]>
> > > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> > > >  [EMAIL PROTECTED]
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Declarative Exception Handling - Any Documentation?
> > > >
> > > > I *think* declarative exception handling has been added to the 1.1
> > > > beta 1 - correct me if I'm wrong.  If so, where can I find good
> > > > docu

RE: Declarative Exception Handling - Any Documentation?

[Craig R. McClanahan]

On Fri, 22 Mar 2002, Matt Raible wrote:

> Date: Fri, 22 Mar 2002 08:40:43 -0700
> From: Matt Raible <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Declarative Exception Handling - Any Documentation?
>
> 1.  Since a key has to be specified in struts-config.xml - what is the
> point of the super(key, value) in ExpiredPasswordException?
>

The "key" attribute of an  is the message key for the
ActionError message that gets created.  This is the text that will
normally get sent back to the user.  In ExpiredPasswordException, the
key is used to localize the text of the exception's getMessage() string,
which is probably what's going to get logged if the exception handler logs
things.

Note that it's not required to have your application exceptions extend
org.apache.struts.util.AppException -- they can be anything you want.  I
imagine a lot of people will want to let the exception handling mechanisms
deal with java.sql.SQLException problems, for example.

> 2.  I added the code from <%-- Error Messages --%> to
> changePassword.jsp, and the key="expired.password" showed up on the
> page.  However, when I added {0} to the key, no substitution occurred.
>
> Is this a bug?  I can enter into bugzilla if so.
>

It's not clear exactly what you tried to do -- please file this as a bug
(with a completed example) if it's still a problem.

> Thanks,
>
> Matt

Craig


>
> > -Original Message-
> > From: Matt Raible [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 20, 2002 8:21 PM
> > To: 'Struts Developers List'
> > Subject: RE: Declarative Exception Handling - Any Documentation?
> >
> >
> > After investigating the PasswordExpiredException, I'm a
> > little confused. This class uses the following code:
> >
> > 
> > public ExpiredPasswordException(String username) {
> > super("error.password.expired", username);
> > }
> > 
> >
> > But there is no key "error.password.expired" in
> > ApplicationResources.properties.  In struts-config.xml there is
> >
> >  > type="org.apache.struts.webapp.example.ExpiredPasswordExceptio
> > n" path="/changePassword.jsp"/>
> >
> > And I found an "expired.password" key, but this is never
> > used. How are each designed to be used - simply for logging?
> > There are no messages that show up in the log for either of these.
> >
> > Here's how I would expect these to be used.
> >
> > 1.  If no key is specified in struts-config, then the key
> > "error.password.expired" would be used. 2.  This message
> > would be attainable with the following JSP code:
> >
> > <%-- Error Messages --%>
> > 
> > 
> > 
> > 
> > 
> >
> > Is this correct?  Also, is it possible to have a separate
> > .properties file for Exception messages?
> >
> > This stuff is great, as well as the rest of Struts - awesome
> > to work with this stuff.  You all do an awesome job - makes
> > my life a lot easier.
> >
> > Matt
> >
> >
> > > -Original Message-
> > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, March 20, 2002 5:55 PM
> > > To: Struts Developers List; [EMAIL PROTECTED]
> > > Subject: Re: Declarative Exception Handling - Any Documentation?
> > >
> > >
> > >
> > >
> > > On Wed, 20 Mar 2002, Matt Raible wrote:
> > >
> > > > Date: Wed, 20 Mar 2002 17:18:45 -0700
> > > > From: Matt Raible <[EMAIL PROTECTED]>
> > > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> > > >  [EMAIL PROTECTED]
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Declarative Exception Handling - Any Documentation?
> > > >
> > > > I *think* declarative exception handling has been added to the 1.1
> > > > beta 1 - correct me if I'm wrong.  If so, where can I find good
> > > > documentation and examples on how to use it?  This is all I found:
> > > >
> > > >
> > > http://www.mail-archive.com/struts->
> > > [EMAIL PROTECTED]/msg04150.htm
> > > > l
> > > >
> > >
> > > It has.
> > >
> > > To use it, you have to use the (new) execute() method in your
> > > Actions, instead of perfor

Re: PlugIn (Craig)

[Craig R. McClanahan]

On Sat, 30 Mar 2002, David Winterfeldt wrote:

> Date: Sat, 30 Mar 2002 11:44:43 -0800 (PST)
> From: David Winterfeldt <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: PlugIn (Craig)
>
> It looks like when you made changes to the PlugIn
> Craig that it broke the ValidatorPlugIn.  Having
> multiple set-property elements under the plug-in used
> to work, but now it looks like only the last one is
> being kept.  It looks like the addition of
> PlugInSetPropertyRule in ConfigRuleSet broke this.
> You probably know the digester better than I do if
> this could be changed.  Or point me in the right
> direction if you don't have time to do this.
>
>  className="org.apache.struts.validator.ValidatorPlugIn">
> value="/WEB-INF/validator-rules.xml"/>
> value="/WEB-INF/validation.xml"/>
> 
>

The change to the PlugIn configuration did indeed change this, but I'm not
so sure it's a "bad thing" that needs to be fixed.

The basic issue is that PlugInConfig maintains a simple name-value Map for
the configured properties, which is then returned via getProperties() and
then used as an argument to BeanUtils.populate() to configure the
instantiated PlugIn object.  So, supporting your syntax above would
require either an API modification, or a change to the contract about what
PlugInConfig.getProperties() returns.

My discomfort with going ahead and doing this is based on the fact that it
is somewhat counterintuitive to expect a JavaBean property setter for a
scalar String property to accept and use multiple values when called
mulitple times -- the user of such a bean is going to expect replacement
semantics in this scenario.  It would also not be possible to implement
configuration of this if we extended the DTD to include a specific PlugIn
(and could therefore use attributes instead of nested 
elements), because XML doesn't allow multiple attributes with the same
name.

Wouldn't it be better to use a comma-delimited list (or something like
that) so you can set this with one setPathname() method?

> David
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jakarta Regexp Package Issue

[Craig R. McClanahan]

On Mon, 1 Apr 2002, David Winterfeldt wrote:

> Date: Mon, 1 Apr 2002 08:23:42 -0800 (PST)
> From: David Winterfeldt <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Jakarta Regexp Package Issue
>
> I'm planning on switching this over tonight.  I'm
> ready to check in the changes to Commons Validator.
> The unit test I made shows that changing this fixes
> one of the e-mail bugs.  I'll also switch Struts to
> use ORO too.

+1

>
> David
>

Craig


> --- Martin Cooper <[EMAIL PROTECTED]>
> wrote:
> > I have no problem with switching to ORO. Then again,
> > I must confess to
> > having no great knowledge of either package
> > (although I do use Regexp on one
> > of my projects). It's interesting that Regexp should
> > be considered lighter -
> > it's a significantly larger download than ORO!
> >
> > I don't think we should allow the user to choose. It
> > would be confusing to
> > the user, and also to us when trying to track down
> > problems and subtle
> > differences in behaviour.
> >
> > --
> > Martin Cooper
> >
> >
> > - Original Message -
> > From: "David Winterfeldt" <[EMAIL PROTECTED]>
> > To: "Struts Developers List"
> > <[EMAIL PROTECTED]>
> > Sent: Friday, March 22, 2002 7:56 AM
> > Subject: Jakarta Regexp Package Issue
> >
> >
> > > I'm reposting this.  It might be easily missed
> > since I
> > > forwarded the bug for this that I filed.
> > >
> > > Email Validation doesn't allow '-' in address.
> > This
> > > is an error in the Jakarta Regexp package.  It
> > also
> > > has trouble with large max values.
> > >ex: ^\d{2,1000}$
> > >
> > > Does anyone think we should just switch to ORO?
> > I'm
> > > leaning that way, but I used Jakarta Regexp
> > because it
> > > was considered 'lighter'.  If it isn't completely
> > > reliable, that doesn't really matter.  Or we could
> > > include both as an option, but I don't want to
> > confuse
> > > anyone.
> > >
> > > David
> > >
> > >
> > >
> > > __
> > > Do You Yahoo!?
> > > Yahoo! Movies - coverage of the 74th Academy
> > Awards®
> > > http://movies.yahoo.com/
> > >
> > > --
> > > To unsubscribe, e-mail:
> > 
> > > For additional commands, e-mail:
> > 
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > 
> > For additional commands, e-mail:
> > 
> >
>
>
> __
> Do You Yahoo!?
> Yahoo! Greetings - send holiday greetings for Easter, Passover
> http://greetings.yahoo.com/
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Multi Struts Config files and path context wish

[Craig R. McClanahan]

On Sat, 30 Mar 2002, Struts-dev Newsgroup wrote:

> Date: Sat, 30 Mar 2002 21:10:01 -0800
> From: Struts-dev Newsgroup <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Multi Struts Config files and  path context wish
>
> Subject: Multi Struts Config files and path context wish
> From: Vic Cekvenich <[EMAIL PROTECTED]>
>  ===
> Tiles can do multi confi like this, via CSV:
> 
> definitions-config
> 
>/WEB-INF/tiles-defs.xml,/WEB-INF/tiles-tests-defs.xml,/WEB-INF/tiles-tutorial-defs.xml,
>   /WEB-INF/tiles-examples-defs.xml
> 
> Validator does it like this, multi item:
> 
> 
> 
> 
>

This is actually getting changed as we speak -- it depends on *very*
non-inuitive behavior of the setPathname() method.  In a standard
JavaBean, calling setPathname() will always replace the previous value --
this technique would only work if it added each value to a list.  If
that's the behavior you want, the method should be addPathname() or
something instead.

> But to have multi config on Struts-config.xml we will require a path?
> The reason I do not want a path is that on a project, it is sometimes
> hard to spearate who is working on what module like that.
> Also, path in url might not be sectioned like that.
> I like how validator and tiles do it a bit better.
>

For multi-app support, I'm going to start with the assumption that we want
to use a path prefix to distinguish the sub-applications (that's the way
many other frameworks do it, it's consistent with how servlet containers
deal with webapps, ...).  Given that, we have to communicate two pieces of
information to the controller servlet for each subapp:
- The path prefix for that subapp
- The struts-config.xml file to be used.

The current technique embeds the path prefix in the name of the servlet
initialization parameter, and therefore means it is *not* stored inside
the struts-config.xml file for that subapp.  In this way, you can design a
subapp without knowing or caring ahead of time what the path prefix will
be (again, this is consistent with webapp design, where you don't have to
know what the context path will be).

Going to a comma-delimited list of struts-config files gives up this
ability to keep the config files independent of the path - therefore I
don't particularly care for that approach here.

> my 2 c.
> Vic
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Problems with 1.1b1

[Craig R. McClanahan]

On Mon, 1 Apr 2002, Ronel Sumibcay wrote:

> Date: Mon, 1 Apr 2002 11:37:04 -0800
> From: Ronel Sumibcay <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Problems with 1.1b1
>
> I take back where the fix should take place. Its really a J2EE issue so the
> fix should really take place in the servlet container before it calls the
> init() method of a preloaded servlet.
>
> Folks with commit priveledges...what do you guys think? Will it hurt to have
> this change in the ActionServet's init() method? Should struts attempt to
> cater to partially compliant J2EE servlet containers? Or should I take this
> problem to the tomcat and jrun lists?
>
> The answer to these questions will help me decide if i should make a
> struts-myfix.jar or wait for a stable strtus 1.1 with the fix, or wait for
> jrun with a bug fix.
>
> Thanks.
>

There are a couple of dimensions to this issue:

* J2EE 1.3 (and therefore Servlet 2.3) require that the thread context
  class loader be initialized appropriately for all web applications.
  For example, Tomcat 4 does this.

* Such support was *not* required in J2EE 1.3 (and therefore Servlet 2.2)
  environments, but it is widely supported.

* Tomcat 3.x purports to support this feature, but IIRC you have to
  explicitly configure it in server.xml by including a particular
  interceptor or something.  Have you got this set up correctly?

* If you have indeed configured this as required, I would suggest it is
  probably a Tomcat 3.3 bug -- it should set up the same context class
  loader for actually loading the servlet class (which fires off the
  getLog() initializers) as it does when calling the service() method.

* The issue is not Struts-specific ... it would affect *any* web app
  that uses the recommended logger discovery mechanism, fired when the
  servlet is initially loaded.

Given that, has anyone reported this as a Tomcat 3.3 bug?

> -ronel
>

Craig


>
>
> -Original Message-
> From: Ronel Sumibcay [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 29, 2002 3:59 PM
> To: 'Struts Developers List'
> Subject: RE: Problems with 1.1b1
>
>
>
> The problem may be that the servlet engine may not be calling
>
> Thread.setContextClassLoader(ClassLoader) when initializing a servlet from
> preload.
>
> This seems to be the case for JRun3.1. It may be the same for Tomcat 3.3a.
> I've made the fix to my ActionServlet, but I think it really needs to be
> done in LogFactory.findClassLoader(). The fix for ActionServlet involves
> moving the LogFactory.getLog() into the init() method of ActionServlet
>
> public void init()
> {
>
> Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader(
> ));
>   log = LogFactory.getLog(this.getClass());
>
> initInternal();
> initOther();
> initServlet();
>
>   ...
> }
>
> The LogFactory.findClassLoader() checks for null to the call to
> Thread.currentThread().getContextClassLoader(), but according to the docs it
> either the primordial classloader or the classloader set when the thread was
> created. It seems like it was never set, so the primordial classloader is
> being returned, thus the ClassNotFoundExceptions.
>
> Hope this helps
>
> -ronel
>
>
> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 22, 2002 10:15 PM
> To: Struts Developers List
> Subject: Re: Problems with 1.1b1
>
>
> Unfortunately, you're not the only one seeing these problems. I really
> thought I'd tested the struts-example app with four different containers
> (Tomcat 3.3a, Tomcat 4.0.3, Resin 1.2.10, Resin 2.0.5) before I released the
> beta, but it seems I must not have tested under Tomcat 3.3a. ;-( The other
> three work just fine.
>
> Here's what I know so far:
>
> 1) The problem is related to class loaders, and possibly to the
> LogFactory.findClassLoader() method. The fact that LogFactory.getLog() is
> called at (ActionServlet) class initialisation time may also be significant.
>
> 2) It is related to the  element. If the web app is not
> loaded on startup, this error does not occur. (Others do, of course, but we
> get past this problem.)
>
> 3) The problem can be worked around by copying commons-logging.jar to:
>
> %TOMCAT_HOME%\lib\common
>
> Unfortunately, I'm by no means a class loader expert, so I'm not sure where
> to go from here. Hopefully someone who has more class loader knowledge than
> I do can chip in now...
>
> --
> Martin Cooper
>
>
> - Original Message -
> From: "Cedric Dumoulin" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Friday, March 22, 2002 9:50 AM
> Subject: Re: Problems with 1.1b1
>
>
> >
> >   After playing with different configurations, here are my conclusions :
> >
> >* 1.1b1 struts-example work fine with tomcat4.0.3 and jdk1.4
> >* 1.1b1 struts-example doesn't work with tomcat3.3a and jdk1.4 (can't
> find

RE: Problems with 1.1b1

[Craig R. McClanahan]

On Mon, 1 Apr 2002, Craig R. McClanahan wrote:

>
> * Such support was *not* required in J2EE 1.3 (and therefore Servlet 2.2)
>   environments, but it is widely supported.
>

Err, that should have said J2EE 1.2 rather than 1.3.

Craig



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Session Scope Question

[Craig R. McClanahan]

On Tue, 2 Apr 2002, Bob Lee wrote:

> Date: Tue, 2 Apr 2002 10:24:50 -0600
> From: Bob Lee <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Session Scope Question
>
> The user guide says that if you use "session" scope, Struts will use the
> "name" attribute from the "form-bean" element to key the instance. Does
> Struts add something else to the key to prevent concurrent modification? For
> example, if the user has two windows open and starts two different instances
> of the same form, will the two instances modify the same ActionForm instance
> in the session?
>

No -- you've got the same multithread issues here that you do with
session-scoped attributes in general.  If your app is going to have cases
where the same form bean is used on more than one frame (or window) at the
same time, in the same session, I'd definitely architect things to use
request scope instead.

> Thanks,
> Bob
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Session Scope Question

[Craig R. McClanahan]

On Tue, 2 Apr 2002, Bob Lee wrote:

> Date: Tue, 2 Apr 2002 11:18:42 -0600
> From: Bob Lee <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Session Scope Question
>
> That's what I was afraid of. Is it possible to manually control which action
> form instance gets used? For example, rather than pass all of the data from
> page to page, pass an instance id that gets created when the user first
> enters the form.
>

There is no machinery to do this for session-based form beans, and it
would be very complex to implement (how do you tell each individual
request accessing the same session which id to use?).  That's why I
continue to encourage using request-based form beans instead, because each
request gets it's own instance -- the fact that the name is the same does
not matter.

> Thanks,
> Bob

Craig


>
> - Original Message -
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Tuesday, April 02, 2002 11:04 AM
> Subject: Re: Session Scope Question
>
>
> >
> >
> > On Tue, 2 Apr 2002, Bob Lee wrote:
> >
> > > Date: Tue, 2 Apr 2002 10:24:50 -0600
> > > From: Bob Lee <[EMAIL PROTECTED]>
> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > > To: Struts Developers List <[EMAIL PROTECTED]>
> > > Subject: Session Scope Question
> > >
> > > The user guide says that if you use "session" scope, Struts will use the
> > > "name" attribute from the "form-bean" element to key the instance. Does
> > > Struts add something else to the key to prevent concurrent modification?
> For
> > > example, if the user has two windows open and starts two different
> instances
> > > of the same form, will the two instances modify the same ActionForm
> instance
> > > in the session?
> > >
> >
> > No -- you've got the same multithread issues here that you do with
> > session-scoped attributes in general.  If your app is going to have cases
> > where the same form bean is used on more than one frame (or window) at the
> > same time, in the same session, I'd definitely architect things to use
> > request scope instead.
> >
> > > Thanks,
> > > Bob
> > >
> >
> > Craig
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Nightly build

[Craig R. McClanahan]

That's because of the switch to jakarta-oro (instead of jakarta-regexp) in
the validator.  Fixed in tonight's build.

Craig


On Tue, 2 Apr 2002, Struts-dev Newsgroup wrote:

> Date: Tue, 2 Apr 2002 10:55:01 -0800
> From: Struts-dev Newsgroup <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Nightly build
>
> Subject: Nightly build
> From: Vic Cekvenich <[EMAIL PROTECTED]>
>  ===
> Today is 466 bytes... fyi.
> Vic
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Servlet 2.3 filter

[Craig R. McClanahan]

On Tue, 2 Apr 2002, Struts-dev Newsgroup wrote:

> Date: Tue, 2 Apr 2002 11:25:01 -0800
> From: Struts-dev Newsgroup <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Servlet 2.3 filter
>
> Subject: Servlet 2.3 filter
> From: Vic Cekvenich <[EMAIL PROTECTED]>
>  ===
> Most containers now are Servlet 2.3 compliant, and there are questions
> on user lists on filters with Action.
> So a non comitter request to make action a filter and Struts Servlet 2.3
> bound. (a question asked at JavaOne at Struts SIG)
>

Those of you at the Struts BOF will recall that we did a poll of those
present (several hundred folks).  Over half those who answered were
running systems based on Servlet 2.2 (and/or J2EE 1.2), and those people
would not be able to use Struts if it required Servlet 2.3.

My takeaway from this was that, for the next few months at least, it's a
little premature to talk about requiring Servlet 2.3 in a production
release of Struts.  However, it might well be time to start talking about
a "Struts 2.0" that is based on this, plus letting us take advantage of
other 2.3-based things like the JSP Standard Tag Library and JavaServer
Faces when they are released.

> Vic
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: anyone care to clarify difference between struts and JSTL?

[Craig R. McClanahan]

On Tue, 2 Apr 2002, Stephenson Tim wrote:

> Date: Tue, 2 Apr 2002 17:52:46 +1000
> From: Stephenson Tim <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: "Struts mailing list (E-mail)" <[EMAIL PROTECTED]>
> Subject: anyone care to clarify difference between struts and JSTL?
>
> hi all,
>
> i have taken a stroll through the mail archive and not found any clear
> definition of what is the difference between the struts taglibs and the
> 'standard' taglibs.
>
> let me admit first that i am completely new to JSTL, what i really want to
> know is should i keep going with struts tags (which i find very powerful) or
> is everyone about to switch directions?
>
> it seems to me that some tags are overlaps such as the logic tags with what
> appears to be called 'core' condition tags.
>
> and some others have been deliberately (and i believe wisely) excluded on
> grounds on breaking MVC (eg JSTL sql tags)
>
> i would be interested in your views especially in whether you guys see a
> future amalgamation of some or any of the struts tags into JSTL.
>

JSTL, as it's name implies, is (or will be when it goes final in June) the
"standard tag library" that will be portable across *all* servlet/JSP
containers once it is implemented.  This has a couple of advantages:

* Page developers will only need to learn one set of tags for the basic
  stuff like iterations and conditionals, which will work across all
  containers and across all application frameworks.

* Tool developers can afford to spend the time to make their tools aware
  of the standard tags -- it's not economically feasible to provide really
  high quality support for twenty million different taglibs.

* Container developers can design their page compilers to create optimized
  code for the standard version of the tags (such as turning 
  into a real Java "for" statement), for better performance.

As you noted, there is a lot of functional overlap with the Struts tags in
the "bean" and "logic" taglibs.  That's because, since Struts was around
first, it set a pretty high baseline for what people expected a standard
tag library to include.  In fact, the expert group that built JSTL took a
lot of the good ideas directly from the Struts tag libraries, as well as
from several others, and coalesced them (while improving on them at the
same time).

My advice to Struts users is as follows:

* If you're running on a Servlet 2.2 / JSP 1.1 container, you
  will not be able to use JSTL (it requires Servlet 2.3 / JSP 1.2).
  Go ahead and continue using the Struts tag libraries.

* If you're running on a Servlet 2.3 / JSP 1.2 container, you
  should begin experimenting with JSTL.  There is no problem in
  using both JSTL and Struts tags in the same page (although,
  obviously, the expression syntax is different).

* Over time, I plan to add a few features to the Struts tags to
  ease migration to JSTL for the "bean" and "logic" libraries --
  for example, I want to support the same expression language, and
  attribute names where that is possible.

* Longer term, I suggest that page developers plan on using the JSTL
  tags in their applications, as quickly as it is feasible for you
  to do so.  But we're not going to throw away the existing Struts
  tags any time soon, so they will continue to be available.

(One other note -- the expression language itself will become part of JSP
1.3, so you'll be able to use it in template text as well as in custom tag
attribute values.)

The same basic story will be my recommendation with regards to JavaServer
Faces, although that will take longer because Faces is not as far as long.
Ultimately, we want to take maximum possible leverage on the features of
JSTL and JavaServer Faces because there will be lots more tools support
for the standard libraries than the Struts libraries could ever gather by
themselves.

Of course, none of this affects your form beans, actions, and the business
logic that they call.  Aren't you glad that you followed the recommended
design patterns and split the presentation logic from the business logic?

:-)

> rgds,tim
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: anyone care to clarify difference between struts and JSTL?

[Craig R. McClanahan]

On Tue, 2 Apr 2002, Stephenson Tim wrote:

> and some others have been deliberately (and i believe wisely) excluded on
> grounds on breaking MVC (eg JSTL sql tags)
>

On this particular point, here's what I told the Struts BOF audience at
JavaOne:

"Shame on you if you use the SQL tags in your
presentation tier directly"

These tags exist because there are valid use cases (prototyping, quick
and dirty "guest book sized" apps, conversions of VB or Cold Fusion apps,
and so on).  But we Struts users know that none of those use cases match
up with creating scalable, maintainable, MVC-based designs.

All the rest of the JSTL tags are good stuff.

Craig



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Security Solution

[Craig R. McClanahan]

See intermixed comments below.

On Tue, 2 Apr 2002, Phase Web and Multimedia wrote:

> Date: Tue, 2 Apr 2002 13:23:35 -0700
> From: Phase Web and Multimedia <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Dev <[EMAIL PROTECTED]>,
>  Struts User <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: RE: Security Solution
>
> Greetings Michael,
>
> I don't believe it has to be struts specific. But, I have never used it
> anywhere but struts. There many other features I would like to add to it.
> Specifically an ldap realm for authorization and perhaps add some hooks that
> will provide EJB conectivity. Do to my EJB ignorance I don't even know if it
> is possible.
>

Such an approach to application-managed security (but with a pluggable
implementation of the user database) would probably be pretty popular.  In
fact, what you are describing is pretty similar to how Tomcat itself
implements container managed security (you might want to snoop the Tomcat
4 sources for ideas).  However, there are some restrictions -- most of
which you've already identified -- in the scope of this effort.

> One thing to note. Because a webapp has limited access to the server scope
> this security solution is context specific for now. This is why I want to
> add some of the afformentioned hooks. I also imagine it would be possible to
> store the security xml file so that it can be cross context and provide a
> single security config for multiple contexts under a host.
>

It seems unlikely to me that a server-wide (or virtual-host-wide)
implementation of application managed security can be created that is
portable across servlet containers.  You pretty much have to hook in to
container-specific facilities to pull it off.  That being said, solving
the problem for a particular webapp is still a very useful scenario.

> Another thing to note is that many of the apis that are out there (ie tiles,
> jsp, servlet) take advantage of the container managed security by checking
> roles. These are all container specific. I've chosen to abandon all of those
> niceties to gain greater flexibility in other areas. I have sacrificed the
> standard convention that these mechanisms provide. I feel it is a good
> decision for my niche.
>
> I will be providing mechanisms equal to the isUserInRole(), getRemoteUser(),
> and getUserPrincipal(). But these objects will be context-session specific.
>

Faking the values returned by these methods is pretty easy in a Servlet
2.3 environment, where you can create a request wrapper.  That would be
sufficient for dealing with what Struts-ish things like tiles needs.

> My solution should be able to work as an app level link to a larger security
> system that bypasses tomcat security all-together.
>
> I have heard some speak about ejb as thought they need the container-managed
> security. This might be so. I don't know. I am hoping that someone might be
> able to provide that functionality.
>

The EJB layer *absolutely* requires container managed security.  In the
absence of using container managed security at the web layer, you'd need
to figure out some other mechanism for converting your own notion of user
identity into a user and role set that is recognized by the EJB tier.  A
couple of options include:

* The web container runs completely separate from the EJB container, and
  appears to be a standard J2EE application client.  (This probably means
  you lose pretty badly on performance, however).

* In Servlet 2.3 there is the notion of the "run-as" identity assigned to
  all web tier code that has not been authenticated via container-managed
  security.  If your application design will let you share a single
  EJB-user identity, you can probably get away with this approach.

> If you would like to look at my code I am more than happy to pass it on.
> But, it is narrow in scope to my application. This has become apparent to me
> as I read some email regarding what I have developed. I believe the code and
> concept to be a good starting point to provide a better security framework.
>
> The strongest part of the code it the SecurityFilter and MulitpleLogin
> configuration options.
>
> Let me know,
> Brandon Goodin
> Phase Web and Multimedia
> P (406) 862-2245
> F (406) 862-0354
> [EMAIL PROTECTED]
> http://www.phase.ws
>

Craig McClanahan



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Servlet 2.3 filter

[Craig R. McClanahan]

On Tue, 2 Apr 2002 [EMAIL PROTECTED] wrote:

> Date: Tue, 2 Apr 2002 14:33:14 -0600
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: RE: Servlet 2.3 filter
>
> Please forgive my ignorance if this is a well-known thing.  I went to
> the Struts BOF and I went to the "Filters can replace Servlets in MVC"
> BOF.  I see the concept, but I just don't see how filters are "better"
> than servlets for MVC.  Is there documentation or discussion about this
> idea somewhere?  I first heard of it at JavaOne.  Is it "pre-supposed"
> that Struts will someday become filter-based or did I misunderstand
> that?  I see how filters are a good frontend to MVC to make sure
> requests don't circumvent your controller, but it doesn't make sense to
> me that a filter would "be" the controller.  What are the community's
> thoughts on that?

This is a really interesting question.

I finally had a chance to review the slides from Kevin Jones's session on
Filters (slides for all the sessions are now available in PDF from
http://java.sun.com/javaone -- this was session 1208).

I won't claim that I agree with everything Kevin proposes about using
Filters as a controller in an MVC environment.  In particular, I would not
consider the "hard to track which servlet is associated with which JSP
page(s)" issue to be a problem in MVC.  Rather, I consider that
separation to be (one of) the whole points of MVC -- making the business
logic and presentation logic as independent of each other as possible.

That being said, I can see the following general advantages for using a
Filter as the controller component of Struts:

* UNIVERSALITY - You can actually guarantee that *all* requests really
  flow through the controller.  Consider the following scenarios in
  Struts 1.0 and 1.1:

  - In the Struts example app, we want to ensure that the user is always
logged on, and redirect to the login page if not (a very common
requirement in apps that manage their own security).  But, in order
to accomplish this guarantee, we've got ugly  tags
on all of the pages, because we can't guarantee that the user will
not link directly to a page.

  - In the multiple application support of Struts 1.1, there is a current
restriction that all links *must* flow through the controller in order
for the sub-application selection logic to work correctly.  We could
get around this by requiring a custom tag on every page again, but
that is clearly not optimal.

  Both of these situations can be elegantly handled by mapping a
  controller Filter to the "/*" URL pattern, so that it watches every
  single request.

* COMPOSABILITY - The current Struts controller logic is very monolithic,
  and it is hard to customize exactly what the controller does for you.
  If, instead, we viewed the controller as a series of services that can
  be included or not (based on application requirements), the application
  architect has the option to pay for only the services they need.
  Examples of current Struts services that might well be decomposed:
  multipart request handling, path->Action mapping, locale selection,
  role permissions checking, form population and validation, ... plus
  the fact that it would be easy to add other (perhaps application
  specific) services that integrate nicely with those provided by Struts.

* FLEXIBILITY - Another aspect of the monolithic nature of the current
  controller is that all of it's processing is applied to every request.
  While that is sort of the idea of MVC :-), there are many cases where
  you might want different sets of services invoked in different parts of
  the same app (or in different sub-applications).  We went part-way in
  this direction in 1.1, by letting you customize the RequestProcessor
  instance used for each sub-app.  It's much more powerful to allow the
  application architect to compose the set of services to be applied
  in a declarative fashion, in web.xml, without having to write any code
  to manage the overall orchestration.

* INTEGRATION - Sometimes you want to be able to integrate existing web
  application functionality, already provided by servlets and/or JSP
  pages, into a Struts based web app.  Today, you have to write "glue"
  actions that do forwards to such resources -- with a Filter based
  controller that front ends things, you can do this more elegantly
  (even if you can't modify the apps being integrated).

* WRAPPING - A completely different sort of advantage in using a Filter
  is the ability (using the Filter APIs) to wrap the request and/or
  response before handing it on to the next filter (or the servlet that
  ultimately gets invoked).  This capability lets you do all sorts of
  interesting things -- just a couple of ideas to whet your appetite:

  - If you want to do application managed security, but like the idea
of role checking and user identification that Struts can use in its
dec