Bernhard Haeussermann

Hi Anders,

the syntax for calling a method having no parameters on an object in Objective-C is as follows:
[myObject myMethod]
The syntax for calling a method with a number of parameters is:
[myObject myMethodParam1:paramValue1 param2:paramValue2 param3:paramValue3]
In this example the name of the method is myMethodParam1:param2:param3: (each ':' acts as a placeholder for a parameter) and paramValue1, paramValue2, and paramValue3 are names of variables.

In Objective-C, each pair of square brackets delimit one method call. In your example there are two method calls: one to the objectAtIndex: method and one to the getValueInDollars method - thus you need two pairs of square brackets, like this:
valueInDollars+=[[array objectAtIndex:i] getValueInDollars];
I found a good basic tutorial about Objective-C here on Cocoa Dev Central. I recommend you work through it - it will make your life much easier.

No, if either condition becomes false the loop will exit.

I mean the loop with the condition (numBounces < 10).
I meant that you limit the number of iterations of this loop to say 100. You could do this by replacing
while (numBounces<10)
by
for (int i=0; (numBounces<10) && (i<100); i++)
just to get a feel for what's going on.

Yes, I would suggest that you use a spring worker, so that you draw a line on the UI.

Initially, you can limit the number of iterations of the main loop to, say 100, and then plot the points to see what it looks like and continue from there.

Running a very time consuming operation in an event listener's code will make the GUI unresponsive. The GUI will not respond until the call to actionPerformed() (or whatever may be the case) returns. So, yes, using a spring worker should make the UI more responsive. I believe that's the type of situation that a spring worker is intended to handle.

Look at what you're doing in the constructor. For each GUI component that listens for events, you're creating a completely separate SimulationGUI object on which it listens, which is extremely wasteful. Furthermore, in the code
ActionListener angleList = new SimulationGUI();
you call the constructor again. But then within that constructor-call this line is executed again and the constructor is called again. In this process of infinite recursion the run-time stack grows and grows until it overflows.

All the GUI components should probably listen for events from the same single SimulationGUI object. That is, in the original code that you posted, you should change

ActionListener angleList = new SimulationGUI();
to
ActionListener angleList = this;
and similar for the other calls to addActionListener().

However, it is evident that you don't really get how the event handling of Swing works. First make sure that you really grasp what's going on in this code.

The person in this post http://groups.google.com/group/ibm.software.websphere.studio/browse_thread/thread/97271ec505c75144 got the same error as you did. He also noted that it occurs at the "Start"-phase of the process.

Consider if it is even necessary for you to go all the way to the Start-phase. I normally choose to run only the Develop Client and Assemble Client phases. That generates all the client-side code that is necessary to work with the web service.

I'm not sure if this will solve the problem, but you should call the close() method on a ResultSet object once you're done using it (and before you reassign it).
You may also have to close() the Statement/PreparedStatement.
You should definately close() the Connection object when you're done with it. It's always a good idea to call close() on the connection in the finally-block of a try-catch construct, so that the database Connection is closed even if an exception occurs in the code that uses the Connection.

What you need to grasp is that the "this" keyword in a Java program always refers to the object on which the method you're currently in was called (the callee of the method).

So to illustrate with the help of an example, suppose that you have a Shape class with a getRenderer() method, where getRenderer() returns a Renderer object that can draw the shape onto the screen.
Suppose further that the Renderer class has a constructor that takes as a parameter the Shape object that it should draw. Then the getRenderer() method of the Shape class might look like this:

public Renderer getRenderer() { return new Renderer(this); }

So this method returns a new Renderer object that draws the Shape object on which the getRenderer() method was called (this).

Hi, I am trying to do a SOAP web service call from a web page using the jqSOAPClient.js library from Javascript. I can do a simple web service call like this:

SOAPClient.Proxy = url; var body = new SOAPObject("sayHi"); body.ns = ns; body.appendChild(new SOAPObject("name").val("John")); var sr = new SOAPRequest(ns+"sayHi",body); SOAPClient.SendRequest(sr,processResponse);

This calls the sayHi() web method with the value "John" for the single parameter with name "name".

I am wondering how I can use this library to call a web method that takes as parameter an object other than a string. As an example, suppose that in the web service there a class AnObject defined as follows:

class AnObject { int id; string name; }

And a web method that is defined as:

doStuff(AnObject miscObject);

How do I build such an object at the client and pass it as a parameter to this web method?

Hi, I'm trying to develop an HTML-page with Javascript/JQuery code that interacts with a SOAP web service running on Glassfish.

I'm trying to do the web service call as a POST HTTP-method request using AJAX. The problem is that the web service is running on a different server than where the page is served from, which, because of the cross-domain policy, results in my browser (Firefox) first doing an OPTIONS HTTP request to determine if the web service will allow the POST request. The web service running on Glassfish won't respond to this OPTIONS request.

I've seen that this can be configured in other application servers, by setting Access-Control-Allow-Origin to a pattern that recognizes all origins that should be accepted (for instance '*' to accept any request).
How do I make Glassfish respond to the OPTIONS request?

Maybe it would be better to make GUI extend JPanel from the start. That way the client can decide if he would like to wrap it directly into a JFrame or put it into a JFrame along with other JPanel's, or put it into a JDialog.

I think there are pro's and cons. In the second version of the GUI class, as I've mentioned before, one can include methods for the client that manipulate the JFrame. The problem here is that the client will have to call methods on the JFrame object to do some things and methods on the GUI object to do some other things.

Of course, when extending JFrame, one needs to be careful of accidentally overriding methods of JFrame. I cannot recall, however, that something like that has ever happened to me. If you use good descriptive names for your methods, this is unlikely to happen.

As for the issue of needing to change the JFrame into a JDialog or JPanel - would this change necessarily be more work when GUI extends JFrame? When I think about it, I'm not quite sure. I would need to try actually doing it for both versions of the GUI class.

I'm still not convinced that having JFrame as a field is the better way to go. I suggest that you consider these comments and decide for yourself.

Hello Neeraj,

Since conn still references the Connection object within your main() method, the Connection object will not be freed up by the garbage collector. However, as soon as the main() method returns, conn goes out of scope, and the Connection object will be eligible for garbage collection. To me this is ok, however, if for some reason you would like the Connection to be eligible for garbage collection while conn is still within scope (i.e. while the main() method is still executing), just set conn equal to null in main().

Hello Ujwwala,

the problem is not your JDK. In Java, an array does indeed not have an add() method.
I suspect that the problem is in the OrderBean class. Perhaps orderItems should have been a List<OrderItem> and not an OrderItem[].
If the length of the array returned by getOrderItems() is larger than 0 (you can use the length-data member of the array to inspect its length, as in System.out.println(order.getOrderItems().length)), then you could simply assign the OrderItem object to the first element of the array, as in order.getOrderItems()[0] = item; .
If this doesn't work (perhaps because the length of the array is 0), your OrderBean class won't cut it. In this case the problem evidently lies in the client stub generator that you're using. Try using a different one.