Running on Xp with WSAD5.0.1 (acts the same in 5.1) an action class is
simply not being called when it is configured identically with others called
in the same manner. It never gets into the action class but kicks out with
a null pointer exception. There is mention of the RequestProcesso r which I
was going to customize but did not. An html:link with path of
mystuff\mtstuff Action.do?reqTy pe="myType" which is exactly they way other
nav picks are fired off. My Action class has worked when we went to a key
entry page first and then detail, but now we know the keys ahead of time so
we attempt to fire off the transaction that gets data in the Action class,
but it is all moot as we never get to it. We have an extended Action
Servlet that has a nav and session filter which I do not believe to be a
problem. The code has been verified exact to that of working modules. I
think this qualifies as a potential bug. I can send anything you want to
specifically show you. What is worse, the error is so low level, clearly
struts has introduced a serious maintenance issue and unwanted complexity -
all famous in Java usage history. Is Struts confusing WSAD
or vica versa? How can I debug at that level. Do I have to pull in all the
source code and compile struts? That is something I would hate to do based
on tiume constraints and for something that should be easy. Please let me
know of similar mind-numbing problems and how they were solved. Don't
dissect the line I made up above, that was an example from memory. The
command is exactly as the others that work with no known differences.
simply not being called when it is configured identically with others called
in the same manner. It never gets into the action class but kicks out with
a null pointer exception. There is mention of the RequestProcesso r which I
was going to customize but did not. An html:link with path of
mystuff\mtstuff Action.do?reqTy pe="myType" which is exactly they way other
nav picks are fired off. My Action class has worked when we went to a key
entry page first and then detail, but now we know the keys ahead of time so
we attempt to fire off the transaction that gets data in the Action class,
but it is all moot as we never get to it. We have an extended Action
Servlet that has a nav and session filter which I do not believe to be a
problem. The code has been verified exact to that of working modules. I
think this qualifies as a potential bug. I can send anything you want to
specifically show you. What is worse, the error is so low level, clearly
struts has introduced a serious maintenance issue and unwanted complexity -
all famous in Java usage history. Is Struts confusing WSAD
or vica versa? How can I debug at that level. Do I have to pull in all the
source code and compile struts? That is something I would hate to do based
on tiume constraints and for something that should be easy. Please let me
know of similar mind-numbing problems and how they were solved. Don't
dissect the line I made up above, that was an example from memory. The
command is exactly as the others that work with no known differences.