Debugger in Forte.

Can someone please...please help me with Forte debugger ?
I'm able to start the debugger, but do not know how to walk the debugger one line at a time through the code.
Any help/pointers would be much appreciated.
Thanks in advance.

Several people including me have given detailed answers to your question already, yet you're still posting, so obviously we're missing something. Could you be a bit more specific on what you need? Are we talking about an application, an applet, a JSP...Do you know how to set a breakpoint? Are you starting the program successfully but just don't know how to single step?

Similar Messages

Forte Debugger Question - How to break on exception?

I am running my midlet under Forte Community Edition 3.0, and I am trying to track down a crash. The output window shows that a NullPointerException was thrown, so it should be a simple matter of finding the line with the offending allocation, but I cant find any way to make the debugger break on an exception. Is this possible?
Thx,
Fred

I'll answer my own question here....the best thing I have found so far is to put a high level catch in the code, then call Exception.printStackTrace in the catch block. Its not ideal, but it helps find the offending code.
Fred

Why does debugger not find source code when compiler output has been directed to the root directory, but the source is in a sub-directory, using Forte for JAVA community edition V3.0

I have configured Forte to put compiler output, i.e. my classes, in the root directory of the project. I now find that the debugger does not find the source code when it is in a sub-directory. However, if I temporarily copy a classes' source code to the root directory the debugger will display it.
To direct compiler output to the root directory I selected Project >Settings>Compiler types, then External Compiler ( which is the default compiler in my case ) and set Target to be the root project directory. This is the only directory it will allow.

This Forum is for Forte 4GL or UDS as its called today. I am not sure if anybody is going to be able to answer your question here. Sorry.
ka

Forte debugger exits (FATAL ERROR in native method: JDWP "util.c")

When debugging my GUI app in Forte on Solaris 8, my debug session exits with the following error:
FATAL ERROR in native method: JDWP "util.c" (Feb 20 2002), line 1029: Unexpected error, error code = 113 (JVMDI_ERROR_INTERNAL)
It seems to do so while in the middle of a comm api routine where I'm accessing the serial port. Has anyone else ever seen this error is Solaris? I have all of the patches required by Sun for JDK1.3.1_02 installed with the same version of the JDK.
The application runs fine when I run it standalone...
Any suggestions?
Thanks.

I've had the same problem. It appears that it occures when an error is thrown that stop a JSP page load.
Everything will run find up to that point, but after that, the util.c error will not go away except by deinstall and reinstall of Forte. We can't even use Forte at this point since it will start throwing the error within 1 hour of reinstall. Crap.
I'm on Windows XP also, and this happens with JVM 1.3 or 1.4.

Problem w/ Forte debugger

While I like Forte a lot it sometimes baffles me with cryptic responses: tracing (F7) into a simple public class file with a couple of other classes defined down in same file - it responds before it even traces one line :
java.lang.NoClassDefFoundError: SportsUnion (wrong name: C/SportsUnion)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:486)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
Exception in thread "main"
How on earth can the name be "wrong"? It compiles just fine. Any help would be appreciated. To anyone whom may answer this there's yet another odd one I just found.
Thanks J.T.

Hello TownsendJ,
Maybe you can simply the class that you are debugging and post it on the Forum so that we can try to reproduce the execption that you are getting.
-Merwyn,
Developer Technical Support,
http://www.sun.com/developers/support.

Forte Debugger crashes in Solaris 8 on Sparc

Just did a brand new install of Forte4J 3 on my Sparc Ultra 30 and am experiencing a crash problem while debugging my swing application. The debug process exits intermittently although when the code is executed standalone it runs fine. The error thrown is:
FATAL ERROR in native method: JDWP "util.c" (Feb 20 2002), line 1029: Unexpected error, error code = 113 (JVMDI_ERROR_INTERNAL)
Has anyone else experienced this?

Well, looks like I didn't have an OS patch installed correctly. After re-installing all of the listed patches required, the crash stopped happening.
When all else fails, RTFM.

Creating Forte FieldWidgets Dynamically at Runtime

