RE: Disadvantages of Struts?

2003-12-03 Thread Rick Hightower 
I don't want to clog up the dev list with a philosophical debate (however
well meaning on Robert's part); no offense intended. I will have to try
harder to avoid such bait in the future. I was being facetious (Playfully
jocular; humorous: facetious remarks), when I said Struts is perfect.

I use Struts and find it useful for projects that I have worked on. It is
not perfect, nor have I found a framework that was perfect. However, I do
not wish to defend it (time is money). Next time you are in Tucson AZ, we
can grab a beer (or coffee) and discuss the finer points at length.

I am going to go with the other well thought out responses and say this
question belongs on the user list.

I will not respond to this thread any longer. My apologies for continuing
this thread on the dev list.

-Original Message-
From: Robert H. Tran [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 03, 2003 6:29 PM
To: Struts Developers List
Subject: Re: Disadvantages of Struts?

I am not sure that is true. Struts seems to lack of an API. IMO, there are
more required configurations than necessary. Take Action for example, to
write an Action, one has to paddle back and forth between the code and the
configuration. It is like an executable having to configure each of its
dlls. The visibility of the mappings is nice to have but the mappings can
be generated after the fact as in a debugging view. When the application is
finished, configurations become static. But since configurations are
required, they will be like loose ends of the application. Another issue:
how can one componentize his code and deploy it in a self-contained plug-in,
as with Eclipse? Please forgive my novice.

- Robert.

- Original Message - 
From: "Rick Hightower" <[EMAIL PROTECTED]>
To: "'Struts Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, December 03, 2003 6:24 PM
Subject: RE: Disadvantages of Struts?


> Don't be silly. Struts is perfect.
>
> -Original Message-
> From: Robert H. Tran [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 03, 2003 2:10 PM
> To: Struts Developers List
> Subject: Disadvantages of Struts?
>
> I just wonder if Struts comes with any significant drawback. I mean not in
> terms of when to use Struts and when not to use it necessarily, but more
in
> the line of anyone's wishes that it had been better. Any advice is very
> appreciated.
>
> - Robert.
>
> -
> 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]



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

RE: Should Struts ship with all of the commons jar files needed to get Struts datasources working?

2003-12-03 Thread Rick Hightower 
I was following the database faq.
http://jakarta.apache.org/struts/faqs/database.html

I was using the BasicDataSource from dbcp as the GenericDataSource is
deprecated. They faq suggests using the BasicDataSource, which depends on
commons-pooling and commons-dbcp.

Thank you for your help. I appreciate it. I was told that someone updated
the faq with my commnents so all is well.

-Original Message-
From: Steve Raeburn [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 03, 2003 2:57 PM
To: Struts Developers List
Subject: RE: Should Struts ship with all of the commons jar files needed to
get Struts datasources working?

Rick,
What DataSource are you trying to set-up? GenericDatSource in
struts-legacy.jar is independent of DBCP so you shouldn't need those
jars.

The following configuration works for me, even when I remove
commons-dbcp and commons-pooling jars from tomcat (4.1.29)

  




  

You don't really need the type property, since GenericDataSource is the
default.

Steve

> -Original Message-
> From: Rick Hightower [mailto:[EMAIL PROTECTED]
> Sent: December 3, 2003 2:20 PM
> To: 'Struts Developers List'
> Subject: Should Struts ship with all of the commons jar files
> needed to
> get Struts datasources working?
>
>
> Currently 1.1 does not ship with commons jar files needed to
> get Struts
> datasources working.
>
>
>
> You need booth commons-pooling and commons-dbcp to get Struts
> Datasources to
> work, but they are *not* included with Struts 1.1. (In fact
> in Struts 1.1.,
> you also need Struts Legacy jar file as well.)
>
>
>
> I think this got through because if you are using Tomcat then both
> commons-pooling and commons-dbcp ship in the shared folder.
> You do need to
> download them if you are using another application server.
> You do need to
> download them only if you are going to use Struts Datasources. My
> understanding was that Struts would ship with the entire set
> of commons jar
> files needed to utilize all of the features of Struts. Are
> Struts Datasource
> EOL or something?
>
>
>
>
>
>
>
> Rick Hightower
>
> Chief Technology Officer
>
> ArcMind
>
> Know the Next!
>
> http://www.arc-mind.com <http://www.arc-mind.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]

RE: Disadvantages of Struts?

2003-12-03 Thread Rick Hightower 
Don't be silly. Struts is perfect. 

-Original Message-
From: Robert H. Tran [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 03, 2003 2:10 PM
To: Struts Developers List
Subject: Disadvantages of Struts?

I just wonder if Struts comes with any significant drawback. I mean not in
terms of when to use Struts and when not to use it necessarily, but more in
the line of anyone's wishes that it had been better. Any advice is very
appreciated.

- Robert.

-
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: Should Struts ship with all of the commons jar files needed to get Struts datasources working?

2003-12-03 Thread Rick Hightower 


I agree with them being deprecated. I always wondered why Struts had its own
way of doing connection pools. 

Although it is convienient in the sense that every app server has a
different way of creating a connection pool. At least with Struts you could
write an application that did not need different connection pool
configuration for every app server.
 

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Vic Cekvenich
Sent: Wednesday, December 03, 2003 1:43 PM
To: [EMAIL PROTECTED]
Subject: Re: Should Struts ship with all of the commons jar files needed to
get Struts datasources working?

Hello Rick,

They are deprecated; targeted for removal; and for a good reason, since 
it's a bad practice to have a data source served by the web app., a 
container provides a data source. In esence, maybe legacy jar should not 
be included any more, it has been a while since 1.1 released.
There is to much talk about data connection's as it is on user.

(I wish more be taged as deprected :logic/bean, since in the future... 
they will be and there was a comment on dev list that no one is keen to 
patch, so just give users a signal )

.V

Rick Hightower wrote:
> Currently 1.1 does not ship with commons jar files needed to get Struts
> datasources working.
> 
>  
> 
> You need booth commons-pooling and commons-dbcp to get Struts Datasources
to
> work, but they are *not* included with Struts 1.1. (In fact in Struts
1.1.,
> you also need Struts Legacy jar file as well.)
> 
>  
> 
> I think this got through because if you are using Tomcat then both
> commons-pooling and commons-dbcp ship in the shared folder. You do need to
> download them if you are using another application server. You do need to
> download them only if you are going to use Struts Datasources. My
> understanding was that Struts would ship with the entire set of commons
jar
> files needed to utilize all of the features of Struts. Are Struts
Datasource
> EOL or something?
> 
>  
> 
>  
> 
>  
> 
> Rick Hightower
> 
> Chief Technology Officer
> 
> ArcMind
> 
> Know the Next!
> 
> http://www.arc-mind.com <http://www.arc-mind.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]

RE: Should Struts ship with all of the commons jar files needed to get Struts datasources working?

2003-12-03 Thread Rick Hightower 
Ya know. I was just starting to warm up to the idea for that very reason. It
is a pain to configure DB connection pools for every app server.



-Original Message-
From: Edgar P Dollin [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 03, 2003 2:03 PM
To: 'Struts Developers List'
Subject: RE: Should Struts ship with all of the commons jar files needed to
get Struts datasources working?

I disagree about the web app containing the DB Pool as configuration of
multiple DB Pools in a container containing many different apps is a royal
pain, not to mention a potential source of downtime for unrelated users.

Please don't remove this feature.  Leave it depreated as long as you like.

Thanks

Edgar


-Original Message-
From: Vic Cekvenich [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 4:43 PM
To: [EMAIL PROTECTED]
Subject: Re: Should Struts ship with all of the commons jar files needed
to get Struts datasources working?


Hello Rick,

They are deprecated; targeted for removal; and for a good reason, since 
it's a bad practice to have a data source served by the web app., a 
container provides a data source. In esence, maybe legacy jar should not 
be included any more, it has been a while since 1.1 released.
There is to much talk about data connection's as it is on user.

(I wish more be taged as deprected :logic/bean, since in the future... 
they will be and there was a comment on dev list that no one is keen to 
patch, so just give users a signal )

.V


-
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]

Should Struts ship with all of the commons jar files needed to get Struts datasources working?

2003-12-03 Thread Rick Hightower 
Currently 1.1 does not ship with commons jar files needed to get Struts
datasources working.

 

You need booth commons-pooling and commons-dbcp to get Struts Datasources to
work, but they are *not* included with Struts 1.1. (In fact in Struts 1.1.,
you also need Struts Legacy jar file as well.)

 

I think this got through because if you are using Tomcat then both
commons-pooling and commons-dbcp ship in the shared folder. You do need to
download them if you are using another application server. You do need to
download them only if you are going to use Struts Datasources. My
understanding was that Struts would ship with the entire set of commons jar
files needed to utilize all of the features of Struts. Are Struts Datasource
EOL or something?

 

 

 

Rick Hightower

Chief Technology Officer

ArcMind

Know the Next!

http://www.arc-mind.com <http://www.arc-mind.com/>

Datasource, DBCP documentation woes, suggested documentation fix

2003-12-02 Thread Rick Hightower 
You need booth commons-pooling and commons-dbcp to get Struts Datasources to
work, but this is not mentioned in the documentation and the required jar
files do not ship with Blank.war. In fact in Struts 1.1., you also need
Struts Legacy jar file as well. Of course, if you are using Tomcat then both
commons-pooling and commons-dbcp ship in the shared folder but you do need
to download them if you are using another application server. You do need to
download them if you are going to use Struts Datasources.

 

I think either

http://jakarta.apache.org/struts/userGuide/configuration.html#data-source_co
nfig

 

or 

 

http://jakarta.apache.org/struts/faqs/database.html

 

should make note of this.

 

Here is a stab at it.

 

Struts Datasources require commons-pooling and commons-dbcp. The blank.war
does not have commons-pooling or commons-dbcp. If you want to use Struts
datasource, you will need to download commons-pooling and commons-dbcp from
the following locations:

 

http://jakarta.apache.org/site/binindex.cgi#commons-dbcp

http://jakarta.apache.org/site/binindex.cgi#commons-pool

 

 

Download the above archives and un-archive them. Then copy the jar files
commons-pool-1.1.jar, and commons-dbcp-1.1.jar into the WEB-INF/lib
directory of your web application. Note that Tomcat 5 ships with
commons-dbcp and commons-pool so you do not need to download and install
commons-dbcp and commons-pool if you are using Tomcat.

 

In addition to the above two jar files, you will need to use the
struts-legacy.jar jar file that ships with Struts 1.1. Copy the
struts-legacy.jar file to the WEB-INF/lib directory of your web application.

 

This might be a moot point depending on how soon Struts 1.2 comes out, and
if commons-pooling and commons-dbcp ship with Struts.

 

Rick Hightower

Chief Technology Officer

ArcMind

"Know the Next!"

http://www.arc-mind.com <http://www.arc-mind.com/> 

520 290 6855 (Phone)

520 661 6753 (Mobile)

RE: DO NOT REPLY [Bug 22878] New: - LookupDispatchAction throws NullPointerException during first execute after tomcat start

2003-09-02 Thread Rick Hightower 
I just realized that I replied to something that said " DO NOT REPLY"...
what a dope I put the comment as per your request.

Rick Hightower
Chief Technology Officer
Trivera Technologies
http://www.triveratech.com
520 290 6855 (Phone)


-Original Message-
From: Steve Raeburn [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 02, 2003 12:01 PM
To: Struts Developers List
Subject: RE: DO NOT REPLY [Bug 22878] New: - LookupDispatchAction throws
NullPointerException during first execute after tomcat start

You could add that suggestion to the bug report if you like.

Steve

> -Original Message-
> From: Rick Hightower [mailto:[EMAIL PROTECTED]
> Sent: September 2, 2003 11:21 AM
> To: 'Struts Developers List'
> Subject: RE: DO NOT REPLY [Bug 22878] New: - LookupDispatchAction throws
> NullPointerException during first execute after tomcat start
>
>
> Gee... this sounds like they forgot to set the load-on-startup element for
> the Action Servlet.
>
>
> Rick Hightower
> Chief Technology Officer
> Trivera Technologies
> http://www.triveratech.com
> 520 290 6855 (Phone)
> 520 977 8605 (Mobile)
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 02, 2003 3:12 AM
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 22878] New: - LookupDispatchAction throws
> NullPointerException during first execute after tomcat start
>
> 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=22878>.
> 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=22878
>
> LookupDispatchAction throws NullPointerException during first
> execute after
> tomcat start
>
>Summary: LookupDispatchAction throws
> NullPointerException during
> first execute after tomcat start
>Product: Struts
>Version: 1.1 Final
>   Platform: All
> OS/Version: Other
> Status: NEW
>   Severity: Normal
>   Priority: Other
>  Component: Standard Actions
> AssignedTo: [EMAIL PROTECTED]
> ReportedBy: [EMAIL PROTECTED]
>
>
> After every start of tomcat the LookupDispatchAction class throws a
> NullPointerException, but it does only do so the first time any
> LookupDispatchAction is executed. Any call to execute() for any
> LookupDispatchAction after that first call does not throw a
> NullPointerException,
>
> Note that this only occurs when _not_ having a message-resources
> defined in
> struts-config.xml. This also gives the following workaround:
> put  in the
> struts-config.xml
> and
> an 'empty' BugWorkaround.properties in WEB-INF/classes.
>
> NullPointerException is thrown at
> org.apache.struts.actions.LookupDispatchAction.execute(LookupDispa
> tchAction.
> java:236)
>
> -
> 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]



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

RE: DO NOT REPLY [Bug 22878] New: - LookupDispatchAction throws NullPointerException during first execute after tomcat start

2003-09-02 Thread Rick Hightower 
Gee... this sounds like they forgot to set the load-on-startup element for
the Action Servlet.


Rick Hightower
Chief Technology Officer
Trivera Technologies
http://www.triveratech.com
520 290 6855 (Phone)
520 977 8605 (Mobile)
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 02, 2003 3:12 AM
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 22878] New: - LookupDispatchAction throws
NullPointerException during first execute after tomcat start

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=22878>.
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=22878

LookupDispatchAction throws NullPointerException during first execute after
tomcat start

   Summary: LookupDispatchAction throws NullPointerException during
first execute after tomcat start
   Product: Struts
   Version: 1.1 Final
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Standard Actions
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


After every start of tomcat the LookupDispatchAction class throws a
NullPointerException, but it does only do so the first time any
LookupDispatchAction is executed. Any call to execute() for any
LookupDispatchAction after that first call does not throw a
NullPointerException,

Note that this only occurs when _not_ having a message-resources defined in
struts-config.xml. This also gives the following workaround:
put  in the struts-config.xml
and
an 'empty' BugWorkaround.properties in WEB-INF/classes.

NullPointerException is thrown at
org.apache.struts.actions.LookupDispatchAction.execute(LookupDispatchAction.
java:236)

-
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: Improve JSTL i18n support with Struts

2003-08-29 Thread Rick Hightower 
Okay. No problem. I will still work on this (I need it) maybe I'll just
come up with a "Best Practice" for using JSTL i18N support with Struts or
something along those lines.

It seems like any JSTL integration is going to wait until Struts 2.0. I
understand the reasoning behind this. It makes a lot of sense to me to wait
till 2.0



//session.setAttribute(Config.FMT_LOCALE, locale);


Rick Hightower
Chief Technology Officer
Trivera Technologies
http://www.triveratech.com
520 290 6855 (Phone)
520 977 8605 (Mobile)
 

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 29, 2003 10:33 AM
To: Struts Developers List
Subject: Re: Improve JSTL i18n support with Struts

This all seems reasonable but needs to wait for Struts 2.x.  1.x must
remain on Servlet 2.2 to maintain backwards compatibility.  IMO, 2.x is
the best time to change the Servlet level because we'll be breaking
compatibility at that time anways.

David

--- Rick Hightower <[EMAIL PROTECTED]> wrote:
> I’d like to see Struts play nice with JSTL i18n support.
> 
> I have a suggestion along these lines. (This is prelim. I am going to
> write
> some tests and do some prototyping but before I do… I’d like to hear if
> there are any thoughts on this).
> 
> Currently when you call Action.setLocale you get this:
> 
> ...class Action...
>     protected void setLocale(HttpServletRequest request, Locale locale)
> {
>  
>     HttpSession session = request.getSession();
>     if (locale == null) {
>     locale = Locale.getDefault();
>     }
>     session.setAttribute(Globals.LOCALE_KEY, locale);
>  
>     }
> 
> I am suggesting this (for the release that embraces JSTL…. Struts 1.3 or
> 1.5).
> 
> import javax.servlet.jsp.jstl.core.Config; //get this guy to use its
> Locale
> key as well
> ...class Action...
>     protected void setLocale(HttpServletRequest request, Locale locale)
> {
>  
>     HttpSession session = request.getSession();
>     if (locale == null) {
>     locale = Locale.getDefault();//Don’t agree with this, but
> that
> is a different story…
>     }
>     session.setAttribute(Globals.LOCALE_KEY, locale);
> session.setAttribute(Config.FMT_LOCALE, locale); //See
> this…. See this…. See this…
>     }
> 
> The Config.FMT_LOCALE is similar to the Globals.LOCALE_KEY except that
> it is
> for the JSTL tags, e.g.,
> 
> 
> 
> This is one possibility and the one that takes the least amount of
> effort.
> Another possibility is to change all struts i18n tags to use
> Config.FMT_LOCALE instead of Globals.LOCALE_KEY, which might be bad
> because
> it would break existing projects.
> 
> I am going to write a prototype along these lines in the near future. I
> need
> to test to see if fmt:message will work with Strut’s resource bundles.
> (I am
> not sure it they will or not... I think they will with a little arm
> twisting. I am still a little ignorant on the details... I got the big
> picture... just not all the details.). Any suggestions from you i18n
> gurus
> would be nice or if someone already started this... clue me in so I
> don't
> waste time.
> 
> This could be a first step in getting rid of our good friend
> bean:message
> and replacing him with fmt:message (or at least deprecating him a bit).
> :(
> 
> Don’t worry. I will add this to the Bugzilla feature request as soon as
> I
> test it.
> 
> Rick Hightower
> Chief Technology Officer
> Trivera Technologies
> http://www.triveratech.com
> 520 290 6855 (Phone)
> 520 977 8605 (Mobile)
>  
> 
> 
> 
> -
> 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]

RE: Action.setLocale, fail early?

2003-08-29 Thread Rick Hightower 
Good point. I did not think of that. (I guess I won't be adding an
enhancement request).

Did you get a chance to look at the i18N/JSTL support email?

Rick Hightower
Chief Technology Officer
Trivera Technologies
http://www.triveratech.com
520 290 6855 (Phone)
520 977 8605 (Mobile)
 

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 29, 2003 10:19 AM
To: Struts Developers List
Subject: Re: Action.setLocale, fail early?

--- Rick Hightower <[EMAIL PROTECTED]> wrote:
> From Nightly build.
> 
>  
> 
> protected void setLocale(HttpServletRequest request, Locale locale)
> {
> 
>  
> 
> HttpSession session = request.getSession();
> 
> if (locale == null) {
> 
> locale = Locale.getDefault();
> 
> }
> 
> session.setAttribute(Globals.LOCALE_KEY, locale);
> 
>  
> 
> }
> 
>  
> 
> Comments on setLocale from Action..
> 
>  
> 
> If the locale is null, wouldn't it be better for the default to come
> from
> the request as in request.getLocale(), which is the behavior of the tags
> when the Locale at Globals.LOCALE_KEY is not in session scope.

What about the situation where you pass in null to clear the Locale from
the session?  The method currently assumes that passing null means "use a
default" instead of trusting the user that what they passed in is what
they want in the session.  Maybe passing null should mean that any Locale
in the session is to be removed.  The saveErrors() and saveMessages()
methods behave that way so it's inconsistent for setLocale() to behave
differently.

Regardless, changing this now would break backwards compatibility but it's
something to think about in 2.x.

David

> 
>  
> 
> Better Yet. Also if they call setLocale, shouldn't the local object be
> non-null. My personal opinion on this stuff is that it should explode
> with
> an illegal argument exception. (I remember a bug report that talked
> about
> Struts quietly handing illegal situations)
> 
>  
> 
> if (locale == null) {
> 
> throw new java.lang.IllegalArgumentException("Locale was
> null");
> 
> }
> 
>  
> 
>  
> 
> As a developer when I misuse an API, I like to see it fail quickly. This
> way
> I don't have to spend a lot of time debugging where I went wrong. Die
> early
> and often in development not during QA or. gulp.. Production!
> 
>  
> 
>  
> 
>  
> 
>  
> 
> Rick Hightower
> 
> Chief Technology Officer
> 
> Trivera Technologies
> 
> http://www.triveratech.com
> 
> 520 290 6855 (Phone)
> 
> 520 977 8605 (Mobile)
> 
>  
> 
>  
> 
> 


__
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]

RE: [OT] As the Struts world turns [was: Re: DO NOT REPLY [Bug 22519] - Allow multiple MessageResources files to be loaded under one key]

2003-08-29 Thread Rick Hightower 
I instant messaged the link to my boss. We laughed about it as well.
Then I showed my wife and sister-in-law. My wife didn't think it was funny.
I enjoyed it a little too much.

Rick Hightower
Chief Technology Officer
Trivera Technologies
http://www.triveratech.com
520 290 6855 (Phone)
520 977 8605 (Mobile)
 

-Original Message-
From: Andrew Hill [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 29, 2003 4:53 AM
To: Struts Developers List
Subject: RE: [OT] As the Struts world turns [was: Re: DO NOT REPLY [Bug
22519] - Allow multiple MessageResources files to be loaded under one key]

Yeh, I thought it was hilarious when I unwittingly clicked the link and got
bombarded with all those windows and the silly jingle! (Mind you I am easily
entertained ;->) and the guy who sits next to me thought it pretty darn
funny too...


-Original Message-
From: Brandon Goodin [mailto:[EMAIL PROTECTED]
Sent: Thursday, 28 August 2003 21:39
To: Struts Developers List
Subject: RE: [OT] As the Struts world turns [was: Re: DO NOT REPLY [Bug
22519] - Allow multiple MessageResources files to be loaded under one
key]


You guys need to lighten up. On every comp I have seen this link it was
easily shutdown. James, don't worry about it.

Brandon Goodin

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 28, 2003 7:19 AM
> To: Struts Developers List
> Subject: Re: [OT] As the Struts world turns [was: Re: DO NOT REPLY [Bug
> 22519] - Allow multiple MessageResources files to be loaded under one
> key]
>
>
> Ya, I read from a different thread about what happens.  That didn't happen
> to me since I use Mozilla (with pop-ups blocked).
>
> Sorry about that, I wouldn't have sent it if I had known.
>
>
> --
> James Mitchell
> Software Engineer / Struts Evangelist
> http://www.struts-atlanta.org
> 770-822-3359
> AIM:jmitchtx
>
>
>
> - Original Message -
> From: "Robert Leland" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Thursday, August 28, 2003 3:27 AM
> Subject: Re: [OT] As the Struts world turns [was: Re: DO NOT REPLY [Bug
> 22519] - Allow multiple MessageResources files to be loaded under one key]
>
>
> > James Mitchell wrote:
> >
> > >Someone posted a link on another thread that might actually help in
> > >situations like this:
> > >
> > >http://www.originalicons.com/smile
> > >
> > >
> > >
> > Not funny.
> >
> >
> > -
> > 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]


-
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: JSR 168 and Struts

2003-08-29 Thread Rick Hightower 
Regarding:" Lacking an implementation to test my hypothesis (*$&# IBM legal
department), I am unsure whether this actually fails or not.  My gut
instinct is that it probably wouldn't, but that it may not be reliable
across implementations of servlet and portlet containers."

Jaco Portal Server is a Java portal server which is compliant with the
Portlet Specification (JSR-168).
 
http://pharos.inria.fr/Java/display.jsp?id=c_14701

I have a client that is mixing Portlets and Struts. I am not an expert on
Portlets. 

They did a lot of research on the best ways to mix the two technologies
(white papers, prototypes, etc.). 



Rick Hightower
Chief Technology Officer
Trivera Technologies
http://www.triveratech.com
520 290 6855 (Phone)
520 977 8605 (Mobile)
 

-Original Message-
From: Clay Richardson [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 28, 2003 9:05 PM
To: [EMAIL PROTECTED]
Subject: JSR 168 and Struts

I apologize if anyone has already asked this question, but I searched
the board and didn't see it.  Also, I tried the user forum first, but
figured maybe this was more appropriate.

 

JSR 168 has the following line in it (Section PLT.16.3):

 

"Servlets and JSPs included from portlets should not use the servlet
RequestDispatcher forward method as its behavior may be
non-deterministic."

 

I am no expert on Struts, although I have used it quite a bit.  It seems
that if I wanted to wrap my Struts app in a Portlet and access various
actions through the PortletRequestDispatcher (the most logical
approach), I would run afoul of this warning.

 

Lacking an implementation to test my hypothesis (*$&# IBM legal
department), I am unsure whether this actually fails or not.  My gut
instinct is that it probably wouldn't, but that it may not be reliable
across implementations of servlet and portlet containers.  

 

I wanted to get some thoughts from the Struts community about this
possible issue.  Also, I wanted to know what the impact would be of
using RequestDispatcher's include method instead?  Or at least providing
the facility to portlet developers?

 

I apologize if I have wrongly assumed anything in my question.  This is
my best estimate based on what I have read.

 

Thanks,

 

 

Clay Richardson

 

 

W. Clay Richardson

Adjunct Professor of Computer Science

Northern Virginia Graduate Center

Virginia Polytechnic Institute and State University

 

"Oh, and how is "education" supposed to make me feel smarter?  Besides,
every time I learn something new, it pushes some old stuff out of my
brain.  Remember when I took that home wine-making course and I forgot
how to drive?" - Homer J. Simpson

 

 

 

 



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

Improve JSTL i18n support with Struts

2003-08-28 Thread Rick Hightower 
I’d like to see Struts play nice with JSTL i18n support.

I have a suggestion along these lines. (This is prelim. I am going to write
some tests and do some prototyping but before I do… I’d like to hear if
there are any thoughts on this).

Currently when you call Action.setLocale you get this:

...class Action...
    protected void setLocale(HttpServletRequest request, Locale locale) {
 
    HttpSession session = request.getSession();
    if (locale == null) {
    locale = Locale.getDefault();
    }
    session.setAttribute(Globals.LOCALE_KEY, locale);
 
    }

I am suggesting this (for the release that embraces JSTL…. Struts 1.3 or
1.5).

import javax.servlet.jsp.jstl.core.Config; //get this guy to use its Locale
key as well
...class Action...
    protected void setLocale(HttpServletRequest request, Locale locale) {
 
    HttpSession session = request.getSession();
    if (locale == null) {
    locale = Locale.getDefault();//Don’t agree with this, but that
is a different story…
    }
    session.setAttribute(Globals.LOCALE_KEY, locale);
session.setAttribute(Config.FMT_LOCALE, locale); //See
this…. See this…. See this…
    }

The Config.FMT_LOCALE is similar to the Globals.LOCALE_KEY except that it is
for the JSTL tags, e.g.,



This is one possibility and the one that takes the least amount of effort.
Another possibility is to change all struts i18n tags to use
Config.FMT_LOCALE instead of Globals.LOCALE_KEY, which might be bad because
it would break existing projects.

I am going to write a prototype along these lines in the near future. I need
to test to see if fmt:message will work with Strut’s resource bundles. (I am
not sure it they will or not... I think they will with a little arm
twisting. I am still a little ignorant on the details... I got the big
picture... just not all the details.). Any suggestions from you i18n gurus
would be nice or if someone already started this... clue me in so I don't
waste time.

This could be a first step in getting rid of our good friend bean:message
and replacing him with fmt:message (or at least deprecating him a bit). :(

Don’t worry. I will add this to the Bugzilla feature request as soon as I
test it.

Rick Hightower
Chief Technology Officer
Trivera Technologies
http://www.triveratech.com
520 290 6855 (Phone)
520 977 8605 (Mobile)
 



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

Action.setLocale, fail early?

2003-08-28 Thread Rick Hightower 
>From Nightly build.

 

protected void setLocale(HttpServletRequest request, Locale locale) {

 

HttpSession session = request.getSession();

if (locale == null) {

locale = Locale.getDefault();

}

session.setAttribute(Globals.LOCALE_KEY, locale);

 

}

 

Comments on setLocale from Action..

 

If the locale is null, wouldn't it be better for the default to come from
the request as in request.getLocale(), which is the behavior of the tags
when the Locale at Globals.LOCALE_KEY is not in session scope.

 

Better Yet. Also if they call setLocale, shouldn't the local object be
non-null. My personal opinion on this stuff is that it should explode with
an illegal argument exception. (I remember a bug report that talked about
Struts quietly handing illegal situations)

 

if (locale == null) {

throw new java.lang.IllegalArgumentException("Locale was null");

}

 

 

As a developer when I misuse an API, I like to see it fail quickly. This way
I don't have to spend a lot of time debugging where I went wrong. Die early
and often in development not during QA or. gulp.. Production!

 

 

 

 

Rick Hightower

Chief Technology Officer

Trivera Technologies

http://www.triveratech.com

520 290 6855 (Phone)

520 977 8605 (Mobile)

RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)

2003-08-28 Thread Rick Hightower 
I am not a voter, but I think

Comments below...


Rick Hightower
Chief Technology Officer
Trivera Technologies
http://www.triveratech.com
520 290 6855 (Phone)
520 977 8605 (Mobile)
 

-Original Message-
From: Steve Raeburn [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 27, 2003 9:20 PM
To: Struts Developers List
Subject: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] -
Enhancement of the html:link tag)

I'm not singling Vic out for this (honest) but...

The standard advice we are now giving everyone is "use JSTL", which I
wholeheartedly agree with and have said myself. However, I think we need to
make sure that we still adequately support non-JSTL solutions and continue
to consider bug fixes/enhancements to Struts tags EVEN where it would
duplicate JSTL functionality because Struts still supports JSP
1.1/Servlet2.2.

 I don't think fixing non-JSTL tags should take priority. I
think deprecated tags like logic:iterate, and their ilk should receive very
little attention. BTW I am going to make a concerted effort to contribute to
this project. Please excuse me while I am new if I make any snafu. (I have
some stuff and ideas in the works. Mostly bug fix type ideas.)

I haven't considered whether this particular enhancement would fall into the
category of something we should do, it just prompted me to raise the issue.

If we've reached the stage where the recommendations we are making *require*
JSTL, then I think it's time to be honest about the required platform for
Struts and up it to 1.1/2.3

 I think Struts 1.2 and higher should *require* JSTL tags,
and overlapping Struts tags should be deprecated (aren't they already). If
this is not feasible for Struts 1.2, then Struts 1.3 or 1.5 or 1.whatever.

Use JSTL instead of Struts-Equivalent Tags
Use core:out instead of bean:write 
Use core:set instead of bean:define 
Use JSTL core:if and core:forEach instead of Struts logic:*
  Use frmt tags in place of bean:message (if possible)
Use JSTL EL Engine in Your Own Custom Tags

I don't know how well the JSTL i18n support plays with the Struts i18n
support as I am only familiar with the latter and not the former at least
not on a carnal level.

Steve

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: August 27, 2003 8:28 PM
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag
>
>
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21465>.
> 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=21465
>
> Enhancement of the html:link tag
>
> [EMAIL PROTECTED] changed:
>
>What|Removed |Added
> --
> --
>  Status|ASSIGNED|RESOLVED
>  Resolution||WONTFIX
>
>
>
> --- Additional Comments From [EMAIL PROTECTED]
> 2003-08-28 03:27 ---
> You can/should use JSTL instead.
> .V
>
> -
> 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: JSTL EL Validator rule: A better requiredif and validatewhen using JSTL

2003-08-27 Thread Rick Hightower 
I only have the JSTL EL validator rule complete. It still needs testing,
logging, and some general refactoring. 

Here is the war file
http://www.rickhightower.com/CustomRule.war

Here is the src
http://www.rickhightower.com/CustomRule.zip

Rick Hightower
Chief Technology Officer
Trivera Technologies
http://www.triveratech.com
520 290 6855 (Phone)
520 977 8605 (Mobile)
 

-Original Message-
From: Steve Raeburn [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 26, 2003 4:37 PM
To: Struts Developers List
Subject: RE: JSTL EL Validator rule: A better requiredif and validatewhen
using JSTL

Rick,

It certainly sounds interesting but I'd like to have a working example to
play with.

It would be nice if you could:
a. Create a small working example as a war and post in on a website for us
to take a look at.
b. Create an enhancement request in Bugzilla and add your proposed patches
there.

a. will make it easier to quickly review your suggestions without having to
worry about cutting and pasting code and getting things working.
b. will make it easier to add the code to CVS if we decide that's the way to
go.

That's just my personal opinion, but it would make me inclined to look at it
sooner.

Also, I do agree that it could not go into the core until we update the
Struts requirements to Servlet 2.3/JSP 1.2 (or later). I thinking along the
same lines as Rob's speculation - I do think that it might OK to make that
change sooner than Struts 2.0. Even my dodgy ISP has been running Tomcat 4
for a while so maybe it would be good to make a switch. 1.5 might be an
appropriate time to do that???

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]

RE: JSTL EL Validator rule: A better requiredif and validatewhen using JSTL

2003-08-27 Thread Rick Hightower 
I did both of the steps you requested.

Bug 22743 posted
Email sent to: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]




Rick Hightower
Chief Technology Officer
Trivera Technologies
http://www.triveratech.com
520 290 6855 (Phone)
520 977 8605 (Mobile)
 

-Original Message-
From: Steve Raeburn [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 26, 2003 4:37 PM
To: Struts Developers List
Subject: RE: JSTL EL Validator rule: A better requiredif and validatewhen
using JSTL

Rick,

It certainly sounds interesting but I'd like to have a working example to
play with.

It would be nice if you could:
a. Create a small working example as a war and post in on a website for us
to take a look at.
b. Create an enhancement request in Bugzilla and add your proposed patches
there.

a. will make it easier to quickly review your suggestions without having to
worry about cutting and pasting code and getting things working.
b. will make it easier to add the code to CVS if we decide that's the way to
go.

That's just my personal opinion, but it would make me inclined to look at it
sooner.

Also, I do agree that it could not go into the core until we update the
Struts requirements to Servlet 2.3/JSP 1.2 (or later). I thinking along the
same lines as Rob's speculation - I do think that it might OK to make that
change sooner than Struts 2.0. Even my dodgy ISP has been running Tomcat 4
for a while so maybe it would be good to make a switch. 1.5 might be an
appropriate time to do that???

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]

RE: JSTL EL Validator rule: A better requiredif and validatewhen using JSTL

2003-08-27 Thread Rick Hightower 
Comments below (**)
 

-Original Message-
From: James Turner [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 26, 2003 4:38 PM
To: 'Struts Developers List'; [EMAIL PROTECTED]
Subject: RE: JSTL EL Validator rule: A better requiredif and validatewhen
using JSTL

The only reason I didn't go with JSTL is that I couldn't find a way to
represent the Foo[] syntax (meaning "the same index into Foo that is
being used by the field being checked") in JSTL, and that's very useful
when you're doing master-detail records where you want the Last Name for
a row to be required if the first name is filled out.  Currently, you
could do this as: ((*this* != null) OR (Firstname[] == null)), how would
you do this in a JSTL syntax?

** Good point. I forgot about that feature of validatewhen. I read up on
what was out there on validatewhen. That is a good feature. I dig it now. I
retract my earlier statement of dropping validatewhen.

** I still think there should be a JSTL validator rule in addition to
validatewhen. JSTL just fits well in this space. 

 (Still on vacation in Ohio, but back in the land of broadband after
living through 24Kb hell in Chillicothe)

** I was just in Cincinnati, Ohio. I go to Ohio a lot on biz (mostly
Columbus). I live in Tucson AZ.

> -Original Message-
> From: Rick Hightower [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, August 26, 2003 5:43 PM
> To: 'Struts Developers List'; [EMAIL PROTECTED]
> Subject: RE: JSTL EL Validator rule: A better requiredif and 
> validatewhen using JSTL
> 
> 
> Comments below... (**)
> 
> David Graham:
> requiredif was released with 1.1, validwhen will be released 
> with 1.2, I will -1 any other changes like this for 1.2 
> because we're too late in the cycle for something like this.  
> 
> ** Okay. No problem. I was merely stating that I give it a +1 
> (although my vote does not count as I am not a contributor or 
> committer). I did not know how late in the cycle you all were.
> 
> Ted is already working on cutting 1.2 and nobody wants 
> another 1.1 release cycle situation.
> 
> ** Excellent. I did not know that. Good to hear. I give Ted a 
> big +1. (I loved his book).
> 
> David Graham:
> That's not how Struts works.  James spent the time to test 
> and commit validwhen and it will be released with 1.2.  
> 
> ** Understood. I was not negating the work James did. I was 
> merely expressing my opinion. I love the idea of 
> validatewhen, just not the implementation. I've read James' 
> book on Struts and I respect his talent and ability. I think 
> JSTL should have been selected instead. If I was voting back 
> then and my vote counted, I would have given it a -1. I give 
> James a +1 for effort.
> 
> 
> David Graham:
> I agree that using the EL for validation makes sense for the 
> reasons you stated.  
> 
> ** Cool. Finally I feel some sunshine. I was beginning to 
> think you did not like this idea.
> 
> David Graham:
> This would get Struts away from the restrictive requiredif 
> rule and the ANTLR generated validwhen rule.  
> 
> *** Yes. Yes. Yes.
> 
> David Graham:
> Using the standard EL would be a Good Thing.  
> 
> *** Yes.
> 
> David Graham:
> However, Struts 1.1 is based on Servlet 2.2 which prevents
> the use of Servlet 2.3 features (the EL) in the standard distro.  
> 
> *** Bummer. I did not know this. What a drag!
> *** Are you sure? I think you can use the validator rule with 
> 2.2. Why couldn't you? (excuse my ignorance) I believe you.
> 
> 
> David Graham:
> An EL based validation could live in the contrib directory 
> along with the struts-el taglib.
> 
> ** Excellent. At least it would have good company.
> ** Okay. Is this where it lives until Struts is based on 
> Servlet 2.3+ not Servlet 2.2?
> 
> 
> 
> 
> -
> 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: JSTL EL Validator rule: A better requiredif and validatewhen using JSTL

2003-08-26 Thread Rick Hightower 
Comments below... (**)

David Graham:
requiredif was released with 1.1, validwhen will be released with 1.2, I
will -1 any other changes like this for 1.2 because we're too late in the
cycle for something like this.  

** Okay. No problem. I was merely stating that I give it a +1 (although my
vote does not count as I am not a contributor or committer). I did not know
how late in the cycle you all were.

Ted is already working on cutting 1.2 and nobody wants another 1.1 release
cycle situation.

** Excellent. I did not know that. Good to hear. I give Ted a big +1. (I
loved his book).

David Graham:
That's not how Struts works.  James spent the time to test and commit
validwhen and it will be released with 1.2.  

** Understood. I was not negating the work James did. I was merely
expressing my opinion. I love the idea of validatewhen, just not the
implementation. I've read James' book on Struts and I respect his talent and
ability. I think JSTL should have been selected instead. If I was voting
back then and my vote counted, I would have given it a -1. I give James a +1
for effort.


David Graham:
I agree that using the EL for validation makes sense for the reasons you
stated.  

** Cool. Finally I feel some sunshine. I was beginning to think you did not
like this idea.

David Graham:
This would get Struts away from the restrictive requiredif rule
and the ANTLR generated validwhen rule.  

*** Yes. Yes. Yes.

David Graham:
Using the standard EL would be a Good Thing.  

*** Yes.

David Graham:
However, Struts 1.1 is based on Servlet 2.2 which prevents
the use of Servlet 2.3 features (the EL) in the standard distro.  

*** Bummer. I did not know this. What a drag!
*** Are you sure? I think you can use the validator rule with 2.2. Why
couldn't you? (excuse my ignorance) I believe you.


David Graham:
An EL based validation could live in the contrib directory along with the
struts-el taglib.

** Excellent. At least it would have good company.
** Okay. Is this where it lives until Struts is based on Servlet 2.3+ not
Servlet 2.2?




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

RE: JSTL EL Validator rule: A better requiredif and validatewhen using JSTL

2003-08-26 Thread Rick Hightower 
David Graham et al. 

I can feel the train derailing off the tracks. Screch!
For a moment let's pretend that I never mentioned BSF or Rhino. I want to
get your collective thoughts on JSTL EL Validator Rule.

JSTL EL Validator Rule (validatejstl) --

What feedback do you have for the JSTL EL validator rule?

David mentioned some disdain for Rhino/JavaScript. What about using JSTL EL
to compare fields in a form for a rule?

How do you think this approach compares to requiredif and validatewhen?

OPTION REQUIREDIF
Is it better to create a complex and verbose set of options like requiredif
to get rid of reliance on an expression language? (IMO very few folks use
this because it is too complex)

OPTION VALIDATEWHEN
Is it better to create a custom expression language just for validation like
validatewhen? 

Would you prefer requiredif, validatewhen, or validatejstl to be part of the
next version of Struts? Or none of them?

Last I heard validatewhen will be part of the next release of Struts. I
think this JSTL EL Validator rule should be included instead. Creating
another expression language for this problem space does not make sense when
a perfectly good expression language like JSTL EL is available. It does not
make sense to maintain a second expression language when Jakarta already has
JSTL, which is better and more mature. JSTL EL is pervasive, e.g., JSTL EL
tags are recommended over legacy struts tags.

I've received some feedback from a few struts users (clients and peers).
They love the idea of JSTL EL validator rule. It just makes so much sense
and solves the problem of doing validation that involves relationships
between form fields. This is a hole in the validator framework that gets
filled quite nicely by validatejstl. The beauty of this is it is so small.

Okay... I am changing tracks to a different conversation.




BSF Validator Rule 

This is a separate issue from the JSTL EL Validator Rule. Perhaps this could
be a separate conversation. 

Having a validate-bsf rule would not necessitate running Rhino... it would
merely be an option.  The validator framework would never have to start
Rhino (JavaScript), Jython (Python), JRuby (Ruby), or any scripting language
unless the web application developer wanted to use this feature.

I like the thought of Rhino because I could create scripts on the client and
the server, and only have one set of validation scripts. I think this is a
better alternative than having to maintain two sets of code that does the
same thing in two languages. Again, this would be an option, not required.

** More Comments below...

Rick Hightower
Chief Technology Officer
Trivera Technologies
http://www.triveratech.com
520 290 6855 (Phone)
520 977 8605 (Mobile)
 

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 26, 2003 6:51 AM
To: Struts Developers List
Subject: RE: JSTL EL Validator rule: A better requiredif and validatewhen
using JSTL

> I am using the JSTL EL Validator that I wrote, but not the BSF or OGNL
> ones

I assume this plan involves running Rhino as the server side Javascript
engine?  I don't think that's a good idea.  

**Why? Size? Performance? Overhead? What if Rhino was only an option (as I
am suggesting)? Would you still be against Rhino if it is only an option not
a requirement?

Validator shouldn't have to
start up a Javascript engine on the server just to do some validations. 

** I agree. This is why I never suggested such a thing.
** It would not have to start JavaScript. This would be an *option*, it
would only start up JavaScript if you used the validate-javascript rule
(more likely validate-bsf).

Javascript is a client side validation tool that's a convenience to users.

** I agree.

 The real benefit from Validator is the server side checks it performs
which should remain in Java.

** I agree. This is an augmentation not a replacement. I am not suggesting
the that validator framework have any dependence on JavaScript/Rhino. This
would all be included and encapsulated in one validator rule.

** H... what if you could do a simple expression like this

form.passwordCheck != value 

Or something like this

form.startDate < value

and replace one ActionForm class (40+ lines of code). 

** Less code to write means less code to maintain.

** I think JSTL EL and JavaScript are valid options for doing comparison of
form fields. Using the BSF, the user could pick any Java scripting language
(Bean Shell, Jython, JRuby or whatever). Duplication is evil. It would be
nice to avoid duplication if possible.

** What were your thoughts on JSTL EL as an expression language for doing
form field relationship comparisons?

** I'll come up with a proof of concept for BSF later. For now I would love
to get your thoughts on JSTL EL.

David





-
To unsubscri

RE: JSTL EL Validator rule: A better requiredif and validatewhen using JSTL

2003-08-26 Thread Rick Hightower 
I think JSTL EL validator rule should move into Struts proper and requiredif
and validatewhen should be deprecated or moved into the contrib folder.

I am happy to commit the JSTL EL validator rule to contrib. What does this
entail on my part?

Comments below (**)

-Original Message-
From: Robert Leland [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 26, 2003 5:32 AM
To: Struts Developers List
Subject: Re: JSTL EL Validator rule: A better requiredif and validatewhen
using JSTL

Rick Hightower wrote:

Regarding:
Sorry, For not commenting on (JSTL EL validator rule). I agree that a JSTL
EL expression makes sense.

** Excellent

For now struts 1.X is still JSP 1.1 based:
   1) Assuming the other committers agree, and I like what I see, add 
the tag to the contrib folder.

** Excellent. What (if anything) do I do to contribute this to the contrib.
folder? 

** I think it should move into Struts proper and requiredif and validatewhen
should be deprecated.

   If this tag targets JSP 2.0 then it would need to go into it's 
own folder.

** It does not target JSP 2.0. It targets JSP 1.1, 1.2 and 2.0. It should
work without problem on all three versions of JSP.

   2) Donate the tag to the struts.sf.net site.

** This is my first time getting involved with Struts. What would this
entail? Any action on my part? Is it time for me to RTFM? If so send me in
the right direction.


   At some point Struts 1.5.X, wildly pulling number out of air, or so 
--may-- go to 1.2/2.3 specs. I believe this because there is now talk of
basing Struts 2.X on JSP 2.0. This spec is even further way from general
adoption than 1.2/2.3, so I believe it would be better to start the move in
the 1.5 time frame.

** This should be a non-issue with this validation rule as it will work in
JSP 1.1, 1.2 or 2.0 without problem.

OR...
Do abopt JSP 1.2/2.3 in the Struts 2.X series and JSP 2.0 in Struts 
3.X series.   


-Rob


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

RE: JSTL EL Validator rule: A better requiredif and validatewhen using JSTL

2003-08-26 Thread Rick Hightower 
What were your thoughts on JSTL EL validator rule?

You commented on BSF and OGNL, but not the JSTL EL validator rule, which I
actually wrote. The others just seem like a good idea.


Regarding:
"This is a General suggestion you have probably given many times yourself
First off then if this is something you would find useful for your work 
then do create the tag and develop the code. That way you would have a
personal investment in  it and continue to improve and maintain it. Then
maybe I would be able to see the entire impact on Struts/commons-validator."

I am using the JSTL EL Validator that I wrote, but not the BSF or OGNL ones
I suggested. I just think they would be a good idea. I'll try the BSF tag
since I don't know much about OGNL. I like the idea of using the same
JavaScript on the client side and the server side, but for now it is just an
idea. I'll try it out.

More comments below


Rick Hightower
Chief Technology Officer
Trivera Technologies
http://www.triveratech.com
520 290 6855 (Phone)
520 977 8605 (Mobile)
 

-Original Message-
From: Robert Leland [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 25, 2003 6:45 PM
To: Struts Developers List
Subject: Re: JSTL EL Validator rule: A better requiredif and validatewhen
using JSTL

Rick Hightower wrote:

>I think there is room for a tag that uses OGNL. OGNL gets used by tapestry
>and WebWork2. Perhaps yet another validator rule could use the BSF
>(BeanScriptingFramework) this would allow the validate expression to be
>written in Rhino (JavaScript for Java), Jython (Python for Java),
BeanShell,
>Perl and more. I think using BSF would be nice. You could have the client
>and server side validation using the same JavaScript code. I am willing to
>contribute the above as well as write a rule that uses BSF and OGNL.
>  
>

Having equalivent client side and servide side validtaion would be very 
nice ! 

** I agree. What did you think of the JSTL validator rule?


One of the
changes in the 1.1.X series of commons-validator is moving the 
Javascript part of validations
from struts to commons-validator. However, now those validations need to 
be unit tested,
and I have just started looking at jsunit for this. Originally the 
Validation code for  Java and Javascript
were almost  line for line identical. Now there are many differences 
between them so maintance
is complicated. 

** I was not aware. I actually thought about doing this type of validation
in the past. I have never done it, but it seems like it would be cool. The
validator framework seems like the right vehicle for this type of shared
JavaScript code between the server and client.

I would be open to using a common set of validation 
routines. I believe the Mozilla
license and the Apache License is fairly compatable so creating a 
dependancy on Rhino shouldn't
impact users of Struts.

** Yep.

I just took a very quick look at OGNL it looks interesting, though I am 
confused, probably becasue I
haven't taken the time to look at all the docs or examples. It says

*

  A binding language between GUI elements (textfield, combobox,
  etc.) to model objects. Transformations are made easier by OGNL's
  TypeConverter mechanism to convert values from one type to another
  (String to numeric types, for example).


  Does this mean BeanUtils would not be used to introspect 
loading/unloading values to/from
  ActionForm elements. I am not against this, or for it just want to 
assess the impact.

** I am not an OGNL expert. It seems cool, but I don't know all the reasons
why. Like I said, it gets used by WebWork2 and Tapestry.

Also there are alot of new terms here I am not familar with seems to 
require
BeanScriptingFramework requires JRuby which I am also not familar with...

** I don't think BSF requires JRuby unless you plan on using Ruby. I've used
BSF in the past to add JavaScript and Python support to a program I wrote.
It is easy to use, and would not be much different to validateel (JSTL EL).


This is a General suggestion you have probably given many times yourself
First off then if this is something you would find useful for your work 
then do create the tag
and develop the code. 

** I found the JSTL EL validateel useful so I wrote it. I think the BSF
would have been useful a few times and I am willing to try it out.

That way you would have a personal investment in 
it and continue to improve
and maintain it. Then maybe I would be able to see the entire impact on 
Struts/commons-validator.

** I have a personal investment in all the code I write.

Sorry for such a shorty answer, I am interested.

** Cool.

-Rob

> 
>
>Thoughts?
>
> 
>
>--Rick Hightower 
>
> 
>
>
>  
>



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

JSTL EL Validator rule: A better requiredif and validatewhen using JSTL

2003-08-25 Thread Rick Hightower 
Request request){

 this.request = request; 

  }

 

  public Object getAttribute(String key) {

return map.get(key);

  }

 

  public void setAttribute(String key, Object value) {

map.put(key, value);

  }

 

  public void removeAttribute(String key) {

map.remove(key); 

  }

 

  public HttpSession getSession() {

return request.getSession(true);

  }

 

  public ServletRequest getRequest() {

return this.request;

  }

 

  public void setAttribute(String key, Object value, int scope) {

 

  if (scope ==PageContext.PAGE_SCOPE){

map.put(key, value);

  }else if (scope == PageContext.REQUEST_SCOPE){

request.setAttribute(key,value);

  }else if (scope==PageContext.SESSION_SCOPE){

request.getSession().setAttribute(key,value);

  }else if (scope==PageContext.APPLICATION_SCOPE){

//TODO fix get app scope from Globals key

  }

   }

 

   public Object getAttribute(String key, int scope) {

 

if (scope ==PageContext.PAGE_SCOPE){

  return map.get(key);

}else if (scope == PageContext.REQUEST_SCOPE){

  return request.getAttribute(key);

}else if (scope==PageContext.SESSION_SCOPE){

  return request.getSession().getAttribute(key);

}else if (scope==PageContext.APPLICATION_SCOPE){

return null; //TODO fix

}else {

  return null;

}

  }

  public void removeAttribute(String key, int scope) {

 

if (scope ==PageContext.PAGE_SCOPE){

   map.remove(key);

}else if (scope == PageContext.REQUEST_SCOPE){

   request.removeAttribute(key);

}else if (scope==PageContext.SESSION_SCOPE){

   request.getSession().removeAttribute(key);

}else if (scope==PageContext.APPLICATION_SCOPE){

 //TODO fix

}else {

   // no op

 

}

  }

 

 

  public Enumeration getAttributeNamesInScope(int scope) {

 

if (scope ==PageContext.PAGE_SCOPE){

  return map.keys();

}else if (scope == PageContext.REQUEST_SCOPE){

  return request.getAttributeNames();

}else if (scope==PageContext.SESSION_SCOPE){

  return request.getSession().getAttributeNames();

}else if (scope==PageContext.APPLICATION_SCOPE){

return null; //TODO fix

}else {

  return null;

} 

 

  }

 

  public Object findAttribute(String key) {

 

Object value = map.get(key);

if (value == null){

   value = request.getAttribute(key); 

}

if (value == null){

  value = request.getSession().getAttribute(key);

}

if (value == null){

  //TODO look it up in app scope

}

return value;

  }

 

//other methods are no ops

 

 

It took me longer to write this email then it did to write the above code
(including the rule itself and the example code) since the JSTL EL engine
provided by Jakarta does all of the real work. Also, if you use the
validator framework and you ever need to do a simple comparison of two
fields... this is the way to go. Plus, with JSTL EL you have access to
headers, attributes in session, request attributes, request parameters, and
so much more.

 

I think there is room for a tag that uses OGNL. OGNL gets used by tapestry
and WebWork2. Perhaps yet another validator rule could use the BSF
(BeanScriptingFramework) this would allow the validate expression to be
written in Rhino (JavaScript for Java), Jython (Python for Java), BeanShell,
Perl and more. I think using BSF would be nice. You could have the client
and server side validation using the same JavaScript code. I am willing to
contribute the above as well as write a rule that uses BSF and OGNL.

 

Thoughts?

 

--Rick Hightower

RE: Exception handling --- suggestion for improvements ---- (e.g., template tag masks original exception) correction in sample code

2001-11-16 Thread Rick Hightower 

Good point... thanks

but is the goal of struts only to be used in app servers that support the
J2EE 1.3 SDK?

check this out

http://java.sun.com/j2ee/sdk_1.2.1/techdocs/api/javax/servlet/jsp/JspExcepti
on.html

The older version of JspException did not support nested exceptions

If struts is already dependent on J2EE SDK 1.3 then I agree with your
statement.
If we endeavor to make it compatible with older versions of the SDK, then we
should create our own wrapper.

What version of the SDK is Websphere, WebLogic, Orion, Resin, JRun, etc.
on?

Thoughts?



Rick Hightower
Director of Development
eBlox, Inc.

Check out our new website!
www.eblox.com

Contact Info:
eBlox Tucson
phone: 520-615-9345 x103
fax: 520-529-5774

Rick's stuff:
http://www.eblox.com/people_detail.php?id=52
http://www.geocities.com/rick_m_hightower/
http://www.brainbench.com/transcript.jsp?pid=2351036


-Original Message-
From: Tom Klaasen (TeleRelay) [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 16, 2001 1:49 AM
To: Struts Developers List
Subject: RE: Exception handling --- suggestion for improvements 
(e.g., template tag masks original exception) correction in sample code


Maybe I'll have to disappoint you about constructing a new Exception
class.
Did you have a look at
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/jsp/JspExcep
tion.html#JspException(java.lang.String,%20java.lang.Throwable) ? Looks
to me this does _exactly_ what you're trying to do.

However, I agree that Struts should not call new
JspException(e.getMessage()), but new JspException("Some intelligent
message", e); instead. This leaves the decision of what to display to
the programmer.

tomK



> -Original Message-
> From: Rick Hightower [mailto:[EMAIL PROTECTED]]
> Sent: vrijdag 16 november 2001 9:24
> To: Struts Developers List
> Subject: Exception handling --- suggestion for improvements
>  (e.g., template tag masks original exception) correction
> in sample code
>
>
>
> We have been using struts for a good while. We really dig the
> framework,
> but...
>
> Often times the struts tags catch the original exception (e.g.,
> ClassCastException), and then throw a JspException; thus, losing the
> original stack trace. This hides\masks the original
> exception. Hiding the
> orginal stack trace makes it harder to debug the problem.
>
> I wrote a JSPWrapperException that preserves the orginal
> stack trace for
> debugging.
> JSPWrapperException extends JspWrapper; however, like
> ServletException, it
> captures the original stack trace and displays it for
> debugging, i.e., the
> JSPWrapperException prints out the original stack trace of
> the original
> exception. This is a real boon for debugging.
>
> I modified 50 or so files in our copy of the struts code base (a 1.0
> derivative with some bug fixes and extra error handing) to use the
> JSPWrapperException instead of the JspException.
>
> It cost about an hour to make the changes, but I feel it will
> save us hours
> of debugging in the future.
>
> There is an ant build file with struts so making the changes
> and creating
> struts.jar was easy.
>
>
>
> I search the struts code base for code like this (example code)
>
> try{
> }
> catch(XYZException e){
>   throw new JspException(e.getMessage());
> }
>
> to code that looks like this
> try{
> }
> catch(XYZException e){
>   throw new JspWrapperException(e, e.getMessage());
> }
>
>
> BTW Here is the code for JspWrapperException
>
> Enjoy.
>
> /*
>  * JspWrapperException.java
>  *
>  * Created on November 15, 2001, 11:14 PM
>  */
>
> package org.apache.struts.util;
> import javax.servlet.jsp.JspException;
>
> /**
>  *
>  * @author  rick
>  */
> public class JspWrapperException extends JspException  {
>
> Exception e;
>
> /**
>  * @param Exception e
>  * @param String message
>  */
> public JspWrapperException(Exception e, String message) {
> super(message);
> this.e = e;
> }
>
> /**
>  */
> public void printStackTrace () {
> super.printStackTrace();
> String sep = System.getProperty("line.separator", "\r\n");
> if (e != null) {
> System.err.println("--- extended Exception
> nest --- ");
> e.printStackTrace();
> }
> }
>
> /**
>  * @param ps
>  */
> public void printStackTrace (java.io.PrintStream ps) {
> super.printStackTrace(ps);
> String sep = System.getProperty("line.separator", "\r\n");
> if (e != null) {
>

RE: Exception handling --- suggestion for improvements ---- (e.g., template tag masks original exception)

2001-11-16 Thread Rick Hightower 

I think it is worth it to add the JspWrapperException in lieu of waiting for
the next Servlet spec. to further its adoption.

Hiding the original stack trace makes debugging tough. This is especially
frustrating to new users. I did this to our copy of Struts last night, and
it only took an hour.

In six months or a year when everyone is using the latest version of the
Servlet spec., it will only take an hour to switch to the new JspException
constructor if so desired.

BTW I volunteer to make the change.


Rick Hightower
Director of Development
eBlox, Inc.

Check out our new website!
www.eblox.com

Contact Info:
eBlox Tucson
phone: 520-615-9345 x103
fax: 520-529-5774

Rick's stuff:
http://www.eblox.com/people_detail.php?id=52
http://www.geocities.com/rick_m_hightower/
http://www.brainbench.com/transcript.jsp?pid=2351036


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Craig R. McClanahan
Sent: Friday, November 16, 2001 10:07 AM
To: Struts Developers List
Subject: Re: Exception handling --- suggestion for improvements 
(e.g., template tag masks original exception)




On Fri, 16 Nov 2001, Rick Hightower wrote:

> Date: Fri, 16 Nov 2001 01:20:45 -0700
> From: Rick Hightower <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Exception handling --- suggestion for improvements  (e.g.,
>  template tag masks original exception)
>
> We have been using struts for a good while. We really dig the framework,
> but...
>
> Often times the struts tags catch the original exception (e.g.,
> ClassCastException), and then throw a JspException; thus, losing the
> original stack trace. This hides\masks the original exception. Hiding the
> orginal stack trace makes it harder to debug the problem.
>

In JSP 1.2, the capability to add a root cause exception (the way
ServletException does it) was added to JspException, so once we migrate to
that platform as a minimum we'll be able to modify Struts to use it.  How
important is it to deal with this issue in the mean time?

Craig


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


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

RE: Exception handling --- suggestion for improvements ---- (e.g., templatetag masks original exception) correction in sample code

2001-11-16 Thread Rick Hightower 

Not having the @since reallly threw me off for a second when you sent that
note.
I had to go check the older API.


Rick Hightower
Director of Development
eBlox, Inc.

Check out our new website!
www.eblox.com

Contact Info:
eBlox Tucson
phone: 520-615-9345 x103
fax: 520-529-5774

Rick's stuff:
http://www.eblox.com/people_detail.php?id=52
http://www.geocities.com/rick_m_hightower/
http://www.brainbench.com/transcript.jsp?pid=2351036


-Original Message-
From: Tom Klaasen (TeleRelay) [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 16, 2001 5:12 AM
To: Struts Developers List
Subject: RE: Exception handling --- suggestion for improvements 
(e.g., templatetag masks original exception) correction in sample code


Tomcat 4 implements the servlet2.3 spec, although I'm not sure the spec
itself is final already.

And Tomcat 4 runs fine on jdk1.3, so I don't suppose they (and thus the
spec) use the jdk1.4 features.

tomK


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: vrijdag 16 november 2001 12:26
> To: Struts Developers List
> Subject: RE: Exception handling --- suggestion for
> improvements  (e.g., templatetag masks original
> exception) correction in sample code
>
>
>
> Ahh, oops.
>
> Or, use the servlet 2.3 API when it comes out (anyone know if
> that API uses
> the new Java 1.4 feature?).
>
> M
>
>
>
>
>
>
> "Tom Klaasen
>
>
> (TeleRelay)"To: "Struts
> Developers List" <[EMAIL PROTECTED]>
>
> 
>
> relay.com>  Subject: RE:
> Exception handling --- suggestion for improvements 
> (e.g., template tag masks
>  original
> exception) correction in sample code
>
> 11/16/2001 03:33
>
>
> PM
>
>
> Please respond to
>
>
> "Struts
>
>
> Developers List"
>
>
>
>
>
>
>
>
>
>
>
>
> OK, my mistake, this seems to be valid only for servlet 2.3 spec, not
> 2.2. Servlet 2.2 has no such feature whatsoever.
>
> For my defense, I can say that Sun should use the @since tag
> more often
> ;)
>
> tomK
>
>
> > -Original Message-
> > From: Tom Klaasen (TeleRelay)
> > Sent: vrijdag 16 november 2001 9:49
> > To: Struts Developers List
> > Subject: RE: Exception handling --- suggestion for
> > improvements  (e.g., template tag masks original
> > exception) correction in sample code
> >
> >
> > Maybe I'll have to disappoint you about constructing a new Exception
> > class.
> > Did you have a look at
> > http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/js
> > p/JspExcep
> > tion.html#JspException(java.lang.String,%20java.lang.Throwable
> > ) ? Looks
> > to me this does _exactly_ what you're trying to do.
> >
> > However, I agree that Struts should not call new
> > JspException(e.getMessage()), but new JspException("Some intelligent
> > message", e); instead. This leaves the decision of what to
> display to
> > the programmer.
> >
> > tomK
> >
> >
> >
> > > -Original Message-
> > > From: Rick Hightower [mailto:[EMAIL PROTECTED]]
> > > Sent: vrijdag 16 november 2001 9:24
> > > To: Struts Developers List
> > > Subject: Exception handling --- suggestion for improvements
> > >  (e.g., template tag masks original exception) correction
> > > in sample code
> > >
> > >
> > >
> > > We have been using struts for a good while. We really dig the
> > > framework,
> > > but...
> > >
> > > Often times the struts tags catch the original exception (e.g.,
> > > ClassCastException), and then throw a JspException; thus,
> losing the
> > > original stack trace. This hides\masks the original
> > > exception. Hiding the
> > > orginal stack trace makes it harder to debug the problem.
> > >
> > > I wrote a JSPWrapperException that preserves the orginal
> > > stack trace for
> > > debugging.
> > > JSPWrapperException extends JspWrapper; however, like
> > > ServletException, it
> > > captures the original stack trace and displays it for
> > > debugging, i.e., the
> > > JSPWrapperException prints out the original stack trace of
> > > the original
> > > exception. This is a real boon for

RE: [VOTE] Struts 1.0.1 Release

2001-11-16 Thread Rick Hightower 

+1

I am not a committer, but I'd like to help, especially with documentation.

Rick Hightower
Director of Development
eBlox, Inc.
 
Check out our new website!  
www.eblox.com

Contact Info:
eBlox Tucson 
phone: 520-615-9345 x103
fax: 520-529-5774 

Rick's stuff:
http://www.eblox.com/people_detail.php?id=52
http://www.geocities.com/rick_m_hightower/
http://www.brainbench.com/transcript.jsp?pid=2351036




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

Exception handling --- suggestion for improvements ---- (e.g., template tag masks original exception) correction in sample code

2001-11-16 Thread Rick Hightower 


We have been using struts for a good while. We really dig the framework,
but...

Often times the struts tags catch the original exception (e.g.,
ClassCastException), and then throw a JspException; thus, losing the
original stack trace. This hides\masks the original exception. Hiding the
orginal stack trace makes it harder to debug the problem.

I wrote a JSPWrapperException that preserves the orginal stack trace for
debugging.
JSPWrapperException extends JspWrapper; however, like ServletException, it
captures the original stack trace and displays it for debugging, i.e., the
JSPWrapperException prints out the original stack trace of the original
exception. This is a real boon for debugging.

I modified 50 or so files in our copy of the struts code base (a 1.0
derivative with some bug fixes and extra error handing) to use the
JSPWrapperException instead of the JspException.

It cost about an hour to make the changes, but I feel it will save us hours
of debugging in the future.

There is an ant build file with struts so making the changes and creating
struts.jar was easy.



I search the struts code base for code like this (example code)

try{
}
catch(XYZException e){
throw new JspException(e.getMessage());
}

to code that looks like this
try{
}
catch(XYZException e){
throw new JspWrapperException(e, e.getMessage());
}


BTW Here is the code for JspWrapperException

Enjoy.

/*
 * JspWrapperException.java
 *
 * Created on November 15, 2001, 11:14 PM
 */

package org.apache.struts.util;
import javax.servlet.jsp.JspException;

/**
 *
 * @author  rick
 */
public class JspWrapperException extends JspException  {

Exception e;

/**
 * @param Exception e
 * @param String message
 */
public JspWrapperException(Exception e, String message) {
super(message);
this.e = e;
}

/**
 */
public void printStackTrace () {
super.printStackTrace();
String sep = System.getProperty("line.separator", "\r\n");
if (e != null) {
System.err.println("--- extended Exception
nest --- ");
e.printStackTrace();
}
}

/**
 * @param ps
 */
public void printStackTrace (java.io.PrintStream ps) {
super.printStackTrace(ps);
String sep = System.getProperty("line.separator", "\r\n");
if (e != null) {
ps.println("--- extended Exception nest ---
");
e.printStackTrace(ps);
}
}

/**
 * @param pw
 */
public void printStackTrace (java.io.PrintWriter pw) {
super.printStackTrace(pw);
String sep = System.getProperty("line.separator", "\r\n");
//
//Nested exception
if (e != null) {
pw.println("--- extended Exception nest ---
");
e.printStackTrace(pw);
}
}

/**
 * @return
 */
public String getMessage () {
StringBuffer message = new StringBuffer(150);
message.append(super.getMessage());

//
//add Line separator
String sep = System.getProperty("line.separator", "\r\n");
message.append(sep);

//
//Add the nested exception
if (e != null) {
message.append(e.getMessage());
    //char = props["line.separator"]
}
return  message.toString();
}
}



Rick Hightower
Director of Development
eBlox, Inc.

Check out our new website!
www.eblox.com

Contact Info:
eBlox Tucson
phone: 520-615-9345 x103
fax: 520-529-5774

Rick's stuff:
http://www.eblox.com/people_detail.php?id=52
http://www.geocities.com/rick_m_hightower/
http://www.brainbench.com/transcript.jsp?pid=2351036


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



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

Exception handling --- suggestion for improvements ---- (e.g., template tag masks original exception)

2001-11-16 Thread Rick Hightower 

We have been using struts for a good while. We really dig the framework,
but...

Often times the struts tags catch the original exception (e.g.,
ClassCastException), and then throw a JspException; thus, losing the
original stack trace. This hides\masks the original exception. Hiding the
orginal stack trace makes it harder to debug the problem.

I wrote a JSPWrapperException that preserves the orginal stack trace for
debugging.
JSPWrapperException extends JspWrapper; however, like ServletException, it
captures the original stack trace and displays it for debugging, i.e., the
JSPWrapperException prints out the original stack trace of the original
exception. This is a real boon for debugging.

I modified 50 or so files in our copy of the struts code base (a 1.0
derivative with some bug fixes and extra error handing) to use the
JSPWrapperException instead of the JspException.

It cost about an hour to make the changes, but I feel it will save us hours
of debugging in the future.

There is an ant build file with struts so making the changes and creating
struts.jar was easy.



I search the struts code base for code like this (example code)

try{
}
catch(XYZException e){
throw new JspException(msg);
}

to code that looks like this
try{
}
catch(XYZException e){
throw new JspException(e, msg);
}


BTW Here is the code for JspWrapperException

Enjoy.

/*
 * JspWrapperException.java
 *
 * Created on November 15, 2001, 11:14 PM
 */

package org.apache.struts.util;
import javax.servlet.jsp.JspException;

/**
 *
 * @author  rick
 */
public class JspWrapperException extends JspException  {

Exception e;

/**
 * @param Exception e
 * @param String message
 */
public JspWrapperException(Exception e, String message) {
super(message);
this.e = e;
}

/**
 */
public void printStackTrace () {
super.printStackTrace();
String sep = System.getProperty("line.separator", "\r\n");
if (e != null) {
System.err.println("--- extended Exception
nest --- ");
e.printStackTrace();
}
}

/**
 * @param ps
 */
public void printStackTrace (java.io.PrintStream ps) {
super.printStackTrace(ps);
String sep = System.getProperty("line.separator", "\r\n");
if (e != null) {
ps.println("--- extended Exception nest ---
");
e.printStackTrace(ps);
}
}

/**
 * @param pw
 */
public void printStackTrace (java.io.PrintWriter pw) {
super.printStackTrace(pw);
String sep = System.getProperty("line.separator", "\r\n");
//
//Nested exception
if (e != null) {
pw.println("--- extended Exception nest ---
");
e.printStackTrace(pw);
}
}

/**
 * @return
 */
public String getMessage () {
StringBuffer message = new StringBuffer(150);
message.append(super.getMessage());

//
//add Line separator
String sep = System.getProperty("line.separator", "\r\n");
message.append(sep);

//
//Add the nested exception
if (e != null) {
message.append(e.getMessage());
    //char = props["line.separator"]
}
return  message.toString();
}
}



Rick Hightower
Director of Development
eBlox, Inc.

Check out our new website!
www.eblox.com

Contact Info:
eBlox Tucson
phone: 520-615-9345 x103
fax: 520-529-5774

Rick's stuff:
http://www.eblox.com/people_detail.php?id=52
http://www.geocities.com/rick_m_hightower/
http://www.brainbench.com/transcript.jsp?pid=2351036


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