RE: [PROPOSAL] Add Exception Handling to ActionForwards

[Hal Deadman]

The tiles:insert problem is discussed here
http://issues.apache.org/bugzilla/show_bug.cgi?id=13279

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 21, 2003 3:10 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Add Exception Handling to ActionForwards
> 
> 
> I tried implementing a simpler solution for Tiles controllers 
> by customizing 
> the RequestProcessor.  I discovered that the  
> tag also calls 
> the controller and just displays exceptions to the user.  I'm 
> a little 
> unsure about what to do at this point...
> 
> David
> 
> >I'll start with a specific situation:
> >Tiles allows you to configure a Controller class on a tile that gets 
> >executed whenever that tile gets used.  This is most 
> commonly used to 
> >prepare data for the tile from some datasource.  However, 
> the declarative 
> >exception handling feature does not apply to this, rendering 
> this Tiles 
> >feature fairly useless.
> >
> >The general feature idea:
> >The problem is that the RequestProcessor only invokes the exception 
> >handling mechanism on an Action's execute() method.  If we 
> extended this 
> >idea to handling exceptions from ActionForwards we could allow 
> >implementations to report errors that occurred while 
> forwarding and allow 
> >applications to recover gracefully.  As it is, I think a 
> ServletException 
> >get propagated up to the servlet.
> >
> >I believe the changes would include changing
> >RequestProcessor.processForwardConfig() throws IOException, 
> >ServletException
> >
> >to
> >
> >RequestProcessor.processForwardConfig() throws Exception
> >
> >and the 2 places that processForwardConfig() is called in 
> RequestProcessor 
> >would catch the Exception and pass it to processException().
> >
> >Thoughts?
> >David
> >
> >
> >
> 
> 
> _
> Tired of spam? Get advanced junk mail protection with MSN 8. 
> 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]

RE: [PATCH] for 13279

[Hal Deadman]

The second patch relies on the JSPException class with the root exception,
available in J2EE 1.3 (jsp1.2?). I think Struts may still be supporting J2EE
1.2 (jsp1.1?).

http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/jsp/JspException
.html

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

I don't think the fact that debug is enabled should be used to change the
exception handling. Normally log levels can be changed without any impact
other than increased or decreased verbosity.

Hal

