Re: Short term plans
At 11:46 am 01-03-03, you wrote: JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3 and JSP 1.2, so they are not even an option for a very significant portion of the Struts user community. Thus, it would be irresponsible to abandon our focus on ensuring the quality of the Struts tag libraries -- and this would be true even if Struts was a commercial product instead of an open source package. With respect (too :-), what criteria should/would the (developer) community use to strike a balance, both ensuring the quality and relevance of Struts taglibs (JSP 1.1 dependent) and migrating users gradually to JSTL (JSP 1.2 dependent)? For instance, in a recent feature request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17535 As David, the recently crowned MVC (what an acronym), pointed out the requested feature for bean:message is already available in JSTL fmt:message. Is there an easy litmus test for Struts users to guestimate if an enhancement is worthwhile requesting? regards, -- John Yu Scioworks Technologies e: [EMAIL PROTECTED] w: +(65) 6873 5989 w: http://www.scioworks.com m: +(65) 9782 9610 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: consultants and poweredby removal
On Friday, February 28, 2003, at 10:48 PM, Craig R. McClanahan wrote: +1, but we should leave a note behind saying what happened. It also wouldn't bother me at all if someone else wanted to maintain such pages (and we could point there from the resources pages). Now that we have an official Jakarta wiki: http://nagoya.apache.org/wiki/apachewiki.cgi?HomePage Why not just point there and let everyone self-maintain consultant and powered-by lists? Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
First, David was probably trying to be helpful. (Why reinvent the wheel?) But to answer your question, I think the litmus test would be whether there is a working patch annexed. All anyone has said is that since the attention of the Committers in their own work is likely to be on other technologies, it is equally likely that the Committers won't be spending their *own* development time *creating* patches. As long as the change has technical merit, and a Committer is willing to take responsbility for the patch, we won't/can't veto something becomes of competition from JSTL/JSF/XLST/Velocity/Tapestry/lord-knows. Meanwhile, if we have a good suite of tests, and a patch comes along, it will be easier for any of us to commit it (since the tests will help catch any problems). -T. John Yu wrote: With respect (too :-), what criteria should/would the (developer) community use to strike a balance, both ensuring the quality and relevance of Struts taglibs (JSP 1.1 dependent) and migrating users gradually to JSTL (JSP 1.2 dependent)? For instance, in a recent feature request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17535 As David, the recently crowned MVC (what an acronym), pointed out the requested feature for bean:message is already available in JSTL fmt:message. Is there an easy litmus test for Struts users to guestimate if an enhancement is worthwhile requesting? regards, -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
Yes, it was James, and I join thanking him, et. all.
The effect is feature creep delaying a release with a limited pool of
resources, for things that some would like to deprecate. Like in Struts
1.2 supporting Tomcat 3.x? That takes time, and limits what can be done
in other areas.
Surely you agree that some tags should slowly move to jakarta.taglib?
And if I can disagree on the stats, my anecdotal evidence is that
projects in development are Tomcat 4.x (JSP and Servlet API).
Else consider adding developers (keep an eye on Matt Raible, Ben
Tomasini, Scot Skyles, Ibatis.com guy, Tiles 201 guy, Stxx guy,
sf.struts people, ... )
Again, my hope is that a quick 1.2 release is Servlet 2.3 and EL.
( Struts 2.0 wish list?: more soapy, and JSP2.0, maven, jelly, and
http://ireport.sourceforge.net/images/screenshot6.gif drag and drop 2
way from jsp to beans, jdk 1.4)
I am now teaching JSP 2.0 in Resin 3/Tomcat 5 in my Struts classe with
this 2.0 syntax:
${ibean['field']}
By the time their 6 month project cycle is ready to deploy, JSP2.0 will
be out.
Just take it into consideration, a faster development cycle, means
making some austerity choices in 1.2. Alternative? Struts 1.2 in
18 months?
.V
Craig R. McClanahan wrote:
On Fri, 28 Feb 2003, David Graham wrote:
Date: Fri, 28 Feb 2003 17:50:08 -0700
From: David Graham [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Short term plans
The taglibs are a heavily used feature. We get a lot of bug reports on them
so the tests are badly needed. There is no doubt that we should use JSTL
but at this point not everyone has that option.
At JavaOne US 2002 (March 2002) I did a survey of the folks that came to
the Struts Community BOF. Over half the people there were developing and
deploying on J2EE 1.2 (i.e. Servlet 2.2 and JSP 1.1) platforms. Yes, it's
almost a year later now, but the situation has not *totally* changed.
JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3
and JSP 1.2, so they are not even an option for a very significant portion
of the Struts user community. Thus, it would be irresponsible to abandon
our focus on ensuring the quality of the Struts tag libraries -- and this
would be true even if Struts was a commercial product instead of an open
source package.
That being said, it's very clear where the future is for view tier
technology. But that's for the future (Struts 1.2 and beyond) -- and,
even for those future Struts versions, users are not always able to
convert their applications instantly. We need to care now, and will
continue to need to care in the future, about the quality of the existing
Struts tag libraries. I'm totally delighted that someone like David has
cared enough to create such a comprehensive test suite for a feature that
is critically important to a very large majority of current, and future,
Struts users.
Thanks David!
David
Craig
With respect, consider how much time struts-devs should spend on tags, I
kind of agree with those that say slowly move them over to taglibs and
separate jar away from core struts, for example if JSTL can do it.
Of course I know, open source means donating contributors kind of get to
work on what they want.
my 2 c.
.V
Karr, David wrote:
-Original Message-
From: James Mitchell [mailto:[EMAIL PROTECTED]
My plans are to finish up html this weekend, and tiles, upload, and
validator by the end of next week. After that I hope to get all the
nested tags done between 3/15 and 3/22, then move on to the struts-el
tags.
The only thing that might delay things is the fact that my contract is
almost up and I'm desperately looking for another job.
Does anyone object or is there a special focus that anyone wants to
get
covered quickly?
Also, are there any volunteers out there wanting to help me get this
stuff nailed?
Sigh.
If your new testing setup is reasonably straightforward, I wouldn't
imagine it could be very difficult for me or someone else to clone them
(and remove some) for the Struts-EL tests. There already is a set of
Cactus tests for Struts-EL which covered more than the original base
Struts tests did, but your new work has very likely jumped well past
that.
In short, if you've finished everything you need to do for bean, logic,
and html, and you have some doors to knock on, then give me what I need
to know and I'll implement the Struts-EL tests (or someone else, if they
wanted to do this). If Aaron has time, he could probably do the same
for the nested tags.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
-
To unsubscribe,
Re: consultants and poweredby removal
The only problem with removing the powered by page is that it's a FAQ. So if we remove the page, we have to decide what we are going to say when people ask What sites are using Struts. There are ways to answer this without an enumeration of links, but we are going to need an answer. What *really* might be nice would be a handful of case studies with a war stories from the development team about creating significant sites with Struts. dIon's Pizza Hut site comes to mind. The Malamute registry would be another likely suspect. So, it wouldn't just be send us your link but send us your story. -T. David Graham wrote: I think we should get rid of poweredby entirely. I was maintaining the update requests for some time and grew *very* tired of it. I'd also rather not have the Struts site be used for advertisments for other companies. The automatic validation idea is good but responding to the update requests is still time consuming. Dave From: James Mitchell [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: consultants and poweredby removal Date: Fri, 28 Feb 2003 22:27:37 -0500 Problem is that some people are referencing the 1.0.2 docs instructions, so even if we do they will probably still send in requests. On a recent request, I went to their site, there was no mention of Struts or Jakarta or Apache or even Java!!! I'm +1 for removing it. I'm also +1 for dumping all 'powered by' references that are invalid. I mean, its one thing to add links to sites that aren't allowed to put our logo there, but its another to get 404 or connection refused. We've had several more mentioned lately so it might be a good idea to scrub that list again and put up some more valid links and remove the bad ones. If we think this is becoming a maintenance problem, I'll volunteer to add a task to the build that let's us validate the references by creating a resources-violators.html report when finished. I was thinking about something with a declarative search criteria or pattern. -- James Mitchell Web Developer/Struts Evangelist http://jakarta.apache.org/struts/ People demand freedom of speech to make up for the freedom of thought which they avoid. - Soren Aabye Kierkegaard (1813-1855) -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Friday, February 28, 2003 9:34 PM To: [EMAIL PROTECTED] Subject: consultants and poweredby removal We no longer actively maintain the consultants and poweredby pages. What does everyone think about removing them? We still get requests to be added to those pages so I think it would be good to get rid of them. David _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17559] - key attribute for tiles (put item)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17559. 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=17559 key attribute for tiles (put item) --- Additional Comments From [EMAIL PROTECTED] 2003-03-01 15:21 --- Hey, I like this one Currently, I use in the layout: ... tiles:importAttribute name=title scope=page/ titlebean:message name=title //title And the attribute bundle to use different message resources would be needed too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17562] New: - Sub-Tiles not rendered correctly in 1.1b2 and 1.1RC1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17562. 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=17562 Sub-Tiles not rendered correctly in 1.1b2 and 1.1RC1 Summary: Sub-Tiles not rendered correctly in 1.1b2 and 1.1RC1 Product: Struts Version: 1.1 RC1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] After upgrading from Struts 1.1b2 to 1.1RC1 many of my Tiles based pages would render incorrectly. I've created a simple example to illustrate this behavior. In 1.1b2 it renders correctly like this: Testing Sub-tiles TILE_A TILE_B In 1.1RC1 it renders incorrectly like this: TILE_A TILE_B Testing Sub-tiles The entry JSP, called subtiles.jsp, looks like this: %@ page contentType=text/html% %@ taglib uri=/WEB-INF/struts-tiles.tld prefix=tiles % html head meta http-equiv=Content-Type content=text/html titleSub-Tiles Test/title /head body h1Testing Sub-tiles/h1 tiles:insert page=tilestable.jsp flush=true tiles:put name=cellone tiles:insert page=tilea.jsp flush=true/ /tiles:put tiles:put name=celltwo tiles:insert page=tileb.jsp flush=true/ /tiles:put /tiles:insert /body /html The tilestable.jsp looks like this: %@ page contentType=text/html% %@ taglib uri=/WEB-INF/struts-tiles.tld prefix=tiles % tiles:useAttribute name=cellone/ tiles:useAttribute name=celltwo/ table border=0 cellpadding=4 cellspacing=4 tr td%= cellone %/td td%= celltwo %/td /tr /table And tilea.jsp is shown below: %@ page contentType=text/html% TILE_A Followed by tileb.jsp here: %@ page contentType=text/html% TILE_B I searched the struts-user list archives and found a thread titled Odd Tiles Behavior with 2003-01-01 Nightly Build. Cedric Dumoulin had indicated to the poster reporting the problem to file a bug in Bugzilla. However I've found no such bug report. Here's the link to Cedric's response: http://shorl.com/gybrypryvabyga - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17562] - Sub-Tiles not rendered correctly in 1.1b2 and 1.1RC1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17562. 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=17562 Sub-Tiles not rendered correctly in 1.1b2 and 1.1RC1 --- Additional Comments From [EMAIL PROTECTED] 2003-03-01 15:32 --- Created an attachment (id=5097) Cedric's response to a struts-user poster with same problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17562] - Sub-Tiles not rendered correctly in 1.1b2 and 1.1RC1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17562. 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=17562 Sub-Tiles not rendered correctly in 1.1b2 and 1.1RC1 --- Additional Comments From [EMAIL PROTECTED] 2003-03-01 15:54 --- I should've mentioned that my JSP container is OC4J 9.0.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
The plan is to change the base servlet requirement in 2.0 not 1.2.
David
From: Vic Cekvenich [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Short term plans
Date: Sat, 01 Mar 2003 07:37:38 -0500
Yes, it was James, and I join thanking him, et. all.
The effect is feature creep delaying a release with a limited pool of
resources, for things that some would like to deprecate. Like in Struts 1.2
supporting Tomcat 3.x? That takes time, and limits what can be done in
other areas.
Surely you agree that some tags should slowly move to jakarta.taglib?
And if I can disagree on the stats, my anecdotal evidence is that projects
in development are Tomcat 4.x (JSP and Servlet API).
Else consider adding developers (keep an eye on Matt Raible, Ben Tomasini,
Scot Skyles, Ibatis.com guy, Tiles 201 guy, Stxx guy, sf.struts people,
... )
Again, my hope is that a quick 1.2 release is Servlet 2.3 and EL.
( Struts 2.0 wish list?: more soapy, and JSP2.0, maven, jelly, and
http://ireport.sourceforge.net/images/screenshot6.gif drag and drop 2 way
from jsp to beans, jdk 1.4)
I am now teaching JSP 2.0 in Resin 3/Tomcat 5 in my Struts classe with this
2.0 syntax:
${ibean['field']}
By the time their 6 month project cycle is ready to deploy, JSP2.0 will be
out.
Just take it into consideration, a faster development cycle, means making
some austerity choices in 1.2. Alternative? Struts 1.2 in 18 months?
.V
Craig R. McClanahan wrote:
On Fri, 28 Feb 2003, David Graham wrote:
Date: Fri, 28 Feb 2003 17:50:08 -0700
From: David Graham [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Short term plans
The taglibs are a heavily used feature. We get a lot of bug reports on
them
so the tests are badly needed. There is no doubt that we should use JSTL
but at this point not everyone has that option.
At JavaOne US 2002 (March 2002) I did a survey of the folks that came to
the Struts Community BOF. Over half the people there were developing and
deploying on J2EE 1.2 (i.e. Servlet 2.2 and JSP 1.1) platforms. Yes, it's
almost a year later now, but the situation has not *totally* changed.
JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3
and JSP 1.2, so they are not even an option for a very significant portion
of the Struts user community. Thus, it would be irresponsible to abandon
our focus on ensuring the quality of the Struts tag libraries -- and this
would be true even if Struts was a commercial product instead of an open
source package.
That being said, it's very clear where the future is for view tier
technology. But that's for the future (Struts 1.2 and beyond) -- and,
even for those future Struts versions, users are not always able to
convert their applications instantly. We need to care now, and will
continue to need to care in the future, about the quality of the existing
Struts tag libraries. I'm totally delighted that someone like David has
cared enough to create such a comprehensive test suite for a feature that
is critically important to a very large majority of current, and future,
Struts users.
Thanks David!
David
Craig
With respect, consider how much time struts-devs should spend on tags, I
kind of agree with those that say slowly move them over to taglibs and
separate jar away from core struts, for example if JSTL can do it.
Of course I know, open source means donating contributors kind of get to
work on what they want.
my 2 c.
.V
Karr, David wrote:
-Original Message-
From: James Mitchell [mailto:[EMAIL PROTECTED]
My plans are to finish up html this weekend, and tiles, upload, and
validator by the end of next week. After that I hope to get all the
nested tags done between 3/15 and 3/22, then move on to the struts-el
tags.
The only thing that might delay things is the fact that my contract is
almost up and I'm desperately looking for another job.
Does anyone object or is there a special focus that anyone wants to
get
covered quickly?
Also, are there any volunteers out there wanting to help me get this
stuff nailed?
Sigh.
If your new testing setup is reasonably straightforward, I wouldn't
imagine it could be very difficult for me or someone else to clone them
(and remove some) for the Struts-EL tests. There already is a set of
Cactus tests for Struts-EL which covered more than the original base
Struts tests did, but your new work has very likely jumped well past
that.
In short, if you've finished everything you need to do for bean, logic,
and html, and you have some doors to knock on, then give me what I need
to know and I'll implement the Struts-EL tests (or someone else, if
they
wanted to do this). If Aaron has time, he could probably do the same
for the nested tags.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
The test I use is this: Does the requested feature exist in JSTL? If so, don't duplicate the effort in Struts. This is not just my opinion, it has been discussed among the committers before. I don't think people requesting enhancements or patches realize the amount of effort required to get it into Struts. Committers have to analyze the request, figure out the code to change, code it, test it, build it, and finally commit it. Add those steps up and you've got several hours of work. *I* will not volunteer my time implementing a feature that is already part of a standard taglib. David From: John Yu [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Short term plans Date: Sat, 01 Mar 2003 16:34:07 +0800 At 11:46 am 01-03-03, you wrote: JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3 and JSP 1.2, so they are not even an option for a very significant portion of the Struts user community. Thus, it would be irresponsible to abandon our focus on ensuring the quality of the Struts tag libraries -- and this would be true even if Struts was a commercial product instead of an open source package. With respect (too :-), what criteria should/would the (developer) community use to strike a balance, both ensuring the quality and relevance of Struts taglibs (JSP 1.1 dependent) and migrating users gradually to JSTL (JSP 1.2 dependent)? For instance, in a recent feature request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17535 As David, the recently crowned MVC (what an acronym), pointed out the requested feature for bean:message is already available in JSTL fmt:message. Is there an easy litmus test for Struts users to guestimate if an enhancement is worthwhile requesting? regards, -- John Yu Scioworks Technologies e: [EMAIL PROTECTED] w: +(65) 6873 5989 w: http://www.scioworks.com m: +(65) 9782 9610 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
On Sat, 1 Mar 2003, John Yu wrote: Date: Sat, 01 Mar 2003 16:34:07 +0800 From: John Yu [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Short term plans At 11:46 am 01-03-03, you wrote: JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3 and JSP 1.2, so they are not even an option for a very significant portion of the Struts user community. Thus, it would be irresponsible to abandon our focus on ensuring the quality of the Struts tag libraries -- and this would be true even if Struts was a commercial product instead of an open source package. With respect (too :-), what criteria should/would the (developer) community use to strike a balance, both ensuring the quality and relevance of Struts taglibs (JSP 1.1 dependent) and migrating users gradually to JSTL (JSP 1.2 dependent)? For instance, in a recent feature request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17535 As David, the recently crowned MVC (what an acronym), pointed out the requested feature for bean:message is already available in JSTL fmt:message. Is there an easy litmus test for Struts users to guestimate if an enhancement is worthwhile requesting? Good question. I think there are multiple perspectives for asking for enhancements, all of them valid. Some examples: * I need it -- This particular feature would help me out right now, without disrupting my entire app by forcing me to upgrade to the latest and greatest. * Lots of people need it -- This particular feature would be generally useful to lots of people using an existing version of Struts (think about how many add-on libraries and tags work fine with 1.0.2 based apps). * I want to work on it -- If we are limited by the number of developers working on Struts and we want those folks working on the future stuff, nothing stops us from adding some more developers that want to continue to enhance the existing tags. NOTE -- this perspective is the most critical for actually getting anything done :-). There's nothing wrong with people operating from any and all of these perspectives simultaneously. In all cases, of course, patches that actually *implement* the new feature (rather than just an enhancement request asking for it) is a lot more likely to get the thing actually done (modulo timing delays when we're trying to get a release out the door). And, if you do that enough times, you're likely to find yourself operating from the third perspective and welcomed as an additional Struts developer -- and people who want to do that would be welcomed. A fourth perspective that is also valid is to be future looking: what do we want a future Struts to look like without being as much concerned about existing users with their day-to-day real life problems. We haven't spent a lot of time (yet) talking about that on the STRUTS-DEV list -- at least partly because I've been afraid we would dive into those (fun) discussions and sort of ignore the fact that 1.1 isn't out the door yet :-). It's certainly time to start articulating our thoughts and desires on this, so we can come to agreement on a coherent roadmap. On the particular issue of the existing Struts tags, at this point I can only state my own interests and plans: * I'm interested in enabling the convenient use of JSTL and JavaServer Faces technologies with an existing and future Struts controller environment. I'm not *personally* going to focus on maintaining and enhancing the existing tag libraries, but it would be ridiculous and counter-productive to suggest that others who want to work on them should not -- I apologize if *I* have ever implied that in my previous comments. * I'm interested in separating the core controller part of Struts (which I personally consider to be the most important part) from the current somewhat tight integration with the JSP tags as the view layer. Organizationally, this might well mean independent releases of the core and appropriate view technology libraries (and perhaps its even time to think about becoming a top-level Apache project like Ant, Avalon, and a few others have done -- but that's for a separate mail thread) * I'm interested in decoupling the controller part of Struts from its current heavy reliance on the Servlet APIs. Among other things, that would enable easy use of Struts in portal servers that will support the emerging portlet API (JSR-168). You've also heard Ted and others talk about the need for a good controller paradigm in the business tier as well as the view tier. We know how to build such a thing :-). * I'm interested in continuing to support Struts users that cannot drop everything and instantly move to the latest and greatest API versions. For example, it's still way way way too early to think about Struts 1.2 being based on Servlet 2.4 and JSP 2.0 (the
DO NOT REPLY [Bug 17299] - Page variable not set on DynaValidatorForms for mutlipage validations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17299. 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=17299 Page variable not set on DynaValidatorForms for mutlipage validations --- Additional Comments From [EMAIL PROTECTED] 2003-03-01 19:30 --- Yes, I defined the form property in the struts-config as an Integer and also tried int and the DYNAMIC property in the backed Map gets set, but the problem is that the setter method directly on the DynaValidatorForm object, setPage (int), never gets called. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
Craig R. McClanahan wrote: http://www.geocities.com/fullback_21_csca/index5.htmlhttp://www.geocities.com/fullback_21_csca/index5.htmlhttp://www.geocities.com/fullback_21_csca/index5.html * I'm interested in decoupling the controller part of Struts from its current heavy reliance on the Servlet APIs. Among other things, that would enable easy use of Struts in portal servers that will support the emerging portlet API (JSR-168). You've also heard Ted and others talk about the need for a good controller paradigm in the business tier as well as the view tier. We know how to build such a thing :-). Yes we do! The more I think about it the more I'm convinced that Struts is a primarily a very effective application framework, that just happened to use web apps for its first implementation. We just need to continue to abstract out the HTTP semantics (as we did for Messages) and expose the framework within. Another good example is the pluggable Request Processor. I could easly see this same object model applied to a business architechture. You wouldn't use a HTTP request, but you could pass around a business context for the same purpose (a la Velocity). Likewise for the response and a CommandMapping (err, ActionMapping). I find that the whole command/semaphore thing that Struts uses with the ActionMapping and ActionForwards works just as well on the business layer. Success is success. The business controller can decide *what* to do, and the Struts controller can *map* that to where the JSP lives. (Standard obit, navigator.) The business layer can define what commands it may pass back (success, failure, annualReport) and then its up to the presentation to decide which pages relate to those commands. IMHO, in the end, a lot us will be building business applications using components from the Commons, and then just exposing that application to Struts for the web-layer stuff. Most of the Struts sub-systems, like validation, messaging, workflow, data access, can (and do) live at the business layer. Our business applications won't use the Struts ApplicationResources: Struts will use business layer's ApplicationResources. A key pattern underlying Struts, and most of the other HTTP application frameworks, is the idea of deploying an object-web from a XML document. Right now, our servlet has two major responsibilities. * Process requests * Deploy the object-web The former responsibility is now fulfilled by the Request Processor. It might be interesting to look at abstracting the Deployment Processor into a pluggable object (or even a sub-framework). Right now, there are a lot of people reading in DTDs and deploying object-webs (including us - for Tiles and the Validator). There would seem to be a need for some type of base processor object, with handy extension points, that could be plugged into a servlet as needed. This could also make it a lot easier for teams to plug-in their own configs and deploy their own object webs. I still need to look and see how Cedric does it, but I think the idea of getting XML elements to extend each other is very imporant. We should be able to do with in all of our config files, and open up the capability for other products as well. While there's been some pressure to build more elements into the struts-config, I would argue that we need to go the other way. We need to be able to share things like validations with the businesss layer. Separate config files for discrete components reduces coupling and increases coherence. The real solution here is better tools. The Struts Console already reads struts-config and validator files. It's easy to envision a tool like this that could read in multiple configs and provide a single view to the developer. And there's a bunch a ways we could make something like the Console a very cool way to write these documents (picklists for valid options, dynamic picklists of most often used values, and so forth). The endgame would be if one Common Console could also read Hibernate and OJB configs, and maybe even help us synch DynaBeans with the data beans. Not to mention editing JXUnit files to create unit testing scripts, or, gosh, Ant buildfiles. Back on the homefront, we already fixed a number of design issues in 1.1. Two remaining hotspots seem to be * Uneven use of the action/page/path properties, * Presumption that ActionServet is the one-and-only ActionServlet, and * Action lock-in action/page/path We added the action property to the link tag in 1.1 (head-slap/). This small change makes a *huge* difference in clarifying the original intent of the API. It may also be helpful to add action to ActionForward and deprecate path in favor of page, to agree with the taglibs (and remove the semantic conflict with ActionMapping.path). We might also think about whether ActionMapping.input should be able to indicate another action. (Since many applications use page controllers to seed the
Re: Short term plans
How about we solve the 7 remaining 1.1 bugs first ;-). Dave From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Short term plans Date: Sat, 01 Mar 2003 17:56:04 -0500 Craig R. McClanahan wrote: My personal preferences on the immediate future are to make Struts 1.2 an evolutionary path for existing 1.0 and 1.1 users, but adopt a release often model of 1.2.x releases like what the Apache HTTPD server does, and what Tomcat 4.1 and 5.0 have adopted -- release a new milestone when you've added a new feature or two, or fixed enough bugs to be worthwhile. For 1.2, how about if we finish the Commons-Resources migration, along with whatever api/bug-fixes turn up in the meantime, and call it a release? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Slow encode method -- patch included
This patch fixes an incredibly inefficient, often-used encodeURL method.
The merits of the patch should be self-evident --
1) it preserves the original goal of using the jdk 1.4's encode if
available, while
2) it does not call 2 java encode method each time and
3) it does not do so much reflection each time around
Let me know of any concerns,
Zorzella
Index: src/share/org/apache/struts/util/RequestUtils.java
===
RCS file:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java,v
retrieving revision 1.90
diff -u -r1.90 RequestUtils.java
--- src/share/org/apache/struts/util/RequestUtils.java 26 Feb 2003 04:48:56 -
1.90
+++ src/share/org/apache/struts/util/RequestUtils.java 1 Mar 2003 23:23:00 -
@@ -1896,6 +1896,19 @@
return errors;
}
+private static Method _encode = null;
+
+static {
+try {
+// get version of encode method with two String args
+Class[] args = new Class[] { String.class, String.class };
+_encode = URLEncoder.class.getMethod(encode, args);
+ } catch (Exception e) {
+log.debug(Could not find Java 1.4 encode method. Using deprecated
version., e);
+ }
+}
+
+
/**
* Use the new URLEncoder.encode() method from java 1.4 if available, else
* use the old deprecated version. This method uses reflection to find the
appropriate
@@ -1904,27 +1917,15 @@
* @return String - the encoded url.
*/
public static String encodeURL(String url) {
-// default to old version
-String encodedURL = URLEncoder.encode(url);
-Class encoderClass = URLEncoder.class;
try {
-// get version of encode method with two String args
-Class[] args = new Class[] { String.class, String.class };
-Method encode = encoderClass.getMethod(encode, args);
-
-// encode url with new 1.4 method and UTF-8 encoding
-encodedURL = (String) encode.invoke(null, new Object[] { url, UTF-8 });
-
-} catch (IllegalAccessException e) {
-log.debug(Could not find Java 1.4 encode method. Using deprecated
version., e);
-} catch (InvocationTargetException e) {
-log.debug(Could not find Java 1.4 encode method. Using deprecated
version., e);
-} catch (NoSuchMethodException e) {
+if (_encode == null)
+return (String) _encode.invoke(null, new Object[] { url, UTF-8 });
+} catch (Exception e) {
log.debug(Could not find Java 1.4 encode method. Using deprecated
version., e);
}
-
-return encodedURL;
+
+return URLEncoder.encode(url);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Short term plans
+1 for both -- James Mitchell Web Developer/Struts Evangelist http://jakarta.apache.org/struts/ People demand freedom of speech to make up for the freedom of thought which they avoid. - Soren Aabye Kierkegaard (1813-1855) -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Saturday, March 01, 2003 6:08 PM To: [EMAIL PROTECTED] Subject: Re: Short term plans How about we solve the 7 remaining 1.1 bugs first ;-). Dave From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Short term plans Date: Sat, 01 Mar 2003 17:56:04 -0500 Craig R. McClanahan wrote: My personal preferences on the immediate future are to make Struts 1.2 an evolutionary path for existing 1.0 and 1.1 users, but adopt a release often model of 1.2.x releases like what the Apache HTTPD server does, and what Tomcat 4.1 and 5.0 have adopted -- release a new milestone when you've added a new feature or two, or fixed enough bugs to be worthwhile. For 1.2, how about if we finish the Commons-Resources migration, along with whatever api/bug-fixes turn up in the meantime, and call it a release? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - 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: Slow encode method -- patch included
Sorry -- I hit a tiny typo there. Correct patch included.
Luiz-Otavio Zorzella wrote:
This patch fixes an incredibly inefficient, often-used encodeURL method.
The merits of the patch should be self-evident --
1) it preserves the original goal of using the jdk 1.4's encode if
available, while
2) it does not call 2 java encode method each time and
3) it does not do so much reflection each time around
Let me know of any concerns,
Zorzella
Index: src/share/org/apache/struts/util/RequestUtils.java
===
RCS file: /home/cvspublic/jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java,v
retrieving revision 1.90
diff -u -r1.90 RequestUtils.java
--- src/share/org/apache/struts/util/RequestUtils.java 26 Feb 2003 04:48:56 - 1.90
+++ src/share/org/apache/struts/util/RequestUtils.java 1 Mar 2003 23:23:00 -
@@ -1896,6 +1896,19 @@
return errors;
}
+private static Method _encode = null;
+
+static {
+try {
+// get version of encode method with two String args
+Class[] args = new Class[] { String.class, String.class };
+_encode = URLEncoder.class.getMethod(encode, args);
+ } catch (Exception e) {
+log.debug(Could not find Java 1.4 encode method. Using deprecated version., e);
+ }
+}
+
+
/**
* Use the new URLEncoder.encode() method from java 1.4 if available, else
* use the old deprecated version. This method uses reflection to find the appropriate
@@ -1904,27 +1917,15 @@
* @return String - the encoded url.
*/
public static String encodeURL(String url) {
-// default to old version
-String encodedURL = URLEncoder.encode(url);
-Class encoderClass = URLEncoder.class;
try {
-// get version of encode method with two String args
-Class[] args = new Class[] { String.class, String.class };
-Method encode = encoderClass.getMethod(encode, args);
-
-// encode url with new 1.4 method and UTF-8 encoding
-encodedURL = (String) encode.invoke(null, new Object[] { url, UTF-8 });
-
-} catch (IllegalAccessException e) {
-log.debug(Could not find Java 1.4 encode method. Using deprecated version., e);
-} catch (InvocationTargetException e) {
-log.debug(Could not find Java 1.4 encode method. Using deprecated version., e);
-} catch (NoSuchMethodException e) {
+if (_encode == null)
+return (String) _encode.invoke(null, new Object[] { url, UTF-8 });
+} catch (Exception e) {
log.debug(Could not find Java 1.4 encode method. Using deprecated version., e);
}
-
-return encodedURL;
+
+return URLEncoder.encode(url);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: src/share/org/apache/struts/util/RequestUtils.java
===
RCS file:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java,v
retrieving revision 1.90
diff -u -r1.90 RequestUtils.java
--- src/share/org/apache/struts/util/RequestUtils.java 26 Feb 2003 04:48:56 -
1.90
+++ src/share/org/apache/struts/util/RequestUtils.java 1 Mar 2003 23:37:19 -
@@ -1896,6 +1896,19 @@
return errors;
}
+private static Method _encode = null;
+
+static {
+try {
+// get version of encode method with two String args
+Class[] args = new Class[] { String.class, String.class };
+_encode = URLEncoder.class.getMethod(encode, args);
+ } catch (Exception e) {
+log.debug(Could not find Java 1.4 encode method. Using deprecated
version., e);
+ }
+}
+
+
/**
* Use the new URLEncoder.encode() method from java 1.4 if available, else
* use the old deprecated version. This method uses reflection to find the
appropriate
@@ -1904,27 +1917,15 @@
* @return String - the encoded url.
*/
public static String encodeURL(String url) {
-// default to old version
-String encodedURL = URLEncoder.encode(url);
-Class encoderClass = URLEncoder.class;
try {
-// get version of encode method with two String args
-Class[] args = new Class[] { String.class, String.class };
-Method encode = encoderClass.getMethod(encode, args);
-
-// encode url with new 1.4 method and UTF-8 encoding
-encodedURL = (String) encode.invoke(null, new Object[] { url, UTF-8 });
-
-} catch (IllegalAccessException e) {
-
Re: Short term plans
On Sat, 1 Mar 2003, Ted Husted wrote: Date: Sat, 01 Mar 2003 17:56:04 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Short term plans Craig R. McClanahan wrote: My personal preferences on the immediate future are to make Struts 1.2 an evolutionary path for existing 1.0 and 1.1 users, but adopt a release often model of 1.2.x releases like what the Apache HTTPD server does, and what Tomcat 4.1 and 5.0 have adopted -- release a new milestone when you've added a new feature or two, or fixed enough bugs to be worthwhile. For 1.2, how about if we finish the Commons-Resources migration, along with whatever api/bug-fixes turn up in the meantime, and call it a release? That by itself would certainly be enough for a 1.2.0, but there's a bunch of other things we've deferred that would make sense in the 1.2.x lifetime. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java
dgraham 2003/03/01 16:22:40
Modified:src/share/org/apache/struts/util RequestUtils.java
Log:
Change encodeURL to not use reflection on every call.
Revision ChangesPath
1.91 +26 -15
jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java
Index: RequestUtils.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java,v
retrieving revision 1.90
retrieving revision 1.91
diff -u -r1.90 -r1.91
--- RequestUtils.java 26 Feb 2003 04:48:56 - 1.90
+++ RequestUtils.java 2 Mar 2003 00:22:40 - 1.91
@@ -142,6 +142,24 @@
* The context attribute under which we store our prefixes list.
*/
private static final String PREFIXES_KEY = org.apache.struts.util.PREFIXES;
+
+/**
+ * Java 1.4 encode method to use instead of deprecated 1.3 version.
+ */
+private static Method encode = null;
+
+/**
+ * Initialize the encode variable with the 1.4 method if available
+ */
+static {
+try {
+// get version of encode method with two String args
+Class[] args = new Class[] { String.class, String.class };
+encode = URLEncoder.class.getMethod(encode, args);
+} catch (NoSuchMethodException e) {
+log.debug(Could not find Java 1.4 encode method. Using deprecated
version., e);
+}
+}
// - Public Methods
@@ -1904,27 +1922,20 @@
* @return String - the encoded url.
*/
public static String encodeURL(String url) {
-// default to old version
-String encodedURL = URLEncoder.encode(url);
-Class encoderClass = URLEncoder.class;
-
try {
-// get version of encode method with two String args
-Class[] args = new Class[] { String.class, String.class };
-Method encode = encoderClass.getMethod(encode, args);
// encode url with new 1.4 method and UTF-8 encoding
-encodedURL = (String) encode.invoke(null, new Object[] { url, UTF-8
});
+if (encode != null) {
+return (String) encode.invoke(null, new Object[] { url, UTF-8 });
+}
} catch (IllegalAccessException e) {
log.debug(Could not find Java 1.4 encode method. Using deprecated
version., e);
} catch (InvocationTargetException e) {
log.debug(Could not find Java 1.4 encode method. Using deprecated
version., e);
-} catch (NoSuchMethodException e) {
-log.debug(Could not find Java 1.4 encode method. Using deprecated
version., e);
}
-return encodedURL;
+return URLEncoder.encode(url);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slow encode method -- patch included
I've made the changes.
A couple things:
1. Please post patches to bugzilla tickets.
2. We adhere to the standard Java coding guidelines which prohibit
underscores except in constants.
3. Your if statement should have been (encode != null)
David
From: Luiz-Otavio Zorzella [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Slow encode method -- patch included
Date: Sat, 01 Mar 2003 15:39:10 -0800
Sorry -- I hit a tiny typo there. Correct patch included.
Luiz-Otavio Zorzella wrote:
This patch fixes an incredibly inefficient, often-used encodeURL method.
The merits of the patch should be self-evident --
1) it preserves the original goal of using the jdk 1.4's encode if
available, while
2) it does not call 2 java encode method each time and
3) it does not do so much reflection each time around
Let me know of any concerns,
Zorzella
Index: src/share/org/apache/struts/util/RequestUtils.java
===
RCS file:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java,v
retrieving revision 1.90
diff -u -r1.90 RequestUtils.java
--- src/share/org/apache/struts/util/RequestUtils.java 26 Feb 2003
04:48:56 - 1.90
+++ src/share/org/apache/struts/util/RequestUtils.java 1 Mar 2003 23:23:00
-
@@ -1896,6 +1896,19 @@
return errors;
}
+private static Method _encode = null;
+
+static {
+try {
+// get version of encode method with two String args
+Class[] args = new Class[] { String.class, String.class };
+_encode = URLEncoder.class.getMethod(encode, args);
+ } catch (Exception e) {
+log.debug(Could not find Java 1.4 encode method. Using
deprecated version., e);
+ }
+}
+
+ /**
* Use the new URLEncoder.encode() method from java 1.4 if
available, else
* use the old deprecated version. This method uses reflection to
find the appropriate
@@ -1904,27 +1917,15 @@
* @return String - the encoded url.
*/
public static String encodeURL(String url) {
-// default to old version
-String encodedURL = URLEncoder.encode(url);
-Class encoderClass = URLEncoder.class;
try {
-// get version of encode method with two String args
-Class[] args = new Class[] { String.class, String.class };
-Method encode = encoderClass.getMethod(encode, args);
-
-// encode url with new 1.4 method and UTF-8 encoding
-encodedURL = (String) encode.invoke(null, new Object[] { url,
UTF-8 });
-
-} catch (IllegalAccessException e) {
-log.debug(Could not find Java 1.4 encode method. Using
deprecated version., e);
-} catch (InvocationTargetException e) {
-log.debug(Could not find Java 1.4 encode method. Using
deprecated version., e);
-} catch (NoSuchMethodException e) {
+if (_encode == null)
+return (String) _encode.invoke(null, new Object[] { url,
UTF-8 });
+} catch (Exception e) {
log.debug(Could not find Java 1.4 encode method. Using
deprecated version., e);
}
-
-return encodedURL;
++return URLEncoder.encode(url);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: src/share/org/apache/struts/util/RequestUtils.java
===
RCS file:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java,v
retrieving revision 1.90
diff -u -r1.90 RequestUtils.java
--- src/share/org/apache/struts/util/RequestUtils.java 26 Feb 2003 04:48:56
- 1.90
+++ src/share/org/apache/struts/util/RequestUtils.java 1 Mar 2003 23:37:19
-
@@ -1896,6 +1896,19 @@
return errors;
}
+private static Method _encode = null;
+
+static {
+try {
+// get version of encode method with two String args
+Class[] args = new Class[] { String.class, String.class };
+_encode = URLEncoder.class.getMethod(encode, args);
+ } catch (Exception e) {
+log.debug(Could not find Java 1.4 encode method. Using
deprecated version., e);
+ }
+}
+
+
/**
* Use the new URLEncoder.encode() method from java 1.4 if available,
else
* use the old deprecated version. This method uses reflection to
find the appropriate
@@ -1904,27 +1917,15 @@
* @return String - the encoded url.
*/
public static String encodeURL(String url) {
-// default to old version
-String encodedURL = URLEncoder.encode(url);
-Class
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/utilRequestUtils.java
On Sat, 2 Mar 2003 [EMAIL PROTECTED] wrote:
Date: 2 Mar 2003 00:22:40 -
From: [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/util
RequestUtils.java
dgraham 2003/03/01 16:22:40
Modified:src/share/org/apache/struts/util RequestUtils.java
Log:
Change encodeURL to not use reflection on every call.
Note that this change imposes a 1.4 dependency to build Struts. That
would be OK with *me* (since I use 1.4 all the time), but may not be OK
with other folks.
Craig
Revision ChangesPath
1.91 +26 -15
jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java
Index: RequestUtils.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java,v
retrieving revision 1.90
retrieving revision 1.91
diff -u -r1.90 -r1.91
--- RequestUtils.java 26 Feb 2003 04:48:56 - 1.90
+++ RequestUtils.java 2 Mar 2003 00:22:40 - 1.91
@@ -142,6 +142,24 @@
* The context attribute under which we store our prefixes list.
*/
private static final String PREFIXES_KEY = org.apache.struts.util.PREFIXES;
+
+/**
+ * Java 1.4 encode method to use instead of deprecated 1.3 version.
+ */
+private static Method encode = null;
+
+/**
+ * Initialize the encode variable with the 1.4 method if available
+ */
+static {
+try {
+// get version of encode method with two String args
+Class[] args = new Class[] { String.class, String.class };
+encode = URLEncoder.class.getMethod(encode, args);
+} catch (NoSuchMethodException e) {
+log.debug(Could not find Java 1.4 encode method. Using deprecated
version., e);
+}
+}
// - Public Methods
@@ -1904,27 +1922,20 @@
* @return String - the encoded url.
*/
public static String encodeURL(String url) {
-// default to old version
-String encodedURL = URLEncoder.encode(url);
-Class encoderClass = URLEncoder.class;
-
try {
-// get version of encode method with two String args
-Class[] args = new Class[] { String.class, String.class };
-Method encode = encoderClass.getMethod(encode, args);
// encode url with new 1.4 method and UTF-8 encoding
-encodedURL = (String) encode.invoke(null, new Object[] { url, UTF-8
});
+if (encode != null) {
+return (String) encode.invoke(null, new Object[] { url, UTF-8
});
+}
} catch (IllegalAccessException e) {
log.debug(Could not find Java 1.4 encode method. Using deprecated
version., e);
} catch (InvocationTargetException e) {
log.debug(Could not find Java 1.4 encode method. Using deprecated
version., e);
-} catch (NoSuchMethodException e) {
-log.debug(Could not find Java 1.4 encode method. Using deprecated
version., e);
}
-return encodedURL;
+return URLEncoder.encode(url);
}
}
-
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/utilRequestUtils.java
How is it any different than the way it was implemented before? If it
doesn't find the 1.4 method it uses the 1.3 method.
David
From: Craig R. McClanahan [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: cvs commit: jakarta-struts/src/share/org/apache/struts/util
RequestUtils.java
Date: Sat, 1 Mar 2003 16:42:21 -0800 (PST)
On Sat, 2 Mar 2003 [EMAIL PROTECTED] wrote:
Date: 2 Mar 2003 00:22:40 -
From: [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/util
RequestUtils.java
dgraham 2003/03/01 16:22:40
Modified:src/share/org/apache/struts/util RequestUtils.java
Log:
Change encodeURL to not use reflection on every call.
Note that this change imposes a 1.4 dependency to build Struts. That
would be OK with *me* (since I use 1.4 all the time), but may not be OK
with other folks.
Craig
Revision ChangesPath
1.91 +26 -15
jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java
Index: RequestUtils.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java,v
retrieving revision 1.90
retrieving revision 1.91
diff -u -r1.90 -r1.91
--- RequestUtils.java 26 Feb 2003 04:48:56 - 1.90
+++ RequestUtils.java 2 Mar 2003 00:22:40 - 1.91
@@ -142,6 +142,24 @@
* The context attribute under which we store our prefixes list.
*/
private static final String PREFIXES_KEY =
org.apache.struts.util.PREFIXES;
+
+/**
+ * Java 1.4 encode method to use instead of deprecated 1.3
version.
+ */
+private static Method encode = null;
+
+/**
+ * Initialize the encode variable with the 1.4 method if
available
+ */
+static {
+try {
+// get version of encode method with two String args
+Class[] args = new Class[] { String.class, String.class
};
+encode = URLEncoder.class.getMethod(encode, args);
+} catch (NoSuchMethodException e) {
+log.debug(Could not find Java 1.4 encode method. Using
deprecated version., e);
+}
+}
// -
Public Methods
@@ -1904,27 +1922,20 @@
* @return String - the encoded url.
*/
public static String encodeURL(String url) {
-// default to old version
-String encodedURL = URLEncoder.encode(url);
-Class encoderClass = URLEncoder.class;
-
try {
-// get version of encode method with two String args
-Class[] args = new Class[] { String.class, String.class
};
-Method encode = encoderClass.getMethod(encode, args);
// encode url with new 1.4 method and UTF-8 encoding
-encodedURL = (String) encode.invoke(null, new Object[] {
url, UTF-8 });
+if (encode != null) {
+return (String) encode.invoke(null, new Object[] {
url, UTF-8 });
+}
} catch (IllegalAccessException e) {
log.debug(Could not find Java 1.4 encode method. Using
deprecated version., e);
} catch (InvocationTargetException e) {
log.debug(Could not find Java 1.4 encode method. Using
deprecated version., e);
-} catch (NoSuchMethodException e) {
-log.debug(Could not find Java 1.4 encode method. Using
deprecated version., e);
}
-return encodedURL;
+return URLEncoder.encode(url);
}
}
-
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]
_
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Commons Validator
Would it bother any of you validator folks if I added myself to the status file of commons validator and committed a fix? I thought it would be polite to ask first :-). Dave _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
The sentiments are good but the reality is sometimes different. I submitted two sets of logic tags in May 2001 which provided switch/case and if/and/or/else logic. They were basically wrappers for the existing struts logic tags. They were rejected at the time because the JSTL would be providing the same functionality - even though these tags worked in 2.2/1.1 and JSTL required 2.3/1.2. Funnily enough they were even on the TODO list at the time!!! So even though 1) * I wanted it * 2) * Other people wanted it * and 3) * I provided them * - it wasn't enough to get them included in Struts. Another thing was, although these logic tags were rejected the Empty and NotEmpty tags were added to Struts afterwards!! I guess the #1 requirement for anyone submitting to struts is can I get a committer to take any interest? Niall TED But to answer your question, I think the litmus test would be whether TED there is a working patch annexed. TED TED All anyone has said is that since the attention of the Committers in TED their own work is likely to be on other technologies, it is equally likely TED that the Committers won't be spending their *own* development time TED *creating* patches. TED TED As long as the change has technical merit, and a Committer is willing TED to take responsbility for the patch, we won't/can't veto something TED becomes of competition from JSTL/JSF/XLST/Velocity/Tapestry/lord-knows. CRAIG At JavaOne US 2002 (March 2002) I did a survey of the folks that came to CRAIG the Struts Community BOF. Over half the people there were developing and CRAIG deploying on J2EE 1.2 (i.e. Servlet 2.2 and JSP 1.1) platforms. Yes, it's CRAIG almost a year later now, but the situation has not *totally* changed. CRAIG CRAIG JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3 CRAIG and JSP 1.2, so they are not even an option for a very significant portion CRAIG of the Struts user community. CRAIG I think there are multiple perspectives for asking for enhancements, CRAIG all of them valid. Some examples: CRAIG CRAIG * I need it -- This particular feature would help me . . . CRAIG CRAIG * Lots of people need it . . .useful to lots of people using an existing version of Struts ... CRAIG CRAIG * I want to work on it . . .nothing stops us from adding some more CRAIGdevelopers that want to continue to enhance the existing tags. CRAIG CRAIG NOTE -- this perspective is the most critical for actually getting anything done :-). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
moving to commons-resources: design/implementation questions
I have a basic version of MessageResources working on top of the commons-resources package. There are some things that I want to review with the team before I submit patches. 1. implementation approach. The approach I took for implementation was to implement a new subclass of o.a.s.u.MessageResources/MessageResourcesFactory, and change the default factory class in MessageResourcesFactory to use the new subclass. This allows us to hook in the new class, but allows existing subclasses of PropertyMessageResources/PropertyMessageResourcesFactory will continue to work without any changes. Comments? 2. o.a.commons.resource.ResourceFactory.getResources() has a name parameter that is the logical name for the resources. I don't have a sense of what sort of name makes sense here, and whether it can be a constant or needs a getter/setter (some work involved in that too). 3. I hardcoded my implementation to use the o.a.commons.resources.impl.PropertyResourcesFactory, rather than discovering it through the ResourcesFactoryFinder. Since this is intended to be a plug-in replacement for the current property based resources, is this OK? 4. Poking through the code and trying it out, it does not appear that the o.a.c.r.impl.PropertyResourcesFactory.createResources() method supports the classloader-based approach to locating property files that was implemented in o.a.s.u.PropertyMessageResources.loadLocale(). It wants a URL really, really bad. This means that Messages message = Messages.getMessages(org.apache.struts.taglib.bean); doesn't work. Ideas? 5. When given a null locale, o.a.c.r.Messages.getMessage() tries to append en_US to the spec for the properties file, rather than reading the base property file as the current implementation does. Is that something to change in Messages? 6. o.a.c.r.Messages.getMessage() returns an undocumented string when can't find a specified resource. To support the returnNull property semantics on o.a.s.u.MessageResources, I need to be able to tell when the resource isn't found. It seems like one of these options should be selected: . expose the return string so that it can be tested for (ugh...) . add a messageExists() method on Messages to allow for a test for a null return (would have to call it every time through) . change the semantics of getMessage() to return null when the underlying message resource isn't found . implement the returnNull() property on Message to allow the behavior to be configured. I think that's everything on my list right now. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
