DO NOT REPLY [Bug 8460] - using null="false" in message-resources adds alt & title element to generated html

[bugzilla]

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

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

using null="false" in message-resources adds alt & title element to generated html

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |



--- Additional Comments From [EMAIL PROTECTED]  2002-07-23 08:17 ---
Ok, here is an attachment with a war file with a simple testcase. Try to change
the  line in the struts-config.xml file to include or
exclude the attribute null="false".

With null=false, the generated html code for the first.jsp file is 



  simple string

  




Without null="false", the generated code is



  simple string

  


The problem are the generated title & alt attributes for the html:text input.

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

DO NOT REPLY [Bug 8460] - using null="false" in message-resources adds alt & title element to generated html

[bugzilla]

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

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

using null="false" in message-resources adds alt & title element to generated html





--- Additional Comments From [EMAIL PROTECTED]  2002-07-23 08:18 ---
Created an attachment (id=2447)
simple testcase war file. try loading url http://localhost:8080/testcase/first.do

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

DO NOT REPLY [Bug 11074] New: - bean:include docs state "internal dispatch" but that's not true

[bugzilla]

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

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

bean:include docs state "internal dispatch" but that's not true

   Summary: bean:include docs state "internal dispatch" but that's
not true
   Product: Struts
   Version: Nightly Build
  Platform: Other
   URL: http://jakarta.apache.org/struts/userGuide/struts-
bean.html#include
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The documentation at the referenced link say that the  tag is 
meant to do an internal dispatch to the specified application component. By 
this I understood that I could do something like:



However the latest CVS appears to use a URLConnection rather than a 
RequestDispatcher so the above doesn't work.

There's a FIXME comment from Craig in the code but I'm not sure what needs 
fixing as I don't know the original intention of this tag. Am I right in 
thinking that where page and forward attributes are used it should be an 
internal dispatch but href should be external?

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

DO NOT REPLY [Bug 11051] - Turning off definitions validation still causes failure

[bugzilla]

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

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

Turning off definitions validation still causes failure

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-07-23 10:23 ---
I have try to turn on and off the tiles config validation, and all seem to work.
The reported error indicate that the config file dtd is not found. This dtd is
available on jakarta site at the specified address. It is also register to the
digester in order to find it offline. In this later case, it is find only if you
specify the correct string for the DOCTYPE declaration.
  The tiles config file should start with exactly this :



 http://jakarta.apache.org/struts/dtds/tiles-config.dtd";>


...

Can you check your tiles config files ? I mark the bug as invalid. Reopen it if
you still can't fix your problem.

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

Re: DO NOT REPLY [Bug 11074] New: - bean:include docs state "internal dispatch" but that's not true

[siraj]

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 23, 2002 2:06 PM
Subject: DO NOT REPLY [Bug 11074] New: - bean:include docs state "internal
dispatch" but that's not true


> 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=11074
>
> bean:include docs state "internal dispatch" but that's not true
>
>Summary: bean:include docs state "internal dispatch" but that's
> not true
>Product: Struts
>Version: Nightly Build
>   Platform: Other
>URL: http://jakarta.apache.org/struts/userGuide/struts-
> bean.html#include
> OS/Version: Other
> Status: NEW
>   Severity: Normal
>   Priority: Other
>  Component: Custom Tags
> AssignedTo: [EMAIL PROTECTED]
> ReportedBy: [EMAIL PROTECTED]
>
>
> The documentation at the referenced link say that the  tag
is
> meant to do an internal dispatch to the specified application component.
By
> this I understood that I could do something like:
>
> 
>
> However the latest CVS appears to use a URLConnection rather than a
> RequestDispatcher so the above doesn't work.
>
> There's a FIXME comment from Craig in the code but I'm not sure what needs
> fixing as I don't know the original intention of this tag. Am I right in
> thinking that where page and forward attributes are used it should be an
> internal dispatch but href should be external?
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


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

Tiles as a Plug-In

[Matt Raible]

I'm trying to upgrade to last night's nightly build.

In tiles-documentation.war (the only tiles webapp I saw) the following
is no longer applicable:



Is this true?

Please confirm.

Matt


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

Re: NPE when setting values on DynaActionForm

[Matt Raible]

The call below results in:

[javac]<-
[javac] 85. DynaActionForm requestForm =
[javac] 86.
DynaActionFormClass.getDynaActionFormClass("requestForm").newInstance();
[javac]
-->
[javac] *** Error: The type of the left-hand side in this assignment,
"org/apache/struts/action/DynaActionForm", is
not compatible with the type of the right-hand side expression,
"org/apache/commons/beanutils/DynaBean".

BUILD FAILED

However, this seems to work:

DynaActionForm requestForm = (DynaActionForm)
DynaActionFormClass.getDynaActionFormClass("requestForm").newInstance();

--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> The required changes to implement this has been checked in, and will be
> available in nightly build 20020723 of Struts.  The only difference is
> that you need to call:
> 
>   DynaActionForm requestForm =
> DynaActionFormClass.getDynaActionFormClass("requestForm").newInstance();
> 
> instead of the previously quoted method name, for consistency with
> previous method signatures.
> 
> Craig
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 


__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

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

Re: NPE when setting values on DynaActionForm

[Craig R. McClanahan]

On Tue, 23 Jul 2002, Matt Raible wrote:

> Date: Tue, 23 Jul 2002 07:15:33 -0700 (PDT)
> From: Matt Raible <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: NPE when setting values on DynaActionForm
>
> The call below results in:
>
> [javac]<-
> [javac] 85. DynaActionForm requestForm =
> [javac] 86.
> DynaActionFormClass.getDynaActionFormClass("requestForm").newInstance();
> [javac]
> 
>-->
> [javac] *** Error: The type of the left-hand side in this assignment,
> "org/apache/struts/action/DynaActionForm", is
> not compatible with the type of the right-hand side expression,
> "org/apache/commons/beanutils/DynaBean".
>
> BUILD FAILED
>
> However, this seems to work:
>
> DynaActionForm requestForm = (DynaActionForm)
> DynaActionFormClass.getDynaActionFormClass("requestForm").newInstance();
>

You're right ... you do need the cast.  Sorry about that -- all I can do
is plead "late night" ...

Craig


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

DO NOT REPLY [Bug 11074] - bean:include docs state "internal dispatch" but that's not true

[bugzilla]

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

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

bean:include docs state "internal dispatch" but that's not true

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-07-23 15:27 ---
Although the original intent was to be smarter about internal dispatches versus
external URLs, there are some really intricate complexities to getting that
decision correct.  I would prefer not to modify  at this point
(and risk breaking its current functionality that people are relying on).

For those who need to ensure that RequestDispatcher is used, I would suggest
using the  tag directly, or the  tag from JSTL.

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

DO NOT REPLY [Bug 11089] New: - Data source keys are global, even when using application modules

[bugzilla]

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

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

Data source keys are global, even when using application modules

   Summary: Data source keys are global, even when using application
modules
   Product: Struts
   Version: Nightly Build
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Current nightly builds of Struts use a single global namespace for 
elements across all application modules (i.e. sub-apps).  It would be nice if
there was a per-module namespace for these (including the "default" data source)
like there is for almost everything else in struts-config.xml.

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

problem with ActionForm object

[Thomas Praschl]

Hi,
I have a simple form on my jsp page. In my ActionForm class I validate whether a 
checkbox was clicked or not. If the checkbox was not clicked an error is returned and 
displayed on the same jsp-page. This works fine but:
Some (not all!) of the properties which were given by the user are not available on 
the error page. 
Furthermore, before I first show the jsp-form I get some information from a database 
which is then stored in the ActionForm bean and therefore displayed in a selectbox. 
After submitting the form and after validation this information is not available on 
the error jsp-page. It seems that the ActionForm object was destroyed too early.

