annotation handling not working when the application is deployed

[snicoll]

We are using a similar approach to the batch admin project where each job is configured in its own spring configuration file. We use the AutomaticJobRegistar class to scan those files and load them.

In our main applicationContext we have the following:

context:annotation-config/>

While our code is running fine in a unit test, it fails in Tomcat with our EntityContext being null (@PersistenceContext). If we add the following to the job configuration file it works

bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" />

Why is that? Isn't context:annotation-config supposed to be reachable and applied in the child contexts as well? Having to define this for each and every job is really painful.

BTW, I can reproduce the problem in a unit test as soon as I use the AutomaticJobRegistar (e.g. child contexts) to load my job.

[Dave Syer]

The application context hierarchy would be different in the test that passed. The AutomaticJobRegistar copies some BeanPostProcessor instances over from the parent context, but it should not be excluding anything without you asking (it does this via the ApplicationContextFactory instances that get created indirectly). Can you post the config for the registrar?

[snicoll]

Yup got that meanwhile. If I use the same automaticJobRegistar config, I get the same issue in the test (which is good).

My config is the following

<bean class="org.springframework.batch.core.configuration.support.AutomaticJobRegistrar">
        <property name="applicationContextFactories">
            <bean class="org.springframework.batch.core.configuration.support.ClasspathXmlApplicationContextsFactoryBean">
                <property name="resources" value="classpath*:/jobs/*Job.xml"/>
            </bean>
        </property>
        <property name="jobLoader">
            <bean class="org.springframework.batch.core.configuration.support.DefaultJobLoader">
                <property name="jobRegistry" ref="jobRegistry"/>
            </bean>
        </property>
    </bean>

Ideally, I would like to inherit from all the BeanPostProcessor (unless this can cause any issue)

[snicoll]

okay so I saw the exclude thing which basically excludes everything by default. Why don't we inherit from context:annotation-config by default (if specified). That seems a fair choice isn't it?

Besides, the set method are very confusing since they don't set but add elements in the list as far as I can see. How can I remove the BeanFactoryAware which excludes virtually anything I want to inherit?

[Dave Syer]

There are definitely some post processors that you don't want to inherit (the ones with a reference to the parent bean factory, and we try to detect those using BeanFactoryAware), so probably annotation config is one of them. Is it such a big deal to include that one line in your Job configuration file?

The set methods are true setters - they don't append to an existing list as far as I can see - so I didn't get that point.

You should see some "Removing BeanPostProcessor..." log messages if you enable debug. Maybe that would help to understand the issue?

[snicoll]

There are definitely some post processors that you don't want to inherit (the ones with a reference to the parent bean factory, and we try to detect those using BeanFactoryAware), so probably annotation config is one of them. Is it such a big deal to include that one line in your Job configuration file?

Yes.

The set methods are true setters - they don't append to an existing list as far as I can see - so I didn't get that point.

Well I misunderstood with ClassPathXmlApplicationContextFactory. I lost the argument creation in the setter. Nevermind.

You should see some "Removing BeanPostProcessor..." log messages if you enable debug. Maybe that would help to understand the issue?

okay, will do.

[snicoll]

You should see some "Removing BeanPostProcessor..." log messages if you enable debug. Maybe that would help to understand the issue?

Okay so for this particular use case, it's indeed removing 4 bean post processors and I can see them but that really does not help, knowing that I just want a set of post processor to be there (if they are defined) and still uses the default value (I am not going to hardcode the list of post processors that I don't want to use ...)

I tried to upgrade ClassPathXmlApplicationContextFactory so that it accepts a "beanPostProcessorIncludeClasses". I have the code and that should do what I want except that I can't change the context factory used by ClasspathXmlApplicationContextsFactoryBean.

The only solution is to copy/paste the getObject method. I am not sure that my use case is so weird. if I have @PersistenceContext injection at the webapp level, it's quite logical to have it in my jobs as well or am I missing something?

[Dave Syer]

The thing you are missing I think is that the post processor simply will not work in the child context. You have to add your own in the child context. If for some reason you don't want to do it in XML then you can customize the bean factory in the application context factory, which might mean forking the factory bean.

[snicoll]

The thing you are missing I think is that the post processor simply will not work in the child context. You have to add your own in the child context. If for some reason you don't want to do it in XML then you can customize the bean factory in the application context factory, which might mean forking the factory bean.

Okay, I indeed missed that completely. That being said, is there any reason why a bean is inherited in a child context and not something as common as those post processors? Is this a limitation of the spring framework or something that was done on purpose? For this particular use case, I can't see a valid reason why it shouldn't work actually ...