{noformat}
<ttarrant> sannegrinovero, your org.hibernate.search.engine imports <module name="org.infinispan" />
<ttarrant> sannegrinovero, sans-slot
<sannegrinovero> ttarrant, hu right. Actually that's tricky, as we need to depend on the current main Infinispan slot for Hibernate Search.
<sannegrinovero> ttarrant, (we don't need but it's optional - we need that version)
<sannegrinovero> ttarrant, what do you suggest? Can you override that for Query, or should I NOT define such dependency and have it specify by the users? (would my services be able to import it in that case?)
<ttarrant> sannegrinovero, I don't think you can do that
<sannegrinovero> ttarrant, what are the options?
<ttarrant> sannegrinovero, we need dmlloyd
<sannegrinovero> ttarrant, :)
<ttarrant> sannegrinovero, because it's not a matter of what you can or cannot do
<sannegrinovero> ttarrant, I guess the source of the problem could be considered that Search is built against infinispan 5.1 (which happens to be default slot) while we override that in Infinispan Query for obvious reasons
<dmlloyd> you've got me!
<sannegrinovero> dmlloyd, thanks and congratulations!
<dmlloyd> thank you!
<sannegrinovero> dmlloyd, you might have seen on in.relation.to, we started to "package" some of our libraries as ready-to-download modules for AS7
<sannegrinovero> dmlloyd, mostly because several projects are depending, in this case, on Hibernate Search: CapeDwarf, ModeShape, Infinispan, ..
<sannegrinovero> dmlloyd, now since my priority is people using AS7.1 we made Hibernate Search modules using the Infinispan slot "main" (i.e. version 5.1.x)
<Kosch> bleeding edge user ;)
<sannegrinovero> dmlloyd, but Infinispan (master, i.e. 5.2.x) would like to consume it as well for the search functionality.
<sannegrinovero> dmlloyd, now in the Search-Engine, we have an optional dependency on Infinispan, which is loaded as a service, hence Search depends on the Infinispan module.
<dmlloyd> and the new infinispan is under a different slot?
<sannegrinovero> yes
<sannegrinovero> I though I could remove the dependency from the Search to Infinispam module, but I assume that removing this dependency, I won't be able to load the services from it anymore.
<dmlloyd> okay well problem number one is probably that the new infinispan should probably not be under a new slot, rather it should replace the original... but I'll leave that aside for the moment
<dmlloyd> Inifispam, lol
<dmlloyd> best typo...
<dmlloyd> this N versions problem is really best addressed by using separate API/implementation modules
<sannegrinovero> I think we all agree in theory, but JDG is built on top of EAP and there isn't an EAP with latest Infinispan (which is obviously needed for it)
<sannegrinovero> while we know that we can't rip out Infinispan from AS7 without breaking things
<dmlloyd> nevertheless JDG should be able to replace modules with updated versions according to the "addon" layered product methodology, can it not?
<sannegrinovero> ttarrant, still following along? you know those reasons better ^^
<sannegrinovero> dmlloyd, do we have other examples of "addons" replacing existing core technology?
<dmlloyd> I do not believe there are actual examples of any layered products yet really!
<sannegrinovero> actually that's not a relevant question sorry: there might be some, still we know that this one is plain incompatible.
<ttarrant> dmlloyd, problem
<ttarrant> dmlloyd, as you know the AS uses a specific version of Infinispan internally for clustering
<ttarrant> dmlloyd, but when we (the infinispan team) release a new version we don't want to interfere with that
<sannegrinovero> AFAIK the configuration parsing is different too
<ttarrant> dmlloyd, I also just created MODULES-150: is that applicable ?
<jbossbot> jira [MODULES-150] Allow specifying slot in MANIFEST Dependencies [Open (Unresolved) Feature Request, Major, David Lloyd] https://issues.jboss.org/browse/MODULES-150
<dmlloyd> you already *can* specify slot in MANIFEST
<dmlloyd> at least in jboss modules you can
<dmlloyd> foo.bar:slot
<dmlloyd> JBoss AS has its own manifest dependency processor but it should also support it
<dmlloyd> the only other solution is to duplicate your hib search module for each version of infinispan it ties on to
<dmlloyd> or otherwise break the dependency
<dmlloyd> if the dep is only for service loading you should be able to break it another way (e.g. specify ClassLoader when locating the service, use TCCL to detect what version to try, etc.)
<ttarrant> dmlloyd, ok
<dmlloyd> an API module solves the problem more elegantly, though it's higher maintenance to be sure
<sannegrinovero> This is currently not very practical, but I like it best: by using different versions we should clearly label it with a different identifier, so I like the clarity of the solution.
<dmlloyd> you have to ensure that your APIs are 100% backwards compatible forever, from a linking perspective
<sannegrinovero> (referring to duplicate in different modules ^)
<dmlloyd> so that old versions can use new APIs
<rhauch> dmlloyd: yes, but I'd still love to have one. :-)
<sannegrinovero> specifying the ClassLoader is a good point, I'll think about having that but in the next version, so next time we'll have an additional option.
<sannegrinovero> ttarrant, what do you think of that ^? Can we find a solution for this round, and use a classloader in the future?
<ttarrant> sannegrinovero, yes
<sannegrinovero> ttarrant, good I'll make an option that the SearchConfiguration can take a CL instance to use for loading of services.
{noformat}
Conclusion: Integrators should be able to pass a ClassLoader to the SearchConfiguration; this doesn't necessarily need to break the SPI as we can use the "Provided Services" trick.
To be discussed: how many different ClassLoaders do we need? just one for "Services" or is there a differentiation for example for "User extensions", ... ?
Or maybe thinks like additional Services (in Hibernate Search terminology) should be loaded from a different source (CL) than for example stopword lists, Domain objects (entities), custom Analyzers?
To keep in mind also the Hibernate ORM has an internal service for ClassLoading; in Search ORM we should use that one.
|
|