Hi Everyone,
Could someone please help me with the following problem I have when
creating Forte fieldwidgets dynamically at run-time. I am using Forte
ver. 3.0.G.2.
(-1-) I have a window class with an empty gridfield, <grfMain>, inside a
viewport. The idea is to populate the gridfield with DataField
fieldwidgets dynamically at runtime. Depending on some input criteria,
sometimes some of the DataFields need to map to IntegerNullables, some
to DoubleNullables and some to DateTimeNullables. (Please note that I
cannot use the Forte window workshop to create these fieldwidgets,
because different types of fieldwidgets will be needed at different
times, in different numbers, at run-time. ) Here is a sample of how I am
currently trying to achieve this:
dfDate : DataField = new;
dfDate.MaskType = MK_Template;
dfDate.DateTemplate = new( value='dd/mm/yyyy' );
dfDate.Row = 1;
dfDate.Column = 2;
dfDate.Parent = <grfMain>;
dfInt : DataField = new;
dfInt.MaskType = MK_INTEGER;
dfInt.Row = 2;
dfInt.Column = 2;
dfInt.Parent = <grfMain>;
dfReal : DataField = new;
dfReal.MaskType = MK_FLOAT;
dfReal.Row = 3;
dfReal.Column = 2;
dfReal.Parent = <grfMain>;
The code above is called after the window has been opened with the
Open() statement.
Looking at the code above, one obvious omission is that the "Mapped
Type" of the Datafields are not set up. In the Forte window workshop, an
interface is provided to set up the "Mapped Type" of the Datafield
widgets, but I'm not sure how to do that dynamically, and that is
basically my biggest problem here.
(-2-) If I now run the window class, the Datafield widgets get created,
and they all have the correct input maks, but no validation gets done
when one tabs away from the field. For example, Datafields with
MaskType=MK_INTEGER will gladly accept '--1--0++7', while Datafields
created in the window workshop (mapping to IntegerNullables) will do a
validation, and not allow one to tab out of the field before the extra
minus and plus signs are not removed.
I have the same problem with the Datafields which have
MaskType=MK_Template and DateTemplate='dd/mm/yyyy'. For the date, one
can enter something like '2*\**\****', and leave the field, while the
same type of datafield created in the window workshop (mapped to a
DateTimeNullable), will not allow you to leave the field before a valid
date has not been entered. To summarise, the input masks of my
dynamically created Datafields work fine, but no validation gets done
when the field looses the focus.
(-3-) As a test, I used the Forte debugger ("view"-"local variables") to
look at the differences between Datafields created dynamically, and
those created in the Forte window workshop. One very obvious difference
was that Datafield attribute "MapTypeName" was filled in for the window
workshop Datafields, but not for my dynamically created Datafields. The
problem is that Forte does not allow me to set this attribute
dynamically in my code. How else can I setup the Mapped Type
dynamically?
(-4-) In order to have a consistent look-and-feel throughout our Forte
project, we are making use of Domain classes for DATE and DECIMAL data
entry fields. My questions are:
(4.1) How must I go about creating Datafields dynamically that make use
of these Domain classes?
(4.2) Is it also a matter of setting up the "MapTypeName" attribute,
which I cannot seem to do?
(4.3) Is the mapping done differently for Domain classes?
(-5-) Another interesting thing to note for Datafields created in the
Forte Window Workshop, is that if the mapped type is IntegerNullable
with Input Mask = Integer, or DoubleNullable with Input Mask = Float,
then the Object that the Datafield widget maps to, must first be
instantiated before the Loose-Focus validations will start to work. For
example, if a Datafield widget called "dfTestInt" was created in the
Forte window workshop, which maps to an IntegerNullable, and Input Mask
= Integer, then the following line is needed before the window is
displayed: dfTestInt = new;
Without this line, one can enter something like '2---3+++7', and leave
the field.
This is not true for Datafields where the mapped type is
DateTimeNullable with say Input Mask Template='dd\mm\yyyy'. In this case
validations are done even thought the object being mapped to, has not
been instantiated yet. In other words you will never be able to enter
'2*/**/****', and leave the field for datafield created in the window
workshop. Maybe in this case the validation is being done by the
template itself?
Thanks in advance
Riaan
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

what I mean is rendering JSF components on the fly, becuase some time you don't know things at design time. Lets say I am designing a page in creator that shows the total number of dependants that belongs to a primary inusrance member in text boxes. Of course we don't know in advance how many dependants we have for a specific member unless we go to databse and fetch all the data at runtime. Desiging some thing dynamic like that is very easy in CGI or ASP/JSP but JSF model seems very static due to it's design time feature.
So is it possible with JSF or not?

Debugger hanging !!!

