jump to navigation

Spring Aggregating MessageSource March 26, 2010

Posted by Phill in General J2EE, Spring.
Tags: , , ,
comments closed

If you’ve ever worked on a modular project which needs to be internationalised, chances are you’ll have run into the requirement of combining messages from various different modules.

By that I mean, each module has its own message source, but you want them to be combined into one MessageSource. This could be required for various different reasons which I won’t go into here, but suffice it to say that this is possible with Spring.

I created an AggregatingMessageSource which would scan the ApplicationContext for instances of MessageSource. When a message was requested, it would search each one sequentially for the relevant message.

Anyway, if you need such a class, I have uploaded it to get you started. Obviously, customise it to your own needs: AggregatingMessageSource.java.

Advertisements

Fun with Spring, GWT and Annotations March 4, 2010

Posted by Phill in Frameworks, Spring.
Tags: , , , ,
comments closed

Recently I’ve been porting across some of our monolithic IceFaces application to a more modular GWT application. (There’s nothing wrong with IceFaces as such, but for several reasons I don’t think it’s the right fit for us any more).

It’s been going pretty well so far, although I’ve only been working on it for a few days. I’ve got the GWT-Widget server library up and running as well, which integrates nicely with Spring for RPC. (It basically means you don’t have to define a new servlet in web.xml for each RPC server you want, you can just define them as Spring beans).

However, it does mean that you have to create a mapping for each Spring bean that you want to publish and define it in the application context XML, which isn’t really ideal for modular applications: I’d quite like them to be detected automatically with annotations, that way if you have another module on the classpath it will automatically be picked up.

So, I created another annotation (@RPCService) and annotated my RPC endpoints with it. The annotation, as its value, had the URL of that endpoint (i.e. “/user” for the users RPC service)

Then, my initial thought was to use Spring to scan the classpath and load each one up. I’ll cut a long story short here and say that was all unecessary: if your RPC classes are defined in the application context (via XML or annotations, it doesn’t matter), all you need to do is get an instance of the Application Context and call getBeansWithAnnotation.

This makes things really simple: I have a bean set up which has an initialise method that uses that method to get all classes annotated with my RPCService annotation, finds out their URLs, and then configures the GWTHandler servlet to map those beans.

Dead easy! And very useful to do, if you’re using the GWT-Widgets library.

Edit: After reading the documentation it seems that what I’ve done is essentially re-implement what’s already available in the library. Still, hopefully it will come in useful if you need to do something similar for another usage…

Using Spring Security in a Swing Desktop application June 12, 2009

Posted by Phill in Frameworks, Spring.
Tags: , ,
comments closed

It seems like there’s very little support (in terms of documentation) for using Spring Security in a Swing (or general Desktop) application. All the documentation I could find assumed that Spring Security was going to be used in a web application.

However, it’s very possible to use the security framework in a Swing application – a little custom code is required, but then, that is only to be expected!

Essentially what we did is create a LoginUtils class, which had an authenticate(username, password) method. This referenced the Spring AuthenticationProvider (we’re using a custom LDAP AuthenticationProvider, but you can use whichever suits your needs).

This is what the code looks like:

public Authentication authenticate( String username, String password )
 {
 UsernamePasswordAuthenticationToken token = new UsernamePasswordAuthenticationToken( username, password );

 Authentication auth = _authProvider.authenticate( token );
 if (null != auth)
 {
 SecurityContextHolder.getContext().setAuthentication( auth );

 _eventPublisher.publishEvent( new InteractiveAuthenticationSuccessEvent( auth, this.getClass() ) );

 return auth;
 }
 throw new BadCredentialsException( "null authentication" );
 }

You can then call this method from wherever you want in your application (for example, from a Login action) and your user will be logged in.

Both _authProvider and _eventPublisher are dependency-injected properties.

Notice the _eventPublisher.publish(…) call.  You do not need this if you have nothing listening out for those events. However, if you do not publish them then they will not be published, so it’s worthwhile doing – particularly if you’re writing a security framework!

The other important thing is – and this is something which caught me out first time round – is that the SecurityContextHolder by default uses a ThreadLocal pattern. For a Swing application you will want the Global pattern. Put this somewhere in your code (i.e. a static initializer, or your main method):

SecurityContextHolder.setStrategyName( SecurityContextHolder.MODE_GLOBAL );

This means that the Authentication object will be available to your entire application – if you don’t do this, objects on a different thread to the one you logged in on will not be able to ‘see’ your credentials. For a while I couldn’t figure out why my Authentication object was coming back as null, until I realised!

Note: this post is application to Spring Security 2.0.4. At the time of writing, version 3 is only at milestone 1 so I have not tried it yet!

Spring Method Security May 13, 2009

Posted by Phill in Spring.
comments closed

Another quick post. I have been using Spring Security to secure methods in a desktop application. It was a bit tricky to configure because Spring Security is based on web applications, but actually it’s not much of a problem.

However, I kept getting AccessDeniedExceptions for authenticated users. It seems that all voters had abstained, which I found puzzling because the RoleVoter should have allowed the method call.

