Skip to Content »
online discount medstore
advair diskus for sale
buy advair diskus without prescription
allegra for sale
buy allegra without prescription
aristocort for sale
buy aristocort without prescription
astelin for sale
buy astelin without prescription
atarax for sale
buy atarax without prescription
benadryl for sale
buy benadryl without prescription
buy clarinex without prescription
clarinex for sale
buy claritin without prescription
claritin for sale
buy flonase without prescription
flonase for sale
buy ventolin without prescription
ventolin for sale
amoxil for sale
buy amoxil without prescription
augmentin for sale
buy augmentin without prescription
bactrim for sale
buy bactrim without prescription
biaxin for sale
buy biaxin without prescription
buy cipro without prescription
cipro for sale
buy cleocin without prescription
cleocin for sale
buy dexone without prescription
dexone for sale
buy flagyl without prescription
flagyl for sale
buy levaquin without prescription
levaquin for sale
buy omnicef without prescription
omnicef for sale
amaryl for sale
buy amaryl without prescription
buy cozaar without prescription
cozaar for sale
buy diabecon without prescription
diabecon for sale
buy glucophage without prescription
glucophage for sale
buy glucotrol without prescription
glucotrol for sale
buy glucovance without prescription
glucovance for sale
buy micronase without prescription
micronase for sale
buy prandin without prescription
prandin for sale
buy precose without prescription
precose for sale
buy cialis professional without prescription
cialis professional for sale
buy cialis soft without prescription
cialis soft for sale
buy cialis super active without prescription
cialis super active for sale
buy cialis without prescription
cialis for sale
buy levitra without prescription
levitra for sale
buy viagra professional without prescription
viagra professional for sale
buy viagra soft without prescription
viagra soft for sale
buy viagra super active without prescription
viagra super active for sale
buy viagra super force without prescription
viagra super force for sale
buy viagra without prescription
viagra for sale
buy celebrex without prescription
celebrex for sale
buy colcrys without prescription
colcrys for sale
buy feldene without prescription
feldene for sale
buy imitrex without prescription
imitrex for sale
buy inderal without prescription
inderal for sale
buy indocin without prescription
indocin for sale
buy naprosyn without prescription
naprosyn for sale
buy pletal without prescription
pletal for sale
buy robaxin without prescription
robaxin for sale
buy voltaren without prescription
voltaren for sale

Tech Life of Recht » archive for 'spring'

 Best feature ever in Eclipse 3.5

  • September 26th, 2009
  • 10:46 am

I recently decided to switch from regular Eclipse to the SpringSource Tool Suite, as we do quite a lot of Spring projects, and not having auto-completion in the XML files is kinda stupid. This also meant upgrading from Eclipse 3.4 to 3.5, and this is where I accidentally ran into the best feature addition ever – or more appropriately, the best usability fix ever, although I don’t actually know if this is just a feature of the STS. In that case, there’s another argument for using it.
The problem in the older versions was that if you had a number of tabs open, you could switch between them using the more or less standardized Ctrl+PageUp/Down, which was nice. However, if one of the tabs contained so-called minitabs, like XML documents or Properties files do, you’d be stuck in these tabs, and Ctrl+PageUp/Down would switch between the minitabs, which was with quite an amount of certainty not what you wanted. This has now changed, so Ctrl+PageUp/Down only changes between the top-level tabs.

The gain in productivity is almost infinite…

 Spring 3.0 Overview

  • September 22nd, 2009
  • 10:33 pm

Last week I was at the Danish Spring User Group meetup in Copenhagen where I did a presentation on the new features in Spring 3.0. About 20 were present, but I thought it might be interesting to read about also.

Generally, Spring 3.0 does not contain any revolutionary features that will change the way you do enterprise development, but there are a number of nice new features which can make Spring easier and nicer to use. I should also note that everything I write is based on Spring 3.0 M4, where some features are still missing, and there might be a number of bugs.

