Using XML Bean Config to set default conversation timeout

[dan.j.allen]

I'm attempting to use the XML Bean Config module to set the default conversation timeout. However, it's not working.

At first, I tried the following:

<beans xmlns="http://java.sun.com/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:s="urn:java:seam:core" 
   xsi:schemaLocation="
      http://java.sun.com/xml/ns/javaee 
      http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
   
   <s:Conversation>
      <s:extends/>
      <s:timeout>5000</s:timeout>
   </s:Conversation>
   
</beans>

But that led to a NullPointer exception when attempting to find the method setTimeout on Conversation, perhaps because Conversation is an interface.

Out of desperation, I tried to apply the field value to the Conversation implementation in Weld:

<beans xmlns="http://java.sun.com/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:s="urn:java:seam:core"
   xmlns:w="urn:java:org.jboss.weld.conversation" 
   xsi:schemaLocation="
      http://java.sun.com/xml/ns/javaee 
      http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">

   <w:ConversationImpl>
      <s:extends/>
      <w:timeout>5000</w:timeout>
   </w:ConversationImpl>
   
</beans>

However, no matter what combination of <s:extends/> or <s:override/> I tried, I got an ambiguous dependency problem. Any solution?

Also, if I'm just setting initial property values, which nested tag should I use, extends or override?

[swd847]

I just investigated this, built in beans such as conversation are not going through BeforeBeanDiscovery and ProcessInjectionTarget, so the XML extension can't veto the old implementation and install it's new one.

[swd847]

Also you should use the <extends> tag to set values. <override> would clear all annotations from the base class, extends merges them with the annotations on the XML.

[dan.j.allen]

Just to keep everyone up to speed, the issue is that XML Bean Config does not yet support interface configuration. I'm creating a JIRA to track the progress. For now, if you are configuring bean properties, it needs to be a real class.

[dan.j.allen]

To make things clearer, Stuart and I discussed renaming the <extends> tag to <specializes> (or <specialises> for the Australian fans), since this term matches much more closely with the way that bean replacement is done in Java using inheritance and the @Specializes annotation). The semantics will be slightly different, but that's to be expected given that we are talking about XML-based configuration.

proposed:

<beans xmlns="http://java.sun.com/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:s="urn:java:seam:core" 
   xsi:schemaLocation="
      http://java.sun.com/xml/ns/javaee 
      http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
   
   <s:Conversation>
      <s:specializes/>
      <s:timeout>5000</s:timeout>
   </s:Conversation>
   
</beans>

We also discussed that explicitly requiring <specializes> or <override> makes it unmistakably clear that you are replacing (in a sense wrapping) a bean rather than introducing a new one. This was a frequent source of confusion in Seam 2, so we want to fix that experience.

[dan.j.allen]

SEAMXML-1

[swd847]

Should it also be <overrides> rather than <override>?

[dan.j.allen]

Stuart Douglas wrote on Mar 31, 2010 05:29:


Should it also be <overrides> rather than <override>?

Yes, let's follow the pattern of using active verbs. Good plan.

[swd847]

The tag names have changed in trunk

[nickarls]

I'm not that familiar with the XML init but will it prevent the initializer in ConversationImpl

   @Inject
   public void init(@ConversationInactivityTimeout long timeout)
   {
      this.timeout = timeout;
      _transient = true;
   }

from running over your settings?

[swd847]

That will run all over the settings.

I am not sure if I should set the field values before injection/initalizer methods or before the PostConstruct method is called (or both, just for good measure).

Currently they are set before injection, which means they are available to the initalizer methods, however conversely init method can walk all over them (which will probably be a pretty common case).

Internally setting field values is implemented as a wrapper around InjectionTarget, so there are 4 places I can put it:

• before inect()


• after inject()


• before PostConstruct()


• after PostConstruct()

Does anyone have any ideas as to what the correct behavior should be here?

[dan.j.allen]

Stuart Douglas wrote on Apr 01, 2010 01:42:


That will run all over the settings.

I agree that the initializer method of the ConversationImpl in Weld should at least be honoring an already assigned value.

I am not sure if I should set the field values before injection/initalizer methods or before the PostConstruct method is called (or both, just for good measure).

What's interesting is that in Seam 2, there was only one post construct method for a bean, whereas in CDI we now have initializers, so there is another point in the bean initialization lifecycle.

The benefit that CDI initializers have over managed bean @PostConstruct methods is that initializers can accept injected parameters. Therefore, I see developers choosing initializers more often than @PostConstruct (and other times using them interchangeably).

Currently they are set before injection, which means they are available to the initalizer methods, however conversely init method can walk all over them (which will probably be a pretty common case).

Internally setting field values is implemented as a wrapper around InjectionTarget, so there are 4 places I can put it:

• before inect()


• after inject()


• before PostConstruct()


• after PostConstruct()

Does anyone have any ideas as to what the correct behavior should be here?

Since the strategy in Seam 2 was to make sure initial field values were assigned before the post construct method was called, I think it is safe to say that we should set the initial field values before initializers as well. Users will likely expect that behavior.

Therefore, I'm going to have to go with before inject, or for that matter, any time during inject but before the initializers are called. I'd definitely stand behind this decision. Initial field values can then be tuned in the initializer or post construct methods.

Setting the field values after the initializer but before post construct is just going to be confusing.

[swd847]

That is the way it is implemented now. In this case it does not really matter, as I can't touch the conversation object anyway.

[nickarls]

I changed init() so it only applies the param if timeout is currently unset (0). Since it's a long and not a Long I can only hope that noone wants to configure it to 0 in XML ;-)