DO NOT REPLY [Bug 23972] - illegal character with struts-validator.war

2003-10-22 Thread 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=23972

illegal character with struts-validator.war

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-10-22 07:25 ---
This is a valid bug.

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

DO NOT REPLY [Bug 23972] - illegal character with struts-validator.war

2003-10-22 Thread 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=23972

illegal character with struts-validator.war

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-10-22 07:28 ---
Fixed in Nightly,

However, this uncovered this uncovered a pending issue that needs a new bug 
ticket opened
and that is the case of the javascript names, both
the file name and the JS name.
Any DoubleCamel validators will not be found if
it's name in the struts validator-rules.xml
isn't also not properly cased for the name attribute.
So: intRange/creditCard is found since it's name
is properly doubled cased.
However, minlength, maxlength is not found.
More details will follow in the new Bug Report.

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

DO NOT REPLY [Bug 24000] New: - Cannot find bean under name org.apache.struts.taglib.html.BEAN (forgot to put the "name" in a multibox)

2003-10-22 Thread 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=24000

Cannot find bean under name org.apache.struts.taglib.html.BEAN (forgot to put the 
"name" in a multibox)

   Summary: Cannot find bean under name
org.apache.struts.taglib.html.BEAN (forgot to put the
"name" in a multibox)
   Product: Struts
   Version: 1.0 Final
  Platform: Other
   URL: http://jakarta.apache.org/struts/userGuide/struts-
html.html#multibox
OS/Version: Linux
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The below "root cause" pointed to the last line of the jsp ???
Perhaps this is again a for the jasper folks, but I guess it is useful to those
who suffer from that seeing it in the struts-dev mail archive too.

Anway, it would be helpful to get a better error message or at least the real
line where it happened!

Within a logic:iterate, I had

  


The pretty useless error I got was:
Apache Tomcat/4.1.24 - Error reportHTTP Status 500 - 



type Exception report
message 
description The server encountered an internal error () that prevented it from 
fulfilling this request.
exception 
org.apache.jasper.JasperException: Cannot find bean under name
org.apache.struts.taglib.html.BEAN
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:254)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at 
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:509)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote

[chain] conditionals again

2003-10-22 Thread Greg Reddin 
I'm sorry to bring back up a discussion that's been hashed out already, 
but there's something I still don't understand...

I can see why it's better for every command in the chain to be executed 
rather than executing a "sub-chain" based on some condition.  I can see 
the correlation of the sub-chain idea to the goto notion.

But this leaves some baggage that I'm still not comfortable with.  Now 
every command after ValidateActionForm has to know about the "validKey" 
attribute.  So far, that's ok.  At least I can readily see the chain of 
execution and there's no variation in it.  But, what if I introduce a 
command of my own that creates some conditions?  Now do I have to 
customize *every* command in the chain after mine just to check for my 
condition?  This also makes it difficult at best to change the order of 
execution if I so desired, but I don't know if that's necessarily a bad 
thing.

If this is the case, how are we any better off with this model than we 
were with a monolithic request processor?  Why should the commands have 
so much inter-dependence now that they are separate objects?  Are we 
better off with them as inter-dependent separate objects than we were as 
one monolithic object?

Now, is there any way to get the best of both worlds -- no gotos, and no 
"state baggage"?  Is it possible that the command could just be 
responsible for executing and not ever be called unless all the 
conditions are in place for it to be executed?  Something at a higher 
level than the command would have to determine whether it should be 
executed?  So, you might have something between the chain and the 
command that determines that.  I'm not sure if that's any better because 
then *that* component would have to know about all the commands as well.

Anyway, I hope I'm making sense.  I hate to ask a question and then 
leave the room, but I'll have to take answers in the morning :-)

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

DO NOT REPLY [Bug 24021] New: - parsing exception fails to report which file being parsed....

2003-10-22 Thread 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=24021

parsing exception fails to report which file being parsed

   Summary: parsing exception fails to report which file being
parsed
   Product: Struts
   Version: 1.1 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Digester
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


This may be a bug for xerces... but I thought I would start here.

If struts-config.xml contains "non-well-formed" XML the exception below is reported. 
Currently 
the only way to know the exception is a problem with struts-config is by looking at 
the stack trace. 
This could be confusing for first time struts users...