Anyway, it turns out that the RoleVoter has a built-in role prefix (“ROLE_”) which was causing problems, as ours have a different prefix.

In order to change this you will need to code the AccessDecisionManager yourself:


<bean id="accessDecisionManager" class="org.springframework.security.vote.AffirmativeBased">
<property name="decisionVoters">
	<list>
 <bean class="org.springframework.security.vote.RoleVoter">
<property name="rolePrefix" value="MY_PREFIX_" />
 </bean>
 </list>
 </property>
 </bean>

<security:global-method-security
 secured-annotations="enabled" access-decision-manager-ref="accessDecisionManager" />

Spring and PropertyPlaceholderConfigurers October 22, 2008

Posted by Phill in Spring.
Tags: , , , ,
comments closed

The project I’m currently working on is a fairly modular web app. We have an application context file for each module. This has worked pretty well so far. However, I ran into an issue today when I wanted to add a new module: I kept getting the issue ‘Could not resolve placeholder ‘(property name)’.

I thought this was a bit strange because I thought I’d set up the property configurer correctly, and the properties file was definitely in the right place.

It turns out (via a bit of Googling – see this thread) that you don’t need multiple PropertyPlaceholderConfigurers. If one is defined, it will load properties for the whole of your application context files (as long as they’re within the same overall context).

If you have multiple PropertyPlaceholderConfigurers defined, what will happen is that if one of them can’t find a specific property, it will treat it as a fatal exception. This is of course going to happen if your different configurers point to different properties files!

There are three solutions:

  • Set the “ignoreUnresolvablePlaceholders” attribute on all property placeholder;
  • Set the “placeholderPrefix” or “placeholderSuffix” properties individually for each one so they don’t all match ${…}
  • Use one property placeholder configurer and just point it to all your properties files.

I’ve gone with the last option at the moment – it’s the best solution for what we need at the moment.

CallableStatements, JdbcTemplate and jTDS October 15, 2008

Posted by Phill in Data Access Layer, General J2EE, Spring.
Tags: , , , ,
comments closed

I’ve been using the jTDS driver to connect to our SQL Server database. We have a stored procedure which I needed to call. In this project I would normally use iBATIS, but this particular call required the features of JdbcTemplate and CallableStatements (there are good reasons which I won’t go into now!)

The stored procedure has one out parameter, and also returns a ResultSet. I thought this would be pretty simple to set up – but all my attempts kept coming up with the error message “Could not set up parameter for remote server” (which the jTDS driver was sending back).

At the time I was using named parameters. What I’ve done is to switch to using positioned parameters (i.e. setString(1, “Parameter”); registerOutParameter(2, Types.VARCHAR)) and that has seemed to fix the problem.

A bit bizarre, but as I couldn’t find any info about this error anywhere on the internet I thought it was worth posting about in case it saves someone else a headache 🙂

Spring Transactions across multiple datasources September 16, 2008

Posted by Phill in Other Stuff, Spring.
Tags: , , , ,
comments closed

Update: Since writing this post I have discovered problems with the Enhydra connection pool, and as such I do not recommend using it. I recommend finding another way to accomplish what you want to do.

We have an application here which connects to two different data sources. I was having problems getting the application to be transactional using Springs @Transactional annotation. The problem is, the Transactional annotation does not let you specify a transaction manager – and one transaction manager can only manage one DataSource. Or so I thought.

It turns out that it is possible, using JTA – and JOTM.

The configuration you need is pretty minimal. In your application context XML file, you need to put the following:

<bean id="jotm"
class="org.springframework.transaction.jta.JotmFactoryBean" />

<bean id="innerDataSource"
class="org.enhydra.jdbc.standard.StandardXADataSource"
destroy-method="shutdown">
<property name="transactionManager" ref="jotm" />
<property name="driverName" value="${dataSource.driver}" />
<property name="url" value="${dataSource.url}" />
<property name="user" value="${dataSource.username}" />
<property name="password" value="${dataSource.password}" />
</bean>

<bean id="dataSource"
class="org.enhydra.jdbc.pool.StandardXAPoolDataSource"
destroy-method="shutdown">
<property name="dataSource" ref="innerDataSource" />
<property name="user" value="${dataSource.username}" />
<property name="password" value="${dataSource.password}" />
</bean>

<bean id="transactionManager"
class="org.springframework.transaction.jta.JtaTransactionManager">
<property name="userTransaction" ref="jotm" />
</bean>

(You also need to set up your libraries to inculde JOTM and the XA Data Sources – which can be got here)

This is for the first DataSource. Your second DataSource should be set up as per the above, except that you don’t need to repeat the jotm or transactionManager beans.

Provided that you then set up your transactions as annotation-driven – and actually use a few annotations – you should find your methods are transactional across multiple dataSources!

You may also find it helps to read a couple of articles on the subject, two which I found helpful are here and here.

Feeling like an idiot September 3, 2008

Posted by Phill in Spring, Testing.
Tags: , , ,
comments closed

Do you ever spend a whole morning tracking down a problem, only to find out that it was your own stupid fault in the first place? I do. I did this morning.