> -Original Message-
> From: Jay [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 03, 2003 3:49 PM
> To: Struts Development
> Subject: [PATCH] for 13279
>
>
> Cedric et.al;
>
> Enclosed are two proposed patches for the "swallowing exception"
> behavior of taglib/tiles/InsertTag.java (Bugzilla #13279).  The first,
> "InsertTagNoFuncChange.txt", does what I originally suggested: merely
> move the real handling of processException to a method outside of the
> inner class to a protected method in InsertTag where sub-classing and
> overriding the default behavior can easily be done.
>
> The second patch ("InsertTagFuncChange.txt") does change the
> behavior by
> only "swallowing" the exception when the log4j debug level is enabled
> for the class.  If debug is not enabled, the exception will be wrapped
> and "re-thrown" as the root cause of a JspException.
>
> I think the second alternative is the better one because a default
> behavior of broadcasting exceptions on the web page is not
> particularly
> desirable.  However, I will be happy if either alternative is applied
>
> I have provided complete javadoc comments for both
> alternatives that you
> may change as required.
>
> Thank you,
> Jay
>
>
>


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

RE: [AXIS4STRUTS] The old In and Out

[Hal Deadman]

I am used to dealing with EJBs so I am probably not as sympathetic as I
should have been to people that have written web applications without EJBs.
In a sense, the business logic code in those non-EJB web apps is hidden away
from other applications that might want to use it, without copying it into
the other application's code base. The only way to access that code from
another application is to interface with the web application via HTTP.

I can see the appeal of exposing the web application's code as web services
using Axis. It seems like exposing Action classes directly as web services
will be more trouble than it's worth. It would seem better to move the code
in the Action class into another class (not tied to Struts/Web) which will
be used by the Action class and exposed directly as a web service running
inside the same web application.

> -Original Message-
> From: David Morris [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 24, 2003 4:59 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [AXIS4STRUTS] The old In and Out
>
>
> Hal and others,
>
> I agree with your analysis, however I think there is still some
> synergy.
> First, loading presentation directly from a Web service could
> be useful
>
> although this could be exposed directly through a custom tag so is
> really not that helpful.  Re-encoding a SOAP request to match the
> current
> Struts expectation would be redundant. Allowing SOAP based input
> to an action could reduce the amount of work necessary to test and
> build dual input systems.
>
> Traditionally, Struts has centered around HTML form based input, but
> I can see value in things like SOAP or SWT views. One problem is that
> Struts is still pretty rigid in this area and the view is generally
> defined
> through static JSP pages. I believe many are moving in different
> directions to a more dynamic form of form definition (I know I am and
> I am seeing questions that lead me to believe other are), which will
> make
> alternative views like SOAP and SWT more compelling.
>
> David Morris
>
> >>> [EMAIL PROTECTED] 01/24/03 12:54PM >>>
> Is the idea behind Axis for Struts to expose Action classes as Web
> Services?
> Ideally Action classes don't have any business logic in them. If that
> is the
> case, why not expose the business tier methods as web services
> directly? I
> think the EJB 2.1 specification's support for exposing Session bean
> methods
> as web services makes a good deal of sense.
>
> I am having a hard time seeing the benefits of Axis4Struts (aside from
> the
> benefits inherent in web services). It seems like a way to bail out
> people
> who mistakenly put valuable business logic in Action classes when the
> right
> thing to do would be to move that code out of the Action class.
>
> Axis and Struts, like ice cream and sex, are both good things, but I
> don't
> see much benefit to combining them.
>
> Hal
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

RE: [AXIS4STRUTS] The old In and Out

[Hal Deadman]

Is the idea behind Axis for Struts to expose Action classes as Web Services?
Ideally Action classes don't have any business logic in them. If that is the
case, why not expose the business tier methods as web services directly? I
think the EJB 2.1 specification's support for exposing Session bean methods
as web services makes a good deal of sense.

I am having a hard time seeing the benefits of Axis4Struts (aside from the
benefits inherent in web services). It seems like a way to bail out people
who mistakenly put valuable business logic in Action classes when the right
thing to do would be to move that code out of the Action class.

Axis and Struts, like ice cream and sex, are both good things, but I don't
see much benefit to combining them.

Hal

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 24, 2003 1:54 PM
> To: Struts Developers List
> Cc: [EMAIL PROTECTED]
> Subject: Re: [AXIS4STRUTS] The old In and Out
>
>
>
>
> Mike -
>
> > If we start with the idea [Kevin's suggestion] that on the
> Axis side we
> > develop a Web Service that accepts SOAP Requests with an
> XML payload and
> > spins that payload into an HTTP POST/GET to a Struts
> Application as if
> > that POST or GET was coming from a Web Browser.  Then we
> need not make
> > any changes to Struts to accept the request as Struts may
> not know or
> > need to know it was from Axis/SOAP (leave that to the application
> > developers).
>
> btw - I was thinking that this might just really be the
> easiest way to get
> something started. It may be better in the long run to try to
> 'embed' Axis
> in Struts directly and have Axis invoke the Struts MVC framwork
> programatically. But even so, I think there's value in
> allowing the Axis
> app and the Struts app to be on different servers - so both
> approaches may
> be good to implement.
>
> I think that the HTTP Post interface may be the best place to
> start because
> it looks easier and faster to get going on.
>
> > That presumption then begs some other questions:
>
> > What advantages should this Axis4Struts bring to the table?
>
> Primarily:
>
>  - Allowing developers already familiar with Struts to build
> Web Services
> apps without learning a great deal about Axis.
>  - Allow developers to build a basic Axis/Struts app and
> extend the web
> service offerings easily by just adding more 'Action's. I
> think this may
> make it easier to maintain/extend Web Service apps than currently.
>  - Allowing developers with existing Struts apps to extend
> them to handle
> non-browser clients (.NET, Swing, JMS, etc.)
>
> > What should we do over and above the minimum accepting of
> SOAP Requests
> > and spinning into an HTTP Browser emulated POST to Struts
> to add value?
>
> To begin with I'm thinking not much. After we get something
> built and get
> users on it, I believe this will be easier to answer.
>
> > Do we even bother with GET?
>
> Can't see any value for initial release.
>
> > Since any programmer can use commons-httpclient to form his own java
> > emulation of a browser POST to struts, what advantage can
> we bring with
> > Axis4Struts?
>
> Any programmer with a .NET client (or other non-java client) can't.
>
> Other tools (such as Cold Fusion) now provide built-in
> support for making
> calls to Axis services. This could be leveraged.
>
> Also, this may not be the only web service that the client
> app calls. If
> you have an app that is accessing a variety of web services
> and you want to
> extend it to leverage some existing functionality in a Struts app, why
> force the developer to write http-client posts?
>
> I think there is value in this project.
>
> > What would the WSDL for an Axis4Struts Web Service look like?  What
> > messages, what types, etc.
>
> I've put a some thought to this. Here's what I've been thinking:
>
> The HTTP Post to the Struts app requires a few things:
>
>   - A server/host and port
>   - A servlet context/module
>   - The Action ( ".do") URI
>   - Name/Value pairs for data (essentially an array of pairs)
>
> The WSDL should allow for these (and only these) I believe to
> begin with.
> This means the Axis app will be "very thin" to begin with.
> All items are of
> type String.
>
> I believe that it would be appropriate to let the first two (server
> host/port and servlet context/module) to be specified at
> deploy time (in
> the Axis wsdd file) to allow for default values. But the
> client code should
> be able to specify them in the SOAP request to over ride the
> defaults and
> allow the Web Service to expose resources from more than one
> Struts app
> through the same Web Service.
>
> > What should we do within the Struts framework to make it easier for
> > developers to have a Forward that returned an XML Payload
> suitable for
> > the Axis4Struts Response?
>
> This I've not got a clear vision of. I'm thinking that
> initially we create
> some sort of utility we can pass a form bean to

RE: TilesRequestProcessor in non-Tiles applications

[Hal Deadman]

Could you configure the Tiles plug-in first and then have your own plug-in
swap in your RequestProcessor implementation that extends
TileRequestProcessor? Then you might not need to extend ActionServlet. Not
sure if you can be sure what order the plug-ins run. Just a thought, haven't
looked into it.

> -Original Message-
> From: Heydtmann, Dirk [PCS] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 08, 2003 6:31 PM
> To: Struts Developers List
> Subject: TilesRequestProcessor in non-Tiles applications
>
>
> Hello:
>
> We would like to propose making the TilesRequestProcessor
> tolerant to where
> it does not choke on a regular (non-Tiles) application. Actually, the
> TilesRequestProcessor already "sort of" supports this, but
> not entirely.
>
> Background:
> In our company we have a legacy MVC framework that now wraps
> around Struts
> 1.1, and this legacy framework has its own request processor
> that needs to
> extend either the TilesRequestProcessor or the standard Struts
> RequestProcessor. Since we would like to keep things simple
> and do not want
> to duplicate our code, we want to extend just one request
> processor class,
> not both. That is why we decided to extend the
> TilesRequestProcessor and
> have our request processor be used for both Tiles and non-Tiles apps.
>
> Below are the two issues we ran into using this approach with
> Struts 1.1
> beta 3, and how we worked around them.
>
>   Issue 1:
>   TilesRequestProcessor expects the TilesUtil
> implementation
> of type TilesUtilStrutsImpl. But unless there is a
> TilesPlugin configured,
> nobody sets this implementation.
>   Workaround: we extended the ActionServlet and
> in its init()
> we are explicitly setting the implementation with
> "TilesUtil.setTilesUtil(new TilesUtilStrutsImpl());"
>
>   Issue 2:
>   TilesRequestProcessor's initDefinitionsMapping() logs an
> error, if a DefinitionsFactory has not been set, i.e. if the
> TilesPlugin has
> not been configured.
>   Workaround: non needed, this is just a nuisance. The
> TilesRequestProcessor still works OK.
>
> Thoughts?
>
>
> Dirk Heydtmann
> Sprint PCS - CAM Architecture
> (913) 794-4671
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

RE: Proposed: logic:else clause

[Hal Deadman]

I think the faster everyone moves from "logic" tags to JSTL the happier
everyone will be. The JSTL choose tag already supports if/elseif/else. The
expression language in JSTL makes logic easy that would be nasty with the
various logic tags.



...


...



http://www.manning.com/bayern/appendixA.pdf


> -Original Message-
> From: James Turner [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 03, 2003 4:44 PM
> To: [EMAIL PROTECTED]
> Subject: Proposed: logic:else clause
>
>
> I find in my code, I do the following a lot:
>
> 
> .
> .
> .
> 
> 
> .
> .
> .
> 
>
> I'd like to propose (and would be willing to code) the following:
> 
> .
> .
> .
> 
> .
> .
> .
> 
> 
>
>
> What do people think?
> James
>
> _
> James
> ICQ#: 8239923
> More ways to contact me: http://wwp.icq.com/8239923
> See more about me: http://web.icq.com/whitepages/about_me?Uin=8239923
> _
>
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

RE: [VOTE] How to implement XHMTL support

[Hal Deadman]

I agree with Martin that you can't ignore people using jsp:include. I prefer
his option B because then it allows someone to use the xhtml support in the
other tags without forcing them to use . They would have to set
the attribute themselves and assume the risks that go along with making
assumptions about how the tag is working.

> -Original Message-
> From: David Graham [mailto:dgraham1980@;hotmail.com]
> Sent: Wednesday, November 13, 2002 9:51 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] How to implement XHMTL support
>
>
> I'm still unclear on the direction we should take here.  I'd
> like to hear
> from other committers :-).
>
> Thanks,
> Dave
>
>
>
>
>
>
> >From: Martin Cooper <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: Struts Developers List <[EMAIL PROTECTED]>
> >Subject: Re: [VOTE] How to implement XHMTL support
> >Date: Tue, 12 Nov 2002 16:57:07 -0800 (PST)
> >
> >We need to ensure that HTML taglib tags in included JSP
> pages also heed
> >the xhtml attribute. That isn't the case with what's there
> now, because
> >findAncestorWithClass() will fail for the tags in the included pages.
> >
> >Note that this is why the form tag stores itself in a
> request attribute.
> >Originally, it also used findAncestorWithClass(), but it was
> changed to
> >allow forms to span pages.
> >
> >So I see two ways of handling this:
> >
> >A) Have the  tag store itself in a request attribute, and
> >change BaseHandlerTag.isXhtml() to grab the tag from there
> before calling
> >getXhtml().
> >
> >B) Have the  tag store the value of its 'xhtml'
> attribute as a
> >request attribute, and use that in BaseHandlerTag.isXhtml().
> >
> >Of these, I prefer the first approach because it makes it harder for
> >people to futz (technical term :) with the value in their pages.
> >
> >--
> >Martin Cooper
> >
> >
> >On Tue, 12 Nov 2002, David Graham wrote:
> >
> > > I've updated that html taglib tags to output xhtml when
> they are nested
> >in a
> > >  tag.  This was very simple to do
> and resulted
> >in
> > > minor code changes.  Users have suggested this approach:
> > >
> > > 1.  Add Globals.XHTML_KEY which is a boolean request
> scoped attribute
> > > 2.  html tags check for that request attribute being true
> and output
> > > accordingly.
> > > 3.  The html:html tag sets this request attribute when it's xhtml
> >attribute
> > > is true.
> > >
> > > The second approach allows the tags to output xhtml
> without relying on
> >the
> > >  tag.  This allows people to construct pages with jsp
> >includes.
> > > The first approach is logically clearer (to me) and you
> can use tiles to
> > > modularly construct the pages like includes.  Approach 2 may be
> >confusing
> > > because you would have to remember all the places you may
> have set that
> > > request attribute.
> > >
> > > So, do we go with 1, 2 or both?
> > >
> > > David
> > >
> > >
> > >
> > >
> > >
> > > _
> > > STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> > > http://join.msn.com/?page=features/junkmail
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> >
> > > For additional commands, e-mail:
> >
> > >
> > >
> >
> >
> >--
> >To unsubscribe, e-mail:
> >
> >For additional commands, e-mail:
> >
>
>
> _
> MSN 8 with e-mail virus protection service: 2 months FREE*
> http://join.msn.com/?page=features/virus
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

RE: Trying the developer list...

[Hal Deadman]

No you can't do that with bean:write. If you want a specific property,
specify the property in the html:messages tag and only messages with that
key will be itereated over.

> -Original Message-
> From: Michael Delamere [mailto:home@;michael-delamere.de]
> Sent: Wednesday, November 13, 2002 5:41 AM
> To: [EMAIL PROTECTED]
> Subject: Trying the developer list...
>
>
> Hi,
>
> I´ve tried answering the following question via the user-list
> twice and
> I have not yet received the solution that I am looking for.  I´ve been
> on this for quite some time now and cannot get it to work!
>
> Basically, I want to pass ActionMessages to my JSP using the
> methods and
> classes provided by struts.
>
> Here is the code in my Action:
>
> ActionMessages messages = new ActionMessages();
> ActionMessage newMessage = new
> ActionMessage("from.my.resourcebundle.text");
> messages.add("key.I.pass.to.jsp", newMessage);
> saveMessages(request, messages);
>
> // I also tried saving it directly
> //request.setAttribute(Action.MESSAGE_KEY, messages);
>
>
> Now in my JSP I would have the following:
>
> 
>  
> 
>
> Whenever I put this code into my JSP however, I get the error:
>
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:386)
> at
> org.apache.jasper.runtime.PageContextImpl.setAttribute(PageCon
> textImpl.j
> ava:229) at
> org.apache.struts.taglib.html.MessagesTag.doStartTag(MessagesT
> ag.java:25
> 3)
>
> Any help on this matter would be very much appreciated
> because I really
> need to get this working!
>
> Regards,
>
>
> Michael
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

