Re: Nightly build issue

[Erik Hatcher]

Oh, sorry for omitting this nightly build 20021028 is the one I 
tried and got the errors below

Erik Hatcher wrote:
I decided to try out a Struts nightly build (from a previous 1.1beta2 
version) and I ran our Cactus test suite to see if all validated ok... 
but I'm getting all Struts tests failing with this error:

String index out of range: -1

java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1520)
at
org.apache.struts.util.RequestUtils.selectApplication(RequestUtils.java:
1462)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1290)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:502)
at
servletunit.struts.CactusStrutsTestCase.actionPerform(CactusStrutsTestCa
se.java:384)

As you can see, I'm using StrutsTestCase on top of Cactus, and my test 
case looks like this:


public void testValidation() throws Exception {
setRequestPathInfo("/saveProfile");
ProfileForm form = new ProfileForm();
form.setMailForward("[EMAIL PROTECTED]");
addToParameters(form);
actionPerform();
verifyNoActionErrors();
}

This problem could certainly be in StrutsTestCase or in my custom 
'addToParameters(form)' method? - but not likely there since thats a 
pretty trivial method to put all form properties in the request. The 
tests worked fine with Struts 1.1beta2, so the only thing that changed 
was our version of Struts.

Thoughts?  I'll drop back to 1.1beta2 until something is resolved in 
either StrutsTestCase or Struts.  Any clues on what changed that could 
have caused this?

Thanks,
Erik




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





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

Re: Nightly build issue

[Erik Hatcher]

More information after digging a bit.  The change to RequestUtils (in 
version 1.61) has this log:

Revision : 1.61
Date : 2002/10/15 17:37:25
Author : 'ekbush'
State : 'Exp'
Lines : +33 -11
Description :
Change RequestUtils.selectApplication so that it looks for an exact
match
rather than using the startsWith criteria.This fixes a problem where
an incorrect module would be selected that either became aparant when
the application had modules where the name of one could be used as the
"root"
of the other.The bug also manifests itself when an action is invoked
from
the default module, which has a path that could be interpreted as a
"root" of
a non-default module.

Ex:modules /foo and /foobar
 module /foo and action /foo in the default module

PR: 12702

And here is the relevant change:

while (prefix.equals("") &&
   ((lastSlash = matchPath.lastIndexOf("/")) != 0)) {

// We may be in a non-default module.  Try to get it's
prefix.
matchPath = matchPath.substring(0, lastSlash);

// Match against the list of module prefixes
for (int i = 0; i < prefixes.length; i++) {
if (matchPath.equals(prefixes[i])) {
prefix = prefixes[i];
break;
}
}
}

lastIndexOf is obviously returning -1 meaning that there is no "/" in 
matchPath.  My application works fine deployed, so this seems like an 
interaction with StrutsTestCase or Cactus with the servlet path being null.

If anyone has ideas on where to dig further to see where a fix is needed 
then I'd happily take it the extra distance and give it a shot to fix it.

	Erik


Erik Hatcher wrote:
Oh, sorry for omitting this nightly build 20021028 is the one I 
tried and got the errors below

Erik Hatcher wrote:

I decided to try out a Struts nightly build (from a previous 1.1beta2 
version) and I ran our Cactus test suite to see if all validated ok... 
but I'm getting all Struts tests failing with this error:

String index out of range: -1

java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1520)
at
org.apache.struts.util.RequestUtils.selectApplication(RequestUtils.java:
1462)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1290)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:502)
at
servletunit.struts.CactusStrutsTestCase.actionPerform(CactusStrutsTestCa
se.java:384)

As you can see, I'm using StrutsTestCase on top of Cactus, and my test 
case looks like this:


public void testValidation() throws Exception {
setRequestPathInfo("/saveProfile");
ProfileForm form = new ProfileForm();
form.setMailForward("[EMAIL PROTECTED]");
addToParameters(form);
actionPerform();
verifyNoActionErrors();
}

