Hi Ephemeris Lappis, - why sometimes the service wiring works, and fails in other cases ?
I remember reading the advice to use DS, I forgot about the detailed reason, but I think it had to do with this and that DS is actively maintained: https://www.slideshare.net/mfrancis/why-classforname-sucks-bj-hargrave https://blog.hargrave.io/2007/07/why-do-classforname-and.html - is there any way to force a refresh of all the referencing bundles when the feature and its service implementation are replaced ? The blunt answer, we restart a cluster node after deployment changes. This dynamism use case is not of importance in our enterprise setup, because of the fine-grained architecture we rarely have serious bugs or bugs that must be fixed under production times. We use OSGi mainly as crash-rails for designing modularity. -----Oorspronkelijk bericht----- Van: Ephemeris Lappis <[email protected]> Verzonden: woensdag 8 maart 2023 13:02 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 Maurice. If I understand your explanation correctly, this inconsistent state only impacts blueprint service references. I've tried with simpler features, with only one service and one reference in the same design with Camel blueprints, and it seems that sometimes it works. See the attached archive with a full project. In this case, with the same Karaf, removing the service implementation feature makes the routes waiting for the service, and adding a new version of the feature, all works again as expected. As all our applicative bundles are based on Camel blueprints, we can't consider rewriting it all... So two questions : - why sometimes the service wiring works, and fails in other cases ? - is there any way to force a refresh of all the referencing bundles when the feature and its service implementation are replaced ? Thanks for your help. Regards. Le mer. 8 mars 2023 à 08:08, Maurice Betzel <[email protected]> a écrit : > > 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. > 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.
