We Keep Coding

Spring scope in Dropwizard App

If I have the following configuration in a Spring project, and different parts of the app get different instances of ServiceA, will I still have a concurrency problem because all instances of ServiceA will be sharing a single instance of dataSource? Do I need to simply know if BasicDataSource is threadsafe? If it is, then I am ok, if it is not, then I will have threading issues?
<bean id="serviceA" name="serviceA" class="com.company.ServiceA" scope="prototype">
<constructor-arg name="dataSource" ref="dataSource"/>
</bean>
<bean id="dataSource" destroy-method="close" name="dataSource"
class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName" value="com.mysql.jdbc.Driver" />
<property name="url" value="${dbConnectionUrl}"/>
<property name="username" value="${user}"/>
<property name="password" value="${password}"/>
<property name="initialSize" value="${connectionSize}" />
<property name="maxActive" value="${maxConnectionSize}" />
<property name="validationQuery" value="SELECT 1" />
<property name="testOnBorrow" value="true" />
</bean>

You won't have any issues unless you are using some very strange datasource. All your beans in Spring should be stateless except for session beans. Out of the box beans from Spring will be like this. If you do this in your code as well you won't have any problems. All your singleton beans could have been essentially static but this would make them less or not testable, as you would have a tough time mocking them. The other issue besides concurrency with having state in your beans which are not session beans is if you try to scale up your application and deploy multiple instances of the same webapp, it will most likely fall over. Typically you don't have your beans use the datasource, (although you may have reasons too). You usually work with a session factory and just get current session from your session factory which has a reference to the datasource. Or using an entity manager which is similar.
Edit To addresss the comments. A stateless bean (no variables) is inherently thread safe. So unless your bean has variables as many threads as you want can access it at the same time. Even if a bean is accessing a database this is the case, it will still be thread safe because the database handles all the concurrency data problems for you. I'm not too sure what you mean by context switching? Two requests may run through the same bean but they will have different sessions from the session factory, there will be no shared state so there will be no concurrency issues.
With the session factory you'll just have to read up on that. Typically you would use something like hibernate for mapping classes to a database, and your session is like your link to the database. This handles all sorts of aspects for working with a database for you. The vast majority of Spring apps are like this. If you google Spring MVC hibernate you will see what I mean.
I believe there is a big debate about whether or not a REST service still can have sessions but I can't really comment on that, although I know you can just pass a session id in the URL, but any way if you are really not having any sessions and no variables you won't have any concurrency issues unless you are referencing a very very strange library, simply because no problems can exist if there is no shared state.

EclipseLink and Spring 3 Web MVC: how should I integrate both technologies?

I'm currently learning EclipseLink and Spring 3.0 MVC:
I wrote a simple standalone application using EclipseLink : it uses a META-INF/persistence.xml file and it reads and writes data from a mysql database.
I also wrote a simple 'HelloWorld' application using Spring3 MVC under apache tomcat. It is based on the following tutorial: http://www.mkyong.com/spring-mvc/spring-3-rest-hello-world-example
now, how should I link both technologies ? As far as I understand from http://static.springsource.org/spring/docs/3.0.0.M3/spring-framework-reference/html/ch14s06.html I need to create a LocalContainerEntityManagerFactoryBean:
<bean id="myEmf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="someDataSource"/>
<property name="loadTimeWeaver">
<bean class="org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver"/>
</property>
</bean>
but what is "someDataSource" ? should I use another library like http://commons.apache.org/dbcp/ ? then what should I do with eclipselink ?
And once the JPA will be configured, how should I access it from my spring Controller ?
Thank you

