Hello. Time has passed since our last messages, but our issue is still the same. So I will try again in case someone else has a new idea...
We still have the same behavior in our real applications bundles : replacing a service (removing/adding the feature repository that provides the bundle), makes all the service references invalid. In a POC project, with similar features, doing the same works as expected. Why does it work in some cases, and fails in other cases ? Can we hope for some solution to force a refresh (with some Karaf command) of all the changed service references ? Thanks again. Regards. Le jeu. 9 mars 2023 à 09:19, Maurice Betzel <[email protected]> a écrit : > > 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. >
