We Keep Coding

How does BeanProperty.create work?

I'm trying to get beans binding to work, because it seems like the closest thing to functional reactive programming I can get NetBeans GUI builder to give me. I'm trying to understand how the code in http://javakenai-dev.cognisync.net/pub/a/2008/03/20/synchronizing-properties-with-beans-binding.html works. In particular, I'm trying to figure out how the TintedPanel example works. It seems like BeanProperty.create either has to do voodoo magic, access private fields, or take the string it gets, capitalize the first letter, prepend "get" or "set" to that, and do runtime introspection to change the string into a method it can call. Can someone point me at complete source code for the TintedPanel example, or explain to me how BeanProperty.create works (preferably with a self-contained working example)?

It looks like JSR 295 the beans binding spec is withdrawn:
https://jcp.org/en/jsr/detail?id=295
There are a couple other SO posts with suggestions for other libraries, or pointers to the old beans binding source:
What will replace Beans Binding in Java 7?
What is the state of Java Beans Binding?
Good luck!

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.

Understanding the practical uses of InitialContext in java?

I have worked most on the legacy projects where i spot this line ctx.lookup("datasource"); many number of times. As per usage I have encountered with Initial context , it is used to get the java object binded with some name in webserver/appserver.
For example, we create datasource thru admin console of weblogic then we can use that object programmaticaly in java program with ctx.lookup("datasource"). If I recall correctly I saw this kind of code during EJB implementation also somewhere where some object that was binded with some name in server itself.
Java docs says When the initial context is constructed, its environment is initialized with properties defined in the environment parameter passed to the constructor. So probably the usage I mentioned earlier, Initial context gets constructed with environment parameters(which probably means objects which admin has created in server like datasource, connection pool if any). This is the just one use I could relate initial context.
Please let me know the if it is correct and right usage of initial context class?
Basically with initial context , we can bind/lookup java object with same name. In case of webserver/appserver probably the objects like datasource,connection pool get binded by the server at the time of start up and we can look up them straightaway?

This looks like a correct use of the context class. In newer EJB implementations you can also use the #EJB and #PersistenceContext annotations. For a deeper understanding read the wikipedia article about Dependency Injection.

Detect if running in servlet container or standalone

I have a simple problem: I want to configure an object differently based on whether the object is instantiated within a servlet container, or whether it is instantiated in a stand alone app.
The object is a database connection, and I care about setting query timeouts.
The first solution that I can come up with is:
if (insideServletContainer(this.getClass().getClassLoader()) {
/// do some servlet specific config
}
else {
/// do some standalone config
}
The question is, of course, can I write a reliable method of telling whether the class was loaded within a servlet container. It feels like a hack at best.
The second option is to assume that the default case is a stand alone instantiation, set defaults based on stand-alone configuration, and override them within the servlet context.
So, to sum up my question is: Do you know of a good/reliable mechanism if the class was loaded from within a servlet container? If not, I will have to take the second route.
Nick

This seems like a really bad idea. Instead, why don't you allow the class to take parameters, then let the container or app configure it appropriately?

Setting aside whether or not this is a good idea, I'd suggest looking up java:comp/env, which is only going to be available in an EE server:
try {
new InitialContext().lookup("java:comp/env");
/// do some servlet specific config
} catch (NamingException ex) {
/// do some standalone config
}

An alternate way to do this sort of thing is to have the configuration injected into this class by some sort of bootstrap loader.
In a standalone version, this would be done by the main() method (or something called from it).
In a webapp version, this would be done by a listener or filter invoked configured within the web.xml.
Dependency injection is useful here as it removes the need for your application to check these sorts of things; instead the application is given what it needs.

I would recommend Dependency Injection like #matt b.
As a second option, if it is only the simple case you described and you don't want to add or learn a DI framework to support this feature. You can accomplish the same thing as your current code by using a properties file to load different value based on the environment. You can simply use a different file for each environment and supply a VM arg to indicate which environment you are running.
db_prop.dev
db_prop.stalone
dp_prop.int
db_prop.prod
Then you can load by resource
"db_prop." + System.getProperty("runtime.env")