Using Seam as a simple IoC bean factory in console app

[siderean]

I'm working on a standalone, J2SE Java application (at a new job) which really calls for wiring beans together outside of application code. In the past I've used Spring to do this (simply creating a bean factory from an XML file in the classpath of the application).

Is there an example of using Seam in a similar way (beans would simply be defined in components.xml, I guess)? Specifically I'm looking for a minimal set of dependant jars to get such a use case implemented.

Thanks!
Don

[pmuir]

I've not heard of anyone doing this . You would need a way to bootstrap seam outside the servlet container. How about Guice?

[siderean]

Thanks for the suggestion, but I guess I'll stick with Spring for this particular application...

I thought Seam might accommodate the use case as I read an article recently that seemed to indicate that Seams most powerful feature is that of an integrated bean container/factory. Unfortunately I guess this simple scenario falls outside it's domain. Very unfortunate as beans in this standalone application are also part of our web applications and it would have been very nice to have a single bean container/factory (right now there is no IoC container in use).

Thanks, Don

[rhasselbaum]

I am interested in doing this, as well. The project I'm working on is a web application, but it also includes some command line utilities for certain administrative tasks. One of the things I like most about Spring is its ability to be bootstrapped outside of any web container. Is there any way to do this with Seam (i.e. without Embedded JBoss)? I don't require EJB, so a regular Java SE environment ought to be enough, right?

[rhasselbaum]

For what it's worth, I found a workable solution in my case. I'm using Spring anyway instead of EJB, and I really only need Spring beans for my console applications. The problem was that I configured Spring/Seam to use Seam-managed (conversation-scoped) Hibernate sessions via the SeamManagedSessionFactoryBean. But this was causing transactions to fail outside of the web container because Seam wasn't initialized.

The solution was to configure Spring's ApplicationContext to fall back to Spring-managed Hibernate sessions when running outside of the web container, which removes the dependency on Seam. One can set this up by creasing a bean alias (called, say, "sessionFactory") that points to the product of either SeamManagedSessionFactoryBean or Spring's AnnotationSessionFactoryBean. All Spring beans that need access to the session factory bind to the alias, and the implementation can be chosen at runtime (e.g. using a PropertyPlaceholderConfigurer).

Obviously, this won't work for everyone, and it kind of sidesteps the issue of bootstrapping Seam outside of a web container. (That would still be nice!) But if your application happens to use Spring anyway, it might be a workaround.