RE: [SURVEY] HREF attribute for FormTag

[Hal Deadman]

--using tiles and container managed security/form based login -see below
> -Original Message-
> From: Craig R. McClanahan [mailto:craigmcc@;apache.org]
> Sent: Monday, October 28, 2002 4:14 PM
> To: Struts Developers List
> Subject: Re: [SURVEY] HREF attribute for FormTag
>
>
>
>
> On Mon, 28 Oct 2002, Alan P Sexton wrote:
>
> > Date: Mon, 28 Oct 2002 20:20:36 +
> > From: Alan P Sexton <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Re: [SURVEY] HREF attribute for FormTag
> >
> >
> > Here is a problem which _MIGHT_ benefit from the proposal.
> I am still
> > too much of a newbie to be sure but haven't found any
> discussion of it
> > in the lists or docs
> >
> > I'm using container managed security with form
> authentication. Because
> > of the context path prepending problem, I can't use FormTag for
> > j_security_check but must use HTML  instead. This
> means I can't
> > use the struts-html tags in the form.  I have not been able
> to get login
> > error messages handled in the login page in the way I used to when I
> > depended on programmatic security as per the struts example.
> >
> > I would like my login page to have the same look and feel
> as the rest of
> > my pages. I have not been able to figure out (yet) how to
> use tiles for
> > this page (which I use for the rest of my web app) and have
> been reduced
> > to manually simulating my tiles based layout (no great hassle but
> > annoying).
> >
>
> It's not going to be feasible to use the Struts HTML tags for the form
> login page even with such an attribute.  Among other things:
>
> * There is no such thing as a form bean associated with the
>   form login page, so you can't use the automatic redisplay
>   functionality anyway.
>
> * The servlet spec *requires* the use of "j_security_check" as
>   the submitted-to URL, and "j_username"/"j_password" as the
>   field names.  There isn't much value add in using the Struts
>   tag equivalents in these things, even if you could.
>
> > Perhaps with some guru magic all this is possible but I
> suspect that the
> > HREF attribute might help.
> >
>
> I don't see how the ability to use Tiles for layout management of this
> page is connected to use of the  tag with an "href".
>

I have a container managed security login page fragment that is a Tile and
don't recall having any problem. Is the problem that you are trying to
specify a tile as the ? My form is using HTML for the form
tag and the username and password fields. When I specify the login page, I
specify struts actions as follows to give me a little more control over what
I display on the login jsp. The login.do action is then mapped to a Tile
component that eventually contains a login.jsp. You can use the url
parameters to determine in your action if you need to display a message to
the user about their login attempt not working.


FORM
RpowerRealm

/login.do?type=attempt
/login.do?type=failed




> > Cheers,
> >
> > Alan
>
> Craig
>
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 


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

RE: [VOTE] How should Tiles be refactored?

[Hal Deadman]

I want to stay on this list but the volume of emails is getting a bit high
and I have work to do. I would appreciate it if emails that aren't adding
information to a thread were taken off list. It's nice to monitor the list
to keep tabs on what's going on but the quality of the traffic has declined
recently. The fact that there is lots of activity recently is good but we
don't need to hear from everyone unless they have something substantive to
add. No need to respond to this. If you agree, thanks, if not, keep sending
email whenever you feel like it and I will just set up a rule.

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 16, 2002 3:14 PM
> To: Struts Developers List
> Subject: RE: [VOTE] How should Tiles be refactored?
>
>
> Well, I know I'm not a committer and all , but
> for what its
> worth...
>
>
>  [   ] I want Tiles to have an independent (non-shared) configuration
> for each module.  No future change is required IMHO.
>
>  [   ] I want Tiles to have an independent (non-shared) configuration
>for each module.  I think we should revisit this
> decision after 1.1F.
>
>  [ x ] I DON'T think we should allow naked pictures of the
> committers on the
>main pageDOH  HAHAHAHA
>
>  [   ] I want tiles to have a (possibly) dependent (shared)
> configuration
>for each module in the 1.1F release.
>  - modules would chain lookup from the current
> module to the
>default module (or something else)
>  - could be turned on/off by a switch which
> defaults to off
>
>  [   ] I want tiles to have a different configuration (Elaborate).
>
>
>
> James "...and you thought I was serious for a sec huh?" Mitchell
> Software Engineer/Struts Evangelist
> http://www.open-tools.org
>
>
>
>
> > -Original Message-
> > From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, October 16, 2002 3:49 PM
> > To: Struts Developers List
> > Subject: [VOTE] How should Tiles be refactored?
> >
> >
> > There's been a lot of discussion on how 1.1 final should look, and I
> > think it's good to have such discussions.  We (commiters
> and non), being
> > tasked with implementing everything that "is" Struts 1.1,
> need to have a
> > clear picture of exactly what that means.  Now, when it
> gets right now
> > to brass tacks, it's irrelevant to me which way we go on
> this (right now
> > - I think my position is well-known).  Something has to be
> done though.
> >  Progress needs to be made, and to make progress we must
> have a clear
> > understanding of how we should proceed.
> >
> > Tiles will not work as expected with modules and that needs
> to be fixed.
> >  What form should it take?  I'm tired of speculation.  I'm happy to
> > study Tiles and determine what needs to change, but I will
> not take the
> > decision of how to implement it upon myself.
> >
> > Please bear in mind that we have folks waiting on 1.1F very
> anxiously
> > and that any behavior can be rectified in a later release.
> Also note
> > that refactoring to support a dependent configuration would not undo
> > (that I can see) any change which would be required to make the
> > configurations entirely independent.  That is a necessary step.  The
> > only question is if/when the next step of allowing sharing across
> > modules should occur.
> >
> > Cast your vote.
> >
> > [   ] I want Tiles to have an independent (non-shared)
> configuration
> > for each module.  No future change is required IMHO.
> > [   ] I want Tiles to have an independent (non-shared)
> configuration
> > for each module.  I think we should revisit this decision
> after 1.1F.
> > [   ] I want tiles to have a (possibly) dependent (shared)
> > configuration for each module in the 1.1F release.
> > - modules would chain lookup from the current
> module to the
> > default module (or something else)
> > - could be turned on/off by a switch which
> defaults to off
> > [   ] I want tiles to have a different configuration
> (Elaborate).
> >
> > --
> > Eddie Bush
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

