Class WebConferencingApplication
- All Implemented Interfaces:
org.springframework.web.WebApplicationInitializer
Web Conferencing has historically been a pure eXo Kernel add-on with no
Spring context at all. It gets one here for a single reason: contributing an
Application Center badge means contributing a Spring bean, and a bean needs a
context to live in. Extending PortalApplicationContextInitializer
registers this WAR's context with the Kernel before the portal container
boots, so beans of this add-on and of the platform become mutually injectable
— which is how VisioApplicationBadgePlugin can @Autowired the
Kernel-side WebConferencingService.
The scan is deliberately narrow. Only MODULE_NAME is scanned, and
every class currently shipped under that package by this add-on, by
web-conferencing-jitsi and by external-visio-connector
carries no Spring annotation whatsoever — so this context registers the badge
plugin and its listener, and nothing else. No JPA and no Liquibase
integration is declared: this add-on keeps managing its own schema through
the Kernel, and pulling those in would put a second, competing persistence
bootstrap in front of it.
AvailableIntegration.WEB_MODULE is kept even though no Spring MVC
endpoint is exposed: it carries the platform's own web security, locale and
transaction filter configuration, and every legacy Kernel WAR that took a
Spring context before this one (agenda, email-connector)
declares it. Dropping it would leave Spring Boot's default security
auto-configuration unadjusted over this WAR's existing url space.
LiquibaseAutoConfiguration is excluded, and the exclusion is what
actually enforces the "no second schema bootstrap" intent. Declining to list
LIQUIBASE_MODULE in the scan is not enough: Spring Boot
auto-configuration triggers on what is present on the classpath, not
on what is scanned, and Liquibase is on every platform's classpath. Left
alone it looks for its default db/changelog/db.changelog-master.yaml,
does not find one here, and fails the liquibase bean — which fails
entityManagerFactory behind it, stops this context, and through the
Kernel/Spring bridge takes the portal itself to a 500. Observed on a running
server, not theorised. agenda excludes the same configuration.
The JPA auto-configuration is deliberately not excluded, even though
this add-on owns no Spring-managed entity. Removing it was tried and broke
the boot differently: the platform modules scanned above expect an
entityManagerFactory to exist
(jpaSharedEM_entityManagerFactory resolves against it), so denying
them one merely swaps a Liquibase failure for a missing-bean one. The add-on
continues to manage its own schema through the Kernel regardless; the factory
simply goes unused here.
-
Field Summary
FieldsModifier and TypeFieldDescriptionstatic final StringBase package of the add-on, and the only root this context scans.Fields inherited from class org.springframework.boot.web.servlet.support.SpringBootServletInitializer
logger -
Constructor Summary
Constructors -
Method Summary
Methods inherited from class io.meeds.spring.kernel.PortalApplicationContextInitializer
createSpringApplicationBuilder, isAsync, onStartupMethods inherited from class org.springframework.boot.web.servlet.support.SpringBootServletInitializer
configure, createRootApplicationContext, deregisterJdbcDrivers, run, setRegisterErrorPageFilter, shutDownSharedReactorSchedulers
-
Field Details
-
MODULE_NAME
Base package of the add-on, and the only root this context scans.- See Also:
-
-
Constructor Details
-
WebConferencingApplication
public WebConferencingApplication()
-