DO NOT REPLY [Bug 13454] - adding focus to the tag with two forms of the same name generates a javascript error

[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=13454

adding focus to the  tag with two forms of the same name generates a 
javascript error

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-11-05 06:20 ---
I've been looking at this bug off and on for the last few days, and in addition
to Ted's comments, no one has mentioned the fact that if you are creating
multiple forms (with focus) as part of some iteration, each form will have a

DO NOT REPLY [Bug 13043] - Adjustment to Iterate logic

[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=13043

Adjustment to Iterate logic

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-11-05 01:57 ---
I'm against adding this to the iterate tag for the following reasons:
1. You can avoid 
duplicating this logic in each Action by creating a parent Action with a method that 
performs this 
logic.
2. The iterate tag is meant to loop over collections and arrays, not a single bean.
3. 
The JSTL provides the  tag that duplicates the iterate tag's functionality 
in a 
standard way.
4. Interoperating with other frameworks that sometimes return a bean and 
sometimes a collection is not Struts' responsibility.

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

DO NOT REPLY [Bug 14238] - add strutstestcase to external how-to links.

[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=14238

add strutstestcase to external how-to links.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-11-05 01:45 ---
This project is linked to on the resources page "Struts projects on SourceForge".  If 
there's a 
compelling case to add another link to it, reopen this RFE with an explanation.

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

DO NOT REPLY [Bug 14150] - Allow to use any subclass of java.text.Format

[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=14150

Allow  to use any subclass of java.text.Format





--- Additional Comments From [EMAIL PROTECTED]  2002-11-05 01:39 ---
I haven't looked into the JSTL's capabilities in this area but would be surprised if 
you couldn't 
do this.  If you truly cannot do it in JSTL, I suggest extending on of those tags or 
using your struts 
extension.  Keep in mind that the Struts tags with JSTL counterparts are not being 
actively 
enhanced.  It just doesn't make sense to duplicate the effort of a standard taglib.

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

DO NOT REPLY [Bug 14150] - Allow to use any subclass of java.text.Format

[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=14150

Allow  to use any subclass of java.text.Format





--- Additional Comments From [EMAIL PROTECTED]  2002-11-04 22:54 ---
I've looked, three times now, at the JSTL and I cannot figure out how to do any
of the following tasks:

1) Take an email address in a string in the form:
First Last 
and convert it to:
First Last

2) Take a size in bytes and convert it into an abrivated form:
123456 becomes 123K
123456789 becomes 123M

3) Truncate a string line to a certain number of characters:
Re: about the graphs on the foo bar report last month from John Doe
becomes:
Re: about the graphs on the foo bar report la...

With my bean:write extension I can write a java.text.Format that does each of
the things with a few lings of code and is reusable. My format method for each
formatter is rather short: #1 is about 25 lines of commented code, #2 is about
15 lines, and #3 is 10 lines. Also I can reuse the formatter logic between the
different jsp pages while it wasn't obivous to me if that is possible with JSTL.

I love Struts strongly resists the urge to become bloat ware but I don't think
this feature would be classified as bloat.

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

DO NOT REPLY [Bug 14150] - Allow to use any subclass of java.text.Format

[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=14150

Allow  to use any subclass of java.text.Format





--- Additional Comments From [EMAIL PROTECTED]  2002-11-04 21:11 ---
Have you checked out the JSTL yet?  The fmt taglib is where Struts should
probably be getting this functionality from.  
ex: http://www.onjava.com/pub/a/onjava/2002/09/11/jstl2.html

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

question about tiles:useAttribute bugfix

[Anand Joshi]

hi Cedric,
I can open defect against this bug. But I feel since this  bug was reported
earlier, wouldn't it be nice to reopen earlier bug fix report?
As this bug was already reported and happened to be fixed under 2002/10/7
build.

Thanks

Anand Joshi
Websphere Development Team
Ph: 919-254-4331 (Tie 444-4331)
mail: [EMAIL PROTECTED]



   
 
  Cedric Dumoulin  
 
  <[EMAIL PROTECTED]To:   Struts Developers List 
<[EMAIL PROTECTED]> 
  g>   cc: 
 
   Subject:  Re: question about 
tiles:useAttribute  
  11/04/2002 04:24 
 
  AM   
 
  Please respond to
 
  "Struts  
 
  Developers List" 
 
   
 




  Can you open a ticket in bugzilla reporting this bug. Don't forget to
specify the faulty configuration (web server(s), struts release(s), ...)

 Thanks,
   Cedric

Anand Joshi wrote:

>
>
>hi Cedric,
>I took nightly build 1031 and extracted struts.jar from it But
>unfortunately it did not solve problem.
>
>Thanks  for your prompt attention!
>
>Anand Joshi
>Websphere Development Team
>Ph: 919-254-4331 (Tie 444-4331)
>mail: [EMAIL PROTECTED]
>
>
>
>

>  Cedric Dumoulin

>  <[EMAIL PROTECTED]To:   Struts Developers
List <[EMAIL PROTECTED]>
>  g>   cc:

>   Subject:  Re: question
about tiles:useAttribute
>  10/29/2002 04:32

>  AM

>  Please respond to

>  "Struts

>  Developers List"

>

>
>
>
>
>  Hi,
>
>  This is a bug in struts1.1b2 when used with web server doing reuse of
>tags. The required behavior of   is to
>use the name as id when id is not provided. This bug has been corrected
>in nightly build since 2002/10/7 .
>  Can you try with the nightly build to check if it solve your problem ?
>
> Cedric
>
>
>Anand Joshi wrote:
>
>
>
>>hi All,
>>I had used tiles:useAttribute in struts 1.0.2 where tiles was separate.
It
>>used to work even without attribute id.
>>
>>Now in struts 1.1b2 release,I have to give id attribute otherwise tag
does
>>not work. specifcally it gives nullPointerException.
>>ie:  this line >classname="java.lang.String" /> : cause exception.
>>while >classname="java.lang.String" /> works fine.
>>Taglib reference does not list id as required attribute. So I am confused
>>for its usage. I am simply adding id="{same value as name}"
>>for all occurances of tiles:useAttribute for porting my webApp to
>>struts1.1b2.
>>Can you explain rationale behind making id as required attribute?
>>
>>Any help will  be greatly appreciated.
>>Thanks
>>
>>Anand Joshi
>>Websphere Development Team
>>Ph: 919-254-4331 (Tie 444-4331)
>>mail: [EMAIL PROTECTED]
>>
>>
>>--
>>To unsubscribe, e-mail:   <
>>
>>
>mailto:struts-dev-unsubscribe@;jakarta.apache.org>
>
>
>>For additional commands, e-mail: <
>>
>>
>mailto:struts-dev-help@;jakarta.apache.org>
>
>
>>
>>
>>
>>
>
>
>--
>To unsubscribe, e-mail:   <
mailto:struts-dev-unsubscribe@;jakarta.apache.org
>
>
>For additional commands, e-mail: <
mailto:struts-dev-help@;jakarta.apache.org
>
>
>
>
>
>
>--
>To unsubscribe, e-mail:   <
mailto:struts-dev-unsubscribe@;jakarta.apache.org>
>For additional commands, e-mail: <
mailto:struts-dev-help@;jakarta.apache.org>
>
>
>
>


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




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

DO NOT REPLY [Bug 14238] New: - add strutstestcase to external how-to links.

[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=14238

add strutstestcase to external how-to links.

   Summary: add strutstestcase to external how-to links.
   Product: Struts
   Version: Unknown
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


As StrutsTestCase is on the Struts 1.2 roadmap, it would be nice to include it 
as an external HOW-TO link.  The URL is here:

http://strutstestcase.sourceforge.net

This is a how-to guide, and as well, it provides instructions for installation.

At some point I will change it's look and feel to be more consistent with the 
Jakarta site, but I think I will wait to do that until the code is integrated.

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

Re: DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[David Graham]

I'm not opposed to the Impl naming if you don't have to type it in code or 
configure it.  The java socket classes use this convention but we're spared 
from seeing them.  In general, I believe Impl classes shouldn't be seen by 
general developers.

David






From: Robert Leland <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: DO NOT REPLY [Bug 14054] - Rename "Application" components to 
"Module"
Date: Mon, 04 Nov 2002 14:27:05 -0500

Subject:  Re: DO NOT REPLY [Bug 14054] - Rename "Application" components to 
"Module"
From: "David Graham" <[EMAIL PROTECTED]>
Date: 2002-11-04 18:04:41
[Download message RAW]

> +1 on the ModuleConfig interface (Struts needs more of these).
>  I'm not sure about StandardModuleConfigImpl though. > Where will the 
user see this *Impl class if anywhere?
> If the user never has to write this then I suggest ModuleConfigImpl. > 
If they have to write it somewhere then drop the "Impl"
> part and use StandardModuleConfig or StrutsModuleConfig.


'ModuleConfigImpl' would be +1. The 'Impl' was patterened after what we do 
here
at my Job and also what commons-logging, commons-pool do for naming 
implementations
and interfaces.

If a --user-- is defined as struts-user mailing list, yes they shouldn't 
see the Impl classes. Neither, would
most of the Struts internal classes. I didn't want to overdesign but did 
want to reserve
the name 'ModuleConfig' for the general concept.


> Dave

-Rob



--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



_
Get faster connections -- switch to MSN Internet Access! 
http://resourcecenter.msn.com/access/plans/default.asp


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

Re: DO NOT REPLY [Bug 14054] - Rename "Application" components to"Module"

[Robert Leland]

Subject:  Re: DO NOT REPLY [Bug 14054] - Rename "Application" components 
to "Module"
From: "David Graham" <[EMAIL PROTECTED]>
Date: 2002-11-04 18:04:41
[Download message RAW]

> +1 on the ModuleConfig interface (Struts needs more of these).
>  I'm not sure about StandardModuleConfigImpl though. 
> Where will the user see this *Impl class if anywhere?
> If the user never has to write this then I suggest ModuleConfigImpl. 
> If they have to write it somewhere then drop the "Impl"
> part and use StandardModuleConfig or StrutsModuleConfig.


'ModuleConfigImpl' would be +1. The 'Impl' was patterened after what we 
do here
at my Job and also what commons-logging, commons-pool do for naming 
implementations
and interfaces.

If a --user-- is defined as struts-user mailing list, yes they shouldn't 
see the Impl classes. Neither, would
most of the Struts internal classes. I didn't want to overdesign but did 
want to reserve
the name 'ModuleConfig' for the general concept.


> Dave

-Rob



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

Re: DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[David Graham]

+1 on the ModuleConfig interface (Struts needs more of these).  I'm not sure 
about StandardModuleConfigImpl though.  Where will the user see this *Impl 
class if anywhere?  If the user never has to write this then I suggest 
ModuleConfigImpl.  If they have to write it somewhere then drop the "Impl" 
part and use StandardModuleConfig or StrutsModuleConfig.

Dave




From: [EMAIL PROTECTED]
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 14054]  - Rename "Application" components to 
"Module"
Date: 4 Nov 2002 17:41:18 -

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=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-04 17:41 
---
So how do we get this process started again ?
I apologize if any comments I made about the the
 ActionMapping->ActionConfig were hasty, judgemental, or
 offended anyone.

My concern right now if to get this process going again.
Since the deprecated code will only exist through Struts 1.1
I would be a +1 on --whatever-- method we choose.
Should we call for a consensis vote ?

I do believe we should provide a deprecation path for users,
Whatever method we use, providng a deprecation path will
only cost us about 10 minutes more than a straight rename.

I would like to make one more suggestion through, and that is to
go ahead and use an interface at the back end of the process
ModuleConfig   - Interface
^
|
  StandardModuleConfigImpl  - Existing ApplicationConfig code
^
|
 ApplicationConfig  - Deprecated Method name.

Delay adding a FactoryMethod for 1.1.
Otherwise for 1.1->1.2 we might go through this renaming again,
when/if other ModuleConfig schemes are implemented.
By doing an interface now we reserve the name ModuleConfig for
the concept it represents and not the implementation.

--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



_
Choose an Internet access plan right for you -- try MSN! 
http://resourcecenter.msn.com/access/plans/default.asp


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

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[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=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-04 17:41 ---
So how do we get this process started again ?
I apologize if any comments I made about the the 
 ActionMapping->ActionConfig were hasty, judgemental, or
 offended anyone.

My concern right now if to get this process going again.
Since the deprecated code will only exist through Struts 1.1
I would be a +1 on --whatever-- method we choose.
Should we call for a consensis vote ?

I do believe we should provide a deprecation path for users,
Whatever method we use, providng a deprecation path will 
only cost us about 10 minutes more than a straight rename. 

I would like to make one more suggestion through, and that is to 
go ahead and use an interface at the back end of the process
ModuleConfig   - Interface 
^
|
  StandardModuleConfigImpl  - Existing ApplicationConfig code
^
|
 ApplicationConfig  - Deprecated Method name.

Delay adding a FactoryMethod for 1.1.
Otherwise for 1.1->1.2 we might go through this renaming again,
when/if other ModuleConfig schemes are implemented.
By doing an interface now we reserve the name ModuleConfig for
the concept it represents and not the implementation.

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

DO NOT REPLY [Bug 14150] - Allow to use any subclass of java.text.Format

[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=14150

Allow  to use any subclass of java.text.Format





--- Additional Comments From [EMAIL PROTECTED]  2002-11-04 16:57 ---
Created an attachment (id=3713)
Class that extends WriteTag to allow the java.text.Format to be specified

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

DO NOT REPLY [Bug 14173] - tag library adds ;jsessionid even if the url is 'javascript:...'.

[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=14173

 tag library adds ;jsessionid even if the url is 'javascript:...'.





--- Additional Comments From [EMAIL PROTECTED]  2002-11-04 15:56 ---
I'm sorry that I missed your point, David. And thank you so much.

I've tested HttpServletResponse.encodeURL() method in Tomcat 4.0.4.
It does differently from IBM WebSphere.
Tomcat 4.0.4 doesn't encode javascript: URLs.

In addition, Tomcat 4.0.4 doesn't encode normal urls (http: or https:) when
client browser sends JSESSIONID cookie. IBM WebSphere alwasy encode every url,
not considering if client browser sends JSESSIONID cookie or not.
IMHO, HttpServletResponse.encodeURL() method is responsible for validating URLs.
Tomcat is doing that. So I'm going to report this bug to IBM. :-)
Thank you for your helps.

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

DO NOT REPLY [Bug 10868] - Validator does not support non-default resource bundles

[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=10868

Validator  does not support non-default resource bundles





--- Additional Comments From [EMAIL PROTECTED]  2002-11-04 14:53 ---
Wait until tomorrow and you can download the binary distribution.  The
struts-example will show how you can specify alternate bundles for the validator
in the same format posted by  Chris Johnson 2002-08-01 21:04.

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

DO NOT REPLY [Bug 14226] New: - BufferedMultipartInputStream constructor throw MaxLengthExceededException if -1 is used for the maxSize paramter

[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=14226

BufferedMultipartInputStream constructor throw MaxLengthExceededException if -1 is 
used for the maxSize paramter

   Summary: BufferedMultipartInputStream constructor throw
MaxLengthExceededException if -1 is used for the maxSize
paramter
   Product: Struts
   Version: 1.1 Beta 2
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: File Upload
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


According to BufferedMultipartInputStream constructor's Javadoc :

* @param maxSize The maximum size in bytes that this multipart
*request can be, or -1 for an unlimited length

since the constructor starts with :

this.inputStream = inputStream;
this.bufferSize = bufferSize;
this.contentLength = contentLength;
this.maxSize = maxSize;

if (maxSize < contentLength) {
throw new MaxLengthExceededException(maxSize);
}

[...]

it seems that using -1 for maxSize throws unavoidably MaxLengthExceededException

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

DO NOT REPLY [Bug 10868] - Validator does not support non-default resource bundles

[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=10868

Validator  does not support non-default resource bundles





--- Additional Comments From [EMAIL PROTECTED]  2002-11-04 12:12 ---
I checked the latest bits but not changes in validation.xml file & 
validator_1_0.dtd to specify the resource bundle name! Is this fix part of the 
commons-validator package? Where can I find the struts-example?

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

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[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=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-04 11:32 ---
Personally, I'm very impressed by the attention to detail here. But I just wanted to 
mention that 
Struts 1.1 is in BETA. We have betas so we can shake-out issues like this and fix them 
before we 
promote the codebase to a release. I really don't know how many people, if any, are 
referring to 
these objects directly. If they are, the problem would be very easy for them to fix by 
renaming 
their own references. At this level, we are working with other advanced developers and 
can expect 
them to do some of their own leg work. I agree that changing how the new config 
package works at this 
point would be rude, but I think simply renaming things doesn't have to be a big deal 
between beta 
releases. I would agree that this discussion would be on task if this were Struts 1.2 
and we were 
renaming the component after the code was formally released. But I truly do not think 
any one 
outside the team will criticize us for just renaming this component now and moving 
forward. When 
it is just as easy for us to deprecate changes between betas, sure, lets go the extra 
yard and do the 
polite thing. But when it stops being simple, we should cut to the chase and play the 
beta card.

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

Re: question about tiles:useAttribute

[Cedric Dumoulin]

 Can you open a ticket in bugzilla reporting this bug. Don't forget to 
specify the faulty configuration (web server(s), struts release(s), ...)

Thanks,
  Cedric

Anand Joshi wrote:



hi Cedric,
I took nightly build 1031 and extracted struts.jar from it But
unfortunately it did not solve problem.

Thanks  for your prompt attention!

Anand Joshi
Websphere Development Team
Ph: 919-254-4331 (Tie 444-4331)
mail: [EMAIL PROTECTED]



   
 Cedric Dumoulin   
 <[EMAIL PROTECTED]To:   Struts Developers List <[EMAIL PROTECTED]> 
 g>   cc:  
  Subject:  Re: question about tiles:useAttribute  
 10/29/2002 04:32  
 AM
 Please respond to 
 "Struts   
 Developers List"  
   




 Hi,

 This is a bug in struts1.1b2 when used with web server doing reuse of
tags. The required behavior of   is to
use the name as id when id is not provided. This bug has been corrected
in nightly build since 2002/10/7 .
 Can you try with the nightly build to check if it solve your problem ?

Cedric


Anand Joshi wrote:

 

hi All,
I had used tiles:useAttribute in struts 1.0.2 where tiles was separate. It
used to work even without attribute id.

Now in struts 1.1b2 release,I have to give id attribute otherwise tag does
not work. specifcally it gives nullPointerException.
ie:  this line 
classname="java.lang.String" /> : cause exception.
while 
classname="java.lang.String" /> works fine.
Taglib reference does not list id as required attribute. So I am confused
for its usage. I am simply adding id="{same value as name}"
for all occurances of tiles:useAttribute for porting my webApp to
struts1.1b2.
Can you explain rationale behind making id as required attribute?

Any help will  be greatly appreciated.
Thanks

Anand Joshi
Websphere Development Team
Ph: 919-254-4331 (Tie 444-4331)
mail: [EMAIL PROTECTED]


--
To unsubscribe, e-mail:   <
   

mailto:struts-dev-unsubscribe@;jakarta.apache.org>
 

For additional commands, e-mail: <
   

mailto:struts-dev-help@;jakarta.apache.org>
 



   



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


 



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

DO NOT REPLY [Bug 12159] - Link to tutorial incorrect

[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=12159>.
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=12159

Link to tutorial incorrect

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-04 08:22 ---
Fixed in the 20021104 nightly build.

--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

cvs commit: jakarta-struts/web/tiles-documentation/doc tutorial.jsp

[jmitchell]

jmitchell2002/11/04 00:17:37

  Modified:web/tiles-documentation/doc tutorial.jsp
  Log:
  Fix Bug # 12159
  
  Revision  ChangesPath
  1.3   +1 -4  jakarta-struts/web/tiles-documentation/doc/tutorial.jsp
  
  Index: tutorial.jsp
  ===
  RCS file: /home/cvs/jakarta-struts/web/tiles-documentation/doc/tutorial.jsp,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- tutorial.jsp  26 Oct 2002 00:25:25 -  1.2
  +++ tutorial.jsp  4 Nov 2002 08:17:37 -   1.3
  @@ -1,7 +1,4 @@
   <%@ page language="java" %>
   <%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %>
   
  -
  -
  -  
  -  
  +
  
  
  

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