Hi all,
unfortunately, I am the chosen for developing under Solaris, using Forte Develop 6.0.
When debugging my application, workshop becomes instable regularly; especially when using the 'Step Over (F7)' command. Workshop is hanging and will never return, so the only solution left is to exit workshop and start all over. I tried updating to 6.0 update 1, but then my class constructors are not handled correctly !!
And something else: the debugger always launches my 'main.cc' source file when started; what the fuck is that good for ???
I am really wondering whether this software is tested before it is released...
By the way: does anyone know how to switch off the fucking 'Re-usable' option in NEdit for ever ?
Yes, as you already may have concluded, I am NOT pleased with working under Forte Develop (and even the entire Solaris environment)...

Nope. I developed the whole core in debug mode of Flex Builder 3, so I know it works there.
Mike

Re: tracing execution and standard Forte messagefilters

Pierre,
There is a tech note describing some of the trace flags that will show
you interpreter profile information. This interface, the information
produced, etc. may change in future releases that's why it's a tech
note and not in the documentation set.
Hope this helps,
Bobby
This note describes how to use the execution profile collector built into
the Tool Interpreter.
NOTE: THIS INTERFACE IS UNSUPPORTED BUT IS MADE AVAILABLE AS IS TO USERS
UNTIL A SUPPORTED INSTANCE OF THE FEATURE EXISTS.
THE SUPPORTED VERSION WILL HAVE A DIFFERENT FUNCTIONALITY AND FORM.
The Tool Interpreter contains an execution profile data collector. The
collection
information can be displayed as trace output or the raw data can be collected
by the program for further manipulation and display. This information
describes the current level of support available. It is possible that this
mechanism will be updated in future releases and/or integrated into the
TOOL debugger.
The profiler only counts intructions executed in the interpreter, it doesn't
account for time spent in C++ code. However it is sill useful in finding
problems in interpreted code and for viewing the dynamic call flow of the
application.
The following trace information is available:
TRACE CALL-RETURN
This trace outputs a single indented line for each method call and
another single line for each method return. The line is indented an
amount equal to the call depth of the task calling the method. The
following information is displayed:
Task Id
Task Name
Method Name
Method Instruction Count
Task(Id=5,Name=InitialLom)Method(Name=Forte.TopClass.StartUp)
Task(Id=5,Name=InitialLom)Method(Instructions=10)
This is enabled using trace setting trc:in:50:1.
This trace can also be used to see the control flow of an application.
TRACE TASK BY METHOD
This trace outputs information about a task and all of the methods that
where called during it's execution. Each method contains information
about the number of times that the method was called and the total
number of instructions consumed by the methods execution. The task
contains the totals of all calls and instructions performed by the
task. The methods are sorted in descending order of instructions
executed.
The following in an example of the output:
TaskByMethod(Id=9,Name=projws.display,Instructions=2212)
ide.projws.updateMenus(Called=1,Instuctions=556)
ide.projws.addBlockComponentsToTree(Called=1,Instuctions=321)
ide.projwsPrefs.LoadPrefs(Called=1,Instuctions=247)
ide.projwsPrefs.Apply(Called=1,Instuctions=206)
UtilsDisplay.PrefMgr.FetchUserPref(Called=12,Instuctions=168)
ide.projws.computeWindowSize(Called=1,Instuctions=168)
ide.projws.refreshBrowser(Called=1,Instuctions=76)
UtilsBase.CompileSession.SetScope(Called=1,Instuctions=68)
ide.projws.fillToolObjTree(Called=1,Instuctions=65)
ide.projws.setTitle(Called=1,Instuctions=53)
UtilsBase.CompileSession.Init(Called=1,Instuctions=48)
UtilsBase.InterfaceBrokerBase.GetCompileSession(Called=1,Instuctions=41)
UtilsBase.InterfaceBrokerBase.LockSession(Called=1,Instuctions=30)
AppModel.abSurrogateRepositoryClient.GetRepository(Called=3,Instuctions=21)
UtilsBase.InterfaceBrokerBase.UnlockSession(Called=1,Instuctions=20)
UtilsDisplay.Workshop.Events(Called=1,Instuctions=20)
UtilsDisplay.Workshop.HelpEvents(Called=1,Instuctions=19)
ide.projws.lookupMask(Called=1,Instuctions=17)
UtilsBase.CompileSession.GetVersionStateForPlan(Called=1,Instuctions=14)
ide.projws.LoadPrefs(Called=1,Instuctions=13)
AppModel.abSurrogateRepositoryClient.GetVersionStateForPlan(Called=1,Instuct
ions=8)
AppModel.abSurrogateRepositoryClient.FindProject(Called=1,Instuctions=8)
ide.projws.resetCurrentNode(Called=1,Instuctions=7)
AppModel.abSurrogateRepositoryClient.IsDetached(Called=1,Instuctions=7)
ide.projws.selectComponent(Called=1,Instuctions=6)
ide.projwsPrefs.Init(Called=1,Instuctions=5)
This is enabled using trace setting trc:in:51:1.
TRACE APP BY METHOD
This trace outputs information about an application and all of the
methods that were called during its execution. Each method contains
information about the number of times that the method was called and
the total number of instructions consumed by the methods execution.
The application contains the totals of all calls and instructions
performed by the task.
The output is similar to the previous case.
This is enabled using trace setting trc:in:53:1.
TRACE TASK BY CALLTREE
This trace outputs the call tree of the task. The call tree shows a
method and all of the methods that it called. And for each of the
called methods the same output is displayed. This can be used to
see more of the call structure of a task. It call also be used to
find the paths in the call tree that consumed most of the instructions.
The methods are sorted in descending order of instructions executed
within each level of the call tree.
TRACE APP BY CALLTREE
This trace outputs the call tree of the application. The call tree
shows a method and all of the methods that it called. And for each of
the called methods the same output is displayed. This can be used to
see more of the call structure of an application. It call also be used
to find the paths in the call tree that consumed most of the
instructions.
The output is similar to the previous case.
This is enabled using trace setting trc:in:54:1.
The following collected information is available:
NOTE: None of the collection options are available at this time.
COLLECT TASK BY METHOD
COLLECT APP BY METHOD
COLLECT TASK BY CALLTREE
COLLECT APP BY CALLTREE
Other potential future features:
The profiler doesn't record when some interpreted TOOL code invokes a method
on a object which in implemented in C++. This causes some profile
information to be lost. If the C++ code invokes a method that is
implemented as interpreted TOOL the BYCALLTREE profile will not show the
C++ code. Thus it could be confusing because it appears that the
interpreted code called something totally different than the what is
expected.
At 10:41 AM 7/31/96, Pierre Gelli wrote:
Hello,
During the process of tuning an application, or just of making it work, it
is useful to trace the flow of processing.
There are two ways of doing it :
1) add your own trace instructions (calls to the LogMgr) at the appropriate
places,
2) use the traces of the Forte Interpreter !
If one relies on solution 1, then it relies on what the developers have
written (and thus sometime forgotten to write !) in their code.
If one relies on solution 2, then potentially it can get as much information
as is available to the interpreter (and the debugger ?), in a fully
independant way since it uses directly the code itself and not added trace
instructions.
So solution 2 seems quite interesting.
Unfortunately there are some potential problems :
a) I haven't found in the documentation an exhaustive description of the
logs the Forte tools do. The only and very short description is on page 148
of the System management Guide. It's far from being exhaustive. So it
requires playing with the filters.
I recommand trying trc:in:1-63. I guess "in" stands for the interpreter.
- level 1 seems to give the call tree,
- level 255 seems to give almost the code !
b) since the flags are not documented by Forte, how reliable and stable will
they be in future versions ?
c) what happens for compiled partitions is not clear to me (I have not tried
it yet).
So my question : are the message filters used by the Forte Tools like the
interpreter described somewhere, i.e. in some Tech Note (I don't have access
to them yet) ?
best regards,
Pierre Gelli
ADP GSI
Payroll and Human Resources Management
72-78, Grande Rue, F-92310 SEVRES
phone : +33 1 41 14 86 42 (direct) +33 1 41 14 85 00 (reception desk)
fax : +33 1 41 14 85 99