It would be nice to see the actual file being parsed in the exception message.

I'm not sure what happens if web.xml fails to parse properly... Will the exception 
report that 
web.xml had problems during parsing? Or would the below exception be displayed without 
the file 
being parsed? Depending on the answer to these questions may move this bug around to 
different 
projects.

Full stack trace:

INFO: Initializing Coyote HTTP/1.1 on port 8060
Starting service Tomcat-Standalone
Apache Tomcat/4.1.24
Parse Fatal Error at line 16 column 2: The content of elements must consist of 
well-formed 
character data or markup.
org.xml.sax.SAXParseException: The content of elements must consist of well-formed 
character 
data or markup.
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(
Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:363)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:137)
at org.apache.struts.digester.Digester.parse(Digester.java:755)
at org.apache.struts.action.ActionServlet.initMapping(ActionServlet.java:1331)
at org.apache.struts.action.ActionServlet.init(ActionServlet.java:465)
at javax.servlet.GenericServlet.init(GenericServlet.java:256)
at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823)
at 
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3420)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3608)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
at org.apache.catalina.core.StandardService.start(StandardService.java:497)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:2190)
at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)


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

Re: [chain] conditionals again

2003-10-22 Thread Craig R. McClanahan 
Greg Reddin wrote:

I'm sorry to bring back up a discussion that's been hashed out 
already, but there's something I still don't understand...

I can see why it's better for every command in the chain to be 
executed rather than executing a "sub-chain" based on some condition.  
I can see the correlation of the sub-chain idea to the goto notion.

But this leaves some baggage that I'm still not comfortable with.  Now 
every command after ValidateActionForm has to know about the 
"validKey" attribute.  So far, that's ok.  At least I can readily see 
the chain of execution and there's no variation in it.  But, what if I 
introduce a command of my own that creates some conditions?  Now do I 
have to customize *every* command in the chain after mine just to 
check for my condition?  This also makes it difficult at best to 
change the order of execution if I so desired, but I don't know if 
that's necessarily a bad thing.

If this is the case, how are we any better off with this model than we 
were with a monolithic request processor?  Why should the commands 
have so much inter-dependence now that they are separate objects?  Are 
we better off with them as inter-dependent separate objects than we 
were as one monolithic object?

Now, is there any way to get the best of both worlds -- no gotos, and 
no "state baggage"?  Is it possible that the command could just be 
responsible for executing and not ever be called unless all the 
conditions are in place for it to be executed?  Something at a higher 
level than the command would have to determine whether it should be 
executed?  So, you might have something between the chain and the 
command that determines that.  I'm not sure if that's any better 
because then *that* component would have to know about all the 
commands as well.

Anyway, I hope I'm making sense.  I hate to ask a question and then 
leave the room, but I'll have to take answers in the morning :-)

If you've got tightly connected commands that are already highly 
interdependent (and a chain for replacing RequestProcessor definitely 
fits this description), there is normally so much shared state 
information already that adding tests for conditions isn't going to add 
any coupling that wasn't present already.  If you're wiring together 
commands that are loosely coupled, and don't necessarily want the 
commands to know about each other's state, you're probably better off 
doing the "branch to an alternate chain" trick, based on a decision in a 
command that implements the branch.

Both styles do work, and (in fact) both are still employed in the 
chain-config.xml right now:

* The "servlet-complete" chain selects the appropriate sub-application
 module and branches, giving you the opportunity to plug in
 per-module chains that are completely different and independent,
 without introducing any coupling other than placing the ModuleConfig
 in the right place (i.e. the "servlet-standard" chain expects that as a
 precondition, instead of loading the ModuleConfig at the beginning
 of its own work).
* The "servlet-standard" chain is mostly synchronous, but still has a
 branch for exception handling (required, in this case, because it's
 not caught until the postprocess() method, meaning that the rest
 of the chain has already been executed and someone threw an
 exception).
For any given chain, pick the style that makes the most sense for your 
use case.  But, while we're still experimenting, I tend to play with 
lots of fine-grained chains that are glued together by "smart" commands 
that branch based on conditions, and then look later to see if there is 
enough shared state to collapse those chains into one.

Thanks,
Greg
Craig



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

DO NOT REPLY [Bug 23465] - "indexed" form data cannot be parsed by a struts DynaActionForm bean

