Try to express my problem

[zaynetro]

I don't really need DemoPostProcessor to be initialized statically. I need it to be initialized after constructing a Hello bean with ServletContext.

ServletContext <-- Hello bean <-- DemoPostProcessort bean

[snicoll]

Why does this need to be a bean?

[zaynetro]

I would need to use it in other parts of the application.

In CometD context this bean will be a BayeuxServer.

[snicoll]

Yeah that won't work for sure. Can you give this a try?

public class DemoBean implements ApplicationListener<ApplicationStartedEvent> {

   ....

   @Override
    public void onApplicationEvent(ApplicationStartedEvent event) {
      ApplicationContext applicationContext = event.getApplicationContext();
      this.servletContext = ((WebApplicationContext) applicationContext).getServletcontext();
    }

}

[snicoll]

I don't really need DemoPostProcessor to be initialized statically. I

I know you don't but that's how BPP should be ideally defined in Spring Land. Such beans are created very early in the lifecycle and making them static makes it easier to express they don't carry too much dependencies. Certainly a BPP that depends on a bean that depends on ServletContext is creating an impossible cycle for the context to resolve when the context is starting as part of the application lifecycle.

[snicoll]

Also I hate to say this but building a war would make you more aligned with what you had before. If you package a war and deploy it to a container, ServletContext will be available upfront the same way it did with Spring Framework.

Perhaps this is something that the cometd project could handle for you? The examples I've seen so far were not really meant for Spring Boot as far as I could see.

[zaynetro]

Thanks a lot for your proactive help! I will take a look after the holidays and get back to you.

If I struggle too much there is an alternative path for me to take. CometD supports running without processing annotations also.

[zaynetro]

I think I have found a solution at least. I don't particularly like it but I still have another option to explore which is not asking cometd to process annotations.

Thanks for your help!

[snicoll]

Sure thing. By solution, you mean catching that technical exception? If so, please don't do that. Using an ObjectProvider with late resolution seems much more aligned with what's actually happening.

[zaynetro]

I wasn't aware of ObjectProvider thanks. I will take a look.

[snicoll]

Sorry not enough coffee here. I meant ApplictionContextAware. While the context that you'll get injected on startup will have a null servlet context you can keep the reference and access the servlet context later. You can also implement that on the BPP if you need it as this a safe callback that doesn't trigger early init.

Long story short: you can inject something early that will get you access to the context once the app has started.

ObjectProvider would work if we'd register the servlet context down the road but we don't for jar deployment which I think is a bug we need to fix.

If you update this sample here with the proposal I am happy to review and guide further. Thanks for the follow up!

[zaynetro]

Sorry, I don't understand. Our DemoPostProcessor is already application context aware. The problem is that I need to inject a bean that should have servlet context upon initialization.

Anyway, sorry to say this but I have to move on with my tasks. I have prompted for a different solution and now I simply post process the specific beans manually without using BPP.

Feel free to close all of my issues.

[zaynetro]

Thanks a lot for your help though! Much appreciated!

[snicoll]

The problem is that I need to inject a bean that should have servlet context upon initialization.

We already saw that this isn't possible. That bean will have to defer access to the servlet context. One way to do that is to inject ApplicationContext and then only access the ServletContext when it needs it. If that bean needs ServletContext in its constructor, I guess this can be rearranged but I can't say without more details.

Having said all of that, I agree this issue has run its course now. Glad you got it working!