From: Pierre Gelli <[email protected]>
Subject: tracing execution and standard Forte message filters
Hello,
During the process of tuning an application, or just of making it work, it
is useful to trace the flow of processing.
There are two ways of doing it :
1) add your own trace instructions (calls to the LogMgr) at the appropriate
places,
2) use the traces of the Forte Interpreter !
So solution 2 seems quite interesting.
Unfortunately there are some potential problems :
a) I haven't found in the documentation an exhaustive description of the
logs the Forte tools do. The only and very short description is on page 148
of the System management Guide. It's far from being exhaustive. So it
requires playing with the filters.
I recommand trying trc:in:1-63. I guess "in" stands for the interpreter.
- level 1 seems to give the call tree,
- level 255 seems to give almost the code !
b) since the flags are not documented by Forte, how reliable and stable will
they be in future versions ?
Pierre Gelli,
level 255 is the most detailed you are right on tracing..... As for documentation
you will want to get ahold of several good tech notes that your Forte
rep or support can get you which provide alot of the info you are after.
Let me know if you can't do this and I can send you some of this info, but you are
best to get the latest and greatest directly from Forte.
Len Leber
ATG Partners

Forte for JAVA: Problems with break points

Dear all,
I have the following problem:
When setting breaks point within the code of my web application (servlets and JSP) the debugger does not seem to be able to find them and to stop where I would it to :o(
When approching a portion of code that I know have a break point, I get the following message in the debugger window->
Connecting to localhost.localdomain:11555
Connection established
Breakpoint reached at line ? in class org.corproware.strutsrelated.listener.DBPoolListener by thread main.
Note the interrogation mark (?) instead of a valid line number.
It looks like I have the same poroblem with a simple java "HelloWorld"
Is their something I don't get or is it a known problem?
Many thanks!

Sorry mate, wrong forum. You shoud try Sun ONE Studio Forum isntead of this one. It is for UDS (Formerly known as Forte)

Forte for java 4 ce

I have downloaded forte 4 community edition. I want to run a stand alone swing application using the accompanying RDBMS pointbase 4.2. While connecting to database it is giving error: 'class not found' com.pointbase.jdbc.....
I think i can overcome this by appending classpath: pointbase\lib\pbserver42.jar. But the problem now is Forte 4 does not allow editing the default debugger classpath. And adding to the classpath of debugger execution in execution type and running debug executor also does not help.
Can somebody help please

I have downloaded forte 4 community edition. I want to
run a stand alone swing application using the
accompanying RDBMS pointbase 4.2. While connecting to
database it is giving error: 'class not found'
com.pointbase.jdbc.....
I think i can overcome this by appending classpath:
pointbase\lib\pbserver42.jar. But the problem now is
Forte 4 does not allow editing the default debugger
classpath. And adding to the classpath of debugger
execution in execution type and running debug executor
also does not help.
Can somebody help pleaseI suggest (if forte 4.0 is like 3.0) you add the jar by right-clicking on the root of the filesystem (the thing at the left of the screen where you have all your files) which name is "Filesystem" and select "Mount JAR ...".
Hope it helps.
Aude.

Problem: List images / Palm / Forte

Are there any issues with creating JAR files that contain PNG files with Forte?
I cannot seem to get images to display in a List on a Palm. With the Forte debugger, I am able to see that the Image is found. No exceptions are throw when I try to get a handle on the PNG.
When it comes to displaying the image, the default list icon is displayed instead.
My image is a black and white, 10x10 PNG image. It is 1kb in size.
Has anyone experienced this problem? If so, how did you solve it?

[kevinsikora],
Not that I know of. With the MIDP 1.0 for PalmOS, there is a restriction of the maximum image file size of 64 kbytes for a PNG image file.
Can you check the Preferences settings on the "Java HQ" AMS application? There is a setting for the color for the MIDP for Palm OS 1.0 environment, that should state black and white since your PNG image is black and white.
Can I assume that you are using the Image.createImage() method in your code and that the PNG file is placed correctly in the JAR file?
HTH.
Rgds,
Allen Lai
Developer Technical Support
Sun Microsystems
http://access1.sun.com

Searching for a good java debugger

Hi all,
I am a new java developer, i was used to work with c++ builder. I am developing java projects without ide help (plain text, actually with JCreator) . I want to find a good ide debugger (like c++ builder's debugger). I tried to use JBuilder but i can not import my existing project to the JBuilder debugger. Do you know any ide debugger that i can import my project? What about Forte? I have not used it yet. May be tips about importing my .java files in the JBuilder debugger.
Thank you for advance, Kostas.

Careful, I might put you on the list too! -:) No just
kidding but blown up wannabe Java experts like
LadyFoxy and Sscotties should be very careful.
Eventually they'll meet the Nightmare Bwitch, and then
it's over!me! me!
do me next :)
to OP, a debugger you ask for? well not exactly the thingie you're looking for, but in some cases quite useful debugger is a omniscient debugger:
http://www.lambdacs.com/debugger/debugger.html
... but its still experimental or something, so it might not yet be fine tuned for every task, it's the idea that counts...