2003-10-22 Thread 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=23465

"indexed" form data cannot be parsed by a struts DynaActionForm bean

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement



--- Additional Comments From [EMAIL PROTECTED]  2003-10-23 01:05 ---
See if this article helps:
http://www.developer.com/java/ejb/article.php/2233591

Otherwise it's probably best discussed on the struts-user list.

I'm going to mark this as an enhancement request, but please close it if it's no
longer an issue or set it back to normal if you still think there is a bug.

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

DO NOT REPLY [Bug 21906] - IncludeTagTest fails under TC 4.1, TestErrorsTag1 fails under TC 3.3

2003-10-22 Thread 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=21906

IncludeTagTest fails under TC 4.1, TestErrorsTag1 fails under TC 3.3

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-10-23 01:08 ---
Thanks to James M, this appears to be fixed now (at least everything works for
me on TC41 and TC33).

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

Re: [chain] conditionals again

2003-10-22 Thread Ted Husted 
Greg Reddin wrote:
If this is the case, how are we any better off with this model than we 
were with a monolithic request processor?  Why should the commands have 
so much inter-dependence now that they are separate objects?  Are we 
better off with them as inter-dependent separate objects than we were as 
one monolithic object?
The next step might be to try and integrate something like Struts 
Workflow and/or Tiles into the RequestProcessor chain and see what the 
various Chains look like.

Though, regardless of what happens with the Struts RequestProcessor (a 
*very* complicated bit of business logic), I'm finding Chain to be a 
very useful interface to an application's business layer.

-Ted.



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

Re: Reviving PageController (ViewController?) discussion?

2003-10-22 Thread Ted Husted 
Joe Germuska wrote:
See Ted's recent post copied in below...  I'm definitely going to look 
at Chain before I invest a lot of energy in a PageController that works 
as earlier discussions have gone.
So, just to report back. I tried using view Command in place of view 
action. It worked fairly well at first. You end up with a number of 
Chains terminating in a view Command, which is fine under most 
circumstances. Though, it starts to get clumsy when you are bridging 
between flows, say from a "insert" flow to a "display detail" flow. So, 
I've gone back to using a view action again. Though, there's only one 
class that is passed the Command name as a parameter. So the view action 
just runs a view Command.

Some frameworks, like Maverick, directly supports the notion of a page 
controller with its own extension point. This seems like a useful 
strategy for Struts to consider.

The conflicting issues seem to be

* We do want to give ActionForward an extension point so that it can 
prepare the request before forwarding to its resource.

* We don't want to confuse matters by introducing another navigational 
decision point. Once the Action has selected an ActionForward, that 
ActionForward should be responsible for the response.

* We don't necessarily want to introduce another class into the mix.

A side issue is that it would be helpful if the framework provided 
better support for selecting alternate paths for an ActionForward, based 
on Locale or other properties ("/pages/en/this.jsp" vs 
"/pages/fr/this.jsp").

So, in addition to preparing the request, the ActionForward extension 
point might also want to adjust the path (or choose between paths 
provided in the configuration).

No concrete proposal; I just wanted to keep this on the table.

-Ted.



--
Ted Husted,
  Junit in Action  - ,
  Struts in Action - ,
  JSP Site Design  - .


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

DO NOT REPLY [Bug 21906] - IncludeTagTest fails under TC 4.1, TestErrorsTag1 fails under TC 3.3

2003-10-22 Thread 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=21906

IncludeTagTest fails under TC 4.1, TestErrorsTag1 fails under TC 3.3

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-10-23 03:13 ---
This still fails for me could someone else
verify that the test.tomcat.41 test passes.

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

RE: DO NOT REPLY [Bug 21906] - IncludeTagTest fails under TC 4.1, TestErrorsTag1 fails under TC 3.3

2003-10-22 Thread James Mitchell 
This has been the source of many nights of frustration for me.  

The problem appears to be with Cactus.

Here's what I'm doing:
Windows XP Pro
JDK 1.4.1_02
Cactus 13-1.4.1 
and a brand spanking new cvs checkout


As I am typing this, I am remote debugging Jboss/Tomcat and with a
breakpoint set on the infamous TestIncludeTag, I execute this in a
browser:

