Re: felix:persistentFactoryComponent
Thanks David, that's great information. Let me try to explain what I've witnessed in another way to see if that is something you would have expected: * When a factory component has a reference, which cannot be _immediately_ resolved at the moment of activation, it will fail. * However, when setting felix:persistentFactoryComponent="true" the component behaves as any other component which might have an unresolved reference, resulting in deferred activation only upon satisfaction of the reference. Would you consider that inline with the intent? (I certainly hope so :D because that's what I'm looking for.) Ray On Tue, Apr 25, 2023 at 11:54 AM David Jencks wrote: > This is my recollection from the distant past, it could be wrong in > several ways. > > IIRC if you have a factory component, when you call it to create a > component the properties are a mix of the factory component’s properties > and the ones you supply. > > Furthermore, the spec says if you change the factory component’s > properties, all the previously created instances are immediately disposed > of. If the manually created component instances are used as dependencies > this might not be what you want. > > So, IIRC, setting this property changes the behavior when you change the > factory properties so the created instances are not automatically disposed > of. > > I thought I’d documented all the non-standard behaviors I implemented, but > this certainly isn’t in the .md. > > David Jencks > > > On Apr 25, 2023, at 6:56 AM, Raymond Augé > wrote: > > > > Hello all, > > > > Could someone explain what it means to use > > > > felix:persistentFactoryComponent="true" > > > > As in: > > > > http://www.osgi.org/xmlns/scr/v1.1.0; > > > > xmlns:felix="http://felix.apache.org/xmlns/scr/extensions/v1.0.0;> > > > > > > > > > felix:persistentFactoryComponent="true" > > > > enabled="false" > > > > factory="factory.component.factory" > > > > > > > > > > > > > ... > > > > -- > > *Raymond Augé* (@rotty3000) > > Senior Software Architect *Liferay, Inc.* (@Liferay) > > OSGi Fellow, Java Champion > > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
felix:persistentFactoryComponent
Hello all, Could someone explain what it means to use felix:persistentFactoryComponent="true" As in: http://www.osgi.org/xmlns/scr/v1.1.0; xmlns:felix="http://felix.apache.org/xmlns/scr/extensions/v1.0.0;> ... -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
Re: repeated calls to Activator
My suspicion is that either:
A) you have the "shared" bundle's activator in an exported package, and it
is detected (from the classpath) as the activator (via an imported package)
in every other bundle (less likely).
B) every bundle that consumes the "shared" bundle dependency, is
accidentally slurping in the activator (package) and detecting it as its
own activator impl (more likely).
A test you could try to discover what's happening is to print the bundle
from the BundleContext passed to the activator `start(BundleContext)`
method and also the classloader of the BundleActivator instance being
called.
System.out.println("=> THE BUNDLE: " + bundleContext.getBundle());
System.out.println("=> THE CLASSLOADER: " +
getClass().getClassLoader());
We can take it from there.
On Fri, Sep 16, 2022 at 7:13 PM Chuck Davis wrote:
> I am attempting to refactor a project into bundles which number 16
> presently. I have a "base" bundle that all others depend on. The
> activator of that bundle is getting called for every other bundle that gets
> activated. Is this to be expected? It seems to me the framework should
> only call the activator a single time. I have been unsuccessful finding
> the reason and it means I cannot do setup in the activator because it gets
> called 15 times. Any insight would be helpful. Thanks.
>
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion
Re: Setting the Gogo shell to UTF-8?
If I had to guess it would have to do with processing pure bytes without considering encoding and hence multi-byte characters. I'd be willing to guess that's a fundamental implementation flaw potentially down to the telnet protocol itself. :( On Thu, Sep 15, 2022 at 3:46 AM David Leangen (OSGi) wrote: > Hi! > > I am having trouble using UTF-8 characters with the Gogo Shell. > > I have implemented a command “register” that takes a string argument. I > try to run it like this: > > g! register 何か漢字で書いてる言葉 > > The string gets parsed as "何㠋漢å—㠧書㠄㠦る言葉” instead of > “何か漢字で書いてる言葉”. Not even sure what encoding that is. > > I checked the stack trace in debug mode to ensure it wasn’t my code. It > seems to me that from the moment the text is input into the shell it gets > interpreted that way (all the way up the stack trace). > > I tried echo as well: > > > ``` > g! echo こんにちは > ã “ã‚“ã «ã ¡ã ¯ > ``` > > > I already checked out a few threads and tried those fixes, but no luck: > > * > https://stackoverflow.com/questions/361975/setting-the-default-java-character-encoding/623036 > * > https://stackoverflow.com/questions/8920712/osgi-bundle-doesnt-display-utf-8-characters > > > I updated my gogo shell to the latest available version on Maven Central. > > > Any other ideas about how I could resolve this issue? > > > Thanks! > =David > > > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
Re: Released Felix Logback version 1.0.6 to address Logback CVE-2021-44228
Alain, apologies for that. The only change is https://issues.apache.org/jira/browse/FELIX-6484 Sincerely, Ray On Tue, Dec 14, 2021 at 12:33 PM Alain Picard < apic...@benchmarkconsulting.com> wrote: > Not very friendly link > > Sorry, you can't view this page > > This page is only available to Jira Software users. If you think you should > be a Jira Software user, you should ask your administrator to give you > application access to Jira Software. > Alain > > > On Tue, Dec 14, 2021 at 12:23 PM Raymond Augé > wrote: > > > Hi, > > > > In order to address CVE-2021-44228 we've conducted a security release of > > Felix Logback 1.0.6 > > https://issues.apache.org/jira/projects/FELIX/versions/12351063 > > > > For your own protection please update your usages to the latest version. > > > > Sincerely, > > Ray > > > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
Released Felix Logback version 1.0.6 to address Logback CVE-2021-44228
Hi, In order to address CVE-2021-44228 we've conducted a security release of Felix Logback 1.0.6 https://issues.apache.org/jira/projects/FELIX/versions/12351063 For your own protection please update your usages to the latest version. Sincerely, Ray
Re: GoGo Command requires a runtime
Another option which is less ideal but useful if you have a strong reason not to make the gogo annotations import optional (maybe there are too many bundles to change or something) then you can tell bnd that certain capabilities (particularly ones which are `effective:=active`) are already provided during assembly resolution by adding the instruction in your bndrun files: ``` -runsystemcapabilities: org.apache.felix.gogo;org.apache.felix.gogo="shell.implementation";version:Version="1.0.0"; implementation.name="gogo.shell" ``` On Thu, Nov 4, 2021 at 9:17 AM Raymond Augé wrote: > So this is because of the imported package `org.apache.felix.gogo.command` > for the annotations right? > > Just make that import optional! > > On Thu, Nov 4, 2021 at 6:20 AM Alexander Broekhuis > wrote: > >> Hi all, >> >> Since a few releases GoGo uses a cap/req model to get a complete set of >> bundles (shell, runtime, command). While this makes sense in most cases, >> this introduces a new problem for us. When creating a component that >> implements some commands, it is now always coupled to the shell bundle as >> well. This adds (IMO) unneeded dependencies, which could have been >> optional. Eg when testing that component I now have to include the shell, >> which in turn requires the commands as well. This also requires me to >> update runconfigurations to use the nointeractive flag for a headless >> environment. >> >> Perhaps I'm overlooking something, but is there a clean way to solve this >> with the current gogo version? In previous versions I could just add the >> runtime and everything would resolve as expected. >> >> Thanks! >> >> -- >> Met vriendelijke groet, >> >> Alexander Broekhuis >> > > > -- > *Raymond Augé* (@rotty3000) > Senior Software Architect *Liferay, Inc.* (@Liferay) > OSGi Fellow, Java Champion > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
Re: GoGo Command requires a runtime
So this is because of the imported package `org.apache.felix.gogo.command` for the annotations right? Just make that import optional! On Thu, Nov 4, 2021 at 6:20 AM Alexander Broekhuis wrote: > Hi all, > > Since a few releases GoGo uses a cap/req model to get a complete set of > bundles (shell, runtime, command). While this makes sense in most cases, > this introduces a new problem for us. When creating a component that > implements some commands, it is now always coupled to the shell bundle as > well. This adds (IMO) unneeded dependencies, which could have been > optional. Eg when testing that component I now have to include the shell, > which in turn requires the commands as well. This also requires me to > update runconfigurations to use the nointeractive flag for a headless > environment. > > Perhaps I'm overlooking something, but is there a clean way to solve this > with the current gogo version? In previous versions I could just add the > runtime and everything would resolve as expected. > > Thanks! > > -- > Met vriendelijke groet, > > Alexander Broekhuis > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
Re: Enforcing mandatory components for an application
I don't think "readiness" is something you completely do inside an app to begin with. (assist with? sure!) This is why I proposed Condition Service; to model the details required for your application to be "ready", hoist that into an externally visible (to the java process) indicator (an open socket, REST endpoint, marker file) and THEN that can be used by any external readiness checker with whatever business logic. Apologies if my recommendation was unclear. But you're likely to have an orchestrator performing liveness/readiness checking anyway, why even try to model that entirely inside the application?!? - Ray
Re: Enforcing mandatory components for an application
Hello Robert, You probably want to use the DS support [1] for the **NEW** _Condition Service Specification_ which was added in OSGi Compendium R8 (currently in the release process). You can try this out with the current 2.2.0-RC1 of Felix SCR [2] on Maven Central. The Condition Service Specification lets you model your application conditions (as the name implies) using OSGi service filters. [1] https://osgi.github.io/osgi/cmpn/service.component.html#service.component-satisfying.condition [2] https://search.maven.org/artifact/org.apache.felix/org.apache.felix.scr/2.2.0-RC1/bundle On Tue, Oct 12, 2021 at 5:50 AM Robert Munteanu wrote: > Hi, > > I have written a couple of small OSGi apps where if a single top-level > DS component, let's call it T, cannot start then the application should > shut down immediately. One example are HTTP services where the HTTP > server port cannot be bound to. > > The causes of failures I have seen are: > - T activation fails > - the bundle providing T fails to resolve > - a dependency of T fails activation > - a dependency of T cannot be provided because the bundle providing it > failed to staret > > I can think of several ways of approaching the problem, but none of > them perfect: > - using the Felix Health Checks[1], that seems wrong since it's a > polling-based approach and we very likely know when a dependency fails > and stop immediately > - using the SCR introspection API [2], which is again based on polling > - waiting for the framework to start and then looking up the service; > but we don't know when the SCR has 'settled' > > Are there any patterns or libraries that I can use to approach this > problem? > > Thanks, > Robert > > [1]: > > https://felix.apache.org/documentation/subprojects/apache-felix-healthchecks.html > [2]: > https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-introspection > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
Re: OSGi On Kubernetes: Apache Felix FTW
Thanks for the feedback JB :D - Ray On Mon, Jun 14, 2021 at 12:44 PM JB Onofré wrote: > Thanks for sharing ! > > FYI with Karaf we mostly use ConfigMap to push config (pretty similar). > > Regards > JB > > > Le 14 juin 2021 à 18:41, Raymond Augé > a écrit : > > > > Hello everyone, > > > > Please enjoy a post I've made which prominently highlights Apache > > Felix/OSGi solutions to enable tight configuration integration for OSGi > on > > Kubernetes. > > > > https://rotty3000.doublebite.com/OSGi-On-Kubernetes-Configuration/ > > > > (there are no ads, no product marketing, rather more of a thanks to all > who > > contribute to Apache Felix and OSGi in general keeping the OSGi community > > in the game in terms of "modern application development".) > > > > Thanks, > > > > -- > > *Raymond Augé* (@rotty3000) > > Senior Software Architect *Liferay, Inc.* (@Liferay) > > OSGi Fellow, Java Champion > > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
OSGi On Kubernetes: Apache Felix FTW
Hello everyone, Please enjoy a post I've made which prominently highlights Apache Felix/OSGi solutions to enable tight configuration integration for OSGi on Kubernetes. https://rotty3000.doublebite.com/OSGi-On-Kubernetes-Configuration/ (there are no ads, no product marketing, rather more of a thanks to all who contribute to Apache Felix and OSGi in general keeping the OSGi community in the game in terms of "modern application development".) Thanks, -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
