Bean property configuration

[johaneltes]

Using Spring with an xml bean source, I typically use the xml file to...

a) Determine which implementation class to use for an interface
b) Configure values for bean properties of a bean (e.g. a JMSTemplate).

Is b) a use-case of CDI?

A sample with Spring:

 <bean id="errorQueueTemplate" class="org.springframework.jms.core.JmsTemplate" >
     <property name="receiveTimeout">
          <value>7200</value>
     </property>
</bean>  

Basically, I have an existing pojo class. I need to configure a number of beans, each with variations in how the properties are configured. All these bean configs would go into a specific spring config file (i.e. spring-jms-config.xml)

I was having weld bean represent the config file and then define a producer method for each of the beans. Something like this:

public class JmsTemplateConfigurationProducer {
     
     @Produces int longReceiveTimeout = 3*3600;
     @Produces int shortReceiveTimeout = 100;

     @Produces @Named
     public JmsTemplate getErrorQeueTemplate() {     
          return new JmsTemplate() {

               @Override
               @Inject @Named("longReceiveTimeout") 
               public void setReceiveTimeout(long receiveTimeout) {
                    super.setReceiveTimeout(receiveTimeout);
               }     
          };               
     }
     
     @Produces @Named
     public JmsTemplate getLogQeueTemplate() {          
          return new JmsTemplate() {

               @Override
               @Inject @Named("shortReceiveTimeout") 
               public void setReceiveTimeout(long receiveTimeout) {
                    super.setReceiveTimeout(receiveTimeout);
               }     
          };               
     }
}

So that injection points may be defined like this:

@Named JmsTemplate logQeueTemplate;

Are there better / less verbose / more "weldish" ways to approach the problem?

/Johan

[alin.heyoulin.qq.com]

I have the same question. So i like spring xml property inject. Does weld can do it?

[gavin.king]

Using Spring with an xml bean source, I typically use the xml file to...

a) Determine which implementation class to use for an interface

In CDI, we use @Altenative for that.

b) Configure values for bean properties of a bean (e.g. a JMSTemplate).

There are various ways to approach this. You could use a portable extension to read values from properties files or XML, or define your properties in Java. I'm not quite sure precisely which route I would go down myself. Probably the Java route.

[alin.heyoulin.qq.com]

If i want inject property into an other java class of jar it is not manager bean. eg:org.apache.commons.dbcp.BasicDataSource

So i would like using xml to config manager bean and have highest priority. So it is not restricted in one jar and it can overide java class define.

[alin.heyoulin.qq.com]

I hope seam3 will have components.xml config file

[gavin.king]

Yes, the plan is to implement something very similar as a portable extension for CDI. Actually, some work has already been done on that.

[meetoblivion]

what exactly do you feel components.xml will do that you can't do with weld?  it seems like the overall goal in weld is injecting via a very little bit of code rather than a verbose xml document (and yes, i've worked at places that have excruciatingly painful spring xml files)

[gavin.king]

John Ament wrote on Dec 28, 2009 02:57:


what exactly do you feel components.xml will do that you can't do with weld?  it seems like the overall goal in weld is injecting via a very little bit of code rather than a verbose xml document (and yes, i've worked at places that have excruciatingly painful spring xml files)

Agreed, the kinds of things that you use XML for in Spring can be accomplished easily in Java in CDI. For example:

@Alternative
class Testing {

    @Produces @LoggedIn User user = new User("gavin", "foobar");

    @Produces @Admin User admin = new User("admin", "nimda");

    @Produces @UserDatabase 
    EntityManager getUserDatabaseEntityManager(@New MockEntityManager em) {
        em.add(user);
        em.add(admin);
        return em;
    }

    @Produces Level logLevel = Level.DEBUG;

}

class Production {

    @Produces @UserDatabase 
    @PersistenceContext(unitName="UserDB") 
    EntityManager em;

    @Produces Level logLevel = Level.WARN;

}

when you enable Testing in beans.xml, you get its definition of stuff. Otherwise you get the defaults defined in Production. No need for complex XML files.

[alin.heyoulin.qq.com]

xml config file can let you reuse your exist old pojo and third part java bean and make it become maneger bean. I don't know how weld to do easily.

[gavin.king]

he youlin wrote on Dec 28, 2009 03:16:


xml config file can let you reuse your exist old pojo and third part java bean and make it become maneger bean. I don't know how weld to do easily.

Write a producer method or field:

@Produces @Special @Named @SessionScoped Foo foo = new Foo(....);

If the constructor is not enough to init the object, use a producer method:

@Produces 
@Special 
@Named 
@SessionScoped 
Foo getFoo() { 
   Foo f = new Foo(); 
   f.init(); 
   return f; 
}

If you need to inject into the Foo, or add interceptors/decorators (unlikely, since it is legacy code), use @New:

@Produces 
@Special 
@Named 
@SessionScoped 
Foo getFoo(@New Foo f) { 
   return f; 
}

Easy!

[meetoblivion]

i guess one of the big things missing from weld as it stands (and will likely be addressed via an extension) is there's not native way to just wire a bean without any code, it requires a producer method.  spring did this via the properties set in the xml, and really the difference here is you need to write a little bit of code, instead of having it just there in an xml file.

but if you think about it, most things that you inject via spring's xml can already be injected automatically in weld - other beans, database connections, property files, etc.

[alin.heyoulin.qq.com]

Somtimes i don't want change the java code at app start up. Just change xml config

[gavin.king]

i guess one of the big things missing from weld as it stands (and will likely be addressed via an extension) is there's not native way to just wire a bean without any code, it requires a producer method. spring did this via the properties set in the xml, and really the difference here is you need to write a little bit of code, instead of having it just there in an xml file.

Cos Spring XML is not code? Nonsense, it's totally code. It's virtually a scripting language, in fact.

Like I said, we will implement XML configuration as a portable extension, but it's a kinda old-fashioned thing that's not really needed in the world of CDI.

Somtimes i don't want change the java code at app start up. Just change xml config

Right. That's the purpose of @Alternative. You can active the particular @Alternative you're interested in just by changing beans.xml.

Read this stuff:

1. http://in.relation.to/Bloggers/MakingExternalResourcesConfigurableWithoutLotsOfXML


2. http://in.relation.to/Bloggers/MakingExternalResourcesConfigurableWithoutLotsOfXMLPart2


3. http://in.relation.to/Bloggers/ModularDependencies

[meetoblivion]

Actually, I think the appropriate use case is when you want to change the value of some primitive type from n to 2n.

and yes, spring xml is its own scripting language, i wasn't trying to infer otherwise.  actually another thing I want to try to get done (once I have the what i need to get dones done) is groovy script extension for producing beans. that'd be cool, right?

[alin.heyoulin.qq.com]

Alternative still have some hard code. And do i have all preconcerted Alternative?

BWT Alternative is not clear than xml