Announcement

**Isomorphic** · 20 Dec 2010, 11:27

Yes, using dependency injection with custom DataSources and the documented approach is to set your serverConstructor to "spring:beanId".

Are you using the "Init" servlet or did you use another approach to initialize the framework? This log appears to be impossible if you were using the Init servlet. The very first thing the Init servlet does is grab the servletContext (which the log subsequently complains is not available).

If this log wasn't edited, it looks like a classloader issue in your IDE or servlet container.

**Sytematic** · 21 Dec 2010, 01:33

Thanks, I didn't use the spring:beanId notation.

However, I do get this error, but ONLY when the bean is declared. As soon as I remove the bean declaration, the error dissappears (but of course, then the bean doesn't work).

Oh, and yes, I do use the Init servlet, this is how it is written in my web.xml

Code:

<!-- ISC init: initializes ISC framework -->  
 <servlet> 
   <servlet-name>Init</servlet-name>  
   <servlet-class>com.isomorphic.base.Init</servlet-class>  
   <load-on-startup>1</load-on-startup> 
 </servlet>

, assuming that that is what you meant with 'using the Init servlet to initialize the system'.

So I don't think it is an IDE issue to be honest: adding the bean causes the error, removing it, makes it go away. Side note: I do not have other custom datasources, that are initialized as beans, only this one.

Might it be because of a bug in the nightly of the power edition of 13-12-2010?

PS: this is my twitter.ds.xml file, but NOT putting 'twitter' on the datasource loader url in my hostpage.html does not make the error go away.

Code:

<?xml version="1.0" encoding="UTF-8"?>
<DataSource 
    ID="twitter" 
    serverConstructor="spring:twitterDataSource"
    requiresAuthentication="true"> 
  <fields>
  	 <field name="twitterUsername" type="text" length="255" primaryKey="true" />
  	 <field name="twitterAccessToken" type="text" length="255" hidden="true"/>
  	 <field name="twitterAccessSecret" type="text" length="255" hidden="true"/>
  	 <field name="tweet" type="text" length="140" />
  </fields>  
</DataSource>

**Sytematic** · 21 Dec 2010, 05:56

Update: if I remove the 'extends BasicDataSource' part in my TwitterDataSource class, it does NOT throw the error (but of course, the datasource does not work then...) !

So it seems that it (BasicDataSource?) somehow does not 'release' the context, yielding the error 'servletContext not yet available', as the log indicates. Or not. Fact is, I cannot really debug this. Could you guys look into this?

An empty class like:

Code:

public class TwitterDataSource extends BasicDataSource {}

Already triggers the error. Removing the 'extends BasicDataSource', makes the error go away....

**Isomorphic** · 21 Dec 2010, 15:05

This is yet more evidence that you have a classloader issue.

There is no "releasing" or pooling of the servletContext. There's just one, captured when the Init servlet runs.

Code:

    public static synchronized void go(ServletContext context)
    {
        if(context != null) ISCFile.servletContext = context;
        ISCInit.go();
    }

.. and then here's the code that logs the subsequent error:

Code:

if(servletContext == null) {
            log.error("Configured for containerIO, but servletContext not available!");
}

There's really only one explanation, and that is that multiple instances of the server framework classes have been loaded. In one context, the Init servlet ran and captured the context. In the other, the Init servlet never ran.

This situation can arise from doing certain things like adding the same .jars to the classpath in multiple locations.

You should also try compiled mode to see if it's just some Eclipse issue with how the project is being started.

**Sytematic** · 21 Dec 2010, 23:44

Ah ok, that makes sense.

Thanks for the info, I will look in to this!

**jaredm** · 23 Jun 2011, 13:41

I know this post is old but I ran into the same problem and it wasn't due to multiple instances of the server framework..

I'm using Spring 3.0 (through Grails) and I found that Spring 3 does a Class.forName on my DataSource even if I specify lazyInit=true.

I applied the same work around as described here: http://forum.springsource.org/showth...ing-3.0-vs-2.5 - I created a Factory class that returns a new instance of my DataSource class. This fixed the Init problem for me.

**Isomorphic** · 23 Jun 2011, 13:58

Ah, so looking back at Sytematic's logs, you're saying those logs are happening because Spring is triggering the SmartGWT server's static initializer, and *not* because of the Init servlet?

If so, how is Spring managing to run before the Init servlet?

**jaredm** · 23 Jun 2011, 15:07

I'm not sure that Systematic's problem is the same as mine, but it is certainly an alternative explanation.

In my case I think Spring is managing to run before the Init servlet because Grails loads its own servlet which I can't influence:

Code:

	<servlet>
		<servlet-name>grails</servlet-name>
		<servlet-class>org.codehaus.groovy.grails.web.servlet.GrailsDispatcherServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>

**Isomorphic** · 23 Jun 2011, 15:32

Got it - yes, we agree that the explanation is basically that Grails/Spring is creating an instance of your class before any other code in the system runs and before out InitServlet, which we require to run first.

There's not a lot we can do about our server classes not working in this mode - they need that servletContext object or they can't use the container to read critical configuration files. So the solutions are:

1. find some way to convince grails to use load-on-startup 2 for it's servlet

2. use the factory pattern you mentioned so that the object that Spring creates at startup doesn't trigger static initializers

3. Spring fixes their apparent bug with lazy init

4. We provide a somewhat weird API allowing someone to initialize our server framework by passing in a servletContext, and you use this with any beans created with Spring by having Spring give you the servletContext via dependency injection (if it can even do this)

**mstickel** · 27 Apr 2012, 13:24

I had this same problem, where Spring was loading before SmartClient. This caused problems when initializing custom DataSources in spring. I'm using Spring 3 and SmartClient 8.2.

The workaround I came up with was to initialize SmartClient not using the Init servlet, but via a Listener instead. According to the spec, listeners are loaded in the order in which they appear in web.xml, so if my SmartClientInitListener comes before my Spring Listener, then these two items should load in the correct order. I'm using this in my code and things appear to be working so far.

Here is the Listener:

Code:

import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

import com.isomorphic.base.ISCInit;
import com.isomorphic.io.ISCFile;

public class SmartClientInitListener implements ServletContextListener {

	@Override
	public void contextInitialized(ServletContextEvent sce) {

		ServletContext servletContext = sce.getServletContext();
		if (servletContext != null) {
			ISCFile.servletContext = servletContext;
		}
		ISCInit.go();
	}

	@Override
	public void contextDestroyed(ServletContextEvent sce) {

	}

}

A snippet from my web.xml:

Code:

	<!--  Initialize SmartClient.  This has to come before Spring listeners. -->
	<listener>
		<listener-class>com.etouchpoint.common.web.smartclient.SmartClientInitListener</listener-class>
	</listener>

	<!-- Spring -->
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>/WEB-INF/spring.xml</param-value>
	</context-param>
	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>
	<listener>
		<listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
	</listener>

Like I said, this appears to work; however, there could be some functionality that I'm missing that I'm unaware of. I don't have the Init servlet source code, so I don't really know all the things that go on there. Perhaps Isomorphic can comment on whether this does everything necessary to actually initialize all parts of the system.

**Isomorphic** · 28 Apr 2012, 10:48

Thanks mstickel, that seems like it must be the right way to ensure Spring isn't calling us before we've initialized. We'll try out this approach and make it the official way that we do initialization if it works.

Announcement

Custom DataSource in combination with Spring's Depencendy Injection

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment