Jitsi custom OSGi classloader issues: fix way bundles are loaded in launcher

I seem to run into classloader-related issues if I build and run the Jitsi code-base as-is.
I don't know if that's an error of how I run it, but this simple fix solves significant issues for me. (@ibauersachs do you know?)
There's some other minor changes.

What's the issue you encounter?
The mainWithCl stuff is necessary so that native bundles are properly loaded IIRC.

What's the issue you encounter?

spellchecker bundle fails to load successfully, prevents GUI from loading because the spellchecker UI component fails.
If I create an XMPP account, then connect it, it fails to load due to an issue with StaxXMLParser. (See stack trace below.)

My theory was (eventually) that this might be a conflict of classloaders, because the type is a subtype. Given that (1.) also occurred. I already tried things like explicitly adding dependency on the Xml-artifact (without '-stax' suffix). I looked into OSGi. Found your advice to someone about using Spifly, but didn't help. Then found the custom loading in the launcher.
2023-05-28 23:27:39.703 [DEBUG] [ForkJoinPool.commonPool-worker-3] net.java.sip.communicator.impl.protocol.jabber.JabberActivator - Got service UIServiceImpl, starting now
2023-05-28 23:27:39.703 [INFO ] [ForkJoinPool.commonPool-worker-1] net.java.sip.communicator.plugin.advancedconfig.AdvancedConfigurationPanel - Handling registration of a new Configuration Form.
2023-05-28 23:27:39.752 [ERROR] [ForkJoinPool.commonPool-worker-3] org.jitsi.impl.osgi.framework.launch.EventDispatcher - Error dispatching event
java.util.ServiceConfigurationError: org.jivesoftware.smack.xml.XmlPullParserFactory: org.jivesoftware.smack.xml.stax.StaxXmlPullParserFactory not a subtype
	at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1244)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
	at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
	at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
	at org.jivesoftware.smack.xml.SmackXmlParser.getXmlPullParserFactory(SmackXmlParser.java:40)
	at org.jivesoftware.smack.xml.SmackXmlParser.newXmlParser(SmackXmlParser.java:65)
	at org.jivesoftware.smack.util.PacketParserUtils.getParserFor(PacketParserUtils.java:80)
	at org.jivesoftware.smack.SmackInitialization.processConfigFile(SmackInitialization.java:159)
	at org.jivesoftware.smack.SmackInitialization.processConfigFile(SmackInitialization.java:154)
	at org.jivesoftware.smack.SmackInitialization.<clinit>(SmackInitialization.java:103)
	at org.jivesoftware.smack.Smack.getVersion(Smack.java:38)
	at org.jivesoftware.smack.Smack.ensureInitialized(Smack.java:64)
	at org.jivesoftware.smack.provider.ProviderManager.<clinit>(ProviderManager.java:125)
	at org.jitsi.xmpp.extensions.jingle.JingleIQProvider.<init>(JingleIQProvider.java:48)
	at net.java.sip.communicator.impl.protocol.jabber.ProviderManagerExt.load(ProviderManagerExt.java:50)
	at net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderFactoryJabberImpl.<init>(ProtocolProviderFactoryJabberImpl.java:54)
	at net.java.sip.communicator.impl.protocol.jabber.JabberActivator.startWithServices(JabberActivator.java:174)
	at net.java.sip.communicator.util.osgi.DependentActivator.addingService(DependentActivator.java:103)
	at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
	at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
	at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
	at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
	at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
	at org.jitsi.impl.osgi.framework.launch.EventDispatcher$Command.run(EventDispatcher.java:121)
	at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1395)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)

The mainWithCl stuff is necessary so that native bundles are properly loaded IIRC.

Just to check, did you notice that the logic in mainWithCl is still present, just moved to main? I just removed the invoking-with-bundle-classloader logic. From what I can tell, when the framework gets initialized, it already takes into account that it gets passed in a plain classloader and seems to operate fine regardless.
To clarify, to run I do: mvn clean verify -DskipTests; java -cp 'lib/:target/bundles/*' net.java.sip.communicator.launcher.Jitsi and that's when the above happens.

Converted to draft: I made a bad assumption on part of the spellchecker, i.e. it's still broken. I want to double-check everything first.

The launcher classpath was missing the entire xmpp-package. Doh.
I've pushed some fixes and I could connect to a local OpenFire server with them. But I didn't try the spellchecking yet. Not surprised if there are errors left from the conversion of real OSGi to the simpler/fake jitsi-osgi.
The changes you made in the main class don't work: the point of the reflective invocation of mainWithCl is that the actual startup is already made from an OSGi classloader. Resource loading , the launch arguments, and other stuff will otherwise break.

The launcher classpath was missing the entire xmpp-package. Doh. I've pushed some fixes and I could connect to a local OpenFire server with them. But I didn't try the spellchecking yet. Not surprised if there are errors left from the conversion of real OSGi to the simpler/fake jitsi-osgi.

Sure, it makes things a bit more fragile, but at the same time the code does not demand very exotic features.
It is curious: you say that you need to add the XMPP packages to the launcher dependencies? That shouldn't be necessary, as you would expect one of Jitsi's XMPP packages to load anything necessary as dependent package. (I.e. not directly a jitsi feature, therefore need not be available.)
My line of reasoning was that the framework internally already tackles the necessary parts for "installing bundles", etc., therefore wrapping with BundleClassLoader is unnecessary.

The changes you made in the main class don't work: the point of the reflective invocation of mainWithCl is that the actual startup is already made from an OSGi classloader. Resource loading , the launch arguments, and other stuff will otherwise break.

I am not surprised to hear this. Still, for me, the classloading issues that I had previously, disappeared. I understand that it does not start with the BundleClassLoader as a root classloader. That's why the manual, reflective invocation was necessary. Using actual classloader + specifying same classloader in reflections was enough for me.
It's curious. I'm going to have another look.