General changes
Generally, support for JDK 1.4 is being removed, so most features will not be usable unless you use JDK 5. Also, support for JUnit 3 is deprecated, meaning that the good old AbstractDependencyInjectionContextTests is not to be used. Instead, use the testrunner introduced in 2.5 together with JUnit 4.
In many places, varargs and generics have been introduced – this is primarily in the ApplicationContext interface, but other places too. Some interfaces, however, will not be changed, so check out the new API.
Most of Spring’s own dependencies will be upgraded. This shouldn’t be much of a problem, but look out for this if you actually use any of the libraries (for example from Apache Commons).

Changes in Spring Beans
In Spring 2.5, there were two common ways of declaring Spring beans: using the standard XML and/or using annotations and autowiring. Spring 3.0 introduces a new way of declaring beans, namely the JavaConfig API.
Using the JavaConfig API, it is possible to declare beans in pure Java. It is not a complete XML replacement, as the JavaConfig classes will still need to be declared as Spring beans, and for that you need XML, at the very least component scanning.

A quick example on declaring beans:
[code]
@Configuration
public class SpringConfig {

@Bean
public MessageGenerator messageGenerator() {
return new EchoMessageGenerator();
}

@Bean
public AsyncMessageGenerator asyncGenerator() {
return new AsyncMessageGenerator(messagePrinter());
}

@Bean
public MessagePrinter messagePrinter() {
return new MessagePrinter();
}
}
[/code]

@Configuration is a @Component, so component scanning will pick up the configuration class. Basically, @Configuration corresponds to the <beans> tag in XML, and each method annotated with @Bean corresponds to the <bean> tag. In the example above, 3 beans are declared: messageGenerator of type MessageGenerator, asyncGenerator of type AsyncMessageGenerator, and messagePrinter of type MessagePrinter. Notice how asyncGenerator has a dependency which is injected using constructor injection by simply calling the bean method. Of course, bean names can be configured using the @Bean annotations. Also, beans can be marked as lazy using the new @Lazy annotation.

Due to technicalities about CGLIB, configuration classes cannot be final and they must have a no-arg constructor. This is because even though, as in the example above, messagePrinter() will be invoked twice, the actual instance will only be invoked once, thereby keeping the singleton scope for beans, which is still the default.

So why would you want to use JavaConfig? Frankly, I’m not sure – especially because you still have to use the old XML files. JavaConfig might be nice for type safety – when you refactor classes and methods, these changes will be picked up by the compiler. Time will tell if this will actually be useful.

Besides the new configuration API, there are some smaller changes which are relevant when declaring beans:

  • It is now possible to autowire scalar values into a bean. This happens using a combination of a new @Value annotation and PropertyPlaceHolders. On a bean property set for example @Value(“{db.url}”), and declare that property in a properties file and load that file using a PropertyPlaceHolder. Spring will then inject the property value into the bean. Using this, it is often possible to avoid any XML declarations at all.
  • More annotations to complement XML configuration: @Lazy to mark a bean as lazy, @DependsOn to express a dependency, and @Primary to mark the primary autowiring candidate.
  • Finally there’s a new type conversion infrastructure, which supercedes the old PropertyEditors. PropertyEditors are stateful and somewhat cumbersome to implement. The new converters are thread-safe and simple to implement. The old PropertyEditors are still supported.

There are a number of smaller changes also in the beans xml schema, but I’ve not experimented with them.

Threading and Scheduling
Here we actually have some pretty nice new features. Basically, Spring 3.0 supports the java.util.concurrent package introduced in JDK 5. Earlier, the new features could be used in Spring, but you had to configure a Executor yourself, schedule jobs, and so on (of course, it was still much better than using the classical synchronized/wait/notifyAll approach). However, Spring 3.0 improves this with two new annotations, @Async and @Scheduled, a number of support classes, and a new namespace.

