[BLOSSOM-229] Add ApplicationContextInitializer Support to BlossomModuleSupport Created: 01/Mar/16  Updated: 29/Jun/18  Resolved: 01/Apr/16

Status: Closed
Project: Blossom
Component/s: blossom-spring-loaded
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Samuel Zihlmann Assignee: Tobias Mattsson
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to BLOSSOM-230 Module class bean properties as Prope... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Visible to:
Peter Mohn

 Description   

It's nice to have java based configuration support in BlossomDispatcherServlet now, but I like to go even further. For my purpose a would like to set a ApplicationContextInitializer on the BlossomDispatcherServlet. Now I have to extend the current BlossomModuleSupport and implement a custom #initBlossomDispatcherServlet method.



 Comments   
Comment by Tobias Mattsson [ 04/Mar/16 ]

What you need to do is:

BlossomDispatcherServlet dispatcherServlet = new BlossomDispatcherServlet();
dispatcherServlet.setContextClass(AnnotationConfigWebApplicationContext.class);
dispatcherServlet.setContextInitializers(new ApplicationContextInitializer<AnnotationConfigWebApplicationContext>() {
    @Override
    public void initialize(AnnotationConfigWebApplicationContext applicationContext) {
        // your initialization code here
    }
});
initDispatcherServlet(dispatcherServlet, "blossom", classNamesToString( your config classes here));

There are many things that can be useful to configure on the dispatcher servlet, and there's already a number of overloaded convenience methods on BlossomModuleSupport with typical settings as parameters. For each new optional parameter these overloaded methods need to support they double in number. To support ApplicationContextInitializer there'd need to be two new initBlossomDispatcherServlet methods, one for classes and one for config files, and another two for initDispatcherServlet. I don't think it's warranted to add these methods since the code required without them is so concise and manageable.

Comment by Samuel Zihlmann [ 07/Mar/16 ]

Ok, that's exactly my method now. Yes you are right, it's acceptable.

Taking about the #initBlossomDispatcherServlet:
I currently initializing multiple dispatcher servlets in the MyModule#start method, which are all sharing the same applicationContext. Which is the best way getting the fully initialized context after calling #initBlossomDeispatcherServlet? Wouldn't it be nice if the applicationContext is the returned object?
My current implementation is a bit messy

WebApplicationContext webApplicationContext = getDispatcherServlets().get(0).getWebApplicationContext();
Comment by Tobias Mattsson [ 11/Mar/16 ]

It would have been helpful it it returned BlossomDispatcherServlet so you could work on that and do getWebApplicationContext on it.

Unfortunately changing the result type of a java method is not binary compatible and existing code would fail with java.lang.NoSuchMethodError unless recompiled.

Generated at Sun Feb 11 23:31:26 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.