I wrote a unit test a while back which tries to insert some data into a database (in a transaction), and then the transaction should be rolled back. (The transactions are handled automagically by AbstractTransactionalSpringContextTests). It all seemed to be working fine – the data was being inserted OK and then rolled back.

However, this morning I noticed that the data was not being rolled back. “That’s strange”, I thought, “I’m sure it was working a few weeks ago…”. I tried turning on debug logging. Spring made absolutely no mention of transactions for those particular tests.

I tried a number of things, including messing around with my Spring configuration – nothing!

Long story short, it turns out that the problem was incredibly simple:

In my unit test class, I’d overridden onSetUp, but hadn’t called super.onSetUp(). The AbstractTransactionalSpringContextTests class makes use on onSetUp to start the transaction. Doh! So, a quick call to super.onSetUp() at the start of my onSetUp method and everything seems to be working again…

This just demonstrates, though – always be sure what you’re overriding before you override it!

Creating a Web Service with Spring-WS July 16, 2008

Posted by Phill in Other Stuff, Spring.
Tags: , , , , ,
comments closed

Recently, I’ve had to use Spring-WS to expose a couple of web services. I’d previously exposed web services using CXF (or XFire as it was then), but that worked a bit differently: you defined the beans you wanted to expose as Web Services, and XFire would generate all the WSDL for you.

I wanted to try out contract-first web service development, hence me using Spring-WS. (There are a variety of good reasons to use contract-first development, rather than generating your interface from Java.)

Anyway, to cut a long story short, here are a few brief notes about my experiences, hopefully this will help out anyone else who wants to start developing in Spring-WS 🙂

  • Before you even start reading through the Spring-WS documentation, read up about XSD. Seriously, if you don’t know XSD, you will need to. Even a basic understanding will help greatly. This document by the W3C is an excellent place to start.
  • The Spring-WS Tutorial isn’t very helpful, in that it only defines a web service which has a request (i.e., no response is required). If you want the Web Service to have a response, you need to also include a “{Name}Response” type in your XSD. In other words, if their example should be modified to include a response to a HolidayRequest, you should include a HolidayResponse element.
  • I used JAXB as an O/X mapper. It has an Ant task which will generate your Java classes from an XSD, which I found very useful. It’s also dead easy to use with Spring-WS.
  • If you’re not using Spring MVC, you’ll need to set up a MessageDispatcherServlet. I bound mine to the path /services/* – however, there are a couple of ‘gotchas’ here:
  1. You’ll probably want to set the transformWsdlLocations parameter to ‘true’, so you can specify the web service path as a relative URL.
  2. The servlet, being a Spring MVC style servlet, looks for an application context .xml file in /WEB-INF/{servlet-name}-servlet.xml. As far as I know, you must include this. It’s not really a problem because it helps separate out concerns (i.e. defining all your Web Service beans in one place) – and also, you can reference all your beans defined elsewhere. However, it’s just something to be aware of.
  3. Remember I said I bound my servlet to /services/*? When you define your endpoints, you must include that prefix in the endpoint. So, if the URL to your service is /ContextPath/services/MyService/, your “locationUri” property of the endpoint will be /services/MyService/. Not /MyService/. It took me a while to figure that out!
  • Finally, you’ll need several beans to define a Web Service. Although you can get this from the Spring-WS documentation, this is a list in the one place:
    • A Wsdl Definition (such as DefaultWsdl11Definition) – which will expose your WSDL.
    • An XSD Schema definition (such as SimpleXsdSchema) – if you’re automatically generating WSDL from your XSD.
    • An endpoint mapping (such as PayloadRootQNameEndpointMapping), which will map from the incoming requests onto your endpoints.
    • Any endpoints you want to have setup, i.e. one per web service you want to expose
    • If you’re using a Marshaller (such as JAXB), you will also need the marshaller / unmarshaller configured, for example Jaxb2Marshaller.

*phew* I think that’s just about everything.

I realise all that is probably not very clear, it’s just a few notes from the little issues I’ve run into over the past few days trying to get the web service to work. In time I might get around to organising it into a more coherent tutorial 🙂

Spring’s Log4JWebConfigurer October 12, 2007

Posted by Phill in Spring.
Tags: , ,
comments closed

In the JavaDoc for Spring’s Log4JWebConfigurer, there’s a bold “warning”, letting you know that it “Assumes an expanded WAR file”. If you want to use an unexpanded WAR file, the advice is to use a VM-wide Log4J setup.

Unfortunately, in our case we needed to have our application use a particular Log4J properties file, and we needed it to be outside the WAR file (i.e. in a shared properties folder on the server). The shared properties folder is on the classpath – so it is available to the application – but unfortunately our EAR file is unexpanded.

In the end, we managed to get it to work: in web.xml, you can add a “classpath:” attribue to the log4jConfigLocation attribute. You also need to set the log4jExposeWebAppRoot property, otherwise (on WebLogic at least) the deployment will fail with an error about setting the WebApp home for an unexpanded EAR file.