RE: Plugins and Modules (Sub-Apps)

[Hal Deadman]

When I have had problems with a Class-Path entry in the manifest.mf of a
weblogic ejb jar file, I have always been able to fix the problem by adding
a space at the end of the line. Not sure if that would always fix it but
it's worth a try. I can't recall for sure if the problem was with Weblogic
or with the Ant EJB task but changing the length of the line has made the
problem go away on several occasions that I know of. There must be a weird
parsing error that manifests itself in some cases.

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 02, 2002 6:21 PM
> To: Struts Developers List
> Subject: Re: Plugins and Modules (Sub-Apps)
>
>
>
>
> On Wed, 2 Oct 2002, Eddie Bush wrote:
>
> > Date: Wed, 02 Oct 2002 14:32:43 -0500
> > From: Eddie Bush <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Re: Plugins and Modules (Sub-Apps)
> >
> > Compiling 1 source file to
> > /home/eddie/dvel/projects/jakarta-struts/target/library/classes
> > Note:
> >
> /home/eddie/dvel/projects/jakarta-struts/src/share/org/apache/
> struts/taglib/html/JavascriptValidatorTag.java
> > uses or overrides a deprecated API.
> > Note: Recompile with -deprecation for details.
> > Transforming into
> /home/eddie/dvel/projects/jakarta-struts/target/library
> > Manifest is invalid: The attribute "Class-Path" may not
> occur more than
> > once in the same section
> > build.xml [341] Invalid Manifest:
> > /home/eddie/dvel/projects/jakarta-struts/conf/share/MANIFEST.MF
> > BUILD FAILED
> >
>
> Sigh ... I wish product vendors would get this kind of thing
> right ... :-(
>
> The spec for MANIFEST.MF files *explicitly* allows more than one
> Class-Path entry, so the above error message is probably a bug in
> NetBeans.  You might recall that we split up the initial (very long)
> classpath line because WebLogic's JVM croaked on it, even
> though that is
> lega as well.
>
> Sheesh.
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

RE: DO NOT REPLY [Bug 8487] - Serializability issues in ActionServlet/RequestProcessor

[Hal Deadman]

I am using Struts and Weblogic 6/7 without any problems. I deploy my apps as
EAR files using the weblogic.deploy tool via Ant. The whole
build/deploy/test cycle is fairly slow and has me dreaming of .NET or a
decent laptop, but you do avoid the whole serializability problem that
occurs when you modify a JSP of an exploded EAR file. You also get a
consistent deployment package that you can target at your dev/test/prod
environments without worrying about people monkeying with the code on the
server.

(If you don't use weblogic.deploy for local builds, and just copy the EAR to
the applications directory, you will get periodic errors if weblogic tries
to hot deploy the ear in the middle of the file copy. )

Let me know if you want an example of using weblogic.deploy.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 23, 2002 2:05 PM
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 8487] - Serializability issues in
> ActionServlet/RequestProcessor
>
>
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> .
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8487
>
> Serializability issues in ActionServlet/RequestProcessor
>
>
>
>
>
> --- Additional Comments From [EMAIL PROTECTED]
> 2002-07-23 18:05 ---
> SRV.15.1.2 declares that HttpServlet implements Serializable.
>  Therefore all
> classes that extend HttpServlet must also implement Serializable.
> ActionServlet extends HttpServlet.  ActionServlet has a
> member variable
> (RequestProcessor processor) that is not Serializable and is
> not transient.  It
> doesn't even appear as though you use the member variable, as
> all uses of the
> RequestProcessor flow through getRequestProcessor.  Removing
> the member
> variable will resolve my issue with ActionServlet and I will
> then agree with
> you that there is a container issue with the ServletContext requiring
> attributes to be Serializable, and that if I want to use
> Struts with Weblogic
> 6.1 then I am out of luck.
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

html-setters.jsp and array form properties

[Hal Deadman]

Does anyone recall why the html-setters.jsp in the excercie-taglib app was
changed to no longer excercise the *Array properties of the TestBean.java
(see below)? Do the current form tags still support array methods on forms
if the form field names don't have the indexes ("formField[1]")? I could
have sworn that a simple array property in the form class used to handle
form fields with the same name but I don't see an example of that in
excercise taglib anymore. It looks like the array tests were removed from
html-setters.jsp about 18 months ago but I don't understand why. The current
tests only test the indexed properties that take an int index argument.

>From TestBean.java, no longer excercised in html-setters.jsp
/** * String arrays that are accessed as an array as well as indexed. */
private String stringArray[] = { "String 0", "String 1", "String 2", "String
3", "String 4" };
public String[] getStringArray() { return (this.stringArray); }
public void setStringArray(String stringArray[]) { this.stringArray =
stringArray; }

Thanks.

Hal Deadman
Tallan, Inc.


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

RE: DO NOT REPLY [Bug 7202] - Add forward attribute to FormTag to allow submision to a global forward

[Hal Deadman]

Does using the forward attribute mean creating a global forward for every
action submitted to by a form? If so you end up with lots of global-forwards
that map directly to actions, so why not just use the action URL?

This seems like just one more level of indirection that has to be followed
when you are trying to figure out which action class a form is submitting to
(if you are looking at the JSP, not the HTML source).

Hal

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 03, 2002 6:20 PM
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 7202] - Add forward attribute to FormTag to
> allow submision to a global forward
>
>
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> .
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7202
>
> Add forward attribute to FormTag to allow submision to a
> global forward
>
>
>
>
>
> --- Additional Comments From [EMAIL PROTECTED]
> 2002-07-03 22:19 ---
> And so ... if the forward.getPath() did not resolve to an
> ActionMapping, it
> would generate the same error that is generated if were
> hardcoded that way. So,
> the suggestion is not that we want the html:form to submit to
> anything but an
> ActionMapping, we are just looking for a cannonical way to
> deliver the
> ActionMapping path to the form at runtime, without resorting
> to a RTE.
>
> -T.
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

RE: Subapps and /WEB-INF (was: Re: DO NOT REPLY [Bug 10268] - Sub-apps need context-relative option for 'input' of an Action)

[Hal Deadman]