I have already post this problem to the struts user list but nobody could help me. 
Maybe this is a know bug.

Thanks

-
Thomas
[EMAIL PROTECTED]

Re: Tiles as a Plug-In

[Cedric Dumoulin]

  It is true.
  I have updated the documentation in cvs, but jakarta site doesn't 
reflect it ;-(. I think that Jakarta site is not automatically updated. 
However, the documentation from struts-documentation.war should shows 
the new syntax:
 In each struts-config.xml:
  




  

You can remove the ActionComponentServlet and the TilesRequestProcessor 
declaration. The old methods to enable Tiles still working for backward 
compatibilities.
Another modification is renaming tiles.tld to struts-tiles.tld. You will 
need to change the file name in all your files, or specify a mapping in 
the web.xml file:
  
/WEB-INF/tiles.tld
/WEB-INF/struts-tiles.tld
  


   Cedric

Matt Raible wrote:

>I'm trying to upgrade to last night's nightly build.
>
>In tiles-documentation.war (the only tiles webapp I saw) the following
>is no longer applicable:
>
>processorClass="org.apache.struts.tiles.TilesRequestProcessor"  />
>
>Is this true?
>
>Please confirm.
>
>Matt
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>  
>



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

RE: problem with ActionForm object

[Christopher Book]

Your form is probably in the request scope.  If you put your form in the
session scope, then your fields will remain.
The problem is that the form is destroyed and recreated with the fields that
you posted.  Instead of putting lists (for selects) in the form, populate
them every time in the action, or have the get method in your form
return the list from your database every time.  Request scope forms are
SUPPOSED to behave in this way.  Once you populate the form and push it to
the page, the request is over.  When the user submits the form, the previous
form is gone and a new one has to be created.

Chris

-Original Message-
From: Thomas Praschl [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 23, 2002 11:47 AM
To: [EMAIL PROTECTED]
Subject: problem with ActionForm object


Hi,
I have a simple form on my jsp page. In my ActionForm class I validate
whether a checkbox was clicked or not. If the checkbox was not clicked an
error is returned and displayed on the same jsp-page. This works fine but:
Some (not all!) of the properties which were given by the user are not
available on the error page. 
Furthermore, before I first show the jsp-form I get some information from a
database which is then stored in the ActionForm bean and therefore displayed
in a selectbox. After submitting the form and after validation this
information is not available on the error jsp-page. It seems that the
ActionForm object was destroyed too early.

I have already post this problem to the struts user list but nobody could
help me. Maybe this is a know bug.

Thanks


-
Thomas
[EMAIL PROTECTED]

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

DO NOT REPLY [Bug 11093] New: - DefinitionsFactoryConfig is not Serializable

[bugzilla]

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

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

DefinitionsFactoryConfig is not Serializable

   Summary: DefinitionsFactoryConfig is not Serializable
   Product: Struts
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Tiles framework
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


DefinitionsFactory declares that it implements Serializable.
ComponentDefinitionsFactoryWrapper implements DefinitionsFactory and has a 
member config that is a DefinitionsFactoryConfig.
DefinitionsFactoryConfig is not Serializable and thus 
ComponentDefinitionsFactoryWrapper breaks when going through serialization.
There doesn't seem to be a reason why DefinitionsFactoryConfig can't be 
Serializable, and locally making that modification seems to work.

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

Re: Tiles as a Plug-In

[Craig R. McClanahan]

On Tue, 23 Jul 2002, Cedric Dumoulin wrote:

> Date: Tue, 23 Jul 2002 17:53:20 +0200
> From: Cedric Dumoulin <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Tiles as a Plug-In
>
>
>   It is true.
>   I have updated the documentation in cvs, but jakarta site doesn't
> reflect it ;-(. I think that Jakarta site is not automatically updated.

I just updated the web site with the most current
struts-documentation.war.  You're correct -- this is not currently
automated.  But it's on my TODO list at least ...

Craig


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

DO NOT REPLY [Bug 11050] - No way to properly validate form properties of types other than String

[bugzilla]

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

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

No way to properly  validate form properties of types other than String

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-07-23 16:47 ---
OK, I agree, form properties should be Strings.

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

DO NOT REPLY [Bug 10534] - does not add servlet context correctly

[bugzilla]

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

 does not add servlet context correctly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2002-07-23 16:51 ---
This occurs once more in the nightly build 20020723.

If there is a workaround, please let me know.

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

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Jing Zhou]

- Original Message -
From: "David M. Karr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 22, 2002 11:45 PM
Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?


> > "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
>
> Craig> I've been thinking about this issue as well, as you might
imagine.
>
> Craig> For general form field properties, I'm assuming that we would
have to make
> Craig> the existence of the form bean explict -- say, for example:
>
> Craig>   
>
> Craig> instead of assuming that you could just use username and "know"
that it
> Craig> was resolved against the form bean in the surrounding scope.
The property
> Craig> name can either be inferred from the expression (i.e. after the
first
> Craig> period), or we could allow an optional "property" attribute
that would
> Craig> provide the field name for the rendered  field.
>
> I'm very hesitant to start parsing the EL string, as there's a lot of
different
> ways to form a legal expression, and I don't want to try to restrict the
form
> of the EL expression in these situations.
>
> We could of course have the "var" attribute be an EL to get the current
value,
> and have the "property" attribute be the "name" attribute in the generated
> HTML, but then you have a disconnect between the value and the name,
whereas
> the current "name/property" pair allows a clean specification of both the
> current value and the request parameter name.
>
> Craig> For indexed things, remember that the subscript in an EL
expression can be
> Craig> a variable.  So something like this should work, where
"customers" is an
> Craig> array of customer objects, and we're inside a form with a field
per
> Craig> customer account number:
>
> Craig>   
> Craig>  Craig>  property="customers[${status.index}]"/>
> Craig>   
>
> Craig> could do the trick, as long as you scanned both the "var" and
"property"
> Craig> attributes for expressions.
>
> Yes, I had considered the array index possibility.  This will provide more
> flexibility, allowing the case of two nested "iterate" tags, and you want
the
> "property" attribute of the HTML tag to come from the OUTER iterate tag
(which
> someone on "struts-user" just asked about today).
>
> However, in the general case, we're still having the users specify more,
and
> redundant information, just to avoid the use of the "name/property" pair.
>
> I guess we could provide two ways to do this:
>
> If the "name" attribute is present, the "name" and "property" are combined
as
> usual.  However, if the "var" attribute is present, in place of the "name"
> attribute, then the "var" value is used for the current value, and the
> "property" attribute is used as the entire "name" attribute (of the
generated
> HTML).

The convention (see JSTL spec 2.2.1) is to use the name "var" for attributes
that export information. As I do not think  should do any
export
things, we could simplify Craig's example as follows:


 


Where we are only interested in the current iteration index evaluated by
an EL engine at run time and no changes are needed in the action codes.

Will it be possible to keep the semantics of name/property attributes
and drop the "indexed" attribute when the EL engine is available?

Jing

>
> (It's certainly confusing to have the "name" attribute mean two different
> things, one in JSP, and the other in HTML).
>
> Unfortunately, a change like this will require changing the base Struts
tag.
> In the case of "CheckboxTag" (and probably others), the current value
lookup is
> done directly in its "doStartTag()" method, with no comparison of "value"
> against null check to bypass it (which is the case in other tags, like
"size"
> and "message", for instance).
>
> --
> ===
> David M. Karr  ; Java/J2EE/XML/Unix/C++
> [EMAIL PROTECTED]
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


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

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

[bugzilla]

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

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

Serializability issues in ActionServlet/RequestProcessor

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2002-07-23 17:25 ---
>From Craig's comment, I presumed that RequestProcessor was modified to be 
Serializable.  It appears that it wasn't.  After spending some time updating to 
the latest nightly build, it seems that RequestProcessor is still an issue for 
us.  It is a member of ActionsServlet which extends HttpServlet which is 
Serializable, so the problem persists.

Admittedly, we are running expanded, but changing that would seem to be a side 
issue.  If there were a Junit test for each class that were Serializable, that 
would shed light immediately on object relationships that break the 
Serializable contract, outside of the context of what app server is being used 
or how.

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

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

[bugzilla]

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

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

Serializability issues in ActionServlet/RequestProcessor

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-07-23 17:48 ---
The real problem is that the requirement for servlet context attributes to be
Serializable is totally bogus.  Containers that require this should be repaired.

Trying to support this "requirement" is not going to be feasible without a
complete architectural change in what gets stored as servlet context attributes.
 Simply making things like ActionServlet and RequestProcessor "implements
Serializable" -- and making all the needed instance variables transient --
doesn't work, because if the container actually does serialize and reload the
object, it will have all sorts of null values and will fail anyway.

I'm not planning on doing any more work to support this -- the J2EE specs only
require serializability on *session* attributes, and that's what Struts does for
the session attributes that it creates.

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

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

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=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: 

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: 

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

[bugzilla]

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

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

Serializability issues in ActionServlet/RequestProcessor





--- Additional Comments From [EMAIL PROTECTED]  2002-07-23 18:20 ---
Making it possible to serialize ActionServlet or RequestProcessor is easy --
just set the offending instance variables to transient, and add "implements
Serializable" on RequestProcessor, and we'd be done.

Making it possible to *de*serialize an ActionServlet or RequestProcessor
instance, and have it actually operate correctly, is substantially more work. 
Without this, making these classes serialize successfully is pointless.  This is
not going to happen in a 1.1 time frame.

See comments from Hal Deadman (on the STRUTS-DEV mailing list, or in the
corresponding archives) about running Struts 1.1 successfully on WebLogic.

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

[BUG] does not add servlet context correctly

[Matt Raible]

Any hints for fixing this in the nightly build?  I'd like to fix it
myself, rather than waiting for tonight's build.

http://issues.apache.org/bugzilla/show_bug.cgi?id=10534

Thanks,

Matt


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

Re: upgrading to 1.1 nightly

[dhay]

Yep, saw that.

To override that method, then, do I have to subclass both ActionServlet (to
override getRequestProcessor()) and subclass RequestProcessor too?  I thought
all this made it easier to plug stuff in?  ;-)

Or am I missing something...?

Cheers,

David




"Craig R. McClanahan" <[EMAIL PROTECTED]> on 07/18/2002
05:58:11 PM

Please respond to "Struts Developers List"
  <[EMAIL PROTECTED]>

To:   Struts Developers List
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: upgrading to 1.1 nightly



The request processing code that was in ActionServlet in 1.0 got migrated
to a separarate class (RequestProcessor) in 1.1.

Craig


On Thu, 18 Jul 2002 [EMAIL PROTECTED] wrote:

> Date: Thu, 18 Jul 2002 16:45:26 -0400
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: upgrading to 1.1 nightly
>
>
>
> Hi.
>
> Am upgrading an app from 1.0 to 1.1 nightly build, and discovered that the
> following method which we were overriding no longer exists!  Should we simply
> override process() now?
>
>/**
> * Ask the specified Action instance to handle this request.  Return
> * the ActionForward instance (if any) returned by
> * the called Action.
> *
> * @param action the Action to process this request
> * @param mappingthe ActionMapping we are processing
> * @param formInstance   the ActionForm we are processing
> * @param requestthe servlet request we are processing
> * @param response   the servlet response we are creating
> * @exception IOExceptionif an input/output error occurs
> * @exception ServletException   if a servlet exception occurs
> */
>protected ActionForward processActionPerform (Action action, ActionMapping
> mapping,
>  ActionForm formInstance,
>  HttpServletRequest request,
>  HttpServletResponse response)
> throws IOException, ServletException
>
> Thanks,
>
> David
>
>
>
>
>
> --
> 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: upgrading to 1.1 nightly

[David M. Karr]

> "dhay" == dhay  <[EMAIL PROTECTED]> writes:

dhay> Yep, saw that.

dhay> To override that method, then, do I have to subclass both ActionServlet (to
dhay> override getRequestProcessor()) and subclass RequestProcessor too?  I thought
dhay> all this made it easier to plug stuff in?  ;-)