Async scheduling is used when you want to execute a job in a thread, and at some point you might want a result. In Spring 3.0, it would look something like this:
[code]
public class AsyncMessageGenerator {
@Async
public Future<String> getMessage(String message) {
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
return new AsyncResult(message);
}
}
[/code]

Using this looks something like this:
[code]
public class AsyncMessageGeneratorTest {
@Autowired private AsyncMessageGenerator generator;

public void testGetMessage() throws InterruptedException, ExecutionException {
Future<String> res = generator.getMessage(“test”));
// do work
System.out.println(res.get());
}
}
[/code]

Spring will detect the @Async annotation and wrap the bean in an AOP Proxy, which will then execute the method in a standard Executor thread. The Future object is a standard java.util.concurrent.Future object, which you can block on if you want to wait for the thread to complete. Any method annotated with @Async must return either void or Future. When returning future, use the AsyncResult class from Spring to wrap the result in the implementation.

As usual, Spring will not do this by pure magic, so you need to register a BeanPostProcessor. Luckily, this can be done using the new scheduling namespace:
[code]
<beans xmlns=”http://www.springframework.org/schema/beans”
xmlns:task=”http://www.springframework.org/schema/task”
xsi:schemaLocation=”http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/task
http://www.springframework.org/schema/task/spring-task-3.0.xsd
“>

<context:annotation-config />
<task:annotation-driven />
</beans>
[/code]

This will register the appropriate BeanPostProcessors, and it will also configure a new Executor. If the default configuration is not ok, it can be customized using the executor element in the annotation-driven tag.

The second way of using threading is by using the @Scheduled annotation. Use this if you want to do something like a TimerTask where a job should be run periodically. The annotation can be used on any void method like this:
[code]
public class MessagePrinter {
private int num;

@Scheduled(fixedRate=1000)
public void printMessage() {
System.out.println(“Message number ” + ++num);
}
}
[/code]

The method shouldn’t be called manually, as Spring will pick it up automatically when instructed to do so using the task:annotation-driven element. In this example, the printMessage method will be run every second. For more advanced scheduling, the annotation also supports the cron attribute which makes it possible to schedule according to regular cron expressions.

These two annotations cover most of the usual scheduling cases, and I think they’re a great addition to Spring 3.0.

REST Support
Support for REST services is probably one of the more known features about Spring 3.0. The REST support is not revolutionary, and personally I prefer JAX-RS, but if you are already using Spring @MVC, using Spring REST might make sense. At least it’s simple to use.

Spring REST consists of two parts: A client API for accessing REST services, and a number of new annotations for @MVC for implementing REST services. The client API is centered around a new RestTemplate, which like all the other Template classes encapsulates all resource management and any transformations you’d want to make, for example from JSON to typed objects.

Using the RestTemplate, you can issue GET/PUT/DELETE/POST requests against a url. It looks something like this:
[code]
public class RestClient {
public List<Conference> listConferences() {
RestTemplate rt = new RestTemplate();
rt.setMessageConverters(new HttpMessageConverter[] {
new MappingJacksonHttpMessageConverter<Object>()
});
Conference[] res = rt.getForObject(“http://jaoo.dk/jaoorest/json”, Conference[].class);

return Arrays.asList(res);
}
}
[/code]

In this example, a GET request is issued against http://jaoo.dk/jaoorest/json. This returns a JSON representation, which is mapped to a regular POJO using the MappingJacksonHttpMessageConverter. This converter simply maps a JSON field to a bean property without any further configuration. For more complicated cases, the raw requests and responses can be accessed using callback methods on the RestTemplate – again like using any other Template class in Spring.

Developing REST services is simply a question of using Spring @MVC and a couple of new annotations. Here’s an example:

[code]
@Controller
public class RestService {

@Autowired
private RestClient client;

@RequestMapping(value=”/{user}”, method=RequestMethod.GET)
public void listFiles(@PathVariable(“user”) String user, @RequestHeader(“ETag”) String etag) {
// if etag matches return NOT_MODIFIED

System.out.println(“Getting files for ” + user);
}

@RequestMapping(value=”/{user}”, method=RequestMethod.PUT)
public void createFile(@PathVariable(“user”) String user, @RequestBody InputStream is) {
// write data to file
}

@RequestMapping(“/”)
public ModelAndView getFeed() {
ModelAndView mv = new ModelAndView();

List cs = client.listConferences();
mv.setView(new ConferenceFeedView());
mv.addObject(“conferences”, cs);

return mv;
}
}
[/code]

The @RequestMapping annotation is used as in 2.5, but now it also supports templates using {name}. A url can then be split into parts like “/blog/{year}/{month}/{day}/{item}”, and each of these parts can be bound to a method parameter using the @PathVariable annotation. This means no more manual url parsing.

This is probably the main feature, but there are also a couple of other annotations:

  • @RequestHeader can be used to bind a request header to a method parameter with automatic type conversion. Headers can be marked as required or can have a default value.
  • @CookieValue can bind a cookie to a method parameter
  • @RequestBody can bind the body of the request to a method parameter
  • @ExceptionHandler can be used to handle certain types of exception using other views than the default error view

Finally, there are a couple of new view implementations for generating feeds: the AbstractAtomFeedView and the AbstractRssFeedView.

There are some other minor additions to @MVC, but I haven’t had time to look into them.

Support for embedded databases
Many people have had the need for an embedded database, especially when running tests, and especially when using an ORM like Hibernate. Previously, you had to start one yourself, probably in some abstract test class, which all test classes then extended. In Spring 3.0, however, Spring can take care of that for you. This happens using the new jdbc namespace, like this:

[code]
<beans xmlns=”http://www.springframework.org/schema/beans”
xmlns:jdbc=”http://www.springframework.org/schema/jdbc”
xsi:schemaLocation=”http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/jdbc
http://www.springframework.org/schema/jdbc/spring-jdbc-3.0.xsd
“>

<jdbc:embedded-database id=”embedded-datasource” type=”HSQL”>
<jdbc:script location=”classpath:embed.sql” />
</jdbc:embedded-database>
</beans>
[/code]

This will automatically create a new DataSource called “embedded-datasource” using HSQL, and after starting the database, it will automatically load the SQL script in embed.sql from the classpath.

Real simple, and it can remove some of your template code, which is always nice.

Spring Expression Language
A new module in Spring 3.0 is the Spring Expression Language. It’s somewhat like the existing expression languages such as JSTL, OGNL, and so on, just with some additional features. Why? Good question, but Spring EL does have some nice features, and Spring EL will be used as the unified EL across all Spring modules. Whether it’s worth the effort or not, I can’t say.

Spring EL expressions are placed in #{}, and can be used in bean XML declarations when setting properties or referring to beans. Here are some examples:

[code]
#{bean.messages} // access a property on the object named “bean”
#{new java.io.File(bean.path)} // create a new instance of java.io.File
#{T(String).format(‘%s’, bean.message)} // invoke a static method on the String class (note the usage of the T operator)
#{props[‘jdbc.url’]} // access a property in the Properties object named “props”
#{bean?.inner?.prop} // navigate safely through a chain, avoiding any NPEs
#{users.?[active == true]} // select all objects where the active property is true from the collection named “users”
[/code]

There are many other features, this is just a short sample. Of course you can also use SpEL outside Spring, but that’s a little more complicated.

Model Validation
Spring 3.0 will support JSR-303 declarative model validation when it becomes final. The M4 release does not have any validation code yet, but that should arrive with the release candidate. Because of this, I haven’t had the opportunity to examine it closer.

Release schedule
Accoring to SpringSource, RC1 should be out this week. RC1 will be feature complete and with updated documentation. The reference documentation is already pretty uptodate, and the Javadocs also.

After RC1, the3.0GA (General Availability) release should be around October, but that depends on the amount of feedback from the community. Finally, 3.1 should be out in early 2010 – no major features are planned yet, but all new features from JEE6 should be supported – probably @Inject, JSR-303 final, and so on.

That’s it for now. As I’ve already mentioned, there are numerous smaller changes and bugfixes, so check out the bug tracker if you’re interested in something particular.