Those changes sound fine but is "forward" a good name for the new action
attribute? I think inputforward provides a slightly better description of
what the attribute is used for. I have always thought that it was not clear
that the attributes "name", "input", "validate", and "scope", all refer to
the action form (or at least they only apply if there is a form) but they
are attributes of the action. I think adding forward would be similarly
confusing.

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 01, 2002 3:11 PM
> To: Struts Developers List
> Subject: Subapps and /WEB-INF (was: Re: DO NOT REPLY [Bug 10268] -
> Sub-apps need context-relative option for 'input' of an Action)
>
>
> Martin raises some interesting issues in this enhancement
> request that I'd
> like to discuss a little before we figure out what to do.
>
> The simplest issue is a design faux pas in the original struts-config
> setup -- the "input" parameter really should have been the name of a
> corresponding forward, so that we could auto-calculate the
> actual URL more
> gracefully.  We can't change the past, but it wouldn't be
> hard to add an
> additional "forward" attribute as an alternative to "input",
> that works
> this way.  What do you think?
>
> The more important issue Martin raises is that the algorithm for
> sub-application mapping (context-relative prefix) doesn't
> play very nice
> with folks who want to put their JSP pages in the /WEB-INF
> subdirectory.
> One way to get around this would be to modify the algorithm
> for converting
> a subapp-relative path into an absolute path in
> RequestUtils.computeURL().
> Instead of always sticking the subapp prefix before the
> specified path,
> it would look at the subapp-relative path and, if it started with
> "/WEB-INF" and perform the appropriate surgery.  Thus, a
> forward to the
> subapp relative page "/WEB-INF/foo.jsp" in subapp "/mysubapp"
> would end up
> creating the URL:
>
>   /WEB-INF/mysubapp/foo.jsp
>
> instead of the current:
>
>   /mysubapp/WEB-INF/foo.jsp
>
> While this is sort of a kludge (and the whole algorithm is
> something that
> should be more easily pluggable in a post-1.1 design), it
> *is* backwards
> compatible with current usage without subapps (i.e. the path
> of a page for
> the default subapp is the same as it is now).
>
> What do you think about implementing both of these options
> (new "forward"
> option on , and the calculation change)?  Together, I
> think they
> address what Martin is after, and deals with the more general
> problems of
> using subapps together with /WEB-INF.
>
> Craig
>
>
> On 1 Jul 2002 [EMAIL PROTECTED] wrote:
>
> > Date: 1 Jul 2002 18:10:02 -
> > From: [EMAIL PROTECTED]
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: DO NOT REPLY [Bug 10268]  - Sub-apps need
> context-relative
> > option for 'input' of an Action
> >
> > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> > .
> > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> > INSERTED IN THE BUG DATABASE.
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10268
> >
> > Sub-apps need context-relative option for 'input' of an Action
> >
> >
> >
> >
> >
> > --- Additional Comments From [EMAIL PROTECTED]
> 2002-07-01 18:10 ---
> > The problem is, my JSP pages are under WEB-INF, and the
> computed URL messes up
> > the path to that directory. If my action config looks like this:
> >
> >   
> >
> > then the computed URL looks like this:
> >
> >   /myApp/mySubApp/WEB-INF/pages/myPage.jsp
> >
> > which is incorrect - the sub-app name should not be there.
> It needs to be:
> >
> >   /myApp/WEB-INF/pages/myPage.jsp
> >
> > to work correctly.
> >
> > There was also a thread on struts-user a while ago where
> someone else was
> > having a similar problem:
> >
> > http://marc.theaimsgroup.com/?l=struts-user&m=101865931500963&w=2
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

RE: Security issues with Struts

[Hal Deadman]

