Comments on: Creating pluggable applications with Wicket and Spring

By: danisevsky

danisevsky — Thu, 01 Oct 2009 14:56:31 +0000

Great article, thank you Igor!

By: Golfman

Golfman — Wed, 23 Sep 2009 05:02:33 +0000

Beans, Spring, annotations – sounds like we’ve all lost our way!

Whatever happened to simple POJOs with a simple lightweight IOC framework that you could put together yourself in an afternoon?

Wicket, on the other hand, rocks massively!

By: dimitris

dimitris — Tue, 01 Sep 2009 14:32:19 +0000

Very nice framework.

I was trying to amplify it to be able to also edit instances (Articles) with an edit button on each line, but I’m having the following problem:

I managed to populate the correct data on the editArticlePage and if I change the DeployerPlugin the page updates correctly on selectionChange(), but on submit the Article still has the old DeployerPlugin value and gives an error. If you are interested I can send my changes until this point. If I find a solution I will update.

By: Ray A.

Ray A. — Mon, 02 Mar 2009 17:13:51 +0000

Very nice framework. I have a maven script that will build a spring hibernate wicket template and separate the HTML page. It helps a lot between the designer “Front End” and core developer “Java/J2EE”.

By: ivaynberg

ivaynberg — Tue, 07 Oct 2008 16:45:09 +0000

@Ray: While BeanPostProcessors are definitely slicker they also come with shortcommings for this particular usecase. Beans that use AOP-autoproxying cannot be processed by postprocessors, so those plugins will not be registered. Also, when you create proxies or apply any kind of aop (eg @Transactional on a bean) both the real class and the cglib generated subclass are viewed by postprocessors so you would have to filter for duplicates. I find that my way, while not as elegant, simply works.

@Per: Good to hear, enjoy.

@Jonathan: This kind of thing can be done with any IOC container that allows introspection. The point of this article was not really to glue Wicket to Spring, but more to demonstrate the pattern. In this whole article there is only one Spring-related class – the registry. I had a template Wicket/Spring project setup and so it was easy for me to base this article on that. Of course, feel free to rewrite the attached code using OSGi and I will be happy to append it to the article.

By: Jonathan Doklovic

Jonathan Doklovic — Tue, 07 Oct 2008 14:34:29 +0000

Nice article, but I think it would be a little better if osgi was used instead of rolling your own plugin registry.

Shouldn’t be that hard now that spring supports osgi.
http://www.springframework.org/osgi

- J

By: Per Ejeklint

Per Ejeklint — Tue, 07 Oct 2008 14:04:41 +0000

Great article! It solves a problem that’s been nagging me for a while – how to write UI plugs for corresponding measuring and control hw devices. Much appreciated.

By: Ray Krueger

Ray Krueger — Tue, 07 Oct 2008 11:10:47 +0000

Very cool.
Though you could clean up your IdentifiableBeanRegistry class by implementing BeanPostProcessor rather than InitializingBean.

Using IntializingBean.afterPropertiesSet you’re forced to go search the BeanFactory after the fact. By implementing BeanPostProcessor.postProcessAfterInitialization Spring will hand each bean to you as it creates them and you can simply use beanType.isAssignableFrom(bean.getClass()) as they come in.

Have a look at the BeanFactory lifecycle…
http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/beans/factory/BeanFactory.html