This problem could certainly be in StrutsTestCase or in my custom 
'addToParameters(form)' method? - but not likely there since thats a 
pretty trivial method to put all form properties in the request. The 
tests worked fine with Struts 1.1beta2, so the only thing that changed 
was our version of Struts.

Thoughts?  I'll drop back to 1.1beta2 until something is resolved in 
either StrutsTestCase or Struts.  Any clues on what changed that could 
have caused this?

Thanks,
Erik




--
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: Nightly build issue

[Eddie Bush]

Can you verify your assumption with the logging output?  It should say 
what the value of matchPath is.  This would be a debug-level logging 
statment indicated by a line stating:

Selecting module for path 

You may have to turn up the volume on your logging output to see it. 
I'd be most interested in what's going on here.

If there is a case where the first character of matchPath may not be a 
"/" then that condition needs to change to a > instead of !=.  I was of 
the impression that the first element of that string would always be a "/".

Erik Hatcher wrote:

More information after digging a bit.  The change to RequestUtils (in 
version 1.61) has this log:

Revision : 1.61
Date : 2002/10/15 17:37:25
Author : 'ekbush'
State : 'Exp'
Lines : +33 -11
Description :
Change RequestUtils.selectApplication so that it looks for an exact
match
rather than using the startsWith criteria.This fixes a problem where
an incorrect module would be selected that either became aparant when
the application had modules where the name of one could be used as the
"root"
of the other.The bug also manifests itself when an action is invoked
from
the default module, which has a path that could be interpreted as a
"root" of
a non-default module.

Ex:modules /foo and /foobar
 module /foo and action /foo in the default module

PR: 12702

And here is the relevant change:

while (prefix.equals("") &&
   ((lastSlash = matchPath.lastIndexOf("/")) != 0)) {

// We may be in a non-default module.  Try to get it's
prefix.
matchPath = matchPath.substring(0, lastSlash);

// Match against the list of module prefixes
for (int i = 0; i < prefixes.length; i++) {
if (matchPath.equals(prefixes[i])) {
prefix = prefixes[i];
break;
}
}
}

lastIndexOf is obviously returning -1 meaning that there is no "/" in 
matchPath.  My application works fine deployed, so this seems like an 
interaction with StrutsTestCase or Cactus with the servlet path being 
null.

If anyone has ideas on where to dig further to see where a fix is 
needed then I'd happily take it the extra distance and give it a shot 
to fix it.

Erik 


--
Eddie Bush




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

Re: Nightly build issue

[Erik Hatcher]

Eddie Bush wrote:

Can you verify your assumption with the logging output?  It should say 
what the value of matchPath is.  This would be a debug-level logging 
statment indicated by a line stating:

Selecting module for path 

You may have to turn up the volume on your logging output to see it. I'd 
be most interested in what's going on here.