someDataSource would just be another bean, for example:
<bean id="someDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="${jdbc.driverClassName}" />
<property name="url" value="${jdbc.url}" />
<property name="username" value="${jdbc.username}" />
<property name="password" value="${jdbc.password}" />
</bean>
Here I'm also using a property replacement for the properties, this is designated by the following bean:
<context:property-placeholder location="classpath:properties/runtime.properties" />
Since context is under a different xml namespace add:
xmlns:context="http://www.springframework.org/schema/context"
to your XML namespaces, and
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd
to your schemaLocation string within the bean xml document.
classpath:properties/runtime.properties
This property file would be found at the following location in a standard Maven setup:
src/main/resources/properties/runtime.properties
Within this runtime.properties file you'd need to define values for each of the properties that have placeholders (i.e. jdbc.driverClassName, jdbc.url, etc.). An example of this would be:
jdbc.driverClassName=com.mysql.jdbc.Driver
If you're using MySQL for your database.
Generally speaking, you might want a service layer between your controller and repository (DAO). The reason being is controller should concentrate only on handling requests, and responding. Any business logic should be done in a different layer, through business objects, etc. Service layer acts as an intermediary between web layer, and repository layer. This not only separates concerns, but also makes things infinitely more unit testable, a huge part of any Spring application (at least it should be!).
As to how to wire things up, try inserting this bean into your Context as well:
<context:component-scan base-package="xx.yy..." />
Where xx and yy are your package names, this will tell Spring to scan your packages for "components" or #Controller objects, #Service, and #Repository (there are a few other ones but those are the main things to know about). With this information provided to Spring, you can #Autowire beans (dependency inject) into other beans.
For example:
#Service
public class SomeServiceImpl implements SomeService
{
private SomeRepository someRepository;
#Autowired
public void setSomeRepository(SomeRepository someRepository)
{
this.someRepository = someRepository;
}
...
}
This will inject the repository into the service allowing you to access that repositories methods.
Another design tip, always program for interfaces in Spring. This is especially true when it comes to repositories due to the fact that early in development, you might want to implement a Hibernate repository, but down the line DBAs might scoff at that, and require a JDBC repository using straight SQL. This way, you just need to implement the Repository using a JDBC approach rather than Hibernate, inject the JDBC repository instead of Hibernate, and you're done.
Hope this gets you started!

Can Spring's LocalContainerEntityManagerFactoryBean be used in a J2SE environment?

I'm using Spring in Glassfish and I have the need to configure it so it also works outside of the container, mainly for development purposes.
What I'm uncertain of, and couldn't find the answer to, was whether I can use the LocalContainerEntityManagerFactoryBean class without a container.
From its name, LocalContainer, it seems I can but in the docs it says:
FactoryBean that creates a JPA
EntityManagerFactory according to
JPA's standard container bootstrap
contract
so I'm uncertain about this issue.
Thanks,
Ittai

