Hi Ephemeris Lappis, blueprint proxy objects not updating is a known issue I have experienced as well, that is why we do more and more declarative services that handle dynamism better. Concerning features, we only use them to generate Karaf archive files (KAR), to have maximum control over what gets deployed, and it gets rid of the external repository security concern (remember log4j). Our nodes per default do not have any external network connection. Maintaining the cluster this way is no hassle up to now as semantic versioning and domain driven design do their job in creating loosely coupled modules that play nice with each other.
-----Oorspronkelijk bericht----- Van: Ephemeris Lappis <[email protected]> Verzonden: dinsdag 7 maart 2023 19:04 Aan: [email protected] Onderwerp: Re: Karaf 4.4.3 / Features wiring and upgrade CAUTION: This email originated from outside of Gaston Schul. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello. I finally changed my design a bit, and separated "F1" into 2 distinct features : - one for the API (interface declaration), say F1A - one for the service implementation, say F1S Now, when a modification is required, I can remove the repo and uninstall F1S, and add the new repo and install the new version. As the imported package in bundles of features Fx are still provided by F1A, Karaf lets me execute the operation. But the service references in bundles from features Fx are not updated, and exceptions "ServiceUnavailableException" are thrown when any operation of these obsolete proxies is called. If I "bundle:refresh" the bundles individually, the references are renewed and it works again. So how can I make Karaf force an update of all the concerned bundles ? I also notice something strange when I remove an old repo. I use "repo-remove -u REPO" to do it, and after that, the feature doesn't appear any more. But when I do "repo-add REPO", it seems that Karaf retrieves some invalid state, and the feature is installed in the same operation, and its bundle started, before I run a "feature:install"... Thanks for your help. Regards. Le ven. 3 mars 2023 à 12:37, Ephemeris Lappis <[email protected]> a écrit : > > Hello. > > I think I still need to learn a lot of things about Karaf's features... > > We have something like that, with 3 features levels : > > - F1 > set dependencies on some Camel and Karaf features > provides bundles that expose OSGi services > > -F2 > set dependencies on many common Camel features used by all the applications > and on F1 > > -Fx (all our applicative features) > set a dependency on F2 > provides the business Camel routes as a blueprint that use services > from F1 (and more) > > Note that in the bundles in Fx features, we have had to set > "<_removeheaders>Import-Service</_removeheaders>" because of missing > capabilities on services that are provided by pax-jdbc or pax-jms : > features do not install since pax-* do not expose these capabilities. > > When we add the repositories and install features for F1, F2 and Fx, all > works. > > Now, if I want to upgrade F1, we remove the repository with option > "-u" to uninstall the feature, and it may be logical to see some > impacts on dependent features F2, Fx, but nothing. > > Then we add the new repository in the new version and install again > F1. Here we also expected some impact on F2 and Fx, but nothing. > > Both actions produce this kind of logs, with "No deployment change" : > > 11:50:08.971 INFO [pipe-feature:install -u $args] The specified > feature: 'caterpillar-support' version '0.0.1.SNAPSHOT' has been > upgraded > 11:50:08.976 INFO [pipe-feature:install -u $args] Adding features: > caterpillar-support/[0.0.1.SNAPSHOT,0.0.1.SNAPSHOT] > 11:50:10.647 INFO [features-3-thread-1] No deployment change. > 11:50:10.653 INFO [features-3-thread-1] Done. > > What is wrong ? We expected all the dependent features and their > bundles (for Fx) to be restarted when a required dependency changes. > And in our case, all the Fx bundles are still displayed as active, > routes running, and so on, but the references with F1's services are > broken, and execution fails. > > Thanks in advance for your help. > > Regards. Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw verzoek gratis toegezonden. All our transactions are subject to the General Conditions of the Belgian Forwarders Association which have been published under nr. 0090237 in the "Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available free of charge upon request. Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande. Email confidentiality notice: This email and any files transmitted with it are confidential and intended only for the use of the recipient. If you have received this email in error please notify its sender.
