[hibernate-dev] The Hibernate Search / Apache Tika interaction with WildFly modules

TLDR - Remove all "optional" Maven dependencies from the project - Things like the TikaBridge need to live in their own build unit (their own jar) - Components which don't have all dependencies shall not be included in WildFly modules These are my notes after debugging HSEARCH-1885. A service can be optionally loaded by the Service Loader pattern, but all dependencies of each module must be available to the static module definition. Our current WildFly modules include the hibernate-search-engine jar, which has an optional dependencies to Apache Tika. We don't provide a module of Apache Tika as it has many dependencies, so there was the assumption that extensions can be loaded from the user classpath (as it normally works). This one specifically, can't currently be loaded from the user EAR/WAR as that causes a The problem is that, while we initialize the org.hibernate.search.bridge.builtin.TikaBridge using the correct classloader (an aggregate from Hibernate ORM which includes the user deployment), this only initialized the definition of the TikaBridge itself. After its class initialization, when this is first used this will trigger initialization of its import statements; it imports org.apache.tika.parser.Parser (among others), but at this point we're out of the scope of the custom classloader usage, so the current module is being used as the extension was in fact *loaded from* the classloader for hibernate-search-engine. The point is that the TikaBridge - while it was loaded from the aggregated classloader - it was ultimately found in the hibernate-search-engine module and at that point was associated with that. A possible workaround is to set the TCCL to the aggregate classloader during initialization of the TikaBridge and its dependencies, but this is problematic as we can't predict which other dependencies will be needed at runtime, when the Tika parsing happens of any random data: one would also need to store a pointer to this classloader within the FieldBridge, and then override the TCCL at runtime each time the bridge is invoked.. that's horrible. The much simpler solution is to make sure the TikaBridge class is loaded *and associated* to a classloader which is actually able to load its extensions! In other words, if the user deployment includes the Tika extensions, it should also include the TikaBridge. So the correct solution is to break out this into a Tika module, and not include it within the WildFly module, but have the users include it as an extension point, as they would with other custom FieldBridges. This problem would apply to any other dependency using the "optional" qualifier of Maven; currently only our Tika integration relies on it, so let's remove it but please let's also avoid "optional" in the future. Thanks, Sanne