[BLOSSOM-174] Areas don't seem to respect exclusion rules from component-scan Created: 05/May/14  Updated: 07/Nov/14  Resolved: 16/May/14

Status: Closed
Project: Blossom
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: TLN Assignee: Tobias Mattsson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Hi Tobias,

in my blossom-servlet.xml I use the following code inspired by the Maven archetype:

<context:component-scan base-package="xzy" use-default-filters="false">
	<context:include-filter type="annotation" expression="info.magnolia.module.blossom.annotation.Template"/>
	<context:include-filter type="annotation" expression="info.magnolia.module.blossom.annotation.Area"/>
	<context:include-filter type="annotation" expression="info.magnolia.module.blossom.annotation.DialogFactory"/>
	<context:include-filter type="annotation" expression="info.magnolia.module.blossom.annotation.VirtualURIMapper"/>
</context:component-scan>

This works well as such.

Now, one of the next steps in our project was using different spring profiles (see http://spring.io/blog/2011/02/11/spring-framework-3-1-m1-released/) because our project has different deployment types which partially require different templates (i.e. Spring Controllers) and we didn't want to confuse the editors with templates being shown as available in the backend although they're not applicable in the current mode.

Thus I created different profiles like this:

<beans profile="abc">
	<context:component-scan base-package="xzy" use-default-filters="false">
		<context:include-filter type="annotation" expression="info.magnolia.module.blossom.annotation.Template"/>
		<context:include-filter type="annotation" expression="info.magnolia.module.blossom.annotation.Area"/>
		<context:include-filter type="annotation" expression="info.magnolia.module.blossom.annotation.DialogFactory"/>
		<context:include-filter type="annotation" expression="info.magnolia.module.blossom.annotation.VirtualURIMapper"/>

		<context:exclude-filter type="annotation" expression="my.Annotation"/>
	</context:component-scan>
</beans>

This, too, is finally working after a lot of research and trial and error. I'm very happy about that.
At least it is working for Controllers. That's good news.

However, it is not working for Areas. Although I proved with the debugger in org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider (line 329, in method isCandidateComponent()) that the area in question is reported as excluded by Spring, the excluded area is finally created in the rendering phase.

You will probably argue it's not a problem, I'm not forced to use any area in my JSP file if I don't like it. However the idea is to have several @Area classes in one controller which have the same are name (e.g. several areas with the signature

@Area(value="sidebar", title="Sidebar")

) and to make them mutually exclusive by the marker annotations as just described. If Blossom doesn't respect the exclusion rules, like it seems, this approach won't work.

The whole subject is a little tricky, I can't guarantee that the problem is with Blossom, but because everything else is working as described above, it's hard to find another explanation at the moment.

Thanks a lot for looking into it on occasion.

Best Regards,
Torsten



 Comments   
Comment by Tobias Mattsson [ 09/May/14 ]

Hi Torsten,

It appears that this is caused by Spring's java config support. Beans annotated with @Component or meta-annotated with @Component which @Controller is, are treated as configuration classes. In our case this is the template class. Configuration classes are scanned for member classes that are configuration classes themselves, using the same criteria.

So the component scan does exclude your area but java config finds it and adds it. Spring MVC's HandlerMappings will then scan the application context and add mappings for both the template and the area.

Finally Blossom inspects the HandlerMapping and finds both.

I can't find a way to influence this behavior except for removing the ConfigurationClassPostProcessor, but this will need to happen at just the right time because its added in a number of places.

It would be easier to decide in the template which areas to render or write a custom Blossom TemplateDefinitionBuilder that knows which controllers to ignore. Either using an annotation or a naming convention.

Hope that helps, Tobias

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