Tracing execution and standard Forte message filters

Hello,
During the process of tuning an application, or just of making it work, it
is useful to trace the flow of processing.
There are two ways of doing it :
1) add your own trace instructions (calls to the LogMgr) at the appropriate
places,
2) use the traces of the Forte Interpreter !
If one relies on solution 1, then it relies on what the developers have
written (and thus sometime forgotten to write !) in their code.
If one relies on solution 2, then potentially it can get as much information
as is available to the interpreter (and the debugger ?), in a fully
independant way since it uses directly the code itself and not added trace
instructions.
So solution 2 seems quite interesting.
Unfortunately there are some potential problems :
a) I haven't found in the documentation an exhaustive description of the
logs the Forte tools do. The only and very short description is on page 148
of the System management Guide. It's far from being exhaustive. So it
requires playing with the filters.
I recommand trying trc:in:1-63. I guess "in" stands for the interpreter.
- level 1 seems to give the call tree,
- level 255 seems to give almost the code !
b) since the flags are not documented by Forte, how reliable and stable will
they be in future versions ?
c) what happens for compiled partitions is not clear to me (I have not tried
it yet).
So my question : are the message filters used by the Forte Tools like the
interpreter described somewhere, i.e. in some Tech Note (I don't have access
to them yet) ?
best regards,
Pierre Gelli
ADP GSI
Payroll and Human Resources Management
72-78, Grande Rue, F-92310 SEVRES
phone : +33 1 41 14 86 42 (direct) +33 1 41 14 85 00 (reception desk)
fax : +33 1 41 14 85 99