 Certified Spring Pro

  • August 28th, 2009
  • 5:28 pm

Certifications are not my thing. They’re pointless, stupid, and promote anything but useful learning. Despite that, I am a certified Java Programmer (yay), and as of today, I am also a Certified Spring Professional, which basically means that I am able to answer 50 irrelevant questions about Spring. Well, not entirely, I was able to answer 44 of them. Of course, you don’t get to know which ones were wrong so you could learn just a little, as that would obviously make the exercise a little useful.

Why then, you might ask, do I go through the trouble? There is a reason, but I don’t quite know if it’s a good one. Someone persuaded me to become a Spring trainer, and for that to happen, you have to be certified, and because the next course is in September, time was somewhat running out. Luckily, it’s more fun being an instructor, so I hope it will pay off later on.

 Two events

  • July 23rd, 2009
  • 11:38 am

Just a short notice about two events you might want to attend – they’re free, and I’ll be presenting at both of them.

First, there’s the first Google Wave Hackaton in Denmark, arranged by Tommy from Miracle. At this hackaton, we will explore the features in Google Wave and do some experiments. All suggestions are welcome, if you have any, go to the Google Group, and if you want to sign up, send an email to tpe (at) miracleas dot dk. It will be held in Århus on August 25th and in Copenhagen on September 10th, although I might only make it to the one in Århus. Oh, and everybody will receive a Google Wave Sandbox account.

The second event is with the Danish Spring User Group. On September 8th in Århus and September 17th in Copenhagen, I will be talking about the new features in Spring 3.0. Spring 3.0 is available in milestone 3, and contains some nice new stuff, summarized nicely here: http://blog.springsource.com/2009/05/06/spring-framework-30-m3-released/

To attend, join the Spring User Group DK on LinkedIn, where the complete schedule for the event can also be found.

 Spring iBatis integration with TypeHandlers

  • May 7th, 2009
  • 8:24 am

I recently had to do some iBatis SqlMap integration in a Spring project. It turned out not to be relevant after all, but I thought I’d share it in case anybody else could use it.
Basically, the problem was that I had to do some type conversion in code. For this, iBatis has the TypeHandler concept, where a handler can be registered on a specific Java type, and when this type is encountered in a SqlMap, the handler is called. Usually, the handlers are configured in the main SqlMap config file by referring to the class name in XML. However, in my case, the handlers had to be Spring-managed beans (they needed some beans to be injected), so the static configuration didn’t work. The solution was to extend the SqlMapClientFactoryBean class to do some extra wiring:

[code]
public class SqlMapTemplateFactoryBean extends SqlMapClientFactoryBean {

private Map handlers;

@SuppressWarnings(“deprecation”)
@Override
public Object getObject() {
ExtendedSqlMapClient client = (ExtendedSqlMapClient) super.getObject();
if (handlers != null) {
for (Iterator i = client.getDelegate().getResultMapNames(); i.hasNext(); ) {
String name = (String) i.next();
ResultMap map = client.getDelegate().getResultMap(name);

for (ResultMapping rm : map.getResultMappings()) {
if (rm.getJavaType() != null &&
handlers.containsKey(rm.getJavaType().getName())) {
rm.setTypeHandler(new CustomTypeHandler(handlers.get(rm.getJavaType().getName())));
}
}
}
}
return client;
}

@Override
public Class getObjectType() {
return SqlMapClientTemplate.class;
}

public void setTypeHandlers(Map handlers) {
this.handlers = handlers;
}
}
[/code]

This FactoryBean can then be used as a replacement for the regular SqlMapClientFactoryBean, and by setting the typeHandlers property, TypeHander instances can be injected:

[code]

dk.test.SomeVO


[/code]