dhay> Or am I missing something...?

Look at the "struts-config_1_1.dtd".  You'll see a "processorClass" attribute
in the "controller" element.  This removes the need to subclass ActionServlet.

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


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

Re: upgrading to 1.1 nightly

[Craig R. McClanahan]

On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:

> Date: Tue, 23 Jul 2002 16:18:35 -0400
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: upgrading to 1.1 nightly
>
>
>
> Yep, saw that.
>
> To override that method, then, do I have to subclass both ActionServlet (to
> override getRequestProcessor()) and subclass RequestProcessor too?  I thought
> all this made it easier to plug stuff in?  ;-)
>

You will need to subclass RequestProcessor with your change to the
processActionPerform() method, but you will not have to subclass
ActionServlet for this.

To override the default RequestProcessor class for a particular
application module, use the "processorClass" attribute of the 
element in the struts-config.xml file for that module (different modules
can use different request processors if they want to, which was the
primary reason it was abstracted out).

> Or am I missing something...?
>
> Cheers,
>
> David
>

Craig


>
>
>
> "Craig R. McClanahan" <[EMAIL PROTECTED]> on 07/18/2002
> 05:58:11 PM
>
> Please respond to "Struts Developers List"
>   <[EMAIL PROTECTED]>
>
> To:   Struts Developers List
>   <[EMAIL PROTECTED]>
> cc:(bcc: David Hay/Lex/Lexmark)
> Subject:  Re: upgrading to 1.1 nightly
>
>
>
> The request processing code that was in ActionServlet in 1.0 got migrated
> to a separarate class (RequestProcessor) in 1.1.
>
> Craig
>
>
> On Thu, 18 Jul 2002 [EMAIL PROTECTED] wrote:
>
> > Date: Thu, 18 Jul 2002 16:45:26 -0400
> > From: [EMAIL PROTECTED]
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: upgrading to 1.1 nightly
> >
> >
> >
> > Hi.
> >
> > Am upgrading an app from 1.0 to 1.1 nightly build, and discovered that the
> > following method which we were overriding no longer exists!  Should we simply
> > override process() now?
> >
> >/**
> > * Ask the specified Action instance to handle this request.  Return
> > * the ActionForward instance (if any) returned by
> > * the called Action.
> > *
> > * @param action the Action to process this request
> > * @param mappingthe ActionMapping we are processing
> > * @param formInstance   the ActionForm we are processing
> > * @param requestthe servlet request we are processing
> > * @param response   the servlet response we are creating
> > * @exception IOExceptionif an input/output error occurs
> > * @exception ServletException   if a servlet exception occurs
> > */
> >protected ActionForward processActionPerform (Action action, ActionMapping
> > mapping,
> >  ActionForm formInstance,
> >  HttpServletRequest request,
> >  HttpServletResponse response)
> > throws IOException, ServletException
> >
> > Thanks,
> >
> > David
> >
> >
> >
> >
> >
> > --
> > 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: 
>
>


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

Announce: JSTL (Standard Tags) + Struts (MVC) live web Demo

[@Basebeans.com]

