How to ‘gracefully’ deal with bean initialization failures in Spring 3 application?

If you rethrow the exception the context will stop loading and your application will be effectively dead. Or if you really want the JVM to completely stop call System.exit(1)

http://stackoverflow.com/questions/5421022/how-to-gracefully-deal-with-bean-initialization-failures-in-spring-3-applicati

Continute to load webapp even if one spring bean initialization fails

Continue to load webapp even if one spring bean initialization fails

AFAIK, you can’t do this.

I do multiple DNS lookups on start up. I do not want the webapp to fail if one of them fails.

In that case, you need to modify your bean(s) to handle the case where the DNS lookup fails, leaving the bean instance in a state where it is essentially inactive but harmless, or where it can retry the DNS lookup later on.
In short, you have to cope with this yourself.

http://stackoverflow.com/questions/6920672/continute-to-load-webapp-even-if-one-spring-bean-initialization-fails

Accessing Spring beans from Legacy code

As I have blogged before, we have been trying to move to using the Spring framework in our web applications. We inherited a large body of working code which used a home-grown framework based on a combination of what Martin Fowler describes as the “JSP as Handler” web presentation pattern in his Enterprise Application Architecture book and Webwork action controllers. Our rationale for introducing Spring into this application is that maintenance and enhancement are very difficult and time-consuming with the existing architecture.
However, the conversion is not going to happen overnight, and neither can we mandate that all new development should stop as we move to the new architecture. It is also not possible to build and deploy the new functionality in separate web applications, because we don’t have the resources to handle the deployment issues that such an approach would require. So our new Spring enabled code co-exists with the legacy code in the same web application.
One by-product of this setup is that we often end up developing non-GUI components using Spring, which need to be hooked into existing legacy code so we can reuse the legacy request flow. There are three ways we could do this:

• Build the Spring bean manually in our legacy code using explict constructor and setter calls.
• Scrap the legacy request flow and rebuild it using Spring.
• Obtain a reference to the Spring bean that has been configured and built declaratively by the Spring container from the legacy code.

The first approach is feasible, but it is extra code that you don’t need to write. Also, the first approach may result in strange null pointer exceptions if you missed something. It is also less efficient to construct them each time than having it be built once by Spring. The second approach is good if your long term goal is to get rid of the existing architecture altogether, but it is even more risky than the first approach because new code will generally contain new bugs. Also, because writing code takes time, you will have to build this extra time into your estimates. In my opinion, the last approach takes the minimum effort, code and poses the least risk, and can be accomplished quite simply, as I show below.
Our approach is to build a Singleton bean which is ApplicationContextAware and instantiate it in the Spring container by defining it in the spring-servlet.xml file in our web application. Because it is ApplicationContextAware, Spring would populate it with a reference to the ApplicationContext. Since we just want references to Spring beans from it, we implement a static getBean() method which would delegate to the ApplicationContext.getBean() method. Here is the code for our Singleton. // SpringApplicationContext.java import org.springframework.beans.BeansException; import org.springframework.context.ApplicationContext; import org.springframework.context.ApplicationContextAware; /** * Wrapper to always return a reference to the Spring Application Context from * within non-Spring enabled beans. Unlike Spring MVC’s WebApplicationContextUtils * we do not need a reference to the Servlet context for this. All we need is * for this bean to be initialized during application startup. */ public class SpringApplicationContext implements ApplicationContextAware { private static ApplicationContext CONTEXT; /** * This method is called from within the ApplicationContext once it is * done starting up, it will stick a reference to itself into this bean. * @param context a reference to the ApplicationContext. */ public void setApplicationContext(ApplicationContext context) throws BeansException { CONTEXT = context; } /** * This is about the same as context.getBean(“beanName”), except it has its * own static handle to the Spring context, so calling this method statically * will give access to the beans by name in the Spring application context. * As in the context.getBean(“beanName”) call, the caller must cast to the * appropriate target class. If the bean does not exist, then a Runtime error * will be thrown. * @param beanName the name of the bean to get. * @return an Object reference to the named bean. */ public static Object getBean(String beanName) { return CONTEXT.getBean(beanName); } } The bean definition for this bean is just this one line: In order to now get a reference to a bean named “mySpringBean” that has been defined in the Spring context, we will issue from somewhere in our legacy (non Spring-enabled) code: MySpringBean mySpringBean = (MySpringBean) SpringApplicationContext.getBean(“mySpringBean”); // do something with MySpringBean The only caveat is that your DispatcherServlet must be loaded in web.xml before any component that needs to call the SpringApplicationContext.getBean(). This ensures that the ApplicationContext has finished loading and SpringApplicationContext has a populated reference to it. This is the second time I had a need for this kind of bridge. The last time was at my previous employer where we were embedding Jive Forums software within our Spring enabled web application. We used the standard approach there, using the Spring ContextListener to store the ApplicationContext in the ServletContext, and then calling WebApplicationContextUtils.getApplicationContext(ServletContext) to get at the Spring context. I believe the approach I have outlined is better, since it is less code and there does not have to be a web container for this functionality to be available.

http://sujitpal.blogspot.com/2007/03/accessing-spring-beans-from-legacy-code.html

SQL SERVER – Retrieve Current Date Time in SQL Server CURRENT_TIMESTAMP, GETDATE(), {fn NOW()}

There are three ways to retrieve the current datetime in SQL SERVER.
CURRENT_TIMESTAMP, GETDATE(), {fn NOW()}

CURRENT_TIMESTAMP
CURRENT_TIMESTAMP is a nondeterministic function. Views and expressions that reference this column cannot be indexed. CURRENT_TIMESTAMP can be used to print the current date and time every time that the report is produced.

GETDATE()
GETDATE is a nondeterministic function. Views and expressions that reference this column cannot be indexed. GETDATE can be used to print the current date and time every time that the report is produced.

{fn Now()}
The {fn Now()} is an ODBC canonical function which can be used in T-SQL since the OLE DB provider for SQL Server supports them. {fn Now()} can be used to print the current date and time every time that the report is produced.

If you run following script in Query Analyzer. I will give you same results. If you see execution plan there is no performance difference. It is same for all the three select statement.
SELECT CURRENT_TIMESTAMP
GO
SELECT {fn NOW()}
GO
SELECT GETDATE()
GO

Performance:
There is absolutely no difference in using any of them. As they are absolutely same.

My Preference:
I like GETDATE(). Why? Why bother when they are same!!! 

http://blog.sqlauthority.com/2007/06/21/sql-server-retrieve-current-date-time-in-sql-server-current_timestamp-getdate-fn-now/

Modify/view static variables while debugging in Eclipse

In the Debug Variables view their is a arrow button in the right of the view. the tooltip of this button is “Menu”. When you click this button a drop down menu is shown where you can select
“Java” -> “Show static variables”

http://stackoverflow.com/questions/801193/modify-view-static-variables-while-debugging-in-eclipse

How to print classpath

package com.test; import java.net.URL; import java.net.URLClassLoader; public class PrintClasspath { public static void main(String[] args) { // Get the System Classloader ClassLoader sysClassLoader = ClassLoader.getSystemClassLoader(); // Get the URLs URL[] urls = ((URLClassLoader) sysClassLoader).getURLs(); for (int i = 0; i < urls.length; i++) { System.out.println(urls[i].getFile()); } } } http://snipplr.com/view/16079/ Classpath Java class path: http://www.jguru.com/faq/view.jsp?EID=816577