We Keep Coding

Java swing component instantiation

Recently while developing a swing application somebody told me to use (ComponentClassName) Beans.instantiate(MyClass.class.getClassLoader(), ComponentClassName.class.getName()) to create component object instead of using "new". I would like to know the right approach.

You can use Beans.instantiate() if the type you want to instantiate is chosen dynamically. Generally the new keyword works just fine, and is what I always use in Swing applications.

I think the right approach will be to use the new keyword, after all, that's it's role. The way you are using Beans seems a bit forced since you know what type of class you wish to instantiate. Second, since this is a swing application, most probably you are using default swing classes (maybe extending some of them). Another problem with this approach is that you must have a constructor without args in your class.
Class.forName() can be used for the same thing as the code above, but if you don't want to dynamically create a class at runtime, stick with the new keyword.

How to know which methods are invoked in java?

Is there any way to know which methods are getting invoked in Java during run time. Actually I am trying to detect those methods which are getting invoked and according to those methods that are invoked use Java Reflection APIS to invoke another method from another classes. In this way I want to divert the execution to my methods first and then call those running methods.
e.g
//Method Invoked_Method = "get the invoked method here "
if(Invoked_Method.equals("somemethodName"){
//invoke Another method ..
}
Although its a security breach, but I am working in team for security products. So have to experiment this.

You may want to consider AOP: http://aopalliance.sourceforge.net/
This allows you to intercept method calls that match a particular expression and enhance or change the default behaviour of the method.
If you're already using them, the Spring and Guice frameworks provide ways to leverage AOP relatively easily.

I suppose what you are saying is you need to trace the callstack at runtime. I found a thread regarding this.
Check this out

Why does StockWatcher.java use class variables instead of local variables in onModuleLoad?

So, yeah. That. I'm going through the tutorial one step at a time, so if the answer comes up later, forgive me. It's step 1 in this section.
I understand the ease of using this to have access in other methods in the EntryPoint class, but coming from the Spring MVC world, this sort of thing might be thought of as a controller and be a singleton (bean). Is it wrong to think this way in the GWT world?

With GWT you are coding as if it was a desktop AWT program. So, you do not have CDI or anything similar.
So, if you put all your information in a bean, you still would have to either:
keep a bean attribute in the class
pass it as a parameter in the method call
to get a reference to it (instead of retrieving it from CDI when needed)
While you can still use a bean when needed, these attributes are closely linked to the main class (in fact they are other graphical components to show). In general, I would only use bean when you have a bunch of attributes that are tightly coupled between them but are not tightly coupled to any other class.

Using Springs IoC in this case?

I am curious on the way Spring is able to bind together an application (just in simple terms of course). In a standalone Java application you bootstrap the application with a lookup then Spring instantiates and binds the objects together (DI).
If you for example have a for loop where you don't know the number of iterations (user input) would you use the dependency lookup method inside the loop body? And would you implement the BeanFactoryAware interface in this case? Or do you make the object by using new keyword?
Just an thing that came to my mind while reading.

"Lets pretend that you need a new instance each time"
If you have a component A that has a for loop where you need a new instance of a "bean" B on each iteration, why not just inject a B factory into A and call that within a for loop.
It all really comes down to what makes sense:
If you need to create something simple (e.g. a new String) on each iteration, then there is nothing wrong with using a new keyword.
If it is something more complex, where it is best to encapsulate "creation details", it would not do you any good to depend on any particular framework (e.g. BeanFactoryAware). Just use a builder/factory, which can either be another bean that would be injected, or can be called statically.
Less magic more clarity

If I understood your question correctly the answer could be: Spring beans are singletons by default.
So in most cases you would never need to lookup one inside the for loop - you'll use the instance looked up just before your loop.
Also you're probably trying to think about Spring beans as JavaBeans that you create to populate with data. You could read this link to see the difference: http://www.shaunabram.com/beans-vs-pojos/
Spring beans are more like JavaEE Enterprise Beans, you don't create them - you just use them.

Spring - multiple command class with AbstractWizardFormController

Can i have a AbstractWizardFormController controller with different command class for each page ?

Sounds like a hack to me, but sure --the formBackingObject() method is called for each page, so you can override that method and add code to determine which command object to return (based on which page view is being requested).
On the other hand, that's going to add complications when you handle each pages submission -- will you have to figure out which type of object you're getting and cast? I'd rethink -- maybe this isn't really a wizard-type situation and you should have separate controllers? Or perhaps you should look at Web Flow? My experience is that the Wizard controller is useful if you're using it as envisioned, but when you start trying to squeeze it into a scenario it's not meant for, it becomes more complicated than helpful.