Subject: Announce: JSTL (Standard Tags) + Struts (MVC) live web Demo
From: "Vic C." <[EMAIL PROTECTED]>
 ===
If you are starting a Java Web, you should use MVC and Standard tags, 
this "kit" is a sample of "best" (at least good) practices.

It is MVC (Struts/Tiles)+JSTL +XSLT+ DAO (Open Source Data Access Object 
w/ SQL) + DB CRUD (Create update delete and SQL DLL scripts)+ J2EE 
Security ( to make Tomcat run like Apache )

It is KISS (you'll see how simple and how very standard) , good 
practices Free Open Source Framework to develop any web app, with the 
aim of being 80% of any app, but done as simple as possible and easy to 
teach. Again, everything is standard and simple. And it is the fastest, 
most efficient way to develop maintainable code I know of.

Samples include CMS (Authorize content, XSLT, CMS Comments, sinkable, 
single sign on, etc.),  Issue tracking, + more coming.

Please download and install and see if you want to attend. Details:
http://basicportal.sourceforge.net

I use it to teach Struts + JSTL public and private classes. I epically 
teach WHY you should want to do something in a certain way, not just how.

To attend and see "best practices"
http://www.basebeans.com/webEx.jsp
The seminar requires you know servlets, jsp,  SQL, JDBC, and at least 
some MVC. (a plus is if you have already deployed and MVC web app in the 
past) Oh...it is $10.00 ( but free to baseBeans clients and/or apache.org 
committers.)

To keep in touch on this join "MVC-Programmers" mail list at
http://www.netbean.net/mailman/listinfo/mvc-programmers

To keep in touch with open source projects go to
http://news.netbean.net/cgi-bin/webnews.cgi

Future plans include more docs, Dream weaver support,  mail client, RSS 
feeds, BLOG, Shopping Cart Store, etc. etc.

Did I say everything is standard and as simple as possible?

Vic

"Always code to the least amount of astonishment"
- 
Elements of Java Style

"If you want to build a ship, do not order your men to gather wood and 
nails, but teach them to yearn for the open sea"



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

Re: upgrading to 1.1 nightly

[dhay]

Cool.  Where can I find documentation on the new format for struts-config.xml /
 info?

Thanks,

David





"Craig R. McClanahan" <[EMAIL PROTECTED]> on 07/23/2002
04:51:19 PM

Please respond to "Struts Developers List"
  <[EMAIL PROTECTED]>

To:   Struts Developers List
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: upgrading to 1.1 nightly





On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:

> Date: Tue, 23 Jul 2002 16:18:35 -0400
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: upgrading to 1.1 nightly
>
>
>
> Yep, saw that.
>
> To override that method, then, do I have to subclass both ActionServlet (to
> override getRequestProcessor()) and subclass RequestProcessor too?  I thought
> all this made it easier to plug stuff in?  ;-)
>

You will need to subclass RequestProcessor with your change to the
processActionPerform() method, but you will not have to subclass
ActionServlet for this.

To override the default RequestProcessor class for a particular
application module, use the "processorClass" attribute of the 
element in the struts-config.xml file for that module (different modules
can use different request processors if they want to, which was the
primary reason it was abstracted out).

> Or am I missing something...?
>
> Cheers,
>
> David
>

Craig


>
>
>
> "Craig R. McClanahan" <[EMAIL PROTECTED]> on
07/18/2002
> 05:58:11 PM
>
> Please respond to "Struts Developers List"
>   <[EMAIL PROTECTED]>
>
> To:   Struts Developers List
>   <[EMAIL PROTECTED]>
> cc:(bcc: David Hay/Lex/Lexmark)
> Subject:  Re: upgrading to 1.1 nightly
>
>
>
> The request processing code that was in ActionServlet in 1.0 got migrated
> to a separarate class (RequestProcessor) in 1.1.
>
> Craig
>
>
> On Thu, 18 Jul 2002 [EMAIL PROTECTED] wrote:
>
> > Date: Thu, 18 Jul 2002 16:45:26 -0400
> > From: [EMAIL PROTECTED]
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: upgrading to 1.1 nightly
> >
> >
> >
> > Hi.
> >
> > Am upgrading an app from 1.0 to 1.1 nightly build, and discovered that the
> > following method which we were overriding no longer exists!  Should we
simply
> > override process() now?
> >
> >/**
> > * Ask the specified Action instance to handle this request.  Return
> > * the ActionForward instance (if any) returned by
> > * the called Action.
> > *
> > * @param action the Action to process this request
> > * @param mappingthe ActionMapping we are processing
> > * @param formInstance   the ActionForm we are processing
> > * @param requestthe servlet request we are processing
> > * @param response   the servlet response we are creating
> > * @exception IOExceptionif an input/output error occurs
> > * @exception ServletException   if a servlet exception occurs
> > */
> >protected ActionForward processActionPerform (Action action,
ActionMapping
> > mapping,
> >  ActionForm formInstance,
> >  HttpServletRequest request,
> >  HttpServletResponse
response)
> > throws IOException, ServletException
> >
> > Thanks,
> >
> > David
> >
> >
> >
> >
> >
> > --
> > 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: 
>
>


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








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

DO NOT REPLY [Bug 11104] New: - multipart/form-data loses EOLs in text areas

[bugzilla]

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

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

multipart/form-data loses EOLs in text areas

   Summary: multipart/form-data loses EOLs in text areas
   Product: Struts
   Version: 1.1 Beta 1
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: File Upload
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have created a form (using the html:form tag) with both a file upload box and
a text area (also using their respective html: tags).  The form is set to
enctype="multipart/form-data".  When the content from the text area is stored in
a String property on its FormBean, the first two lines have been combined into
one (EOL characters removed), and the subsequent lines are separated by CRs only.

If I remove the file upload box and the enctype, the proper value is stored in
the String property, including EOLs.

If I print out the data submitted by the browser, it appears that the browser is
submitting the text correctly, and the request is populated correctly, so
presumably it is Struts mangling it.

I'm running Struts 1.1b1 on Jboss 246/Tomcat 403 on Red Hat 7.2, and I tried a
Mozilla 1.0 client on that box as well as an IE 6 client on a Windows 2000 box.

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

Re: upgrading to 1.1 nightly

[dhay]

Sorry - found struts-config dtd!!!

Cheers,

David





"David_Hay/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com on 07/23/2002 06:07:52
PM

Please respond to "Struts Developers List"
  <[EMAIL PROTECTED]>

To:   "Struts Developers List"
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: upgrading to 1.1 nightly





Cool.  Where can I find documentation on the new format for struts-config.xml /
 info?

Thanks,

David





"Craig R. McClanahan" <[EMAIL PROTECTED]> on 07/23/2002
04:51:19 PM

Please respond to "Struts Developers List"
  <[EMAIL PROTECTED]>

To:   Struts Developers List
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: upgrading to 1.1 nightly





On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:

> Date: Tue, 23 Jul 2002 16:18:35 -0400
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: upgrading to 1.1 nightly
>
>
>
> Yep, saw that.
>
> To override that method, then, do I have to subclass both ActionServlet (to
> override getRequestProcessor()) and subclass RequestProcessor too?  I thought
> all this made it easier to plug stuff in?  ;-)
>

You will need to subclass RequestProcessor with your change to the
processActionPerform() method, but you will not have to subclass
ActionServlet for this.

To override the default RequestProcessor class for a particular
application module, use the "processorClass" attribute of the 
element in the struts-config.xml file for that module (different modules
can use different request processors if they want to, which was the
primary reason it was abstracted out).

> Or am I missing something...?
>
> Cheers,
>
> David
>

Craig