http://localhost:8080/test/JspRedirector?Cactus_TestMethod=testIncludeTa
gForward&Cactus_TestClass=org.apache.struts.taglib.bean.TestIncludeTag&C
actus_AutomaticSession=true&Cactus_Service=CALL_TEST&cacheId=1

...the remote debugger correctly stops at my breakpoint

I create a new Expression as "request.getServerPort()" and I'll give you
3 guesses as to what it evaluates to

I don't have the source (nor the desire to attain it) for any version of
Cactus for further investigation, but it appears that the request
wrapper (org.apache.cactus.server.HttpServletRequestWrapper) is not
returning the correct value, which causes several tests to fail.

Using any of the tags in a normal environment (non cactus) works
fine..go figure.


--
James Mitchell
Software Engineer / Struts Evangelist
http://www.struts-atlanta.org
678.910.8017
AIM:jmitchtx




> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, October 22, 2003 11:14 PM
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 21906] - IncludeTagTest fails 
> under TC 4.1, TestErrorsTag1 fails under TC 3.3
> 
> 
> 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=21906

IncludeTagTest fails under TC 4.1, TestErrorsTag1 fails under TC 3.3

[EMAIL PROTECTED] changed:

   What|Removed |Added


 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-10-23 03:13
---
This still fails for me could someone else
verify that the test.tomcat.41 test passes.

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


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

RE: DO NOT REPLY [Bug 21906] - IncludeTagTest fails under TC 4.1, TestErrorsTag1 fails under TC 3.3

2003-10-22 Thread Steve Raeburn 
I ran the tests today on 33 and 41 with a new checkout and everything
worked. Strange. I'll do it it again tomorrow to double check that I'm not
crazy.

(I'm on 1.4.2_01, W2K, Cactus 13-1.4.1, TC3.3a, TC4.1.27)

Steve

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]
> Sent: October 22, 2003 10:49 PM
> To: 'Struts Developers List'
> Subject: RE: DO NOT REPLY [Bug 21906] - IncludeTagTest fails under TC
> 4.1, TestErrorsTag1 fails under TC 3.3
>
>
> This has been the source of many nights of frustration for me.
>
> The problem appears to be with Cactus.
>
> Here's what I'm doing:
> Windows XP Pro
> JDK 1.4.1_02
> Cactus 13-1.4.1
> and a brand spanking new cvs checkout
>
>
> As I am typing this, I am remote debugging Jboss/Tomcat and with a
> breakpoint set on the infamous TestIncludeTag, I execute this in a
> browser:
>
> http://localhost:8080/test/JspRedirector?Cactus_TestMethod=testIncludeTa
> gForward&Cactus_TestClass=org.apache.struts.taglib.bean.TestIncludeTag&C
> actus_AutomaticSession=true&Cactus_Service=CALL_TEST&cacheId=1
>
> ...the remote debugger correctly stops at my breakpoint
>
> I create a new Expression as "request.getServerPort()" and I'll give you
> 3 guesses as to what it evaluates to
>
> I don't have the source (nor the desire to attain it) for any version of
> Cactus for further investigation, but it appears that the request
> wrapper (org.apache.cactus.server.HttpServletRequestWrapper) is not
> returning the correct value, which causes several tests to fail.
>
> Using any of the tags in a normal environment (non cactus) works
> fine..go figure.
>
>
> --
> James Mitchell
> Software Engineer / Struts Evangelist
> http://www.struts-atlanta.org
> 678.910.8017
> AIM:jmitchtx
>
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, October 22, 2003 11:14 PM
> > To: [EMAIL PROTECTED]
> > Subject: DO NOT REPLY [Bug 21906] - IncludeTagTest fails
> > under TC 4.1, TestErrorsTag1 fails under TC 3.3
> >
> >
> > 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=21906
>
> IncludeTagTest fails under TC 4.1, TestErrorsTag1 fails under TC 3.3
>
> [EMAIL PROTECTED] changed:
>
>What|Removed |Added
> 
> 
>  Status|RESOLVED|REOPENED
>  Resolution|FIXED   |
>
>
>
> --- Additional Comments From [EMAIL PROTECTED]  2003-10-23 03:13
> ---
> This still fails for me could someone else
> verify that the test.tomcat.41 test passes.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



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