Unfortunately for some reason the interaction with JBoss and Log4j 
doesn't like debug output and the lowest level I can get visible is 
'INFO' level messages.  *ugh* - why is logging so darn brittle and 
troublesome?!  :/  (and yes, I've fought with this in the past, but it 
wasn't worth devoting much time to given other higher priority concerns)

If there is a case where the first character of matchPath may not be a 
"/" then that condition needs to change to a > instead of !=.  I was of 
the impression that the first element of that string would always be a "/".

Perhaps its something related to how Cactus is invoking through 
ActionServlet that the path does not begin with "/"?

Also, I'm not using modules, if that has any bearing on this.

I've noticed other fishy things with our application and the 20021028 
build that I haven't had time to dig into yet.

	Erik



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

RE: Nightly build issue

[Matt Read]

I had the same problem with JBoss. If you're on JBoss 3 then you might want
to try changing this (in log4j.xml):

  
  
  

  



to this:

  
  
  

  



Hope that helps, I had the same problem as you.

Matt.

-Original Message-
From: Erik Hatcher [mailto:jakarta-struts@;ehatchersolutions.com]
Sent: Monday, October 28, 2002 19:43
To: Struts Developers List
Subject: Re: Nightly build issue


Eddie Bush wrote:
> Can you verify your assumption with the logging output?  It should say
> what the value of matchPath is.  This would be a debug-level logging
> statment indicated by a line stating:
>
> Selecting module for path 
>
> You may have to turn up the volume on your logging output to see it. I'd
> be most interested in what's going on here.

Unfortunately for some reason the interaction with JBoss and Log4j
doesn't like debug output and the lowest level I can get visible is
'INFO' level messages.  *ugh* - why is logging so darn brittle and
troublesome?!  :/  (and yes, I've fought with this in the past, but it
wasn't worth devoting much time to given other higher priority concerns)

> If there is a case where the first character of matchPath may not be a
> "/" then that condition needs to change to a > instead of !=.  I was of
> the impression that the first element of that string would always be a
"/".

Perhaps its something related to how Cactus is invoking through
ActionServlet that the path does not begin with "/"?

Also, I'm not using modules, if that has any bearing on this.

I've noticed other fishy things with our application and the 20021028
build that I haven't had time to dig into yet.

Erik



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

Re: Nightly build issue

[Craig R. McClanahan]

On Mon, 28 Oct 2002, Erik Hatcher wrote:

> Date: Mon, 28 Oct 2002 13:42:44 -0600
> From: Erik Hatcher <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Nightly build issue
>
> Eddie Bush wrote:
> > Can you verify your assumption with the logging output?  It should say
> > what the value of matchPath is.  This would be a debug-level logging
> > statment indicated by a line stating:
> >
> > Selecting module for path 
> >
> > You may have to turn up the volume on your logging output to see it. I'd
> > be most interested in what's going on here.
>
> Unfortunately for some reason the interaction with JBoss and Log4j
> doesn't like debug output and the lowest level I can get visible is
> 'INFO' level messages.  *ugh* - why is logging so darn brittle and
> troublesome?!  :/  (and yes, I've fought with this in the past, but it
> wasn't worth devoting much time to given other higher priority concerns)
>

Agreed on brittleness.

I don't know if Log4J has the same mechanism, but I got caught on
something similar to this with JDK 1.4 logging -- there's a setting for
the minimum logging level that is written to the console handler, no
matter what the individual loggers are set for
(java.util.logging.ConsoleHandler.level).  The default level, of course,
is INFO.  It frustrated the heck out of me why I couldn't get trace or
debug output until I reset this to TRACE.

> > If there is a case where the first character of matchPath may not be a
> > "/" then that condition needs to change to a > instead of !=.  I was of
> > the impression that the first element of that string would always be a "/".
>
> Perhaps its something related to how Cactus is invoking through
> ActionServlet that the path does not begin with "/"?
>
> Also, I'm not using modules, if that has any bearing on this.
>

Module paths are supposed to have semantics like context paths -- they are
either a string starting with a slash, or a zero-length string for the
default module.  Using this approach, Struts can always construct
server-relative paths like this:

  String path = contextPath + modulePath + moduleRelativeResourcePath;

> I've noticed other fishy things with our application and the 20021028
> build that I haven't had time to dig into yet.
>

There were build problems over the weekend that might or might not be
contributing to this as well.

>   Erik
>

Craig


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

Re: Nightly build issue

[Erik Hatcher]

Excellent, thanks Matt!  That did the trick... now I just need to tune 
it so I only see the output I want to see :)

	Erik


Matt Read wrote:
I had the same problem with JBoss. If you're on JBoss 3 then you might want
to try changing this (in log4j.xml):

  
  
  

  



to this:

  
  
  

  



Hope that helps, I had the same problem as you.

Matt.

-Original Message-
From: Erik Hatcher [mailto:jakarta-struts@;ehatchersolutions.com]
Sent: Monday, October 28, 2002 19:43
To: Struts Developers List
Subject: Re: Nightly build issue


Eddie Bush wrote:


Can you verify your assumption with the logging output?  It should say
what the value of matchPath is.  This would be a debug-level logging
statment indicated by a line stating:

Selecting module for path 

You may have to turn up the volume on your logging output to see it. I'd
be most interested in what's going on here.



Unfortunately for some reason the interaction with JBoss and Log4j
doesn't like debug output and the lowest level I can get visible is
'INFO' level messages.  *ugh* - why is logging so darn brittle and
troublesome?!  :/  (and yes, I've fought with this in the past, but it
wasn't worth devoting much time to given other higher priority concerns)



If there is a case where the first character of matchPath may not be a
"/" then that condition needs to change to a > instead of !=.  I was of
the impression that the first element of that string would always be a


"/".

Perhaps its something related to how Cactus is invoking through
ActionServlet that the path does not begin with "/"?

Also, I'm not using modules, if that has any bearing on this.

I've noticed other fishy things with our application and the 20021028
build that I haven't had time to dig into yet.

	Erik



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

Re: Nightly build issue

[Erik Hatcher]

Eddie Bush wrote:

Can you verify your assumption with the logging output?  It should say 
what the value of matchPath is.  This would be a debug-level logging 
statment indicated by a line stating:

Selecting module for path 

After getting the logging opened up, my results are  is "" 
(blank, not null) when running through Cactus/StrutsTestCase, but not 
when running through a browser.  Odd.  I guess this is not a Struts 
issue per se.  I'll take this up on the Cactus list when I get a chance.

	Erik




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

Re: Nightly build issue

[Erik Hatcher]

I'm still not having any luck with this issue (now at the 20021029 
build).  I've been toying with the request.setURL call in a Cactus 
beginXXX method, but that has no effect at all on this even though I can 
tell my setting of the servlet path is working (in my testXXX I println 
request.getServletPath()).

Very strange.  I wonder if it has to do with the request value of 
RequestProcessor.INCLUDE_SERVLET_PATH being blank instead?

Anyone have thoughts on this?

Would you mind making the > than change, Eddie?  I can try it on the 
next build to see if my tests then start working.

Thanks,
	Erik


Eddie Bush wrote:
Can you verify your assumption with the logging output?  It should say 
what the value of matchPath is.  This would be a debug-level logging 
statment indicated by a line stating:

Selecting module for path 

You may have to turn up the volume on your logging output to see it. I'd 
be most interested in what's going on here.

If there is a case where the first character of matchPath may not be a 
"/" then that condition needs to change to a > instead of !=.  I was of 
the impression that the first element of that string would always be a "/".

Erik Hatcher wrote:

More information after digging a bit.  The change to RequestUtils (in 
version 1.61) has this log:

Revision : 1.61
Date : 2002/10/15 17:37:25
Author : 'ekbush'
State : 'Exp'
Lines : +33 -11
Description :
Change RequestUtils.selectApplication so that it looks for an exact
match
rather than using the startsWith criteria.This fixes a problem where
an incorrect module would be selected that either became aparant when
the application had modules where the name of one could be used as the
"root"
of the other.The bug also manifests itself when an action is invoked
from
the default module, which has a path that could be interpreted as a
"root" of
a non-default module.

Ex:modules /foo and /foobar
 module /foo and action /foo in the default module

PR: 12702

And here is the relevant change:

while (prefix.equals("") &&
   ((lastSlash = matchPath.lastIndexOf("/")) != 0)) {

// We may be in a non-default module.  Try to get it's
prefix.
matchPath = matchPath.substring(0, lastSlash);

// Match against the list of module prefixes
for (int i = 0; i < prefixes.length; i++) {
if (matchPath.equals(prefixes[i])) {
prefix = prefixes[i];
break;
}
}
}

lastIndexOf is obviously returning -1 meaning that there is no "/" in 
matchPath.  My application works fine deployed, so this seems like an 
interaction with StrutsTestCase or Cactus with the servlet path being 
null.

If anyone has ideas on where to dig further to see where a fix is 
needed then I'd happily take it the extra distance and give it a shot 
to fix it.

Erik 






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

Re: Nightly build issue

[Eddie Bush]

Erik Hatcher wrote:


I'm still not having any luck with this issue (now at the 20021029 
build).  I've been toying with the request.setURL call in a Cactus 
beginXXX method, but that has no effect at all on this even though I 
can tell my setting of the servlet path is working (in my testXXX I 
println request.getServletPath()).

Very strange.  I wonder if it has to do with the request value of 
RequestProcessor.INCLUDE_SERVLET_PATH being blank instead?

Anyone have thoughts on this?

Would you mind making the > than change, Eddie?  I can try it on the 
next build to see if my tests then start working. 

Not a bit.  I'd intended to do this already but life has been slightly 
frantic here recently.  I'll endeavor to have it there for the next 
nightly.

Thanks,
Erik 


--
Eddie Bush




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

Re: Nightly build issue

[Erik Hatcher]

Eddie and others - that change did the trick.  I'm now back in business 
with Cactus tests!  Many thanks.  I'll keep the issue open with the 
Cactus folks and I very well could be doing something strange in my test 
case configuration as well, but at least Struts is still happy and now 
I'm happy!

	Erik


Erik Hatcher wrote:
I'm still not having any luck with this issue (now at the 20021029 
build).  I've been toying with the request.setURL call in a Cactus 
beginXXX method, but that has no effect at all on this even though I can 
tell my setting of the servlet path is working (in my testXXX I println 
request.getServletPath()).