>
>
>
> "Craig R. McClanahan" <[EMAIL PROTECTED]> on
07/18/2002
> 05:58:11 PM
>
> Please respond to "Struts Developers List"
>   <[EMAIL PROTECTED]>
>
> To:   Struts Developers List
>   <[EMAIL PROTECTED]>
> cc:(bcc: David Hay/Lex/Lexmark)
> Subject:  Re: upgrading to 1.1 nightly
>
>
>
> The request processing code that was in ActionServlet in 1.0 got migrated
> to a separarate class (RequestProcessor) in 1.1.
>
> Craig
>
>
> On Thu, 18 Jul 2002 [EMAIL PROTECTED] wrote:
>
> > Date: Thu, 18 Jul 2002 16:45:26 -0400
> > From: [EMAIL PROTECTED]
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: upgrading to 1.1 nightly
> >
> >
> >
> > Hi.
> >
> > Am upgrading an app from 1.0 to 1.1 nightly build, and discovered that the
> > following method which we were overriding no longer exists!  Should we
simply
> > override process() now?
> >
> >/**
> > * Ask the specified Action instance to handle this request.  Return
> > * the ActionForward instance (if any) returned by
> > * the called Action.
> > *
> > * @param action the Action to process this request
> > * @param mappingthe ActionMapping we are processing
> > * @param formInstance   the ActionForm we are processing
> > * @param requestthe servlet request we are processing
> > * @param response   the servlet response we are creating
> > * @exception IOExceptionif an input/output error occurs
> > * @exception ServletException   if a servlet exception occurs
> > */
> >protected ActionForward processActionPerform (Action action,
ActionMapping
> > mapping,
> >  ActionForm formInstance,
> >  HttpServletRequest request,
> >  HttpServletResponse
response)
> > throws IOException, ServletException
> >
> > Thanks,
> >
> > David
> >
> >
> >
> >
> >
> > --
> > 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: 
>
>


--
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: upgrading to 1.1 nightly

[Craig R. McClanahan]

On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:

> Date: Tue, 23 Jul 2002 18:07:52 -0400
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: upgrading to 1.1 nightly
>
>
>
> Cool.  Where can I find documentation on the new format for struts-config.xml /
>  info?
>

How about all of the documentation in the DTD itself?

http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd

> Thanks,
>
> David
>

Craig


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

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[David M. Karr]

> "Jing" == Jing Zhou <[EMAIL PROTECTED]> writes:

Jing> The convention (see JSTL spec 2.2.1) is to use the name "var" for attributes
Jing> that export information. As I do not think  should do any
Jing> export
Jing> things, we could simplify Craig's example as follows:

Jing> 
Jing>  
Jing> 

Jing> Where we are only interested in the current iteration index evaluated by
Jing> an EL engine at run time and no changes are needed in the action codes.

It's funny to have "c:forEach" iterate over a collection, but ignore the item,
which is essentially what's happening here.  However, it does make sense here.

Just to summarize your example, the "property" attribute will be used in two
different ways.  It will be recursively wrapped by "${" and "}" and passed to
the EL engine to get the current value, and sent "raw" as the request parameter
name.  By "recursive", I mean that "customers[${status.index}].id" would be
evaluated, resulting in (say) "customers[2].id" to get the request parameter
value, and then wrapped with "${" and "}" to get the current value.

Jing> Will it be possible to keep the semantics of name/property attributes
Jing> and drop the "indexed" attribute when the EL engine is available?

I'd like to be sure exactly what you're asking here.  It's obvious that we
wouldn't need to use "indexed" if we directly construct the index expression,
as in this example.

The "property" attribute could have two different interpretations, depending on
whether the "name" attribute was present.  The old meaning if "name" was
present, and the new meaning if "name" is not present.  The "indexed" attribute
could only be present if the "name" attribute was present.

This would provide a transitional strategy, even while using the Struts-EL
library.

I'm still bouncing around these ideas in my mind.  Any other affirmation or
rejection of these ideas would be useful, at least.

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


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

cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java

[craigmcc]

craigmcc2002/07/23 17:30:24

  Modified:src/share/org/apache/struts/action ActionServlet.java
  Log:
  Add a new servlet initialization parameter "rulesets" for ActionServlet,
  that allows you to specify a comma-delimited list of fully qualified class
  names of org.apache.commons.digester.RuleSet instances that will be added
  to the Digester instance used to process struts-config.xml files for this
  web application.
  
  Revision  ChangesPath
  1.116 +46 -6 
jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
  
  Index: ActionServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v
  retrieving revision 1.115
  retrieving revision 1.116
  diff -u -r1.115 -r1.116
  --- ActionServlet.java23 Jul 2002 01:17:02 -  1.115
  +++ ActionServlet.java24 Jul 2002 00:30:24 -  1.116
  @@ -95,6 +95,7 @@
   import org.apache.commons.collections.FastHashMap;
   import org.apache.commons.digester.Digester;
   import org.apache.commons.digester.Rule;
  +import org.apache.commons.digester.RuleSet;
   import org.apache.commons.logging.Log;
   import org.apache.commons.logging.LogFactory;
   import org.apache.struts.config.ActionConfig;
  @@ -195,6 +196,12 @@
* detail - The debugging detail level for the Digester
* we utilize to process the application module configuration files. Accepts
* values 0 (off) and 1 (least serious) through 6 (most serious). [0]
  + * rulesets - Comma-delimited list of fully qualified
  + * classnames of additional org.apache.commons.digester.RuleSet
  + * instances that should be added to the Digester that will
  + * be processing struts-config.xml files.  By default, only
  + * the RuleSet for the standard configuration elements is
  + * loaded.  (Since Struts 1.1)
* validating - Should we use a validating XML parser to
* process the configuration file (strongly recommended)? [true]
* 
  @@ -1046,16 +1053,17 @@
* configure a corresponding ApplicationConfig object (which must be
* pushed on to the evaluation stack before parsing begins).
*
  + * @exception ServletException if a Digester cannot be configured
* @since Struts 1.1
*/
  -protected Digester initConfigDigester() {
  +protected Digester initConfigDigester() throws ServletException {
   
   // Do we have an existing instance?
   if (configDigester != null) {
   return (configDigester);
   }
   
  -// Create and return a new Digester instance
  +// Create a new Digester instance with standard capabilities
   configDigester = new Digester();
   configDigester.setDebug(detail);
   configDigester.setNamespaceAware(true);
  @@ -1067,6 +1075,38 @@
   if (url != null)
   configDigester.register(registrations[i], url.toString());
   }
  +
  +// Add any custom RuleSet instances that have been specified
  +String rulesets = getServletConfig().getInitParameter("rulesets");
  +if (rulesets == null) {
  +rulesets = "";
  +}
  +rulesets = rulesets.trim();
  +String ruleset = null;
  +while (rulesets.length() > 0) {
  +int comma = rulesets.indexOf(",");
  +if (comma < 0) {
  +ruleset = rulesets.trim();
  +rulesets = "";
  +} else {
  +ruleset = rulesets.substring(0, comma).trim();
  +rulesets = rulesets.substring(comma + 1).trim();
  +}
  +if (log.isDebugEnabled()) {
  +log.debug("Configuring custom Digester Ruleset of type " +
  +  ruleset);
  +}
  +try {
  +RuleSet instance = (RuleSet)
  +RequestUtils.applicationInstance(ruleset);
  +configDigester.addRuleSet(instance);
  +} catch (Exception e) {
  +log.error("Exception configuring custom Digester RuleSet", e);
  +throw new ServletException(e);
  +}
  +}
  +
  +// Return the completely configured Digester instance
   return (configDigester);
   }
   
  
  
  

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

cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java

[craigmcc]