This does sounds like a problem if you use session scoped forms. It seems to
me like a good reason not to use session scoped forms and another reason to
minimize use of the session in general. Sessions have other problems that
arise when a user opens multiple browsers for example. It also argues for
ensuring that your model layer code doesn't rely on validation done in the
presentation layer (especially if it's an internet banking application). I
am not saying your idea for session synchronization wouldn't work but you
could work around it and you would probably be better off in the end.

Hal

> -Original Message-
> From: Marcel Kruzel [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 01, 2002 2:46 AM
> To: [EMAIL PROTECTED]
> Subject: Security issues with Struts
>
>
> Hello Struts developers,
>
> We are now developing an internet banking
> application with Stuts of course.
> Of course, we are highly concerned
> in possible security holes in the framework
> (or in the application using the framework).
> I believe, there is one, that, when properly
> used, can cause some troubles for developers!
>
> Here it is:
>
> Imagine a scenario, where user submits a form,
> the Struts automatically populate the
> form bean and then
> the validation of the parameters takes place.
> After that, if OK, the perform method is called.
> Here, I already know, that the
> params were ok, so I write the
> transaction to database. The problem here
> is the perform method. When precisely at the
> moment of perform method call user decides
> to submit the form once again (with
> different values of course), the form bean
> is again populated, and possibly wrong
> (not validated) data might be writen to database
> (by the first thread, that is not aware
> of the second submit).
> I am afraid, there is not a possibility to
> synchronize acccess to the form,
> since the population of form bean is automatic.
>
> I know, that the solution to the problem here is
> in the perform method
> to make copy of the parameters and then validate
> them again. Or, I can
> make validation only in the perform method,
> but first I have to remove the
> form bean from session, then validate
> and then write to database, and then possibly
> return that form bean to the session.
>
> Sorry for so long description,
> but I tried to make myself as clear as possible.
>
> My preferred solution to the problem would be:
> In the struts-config.xml put an attribute
> to action, describing, that handling
> such an action requires session synchronization.
> Thus everything, starting from form population
> and ending with "return mapping.findForward(...)"
> would be synchronized on a session object.
> (I do this synchronization on a session
> anyway - in each perform method).
>
> So, what do You think?
>
> Thanx to all contributors
> for such a great framework,
> and enjoy the summer.
>
> Marcel Kruzel
> Czech Republic
>
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

RE: Tiles And Struts

[Hal Deadman]

I vote for fewer jar files. I have so many jars in my ear and war that when
weblogic uses jikes to compile my jsps, the maximum DOS command line length
is exceeded. I pre-compile my jsps with Ant and the paths are shorter than
in the server directory so it's not a problem now but I could be getting
close.

Seperating the commons stuff made sense because they are useful without
struts but I don't see enough benefit to breaking up struts.jar any more. I
suppose the build script could offer the complete struts.jar and also build
the other jars if people needed them broken out.


> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 27, 2002 11:08 AM
> To: Struts Developers List; [EMAIL PROTECTED]
> Subject: Re: Tiles And Struts
>
>
>
>
> On Thu, 27 Jun 2002, Ted Husted wrote:
>
> > Date: Thu, 27 Jun 2002 06:37:07 -0400
> > From: Ted Husted <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> >  [EMAIL PROTECTED]
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Re: Tiles And Struts
> >
> > "Craig R. McClanahan" wrote:
> > > ... once the basic integration is done.
> >
> > So, will there still be a separate tiles.jar, or is that going to be
> > rolled into the Struts.jar too?
> >
>
> The core classes are already merged in, so you won't need a separate
> tiles.jar.  I've also merged in the creation of
> struts-tiles.tld (instead
> of tiles.tld) in the same fashion as the others.
>
> > Not for nothing, but maybe this would be a good time to
> also split the
> > distribution into two jars, struts-core.jar and struts-taglib.jar.
> >
>
> I understand the concept and the reasoning.  My only concerns are:
>
> * What is the harm in having classes in struts.jar that you do
>   not use?  They're never loaded anyway, and the disk occupancy
>   is minimal.  (And I'd bet nobody loads all the "core" classes
>   either.)
>
> * I'm sure that I am not the only user that has lots of Ant build.xml
>   files with a "${struts.jar}" property referring to "the" JAR file
>   that needs to be added into a classpath, or copied into WEB-INF/lib.
>
> > While the vast majority of Struts applications will use the
> taglibs, a
> > growing number are using other technologies. Expresso and Stxx offer
> > some slick XLS support for Struts. The Velocity View Tools
> are another
> > tag-free alternative. More are sure to follow.
> >
> > Meanwhile, as we shift to the JSTL, our taglibs, as good as
> they are,
> > start to become more and more of an optional component. Since we are
> > making so many other JAR changes this cycle, it seems like
> a good time
> > to do this too.
> >
>
> I guess it probably is appropriate timing if we want to do
> this -- but it
> seems more like a marketing gimic than a technical necessity.
>
> > -T.
> >
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

RE: multipart requests + forwarding = bug

[Hal Deadman]

The subject of this email doesn't seem to match the body but if you are
referring to bug reports about the multipart requests and forwarding, there
are a couple in bugzilla already.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8732
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9760 (duplicate)

Hal

> -Original Message-
> From: Rob Leland [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 12:46 PM
> To: Struts Developers List
> Subject: multipart requests + forwarding = bug
>
>
> I haven't experienced this bug but my office mate mentioned
> he experienced it, he is not here today. There also seems to been some
> discussion, and several different patches floating around to fix this.
>
> If this is still a problem could someone who has experienced this
> file a BUG report at http://nagoya.apache.org/bugzilla/
>
> I'll see that it gets fixed.
>
> -Rob
>
>
>
>
> Matt Raible wrote:
>
> >You might try matching up your form names in your
> validation.xml file:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >Should be "logonForm" according to struts-config.xml.
> >
> >HTH,
> >
> >Matt
> >--- Struts-dev Newsgroup <[EMAIL PROTECTED]> wrote:
> >
> >>Subject: Validation on DynamicForm problem
> >>From: "Tomas" <[EMAIL PROTECTED]>
> >> ===
> >>Hello,
> >>
> >>how, to make verification (validation) of dynamic forms ?
> >>
> >>in struts-config.xml  is:
> >>
> >>
> >>
> >>
> >>
> >>.
> >>
> >>.
> >>
> >>.
> >>
> >> >>
> >>type="org.apache.struts.validator.DynaValidatorActionForm">
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> >>
> >>name="logonForm"
> >>
> >>validate="true"
> >>
> >>scope="session"
> >>
> >>input="/index.jsp">
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> >>
> >>parameter="org.apache.struts.webapp.validator.ApplicationRes
> ources"/>
> >>
> >>
> >>
> >>
> >>
> >> >>
> >>value="/WEB-INF/validator-rules.xml,/WEB-INF/validator.xml"/>
> >>
> >>
> >>
> >>.
> >>
> >>.
> >>
> >>.
> >>
> >>
> >>
> >>
> >>
> >>in file validator.xml is:
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>in web.xml is:
> >>
> >>
> >>
> >>
> >>
> >>action
> >>
> >>org.apache.struts.action.ActionServlet et-class>
> >>
> >>
> >>
> >>application
> >>
> >>ApplicationResources
> >>
> >>
> >>
> >>
> >>
> >>config
> >>
> >>/WEB-INF/struts-config.xml
> >>
> >>
> >>
> >>
> >>
> >>debug
> >>
> >>3
> >>
> >>
> >>
> >>
> >>
> >>detail
> >>
> >>3
> >>
> >>
> >>
> >>
> >>
> >>validate
> >>
> >>true
> >>
> >>
> >>
> >>2
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>no efect in edit form, always (but still) error messages:
> >>
> >>
> >>
> >>747375 [HttpProcessor[80][4]] DEBUG
> >>
> >>org.apache.struts.action.RequestProcessor - Validating input form
> >>
> >>properties
> >>
> >>747375 [HttpProcessor[80][4]] DEBUG
> >>
> >>org.apache.struts.action.RequestProcessor - No errors
> detected, accepting
> >>
> >>input
> >>
> >>
> >>
> >>Can you help?
> >>
> >>Second question is, how to used text fields (width
> indexed=true) on dynamic
> >>forms?
> >>
> >>[EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:

>>For additional commands, e-mail:

>>
>
>
>__
>Do You Yahoo!?
>Yahoo! - Official partner of 2002 FIFA World Cup
>http://fifaworldcup.yahoo.com
>
>--
>To unsubscribe, e-mail:

>For additional commands, e-mail:

>
>
>



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


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

RE: Scalability question

[Hal Deadman]

I do make my Business delegates instance variables of my Action classes
because they are thread-safe (and the controller does have to depend on the
model). They are light-weight objects but it's nice that I only have to
create them once, which I can do in the constructor because there is only
one instance of each Action.

My business delegates use a singleton ServiceLocator class that caches the
InitialContext and EJB home interfaces that are looked up (thank-you EJBX).
I rely on the container to make creating session bean remote interfaces
efficient.

If someone is doing Struts, they should already be familiar with the way
Servlets&JSPs have to be made thread-safe so I don't think it should be a
problem for novice programmers.

I am not trying to come across as an authority, I am just speaking from my
experience and I like the fact Action classes are only created once.

Hal

> -Original Message-
> From: Steven D. Monday [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 13, 2002 9:53 AM
> To: Struts Developers List
> Subject: RE: Scalability question
>
>
>
> Hal,
>
> Thanks for the reply.  I don't think I was attempting to make
> a point as
> much as learn some of the rationale behind the choice of a
> single action
> instance as opposed to creating an action instance perhaps upon every
> request for example.  A couple follow up questions.
>
> > Action classes aren't supposed to have any kind of serious business
> process.
>
> I didn't mean to imply that an action class itself would
> implement serious
> business logic itself.  However, unless I'm misunderstanding
> the role of an
> action class I would assume that it would perhaps instantiate
> a business
> object and ask it to perform some service.  My point was that
> in the act of
> performing a service the business object would likely exhaust more cpu
> cycles/memory than would be expending creating an action
> class instance and
> garbage collecting it.  What motivated me to ask this question was the
> following verbage I found on Martin Fowler's site:
> http://www.martinfowler.com/isa/frontController.html, regarding front
> controller command classes and thread-safety:
>
> "Since you create new command object with each request, you
> don't have to
> worry about making the command classes thread safe. This can avoid the
> headaches of multi-threaded programming. You do have to make
> sure that you
> don't share any other objects, such as the model objects."
>
> > Also, if you are creating an Action for every request,
> there isn't much
> > point in having  instance variables that might cause serialization
> issues,
> > so why have more than one instance?
>
> In principle I agree.  However, again in reality it many
> times is the case
> that developers don't consider thread safety issues as closely as they
> should.  This reality coupled with Martin's comments above
> made me curious
> as to what maintaining a single instance of commands buys you.
>
> Again, not saying maintaining a single instance of actions is
> not good or
> perhaps the best approach, just looking to understand.
>
>   Thanks
>   Steve
>
>
>
>
>
>
> "Hal Deadman"
>
> 
> allan.com>
>
>
>
> 05/13/2002
>
> 08:22 AM   To: "'Struts Developers
> List'" <[EMAIL PROTECTED]>
> Please respond cc:
>
> to "Struts
>
> Developers
>
> List"
>
>   Subject: RE:
> Scalability question
>
>
>
>
>
> Caterpillar: Confidential Green  Retain Until: 06/12/2002
>  Retention Category:  G90 -
>  Information and Reports
>
>
>
>
> Action clases aren't supposed to have any kind of serious
> business process.
> You should keep your business objects "Struts-free". That's
> why you don't
> pass ActionForms directly to EJBs or business components.
> Struts needs to
> stop at the view-controller because the model should not depend on the
> view.
>
> Also, if you are creating an Action for every request, there
> isn't much
> point in having  instance variables that might cause
> serialization issues,
> so why have more than one instance? If you are saying that
> there should be
> one Action instance per session then I would argue that you
&g

RE: Scalability question

[Hal Deadman]

Action clases aren't supposed to have any kind of serious business process.
You should keep your business objects "Struts-free". That's why you don't
pass ActionForms directly to EJBs or business components. Struts needs to
stop at the view-controller because the model should not depend on the view.

Also, if you are creating an Action for every request, there isn't much
point in having  instance variables that might cause serialization issues,
so why have more than one instance? If you are saying that there should be
one Action instance per session then I would argue that you should manage
your use of the session seperately, it's not in the Action classes' domain.

Hal

> -Original Message-
> From: Steven D. Monday [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 13, 2002 8:57 AM
> To: Struts Developers List
> Subject: RE: Scalability question
>
>
>
> In the paragraph below Craig mentioned that the "same one
> (action instance)
> is reused continuously".  I'm curious as to the rationale behind
> maintaining a single instance of each action class,
> especially given that
> it does introduce the requirement (unfortunately not always
> understood by
> developers) that actions be written in a reentrant fashion.
> I'm assuming
> that it was perhaps a performance optimization?  However, it
> seems that if
> an action class invokes any kind of serious business process that the
> time/resources expended creating (even reflectively) and destroying an
> action instance would pale compared to time/resources expended by the
> business object model.  Just curious.
>
>  Thanks
>  Steve
>
> >Action instances have exactly the same thread processing
> characteristics
> >as non-STM servlets - the single instance is utilized by
> multiple requests
> >(on different threads) simultaneously.  This has two important
> >implications:
>
> >* You (and Struts) don't have to worry about pooling Action
> instances -
> >  the same one is reused continuously, with no locking or allocation
> >  overhead.
>
> >* You must program your Action instances in a thread-safe manner.
> >  The most important rule is to not store any per-request state
> >  information in instance variables in the Action class.
>
>
>
>
> "Craig R.
>
> McClanahan"
>
> 
> che.org>
>
>
>
> 05/10/2002To: Struts Developers List
> <[EMAIL PROTECTED]>
> 06:23 PM  cc:
>
> Please
>
> respond to
>
> "Struts
>
> Developers   Subject: RE:
> Scalability question
> List"
>
>
>
>
>
>
>
>
> Caterpillar: Confidential Green  Retain Until: 06/09/2002
>  Retention Category:  G90 -
>  Information and Reports
>
>
>
>
>
>
> On Fri, 10 May 2002, David Cherryhomes wrote:
>
> > Date: Fri, 10 May 2002 15:14:34 -0700 (PDT)
> > From: David Cherryhomes <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: RE: Scalability question
> >
> > I'm sorry, maybe I was unclear. I am not challenging the
> > usefulness of Struts, I am well aware of the vast amount of
> > functionality that the framework encompasses. I am currently
> > using Struts as a core part of the MVC approach in my enterprise
> > application. My question is about the scalability of Struts
> > Action classes.
> >
> > It is my understanding that a Servlet engine will create new
> > instances/threads of a Servlet as needed (similar to stateless
> > session beans), and hence is very scalable for multiple
> > concurrent requests.
>
> This is true only if your servlet implements the
> SingleThreadModel (STM)
> interface.  If it doesn't, a single instance of your servlet
> is allocated
> and is shared by all concurrent requests.  The Struts
> controller servlet
> is an example of this (it is not an STM servlet) -- there is
> one and only
> one instance of this servlet for your webapp.
>
> > My understanding is that an Action class,
> > on the other hand, is stored as an instance variable.
>
> The set of Action instances that have been created are stored
> in a servlet
> instance variable, but they are reused on multiple requests
> for the same
> action.  In fact, Struts makes a similar guarantee about
> Action instances
> to what the servlet container promises about non-STM servlets -- there
> will be at most one occurrence of any given Action
> implementation class.
>
> > The
> > question is this: if I have a class that performs a massive
> > amount of business processes (inclusive of attaching to multiple
> > EJB's), will the multiple concurrent requests end up queued in a
> > wait status until each one is finished processing, or is there a
> > multiple instance/thread approach

RE: Scalability question

[Hal Deadman]

As long as there are no synchronization issues with your Action class
then it shouldn't be a bottleneck. I don't even know why an application
server would create more than one instance of a servlet. The doGet()
method on a servlet or the process() method on an Action class can be
called by as many concurrent threads as your application server wants to
use and it shouldn't be a problem.There is no waiting or queueing
going on. 

Every thread gets their own copy of the local variables in the method.
You can have instance variables in the Action class (like a Business
Delegate or session bean home interface) as long as they are created
once in the constructor and only contain "thread safe" methods with no
synchronization issues. 

This is not to say that Struts doesn't have some overhead but so do
EJBs, databases, networks, etc. You use them because they make your code
more maintainable and increase productivity. Performance problems are
almost always going to come from bad code or database mis-use rather
than a framework like Struts. 

Hal

> -Original Message-
> From: David Cherryhomes [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 10, 2002 6:15 PM
> To: Struts Developers List
> Subject: RE: Scalability question
> 
> 
> I'm sorry, maybe I was unclear. I am not challenging the
> usefulness of Struts, I am well aware of the vast amount of
> functionality that the framework encompasses. I am currently
> using Struts as a core part of the MVC approach in my enterprise
> application. My question is about the scalability of Struts
> Action classes.
> 
> It is my understanding that a Servlet engine will create new
> instances/threads of a Servlet as needed (similar to stateless
> session beans), and hence is very scalable for multiple
> concurrent requests. My understanding is that an Action class,
> on the other hand, is stored as an instance variable. The
> question is this: if I have a class that performs a massive
> amount of business processes (inclusive of attaching to multiple
> EJB's), will the multiple concurrent requests end up queued in a
> wait status until each one is finished processing, or is there a
> multiple instance/thread approach to Action classes (similar to
> a Servlet engine with Servlets)?
> 
> The enterprise application I'm working on isn't for some
> website, but a truly web-deployed enterprise app which must
> scale to thousands of concurrent users with millions of records
> in the DB. Thus, performance is a HUGE concern (e.g., a wait of
> 500 miliseconds is about the max permitted).
> 
> Thanks
> 
> --- James Mitchell <[EMAIL PROTECTED]> wrote:
> > Yes, you can create your entire web site with only servlet
> > filters, jsp, and
> > a few beans.
> > 
> > And at some point you will find out what struts does for you
> > (the hard way)
> > and why it is superior to all other Java Web Application
> > Development
> > Frameworks.
> > 
> > I hope this helps.
> > 
> > JM
> > 
> > "Its a dog-eat-dog world out there, and I feel like I'm
> > wearing milkbone
> > underwear!"
> >   Guess who?
> > 
> > 
> > > -Original Message-
> > > From: David Cherryhomes [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, May 10, 2002 5:27 PM
> > > To: Struts Developers List
> > > Subject: Scalability question
> > >
> > >
> > > Have there been any solid tests in regards to the
> > scalability of
> > > using the Action Servlet and Action class (as opposed to
> > using a
> > > single Filter servlet which forwards to other Servlets)? I
> > am
> > > especially concerned since my Action class connects (thru a
> > > BusinessDelegate) to one or more EJB's that are really
> > > responsible for processing the business logic.
> > >
> > > Any thoughts on this would be greatly appreciated.
> > >
> > > __
> > > Do You Yahoo!?
> > > Yahoo! Shopping - Mother's Day is May 12th!
> > > http://shopping.yahoo.com
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > 
> > > For additional commands, e-mail:
> > > 
> > >
> > >
> > 
> > 
> > --
> > To unsubscribe, e-mail:  
> > 
> > For additional commands, e-mail:
> > 
> > 
> 
> 
> __
> Do You Yahoo!?
> Yahoo! Shopping - Mother's Day is May 12th!
> http://shopping.yahoo.com
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 



smime.p7s
Description: application/pkcs7-signature

RE: Struts Improvement Proposal: Logic Extensibility

[Hal Deadman]

It sounds like what your trying to do falls outside of the Struts mandate to
aid in the VC of an MVC application. Action classes aren't supposed to do
any processing themselves, they just invoke methods on business objects,
load some context with whatever the jsp needs, and return forwards.

If you want some sort of XML driven processing engine for your business
logic, that is outside the scope of Struts. Action classes should be
extremely simple, and there will be lots of them, one or two per jsp. You
shouldn't try to hard to re-use them. Re-use your business objects from
different action classes, make those modular.

> -Original Message-
> From: Phase Web and Multimedia [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 25, 2002 6:36 PM
> To: Struts Developers List
> Subject: RE: Struts Improvement Proposal: Logic Extensibility
>
>
> You are correct, it does sound like an Action class and
> really it would be
> in many ways. But, The difference is that it does not forward
> anywhere it
> merely performs data preparation and processing without
> having to bounce
> around to several Action classes. The Action uses the process
> chain defined
> in the process.xml doc to prepare data for the view. The
> action could still
> do specific functions that it needs to do to then route to
> the proper view.
>
> My thoughts were also that the processing of the Process
> chain could be
> specified to happen either pre or post (not sure though, I
> haven't gotten
> that far in my thoughts).
>
> I imagine also there might be some conditional issues. But,
> that is why I
> don't want to make it an Action class. It is possible though
> that maybe this
> would be taken further. I just think that we have to be able
> to reuse more
> logic easier. The current structure requires a fair amount of
> predertermination and not quite enough modularity.
>
> Brandon Goodin
> Phase Web and Multimedia
> P (406) 862-2245
> F (406) 862-0354
> [EMAIL PROTECTED]
> http://www.phase.ws
>
>
> -Original Message-
> From: Tim Moore [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 25, 2002 3:41 PM
> To: Struts Developers List
> Subject: RE: Struts Improvement Proposal: Logic Extensibility
>
>
> Does the interface of a Process differ at all from Action? This sounds
> like something that could possibly be implemented now by making a
> ChainingAction or some such that simply called the perform method of a
> (configurable) list of other action classes.  How does the servlet
> determine the view to ultimately forward to?  I could imagine either
> using the return value of the last Process or using the first non-null
> return value if you wanted to allow intermediate steps to break out of
> the process.
> --
> Tim Moore / Blackboard Inc. / Software Engineer
> 1899 L Street, NW / 5th Floor / Washington, DC 20036
> Phone 202-463-4860 ext. 258 / Fax 202-463-4863
>
>
> > -Original Message-
> > From: Phase Web and Multimedia [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, April 25, 2002 5:32 PM
> > To: Struts Developers List
> > Subject: Struts Improvement Proposal: Logic Extensibility
> >
> >
> > Okay here is the idea I proposed earlier ("Struts (MVC)
> > Shortcomings?") in more solid thought.
> >
> > My hope in this is to provide an non-hard-coding mechanism to
> > take advantage of reusable logic without having to forward
> > around to a bunch of Action classes (which doesn't work anyways).
> >
> > Here is my proposal:
> >
> > An action mapping could have an associated Process Config
> > specified in the  of the action class.
> > Something like: 
> >
> > An associated config file called processor.xml could be set
> > up to define process patterns that have names associated with
> > the value attribute of the set-property. Something like: 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > This config info could be placed into the Application Scope
> > at the app startup using the plugin mechanism of Struts 1.1.
> >
> > When an Action is called it would look to see what "process
> > group" it needs to call and using reflection to perform the
> > specified chain of processing in the order specified in the
> > process-groupname config.
> >
> > A process class would conform to an interface and would have
> > access to everything that the Action has access to. This way
> > any errors or scoped beans/Attributes that need to be set can
> > be set from within the process class. Also, the process class
> > could access other logic beans for sql and such.
> >
> > Any unique coding that needs to happen can still be contained
> > in an Action class. But for code that is reusable. This would
> > be very nice.
> >
> > Brandon Goodin
> > Phase Web and Multimedia
> > P (406) 862-2245
> > F (406) 862-0354
> > [EMAIL PROTECTED]
> > http://www.phase.ws
> >
> > -Original Message-
> > From: Phase Web and Mu

RE: multipart/form-data (bug?) or intended behavior?

[Hal Deadman]

I haven't had a chance to test whether the request parameters are still available. 
Without the patch, the processActionForward() method will call doForward() if 
redirect="false" which calls RequestDispatcher.forward(). That will always fail if the 
wrapped request is used. Does it matter if getParameter() works or not in the actions 
that follow the first action? If that limitation exists I think it's preferable than 
getting an error. 

Currently if the input attribute specified for the target after failed validation is 
an action or if you try to forward to an action from the first action execute method 
with redirect=false, then you get an error eventually after the actions execute method 
is called. 

After I submitted this patch, I thought it might not be the best way if anyone out 
there is extending RequestProcessor.java. Are there any struts extensions like Tiles 
or Velocity that extend that? If they are overriding doForward() or doInclude() then 
they need to be sure they unwrap the request before dispatching it. 

Hal


> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, April 21, 2002 12:49 AM
> To: Struts Developers List; [EMAIL PROTECTED]
> Subject: Re: multipart/form-data (bug?) or intended behavior?
> 
> 
> Hal,
> 
> With this patch, are the original request parameters still 
> available in the
> target action or JSP? For a multipart request, the request 
> wrapper is where
> the parameters are maintained so that request.getParameter() 
> and friends
> work as usual.
> 
> If that all works, could you enter a bug report in bugzilla 
> and attach your
> patch to it? That will ensure that we don't lose track of it.
> 
> Thanks.
> 
> --
> Martin Cooper
> 
> 
> - Original Message -
> From: "Hal Deadman" <[EMAIL PROTECTED]>
> To: "'Struts Developers List'" <[EMAIL PROTECTED]>
> Sent: Friday, April 19, 2002 10:38 AM
> Subject: RE: multipart/form-data (bug?) or intended behavior?
> 
> 
> > The attached version of RequestProcessor.java fixed the multipart
> > request forwarding issue that we were experiencing. Here is 
> the patch
> > diff and I attached the old and new versions of 
> RequestProcessor.java.
> > The patch just makes sure that the request is always 
> unwrapped before
> > forwarding by moving the unwrap code to doForward() and 
> doInclude(). It
> > could also just be added to processActionForward().
> >
> > 534a535,539
> > > // Unwrap the multipart request (if any)
> > > if (request instanceof MultipartRequestWrapper) {
> > > request = ((MultipartRequestWrapper)
> > request).getRequest();
> > > }
> > >
> > 568a574,578
> > > // Unwrap the multipart request (if any)
> > > if (request instanceof MultipartRequestWrapper) {
> > > request = ((MultipartRequestWrapper)
> > request).getRequest();
> > > }
> > >
> > 932a943,945
> > > if (request instanceof MultipartRequestWrapper) {
> > > request = ((MultipartRequestWrapper)
> > request).getRequest();
> > > }
> > 952,956d964
> > < // Unwrap the multipart request (if any)
> > < if (request instanceof MultipartRequestWrapper) {
> > < request = ((MultipartRequestWrapper)
> > request).getRequest();
> > < }
> > <
> > 981,985d988
> > < // Unwrap the multipart request (if any)
> > < if (request instanceof MultipartRequestWrapper) {
> > < request = ((MultipartRequestWrapper)
> > request).getRequest();
> > < }
> > <
> > 1058a1062
> > >
> >
> >
> >
> > -Original Message-
> > From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, April 19, 2002 8:12 AM
> > To: Struts Developers List
> > Subject: RE: multipart/form-data (bug?) or intended behavior?
> >
> >
> > Can't this multi-part request forward problem be fixed by 
> unwrapping the
> > request before doing RequestDispatcher.forward/include? All 
> the methods
> > in RequestProcessor get the real request object from within the
> > MultipartRequestWrapper before calling doForward() or 
> doInclude() except
> > for processActionForward() which gets called after action.execute().
> >
> > I think the
> > if (request instanceof MultipartRequestWrapper) {
> > request = ((MultipartRequestWrapper) 
> request).getRequest();
> &