Re: SuccessAction (was RE: Addition of two new actions)

[Ted Husted]

Maverick directly supports the idea that a command may have only one 
destrintation, and then streamlines its behavior. So we have some 
precedent under the "great minds" theory =:0)

ActionMapping.findForwards only brings back local forwards.  So the 
"DefaultAction" could just forward to the first and only local forward, 
and perhaps throw an exception if there were not exactly one.

Something like

  String[] forwards = mapping.findForwards();

  if (1!=forwards.length) {
	throw new RuntimeException("DefaultAction: Exactly one forward must be 
specified");
  }

 return mapping.findForward(forwards[0]);

-Ted.

Joe Germuska wrote:

At 16:51 -0700 8/8/03, David Graham wrote:

I'd like to get your thoughts (and others) on my proposal at the 
beginning
of this message.  In short, we wouldn't use the parameter attribute nor
would we define "success" as the only correct forward name.  
SuccessAction
would forward to the first  that's defined for it.


This sounds like a great compromise, seeing as it would be totally 
compatible with naming the forwards "success", as well as anything else. 
( I tend to use "page" in the analogous case).

Joe

--
Ted Husted,
  Junit in Action  - ,
  Struts in Action - ,
  JSP Site Design  - .


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

DO NOT REPLY [Bug 20761] - Define collection types as DynaForm properties

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20761

Define collection types as DynaForm properties

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Should have the ability to  |Define collection types as
   |define collection types |DynaForm properties

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

cvs commit: jakarta-struts/contrib/tag-doc build.xml

[craigmcc]

craigmcc2003/08/09 12:29:30

  Modified:.build.xml
   contrib/struts-el build.xml
   contrib/struts-el/src/share/org/apache/strutsel/taglib/html
ELFormTag.java ELHtmlTag.java
ELJavascriptValidatorTag.java
   contrib/struts-faces build.xml
   contrib/struts-legacy build.xml
   contrib/tag-doc build.xml
  Log:
  Correct loading order of properties files to go from most local (current
  directory) to most global (${user.home}/build.properties).  Since Ant
  follows a "first definition wins" strategy, this makes the most sense
  for our convention of allowing local overrides of global values.  It also
  means that I can now do an "ant dist" in the top level directory with only
  one thing in my build.properties file (jdk.version=1.4), so this should fix
  the nightly builds as well (verifying that is my next step).
  
  Also fixed some compile errors in struts-el -- I don't know how that code
  could have compiled for anyone.  Could someone more familiar with that
  library make sure I did the changes correctly?
  
  Revision  ChangesPath
  1.118 +5 -2  jakarta-struts/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-struts/build.xml,v
  retrieving revision 1.117
  retrieving revision 1.118
  diff -u -r1.117 -r1.118
  --- build.xml 8 Aug 2003 06:00:55 -   1.117
  +++ build.xml 9 Aug 2003 19:29:30 -   1.118
  @@ -113,9 +113,9 @@
   -->
   
   
  -
  -
   
  +
  +
   
   
   
  @@ -204,6 +204,9 @@
   
   
   
  +
  +
  +
   
   
   
  
  
  
  1.17  +4 -4  jakarta-struts/contrib/struts-el/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-struts/contrib/struts-el/build.xml,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- build.xml 13 Jun 2003 03:22:14 -  1.16
  +++ build.xml 9 Aug 2003 19:29:30 -   1.17
  @@ -51,10 +51,10 @@
-->
   

  - 
  - 
  - 

  + 
  + 
  + 
   


  @@ -219,7 +219,7 @@
   -->
 
  
  -   
  +   
 

   
  
  
  
  1.9   +7 -7  
jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELFormTag.java
  
  Index: ELFormTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELFormTag.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- ELFormTag.java26 Jul 2003 05:48:02 -  1.8
  +++ ELFormTag.java9 Aug 2003 19:29:30 -   1.9
  @@ -386,9 +386,9 @@
   this, pageContext)) != null)
   setScope(string);
   
  -if ((bool = EvalHelper.evalBoolean("scriptLanguage", 
getScriptLanguageExpr(),
  -   this, pageContext)) != null)
  -setScriptLanguage(bool.booleanValue());
  +if ((string = EvalHelper.evalString("scriptLanguage", 
getScriptLanguageExpr(),
  +this, pageContext)) != null)
  +setScriptLanguageExpr(string);
   
   if ((string = EvalHelper.evalString("style", getStyleExpr(),
   this, pageContext)) != null)
  
  
  
  1.8   +7 -7  
jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELHtmlTag.java
  
  Index: ELHtmlTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELHtmlTag.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- ELHtmlTag.java26 Jul 2003 05:48:03 -  1.7
  +++ ELHtmlTag.java9 Aug 2003 19:29:30 -   1.8
  @@ -158,9 +158,9 @@
   Boolean bool= null;
   String  string  = null;
   
  -if ((bool = EvalHelper.evalBoolean("lang", getLangExpr(),
  -   this, pageContext)) != null)
  -setLang(bool.booleanValue());
  +if ((string = EvalHelper.evalString("lang", getLangExpr(),
  +this, pageContext)) != null)
  +setLangExpr(string);
   
   if ((bool = EvalHelper.evalBoolean("locale", getLocaleExpr(),
  this, pageContext)) != null)
  
  
  
  1.9   +7 -7  
jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELJavascriptValidatorTag.java
  
  Index: ELJavascriptValidatorTag.java
  ===
  RCS file: 
/home/cvs/jakarta-str

RE: Addition of two new actions

[Steve Raeburn]

Please correct me if I'm wrong, but that still doesn't enable you to specify
one  to be context relative and another module relative
within the same module as you can by using 'contextRelative' attribute on a
.

Steve


> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper
> Sent: August 4, 2003 3:23 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Addition of two new actions
>
>
>
> "Steve Raeburn" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > You're right  is module relative (despite
> what it says
> in
> > the Javadoc). However, I don't see how it can used with a
> context relative
> > path.
>
> You might want to take a look at the 'forwardPattern' attribute, and the
> RequestUtils.forwardURL() method (especially the JavaDoc for the latter).
>
> --
> Martin Cooper
>
>
> >
> > There is no contextRelative attribute on the action config so you don't
> get
> > to choose (or change) how your forward works.
> >
> > Of the three ways of defining forwards that you identified only one,
> > , works flexibly with modules and that's the one that we don't
> ship
> > an action for with Struts.
> >
> > SuccessAction works flexibly with modules, it's tool friendly,
> it's simple
> > to understand and its configuration is consistent with almost all other
> > actions.
> >
> > Steve



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

DO NOT REPLY [Bug 17259] - o.a.s.validator.DynaValidatorForm logging

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17259

o.a.s.validator.DynaValidatorForm logging

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|LATER   |



--- Additional Comments From [EMAIL PROTECTED]  2003-08-09 00:15 ---
This was completed.  Reopening to close...

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

DO NOT REPLY [Bug 22283] New: - document how to use html:html xhtml=true

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22283

document how to use html:html xhtml=true

   Summary: document how to use html:html xhtml=true
   Product: Struts
   Version: 1.0 Final
  Platform: Other
   URL: http://jakarta.apache.org/struts/struts-html.html#html
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Before struts, I had my HTML files started like 


http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="en">
...

Suggestion:
=== 
Add to the documentation as per the above URL a description on
1) how to get the "xmlns" and "xml:lang" attribute into the html:html struts tag
2) Document whether the http://jigsaw.w3.org/css-validator/validator?uri=https://mydomain/index_en.jsp

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

cvs commit: jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html ELRewriteTag.java ELRewriteTagBeanInfo.java

[dmkarr]

dmkarr  2003/08/10 14:42:21

  Modified:contrib/struts-el/doc/userGuide struts-html-el.xml
   contrib/struts-el/src/share/org/apache/strutsel/taglib/html
ELRewriteTag.java ELRewriteTagBeanInfo.java
  Log:
  Added action attribute added in base class
  
  Revision  ChangesPath
  1.21  +17 -0 
jakarta-struts/contrib/struts-el/doc/userGuide/struts-html-el.xml
  
  Index: struts-html-el.xml
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/struts-el/doc/userGuide/struts-html-el.xml,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- struts-html-el.xml10 Aug 2003 09:14:04 -  1.20
  +++ struts-html-el.xml10 Aug 2003 21:42:21 -  1.21
  @@ -5557,6 +5557,23 @@
   
   
   
  + action
  + false
  + false
  + 
  + Logical name of a Action that
  + contains the actual content-relative URI of the destination
  + of this transfer.  This hyperlink may be dynamically
  + modified by the inclusion of query parameters, as described
  + in the tag description. You must specify
  + exactly one of the action attribute, the
  + forward attribute, the
  + href attribute, or the page
  + attribute.
  + 
  +
  +
  +
 anchor
 false
 false
  
  
  
  1.7   +24 -4 
jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELRewriteTag.java
  
  Index: ELRewriteTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELRewriteTag.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- ELRewriteTag.java 9 Mar 2003 05:47:25 -   1.6
  +++ ELRewriteTag.java 10 Aug 2003 21:42:21 -  1.7
  @@ -79,6 +79,11 @@
   public class ELRewriteTag extends RewriteTag {
   
   /**
  + * Instance variable mapped to "action" tag attribute.
  + * (Mapping set in associated BeanInfo class.)
  + */
  +private String actionExpr;
  +/**
* Instance variable mapped to "anchor" tag attribute.
* (Mapping set in associated BeanInfo class.)
*/
  @@ -140,6 +145,11 @@
   private String transactionExpr;
   
   /**
  + * Getter method for "action" tag attribute.
  + * (Mapping set in associated BeanInfo class.)
  + */
  +public String getActionExpr() { return (actionExpr); }
  +/**
* Getter method for "anchor" tag attribute.
* (Mapping set in associated BeanInfo class.)
*/
  @@ -201,6 +211,11 @@
   public String getTransactionExpr() { return (transactionExpr); }
   
   /**
  + * Setter method for "action" tag attribute.
  + * (Mapping set in associated BeanInfo class.)
  + */
  +public void setActionExpr(String actionExpr) { this.actionExpr = actionExpr; }
  +/**
* Setter method for "anchor" tag attribute.
* (Mapping set in associated BeanInfo class.)
*/
  @@ -267,6 +282,7 @@
   public void release()
   {
   super.release();
  +setActionExpr(null);
   setAnchorExpr(null);
   setForwardExpr(null);
   setHrefExpr(null);
  @@ -300,6 +316,10 @@
   private void evaluateExpressions() throws JspException {
   String  string  = null;
   Boolean bool= null;
  +
  +if ((string = EvalHelper.evalString("action", getActionExpr(),
  +this, pageContext)) != null)
  +setAction(string);
   
   if ((string = EvalHelper.evalString("anchor", getAnchorExpr(),
   this, pageContext)) != null)
  
  
  
  1.4   +7 -3  
jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELRewriteTagBeanInfo.java
  
  Index: ELRewriteTagBeanInfo.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELRewriteTagBeanInfo.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ELRewriteTagBeanInfo.java 9 Mar 2003 05:51:09 -   1.3
  +++ ELRewriteTagBeanInfo.java 10 Aug 2003 21:42:21 -  1.4
  @@ -85,6 +85,10 @@
   ArrayList proplist = new ArrayList();
   
   try {
  +proplist.add(new PropertyDescriptor("action", ELRewriteTag.class,
  +null, "setActionExpr"));
  +} catch (IntrospectionException ex

Re: RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)

[苗启广]

ÔÚ 2003-08-09 03:01:00 ÄúдµÀ£º
>Is this a vote?  If so, shouldn't we have [VOTE] on the subject line?of you ? Could 
>you tell me ? Thanks~~
>
>
>--
>James Mitchell
>Software Engineer / Struts Evangelist
>http://www.struts-atlanta.org
>678.910.8017
>AIM:jmitchtx
>
>
>
>
>> -Original Message-
>> From: Steve Raeburn [mailto:[EMAIL PROTECTED]
>> Sent: Friday, August 08, 2003 5:38 PM
>> To: Struts Developers List
>> Subject: Parameter/Mapping/ConfigDispatchAction (Was RE:
>> Addition of two new actions)
>>
>>
>> I *think* we agreed to add this action. Pick a name.
>>
>> [ ] ParameterDispatchAction
>> [ ] MappingDispatchAction
>> [ ] ConfigDispatchAction
>>
>> Steve
>>
>> > -Original Message-
>> > From: Steve Raeburn [mailto:[EMAIL PROTECTED]
>> > Sent: August 4, 2003 1:25 PM
>> > To: Struts Developers List
>> > Subject: RE: Addition of two new actions
>> >
>> >
>> > In an ideal world, DispatchAction should probably become
>> > ParameterDispatchAction and this could be plain old DispatchAction.
>> >
>> > Is Anthony's original suggestion of ConfigDispatchAction any better?
>> >
>> > I can't think of a name that I *really* like so I'm +0 on Mapping
>> > or Config.
>> >
>> > Steve
>> >
>> > > -Original Message-
>> > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper
>> > > Sent: August 4, 2003 10:15 AM
>> > > To: [EMAIL PROTECTED]
>> > > Subject: Re: Addition of two new actions
>> > >
>> > > I'm +1 on this, other than on naming. I think
>> ParameterDispatchAction is
>> > > definitely the wrong name for the last of these. People
>> are *far* more
>> > > likely to think of the "Parameter" in the name as meaning
>> a request
>> > > parameter than they are to think of the "parameter" action mapping
>> > > attribute. Perhaps MappingDispatchAction instead?
>> > >
>> > > I am -0 on combining all of this into one action.
>> > >
>> > > --
>> > > Martin Cooper
>> > >
>> > >
>> >
>> >
>> >
>> >
>> -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> >
>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
 mqg

- SOUVENIR --- .
| Souvenir of China |
| A Good Place for You  |
`--> http://www.souvenirchina.com -'
mailto:[EMAIL PROTECTED]




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

Re: When is the next release?

[Craig R. McClanahan]

Miscellaneous comments interspersed.

On Sun, 10 Aug 2003, Ted Husted wrote:

> Date: Sun, 10 Aug 2003 12:43:16 -0400
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: When is the next release?
>
> AFAIK, the consensus is that our releases should follow the same general
> process used by the Jakarta Commons and the Apache HTTP Server project.
>
> So, for reference, I'm following
>
> http://httpd.apache.org/dev/release.html
>
> and
>
> http://jakarta.apache.org/commons/releases/
>
> but observing the HTTPD numbering system.
>
> Right now, I intend to post a Release Plan for majority approval, either
> late tonight or early tomorrow. This Plan would include when we plan to
> roll the initial Alpha release. (I may even decided just to roll a
> release and post that along with the Plan.) We'd then vote whether to
> upgrade 1.2.1 from Alpha to Beta or General Availability (GA).
>

The way Tomcat does it, you don't even claim "alpha" status until after a
vote.  They do a limited announcement of "here's the bits, try 'em out" to
just tomcat-dev and tomcat-user (essentially, it is a "test" release),
then hold the vote.  I think there's merit in this approach -- stability,
like beauty, is in the eye of the beholder :-).

Also, we shouldn't be shy about just abandoning a release if it turns out
to have fatal bugs -- just fix them, and get ready for the next.

> Since there are any burning reasons to ship this instantly, I'm taking
> it as a foregone conclusion that this first roll will be at least a
> Beta. I'm confident that there are not any "serious problems that
> prohibits its use", so I don't believe it will not remain an Alpha. But,
> I do suspect that there may be "problems with this release that prohibit
> its widespread adoption" -- even if it simply documenting "what to do
> now that X is deprecated". So, I was calling it a Beta release.
>
> Once we have cleaned up the 1.2.1 roll (which I wager will only be a
> Beta), we can roll 1.2.2. Hopefully, the 1.2.2 release will merit the
> General Availability stamp. Of course, nobody knows until the vote.
>

It depends partly, of course, on what features we decide to add in each
release.

> Heretofore, we have rolled several version of the same "release" and
> then suffixed them B1, B2, and so forth. Moving forward (as I understand
> it), we of these releases get their own integer. If the release does not
> make it to GA, it dies on the vine, we and go onto the next number.
>
> In practice, you often get a odd/even pattern, where the odd was the
> "beta" or "development" version and even is the stable release. Some
> communities, like Linux, Perl, and Emacs, codify this pattern. When the
> odd-beta is sufficiently patched to make it release-worthy, they roll it
> over to the next even number and release that for general availability
>

Tomcat's 4.1 experience was that only every sixth release or so was voted
GA, at least for the first several.  Now that they're up to 4.1.27, and
the number of changes is much more limited (new development is happening
in the 5.0.x series), GA things will probably happen a lot closer
together.

> AFAIK, we're not enforcing the odd/even pattern or a formal "patch
> level". So, if we roll 1.2.2 and it fails to get the votes for a GA,
> we'd go on to 1.2.3, and if that passes, it becomes the next "stable"
> release, odd or not.
>

Yep.  Patterns don't really matter.

> Of course, it would even be possible for 1.2.1 to pass a GA vote, if
> someone called for one. Personally, I think that unlikely, if only for
> documentation issues. But, others could out-vote me if the consensus
> feels differently.
>

I think it's unlikely to pass a GA vote, simply because ripping out all
the deprecated stuff is a fairly major amount of surgery, and we might
have missed something.  But we'll see.

> The core idea is that when any of us feel brave enough to roll a
> release, we can tag CVS with the next integer, and have at it. The
> instant we tag and roll it, it's automatically an Alpha. To upgrade the
> status from Alpha to Beta, or from Alpha to GA, we need a Majority Vote
> of the Committers (At least three committers have voted positively for a
> status and that there were more positive than negative votes (three is
> our working quorum for a binding vote)).
>
> To prevent any confusion with the CVS tags and so forth, the releases
> are immutable. Once it's rolled, it's rolled. If there's an issue that
> keeps a release from being upgraded, you either patch it, or tag and
> roll another release.
>

Absolutely.  One missing detail in the plan, though, is whether we branch
on each 1.2.x release.  Tomcat doesn't and I don't see a reason to since
we would probably never go back and try a 1.2.5.1 release to fix something
in 1.2.5.

Another thing Remy does for Tomcat (which I *really* appreciate) is keeps
a running change log (summary, not detai

Re: Resource Bundle Prototyping

[Joe Germuska]

At 12:30 -0400 8/6/03, Sgarlata Matt wrote:
Or did you mean I'm not modularizing my app well?  Maybe so, but I still
think a notion of a Struts "application" could be beneficial.
No, I meant nothing like that.

IMHO, the conceptual issue is that there seems to be no
notion of a Struts "application" reflected in the code because all the
modules are peers with equal status.
I'm pretty sure this was an explicit design intention, although the 
main reason may have been to make backwards compatibility more 
manageable (or maybe not -- I can't cite any place where this was 
discussed; I just have vague recollections).  From reading the lists, 
it's clear that many people intuitively expect modules to be less 
walled off from each other.

Maybe a smarter Modularization, but one which might break some 
compatibility, could be targetted for a 1.5 release, or some 
mid-point between 2.0, which has a lot of bigger changes marked for 
it.

Or maybe compatibility can be preserved anyway.

Joe

--
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time." 
	--Jaron Lanier

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

RE: When is the next release?

[Steve Raeburn]

I hope I wasn't being presumptive. You can always put it back if you want to
remove it :-)

Steve

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: August 10, 2003 9:17 AM
> To: Struts Developers List
> Subject: Re: When is the next release?
>
>
> Steve Raeburn wrote:
> > I'm for removing it. I can do this if no one else is on it already.
>
> David said he thought I was going to do it, and I thought David was
> going to do it, so let's split the difference and let Steve do it =:)
>
> -Ted.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



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

RE: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html RewriteTag.java

[Steve Raeburn]

The tld is generated from the xml file. I thought I was going crazy when I
couldn't find the source tld files >8-)

Steve

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: August 10, 2003 9:11 AM
> To: Struts Developers List
> Subject: Re: cvs commit:
> jakarta-struts/src/share/org/apache/struts/taglib/html RewriteTag.java
>
>
> Do we also need to add a TLD entry for this attribute?
>
> David
>
> --- [EMAIL PROTECTED] wrote:
> > sraeburn2003/08/10 03:05:51
> >
> >   Modified:doc/userGuide struts-html.xml
> >src/share/org/apache/struts/taglib/html RewriteTag.java
> >   Log:
> >   Added action attribute to rewrite tag.
> >   PR: 22261
> >
> >   Revision  ChangesPath
> >   1.58  +17 -0 jakarta-struts/doc/userGuide/struts-html.xml
> >
> >   Index: struts-html.xml
> >   ===
> >   RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-html.xml,v
> >   retrieving revision 1.57
> >   retrieving revision 1.58
> >   diff -u -r1.57 -r1.58
> >   --- struts-html.xml   10 Aug 2003 09:14:04 -  1.57
> >   +++ struts-html.xml   10 Aug 2003 10:05:51 -  1.58
> >   @@ -5550,6 +5550,23 @@
> >a JavaScript procedure.
> >
> >
> >   + 
> >   +  action
> >   +  false
> >   +  true
> >   +  
> >   +  Logical name of a Action that
> >   +  contains the actual content-relative URI of the
> > destination
> >   +  of this transfer.  This hyperlink may be
> > dynamically
> >   +  modified by the inclusion of query parameters, as
> > described
> >   +  in the tag description. You must
> > specify
> >   +  exactly one of the action attribute,
> > the
> >   +  forward attribute, the
> >   +  href attribute, or the
> > page
> >   +  attribute.
> >   +  
> >   +
> >   +
> >
> >  anchor
> >  false
> >
> >
> >
> >   1.15  +5 -5
> > jakarta-struts/src/share/org/apache/struts/taglib/html/RewriteTag.java
> >
> >   Index: RewriteTag.java
> >   ===
> >   RCS file:
> >
> /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/R
> ewriteTag.java,v
> >   retrieving revision 1.14
> >   retrieving revision 1.15
> >   diff -u -r1.14 -r1.15
> >   --- RewriteTag.java   31 Jul 2003 00:25:39 -  1.14
> >   +++ RewriteTag.java   10 Aug 2003 10:05:51 -  1.15
> >   @@ -102,7 +102,7 @@
> > forward,
> > href,
> > page,
> >   - null,
> >   + action,
> > params,
> > anchor,
> > false,
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> __
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



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

FW: Re: Asking for opinion: Struts a J2EE Bottleneck?

[Ted Husted]

The Struts framework is not going to start losing it's shine. ;)

Struts is the most widely accepted web application framework in the 
known universe. In all likelihood, more people use Struts than all other 
frameworks combined. Not only by developers, but also by the tool 
vendors, like WebSphere. If there is an issue -- and I'm not saying 
there is -- then the community will fix it.

The parts of the thread I read weren't even scientific; just people 
waving their arms and making wild guesses. The hundred thousand 
developers using Struts aren't going to go off and use something else 
based on this thread. At least not when their own personal experience 
has shown them that "Struts works for me!".

When people talk about Struts and reflection, they are usually talking
about the (optional) JSP tags. The JSP tag issue will apply to any
application that uses JavaServer Pages. It's not Struts specific.
If you use a container with a decent JSP compiler, or the Struts JSTL
tags on a container optimized for JSTL, then there would also be no
"bottleneck".
If you are willing to consider Turbine/Velocity, then my very best
advice is to use Struts/Velocity. I do this myself, and absolutely love
the combination =:0)
-Ted.

JDR wrote:
Dear Ted:
 
Thanks for your reply.  =)
 
In that case, since the Struts Framework may start losing its shine, 
can you recommend an open source framework out there that is worth 
investing time and effort on learning and practicing.
 
I would like it to strike a balance between :
 
1.  Performance, meaning it will not be a potential bottleneck as 
Struts now may be (now that you have implied some truth to that =) ).
2.  Longevity, one that may well be present and widely used in at 
least five years from now.
3.  Flexibility, one that is suitable for a wide spectrum of projects.
4.  Ease of use, one that will be widely supported by many of the 
IDE vendors out there and improve development productivity.
 
I am honestly having a hard time choosing a framework to learn about 
because of so many available open source offerings everywhere. Each 
have its advantages, but I don't know how to choose which one is "the 
best" or at least something close to that.
 
So I thought I'd rather take the opinion of someone who is 
well-experienced in adopting (and designing) frameworks for different 
kinds of projects. I presume you have tried quite a number of frameworks 
by now to have decided on your preference. Since you have mentioned that 
you are now using Velocity templates, does that mean that the 
Velocity-Turbine tandem has suited most requirements for your different 
projects?
 
Again, thanks for taking the time to respond to my mail, and more 
power ! 
  
Best Regards,
 

Ted Husted wrote:

If there's a bottleneck, it would be the JSP tags.

Personally, I use Velocity Templates now, so the tags aren't an issue
for me. =:0)
JDR wrote:
 > Dear Ted:
 >
 > Greetings ! I have come to know of your site through
 > the book "Professional JSP Site Design" by Wrox, and
 > have been reading your essays and many other useful
 > resources on your website.
 >
 > I have read your essay, "Is Struts Performant?" , and
 > I found it a good read, justifying the use of Struts
 > as a framework for a Java Web Application.
 >
 > However, recently, The Middleware Comoany released a
 > news about a "J2EE vs. .Net" Case Study. A forum about
 > this report is available on this page:
 >
 >
http://www.theserverside.com/home/thread.jsp?thread_id=20655&article_count=146
! >
 > Much of the posts imply that Struts became a
 > bottleneck for the J2EE Application due to the "cost
 > of Java Reflection", this could mean that many other
 > framework built on Java reflection (Axis, Hibernate,
 > etc.) will not be as performant as they were once
 > thought to be. Does this mean that Java Web Developers
 > should again look for other framework strategies, and
 > avoid those that use reflection as much as possible?
 >
 > I am asking for your honest opinion on this matter,
 > and I'm also encouraging you to join the above forum.
 >
 > If it's not too much to ask, may I also ask for your
 > opinion about the SOFIA framework, an alternative I
 > recently learned about in www.salmonllc.com. Does this
 > kind of framework (GUI-style programming) worth
 > learning about ? They do have a comparison against
 > Struts, but the document only showed how their
 > fram! ework's features are superior to Struts, so it's
 > kind of biased. I'm beginning to think that their
 > WYSIWYG workspace may speed up development, but I'm
 > not so sure about their MVC design. I noticed that
 > their implementation relies on Swing-style event
 > handling. Will this kind of framework be comparable to
 > Struts in terms of performance,

cvs commit: jakarta-struts/contrib/struts-legacy/src/jdk/1.4/org/apache/struts/legacy GenericConnection.java

[sraeburn]

sraeburn2003/08/09 23:00:49

  Modified:contrib/struts-el build-webapp.xml build-tests.xml
build.properties.sample
   doc/userGuide installation.xml configuration.xml
   .build-all-clean.bat.sample build.xml
build-webapp.xml build.properties.sample
build-tests.xml
   src/share/org/apache/struts/config DataSourceConfig.java
   conf/share MANIFEST.MF
   src/share/org/apache/struts/action ActionServlet.java
   doc/faqs database.xml
  Removed: contrib/struts-legacy/src/conf MANIFEST.MF
   contrib/struts-legacy build.xml LICENSE.txt STATUS.txt
build.properties.sample
   contrib/struts-legacy/src/jdk/1.3/org/apache/struts/legacy
GenericConnection.java
   src/share/org/apache/struts/util GenericDataSource.java
   contrib/struts-legacy/src/java/org/apache/struts/legacy
package.html GenericDataSource.java
   contrib/struts-legacy/src/jdk/1.4/org/apache/struts/legacy
GenericConnection.java
  Log:
  Removed GenericDataSource and struts-legacy
  
  Revision  ChangesPath
  1.6   +0 -5  jakarta-struts/contrib/struts-el/build-webapp.xml
  
  Index: build-webapp.xml
  ===
  RCS file: /home/cvs/jakarta-struts/contrib/struts-el/build-webapp.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- build-webapp.xml  7 Jun 2003 21:53:28 -   1.5
  +++ build-webapp.xml  10 Aug 2003 06:00:48 -  1.6
  @@ -77,10 +77,6 @@
 servlet API classes you wish to
 compile against.
   
  -struts-legacy.jar (required).  The path to the JAR file
  -  of the Jakarta Struts Legacy
  -  package (version 1.0 or later).
  -
   struts.libs   If specified, must be the pathname of a
 directory from which "struts.jar" will be
 copied to your WEB-INF/lib directory, and
  @@ -181,7 +177,6 @@
 
 
 
  -  
 
 
 
  
  
  
  1.7   +0 -3  jakarta-struts/contrib/struts-el/build-tests.xml
  
  Index: build-tests.xml
  ===
  RCS file: /home/cvs/jakarta-struts/contrib/struts-el/build-tests.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- build-tests.xml   7 Jun 2003 21:53:28 -   1.6
  +++ build-tests.xml   10 Aug 2003 06:00:48 -  1.7
  @@ -111,7 +111,6 @@
 
 
 
  -  
 
 
  
  @@ -202,8 +201,6 @@
   
   
  -
   
   
   
  -# The JAR file containing version 1.0 (or later) of the Struts Legacy package
  -# from the Jakarta Struts contrib area.
  -struts-legacy.jar= 
  -
   # Properties related to Struts unit testing
   # -
   
  
  
  
  1.32  +0 -2  jakarta-struts/doc/userGuide/installation.xml
  
  Index: installation.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/installation.xml,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- installation.xml  26 Jul 2003 03:56:25 -  1.31
  +++ installation.xml  10 Aug 2003 06:00:48 -  1.32
  @@ -352,8 +352,6 @@
   Validator package JAR file from the Jakarta Commons project.
   servletapi.home - Pathname to the directory of
   your binary distribution of the Servlet API classes.
  -struts-legacy.jar - Pathname of the Struts Legacy
  -package JAR file from the Jakarta Struts contrib area.
   tomcat.home - Pathname to the directory of your
   binary distribution of Tomcat 3.2 (required only if you wish to
   use the deploy.tomcat target).
  
  
  
  1.24  +5 -12 jakarta-struts/doc/userGuide/configuration.xml
  
  Index: configuration.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/configuration.xml,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- configuration.xml 8 Jul 2003 00:30:33 -   1.23
  +++ configuration.xml 10 Aug 2003 06:00:48 -  1.24
  @@ -381,13 +381,6 @@
   And other sundry properties.
   
   
  -
  -As a further convenience, Struts provides a default DataSource
  -implementation, [org.apache.struts.util.GenericDataSource].
  -The type property can be used to specify

Re: cvs commit: jakarta-struts/contrib/tag-doc build.xml

[David M. Karr]

> "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:

Craig> On Sat, 9 Aug 2003, David M. Karr wrote:
>> Date: 09 Aug 2003 16:01:52 -0700
>> From: David M. Karr <[EMAIL PROTECTED]>
>> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> Subject: Re: cvs commit: jakarta-struts/contrib/tag-doc build.xml
>> 
>> > "craigmcc" == craigmcc  <[EMAIL PROTECTED]> writes:
>> 
craigmcc> craigmcc2003/08/09 12:29:30
craigmcc> Modified:.build.xml
craigmcc> ELFormTag.java ELHtmlTag.java
craigmcc> ELJavascriptValidatorTag.java
craigmcc> Log:
>> 
craigmcc> Also fixed some compile errors in struts-el -- I don't know how that code
craigmcc> could have compiled for anyone.  Could someone more familiar with that
craigmcc> library make sure I did the changes correctly?
>> 
>> Huh?  What compile errors were you getting?  I just re-updated and changed it
>> back to the way it was (in ELFormTag, at least), and it compiles fine (with
>> both 1.4.1 and 1.3.1).  It can't work the way you changed it, because it has to
>> call the base class setter, which takes a boolean, not a string.

Craig> I was getting "cannot resolve method" errors for the cases that were
Craig> changed.  Can you go ahead and commit your reversions so I can reproduce
Craig> the errors?

Done.  I made these changes a few days ago to match very recent changes to the
base tags.  If you're getting "cannot resolve method" errors, I would assume
the struts.jar you're referencing is before those changes.

-- 
===
David M. Karr  ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]   ; SCJP; SCWCD




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

cvs commit: jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/logic ELMatchSupport.java

[dmkarr]

dmkarr  2003/08/09 20:02:59

  Modified:contrib/struts-el/src/share/org/apache/strutsel/taglib/logic
ELMatchSupport.java
  Log:
  Changed from RequestUtils to TagUtils.
  
  Revision  ChangesPath
  1.4   +5 -5  
jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/logic/ELMatchSupport.java
  
  Index: ELMatchSupport.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/logic/ELMatchSupport.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ELMatchSupport.java   1 Oct 2002 04:25:51 -   1.3
  +++ ELMatchSupport.java   10 Aug 2003 03:02:59 -  1.4
  @@ -63,7 +63,7 @@
   import org.apache.struts.util.MessageResources;
   import javax.servlet.jsp.JspException;
   import javax.servlet.jsp.PageContext;
  -import org.apache.struts.util.RequestUtils;
  +import org.apache.struts.taglib.TagUtils;
   
   /**
* This class is used as a helper class for both the
  @@ -113,7 +113,7 @@
   } else {
   JspException e = new JspException
   (messages.getMessage("logic.location", location));
  -RequestUtils.saveException(pageContext, e);
  +TagUtils.getInstance().saveException(pageContext, e);
   throw e;
   }
   
  
  
  

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

cvs commit: jakarta-struts/web/example/WEB-INF struts-config-registration.xml struts-config.xml

[rleland]

rleland 2003/08/09 19:52:55

  Modified:web/example/WEB-INF struts-config-registration.xml
struts-config.xml
  Log:
  Use standard prexisting ELEMENTS description and display-name,
  instead of description-short & description-long.
  
  -Rob
  
  Revision  ChangesPath
  1.3   +4 -4  
jakarta-struts/web/example/WEB-INF/struts-config-registration.xml
  
  Index: struts-config-registration.xml
  ===
  RCS file: 
/home/cvs/jakarta-struts/web/example/WEB-INF/struts-config-registration.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- struts-config-registration.xml9 Aug 2003 08:50:52 -   1.2
  +++ struts-config-registration.xml10 Aug 2003 02:52:55 -  1.3
  @@ -5,15 +5,15 @@
 "http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd";>
   
   
  -  
  -  
  -
  -  
  +  
   
 
 
  
  
  
  1.33  +4 -4  jakarta-struts/web/example/WEB-INF/struts-config.xml
  
  Index: struts-config.xml
  ===
  RCS file: /home/cvs/jakarta-struts/web/example/WEB-INF/struts-config.xml,v
  retrieving revision 1.32
  retrieving revision 1.33
  diff -u -r1.32 -r1.33
  --- struts-config.xml 9 Aug 2003 08:50:52 -   1.32
  +++ struts-config.xml 10 Aug 2003 02:52:55 -  1.33
  @@ -6,14 +6,14 @@
   
   
   
  -  
  -  
  -
  -  
  +  
   
   
 
  
  
  

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

Re: Resource Bundle Prototyping

[Joe Germuska]

At 12:01 -0400 8/6/03, Sgarlata Matt wrote:
Good point!  I ran originally ran into the resource bundle problem a long
time ago, and forgot that there are other application-wide settings that
would be nice to inherit from module to module.
1) Declarative Exception Handling () - in my application,
each module treats exceptions the same way, so we end up copying the
 portion of the struts-config file from module to module.
2) Global Forwards - same deal with global forwards.  We have a "debug"
forward that we use when debugging Action classes that gets copied to every
module(System.out.println isn't practical on some application servers, and
we haven't implemented log4j yet, so "debug" isn't a great example, but I'm
sure someone can think of a better one)
Maybe this is just pointing out a need to better understand the 
relationships between modules?  Although they work for many of us in 
a simple fashion, problems like yours (among others) seem to point 
out ways in which the modularization is not completely worked out yet.

Just a thought.  I'm in between major Struts projects at the moment, 
so I don't have anything fresh in my own head.

Joe

--
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time." 
	--Jaron Lanier

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

RE: When is the next release?

[Craig R. McClanahan]

On Sat, 9 Aug 2003, Steve Raeburn wrote:

> Date: Sat, 9 Aug 2003 20:10:16 -0700
> From: Steve Raeburn <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: RE: When is the next release?
>
> > -Original Message-
> > From: Robert Leland [mailto:[EMAIL PROTECTED]
> > Sent: August 9, 2003 7:43 PM
> > To: Struts Developers List
> > Subject: Re: When is the next release?
> >
> >
> > Are we going to take the struts-legacy out this build or remove
> > it for 1.3.
>
> I'm for removing it. I can do this if no one else is on it already.
>
> I'd also like to remove the  deprecated attributes (name, style,
> type) if there are no objections.
>

If we have remaining 1.1 deprecations, I'd prefer we cleaned them all out
before the first 1.2 release so nobody assumes that we'll have to keep
them all the way through a 1.2.x lifetime.

> > If so then the data source code will need to be removed, before the beta.
> > Beta implies a stable interface.
> > Also I thought we were going to do away with alpha/beta/RC  anyway.
>
> I'm sure I read a message on that a couple of days ago, but I can't find it
> now. (Must be losing it)
> Anyway, the gist was that we don't have a current non-stable/development
> release (odd numbered) so we'd need a Beta.
>
> If I could find the message I might understand it myself :-)
>

See my previous response re: the way that Tomcat and Apache HTTPD do it.
That's what we agreed to use for 1.2, quite a while back.

> Steve

Craig

>
> >
> > >
> > >
> > > -Ted.
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> >
> >
> > --
> > Robert Leland   [EMAIL PROTECTED]
> > --
> > Java, J2EE, Struts, Web Application Development
> >
> > 804 N. Kenmore Street   +01-703-525-3580
> > Arlington VA 22201
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: Building contrib packages WAS Re: cvs commit: jakarta-struts/contrib/tag-doc build.xml

[David M. Karr]

> "David" == David Graham <[EMAIL PROTECTED]> writes:

David> --- "David M. Karr" <[EMAIL PROTECTED]> wrote:
>> > "David" == David Graham <[EMAIL PROTECTED]> writes:
>> 
David> While we're somewhat on this topic I'd like to get some
>> clarification on
David> the build process.  Why do struts-el and struts-legacy get
>> built with the
David> standard Struts build file?  Struts-EL has *never* built on
>> my machine and
David> I have just taken it on faith the rest of Struts built
>> properly.  Also,
David> after struts-legacy was added I've had to run my builds
>> twice.  The first
David> one always fails and the second succeeds (well, not really
>> succeeds
David> because struts-el fails).
>> 
>> So what compile errors are you getting in Struts-EL and Struts-Legacy?

David> I don't get any compile errors.  It's a problem with jars not being in the
David> right place or my build.properties being incorrect.  I don't mean this in
David> any negative way but I'm not interested in building struts-el.  When I
David> build Struts I'm mainly interested in picking up a webapp and running
David> through it to see if my changes work.  

I understand completely.  Note that you can avoid building Struts-EL if you
ensure that the "jstl.jar" variable is NOT set (I believe Craig set this up).
It's also possible that Craig's fix a minute ago may make this work better for
you.

David> If there's no concrete reason to build struts-el with Struts, I'd like to
David> see them separated to simplify the build process.  This specific problem
David> will go away when struts-el is part of the taglib distro but I think there
David> is a more general problem of building contrib packages along with the
David> standard packages.

I don't really know how to address this.

-- 
===
David M. Karr  ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]   ; SCJP; SCWCD




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

Re: cvs commit: jakarta-struts/contrib/tag-doc build.xml

[Craig R. McClanahan]

On Sat, 9 Aug 2003, David M. Karr wrote:

> Date: 09 Aug 2003 18:12:19 -0700
> From: David M. Karr <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: jakarta-struts/contrib/tag-doc build.xml
>
> > "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
>
> Craig> On Sat, 9 Aug 2003, David M. Karr wrote:
> >> Date: 09 Aug 2003 16:01:52 -0700
> >> From: David M. Karr <[EMAIL PROTECTED]>
> >> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: cvs commit: jakarta-struts/contrib/tag-doc build.xml
> >>
> >> > "craigmcc" == craigmcc  <[EMAIL PROTECTED]> writes:
> >>
> craigmcc> craigmcc2003/08/09 12:29:30
> craigmcc> Modified:.build.xml
> craigmcc> ELFormTag.java ELHtmlTag.java
> craigmcc> ELJavascriptValidatorTag.java
> craigmcc> Log:
> >>
> craigmcc> Also fixed some compile errors in struts-el -- I don't know how that 
> code
> craigmcc> could have compiled for anyone.  Could someone more familiar with that
> craigmcc> library make sure I did the changes correctly?
> >>
> >> Huh?  What compile errors were you getting?  I just re-updated and changed it
> >> back to the way it was (in ELFormTag, at least), and it compiles fine (with
> >> both 1.4.1 and 1.3.1).  It can't work the way you changed it, because it has 
> to
> >> call the base class setter, which takes a boolean, not a string.
>
> Craig> I was getting "cannot resolve method" errors for the cases that were
> Craig> changed.  Can you go ahead and commit your reversions so I can reproduce
> Craig> the errors?
>
> Done.  I made these changes a few days ago to match very recent changes to the
> base tags.  If you're getting "cannot resolve method" errors, I would assume
> the struts.jar you're referencing is before those changes.
>
>

Picking up your reversions, I get 3 errors (plus two deprecation warnings
I'm not worrying about) when I run "ant clean dist" from the top-level
directory:

/home/craigmcc/Jakarta/jakarta-struts-1.2/contrib/struts-el/src/share/org/apache/strutesl/taglib/html/ELJavascriptValidatorTag.java:281:
cannot resolve symbol
symbol: method setScriptLanguage (boolean)
location: class org.apache.strutsel.taglib.html.ELJavascriptValidatorTag

  setScriptLanguage(bool.booleanValue());
  ^

/home/craigmcc/Jakarta/jakarta-struts-1.2/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELFormTag.java:391:
cannot resolve symbol
symbol: method setScriptLanguage (boolean)
location: class org.apache.strutsel.taglib.html.ELFormTag
  setScriptLanguage(bool.booleanValue());
  ^

/home/craigmcc/Jakarta/jakarta-struts-1.2/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELHtmlTag.java:163:
cannot resolve symbol
symbol: method setLang(boolean)
location: class org.apache.strutsel.taglib.html.ELHtmlTag
  setLang(bool.booleanValue());
  ^

If I cd to "contrib/struts-el" and run "ant clean dist", I get exactly the
same errors.

Craig


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

Re: When is the next release?

[Craig R. McClanahan]

On Sat, 9 Aug 2003, Robert Leland wrote:

> Date: Sat, 09 Aug 2003 22:42:43 -0400
> From: Robert Leland <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: When is the next release?
>
> Ted Husted wrote:
>
> > Just a head's up. I'd like to draw up a Release Plan tomorrow for
> > Struts 1.2 beta 1. I'd like to get this out so people can start
> > migrating to the "non-deprecated Struts 1.1+" (for lack of a better
> > term) *before* we get into the Commons Resources thing.
> >
> > Since we did so much backward-compatiblity work on Struts 1.1, getting
> > the deprecations out of some of the older code will be no small task
> > for some people, but the sooner we get the community started on this,
> > the better.
> >
> > If anyone else would like to be the Release Manager, please feel free
> > to chime in. I'd be happy to pass the baton once the plan is in place.
>
>
> Are we going to take the struts-legacy out this build or remove it for 1.3.
> If so then the data source code will need to be removed, before the beta.
> Beta implies a stable interface.
> Also I thought we were going to do away with alpha/beta/RC  anyway.
>

That was my understanding as well -- we agreed to switch to the x.y.z
style that Apache HTTPD and Tomcat are using, where you post the bits and
then call for a vote on stability (alpha/beta/general availability).  It's
perfectly reasonable to have a series of "general availability" releases
with new features in the 1.2.x series, as long as we continue to maintain
backwards compatibility within it.

Therefore the first release would be 1.2.1 and we'd keep going from there.

> >
> >
> > -Ted.
> >

Craig

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

RE: SuccessAction (was RE: Addition of two new actions)

[Steve Raeburn]

I've created some patches to try this out and attached them to Bugzilla.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22267

Sorry about the multiple patch files, but WS Studio wouldn't play ball.

I haven't touched Action...yet ;-)

Steve



> -Original Message-
> From: Steve Raeburn [mailto:[EMAIL PROTECTED]
> Sent: August 8, 2003 8:36 PM
> To: Struts Developers List
> Subject: RE: SuccessAction (was RE: Addition of two new actions)
>
>
> > I thought the whole point was that there would be only one forward
> > and the action would always forward to that forward?  In that case,
> > you could count on using the first one.
>
> Just thinking that if an anonymous/default ActionForward were
> allowed, then
> it could also be useful for other actions. In any case, it's better not to
> allow a situation where the behaviour is unspecified.
>
> >> You'd probably need to add a method such as getDefaultForward()
> >> to retrieve it.
> >
> > This part seems to be adding complexity to something which was meant
> > to be very simple.
>
> I think it might actually be possible to reduce the visible complexity by
> doing that. e.g.
>
>  type="org.apache.struts.actions.SuccessAction">
>   
>   
>
> SuccessAction may not now be best name, but let's stick with it for the
> moment.
>
> To be really radical, we could absorb the behaviour into Action,
> and have it
> check for a default ActionForward and use that, if found. That way there's
> no need for a SuccessAction at all. Then you could just do:
>
>  type="org.apache.struts.action.Action">
>   
>   
>
> If Action actually does something useful, could we go crazy and
> default the
> type as well?
>
>   
>   
>   
>
> Now that's simple. Especially if you allow a global default forward...
>
>   
>
> Probably not quite so useful, but nicely minimal!
>
> Steve
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



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

DO NOT REPLY [Bug 22261] New: - html:rewrite tag functionality and documentation mismatch

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22261

html:rewrite tag functionality and documentation mismatch

   Summary: html:rewrite tag functionality and documentation
mismatch
   Product: Struts
   Version: 1.1 Final
  Platform: All
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am not sure if this is an issue with the tag itself or the documentation on 
the html:rewrite tag. 

In the documentation, it states that:  "You must specify exactly one of the 
action attribute, the forward attribute, the href attribute, or the page 
attribute."  I am trying to use the rewrite tag to generate the URI for an 
action, but the tag will not let me do that.  I was able to modify the tag and 
TLD to allow an action to be specified, as the documentation implies.

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

FW: Validator

[Yansheng Lin]

Can anyone on the dev list shed some light on the following Q?  
When could the JavaBean be a String type?

Thank you!

-Original Message-
From: Erez Efrati [mailto:[EMAIL PROTECTED] 
Sent: August 6, 2003 3:33 PM
To: 'Struts Users Mailing List'
Subject: Validator



I am trying to figure out the code in struts.validator.FieldsCheck.java
in order to write one of my own.
Can someone explain what the purpose of the following lines of code in
all of the validateXXX() in Struts:

validateIntRange (...) {

if (isString(bean)) {
value = (String) bean;
}
...
}

Is this really necessary?

Erez



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


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