craigmcc2002/07/23 17:47:23

  Modified:src/share/org/apache/struts/action ActionServlet.java
  Log:
  Pass a SAX InputSource, with a system identifier, to the Digester used to
  parse struts-config.xml files.  This allows struts-config.xml to use relative
  references to other XML files within the WEB-INF subdirectory, in order to
  partition the contents into multiple individual files.
  
  Revision  ChangesPath
  1.117 +9 -5  
jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
  
  Index: ActionServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v
  retrieving revision 1.116
  retrieving revision 1.117
  diff -u -r1.116 -r1.117
  --- ActionServlet.java24 Jul 2002 00:30:24 -  1.116
  +++ ActionServlet.java24 Jul 2002 00:47:23 -  1.117
  @@ -114,6 +114,7 @@
   import org.apache.struts.util.MessageResourcesFactory;
   import org.apache.struts.util.RequestUtils;
   import org.apache.struts.util.ServletContextWriter;
  +import org.xml.sax.InputSource;
   
   
   /**
  @@ -852,8 +853,11 @@
   
   Digester digester = initConfigDigester();
   digester.push(config);
  +URL url = getServletContext().getResource(path);
  +InputSource is = new InputSource(url.toExternalForm());
   input = getServletContext().getResourceAsStream(path);
  -digester.parse(input);
  +is.setByteStream(input);
  +digester.parse(is);
   input.close();
   getServletContext().setAttribute
   (Action.APPLICATION_KEY + prefix, config);
  
  
  

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

RE: cvs commit:jakarta-struts/src/share/org/apache/struts/action ActionServlet.java

[Martin Cooper]

Well that's kinda interesting. ;-)

Since the use of custom additions to the config file will cause validation
against the DTD to fail, should we deliberately turn off validation if this
option is being used (i.e. ignore the value of the 'validating' init param
and always treat it as false)?

--
Martin Cooper


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 23, 2002 5:30 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/action
> ActionServlet.java
> 
> 
> craigmcc2002/07/23 17:30:24
> 
>   Modified:src/share/org/apache/struts/action ActionServlet.java
>   Log:
>   Add a new servlet initialization parameter "rulesets" for 
> ActionServlet,
>   that allows you to specify a comma-delimited list of fully 
> qualified class
>   names of org.apache.commons.digester.RuleSet instances that 
> will be added
>   to the Digester instance used to process struts-config.xml 
> files for this
>   web application.
>   
>   Revision  ChangesPath
>   1.116 +46 -6 
> jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
>   
>   Index: ActionServlet.java
>   ===
>   RCS file: 
> /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
tionServlet.java,v
>   retrieving revision 1.115
>   retrieving revision 1.116
>   diff -u -r1.115 -r1.116
>   --- ActionServlet.java  23 Jul 2002 01:17:02 -  1.115
>   +++ ActionServlet.java  24 Jul 2002 00:30:24 -  1.116
>   @@ -95,6 +95,7 @@
>import org.apache.commons.collections.FastHashMap;
>import org.apache.commons.digester.Digester;
>import org.apache.commons.digester.Rule;
>   +import org.apache.commons.digester.RuleSet;
>import org.apache.commons.logging.Log;
>import org.apache.commons.logging.LogFactory;
>import org.apache.struts.config.ActionConfig;
>   @@ -195,6 +196,12 @@
> * detail - The debugging detail 
> level for the Digester
> * we utilize to process the application module 
> configuration files. Accepts
> * values 0 (off) and 1 (least serious) through 6 
> (most serious). [0]
>   + * rulesets - Comma-delimited list of 
> fully qualified
>   + * classnames of additional 
> org.apache.commons.digester.RuleSet
>   + * instances that should be added to the 
> Digester that will
>   + * be processing struts-config.xml files. 
>  By default, only
>   + * the RuleSet for the standard 
> configuration elements is
>   + * loaded.  (Since Struts 1.1)
> * validating - Should we use a 
> validating XML parser to
> * process the configuration file (strongly 
> recommended)? [true]
> * 
>   @@ -1046,16 +1053,17 @@
> * configure a corresponding ApplicationConfig object 
> (which must be
> * pushed on to the evaluation stack before parsing 
> begins).
> *
>   + * @exception ServletException if a Digester cannot be 
> configured
> * @since Struts 1.1
> */
>   -protected Digester initConfigDigester() {
>   +protected Digester initConfigDigester() throws 
> ServletException {
>
>// Do we have an existing instance?
>if (configDigester != null) {
>return (configDigester);
>}
>
>   -// Create and return a new Digester instance
>   +// Create a new Digester instance with standard 
> capabilities
>configDigester = new Digester();
>configDigester.setDebug(detail);
>configDigester.setNamespaceAware(true);
>   @@ -1067,6 +1075,38 @@
>if (url != null)
>configDigester.register(registrations[i], 
> url.toString());
>}
>   +
>   +// Add any custom RuleSet instances that have been 
> specified
>   +String rulesets = 
> getServletConfig().getInitParameter("rulesets");
>   +if (rulesets == null) {
>   +rulesets = "";
>   +}
>   +rulesets = rulesets.trim();
>   +String ruleset = null;
>   +while (rulesets.length() > 0) {
>   +int comma = rulesets.indexOf(",");
>   +if (comma < 0) {
>   +ruleset = rulesets.trim();
>   +rulesets = "";
>   +} else {
>   +ruleset = rulesets.substring(0, comma).trim();
>   +rulesets = rulesets.substring(comma + 1).trim();
>   +}
>   +if (log.isDebugEnabled()) {
>   +log.debug("Configuring custom Digester 
> Ruleset of type " +
>   +  ruleset);
>   +}
>   +try {
>   +RuleSet instance = (RuleSet)
>   +RequestUtils.applicationInstance(ruleset);
>   +configDigester.addRuleSet(instance);
>   +} catch (Exception e) {
>   +log.error("Exception c

RE: cvs commit: jakarta-struts/src/share/org/apache/struts/actionActionServlet.java

[Craig R. McClanahan]

On Tue, 23 Jul 2002, Martin Cooper wrote:

> Date: Tue, 23 Jul 2002 17:46:20 -0700
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action ActionServlet.java
>
> Well that's kinda interesting. ;-)
>
> Since the use of custom additions to the config file will cause validation
> against the DTD to fail, should we deliberately turn off validation if this
> option is being used (i.e. ignore the value of the 'validating' init param
> and always treat it as false)?
>

I'm having conversations with the Stxx guys about exactly this issue.
They really really really want to be able to run on top of a stock 1.1
release, and I'd like to see if we can accomodate that.

Right now, turning off validation has been disabled because we rely on
some of the default values (so that we can avoid references to
Action.X constants in the config classes, to help keep them
serializable  yadda yadda).  There are alternatives to this that I'm
looking into -- like copying all the manifest constants into an
org.apache.struts.Constants file and having Action.X refer to those
for backwards compatibility.

Even if we have to keep validation, there are some (unpleasant but usable)
options, like maintaining a separate DTD that was a superset of the
standard one.  What I'd really like to find is a way that an existing DTD
can be extended (say, add the  element nested inside a
 that the Stxx guys want) without having to start from scratch.
Any ideas?

> --
> Martin Cooper
>

Craig


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

DO NOT REPLY [Bug 11104] - multipart/form-data loses EOLs in text areas

[bugzilla]

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

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

multipart/form-data loses EOLs in text areas

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-07-24 02:03 ---


*** This bug has been marked as a duplicate of 9198 ***

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

DO NOT REPLY [Bug 9198] - First line feed in text parameters lost

[bugzilla]

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

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

First line feed in text parameters lost

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
   ||u



--- Additional Comments From [EMAIL PROTECTED]  2002-07-24 02:03 ---
*** Bug 11104 has been marked as a duplicate of this bug. ***

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

cvs commit: jakarta-struts STATUS

[jholmes]

jholmes 2002/07/23 19:25:53

  Modified:.STATUS
  Log:
  bring up to date
  
  Revision  ChangesPath
  1.39  +7 -2  jakarta-struts/STATUS
  
  Index: STATUS
  ===
  RCS file: /home/cvs/jakarta-struts/STATUS,v
  retrieving revision 1.38
  retrieving revision 1.39
  diff -u -r1.38 -r1.39
  --- STATUS21 Jul 2002 20:07:31 -  1.38
  +++ STATUS24 Jul 2002 02:25:53 -  1.39
  @@ -6,17 +6,20 @@
   OUTSTANDING BUGS IN STRUTS 1.1-b1 AND NIGHTLY BUILDS
   
   
  -   15 open bugs to swat!!
  +   21 open bugs to swat!!
   
   
   Controller:
   --
   11021 ActionForward or  tag does not support absolute URIs
  +11089 Data source keys are global, even when using application modules
   
   
   Custom Tags:
   ---
1586 The  tag generates incorrect focus javascript for radio buttons.
  + 8460 using null="false" in message-resources adds alt & title element to generated 
html
  +10534  does not add servlet context correctly
   
   
   Documentation:
  @@ -41,10 +44,12 @@
   
   10322 Problems with LookupDispatchAction and other locales
   10953 sub-application loses message resource
  +10979 DynaActionForm in session losts datas.
   
   
   Tiles Framework:
   ---
  +11093 DefinitionsFactoryConfig is not Serializable
   
   
   Unknown:
  
  
  

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

cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java

[craigmcc]

craigmcc2002/07/23 22:06:05

  Modified:src/share/org/apache/struts/action Action.java
  Added:   src/share/org/apache/struts Globals.java
  Log:
  Migrate global manifest constants to a new class (org.apache.struts.Globals)
  that has no other content, so they can be referenced without requiring any
  references to the org.apache.struts.action.Action class.
  
  Revision  ChangesPath
  1.1  jakarta-struts/src/share/org/apache/struts/Globals.java
  
  Index: Globals.java
  ===
  /*
   * $Header: /home/cvs/jakarta-struts/src/share/org/apache/struts/Globals.java,v 1.1 
2002/07/24 05:06:05 craigmcc Exp $
   * $Revision: 1.1 $
   * $Date: 2002/07/24 05:06:05 $
   *
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999-2002 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Struts", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   */
  
  
  package org.apache.struts;
  
  
  /**
   * Global manifest constants for the entire Struts Framework.
   *
   * Many of these constants were initially defined in Action,
   * but were moved here so that they could be referenced without referencing
   * the Action class itself.  For backwards compatibility,
   * constant references there point at this class, and the constant values
   * themselves have not changed.
   *
   * @author Craig R. McClanahan
   * @version $Revision: 1.1 $ $Date: 2002/07/24 05:06:05 $
   */
  
  public class Globals {
  
  
  // - Manifest Constants
  
  
  /**
   * The context attributes key under which our ActionServlet
   * instance will be stored.
   *
   * @since Struts 1.1
   */
  public static final String ACTION_SERVLET_KEY =
  "org.apache.struts.action.ACTION_SERVLET";
  
  
  /**
   * The base of the context attributes key under which our
   * ApplicationConfig data structure will be stored.  This
   * will be suffixed with the actual module prefix (including the
   * leading "/" character) to form the actual attributes key.
   *
   * For each request processed by the controller servlet, the
   * ApplicationConfig object for the module selected by
   * the request URI currently being processed will also be exposed under
   * this key as a request attribute.
   *
  

RE: cvs commit:jakarta-struts/src/share/org/apache/struts/action ActionServlet.java

[Martin Cooper]

Well, I do have one idea, off the top of my head. It's a bit whacky, but in
a perverse kind of way, it fits with what Stxx is all about. I'm not
entirely sure it meets the Stxx folks' goals, though.

The idea is to allow for Struts to apply a transform to the config file
before passing it to the Digester. In this particular case, a Stxx config
file would be transformed by a Stxx-to-Struts XSL stylesheet, the result of
which would be passed to the Digester as a regular struts-config.xml input
stream. A separate Stxx Struts Plugin could then apply a different transform
on the same Stxx config file, and perform the remaining Stxx-specific
configuration for the web app.

While this would mean maintaining a separate DTD for Stxx (assuming they
want a validating parse), it does provide a great deal of flexibility in
configuring Struts and extending it from a single config file.

--
Martin Cooper



-Original Message-
From: Craig R. McClanahan
To: Struts Developers List
Sent: 7/23/2002 6:21 PM
Subject: RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action
ActionServlet.java



On Tue, 23 Jul 2002, Martin Cooper wrote:

> Date: Tue, 23 Jul 2002 17:46:20 -0700
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action
ActionServlet.java
>
> Well that's kinda interesting. ;-)
>
> Since the use of custom additions to the config file will cause
validation
> against the DTD to fail, should we deliberately turn off validation if
this
> option is being used (i.e. ignore the value of the 'validating' init
param
> and always treat it as false)?
>

I'm having conversations with the Stxx guys about exactly this issue.
They really really really want to be able to run on top of a stock 1.1
release, and I'd like to see if we can accomodate that.

Right now, turning off validation has been disabled because we rely on
some of the default values (so that we can avoid references to
Action.X constants in the config classes, to help keep them
serializable  yadda yadda).  There are alternatives to this that I'm
looking into -- like copying all the manifest constants into an
org.apache.struts.Constants file and having Action.X refer to those
for backwards compatibility.

Even if we have to keep validation, there are some (unpleasant but
usable)
options, like maintaining a separate DTD that was a superset of the
standard one.  What I'd really like to find is a way that an existing
DTD
can be extended (say, add the  element nested inside a
 that the Stxx guys want) without having to start from scratch.
Any ideas?

> --
> Martin Cooper
>

Craig


--
To unsubscribe, e-mail:

For additional commands, e-mail:




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

cvs commit: jakarta-struts/src/share/org/apache/struts/config DataSourceConfig.java MessageResourcesConfig.java

[craigmcc]

craigmcc2002/07/23 22:28:05

  Modified:conf/share struts-config_1_1.dtd
   src/share/org/apache/struts/action ActionServlet.java
   src/share/org/apache/struts/config DataSourceConfig.java
MessageResourcesConfig.java
  Log:
  Remove the dependence in our configuration beans on default values that are
  established in the DTD, which were requiring us to do a validating parse.
  Re-enable the "validating" init parameter, which defaults to performing a
  validating parse but allows disabling it.
  
  Revision  ChangesPath
  1.27  +9 -9  jakarta-struts/conf/share/struts-config_1_1.dtd
  
  Index: struts-config_1_1.dtd
  ===
  RCS file: /home/cvs/jakarta-struts/conf/share/struts-config_1_1.dtd,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- struts-config_1_1.dtd 10 Jul 2002 20:36:23 -  1.26
  +++ struts-config_1_1.dtd 24 Jul 2002 05:28:04 -  1.27
  @@ -111,10 +111,10 @@
   
key Servlet context attribute key under which this data source
will be stored.  Default is the value specified by string
  - constant defined by Action.DATA_SOURCE_KEY. The application
  + constant defined by Globals.DATA_SOURCE_KEY. The application
module prefix (if any) is appended to the key
(${key}$prefix}).
  - [org.apache.struts.Action.DATA_SOURCE_KEY]
  + [org.apache.struts.Globals.DATA_SOURCE_KEY]
   
NOTE: The application module prefix includes the leading
slash, so the default datasource for a module named "foo" is
  @@ -128,7 +128,7 @@
   
   
   
  -
  +
   
   
   
  @@ -148,8 +148,8 @@
   bundle   Servlet context attribute for the message resources bundle
associated with this handler. The default attribute is the
value specified by the string constant declared at
  - Action.MESSAGES_KEY.
  - [org.apache.struts.Action.MESSAGES_KEY]
  + Globals.MESSAGES_KEY.
  + [org.apache.struts.Globals.MESSAGES_KEY]
   
   classNameThe configuration bean for this ExceptionHandler object.
If specified, className must be a subclass of the default
  @@ -575,9 +575,9 @@
key Servlet context attribute under which this message
resources bundle will be stored. The default attribute is
the value specified by the string constant at
  - [Action.MESSAGES_KEY]. The application module prefix (if
  + [Globals.MESSAGES_KEY]. The application module prefix (if
any) is appended to the key (${key}${prefix}).
  - [org.apache.struts.Action.MESSAGES_KEY]
  + [org.apache.struts.Globals.MESSAGES_KEY]
   
NOTE: The application module  prefix includes the leading
slash, so the default message resource bundle for a module
  @@ -595,7 +595,7 @@
   
   
   
  -
  +
   
   
   
  
  
  
  1.118 +17 -5 
jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
  
  Index: ActionServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v
  retrieving revision 1.117
  retrieving revision 1.118
  diff -u -r1.117 -r1.118
  --- ActionServlet.java24 Jul 2002 00:47:23 -  1.117
  +++ ActionServlet.java24 Jul 2002 05:28:04 -  1.118
  @@ -1067,11 +1067,23 @@
   return (configDigester);
   }
   
  +// Check the status of the "validating" initialization parameter
  +boolean validating = true;
  +String value = getServletConfig().getInitParameter("validating");
  +if (value != null) {
  +if ("false".equalsIgnoreCase(value) ||
  +"no".equalsIgnoreCase(value) ||
  +"n".equalsIgnoreCase(value) ||
  +"0".equalsIgnoreCase(value)) {
  +validating = false;
  +}
  +}
  +
   // Create a new Digester instance with standard capabilities
   configDigester = new Digester();
   configDigester.setDebug(detail);
   configDigester.setNamespaceAware(true);
  -configDigester.setValidating(true);
  +configDigester.setValidating(validating);
   configDigester.setUseContextClassLoader(true);
   configDigester.addRuleSet(new ConfigRuleSet());
   for (int i = 0; i < registrations.length; i += 2) {
  
  
  
  1.7   +6 -5  
jaka

cvs commit: jakarta-struts/src/share/org/apache/struts Globals.java

[craigmcc]

craigmcc2002/07/23 22:31:29

  Modified:src/share/org/apache/struts Globals.java
  Log:
  Make the new Globals class serializable, in case some JVMs get fussy.
  
  Revision  ChangesPath
  1.2   +8 -5  jakarta-struts/src/share/org/apache/struts/Globals.java
  
  Index: Globals.java
  ===
  RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/Globals.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Globals.java  24 Jul 2002 05:06:05 -  1.1
  +++ Globals.java  24 Jul 2002 05:31:29 -  1.2
  @@ -63,6 +63,9 @@
   package org.apache.struts;
   
   
  +import java.io.Serializable;
  +
  +
   /**
* Global manifest constants for the entire Struts Framework.
*
  @@ -76,7 +79,7 @@
* @version $Revision$ $Date$
*/
   
  -public class Globals {
  +public class Globals implements Serializable {
   
   
   // - Manifest Constants
  
  
  

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

RE: cvs commit: jakarta-struts/src/share/org/apache/struts/actionActionServlet.java

[Craig R. McClanahan]

On Tue, 23 Jul 2002, Martin Cooper wrote:

> Date: Tue, 23 Jul 2002 22:14:06 -0700
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List ' <[EMAIL PROTECTED]>
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action ActionServlet.java
>
> Well, I do have one idea, off the top of my head. It's a bit whacky, but in
> a perverse kind of way, it fits with what Stxx is all about. I'm not
> entirely sure it meets the Stxx folks' goals, though.
>
> The idea is to allow for Struts to apply a transform to the config file
> before passing it to the Digester. In this particular case, a Stxx config
> file would be transformed by a Stxx-to-Struts XSL stylesheet, the result of
> which would be passed to the Digester as a regular struts-config.xml input
> stream. A separate Stxx Struts Plugin could then apply a different transform
> on the same Stxx config file, and perform the remaining Stxx-specific
> configuration for the web app.
>
> While this would mean maintaining a separate DTD for Stxx (assuming they
> want a validating parse), it does provide a great deal of flexibility in
> configuring Struts and extending it from a single config file.
>

That is a pretty creative idea, and sort of mirrors what we do to create
both TLDs and documentation files from the same sources.  The biggest
potential drawback is the extra startup time that this implies.

In the mean time, I did a little bit of refactoring (moving the manifest
constants from o.a.s.a.Action to o.a.s.Globals, and pointing the old ones
to the new ones) that let us avoid the need to require validation.  Along
the way, I restored the functionality of the "validating" init parameter
to the controller servlet.  Coupled with the previous change allowing
registration of new rulesets, Stxx ought to be good to go with tonight's
nightly build (20020724).

> --
> Martin Cooper
>

Craig


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

action calling another action

[Pierre Delisle]

I have a 1.0 struts-based web application where a "higher-level" action 
depends on the processing associated with another lower-level action.

For example, action "foo" needs to invoke the processing
associated with action "bar".

Using struts 1.0, I could do the following in the FooAction:

  ActionServletMine actionServlet = 
  (ActionServletMine)mapping.getMappings().getServlet();
  ActionMapping targetMapping = actionServlet.findMapping("/bar.do");
  ((BarAction)actionServlet.getActionInstance(
  targetMapping)).perform(targetMapping, form, request, response);

ActionServletMine is my own subclass of ActionServlet. It simply provides
the extra method "getActionInstance()" to allow me to get access to the
action instance associated with "targetMapping". (it calls 
processActionCreate()).

Migrating to struts 1.1, I was hoping for backwards compatibility,
but ActionMapping.getMappings() seems to have been removed without
being first deprecated. Any reason, or am I missing something?
(btw, I know I could simply call getServlet() within the Action subclass,
but I'm still curious as to why getMappings() has been removed).


If I am to bite the bullet right now and rearchitect the
webapp with the new struts 1.1 api, I still run into a few
issues. 

What I've described above is how I thought would be the proper way
to handle "action calling other action" in the very early days of 1.0. 
There might be a better approach now. If so, I'd appreciate if someone
could point me in the right direction.

If I am to simply migrate the above code to the new 1.1 apis, 
it appears that I'd have to do the following:

  ActionServlet actionServlet = getServlet();
  ApplicationConfig appConfig = mapping.getApplicationConfig();
  RequestProcessor rp = actionServlet.getRequestProcessor(appConfig);

It appears that "findMapping()" has been deprecated. So the code
ActionMapping targetMapping = actionServlet.findMapping("/bar.do");
should be replaced by
ActionConfig targetAction = appConfig.findActionConfig() 

The problem though is that the execute() method of an Action expects
an ActionMapping object... which means that I'm back to want to use the old
1.0 api to get an ActionMapping (or I'm once again missing something). 
How come the new execute() method of Action does not take an ActionConfig 
object as argument instead of the old ActionMapping?

Finally, it would be preferable to migrate to the new RequestProcessor interface.
However, ActionServlet.getRequestProcessor() is protected,
preventing me from accessing it from my Action code. 
Any reason why it is not public?

Many thanks for any answer/advice...

-- Pierre

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