It's not Smack that was missing, but the entire protocol-jabber project. This is a fully optional part, just like SIP or IRC. You probably didn't notice this as the project was built nonetheless and adding bundles/* to the classpath in the script actually made it available. But it wasn't as part of the Maven classpath of the launcher submodule.
Bundle loading is indeed done within the 'framework', but the LaunchArgs would then be in a different classloader than the bundles that need it. Plus the other stuff with resources, native libs, etc. I can't remember all the details as it's been a while, but I know it solved more problems than it created.
Actually, I'd like to get rid of all OSGi stuff that's beyond the service registry.

It's not Smack that was missing, but the entire protocol-jabber project. This is a fully optional part, just like SIP or IRC. You probably didn't notice this as the project was built nonetheless and adding bundles/* to the classpath in the script actually made it available. But it wasn't as part of the Maven classpath of the launcher submodule.

Ah, right! That also makes sense in my understanding of it. :-P

Right, checked.

Bundle loading is indeed done within the 'framework', but the LaunchArgs would then be in a different classloader than the bundles that need it. Plus the other stuff with resources, native libs, etc. I can't remember all the details as it's been a while, but I know it solved more problems than it created.

I prly will have a look at this, if only to see if I understand how it works.

The FrameworkImpl functions as the "root bundle". When the classloader is included in a bundle-to-be-installed, it is always wrapped in a BundleClassLoader. I have adapted the reflections function-calls to include the same classloader. (My intuition/educated guess is that the BundleClassLoader exists primarily to compartmentalize the loaded classes, such that service-loading actions are possible. Then the root classloader - part of framework - does not strictly need wrapped.)

Spellchecker fixed. (See 486ebaa33759cbf48adbd7af96c45dfee3b19fde.)

Let me know if you guys are even interested in any improvements. I fully understand if focus is on other things. I just want to avoid others spending the same time fixing the same issues.

Let me know if you guys are even interested in any improvements. I fully understand if focus is on other things. I just want to avoid others spending the same time fixing the same issues.

Anything that gets stuff working again is welcome. Preferably in small chunks as I'm currently not working a lot on it and if I can click merge on GitHub mobile it's off everybody's mind ;-)

Why not to merge directly this PR?

The review comments were valid. I have not made time to fix those. I plan to pick this up but have been delaying. I will (probably) make a new PR when the changes have been made.
On July 19, 2023 5:46:54 PM UTC, Neustradamus @.***> wrote:

Why not to merge directly this PR?
--
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/pull/801#issuecomment-1642501996
You are receiving this because you authored the thread.
Message ID: @.***>

@ibauersachs I investigated myself and have these findings. I cannot confirm your claim that the AppClassLoader is used directly. These results correspond with my earlier claim. See steps below.

set breakpoint in OtrActivator.
when on breakpoint, move up the stack to FrameworkStartLevelImpl$Command. (See first code-snippet below.)
in memory-outline to the right for selected stack frame:

expand this,
expand this$0,
expand bundles,
expand 0 + 1 + 1/bundleActivators + 1/classLoader + 2 + 2/bundleActivators + 2/classLoader

this should roughly represent the second code snippet.
observe:

First entry (i.e. 0) is the Framework, with the classloader {ClassLoaders$AppClassLoader@3790}, as expected.
Second entry is bundle, in this case "net.java.sip.communicator.launcher.ShutdownTimeout", "net.java.sip.communicator.argdelegation.ArgDelegationActivator".
Second entry classloader is '{BundleClassLoader@4996}' with parent '{ClassLoaders$AppClassLoader@3790}`, i.e. the framework classloader, as expected.
Same for third entry (second bundle) and fourth entry (third bundle), etc.

<init>:124, OtrActivator (net.java.sip.communicator.plugin.otr)
newInstance0:-1, NativeConstructorAccessorImpl (jdk.internal.reflect)
newInstance:77, NativeConstructorAccessorImpl (jdk.internal.reflect)
newInstance:45, DelegatingConstructorAccessorImpl (jdk.internal.reflect)
newInstanceWithCaller:499, Constructor (java.lang.reflect)
newInstance:480, Constructor (java.lang.reflect)
start:467, BundleImpl (org.jitsi.impl.osgi.framework)
startLevelChanged:493, FrameworkImpl (org.jitsi.impl.osgi.framework.launch)
run:133, FrameworkStartLevelImpl$Command (org.jitsi.impl.osgi.framework.startlevel)
exec:1395, ForkJoinTask$RunnableExecuteAction (java.util.concurrent)
doExec$$$capture:373, ForkJoinTask (java.util.concurrent)
doExec:-1, ForkJoinTask (java.util.concurrent)
topLevelExec:1182, ForkJoinPool$WorkQueue (java.util.concurrent)
scan:1655, ForkJoinPool (java.util.concurrent)
runWorker:1622, ForkJoinPool (java.util.concurrent)
run:165, ForkJoinWorkerThread (java.util.concurrent)

this = {FrameworkStartLevelImpl$Command@3839}
 listeners = {FrameworkListener[1]@3837}
 startLevel = 3
 this$0 = {FrameworkStartLevelImpl@3814}
  framework = {FrameworkImpl@3820}
   logger = {Logger@3824}
   bundles = {LinkedList@3825}  size = 86
    0 = {FrameworkImpl@3820}
     logger = {Logger@3824}
     bundles = {LinkedList@3825}  size = 86
     configuration = {ImmutableCollections$Map1@3826}  size = 1
     eventDispatcher = {EventDispatcher@3827}
     frameworkStartLevel = {FrameworkStartLevelImpl@3814}
     nextBundleId = 86
     nextServiceId = 25
     serviceRegistrations = {LinkedList@3828}  size = 24
     stopEvent = {Object@3829}
     frameworkListeners = {Collections$SynchronizedRandomAccessList@3830}  size = 0
     bundleActivatorClasses = {ArrayList@3831}  size = 0
     bundleActivators = {ArrayList@3832}  size = 0
     headers = {Hashtable@3833}  size = 1
     bundleContext = {BundleContextImpl@3834}
     bundleId = 0
     bundleStartLevel = {BundleStartLevelImpl@3835}
     framework = null
     location = "file:/home/dev-otr/.m2/repository/org/jitsi/jitsi-android-osgi/2.0-3-gd59644a/jitsi-android-osgi-2.0-3-gd59644a.jar"
     classLoader = {ClassLoaders$AppClassLoader@3790}
     state = 8
    1 = {BundleImpl@4906}
     bundleActivatorClasses = {ArrayList@4990}  size = 2
      0 = {Class@2331} "class net.java.sip.communicator.launcher.ShutdownTimeout"
      1 = {Class@2334} "class net.java.sip.communicator.argdelegation.ArgDelegationActivator"
     bundleActivators = {ArrayList@4991}  size = 2
     headers = {Hashtable@4992}  size = 1
     bundleContext = {BundleContextImpl@4993}
     bundleId = 1
     bundleStartLevel = {BundleStartLevelImpl@4994}
     framework = {FrameworkImpl@3820}
     location = "file:/home/dev-otr/dev/jitsi/modules/launcher/target/classes/"
     classLoader = {BundleClassLoader@4996}
      parent = {ClassLoaders$AppClassLoader@3790}
      nativeLibraries = {HashMap@4997}  size = 0
      nativeLibTempDir = null
      ucp = {URLClassPath@4998}
      acc = {AccessControlContext@4999}
      closeables = {WeakHashMap@5000}  size = 0
      pdcache = {ConcurrentHashMap@5001}  size = 0
      ClassLoader.parent = null
      name = null
      unnamedModule = {Module@5002} "unnamed module @145aa870"
      nameAndId = "org.jitsi.impl.osgi.framework.BundleClassLoader @15d49048"
      parallelLockMap = null
      package2certs = {ConcurrentHashMap@5004}  size = 0
      classes = {ArrayList@5005}  size = 0
      defaultDomain = {ProtectionDomain@5006} "ProtectionDomain  (null <no signer certificates>)\n org.jitsi.impl.osgi.framework.BundleClassLoader@15d49048\n <no principals>\n java.security.Permissions@686fd5f0 (\n ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans.*")\n ("java.lang.RuntimePermission" "accessClassInPackage.com.apple.*")\n ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.java.swing.plaf.*")\n ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans")\n ("java.util.PropertyPermission" "java.specification.version" "read")\n ("java.util.PropertyPermission" "java.vm.vendor" "read")\n ("java.util.PropertyPermission" "path.separator" "read")\n ("java.util.PropertyPermission" "os.version" "read")\n ("java.util.PropertyPermission" "java.vendor.url" "read")\n ("java.util.PropertyPermission" "java.vm.name" "read")\n ("java.util.PropertyPermission" "java.vm.specification.version" "read")\n ("java.util.PropertyPermission" "os.name" "read")\n ("java.util.PropertyPermission" "java.version" "read")\n ("java.ut"
      packages = {ConcurrentHashMap@5007}  size = 0
      libraries = {NativeLibraries@5008}
      assertionLock = {BundleClassLoader@4996}
      defaultAssertionStatus = false
      packageAssertionStatus = null
      classAssertionStatus = null
      classLoaderValueMap = null
     state = 32
    2 = {BundleImpl@4907}
     bundleActivatorClasses = {ArrayList@5014}  size = 1
     bundleActivators = {ArrayList@5015}  size = 1
      0 = {NimbuzzAvatarsActivator@5022}
     headers = {Hashtable@5016}  size = 1
     bundleContext = {BundleContextImpl@5017}
     bundleId = 2
     bundleStartLevel = {BundleStartLevelImpl@5018}
     framework = {FrameworkImpl@3820}
     location = "file:/home/dev-otr/dev/jitsi/modules/plugin/nimbuzzavatars/target/classes/"
     classLoader = {BundleClassLoader@5020}
      parent = {ClassLoaders$AppClassLoader@3790}
      nativeLibraries = {HashMap@5023}  size = 0
      nativeLibTempDir = null
      ucp = {URLClassPath@5024}
      acc = {AccessControlContext@5025}
      closeables = {WeakHashMap@5026}  size = 0
      pdcache = {ConcurrentHashMap@5027}  size = 0
      ClassLoader.parent = null
      name = null
      unnamedModule = {Module@5028} "unnamed module @40dd4c21"
      nameAndId = "org.jitsi.impl.osgi.framework.BundleClassLoader @a8ef162"
      parallelLockMap = null
      package2certs = {ConcurrentHashMap@5030}  size = 0
      classes = {ArrayList@5031}  size = 0
      defaultDomain = {ProtectionDomain@5032} "ProtectionDomain  (null <no signer certificates>)\n org.jitsi.impl.osgi.framework.BundleClassLoader@a8ef162\n <no principals>\n java.security.Permissions@28b3ea15 (\n ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans.*")\n ("java.lang.RuntimePermission" "accessClassInPackage.com.apple.*")\n ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.java.swing.plaf.*")\n ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans")\n ("java.util.PropertyPermission" "java.specification.version" "read")\n ("java.util.PropertyPermission" "java.vm.vendor" "read")\n ("java.util.PropertyPermission" "path.separator" "read")\n ("java.util.PropertyPermission" "os.version" "read")\n ("java.util.PropertyPermission" "java.vendor.url" "read")\n ("java.util.PropertyPermission" "java.vm.name" "read")\n ("java.util.PropertyPermission" "java.vm.specification.version" "read")\n ("java.util.PropertyPermission" "os.name" "read")\n ("java.util.PropertyPermission" "java.version" "read")\n ("java.uti"
      packages = {ConcurrentHashMap@5033}  size = 0
      libraries = {NativeLibraries@5034}
      assertionLock = {BundleClassLoader@5020}
      defaultAssertionStatus = false
      packageAssertionStatus = null
      classAssertionStatus = null
      classLoaderValueMap = null
     state = 32
    3 = {BundleImpl@4908}
     bundleActivatorClasses = {ArrayList@5037}  size = 1
     bundleActivators = {ArrayList@5038}  size = 1
      0 = {HIDActivator@5045}
     headers = {Hashtable@5039}  size = 1
     bundleContext = {BundleContextImpl@5040}
     bundleId = 3
     bundleStartLevel = {BundleStartLevelImpl@5041}
     framework = {FrameworkImpl@3820}
     location = "file:/home/dev-otr/dev/jitsi/modules/impl/hid/target/classes/"
     classLoader = {BundleClassLoader@5043}
      parent = {ClassLoaders$AppClassLoader@3790}
      nativeLibraries = {HashMap@5046}  size = 0
      nativeLibTempDir = null
      ucp = {URLClassPath@5047}
      acc = {AccessControlContext@5048}
      closeables = {WeakHashMap@5049}  size = 0
      pdcache = {ConcurrentHashMap@5050}  size = 0
      ClassLoader.parent = null
      name = null
      unnamedModule = {Module@5051} "unnamed module @3ee56aa6"
      nameAndId = "org.jitsi.impl.osgi.framework.BundleClassLoader @2eea88a1"
      parallelLockMap = null
      package2certs = {ConcurrentHashMap@5053}  size = 0
      classes = {ArrayList@5054}  size = 0
      defaultDomain = {ProtectionDomain@5055} "ProtectionDomain  (null <no signer certificates>)\n org.jitsi.impl.osgi.framework.BundleClassLoader@2eea88a1\n <no principals>\n java.security.Permissions@7f3d5c22 (\n ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans.*")\n ("java.lang.RuntimePermission" "accessClassInPackage.com.apple.*")\n ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.java.swing.plaf.*")\n ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans")\n ("java.util.PropertyPermission" "java.specification.version" "read")\n ("java.util.PropertyPermission" "java.vm.vendor" "read")\n ("java.util.PropertyPermission" "path.separator" "read")\n ("java.util.PropertyPermission" "os.version" "read")\n ("java.util.PropertyPermission" "java.vendor.url" "read")\n ("java.util.PropertyPermission" "java.vm.name" "read")\n ("java.util.PropertyPermission" "java.vm.specification.version" "read")\n ("java.util.PropertyPermission" "os.name" "read")\n ("java.util.PropertyPermission" "java.version" "read")\n ("java.ut"
      packages = {ConcurrentHashMap@5056}  size = 0
      libraries = {NativeLibraries@5057}
      assertionLock = {BundleClassLoader@5043}
      defaultAssertionStatus = false
      packageAssertionStatus = null
      classAssertionStatus = null
      classLoaderValueMap = null
     state = 32
[..]

I don't know what exactly you tried, but it doesn't work. What you show in the stacktrace and inspection is a field on BundleImpl, which doesn't represent the actually used classloader. If you expand bundleActivatorClasses/0/classLoader you'll see the actual classloader of the activators.
Or easier, while still in OtrActivator, just inspect getClass().getClassLoader().
Via Reflection:

Your suggested change:

I don't know what exactly you tried, but it doesn't work. What you show in the stacktrace and inspection is a field on BundleImpl, which doesn't represent the actually used classloader. If you expand bundleActivatorClasses/0/classLoader you'll see the actual classloader of the activators.

Confirmed.

Or easier, while still in OtrActivator, just inspect getClass().getClassLoader(). Edit: for the record, this is on JDK 11.0.20 (Temurin).

JDK versions shouldn't matter. Regardless, same outcome for me.

Okay, I am not sure we have the same goal in mind. And I think the discussion essentially becomes: "how is OSGi supposed to work?"
Your suggested change would result in all bundles being loaded in the same BundleClassLoader instance, as well as the application. I think your goal is to have all bundles in separate BundleClassLoaders, essentially what installBundle does, but also for all the classes/types. However, that would mean you cut off access to the types from the Jitsi framework/application itself.
My suggestion loads the types of the direct dependencies, i.e. what Jitsi works with, in the AppClassLoader, and provides a BundleContext with isolated classloader for dependencies to be installed in. All services offered by the BundleContext should use their own classloader.
At this point, my question is whether the suggested wrapping of AppClassLoader with a single BundleClassLoader makes a different (i.e. is or is not redundant), as:

your suggestion would still have a combined: Jitsi Framework + all bundles types.
how much class isolation do you want to achieve?

Additionally, the issue might start earlier:
We currently use reflections to search for the classes, then we figure out the file path, and then we "pretend" to install it anew. However, the classloader has already touched it at this point. (Hence Jitsi + all bundles in single BundleClassLoader.)
If this is the issue, we should search by filename and install that way, such that the classloader doesn't touch/initialize.
Right now, I run into a combination of limitations to understanding OSGi and confusing statements/results from what is happening in the Jitsi code: either the current code does not achieve the result you have in mind, or both suggestions achieve same nett outcome.

The goal is to get rid of OSGi as much as possible. However, since the whole application very deepöy relies on it, it's next to impossible, at least for the service registry.
Why?
Many dependencies do not have the required manifest, are broken or become randomly broken in an update. Working with native Java mechanism lile ServiceLoader is a pain.  IDE support is minimal. Setup is a pain.
The reason for all the foo with the filenames is because it's currently required to launch Jitsi and not throwing NPEs.
The classloader-per-bundle isolation is not required in Jitsi, if I wanted that, Felix would still be the framework not the current fake.
The only reason BundleClassLoader exists at all is for the native libraries as explained in a previous comment.
That could go away too if you go over all jars of the classpath, extract all natives like the BundleClassLoader would into a directory that is on java.library.path (that could even be done at build time).
What's your goal?

What's your goal?

Fix the code-base such that we can reliably build jitsi without needing to investigate and/or make changes to the code. Possibly add some error handling to prevent whole application from crashing/hanging/... when something is missing. (Such as in my case the issue with spellchecker.) I wanted to upstream the changes that I needed to make, and in the proper way, hence the discussion right now. Such that when someone checks out the codebase next, they will be able to get started immediately.
I think we were aligned on everything except the reflection/OSGi loading stuff. And, because it seems like we're contradicting each-other, I want(ed) to figure out how/what/why.
It's also why I checked whether or not the contributions are still wanted. (Not trying to revisit this question, just stating motivation.)

What's your goal?

Fix the code-base such that we can reliably build jitsi without needing to investigate and/or make changes to the code. Possibly add some error handling to prevent whole application from crashing/hanging/... when something is missing. (Such as in my case the issue with spellchecker.) I wanted to upstream the changes that I needed to make, and in the proper way, hence the discussion right now. Such that when someone checks out the codebase next, they will be able to get started immediately.

That's precisely why I got rid of the real OSGi framework, Felix. E.g. no more manual Import-Package/Export-Package fiddling. No more repackaging of non-OSGified libs from Maven.

I think we were aligned on everything except the reflection/OSGi loading stuff. And, because it seems like we're contradicting each-other, I want(ed) to figure out how/what/why.

The reflection stuff in Main, ugly as it is, makes everything much simpler.

It's also why I checked whether or not the contributions are still wanted. (Not trying to revisit this question, just stating motivation.)

They are. But hopefully it's obvious that I request on stuff that doesn't work.

Aha! Now I get what you're talking about. :-P The library-loading has been sprinkled with magic fairy dust. BundleClassLoader#findLibrary makes native libraries available/accessible upon searching for them.
So, basically, my understanding of OSGi is correct, but the code relies on an additional benefit that we rely on.
if (OSUtils.class.getClassLoader().getClass().getName().contains("Bundle")) {
    loadLibrary = (libname, clazz) -> {
        System.loadLibrary(libname);
    };
} else {
    loadLibrary = JNIUtils::loadLibrary;
}

Aha! Now I get what you're talking about. :-P The library-loading has been sprinkled with magic fairy dust.

That magic fairy dust is what a OSGi framework normally does: https://github.com/apache/felix-dev/blob/e75de7154a69f03bf87a5024ddca414da1fcc8c9/framework/src/main/java/org/apache/felix/framework/BundleWiringImpl.java#L2481

BundleClassLoader#findLibrary makes native libraries available/accessible upon searching for them. Most of the native libraries are loaded in the static initializer, so we cannot benefit from the bundle initialization itself.

The static initializer has nothing to do with bundle initialization. The only way to catch System.loadLibrary and provide a custom location after JVM startup (without reflection) is a custom classloader. If you know of anything else: awesome!

So, basically, my understanding of OSGi is correct, but the code relies on the adapted native-library-loading provided in the BundleClassLoader. (I know that's what you said, but not with sufficient detail for it to make sense to me in terms of how we are restricted.)

I probably assumed you still know all that stuff from back in the days™...

Aha! Now I get what you're talking about. :-P The library-loading has been sprinkled with magic fairy dust.

That magic fairy dust is what a OSGi framework normally does: https://github.com/apache/felix-dev/blob/e75de7154a69f03bf87a5024ddca414da1fcc8c9/framework/src/main/java/org/apache/felix/framework/BundleWiringImpl.java#L2481

Sure, except it was not obvious how to reconcile the two notions of "getting rid of the full-blown OSGi runtime" and "we need to do this manual thing to get the OSGi to work correctly". They seemed contradictory, as the classloader makes a significant difference while the OSGi framework was not bothered in the least.

BundleClassLoader#findLibrary makes native libraries available/accessible upon searching for them. Most of the native libraries are loaded in the static initializer, so we cannot benefit from the bundle initialization itself.

The static initializer has nothing to do with bundle initialization. The only way to catch System.loadLibrary and provide a custom location after JVM startup (without reflection) is a custom classloader. If you know of anything else: awesome!

The Java run-time leaves almost no wiggle-room. This also involves libjitsi which is shared among products IIUC, so I am not going to go there.

So, basically, my understanding of OSGi is correct, but the code relies on the adapted native-library-loading provided in the BundleClassLoader. (I know that's what you said, but not with sufficient detail for it to make sense to me in terms of how we are restricted.)

I probably assumed you still know all that stuff from back in the days™...

You know, I asked myself the same thing. I remember there being the directory with some native libs, and Felix's loading list for bundles. I may have been actively involved just before the switch to embedded native binaries, or I just encountered the unbundled ones.

I reverted the classloader changes. If you still want to merge because of the pom-change, prly better to squash it :-D ... or drop the PR. I leave it to you.

The Java run-time leaves almost no wiggle-room. This also involves libjitsi which is shared among products IIUC, so I am not going to go there.

libjitsi is now only used by Jitsi and Jigasi. Both use jitsi-android-osgi and would benefit from simplification. Also, libjitsi just calls System.loadLibrary, so as long as this works, it's fine.

I probably assumed you still know all that stuff from back in the days™...

You know, I asked myself the same thing. I remember there being the directory with some native libs, and Felix's loading list for bundles.

The list of natives in libs/ were the ones built from within Jitsi's source, and when libjitsi didn't exist yet. The loading list of bundles is something I got rid of since the great repacking since ~2019.

I may have been actively involved just before the switch to embedded native binaries, or I just encountered the unbundled ones.

The split to libjitsi started the bundling, although still with locally-compiled and committed binaries.

The Java run-time leaves almost no wiggle-room. This also involves libjitsi which is shared among products IIUC, so I am not going to go there.

libjitsi is now only used by Jitsi and Jigasi. Both use jitsi-android-osgi and would benefit from simplification. Also, libjitsi just calls System.loadLibrary, so as long as this works, it's fine.

FYI, I traced the loading process. System.loadLibrary is influenced by ClassLoader.findLibrary and even then with some imposed limits. That's how BundleClassLoader is able to do what it does. So going back to the original classloader means you'd need to ensure the native binaries are available/locatable on the file-system. Simplification would be easy enough, as long as any users of libjitsi (in this particular case) can handle having the native libraries outside the jar-file.
Write your own, and you can do all the weird things you want, as long as you can adhere to the restrictions imposed. From my quick look and from memory, the restrictions are roughly:
After having called ClassLoader.findLibrary, you must have the library available and accessible on an absolute filesystem path. (And if libname is an absolute path itself, it will immediately load therefore skip ClassLoader.findLibrary.)


Filter for corpus Sahidica.1cor produces inaccurate results

Chapter 1 is missing from the document result list.

This is related to the sahidica.mark metadata value in ANNIS from https://github.com/CopticScriptorium/cts/issues/71.
(reference http://corpling.uis.georgetown.edu/annis-service/annis/meta/doc/sahidica.1corinthians/1Cor_01)

metadata is incorrect -- needs to be changed.

fixed metadata -- ready for republication and re-ingest.


[Add]  new link for Images subcategory

Site URL
https://create.vista.com/de/
Description of the above provided site
VistaCreate is a free graphic design tool with thousands of free templates.
Category
Frontend
Sub Category
Images
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)
[X] I am participating in Hacktoberfest 2023

You've been assigned @Dea314! :) Please keep the following in mind as you make your PR:

Create a separate branch with Git before you push your commits. If you need help with this, check out this article, How to Create a Local Branch in Git
Follow the directions in the PR template to fill it out completely. If you need more tips, check out the blog post, Writing Your First Pull Request: Tips, Best Practices, and AI-Powered Tools for Success

@CBID2 can you pls assign this issue to me

@CBID2 can you pls assign this issue to me

Sorry @chinmay7016. @Dea314 expressed interest in doing this contribution

@chinmay7016
Are you interested in contributing?
@Dea314
You are not interested, right.

I'm closing this issue due to inactivity. Please feel free to reopen it if you'd like to contribute or have further discussions.


GD-35: Add a example project

Why
We want to show how to use the gdUnit4 C# API in a project. Using the NuGet packages as reference in your project

dismiss


tbb linking for embree broken under superbuild

Hello,
Under OSPRay v 2.7.0 (sha a783bf9), when using the superbuild on TACC Frontera (CentOS 7.8.2003), the superbuild fails to link Embree against the oneAPI TBB download, as many symbols are left undefined by the oneAPI TBB. See attached CMakeCache.txt and the link error output.
As perhaps a second issue, turning off TBB download in the superbuild is an insufficient fix, since the superbuild does not allow the user to specify the TBB location. On our systems, TBB is installed in a non-standard location and needs to be specified to be found.
I was able to build this version of OSPRay successfully by downloading each dependency independently and managing the dependencies within each package's respective cmake config.
All best,
Paul
CMakeCache.txt
make.out.zip

Hi Paul,
I'm able to reproduce this issue, it seems like when the intel module is loaded on TACC there's some conflict at link time between the TBB provided by the 2019 module (which is too old) vs. the one we're actually supposed to be linking with that was downloaded in the superbuild (2021.3). I am able to build if I unload the intel module, but that's not a great option since then you lose access to Intel MPI, and we should be able to find/link the right TBB even when the system has a different one installed.
We'll look into this more and let you know when we find a resolution.

Great sleuthing, Will! Thanks for the update. Perhaps there are additional CMake vars that can be used to avoid the conflict.
All best,
Paul
On Sep 13, 2021, at 12:21 PM, Will Usher<EMAIL_ADDRESS>wrote:
Hi Paul,
I'm able to reproduce this issue, it seems like when the intel module is loaded on TACC there's some conflict at link time between the TBB provided by the 2019 module (which is too old) vs. the one we're actually supposed to be linking with that was downloaded in the superbuild (2021.3). I am able to build if I unload the intel module, but that's not a great option since then you lose access to Intel MPI, and we should be able to find/link the right TBB even when the system has a different one installed.
We'll look into this more and let you know when we find a resolution.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/ospray/ospray/issues/490#issuecomment-918407545, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAI74G3FBK5ZGWYYLEE3WBDUBYXKVANCNFSM5DLZCECQ.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

fixed in 5d88a8cd84268c07ec7632bd6a4a2e71f5c377b6, patch release coming within the next days

@pnav we need to revert the workaround in 5d88a8c, because it creates too many side-effects (e.g., rebuilding the superbuild a 2nd time does not work). You could still apply it to compile on TACC. Additionally, we are also looking for less intrusive solutions.

Needs to be fixed in TACC's build environment.


Unable to launch AITrack when Windows Defender ASR rule is enabled

Attack Surface Reduction rule c1db55ab-c21a-4637-bb3f-a12568109d35 (Use advanced protection against ransomware) is blocking AITrack.exe from launching.
Microsoft Defender Exploit Guard has blocked an operation that is not allowed by your IT administrator.
 For more information please contact your IT administrator.
 	ID: C1DB55AB-C21A-4637-BB3F-A12568109D35
 	Detection time: 2020-08-12T16:49:31.248Z
 	User: ******\********
 	Path: C:\Users\*******\Downloads\aitracker-v0.3\AITrack.exe
 	Process Name: C:\Windows\explorer.exe
 	Security intelligence Version: 1.321.1239.0
 	Engine Version: 1.1.17300.4
 	Product Version: 4.18.2007.8

Windows 10 Pro for Workstations v2004, 19041.388.
https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/attack-surface-reduction#use-advanced-protection-against-ransomware

Maybe executing  AITrack.exe as admin could fix the issue (?)

Running as Administrator makes no difference in this case, and whitelisting AITrack.exe also has no effect. From what I can tell so far it looks like it's caused by one of the DLL's that the executable loads, will need to take a further look.

Could you confirm whether this is fixed with the new release (v0.5)?


Fix gemspec to work with pundit >= 1.0.0

When adding the gem to the gemfile, I got a bundler error:
Bundler could not find compatible versions for gem "pundit":
  In snapshot (Gemfile.lock):
    pundit (= 1.1.0)

  In Gemfile:
    policy-assertions (>= 0) ruby depends on
      pundit (~> 1.0.0) ruby

    pundit (>= 0) ruby

So, I updated the gemspec to allow any pundit version >= 1.0.0

Thanks @DannyBen. I'll be updating the gem shortly with other changes as well.

Working on another gem now, I noticed that bundler does not like "open ended" version specs. You will probably see it if you try to build the gem. So I am not sure if my fix is actually a good one...
Maybe just remove the dependency? Or change it to be ~> 1.0 and not ~>1.0.0?

It looks valid according to the ruby gems guide. I didn't receive any warnings when building and I've been using it without any problems. I think it should be okay.


Update Rufio dependency

Rufio has has an API change since it was integrated and released 0.1. This issue is to update CAPT in-line with Rufio v0.1.

On hold until we update Tink and release another CAPT. See https://github.com/tinkerbell/cluster-api-provider-tinkerbell/issues/200#issuecomment-1230775034


launch.json for new java debug extension

Hi! humans. I'm having trouble figuring out this launch.json stuff. I'm supposed to enter the fully qualified name of the mainClass but i have no idea what that is. I've tried a bunch of things but i can't figure it out.
i keep getting this error:
Failed to resolve classpath: Main class 'com.java.first' doesn't exist in the workspace.
PLEASE HELP!!
here's the launch.json settings
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "java",
"name": "Debug (Launch)",
"request": "launch",
"mainClass": "com.java.first", //here's where i'm having an issue. i don't know anything about this.
"args": ""
},
{
"type": "java",
"name": "Debug (Attach)",
"request": "attach",
"hostName": "localhost",
"port": 0
}
]
}

VSCode Version: Code 1.17.1 (1e9d36539b0ae51ac09b9d4673ebea4e447e5353, 2017-10-10T14:24:50.851Z)
OS Version: Windows_NT x64 10.0.15063
Extensions:

Extension
Author (truncated)
Version

php-debug
fel
1.11.1

cpptools
ms-
0.13.1

debugger-for-chrome
msj
3.3.1

java
red
0.11.0

vscode-icons
rob
7.15.0

vscode-java-debug
vsc
0.1.0

vscode-java-pack
vsc
0.1.0

Steps to Reproduce:

Reproduces without extensions: Yes/No

Please file this against the java extension you are using. Thank you


Insufficient documentation for planner task list when fetching all plan tasks

The command planner task list contains insufficient information under the heading Options. Mainly when a user wants to retrieve all the tasks of a plan.
For planId and planName, it states that they can only use them in conjunction with bucketName. This isn't the case. If they want to retrieve all the tasks of a plan they shouldn't include bucket information. Here I propose to change the documentation to the following.

Option
Description

--planId [planId]
ID of the plan. To retrieve tasks from a bucket, specify planId or planName when using bucketName. To retrieve tasks from a plan, specify planId or planName but not both.

--planName [planName]
Name of the plan. To retrieve tasks from a bucket, specify planId or planName when using bucketName. To retrieve tasks from a plan, specify planId or planName but not both.

https://pnp.github.io/cli-microsoft365/cmd/planner/task/task-list/

Hi @Jwaegebaert, good catch! The docs are not really clear here indeed.
Let's fine tune what you propose though.

Perfect, I will create a PR for it.

What about:

Option
Description

--planId
ID of a plan to list the tasks of. Specify either planId or planName but not both. Use in combination with bucketName to retrieve tasks from a specific bucket.

Of course, on what aspect would you like more fine-tuning?

What about:

Option
Description

--planId
ID of a plan to list the tasks of. Specify either planId or planName but not both. Use in combination with bucketName to retrieve tasks from a specific bucket.

One more point on this, perhaps. We no longer mention that they can also use these individually to retrieve all the tasks in a plan.

Always use in combination with either ownerGroupId or ownerGroupName.

I don't know if this one is directly needed because at ownerGroupId it is already stated that it should be used with planName

All good for me. I've adjusted the specs to your suggestions. 😄

Let's open it up for contribution!

Let's get this closed asap! 😁


TypeError: i is null / TypeError: Cannot read property 'split' of null

I get an error Uncaught TypeError: Cannot read property 'split' of null in Chrome, and TypeError: i is null [Learn More] in Firefox, given the following code:
<svg data-src="/images/test.svg" id="test"></svg>

document.addEventListener('DOMContentLoaded', function() {
  var elementsToInject = document.querySelectorAll('svg[data-src]');
  console.log(elementsToInject);
  # [svg#test]
  var injector = new SVGInjector();
  console.log(injector);
  # [svg#test]
  # n {}
  # XHR finished loading: GET "http://localhost:3000/images/test.svg".

  injector.inject(elementsToInject);
});

Any ideas how to trobleshoot this?

Did you try with the latest version.. without investigation, this looks like a bug that has been fixed with 2.1.2.
If the error persists, would you mind to share a gist with me, so I can debug this?
Thank you!

I used 2.1.3. Will try and reproduce!

If anyone falls on this like me, it seems to be due to a wrong handling of the cases where the viewBox attribute is not present on the svg element.

If anyone falls on this like me, it seems to be due to a wrong handling of the cases where the viewBox attribute is not present on the svg element.

Ha, I just had this issue today. Talk about good timing ^^ Thanks!

yeah - just hit this problem. if you are using svgomg then it will strip the viewbox


Circular dependency with serve-static

Hi,
I'm trying to add it via NuGet Package Manager, and I receive and error which says that there is a circular dependency with serve static.

Install-Package : Circular dependency detected 'express.TypeScript.DefinitelyTyped 2.1.7 => mime.TypeScript.DefinitelyTyped 0.0.1 => node.TypeScript.DefinitelyTyped 1.7.8 => serve-static.TypeScript.DefinitelyTyped 0.0.4 => express.TypeScript.DefinitelyTyped 2.1.7'.

Can you fix this somehow?

@staxmanade ?

It looks like there is a circular reference:
https://github.com/borisyankov/DefinitelyTyped/blob/master/express/express.d.ts#L14
https://github.com/borisyankov/DefinitelyTyped/blob/master/serve-static/serve-static.d.ts#L13
The root circular reference will have to be addressed.

From what I can gather, the root problem is:
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/express/express.d.ts#L1077
I had a go at making an 'express-core.d.ts' file by moving everything except the var static.. line (so it didn't depend on serve-static), but can't figure out how to declare the modules so that they 'merge' when you reference express.d.ts and express-core.d.ts together.
Maybe this isn't possible or the wrong approach.

Closing issue - track in PR for now.

Note for anyone upgrading from the old versions now that the PR has been merged. You'll need to manually remove the old packages to get over the 'dependency hump'.
uninstall-package express.TypeScript.DefinitelyTyped -Force
uninstall-package serve-static.TypeScript.DefinitelyTyped -Force
install-package express.TypeScript.DefinitelyTyped  -DependencyVersion Highest

Hopefully from now on, this problem won't reoccur on future package updates.


Update iiot-services.md

@terrymandin : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@terrymandin - This pull request was opened in the public repository. For future reference, most Microsoft-internal contributors work in the private repo.
In the private repo, content benefits from automated validations, a content staging environment, and comprehensive PR reviews. Also, you can sign off directly in your PR (in the public repo, you can't sign off on your own PR), and many PRs qualify for auto-merge.
To edit an article in the private repo from within the documentation, after you select Edit on an article page,  add “-pr” to the repo name in the URL.
SpineEdit is a MicrosoftDocs-approved Chrome extension that opens the edit option in the private repo, if there is one and if you have access to it.
Thanks!

Related links in the internal Microsoft Docs contributor guide:
Public vs. private repos | Move a commit to a different repo (public -> private) | GitHub for content reviews
Quick reference for contributing to the docs | Make changes to a Docs article | PR review quality criteria

Looks good.


Using terminfo instead of termcap

Hi there, everyone!
Don't know how feasible this is. Not all Unix-likes have termcap available to them, but most have terminfo by default. CRuby doesn't seem to depend on termcap when compiling. Is this somehow doable?

Doesn't know if it is sufficient for OpenBSD, but it builds without errors on my Arch Linux x86_64.
Correct me if there is something I am missed. :-P
diff --git a/Rakefile b/Rakefile
index 0f33c5e..89dab05 100644
--- a/Rakefile
+++ b/Rakefile
@@ -3,6 +3,7 @@
 # basic build file for mruby
 MRUBY_ROOT = File.dirname(File.expand_path(__FILE__))
 MRUBY_BUILD_HOST_IS_CYGWIN = RUBY_PLATFORM.include?('cygwin')
+MRUBY_BUILD_HOST_IS_OPENBSD = RUBY_PLATFORM.include?('openbsd')

 # load build systems
 load "#{MRUBY_ROOT}/tasks/ruby_ext.rake"
diff --git a/mrbgems/mruby-bin-mirb/mrbgem.rake b/mrbgems/mruby-bin-mirb/mrbgem.rake
index 98df384..e771145 100644
--- a/mrbgems/mruby-bin-mirb/mrbgem.rake
+++ b/mrbgems/mruby-bin-mirb/mrbgem.rake
@@ -6,10 +6,16 @@ MRuby::Gem::Specification.new('mruby-bin-mirb') do |spec|
   if spec.build.cc.search_header_path 'readline/readline.h'
     spec.cc.defines << "ENABLE_READLINE"
     if spec.build.cc.search_header_path 'termcap.h'
-      if MRUBY_BUILD_HOST_IS_CYGWIN then
-        spec.linker.libraries << 'ncurses'
-      else
-        spec.linker.libraries << 'termcap'
+      if MRUBY_BUILD_HOST_IS_CYGWIN || MRUBY_BUILD_HOST_IS_OPENBSD
+        if spec.build.cc.search_header_path 'termcap.h'
+          if MRUBY_BUILD_HOST_IS_CYGWIN then
+            spec.linker.libraries << 'ncurses'
+          elsif spec.linker.has_library('libterminfo') then
+            spec.linker.libraries << 'terminfo'
+          else
+            spec.linker.libraries << 'termcap'
+          end
+        end
       end
     end
     if RUBY_PLATFORM.include?('netbsd')

@hiroshiyui could you submit the patch as pull-request?


Add Rust cache directive, cache: cargo

Resolves https://github.com/travis-ci/travis-ci/issues/4470
As discussed in that thread, we will add:
cache: cargo

and equivalent for Rust.
This will add $HOME/.cargo and target (in
$TRAVIS_BUILD_DIR) to the cache.

Test: https://staging.travis-ci.org/BanzaiMan/travis_staging_test/builds/492954


Resolved issues #23 - switch to Coditsu, update all gems

Resolved issues #23 - switch to Coditsu with quality management, update all gems

:+1:

Finally ;)


automatic completion function

When can I provide the automatic completion function or provide an external interface for developers to customize the completion of the library

hi, really sorry for the huge delay... and humm I don't understand your question. There is no way to autocomplete anything in my package, sorry.


Topic create and alter

Description
Topics are  automatically created when I use producer or consumer.
How to alter PartitionCount and ReplicationFactor?

You can't from client - you will have to use kafka-topics command.
An admin client is on the way (implemented in Kafka and available in Java) , but does not allow to change partition count and replication factor yet (only create, delete and alter config you can alter via kafka-topics among other operations) Creating and deleting are being added to librdkafka soon.
Also note that you can't create topics if topic autocreation is disabled on broker .

I may have misunderstand what you meant by alter. In kafka, alter typically means "modify after creation (which, as I stated, is not possible,
If you want to create a topic with a given number of partition/ replica: it's not available in librdkafka/Confluent.Kafka yet, but it it's on roadmap, you can follow discussions here: https://github.com/edenhill/librdkafka/issues/986
For now, best and simplest way is to use kafka-topics (needing zookeeper endpoint and proper rights)

yep - use the kafka-topics command to create / alter topics. as @treziac notes, you can't use the client for this yet. you can turn off auto-topic creation with the auto.create.topics.enable broker config property (it's unfortunately not the default - I think that would be better).

What is the status of altering ReplicationFactor of a topic via C# API? Doesn't seem to be included in the API v1.2.1 and v1.3.0-pre, or am I missing something?

that's not supported by AlterConfigs (in any language)

@mhowlett we stumbled on this as well. What is the reason why changing replication factor for existing topics is not supported (as you said in all languages)? Especially since you allow to change min.insync.replicas for existing topics. In our case this lead to a situation where we were able to change min.insync.replicas from 1 to 2, but we were not able change replication factor from 1 to 3 which would render topic unusable. kafka-topics CLI is not an option in our case as we want our microservices to manage their own topics in automated way.

@mhowlett Any update on the issue raised by @KrzysztofBranicki ? We are also facing the same issue.


Cannot read properties of undefined (reading 'raw')

Hi! 👋
Firstly, thanks for your work on this project! 🙂
Today I used patch-package to patch<EMAIL_ADDRESS>for the project I'm working on.
I faced with error "Cannot read properties of undefined (reading 'raw')". Here's the error stack:
err: {
      "type": "Error",
      "message": "Cannot read properties of undefined (reading 'raw')",
      "stack":
          TypeError: Cannot read properties of undefined (reading 'raw')
              at /usr/src/server/node_modules/nestjs-pino/LoggerErrorInterceptor.js:19:52
              at Observable.init [as _subscribe] (/usr/src/server/node_modules/rxjs/src/internal/observable/throwError.ts:125:68)
              at Observable._trySubscribe (/usr/src/server/node_modules/rxjs/src/internal/Observable.ts:244:19)
              at /usr/src/server/node_modules/rxjs/src/internal/Observable.ts:234:18
              at Object.errorContext (/usr/src/server/node_modules/rxjs/src/internal/util/errorContext.ts:29:5)
              at Observable.subscribe (/usr/src/server/node_modules/rxjs/src/internal/Observable.ts:220:5)
              at /usr/src/server/node_modules/rxjs/src/internal/operators/catchError.ts:120:25
              at OperatorSubscriber._this._error (/usr/src/server/node_modules/rxjs/src/internal/operators/OperatorSubscriber.ts:52:13)
              at OperatorSubscriber.Subscriber.error (/usr/src/server/node_modules/rxjs/src/internal/Subscriber.ts:91:12)
              at OperatorSubscriber.Subscriber._error (/usr/src/server/node_modules/rxjs/src/internal/Subscriber.ts:124:24)
}

Here is the diff that solved my problem:
diff --git a/node_modules/nestjs-pino/LoggerErrorInterceptor.js b/node_modules/nestjs-pino/LoggerErrorInterceptor.js
index a0a3b29..f9300a6 100644
--- a/node_modules/nestjs-pino/LoggerErrorInterceptor.js
+++ b/node_modules/nestjs-pino/LoggerErrorInterceptor.js
@@ -14,12 +14,14 @@ let LoggerErrorInterceptor = class LoggerErrorInterceptor {
         return next.handle().pipe((0, rxjs_1.catchError)((error) => {
             return (0, rxjs_1.throwError)(() => {
                 const response = context.switchToHttp().getResponse();
-                const isFastifyResponse = response.raw !== undefined;
-                if (isFastifyResponse) {
-                    response.raw.err = error;
-                }
-                else {
-                    response.err = error;
+                if (response) {
+                    const isFastifyResponse = response.raw !== undefined;
+                    if (isFastifyResponse) {
+                        response.raw.err = error;
+                    }
+                    else {
+                        response.err = error;
+                    }
                 }
                 return error;
             });
@@ -30,4 +32,4 @@ LoggerErrorInterceptor = __decorate([
     (0, common_1.Injectable)()
 ], LoggerErrorInterceptor);
 exports.LoggerErrorInterceptor = LoggerErrorInterceptor;
-//# sourceMappingURL=LoggerErrorInterceptor.js.map
\ No newline at end of file
+//# sourceMappingURL=LoggerErrorInterceptor.js.map§
\ No newline at end of file

This issue body was partially generated by patch-package.

Hi, thanks for opening an issue and for your kind words.
It looks like the error is faced when interceptor is used to handle non-http context errors, right?

This happens when an HttpException is thrown in my code like so:
throw new HttpException('Bad Request', HttpStatus.BAD_REQUEST);

I'll try


Update direct-routing-plan-media-bypass.md

@nenonix @JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@CarolynRowe - for review


Fix packages

Information

Type
Breaking change

Feature/Fix/Doc/Chore
Yes/No

Todos

[ ] Tests
[ ] Coverage
[ ] Example
[ ] Documentation

:tada: This PR is included in version 6.55.3 :tada:
The release is available on:

v6.55.3
GitHub release

Your semantic-release bot :package::rocket:


Update index.ja.mdx

Closes #3148
Description
old image src in index.ja.mdx is broken
so i changed it to "https://c4.wallpaperflare.com/wallpaper/946/34/413/anime-tengen-toppa-gurren-lagann-littner-yoko-thigh-highs-wallpaper-preview.jpg" to close this issue
Current behavior (before updates)

New behavior (after updates)

Thank you! Can you fix en document as well?

Done :-)

@5AIPAVAN
Sorry.
Can you replace url with this?
https://www.gurren-lagann.net/tv/images/kv.jpg

@5AIPAVAN Sorry. Can you replace url with this? https://www.gurren-lagann.net/tv/images/kv.jpg

done :-)


Plugin style seems broken in latest on jenkins LTS

The current plugin release lifecycle to jenkins looks odd - there are currently 12 1.13 releases, 9 of which were released in the last 4 days.
Public releases of the plugin have been observed at https://updates.jenkins-ci.org/download/plugins/build-monitor-plugin/ and https://plugins.jenkins.io/build-monitor-plugin/#releases
The latest 1.13 release builds also seems to have styling issues (at least when used with jenkins LTS).
The plugin seems to be pushed to the jenkins update repo too often (and maybe some extra testing would be required)?
Thanks

This caused by the custom hosting and release process developed by @jan-molak. The standard hosting and released process used by the @jenkinsci organization (JEP-229) has a way of using labels to mark certain PRs (e.g. dependency updates) as ineligible for release. I have offered to migrate this repository to the @jenkinsci organization and set up JEP-229, but the decision is up to @jan-molak.

Thanks @basil.
@jan-molak, is @basil's help and approach something you could please consider adopting?
I have no concrete numbers but I guess this is/will affect many jenins around the world.
Thanks!

Hi @salavessa!

The current plugin release lifecycle to jenkins looks odd

Build Monitor uses a continuous deployment workflow, where every change that's merged to master and passes the automated tests is automatically released to the Jenkins registry.
My thinking behind it was that if anything was good to go to master, it should be made available to the community, no matter if it's a dependency update or a code change. Especially that not keeping up to date with dependencies can be a cause of security issues...
Note that I've developed this system back in 2013, so about 6 years before the Jenkins project had this capability. While I still believe this is the right approach, I probably would've gone about the versioning scheme a bit differently if I was to design it again.

there are currently 12 1.13 releases, 9 of which were released in the last 4 days.

That's correct, recently Build Monitor Contributors have been doing an amazing job helping to revive Build Monitor, and I've been doing my best to get the PRs merged to help keep the momentum going. And again, as soon as a PR is merged - it gets released.

The plugin seems to be pushed to the jenkins update repo too often

I'm not sure about that. If there are new fixes available, wouldn't we want to make them available as soon as they can be used?
@basil, @dcendents - is there any reason why the current continuous deployment approach should be revised?

The latest 1.13 release builds also seems to have styling issues (at least when used with jenkins LTS).

Interesting, thanks for reporting that! Would you be able to tell us more about the behaviour you see vs what you'd expect? Could you attach any screenshots to help us see what you see? Are there any errors visible in the browser log?
Let's try to get to the bottom of it!

@basil, @dcendents - is there any technical reason why the current continuous deployment approach should be revised?

Well, code cleanup PRs and dependency updates are generally useful to merge, but spinning a dedicated release for them and forcing users to upgrade to that release when its changelog just consists of entries like "No user-visible changes" tends to annoy users. That's why JEP-229 ignores Dependabot PRs and code cleanup (based on label) and requires PRs to be labelled as e.g. "bug" or "RFE" for continuous deployment to kick in. This seems to have struck a chord with users.

The latest 1.13 release builds also seems to have styling issues (at least when used with jenkins LTS).

There was indeed a recent regression, but it was fixed in #517.

Hi @jan-molak and @basil,
Thanks for the info - I can confirm that the latest release/build 1.13+build.202111220004 has fixed the styling bug initially reported.
I still believe that having such short release cycles makes it odd specially if you notice a bug in a release you just installed and when you rollback to the previous one (or update to the new latest) and the bug is still there - I ended up pretty "lost" to find a good release/version to rollback to so in my case and to be safe, I just revertd to the one from 1st October (i.e. 8 releases before the latest available by then).
Anyway, good work and thanks for the quick fix on #517
Thanks!


Remove _workaround fields from the Interpolator struct

I got compiler errors that generic parameters are unused, so I added fields of those types.
I'm sure there's a way to remove these unneeded fields. It's just cleanup

https://github.com/GWBasic/index_signal/commit/4674e7e40fb5814bf7c7cb2dfa0e04258ade455b


Missing error message when  app and typename are equal

Expected behaviour
When sysl app and typename are equalreljam and sysl should report an error.
Actual behaviour
When sysl app and typename are equalreljam does not report an error but creates uncompilable Java code.
Steps to reproduce the behaviour
> cat article.sysl
Article [version="0.0.1", package="io.sysl.bug"]:  # <============= Article here

    !type Article:                                 # <============= Article here
        content <: Content

    !type Content:
        Text <: string
> reljam --out gen model /article Article
> javac gen/io/sysl/bug/*.java
ArticleJsonDeserializer.java:64: error: cannot find symbol
    private Article.View deserializeArticleView(JsonParser p)
                   ^
  symbol:   class View
  location: class Article
[...]

Also true for !table


TypeScript declarations for react-player/lazy broken in v2.8.1

Current Behavior
Previously successfully using react-player v2.7.2 in TypeScript project importing react-player/lazy.
Upgrading to react-player v2.8.1 results in TypeScript errors as the TypeScript declarations for react-player/lazy have been broken.
Expected Behavior
Working TypeScript declarations for react-player/lazy.
Steps to Reproduce
Just try importing "react-player/lazy" in TypeScript project using react-player v2.8.1.
Environment

URL attempting to play: n/a
Browser: Chrome
Operating system: Windows 10
jsFiddle example: n/a

Other Information
Related to old closed issue https://github.com/cookpete/react-player/issues/918.
The react-player/lazy/index.d.ts file seems to be a copy of the react-player/index.d.ts file but this simple approach no longer works due to broken relative path imports.

Hello 🖖
Got this error on my side :
JSX element class does not support attributes because it does not have a 'props' property.ts(2607)
'ReactPlayer' cannot be used as a JSX component.
  Its instance type 'ReactPlayer' is not a valid JSX element.
    Type 'ReactPlayer' is missing the following properties from type 'ElementClass': render, context, setState, forceUpdate, and 3 more.

Import :
import ReactPlayer from 'react-player/lazy'`

Usage :
<ReactPlayer
  url={url}
  width="100%"
  height="100%"
  playing
  muted
  controls={false}
/>

Hello 🖖
Got this error on my side :
JSX element class does not support attributes because it does not have a 'props' property.ts(2607)
'ReactPlayer' cannot be used as a JSX component.
  Its instance type 'ReactPlayer' is not a valid JSX element.
    Type 'ReactPlayer' is missing the following properties from type 'ElementClass': render, context, setState, forceUpdate, and 3 more.

Import :
import ReactPlayer from 'react-player/lazy'`

Usage :
<ReactPlayer
  url={url}
  width="100%"
  height="100%"
  playing
  muted
  controls={false}
/>

Hello 🖖
Got this error on my side :
JSX element class does not support attributes because it does not have a 'props' property.ts(2607)
'ReactPlayer' cannot be used as a JSX component.
  Its instance type 'ReactPlayer' is not a valid JSX element.
    Type 'ReactPlayer' is missing the following properties from type 'ElementClass': render, context, setState, forceUpdate, and 3 more.

Import :
import ReactPlayer from 'react-player/lazy'`

Usage :
<ReactPlayer
  url={url}
  width="100%"
  height="100%"
  playing
  muted
  controls={false}
/>

Hi @toinelin, yes I believe that error is caused by the react-player/lazy TypeScript declarations being broken.

Hello 🖖
Got this error on my side :
JSX element class does not support attributes because it does not have a 'props' property.ts(2607)
'ReactPlayer' cannot be used as a JSX component.
  Its instance type 'ReactPlayer' is not a valid JSX element.
    Type 'ReactPlayer' is missing the following properties from type 'ElementClass': render, context, setState, forceUpdate, and 3 more.

Import :
import ReactPlayer from 'react-player/lazy'`

Usage :
<ReactPlayer
  url={url}
  width="100%"
  height="100%"
  playing
  muted
  controls={false}
/>

Hi @toinelin, yes I believe that error is caused by the react-player/lazy TypeScript declarations being broken.

@JuanM04 Any ideas?
There does seem to be a circular requirement between base.d.ts and index.d.ts. Not sure if that’s related.
I can't see any import statements that would be affected by the directory it's in.

@JuanM04 Any ideas?
There does seem to be a circular requirement between base.d.ts and index.d.ts. Not sure if that’s related.
I can't see any import statements that would be affected by the directory it's in.

It's because types/index.d.ts needs all of its imports in the same directory but in prepublish it's copied alone to lazy/index.d.ts so the imports need to go back a directory.

It's because types/index.d.ts needs all of its imports in the same directory but in prepublish it's copied alone to lazy/index.d.ts so the imports need to go back a directory.

That's basically it. lazy/index.d.ts, it imports ./base when it should import ../base

That's basically it. lazy/index.d.ts, it imports ./base when it should import ../base


deprecating Azure RI with new version, supporting more RI Types

Description

deprecating old policy that used Azure EA key
adding more Reservation types
adding support for shared subscription

Issues Resolved
[List any existing issues this PR resolves]
Contribution Check List

[ ] All tests pass.
[ ] New functionality includes testing.
[ ] New functionality has been documented in the README if applicable
[ ] New functionality has been documented in CHANGELOG.MD

Danger has errored
[!] Invalid Dangerfile file: cost/azure/reserved_instances/mca_recommendations/azure_reserved_instance_recommendations.pt:8: syntax error, unexpected <<, expecting end-of-input
<<<<<<< Updated upstream
^. Updating the Danger gem might fix the issue. Your Danger version: 8.2.3, latest Danger version: 8.3.1
 #  from Dangerfile:99
 #  -------------------------------------------
 #  has_app_changes.each do |file|
 >    pp.parse(file)
 #    category = pp.parsed_category
 #  -------------------------------------------

  Generated by :no_entry_sign: Danger

Danger has errored
[!] Invalid Dangerfile file: 784: unexpected token at ``. Updating the Danger gem might fix the issue. Your Danger version: 8.2.3, latest Danger version: 8.3.1
 #  from Dangerfile:174
 #  -------------------------------------------
 #  # Lint added and modified files only
 >  textlint.lint
 #  -------------------------------------------

  Generated by :no_entry_sign: Danger

Danger has errored
[!] Invalid Dangerfile file: 784: unexpected token at ``. Updating the Danger gem might fix the issue. Your Danger version: 8.2.3, latest Danger version: 8.3.1
 #  from Dangerfile:174
 #  -------------------------------------------
 #  # Lint added and modified files only
 >  textlint.lint
 #  -------------------------------------------

  Generated by :no_entry_sign: Danger


[Question] how to use multiple pub topics

the simplicity of the library is a strong chracteristic :-). Currently the publish topic is set during initialization of the class instance. What is the best way to use more than 1 publish topic in the current implementation of MQTTSerialPrinter? Use a second instance? Or would such functionality require an update of the MQTTSerialPrinter code?

Yeah, the easiest way would be to just have multiple instances sharing the same mqtt client. That would work fine if you want to send some messages to one topic and some to another like this:
WiFiClient wifi_client;
PubSubClient mqtt_client(wifi_client);

MQTTSerialPrinter Log1(mqtt_client, "topic_1");
MQTTSerialPrinter Log2(mqtt_client, "topic_2");

...

// Send to topic_1
Log1.println("Hello topic 1");

// Send to topic_2
Log2.println("Hello topic 2");

If you want it to repeat the same message to a bunch of topics it would be cleaner with a change to MQTTSerialPrinter. Instead of a single topic it could store an array and have an addTopic() function maybe. If that's something you want I can add it or feel free to open your own PR.


README: create README.md

Add title, table of contents, usage example, contributing guide, license info, badges.

Tagged as MISTAKE. DELETED


Cucumber JVM

Are there any plans to support Cucumber-JVM as well as Cucumber JS?
Would such a contribution be welcomed?

Not sure I understand the question.  We support tests written in Cucumber.

There are various implementations in different languages of tools that parse Gherkin *.feature files and drive browsers to execute the steps and scenarios, defined in the Gherkin *.feature files.  E.g.

Cucumber (Ruby)
Cucumber JS
Cucumber JVM
Behat (PHP)
Specflow (C#)
and more

I believe protractor only works with Cucumber JS.  Perhaps it already supports other implementations?
If not, are there any plans to support more?

Actually there are plans to spin cucumber JS support out into a separate repo.  Regardless, Protractor doesn't support Java, so how could it possibly support Cucumber JVM?

Closing stale issues. Please open a new issue if you feel there is still a general bug.


Chapt. 4 Copyright notice and format of .md file

Hi, I've corrected the copyright notice and the format of the markdown.

Thank you very much.


[MM-39770] Make thread mention badge visible in all themes

Summary
Mention badge in thread wasn't visible in some themes.
Ticket Link

MM-39770
Release Note

 Made thread mention badge visible in all themes

Will try to auto merge this PR once all tests and checks are passing. This might take up to an hour.

Cherry pick is scheduled.

/cherry-pick cloud

Cherry pick is scheduled.


Gcp plugin

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area plugins

/area registry

/area build

/area documentation

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

Welcome @ahmedameenaim! It looks like this is your first PR to falcosecurity/plugins 🎉


Training data is too generic, lots of false positives

Training data (at least) needs work - even at 90% threshold, I get false positives on simple non-twss data:
twss.is("hello there, is this car still available?");
>> true

This is a known issue. And since I can't figure out how to merge issues, I'm closing this one down.


Should bf16 vmv.v.v and vmerge.vvm be supported with Zvfbfmin?

I notice that clang supports vmv_v_v and vmerge for f16 with Zvfhmin. Seems reasonable that bf16 should be the same.
CC: @kito-cheng @rofirrim

No objection.


engine: fix service watching

I'm not entirely sure why this timeout was there, but this code was pretty broken:
The defer cancel() here meant we were canceling the watch's context immediately after starting dispatchServiceChangesLoop, so it'd exit pretty much immediately.
If we simply remove the defer cancel(), then we're still passing an expiring context into WatchServices, and dispatchServiceChangesLoop exits after watchTimeout (10 seconds).
My best guess is that at some point someone thought WatchServices was potentially blocking, and added the timeout to ensure we weren't waiting for it forever. Looking at it now, though, I don't see any code in there that would even care if ctx expired anyway, so I think it's perfectly safe to remove (well, from the perspective of ServiceWatcher, anyway. It's possible that fixing ServiceWatcher breaks something else that was only working because ServiceWatcher was broken).

(FWIW, AFAIK no one has actually reported a problem with this - I just happened to run into it when I was copy/pasting code from this for event watching yesterday)


"failed to remove /lib /lib64" when rebuild

Describe the bug
When i rebuild my configuration, i get two warnings
rmdir: failed to remove '/lib': No such file or directory
rmdir: failed to remove '/lib64': No such file or directory

To Reproduce
https://github.com/eoli3n/nix-config/blob/master/hosts/work/configuration.nix
nixos-rebuild switch

Expected behavior
No warnings
Logs
[...]
building '/nix/store/896l193vlmnfw44pw3ci8a0yi2x9y6mz-user-units.drv'...
building '/nix/store/amykxli2n9nbbaxdrhp0s5g8cq1waab1-etc.drv'...
building '/nix/store/6zi5xbma3h5yyq2ch4kyph2xzspi6icp-nixos-system-work-20.03pre211190.a21c2fa3ea2.drv'...
NOT restarting the following changed units<EMAIL_ADDRESS>activating the configuration...
setting up /etc...
reloading user units for user...
setting up tmpfiles
reloading the following units: dbus.service
restarting the following units: polkit.service

Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 4.19.100, NixOS, 20.03pre211190.a21c2fa3ea2 (Markhor)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.2`
 - channels(root): `"nixos-20.03pre211190.a21c2fa3ea2"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:
I don't know which package does this

I also noticed this recently and it's reproducible even on no-op rebuilds:
[root@nixos-unstable:~]# nixos-rebuild switch
building Nix...
building the system configuration...
updating GRUB 2 menu...
activating the configuration...
setting up /etc...
rmdir: failed to remove '/lib': No such file or directory
rmdir: failed to remove '/lib64': No such file or directory
reloading user units for michael...
setting up tmpfiles

I had a look though Nixpkgs and it seems to be fixed/reverted already: 26aba55951a09340959b68330875904ac43a3a31 I.e. it shouldn't be there on the next update.
Other relevant commits:

5495cb91eb7c3fe1d93be2ea08f75fdd7c907036
45db499d2de2235388212a911b8344b58ddfda36
af665d822a166ae62547c1c310207f11acaded17

Relevant PR: https://github.com/NixOS/nixpkgs/pull/69057

Got this a few times as well, followed instantly by a kernel panic on two occasions.

The fix is now in nixos-unstable and I don't get the error message anymore.
@Synthetica9 that's strange, though the kernel panic should definitely be unrelated to this issue (must be caused by something else later in the activation script (/run/current-system/activate)).


Docs: Clarify description of stages 1 and 2

The description for stages 1 and 2 in the architecture document was
rather confusing. Part of the confusion was in the wording, part in the
description itself.
I still have questions as to what exactly the execution group is, though.

Yeah execution group is probably a historical term before we introduced pods. Would it make it clear enough for you if you just s/execution group/pod/ ?

Thanks for tackling this, it's long overdue for an update.

Thanks for clarifying that execution group is simply the pod. Makes sense now.

LGTM, although now I realise that it's problematic that this document is describing our particular stage1 whereas really it should talk about them more generally. Can fix that in a follow up though. Thanks!


java.lang.UnsatisfiedLinkError: dlopen failed: library "libMNN.so" not found

hi，I ran your code in Android Studio，do what you say in README，
I build mnn .so files, and put them in  src/main/jniLibs/,  total two folder arm64-8v and  armeabi-v7a.
but I got this error ,

my compute's info:

windows 10
i5- 7300

I run code in an android Virtual Devices：

I run a Virtual Device with CPU/ABI is arm64-8v or armeabi-v7a, it show
Error while waiting for device: The emulator process for AVD Pixel_4_API_30_arm64 was killed.

I try some other method to solve this, but failed, could you help me?

我是用真机测试的。


clone build-digitalocean-centos69-x64-1

to replace build-joyent-centos69-x64-1

looks like https://ci.adoptopenjdk.net/computer/build-digitalocean-centos69-x64-1/ is missing a few tags that the joyent machine had:
icedteabuild , gcc73

deleted build-joyent-centos69-x64-1 from jenkins

added https://ci.adoptopenjdk.net/computer/build-digitalocean-centos69-x64-2/

deleted build-joyent-centos69-x64-1 from triton


update flashinfer

Close this PR. Flashinfer has been formally released!! We can switch to importing from Pypi.


Added tests for Sort Feature

Codecov Report
Base: 48.16% // Head: 42.22% // Decreases project coverage by -5.94% :warning:

Coverage data is based on head (8f47083) compared to base (1b9d961).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master      #71      +/-   ##
============================================
- Coverage     48.16%   42.22%   -5.95%
- Complexity      438      469      +31
============================================
  Files           109      131      +22
  Lines          2213     2738     +525
  Branches        265      344      +79
============================================
+ Hits           1066     1156      +90
- Misses         1076     1494     +418
- Partials         71       88      +17

Impacted Files
Coverage Δ

...java/longtimenosee/logic/commands/SortCommand.java
36.36% <0.00%> (+36.36%)
:arrow_up:

...rc/main/java/longtimenosee/model/ModelManager.java
59.34% <0.00%> (-13.39%)
:arrow_down:

.../longtimenosee/logic/parser/AddressBookParser.java
48.38% <0.00%> (-13.16%)
:arrow_down:

...timenosee/storage/JsonSerializableAddressBook.java
61.29% <0.00%> (-12.63%)
:arrow_down:

...in/java/longtimenosee/logic/parser/ParserUtil.java
40.00% <0.00%> (-12.39%)
:arrow_down:

...a/longtimenosee/model/person/UniquePersonList.java
83.33% <0.00%> (-5.04%)
:arrow_down:

...va/longtimenosee/logic/commands/CommandResult.java
76.00% <0.00%> (-4.96%)
:arrow_down:

src/main/java/longtimenosee/model/AddressBook.java
61.01% <0.00%> (-4.84%)
:arrow_down:

...rc/main/java/longtimenosee/logic/LogicManager.java
66.66% <0.00%> (-4.77%)
:arrow_down:

src/main/java/longtimenosee/model/Model.java
100.00% <0.00%> (ø)

... and 41 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


moved set_camera_zoom and do_set_servo to commander

Describe problem solved by this pull request
SET_CAMERA_ZOOM was handled in mavlink_receiver before and DO_SET_SERVO only in mission_blocks. Moved both to the Commander.cpp. Also changed the formula for DO_SET_SERVO, as it probably required some very specific mixer before. Now it merely scales the 0-2000 input in the command to -1 to 1 and the rest is up to the mixer.

I'm a bit confused here. What exactly does it fix? And why?

I'm a bit confused here. What exactly does it fix? And why?

Both SET_CAMERA_ZOOM and DO_SET_SERVO can be mission items now and be performed if you send a COMMAND_LONG.
Before this PR, you could have DO_SET_SERVO as mission item, but not as command, and SET_CAMERA_ZOOM as command, but not as mission item.

Right. And this actually works? :astonished:

Right. And this actually works?

After reaching waypoint with SET_CAMERA_ZOOM, param1=2, param2=50:
~/Development/FirmwarePX4/build/px4_sitl_default/bin$ sudo ./px4-listener actuator_controls_2

TOPIC: actuator_controls_2
 actuator_controls_s
	timestamp: 414596000  (19.948000 seconds ago)
	timestamp_sample: 0
	control: [nan, nan, nan, nan, 0.0000, nan, nan, nan]

After reaching waypoint with SET_CAMERA_ZOOM, param1=2, param2=50:
~/Development/FirmwarePX4/build/px4_sitl_default/bin$ sudo ./px4-listener actuator_controls_2

TOPIC: actuator_controls_2
 actuator_controls_s
	timestamp: 436496000  (9.784000 seconds ago)
	timestamp_sample: 0
	control: [nan, nan, nan, nan, 1.0000, nan, nan, nan]

After reaching waypoint with DO_SET_SERVO, param1=1, param2=1500:
~/Development/FirmwarePX4/build/px4_sitl_default/bin$ sudo ./px4-listener actuator_controls_2

TOPIC: actuator_controls_2
 actuator_controls_s
	timestamp: 458816000  (18.656000 seconds ago)
	timestamp_sample: 0
	control: [nan, 0.5000, nan, nan, nan, nan, nan, nan]

A manual DO_SET_SERVO:
~/Development/FirmwarePX4/build/px4_sitl_default/bin$ rosservice call /mavros/cmd/command "{broadcast: false, command: 183, confirmation: 0, param1: 1, param2: 2000, param3: 0.0,
  param4: 0.0, param5: 0.0, param6: 0.0, param7: 0.0}"
success: True
result: 0
~/Development/FirmwarePX4/build/px4_sitl_default/bin$ sudo ./px4-listener actuator_controls_2

TOPIC: actuator_controls_2
 actuator_controls_s
	timestamp: 539864000  (1.084000 seconds ago)
	timestamp_sample: 0
	control: [nan, 1.0000, nan, nan, nan, nan, nan, nan]

A manual SET_CAMERA_ZOOM:
~/Development/FirmwarePX4$ rosservice call /mavros/cmd/command "{broadcast: false, command: 531, confirmation: 0, param1: 2, param2: 100, param3: 0.0,
  param4: 0.0, param5: 0.0, param6: 0.0, param7: 0.0}"
success: True
result: 0
simadm@10:~/Development/FirmwarePX4$ sudo ./build/px4_sitl_default/bin/px4-listener vehicle_command

TOPIC: vehicle_command
 vehicle_command_s
	timestamp: 847064000  (14.288000 seconds ago)
	param5: 0.000000
	param6: 0.000000
	param1: 2.0000
	param2: 100.0000
	param3: 0.0000
	param4: 0.0000
	param7: 0.0000
	command: 541
	target_system: 1
	target_component: 1
	source_system: 1
	source_component: 240
	confirmation: 0
	from_external: True
simadm@10:~/Development/FirmwarePX4$ sudo ./build/px4_sitl_default/bin/px4-listener actuator_controls_2

TOPIC: actuator_controls_2
 actuator_controls_s
	timestamp: 859448000  (5.292000 seconds ago)
	timestamp_sample: 0
	control: [nan, nan, nan, nan, 1.0000, nan, nan, nan]

@hamishwillee I think you are more on track on the DO_SET_SERVO requests on slack...is this a feasible solution for it? The only problem is the collision with actuator_controls_2 from the vmount module.

I prefer to avoid the collision, and rather go for aux in control group #3 as outlined in https://github.com/PX4/Firmware/pull/10320#issuecomment-561119536 with a new command. That way most existing setups can just use it w/o mixer changes and it is testable via RC as well.
Zoom should go through vmount. How are you using that currently, without vmount?

I prefer to avoid the collision, and rather go for aux in control group #3 as outlined in #10320 (comment) with a new command. That way most existing setups can just use it w/o mixer changes and it is testable via RC as well.
Zoom should go through vmount. How are you using that currently, without vmount?

The camera that we use is happy with getting the PWM signal just once for setting the zoom, so publishing actuator_controls_2 once was sufficient to get the zoom controlled, of course with a corresponding mixer file.

It was just brought to my attention that my PR for DO_SET_SERVO (https://github.com/PX4/Firmware/pull/15281) conflicts with this. Not really sure what's going on here, or who should continue DO_SET_SERVO work? After talking with @bkueng, I am currently working on mapping DO_SET_SERVO to control group 3 RC aux 1-3. I am also adding support for the new MAV_CMD_DO_SET_ACTUATOR message.


doesn't start use on docker using docker compose

i tried to run using docker-compose , i added an empty .env file and runned docker-compose up

Hi Merrick,
thank you for your interest. I don't know docker very well, @RobertoBochet as put a comment at the end of this issue, can this one be helpful ?
I'm not sure the .env should be empty.
I will join mine in the evening

maybe i'm missing some env varibales , anything what do i have to add ?

Find bellow my .env file
don't forget to create your APP_KEY
`APP_NAME=Laravel
APP_ENV=local
APP_KEY=
APP_DEBUG=true
APP_URL=http://<IP_ADDRESS>:8000/
LOG_CHANNEL=stack
LOG_LEVEL=debug
DB_CONNECTION=mysql
DB_HOST=<IP_ADDRESS>
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=root
DB_PASSWORD=
BROADCAST_DRIVER=log
CACHE_DRIVER=file
FILESYSTEM_DRIVER=local
QUEUE_CONNECTION=sync
SESSION_DRIVER=file
SESSION_LIFETIME=120
MEMCACHED_HOST=<IP_ADDRESS>
REDIS_HOST=<IP_ADDRESS>
REDIS_PASSWORD=null
REDIS_PORT=6379
MAIL_MAILER=smtp
MAIL_HOST=mailhog
MAIL_PORT=1025
MAIL_USERNAME=null
MAIL_PASSWORD=null
MAIL_ENCRYPTION=null
MAIL_FROM_ADDRESS=null
MAIL_FROM_NAME="${APP_NAME}"
AWS_ACCESS_KEY_ID=
AWS_SECRET_ACCESS_KEY=
AWS_DEFAULT_REGION=us-east-1
AWS_BUCKET=
AWS_USE_PATH_STYLE_ENDPOINT=false
PUSHER_APP_ID=
PUSHER_APP_KEY=
PUSHER_APP_SECRET=
PUSHER_APP_CLUSTER=mt1
MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"
`

I have add one.


Need of kicking connected clients when others tries to connect with same Id

I am having problems beacause a client using another mqtt client library losts i'ts connection and gets stucked, I was wondering if it could be posible to manage the connected clients and kick the stucked client. This way it would be able to reconnect because no fake connection with it's Id would exist in our broker.
I was thinking of kicking a connected client when another one tries to connect with the same Id.

Hi @aaarnaaauuu,
at the moment the server will disconnect the old client if a new one connects with the same client ID. So it should already work as you described.
Best regards
Christian

It's true @chkr1011 , thanks for answering.
Kind regards,
Arnau

anw, how to kick a client with an ID? could not find any method in the library

@phamminhkhac You can use the https://github.com/chkr1011/MQTTnet/wiki/Server#intercepting-subscriptions for this.
E.g.:
var optionsBuilder = new MqttServerOptionsBuilder()
    .WithSubscriptionInterceptor(context =>
    {
        if (context.TopicFilter.Topic.StartsWith("#") && context.ClientId != "Imperator")
        {
            context.AcceptSubscription = false;
            context.CloseConnection = true;
        }
    })
    .Build();

where context.CloseConnection = true; will kick the client from the broker when it tries to subscribe to #.
You can do the same for connection and publishing by the way. If you want another fully working example, check e.g. my example project under https://github.com/SeppPenner/NetCoreMQTTExampleJsonConfig/blob/master/NetCoreMQTTExampleJsonConfig/Program.cs.


UX: Attempt to start boot2docker automatically

❯ docker pull gliderlabs/alpine
Using default tag: latest
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

It would be nice to

have the docker cli check for the existence of  boot2docker,

true: attempt to run boot2docker up automatically
false: a link to this error in a Docker FAQ (can't seem to find one here, surprisingly)

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

❯ docker --version
Docker version 1.9.1, build a34a1d5

❯ docker info
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

❯ uname -a
Darwin Kevins-MacBook-Pro.local 15.2.0 Darwin Kernel Version 15.2.0: Fri Nov 13 19:56:56 PST 2015; root:xnu-3248.20.55~2/RELEASE_X86_64 x86_64

I don't think we'll implement a check if boot2docker / docker-machine is present, and automatically start the machine (and set the environment variables).
However, if you have suggestions on what to add to the FAQ, please do! If you want to contribute a docs change, that'd be awesome: the Markdown file used to generate the FAQ page is in this repository; https://github.com/docker/docker/blob/master/docs/misc/faq.md
If you need more info on our contribution process, please read the contributors guide; https://docs.docker.com/opensource/workflow/make-a-contribution/, but feel free to ping me here if you need help :+1:

I'm running into this myself from time to time so I can create a new note to the FAQ since it's not already taken.
#dibs


CASMINST-6707: Linting

Backport of https://github.com/Cray-HPE/docs-csm/pull/4411

/backport release/1.3


NSPOSIXErrorDomain Error 53

Bug description:

When reopening a webview this error appear with certain pages.
To Reproduce:

Very easy to reproduce, an app with a webview (instagram seems to be having this issue most).
Open the webview, put app in background and reopen app.
Expected behavior:

No error
Screenshots/Videos:

Environment:

OS: Android
OS version:
react-native version: 0.61.4
react-native-webview version: 8.0.2

Same problem here testing in iOS 12.1 device.

This is still an issue, it shouldn't be closed.

This is still an issue, it shouldn't be closed.


num_features

Why are you taking num_features = 13?
How do you come up with this number 13, Is there a reason behind it?
Please help me understand this

Usually people use 13 coefficients from MFCC alongside the delta and double delta features. I just skipped the deltas features, ended up with only 13 features.