The final solution to the faces exception error was more bizarre than I could have guessed. The server.xml file had gotten hosed somehow. I could open it in the XML editor but it would display as text, with no highlighting and coloring. The server.xml file I had in the debugging server config folder, opened just fine, with the syntax coloring and was virtually identical So I copied the one that was OK to the folder that wasn't (renamed the old one) and that took care of the issue, with the faces exception error.

Still no debugging though. Working on that.

Pete


Aaron Bartell wrote:
Hmmm... this could *possibly* be related to the faces-config.xml file having reference to a Java object that has been refactored to be something else. Have you done any refactoring of class names around the time that this occurred?

Not knowing how EGL does its generation (no pun intended ;-) I wonder if you took the project off of auto-build and then did a manual build if that would fix it.

HTH,
Aaron Bartell
http://mowyourlawn.com

On Tue, May 27, 2008 at 6:14 PM, Pete Helgren <Pete@xxxxxxxxxx <mailto:Pete@xxxxxxxxxx>> wrote:

Thanks. I try to clean and regenerate the project and restart the
server whenever I ran into something. It is actually weirder than
that. Last week I had no problems and then over the weekend I
attempted to hook up to my DB2 for i5/OS DB. There are some
subtleties I had to work out and I did a lot of comparing of the
imported project we used in the workshop to the project I created
from scratch and I finally figured out that I needed a context.xml
file in the META-INF folder that would point to my JNDI
resources. That solved a weird JNDI error but then I had a class
loading error (sigh!). I contacted the guy who presented the
course and he ran me through a one on one interactive tutorial for
about an hour on Memorial Day (those IBM guys are phenomenal -
doing a one on one to solve a problem on a holiday no less....). We got stuff running great in WAS 6.0, I even have debugging
available, but that was in a separate workspace.

I finally figured out my class loading issue with Tomcat in the
old workspace and got the application running but now I can't
debug. I can't debug anything, even the stuff I had working in
the imported project, so I guess my poking around to solve my
other issues have broken something else.

The latest issue in this project in this workspace is I get the
following stacktrace when I start the server:

May 27, 2008 4:31:17 PM org.apache.catalina.core.StandardContext
listenerStart
SEVERE: Error configuring application listener of class
com.sun.faces.config.ConfigureListener
java.lang.NoClassDefFoundError: javax.faces.FacesException
at java.lang.J9VMInternals.verifyImpl(Native Method)
at java.lang.J9VMInternals.verify(J9VMInternals.java:63)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:124)
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1301)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3713)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4216)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:448)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)

It is acting like it can't find the .jar but jsf-api.jar is in
web-inf/lib. It may be the reason the debugging isn't
starting...or maybe not. Still trying to resolve this on. Meanwhile, if I jump back to the new workspace with only the
single WAS project, the exact same code works fine. That is my
backup right now so I can keep "experimenting". I may just dump
everything I have done in the old workspace and create a new one
and but my Tomcat project from scratch, since I know what to look
for. Perhaps I'll get my debugging back then.

Thanks for chiming in. I was afraid no one else had subscribed to
the EGL list.

Pete



Aaron Bartell wrote:
Try restarting your app server. If a signature to a Java class
got changed then it won't necessarily be able to stop at that
breakpoint again, and if you have silenced the reminders that
popup each time you do this then you wouldn't have been
notified. This is something I run into from time to time with
regular JSF so I thought it might be your issue also.

HTH,
Aaron Bartell
http://mowyourlawn.com

On Tue, May 27, 2008 at 1:16 PM, Pete Helgren <Pete@xxxxxxxxxx
<mailto:Pete@xxxxxxxxxx>> wrote:

When I right click my JSP page and select "Debug as" and
"Debug on
server" the application doesn't break at the breakpoint,
although it
runs. Server status shows "Debugging". At one time I had
this working
but I must have broken something (no surprise there). I must
be missing
something simple but don't know what. What should I check ?

Pete

--
This is the EGL on and around the IBM i (EGL-i) mailing list
To post a message email: EGL-i@xxxxxxxxxxxx
<mailto:EGL-i@xxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/egl-i
or email: EGL-i-request@xxxxxxxxxxxx
<mailto:EGL-i-request@xxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at http://archive.midrange.com/egl-i.



--
This is the EGL on and around the IBM i (EGL-i) mailing list
To post a message email: EGL-i@xxxxxxxxxxxx
<mailto:EGL-i@xxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/egl-i
or email: EGL-i-request@xxxxxxxxxxxx
<mailto:EGL-i-request@xxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at http://archive.midrange.com/egl-i.



This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].