I just wanted to note that Spring supports running the JPA stuff outside of a container, and doesn't require anything in the way of a transaction manager. The question to ask is whether you are using Spring's declarative transaction management (e.g., "#Transactional").
If you are, then you need to provide an implementation of "PlatformTransactionManager." Here still, you do NOT need to use full on JTA support (as provided by Atomikos in the above example. YOu can simply use a JpaTransactionManager instance (which expects a reference to the entity manager factory) provided you are not doing anything with "XA" etc. If you are doing XA, then Atomikos, or Bitronix or any of a number of other options are just fine. You might look at this example http://blog.springsource.com/2011/08/15/configuring-spring-and-jta-without-full-java-ee/ which demonstrates how to use JTA (with JPA and JMS, for example).
So, reiterating, if you're just doing simple JPA (connecting to one database) then you don't need JTA, and you definitely don't need GlassFish. If you need XA, then you can still use a third party JTA provider as the responder above suggested, and you still don't need Glassfish.
Finally, if you truly wish to maintain both GlassFish + JTA, and a separate JPA that works only locally for rapid development on a faster container, you might consider the imminent Spring 3.1, which features "profiles" to allow you to conditionally define beans per environment (e.g., "production," or "dev," or "cloud," or whatever you'd like.)

Yes, it's possible, but you need to provide a transaction manager (like Atomikos). The rest of the configuration is the same.
This is an example:
<bean id="userTransactionService" class="com.atomikos.icatch.config.UserTransactionServiceImp"
init-method="init" destroy-method="shutdownForce">
</bean>
<bean id="AtomikosTransactionManager" class="com.atomikos.icatch.jta.UserTransactionManager"
init-method="init" destroy-method="close" depends-on="userTransactionService">
<property name="forceShutdown" value="true" />
</bean>
<bean id="AtomikosUserTransaction" class="com.atomikos.icatch.jta.UserTransactionImp"
depends-on="userTransactionService">
<property name="transactionTimeout" value="300" />
</bean>
<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"
depends-on="userTransactionService">
<property name="transactionManager" ref="AtomikosTransactionManager" />
<property name="userTransaction" ref="AtomikosUserTransaction" />
</bean>
<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
....
</bean>

Oracle connections in Spring

I am using Oracle 9 JDBC Thin Driver - the connection string I have used for standard JDBC was:
jdbcConn.connect("jdbc:oracle:thin:myDevDb/myDevDb#fooServer:1521:MYSIDNAME");
...just trying to get my head around using this kind of connection in Spring 2.5.
How do you wire up Spring to an Oracle connection - think it has something to do with an XML conifg file but not sure, there seems to be a couple of ways to do it.
Any help much appreciated...
LATEST EDIT
Thanks to those who have responded so far - but I need a bit of a "leg up" - on the part where you configure in the database connection string setup in your config, where do you put this info, and how?
I have an existing Java web application - and I am trying to get to grips with how I 'shoehorn' Spring into my existing app.

There are a few ways of doing this and it depends on what your environment is. If you're using Spring there's a fair chance you're deploying a Web application or you're otherwise in a J2EE environment. If this is the case (and arguably even if it isn't) you probably want to configure a DataSource.
This is a fairly minimal solution:
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="${jdbc.driverClassName}"/>
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
</bean>
The above is using the Apache (Jakarta Commons) database connection pooling but your appserver probably has an alternative you may want to use instead. Also, different database vendors have their own data source implementations too (eg OracleDataSource and OracleXADataSource for Oracle).
Note the use of properties like jdbc.username. This is a typical configuration because database configurations typically vary between environment. You can activate a property configurator with something like:
<bean id="jdbcConfiguration" class="org.springframework.beans.factory.config.PropertiesPlaceholderConfigurer">
<property name="location" value="classpath:jdbc.properties"/>
</bean>
Now you probably want transactions too I would imagine. The easiest way is to use a platform transaction manager but, like with most things Spring, there are multiple ways of doing it.
<bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>
After this you can use this bean directly or (arguably more common) you can use declarative transactions with AOP (annotations).
More on these subjects in the (superb) Spring reference documentation.

WebSphere and PropertyPlaceholderConfigurer

I'm a big user of properties (with PropertyPlaceholderConfigurer) for making my application as "dynamic" as possible. Almost all the constants are defined as such. Anyway, I'm currently defining a default.properties which comes shipped with the default WAR.
In other environments (Acceptance/Production) I need to overwrite of the configurations. I'm doing this as following:
<bean id="propertyManager"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>classpath:com/company/default.properties</value>
<value>file:${COMPANY_PROPERTIES_LOCATION}\kbo-select-settings.properties</value>
</list>
</property>
</bean>
With this means I can use a promotable build for each of the environments.
HOWEVER, I do dislike the fact that I can't change any of my properties from inside WebSphere. Instead I have to go to each of the servers (we have 8 clustered) and change the properties accordingly. It would be a lot more user friendly if I could change those from inside WebSphere and just perform a restart afterwards...
Anyone has an idea on how I could do such a promotable build? I already define JNDI configuration for datasources/java mail/etc.
Thanks!

We solved this problem by using an extension on the property file for each environment (local, dev, int, tst ...) and each file contained specific values for those environments. The only addition you then require is a VM argument on the server to set -Druntime.env=X.
Your lookups in your config file will then look like this
<bean id="propertyManager"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>classpath:com/company/default.properties.${runtime.env}</value>
<value>file:${COMPANY_PROPERTIES_LOCATION}\kbo-select-settings.properties</value>
</list>
</property>
</bean>
Of course this only works if you have fairly static environments, as it still doesn't lend itself to changing it at runtime, but it does makes promotion of the application dead simple. If you want to be able to change the values without redeploying your application, you will have to have them stored outside your application, which you already seem to be doing for the kbo-select-settings.properties

One potential issue is that you are hardcoding the location of your properties file. You could specify the location of the properties file as a JNDI resource and falling back on the defaults specified on the classpath:
<!-- try to lookup the configuration from a URL, if that doesn't work, fall back to the properties on the classpath -->
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location">
<bean class="org.springframework.core.io.UrlResource">
<constructor-arg>
<jee:jndi-lookup
jndi-name="url/config"
default-value="file:///tmp" /> <!-- dummy default value ensures that the URL lookup doesn't fall over if the JNDI resource isn't defined -->
</constructor-arg>
</bean>
</property>
<property name="properties">
<bean class="org.springframework.beans.factory.config.PropertiesFactoryBean">
<property name="locations">
<list>
<value>classpath:com/company/default.properties</value>
</list>
</property>
</bean>
</property>
<property name="ignoreResourceNotFound" value="true"/>
</bean>
That way you can specify different file names for different environments using the WAS console in Resources > URL > URLs by creating a resource with the JNDI-name "url/config" and pointing it to the correct file (file:///your/path/to/properties).
As an alternative solution, if you want to manage individual properties through the console, you instead of using the PropertyPlaceholderConfigurer you could use jee:jndi-lookup to get values from the web.xml env-entries (which you can manage using the WAS console). See this answer

If the configuration is in the EAR file then I know of no simple way to propogate changes without backdoor cheats or re-deploying the app.
I think that configuration, espcially that which changes when you promote the app should not be in the application.
One approach is described here by Keys Botzum,
Note that you can actually propogate files that are not part of any particular application out to nodes using standard WebSphere synchronisation.
Another option is to use a database for config. These days poppin XML into a DB such as DB2 is not very hard.

Adding a URL resource that points to your config files to your websphere servers and then looking that up in your application is a viable way to go. You can then configure the url to point to a central location where all the configuration files are managed - if you use svn and your svn has read-only access you could even directly read them from svn (via http).
Spring has some built in facilities for this, and it also means you can priorities various config files.
For more information take a look at how-to-differentiate-between-test-and-production-properties-in-an-application

The way that I have dealt with this is to use property values on the JVM's but then reference them to a WebSphere variable that is defined at the cluser or cell level. For example, say you want a value called value1 set in param1 in your spring configuration you would do the following:
<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer" />
And then something like as follows do reference the variable:
<bean id="id" class="com.blah.class">
<property name="value1" value="${param1}" />
</bean>
Then within your tests you can setup your tests as follows:
/**
* #see org.springframework.test.AbstractSingleSpringContextTests#prepareApplicationContext(org.springframework.context.support.GenericApplicationContext)
*/
#Override
protected void prepareApplicationContext(GenericApplicationContext context) {
System.setProperty("param1", "myvalue");
}
Then from within the websphere configuration, if you create a JVM variable and link it to the WebSphere variable you only need to change the WebSphere variable and it will automatically update all the JVM variables on each machine.
To do this, create a JVM variable called:
param1
with a value of ${webspherevar.param1}
And then create a WebSphere variable called:
webspherevar.param1
That contains whatever the value you need to put in it. This allows you to then not have to ship around the values for each environment and they can be instead loaded into the environment and just used.
I hope this helps.