From: Pierre Gelli <[email protected]>
Subject: tracing execution and standard Forte message filters
Hello,
During the process of tuning an application, or just of making it work, it
is useful to trace the flow of processing.
There are two ways of doing it :
1) add your own trace instructions (calls to the LogMgr) at the appropriate
places,
2) use the traces of the Forte Interpreter !
So solution 2 seems quite interesting.
Unfortunately there are some potential problems :
a) I haven't found in the documentation an exhaustive description of the
logs the Forte tools do. The only and very short description is on page 148
of the System management Guide. It's far from being exhaustive. So it
requires playing with the filters.
I recommand trying trc:in:1-63. I guess "in" stands for the interpreter.
- level 1 seems to give the call tree,
- level 255 seems to give almost the code !
b) since the flags are not documented by Forte, how reliable and stable will
they be in future versions ?
Pierre Gelli,
level 255 is the most detailed you are right on tracing..... As for documentation
you will want to get ahold of several good tech notes that your Forte
rep or support can get you which provide alot of the info you are after.
Let me know if you can't do this and I can send you some of this info, but you are
best to get the latest and greatest directly from Forte.
Len Leber
ATG Partners

SAXParser noSuchMethodError occurs in execution, not in debug with Forte

Hi gurus
Im having some trouble with parsing an XML file using xerces.
Basically all i want to do is take a list of XML files from a JFileChooser and then change the list to display the value of an attribute within that file instead of the original file name. The list bit is easy and i have the file chooser list and all the File objects within it.
My code is as follows
"factory" is a SaxParserFactory and "handler" is an instance of a DefaultHandler subclass that i have written.
ListModel lm = fileList.getModel();
        SAXParser saxparser ;
        try {
            saxparser = factory.newSAXParser();
            for (int i = 0; i < lm.getSize(); i++) {
                File theFile = (File)lm.getElementAt(i);
                // sax parse each file
                if (!theFile.isDirectory() && theFile.getName().endsWith(".xml"))
                saxparser.parse(theFile, handler);
        catch (Throwable t ) {
         t.printStackTrace();
        }The problem i have is that running this normally throws an exception, a NoSuchMethodError on the saxparser.parse(theFile, handler) method. HOWEVER, when i run this using the Forte debugger it works fine when i step through each line.
Anyone got any ideas??
Mark

I think I'm having a similar problem. When I try to compile my code that is almost identical to yours, it gives me a "Cannot resolve symbol" error on the SAXParser.parse() method. It only gives me this error when I pass in a DefaultHandler object. If I use a HandlerBase object, it seems to work, but I'd obviously rather not use a deprecated object. I've tried passing in File objects, InputStreamObjects, just about any possibility that it SAYS the method supports, but Forte won't compile it, while it seems to compile fine using the command line. Any thoughts?

Debugger in Forte.

Similar Messages

Maybe you are looking for