Very strange.  I wonder if it has to do with the request value of 
RequestProcessor.INCLUDE_SERVLET_PATH being blank instead?

Anyone have thoughts on this?

Would you mind making the > than change, Eddie?  I can try it on the 
next build to see if my tests then start working.

Thanks,
Erik


Eddie Bush wrote:

Can you verify your assumption with the logging output?  It should say 
what the value of matchPath is.  This would be a debug-level logging 
statment indicated by a line stating:

Selecting module for path 

You may have to turn up the volume on your logging output to see it. 
I'd be most interested in what's going on here.

If there is a case where the first character of matchPath may not be a 
"/" then that condition needs to change to a > instead of !=.  I was 
of the impression that the first element of that string would always 
be a "/".

Erik Hatcher wrote:

More information after digging a bit.  The change to RequestUtils (in 
version 1.61) has this log:

Revision : 1.61
Date : 2002/10/15 17:37:25
Author : 'ekbush'
State : 'Exp'
Lines : +33 -11
Description :
Change RequestUtils.selectApplication so that it looks for an exact
match
rather than using the startsWith criteria.This fixes a problem where
an incorrect module would be selected that either became aparant when
the application had modules where the name of one could be used as the
"root"
of the other.The bug also manifests itself when an action is invoked
from
the default module, which has a path that could be interpreted as a
"root" of
a non-default module.

Ex:modules /foo and /foobar
 module /foo and action /foo in the default module

PR: 12702

And here is the relevant change:

while (prefix.equals("") &&
   ((lastSlash = matchPath.lastIndexOf("/")) != 0)) {

// We may be in a non-default module.  Try to get it's
prefix.
matchPath = matchPath.substring(0, lastSlash);

// Match against the list of module prefixes
for (int i = 0; i < prefixes.length; i++) {
if (matchPath.equals(prefixes[i])) {
prefix = prefixes[i];
break;
}
}
}

lastIndexOf is obviously returning -1 meaning that there is no "/" in 
matchPath.  My application works fine deployed, so this seems like an 
interaction with StrutsTestCase or Cactus with the servlet path being 
null.

If anyone has ideas on where to dig further to see where a fix is 
needed then I'd happily take it the extra distance and give it a shot 
to fix it.

Erik 







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






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