Type Checking for MutationRecord gives ClassCastException in Chrome

The follow code gives ClassCastException in Chrome(Version 83.0.4103.61 (Official Build) (64-bit)) and new Edge(Version 83.0.478.37 (Official build) (64-bit)) but not Edge Legacy
    private void setupMutation(Node target) {
        Consumer<MutationRecord> recordConsumer = mutationRecord -> DomGlobal.console.log("oldValue", mutationRecord.oldValue);

        MutationObserverInit mutationObserverInit = MutationObserverInit.create();
        mutationObserverInit.setAttributes(true);
        mutationObserverInit.setChildList(true);
        mutationObserverInit.setSubtree(true);

        MutationObserver mutationObserver = new MutationObserver(new MutationObserver.MutationObserverCallbackFn() {
            public Object onInvoke(JsArray<MutationRecord> recordJsArray, MutationObserver observer) {
                recordJsArray.forEach((recordConsumer1, ignore, params) -> {
                    recordConsumer.accept(recordConsumer1);
                    return null;
                });

                return null;
            }
        });

        mutationObserver.observe(target, mutationObserverInit);
    }

Below is the type check that fails for MutationObserver. In the console there is a test againt $wnd and window for the mutationRecord instance

And the generated code where castToNative is used.

We iterated on this a bit in gitter, and here's our conclusion:
The original code that worked in elemtental2 1.0.0-RC1 worked fine, using
for (MutationRecord record : recordJsArray)...

since MutationObserver.MutationObserverCallbackFn provided MutationRecord[] recordJsArray as an argument - a java array, so no casting was done on the way out. Now, in 1.0.0 with the shift to JsArray<MutationRecord> recordJsArray, the generics are checked at runtime on the way out when assigning to record for a for-each loop, or when calling JsArray.forEach and invoking the lambda (as in the original report above).
The bug in Chrome is that instead of the objects being an instance of the global window where the mutation occurred, it is an instance of the iframe in which GWT code runs.
This is not a new breakage in Chrome however - it appears to have been wrong before, but it was easier to work around before, since you could iterate the generic collection. The workaround for this JsArray problem is to cast to JsArray<Object>, iterate those Objects instead, and then Js.uncheckedCast them to MutationRecord.
Perhaps change MutationRecord to be some kind of @interface or @record so that it isn't subject to these checks? It doesn't seem like a very satisfying solution, but it does get around Chrome's bug here.

It seems to me to be a problem in GWT. I'll ask @rluble to take a look.

Perhaps change MutationRecord to be some kind of @interface or @record so that it isn't subject to these checks? It doesn't seem like a very satisfying solution, but it does get around Chrome's bug here.

This is not a solution. MutationRecord is a valid token at runtime and MutationRecord has a prototype and constructor (Even if you are not allowed to call it directly) so it needs to be a class.

I am not sure there is a good solution here. elemental2 is generated from the closure definitions and the definition is for all purposes correct.
The alternative is to use a workaround like
for(Object o : recordJsArray) {
  MutationRecord rec = Js.unckeckedCast(o);
}

Since this is a browser issue I think that a workaround here is the proper solution.

@rluble yes, the first workaround is what we did after figuring out what chrome was doing wrong (though we cast the array to JsArray<Object> first, I didn't realize we could just change the type of the "next" variable in the loop).
I think the second solution might be better off without using raw types? I frequently run into issues when mixing raw types with lambdas/references in normal javac, and imagine similar issues could arise in jdt.

Other possible solution is to change GWT so that to have a yet another custom casting logic for JsPackage.GLOBAL classes; so that at runtime the logic becomes x instanceof $wnd.Blah || x instanceof window.Blah. It seems to me that for most cases when you reference the global scope you actually don't care if it is the iframe or the top window, especially from the instanceof/cast perspective.
I could review the patch if you want to do such a change but it is not a completely trivial change.
The relevant classes are ImplementCastsAndTypeChecks.java that has the main transformation logic, TypeCategory that defines the types of things and Casts.java that has the runtime support.

Yeah, and especially if you get into "more than one running gwt module on the page" territory, I'd worry that this still wouldn't be complete. Hard to say if that is a reasonable use with this edge case or not.
Additionally, it doesn't solve things like https://github.com/google/elemental2/issues/16#issuecomment-341163467, where each IFrameElement has a Window contentWindow field, but this window would fail a instanceof $wnd.Window and instanceof window.Window check.
What are your thoughts with regard to j2cl and this kind of issue?

What are your thoughts with regard to j2cl and this kind of issue?

J2CL does not make any assumption about the nature of the global scope. Whenever you say JsPackage.GLOBAL, it just means that it should be emitted unqualified. So it would take whatever global context the code is in. It would work the same as if you had written `x instanceof SomeObject. So if the extern does not model correctly the runtime environment you would have the same problem writing native JavaScript.
I know that JavaScript does not perform instanceof automagically but hey I don't think there is much we can do regarding jsinterop_generator ATM.

Didn't read all the discussion but if Chrome has a bug here, we can suggest users to workaround this which should be easy to do so:
for (MutationRecord m: recordJsArray.toArray(new MutationRecord[0])) {
  ...
}

At one point, we should figure out a way to 'optionally' disable type checking for all Elemental.

Bumped into the same issue. Seems to be wider than just the MutationRecord - the DOM nodes which are monitored by the MutationObserver are created as instances of the inner iFrame. This propagates through the entire app as any naive cast of a Node/Element/HTMLElement (e.g. event.target in event handlers) also throws.
The ultimate workaround I'm looking for is the ability to disable type checking in SuperDevMode. Is there maybe a way to do that? -XdisableCastChecking does not work in SuperDevMode, see https://github.com/gwtproject/gwt/issues/9318.

I was able to workaround this by forcing the DevMode linker to run the app code on the main window. This has drawbacks like not being able to use code splitting (I think...)
Anyway this thing solved it for me, perhaps the annotations are redundant:
import com.google.gwt.core.ext.LinkerContext;
import com.google.gwt.core.ext.linker.LinkerOrder;
import com.google.gwt.core.linker.CrossSiteIframeLinker;

@LinkerOrder(LinkerOrder.Order.PRIMARY)
@GwtIncompatible
public class MainWindowDevModeLinker extends CrossSiteIframeLinker {

  @Override
  protected String getJsInstallLocation(LinkerContext context) {
    return "com/google/gwt/core/ext/linker/impl/installLocationMainWindow.js";
  }
}


[BUG] maxTries and tryTimeoutInSeconds are not applied expectedly when using RequestRetryOptions.

Describe the bug
maxTries and tryTimeoutInSeconds are not applied expectedly when using RequestRetryOptions.
tryTimeoutInSeconds was set to 1 second and maxTries was set to 5. Then I tried downloading a large file (100MB).
The large file cannot be download in 1 second. So retry will be executed 5 times.
But retry was executed only once and then download was succeeded unexpectedly.
Could you please tell me if this issue is due to client application?
Could you please tell me if there are any workarounds?
RequestRetryOptions was configured as follows.
        BlobServiceClient blobServiceClient = new BlobServiceClientBuilder()
        .connectionString(connectStr)
        .httpLogOptions(new HttpLogOptions().setLogLevel(HttpLogDetailLevel.BASIC))
        .retryOptions(new RequestRetryOptions(RetryPolicyType.EXPONENTIAL, 5, 1, new Long(10000), new Long(20000), null))
        .buildClient();

RequestRetryOptions
https://docs.microsoft.com/en-us/java/api/com.azure.storage.common.policy.requestretryoptions.requestretryoptions?view=azure-java-stable#com_azure_storage_common_policy_RequestRetryOptions_RequestRetryOptions_com_azure_storage_common_policy_RetryPolicyType_java_lang_Integer_java_lang_Integer_java_lang_Long_java_lang_Long_java_lang_String_
Exception or Stack Trace
I can see that a request was timed out at around 1:51:03.
After 10 seconds later, retry was executed at 1:51:14. But after that no retry was executed.
4月 16, 2021 1:51:03 午後 com.azure.core.util.logging.ClientLogger info
情報: --> GET https://yourstoragename.blob.core.windows.net/sample/testfile
4月 16, 2021 1:51:14 午後 com.azure.core.util.logging.ClientLogger info
情報: --> GET https://yourstoragename.blob.core.windows.net/sample/testfile

Here is the full stdout.
Picked up _JAVA_OPTIONS: -Xmx512m
[INFO] Scanning for projects...
 This is not a problem with exec:java, it is a problem with the running code. Although not serious, it should be remedied.
[WARNING] Couldn't destroy threadgroup org.codehaus.mojo.exec.ExecJavaMojo$IsolatedThreadGroup[name=com.blobs.quickstart.App,maxpri=10]
java.lang.IllegalThreadStateException
    at java.lang.ThreadGroup.destroy (ThreadGroup.java:795)
    at org.codehaus.mojo.exec.ExecJavaMojo.execute (ExecJavaMojo.java:293)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:78)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:567)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  44.081 s
[INFO] Finished at: 2021-04-16T13:51:45+09:00
[INFO] ------------------------------------------------------------------------

To Reproduce
Steps to reproduce the behavior:

I followed the following tutorial. The version of azure-storage-blob was set to 12.10.2.
https://docs.microsoft.com/en-us/azure/storage/blobs/storage-quickstart-blobs-java?tabs=powershell
Upload large files (100MB) to Storage Account.
Navigate to the /src/main/java/com/blobs/quickstart directory
Open the App.java file in your editor and change to following code snippet. (Please change file name, Storage name and the access key.)
Execute following commands.

mvn compile
mvn package
mvn exec:java -D"exec.mainClass"="com.blobs.quickstart.App"

Code Snippet
/* sample code  */
// https://docs.microsoft.com/ja-jp/azure/storage/blobs/storage-quickstart-blobs-java?tabs=powershell

package com.blobs.quickstart;

/**
 * Azure blob storage v12 SDK quickstart
 */
import com.azure.storage.blob.*;
import java.io.IOException;
////////////////
import com.azure.storage.common.policy.RequestRetryOptions;
import com.azure.storage.common.policy.RetryPolicyType;
import com.azure.core.http.policy.HttpLogOptions;
import com.azure.core.http.policy.HttpLogDetailLevel;
////////////////

import java.io.File;

public class App {
	// static
	static String connectStr = "DefaultEndpointsProtocol=https;AccountName=storagename;AccountKey=accountkey;EndpointSuffix=core.windows.net";
	static String file = "C:\\Users\\username\\Downloads\\testfile";
        static String fileName = "testfile";
        static String containerName = "sample";

	public static void main(String[] args) throws IOException {

        BlobServiceClient blobServiceClient = new BlobServiceClientBuilder()
        .connectionString(connectStr)
        .httpLogOptions(new HttpLogOptions().setLogLevel(HttpLogDetailLevel.BASIC))
        .retryOptions(new RequestRetryOptions(RetryPolicyType.EXPONENTIAL, 5, 1, new Long(10000), new Long(20000), null))
        .buildClient();

        BlobContainerClient containerClient = blobServiceClient.getBlobContainerClient(containerName);
        BlobClient blobClient = containerClient.getBlobClient(fileName);
        ///////////////////////////
        blobClient.downloadToFile(file);
        ///////////////////////////

        // File delFile;
        // /*
        //  * delete files for test
        //  */
        // delFile = new File(file);
        // delFile.delete();
	}
}

Expected behavior
Retry should be executed 5 times.
Screenshots
If applicable, add screenshots to help explain your problem.
Setup (please complete the following information):

OS: [e.g. iOS] Windows
IDE : [e.g. IntelliJ] Visual Studio Code
Version of the Library used: azure-storage-blob 12.10.2

FYI
mvn -v
Picked up _JAVA_OPTIONS: -Xmx512m
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Users\username\apache-maven-3.6.3\bin\..
Java version: 16, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk-16
Default locale: ja_JP, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Additional context
This issue was reported from my customer.
Customer would like to fix this issue.
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Bug Description Added
[x] Repro Steps Added
[x] Setup information Added

Hi @takmnagaya
Thank you for reporting this issue. I will take a look at what may be going wrong.

Hello @gapra-msft
I really appreciate your help!
I changed chunk size to 400MB and tried downloading a file (1GB) with ParallelTransferOptions.blockSizeLong.
But retry was executed only once...
Could you please check if this is expected behavior...?
If you need more information, please feel free to contact me!
I used ParallelTransferOptions.blockSizeLong as follows.
        BlobServiceClient blobServiceClient = new BlobServiceClientBuilder()
        .connectionString(connectStr)
        .httpLogOptions(new HttpLogOptions().setLogLevel(HttpLogDetailLevel.BASIC))
        .retryOptions(new RequestRetryOptions(RetryPolicyType.EXPONENTIAL, 5, 1, new Long(10000), new Long(20000), null))
        .buildClient();

        BlobContainerClient containerClient = blobServiceClient.getBlobContainerClient(containerName);
        BlobClient blobClient = containerClient.getBlobClient(fileName);
        ///////////////////////////
        Duration timeout = Duration.ofSeconds(10000);
        // blobClient.downloadToFileWithResponse(new BlobDownloadToFileOptions(file).setDownloadRetryOptions(new DownloadRetryOptions().setMaxRetryRequests(5)), timeout, Context.NONE);
        blobClient.downloadToFileWithResponse(file, null, new ParallelTransferOptions().setBlockSizeLong(400L * 1024 * 1024), null, null, false, null, null, Context.NONE);
        ///////////////////////////

I can see that chunk size was changed successfully from logs.
<-- 206 https://yourstoragename.blob.core.windows.net/sample/testfile (719 ms, 419430400-byte body)<-- END HTTP

First retry was executed at around 4:30:34. But after that, it seemed to me that no retry were executed.
Finally the large file was downloaded successfully. But it was not expected...
Expected behavior is that retries are executed 5 times and download fails.
4月 20, 2021 4:30:23 午後 com.azure.core.util.logging.ClientLogger info
情報: --> GET https://yourstoragename.blob.core.windows.net/sample/testfile
4月 20, 2021 4:30:34 午後 com.azure.core.util.logging.ClientLogger info
情報: --> GET https://yourstoragename.blob.core.windows.net/sample/testfile
4月 20, 2021 4:30:35 午後 com.azure.core.util.logging.ClientLogger info

Here are full logs.
Picked up _JAVA_OPTIONS: -Xmx512m
[INFO] Scanning for projects...
 This is not a problem with exec:java, it is a problem with the running code. Although not serious, it should be remedied.
[WARNING] Couldn't destroy threadgroup org.codehaus.mojo.exec.ExecJavaMojo$IsolatedThreadGroup[name=com.blobs.quickstart.App,maxpri=10]
java.lang.IllegalThreadStateException
    at java.lang.ThreadGroup.destroy (ThreadGroup.java:795)
    at org.codehaus.mojo.exec.ExecJavaMojo.execute (ExecJavaMojo.java:293)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:78)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:567)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  05:21 min
[INFO] Finished at: 2021-04-20T16:35:42+09:00
[INFO] ------------------------------------------------------------------------

Hi @takmnagaya Could you change the value to something more dramatic? It looks like some retries are happening but eventually a request is coming back in < 1s, which is causing the retries to not happen 5 times.
Here is a short PoC that the retry policy does indeed work as intended.
Basically I mock the http client to return a response after 2 seconds (and I am using the same retry policy options that you shared). If you run this, you will see the retry happen 5 times (and it will ultimately throw an exception when the 5 tries are up)
BlobServiceClient serviceClient = new BlobServiceClientBuilder()
                .connectionString(connectionString)
                .httpClient(new HttpClient() {
                    @Override
                    public Mono<HttpResponse> send(HttpRequest httpRequest) {
                        HttpResponse httpResponse = new HttpResponse(httpRequest) {
                            @Override
                            public int getStatusCode() {
                                return 200;
                            }

                            @Override
                            public String getHeaderValue(String s) {
                                return null;
                            }

                            @Override
                            public HttpHeaders getHeaders() {
                                return null;
                            }

                            @Override
                            public Flux<ByteBuffer> getBody() {
                                return null;
                            }

                            @Override
                            public Mono<byte[]> getBodyAsByteArray() {
                                return null;
                            }

                            @Override
                            public Mono<String> getBodyAsString() {
                                return null;
                            }

                            @Override
                            public Mono<String> getBodyAsString(Charset charset) {
                                return null;
                            }
                        };
                        return Mono.just(httpResponse).delaySubscription(Duration.ofSeconds(2));
                    }
                })
                .httpLogOptions(new HttpLogOptions().setLogLevel(HttpLogDetailLevel.BASIC))
                .retryOptions(new RequestRetryOptions(RetryPolicyType.EXPONENTIAL, 5, 1, new Long(10000), new Long(20000), null))
                .buildClient();

        serviceClient.getHttpPipeline().send(new HttpRequest(HttpMethod.HEAD, new URL("https://account.blob.core.windows.net"), new HttpHeaders().put("Content-Length", "0"), Flux.empty()))
                .block();

Hi @takmnagaya Do you have any further questions? If so, feel free to open a new issue. I will close this one as I believe it has been resolved.


Allow specifying colors of only first columns?

Thanks for this package! I like this feature of colored tables. Ideally, one should be able to specify a list of colors that does not correspond to the header (shorter or longer).
For example, one could specify the first 2 colors (red and green) and left the others unspecified, i.e. assume that they have the default color.
colors = [
    pretty_tables.Colors.red,
    pretty_tables.Colors.green
    # next columns are default color
]

Wouldn't that make writing the code much easier,  and would make the code more robust if the no of columns changes?

Sure, that's a sane thing to do when nothing is provided. I've put up PR #5, care to take a look and see if that does what you are looking for?

Perfect! 👍


both operands of "===" should be AnyObject

This eliminates the compiler error. But does it eliminate the root cause? That is, should $0 be Any Object?

The correct fix for this would be to change the extension to:
extension Sequence where Element: AnyObject
While the iterator also uses the Element associated type and that one is constrained to be equal to the Sequence's Element type, the type system only checks the Sequence's Element type in this case, so it can't establish that every element of the Sequence is also an AnyObject anyway when only the Iterator's Element is specified.
Hope that makes sense.


Comment lines in control file break syntax highlighting of line(s) below

Without comment:

With comment:

Nice catch! Can reproduce in v1.3.1.
substvar parsing seems to fall apart with comments and I'll need to investigate this a bit deeper.

Issue present not only in substvar parsing:

Should be fixed in 1.3.2, along with some other minor issues.
Thanks for reporting this! 🎉


release-0.6.2

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 62.39%. Comparing base (ce27599) to head (8a37715).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #922      +/-   ##
==========================================
- Coverage   64.25%   62.39%   -1.87%
==========================================
  Files          48       45       -3
  Lines        5951     5419     -532
  Branches      144        0     -144
==========================================
- Hits         3824     3381     -443
+ Misses       2127     2038      -89

Components
Coverage Δ

apel_plugin
∅ <ø> (∅)

auditor
68.73% <ø> (ø)

auditor_client
94.37% <ø> (ø)

slurm_collector
68.75% <ø> (ø)

slurm_epilog_collector
0.00% <ø> (ø)

htcondor_collector
∅ <ø> (∅)

priority_plugin
37.50% <ø> (ø)


Addded codecov build in travis

I think this works:
https://codecov.io/gh/ant6/beprof
https://travis-ci.org/ant6/beprof/jobs/174296456
Solves #94

py3.6 fails - @grzanka should I add it to "allow failures"?

Add 3.6 to "allow failures" like in pymchelper/pytrip.

https://codecov.io/gh/DataMedSci/beprof also seems to work

Current coverage is 42.03% (diff: 100%)

No coverage report found for master at 3ab415f.

Powered by Codecov. Last update 3ab415f...48b2300


Feature/adopt tflite v2 10

@apurvabisht97 , please test these changes after other PRs are complete. will pull latest changes once they are done.

APK Signing (Refer: https://github.com/Sunbird-Saral/Project-Saral/wiki/Saral-v1.0-release-steps-from-source-code )
Updated AL/ML TF models to tflite v2.10

I have tested gujrat(all) , odisha and up (all) layout this pr is working as expected .


Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
affecting oracle java9 with maven

I'm seeing this too on Gerrit Code Review, and further warnings:
WARNING: Illegal reflective access by com.google.inject.assistedinject.FactoryProvider2$MethodHandleWrapper (file:/home/davido/.gerritcodereview/tmp/gerrit_13189476373589339762_app/guice-assistedinject-4.1.0.jar) to constructor java.lang.invoke.MethodHandles$Lookup(java.lang.Class,int)

Has this been resolved?

Should this be fixed within Guice or within the cglib?

Still happening for me with 4.2.0, even though its release notes list it as Java 9 compatible.

Switching from cglib to ByteBuddy would be a nice fix.

What progress with this? Got it on Spring Boot projects on Java 10. Is ByteBuddy will fix that?
I think this is actual nowadays since there comes Java 11 and Spring will start to support it oficially, It's big thing in Java world.

Very easy to fix...
System.setProperty("com.google.inject.internal.cglib.$experimental_asm7", "true");
Then
--add-opens java.base/java.lang=com.google.guice,javassist

this warning is really anoying pls fix

Did you try latest release 4.2.2?

Should I remove the system property?

For Gradle application plugin:
applicationDefaultJvmArgs = ['--add-opens', 'java.base/java.lang=ALL-UNNAMED']

Note there are 2 different issues when using Java9+

first was the introduction of new bytecode - this has been handled by upgrading ASM, and also CGLIB because it in turn needs to tell ASM to process the new bytecode level
second the introduction of JPMS has brought in new access checks when running applications on the module path - this can lead to warnings for code that uses reflection, like Guice's use of AOP

The second issue will require more changes to CGLIB to use the new lookup API when running on JPMS, rather than reflection. (Either that or switch to use ByteBuddy)
Until then running applications using the classic classpath shouldn't trigger warnings, because the new module access checks don't kick in. Similarly using --add-opens java.base/java.lang=<module-name> to grant access to modules on the module path that use reflection should also remove the warnings.
If you don't need AOP then you could also consider using the no-AOP build which doesn't use ASM or CGLIB, and shouldn't trigger these warnings.

Also found when using Guice - it's better to have an open module for your running app rather than opens/exports package to com.google.guice (for AOP)  - especially for larger projects, the module-info gets bloated and it becomes a little messy.
open module running.app{
        requires com.google.guice;
	requires javax.inject;
	requires aopalliance;
}

Did you try latest release 4.2.2?

yes

Hello.
There is one non trivial thing...
--add-opens flag does not work for custom module layers.
My application creates a custom module layer (on top of the java boot layer) and loads guice module in that layer. --add-opens does not work because it applied only to the boot layer, and boot layer does not contain guice module at it's construction time so that flag is just ignored.
Caused by: com.google.common.util.concurrent.UncheckedExecutionException: java.lang.IllegalStateException: Unable to load cache item
        at com.google.common@27.0-jre/com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2050)
        at com.google.common@27.0-jre/com.google.common.cache.LocalCache.get(LocalCache.java:3952)
        at com.google.common@27.0-jre/com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3974)
        at com.google.common@27.0-jre/com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4958)
        at com.google.common@27.0-jre/com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4964)
        at com.google.guice@4.2.2/com.google.inject.internal.FailableCache.get(FailableCache.java:51)
        at com.google.guice@4.2.2/com.google.inject.internal.ConstructorInjectorStore.get(ConstructorInjectorStore.java:48)
        at com.google.guice@4.2.2/com.google.inject.internal.ConstructorBindingImpl.initialize(ConstructorBindingImpl.java:155)
        at com.google.guice@4.2.2/com.google.inject.internal.InjectorImpl.initializeJitBinding(InjectorImpl.java:595)
        at com.google.guice@4.2.2/com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:932)
        at com.google.guice@4.2.2/com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:852)
        at com.google.guice@4.2.2/com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:291)
        at com.google.guice@4.2.2/com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:222)
        at com.google.guice@4.2.2/com.google.inject.internal.InjectorImpl.getInternalFactory(InjectorImpl.java:938)
        at com.google.guice@4.2.2/com.google.inject.internal.FactoryProxy.notify(FactoryProxy.java:48)
        at com.google.guice@4.2.2/com.google.inject.internal.ProcessedBindingData.runCreationListeners(ProcessedBindingData.java:60)
        at com.google.guice@4.2.2/com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:133)
        at com.google.guice@4.2.2/com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:106)
        at com.google.guice@4.2.2/com.google.inject.Guice.createInjector(Guice.java:87)
        at com.google.guice@4.2.2/com.google.inject.Guice.createInjector(Guice.java:69)
        at com.google.guice@4.2.2/com.google.inject.Guice.createInjector(Guice.java:59)
        at myapp.m1/myappclass(myapp.java:73)
        ... 7 more
Caused by: java.lang.IllegalStateException: Unable to load cache item
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.internal.$LoadingCache.createEntry(LoadingCache.java:79)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.internal.$LoadingCache.get(LoadingCache.java:34)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:116)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:291)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.reflect.$FastClass$Generator.create(FastClass.java:65)
        at com.google.guice@4.2.2/com.google.inject.internal.BytecodeGen.newFastClassForMember(BytecodeGen.java:258)
        at com.google.guice@4.2.2/com.google.inject.internal.BytecodeGen.newFastClassForMember(BytecodeGen.java:207)
        at com.google.guice@4.2.2/com.google.inject.internal.DefaultConstructionProxyFactory.create(DefaultConstructionProxyFactory.java:49)
        at com.google.guice@4.2.2/com.google.inject.internal.ProxyFactory.create(ProxyFactory.java:156)
        at com.google.guice@4.2.2/com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:92)
        at com.google.guice@4.2.2/com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29)
        at com.google.guice@4.2.2/com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37)
        at com.google.guice@4.2.2/com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33)
        at com.google.guice@4.2.2/com.google.inject.internal.FailableCache$1.load(FailableCache.java:40)
        at com.google.common@27.0-jre/com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3528)
        at com.google.common@27.0-jre/com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2277)
        at com.google.common@27.0-jre/com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2154)
        at com.google.common@27.0-jre/com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2044)
        ... 29 more
Caused by: java.lang.ExceptionInInitializerError
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$DuplicatesPredicate.evaluate(DuplicatesPredicate.java:104)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$CollectionUtils.filter(CollectionUtils.java:52)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.reflect.$FastClassEmitter.<init>(FastClassEmitter.java:69)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.reflect.$FastClass$Generator.generateClass(FastClass.java:77)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$AbstractClassGenerator.generate(AbstractClassGenerator.java:329)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:93)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:91)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.internal.$LoadingCache$2.call(LoadingCache.java:54)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.internal.$LoadingCache.createEntry(LoadingCache.java:61)
        ... 46 more
Caused by: com.google.inject.internal.cglib.core.$CodeGenerationException: java.lang.reflect.InaccessibleObjectException-->Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to module com.google.guice
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$ReflectUtils.defineClass(ReflectUtils.java:464)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$AbstractClassGenerator.generate(AbstractClassGenerator.java:336)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:93)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:91)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.internal.$LoadingCache$2.call(LoadingCache.java:54)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.internal.$LoadingCache.createEntry(LoadingCache.java:61)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.internal.$LoadingCache.get(LoadingCache.java:34)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:116)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:291)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$KeyFactory$Generator.create(KeyFactory.java:221)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$KeyFactory.create(KeyFactory.java:174)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$KeyFactory.create(KeyFactory.java:157)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$KeyFactory.create(KeyFactory.java:149)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$KeyFactory.create(KeyFactory.java:145)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$MethodWrapper.<clinit>(MethodWrapper.java:23)
        ... 57 more
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to module com.google.guice
        at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
        at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
        at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
        at java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$ReflectUtils$1.run(ReflectUtils.java:61)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.core.$ReflectUtils.<clinit>(ReflectUtils.java:52)
        at com.google.guice@4.2.2/com.google.inject.internal.cglib.reflect.$FastClassEmitter.<init>(FastClassEmitter.java:67)
        ... 54 more

any update?

+1

It is fixed and correct, there is nothing more needing to be done

The library is correctly blocked from reflecting on java.lang, the opens clause correctly fixes this
JPMS is strict encapsulation, so your packages have to be "open" to private/protected field inject, (which is now a bug, so dont ever field reflect again)
Entertaining strict encapsulation correctly fixes any opens clauses
Opening the base module, opens all the jdk modules (except for jdk.unsupported), this is why an open module works
Opening your module does not break strict encapsulation beyond your module, every requires is still in its chains and constraints, minimal performance impact is felt by opening your module.
While a bit lazy, specifying the running base module as open also removes any --add-opens clause you need making it feel exactly like previous JRE's.

I strongly feel this issue can be closed as fixed, as it is correct, and it is adhering to JPMS standards.

You mean the fix ist, that everyone needs to add an --add-opens to java.lang for guice??

Yes, That's called Strict Encapsulation. That's called, perfection.
You can be lazy as well however.
Option 1 for strict encapsulation and pure JPMS, and yes it is correct, and amazing, and unbelievably blazing fast.
Option 2 is opening your base module so that the java.base/java.lang automatically assumes opened. The module hierarchy is still maintained, and all your classes still execute in the modular engine,
open module my.module {
}

Welcome to the future! It's scary, but it is honestly amazing, if you are willing to put the old tools down, and pick the new tools up.

An example of each method :

Strictly Defined Enterprise Web App Example - https://github.com/GedMarc/JWebMPHomePage/blob/master/src/jre11/java/module-info.java
Loosly Defined Enterprise Web App Example - https://github.com/GedMarc/JWebMPHomePage/blob/master/src/jre11/java/module-info_openmodule.txt

This is running hibernate 3.5.7 persistence with hazelcast 3.10.4 100% modular with (btm-jpms), (uadetector-core-jpms), (guiced-injection), etc etc. There is also Rabbit MQ managing JMQ
I chose the ugly way in fact, i prefer the modular hierarchy strict and don't mind using --add-opens, plus there's is a 260ms drop in boot time
JRE 8 to pure JPMS is a 8 second drop in boot time from 11 seconds to 3, which is always nice.
I'm a fan of it now (if you haven't noticed), but truly hated it, as I guess we do with everything new.

Is this something that Google can and will fix in the future? Does this mean my application that uses Guice with an injector will stop working in newer versions of Guice (or newer versions of Java)? The part of this message that concerns me is this as I am not sure what it means:
WARNING: All illegal access operations will be denied in a future release

Why don't you write your application to adhere to JPMS?
All private and protected field reflection no matter the library will have this, and again, it is correct. Don't remove your libraries, define your application correctly?

I'm not sure I understand how libraries throwing an error means I'm writing my application incorrectly when the error explicitly says: WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
What does that have to do with my code and my application? What do you mean define my application correctly?
I literally just upgraded from Java 8 to Java 11 all in one go so all of these errors and warnings I received are confusing. Java is starting to feel more like a community project rather than a robust, enterprise company-backed language.
How is libraries throwing a warning (and it sounds like eventually an error) my fault in any way when the warning tells me to report it to the maintainers of the library?

I don't think you understand JPMS,
You can't just "Move from JRE8 to JRE11", not possible.
You can't enable AOP without opening the package to google guice,
You can't inject private and protected without opening the package to google guice.
You simply just can't do it.
You're asking to rollback JPMS so your application that ran in JRE 8 will run in JRE 11, if that's what you want, then run in classpath mode which will be completely dropped in JRE12 and no illegal access at all will be used, and that will be the limit of JRE updates you will ever do.
If you don't jump on the boat for JPMS, don't complain about your ClassPath app not working in a modular system.
They are not commenting on the issue, because there is no issue other than a lack of fundamental understanding on your part.

Guice works just fine in JPMS, so much so that I have JTA, JPA, MQ, Proxying, and everything else running under it. Problem here is not Guice.

then run in classpath mode which will be completely dropped in JRE12

AFAIK there is no plan to remove the classpath in Java 12. The modulepath and the classpath are going to coexist for a long time.

as far as I'm aware, JDK 12 Is the last JRE with relaxed illegal access (JEPS261), JRE 13 will be purely strict only.
If you are still confused about your very standard jdk error  - https://blog.codefx.org/java/java-11-migration-guide/#Illegal-Access-To-Internal-APIs
Here's what you need to do, create an open module, or open java.base so that you tell java to enable proxy classes.
Whether you use byte buddy, cglib, javaassist or even just custom proxying, you will have to perform these steps.
If you don't want to do that and stick with classpathing, you need to understand that your development path has an end date, but you can always just --illegal-access=allow which is definitely not recommended but will do what you want it to.
Your message is saying cglib is trying to proxy, but you haven't allowed cglib to proxy anything.

This is very confusing to me. So I fixed illegal access to internal APIs - that's easy, I just removed all sun.* and com.sun.* imports and replaced it with either identical java.* imports or simply re-wrote sections of code. That's fine.
I have no idea what JPMS is or what these classpath vs modulepath changes are all about. I load in dependencies (libraries) for one of my applications with gradle and another application just through my IDE. Does this mean that the way all dependencies are loaded will have to change - both for gradle and otherwise, from "classpath" to "modulepath"? I don't even know what classpathing is, nor what illegal reflective access is or modulepathing or even what proxying is. I don't understand why some libraries throw this warning while others do not. I have asked literally 5 of my most expert Java friends and they don't even know what JPMS is let alone the steps required here to fix this issue. I am at a loss here.

Um, shew, that's a topic for a different thread. But I guess it may help a bit?
This is my experience, if I am incorrect in any way please correct me, I am learning just as much as everyone else!
So it's very easy actually, there's a curse with backwards compatibility, anything "new" has to be done differently, you can't change existing things, just "update" them (like FileOutputStream to FileChannel had to be new, where-as a simple update to the math class would suffice with floating methods. Some classes like util.properties have been incorrect with types and a random serial version id since 1.0
It only changed to a class version in 1.03, it should have just been 1L, and in JDK 1.4 the structure should have removed hashtable, but the JDK has been getting dirtier and dirtier and slower and slower just to support this backwards compatibility, and we've been getting too used and too comfortable with it.
So yes, the JVM has changed enormously, but still backwards compatible, you have to add stuff to command line sometimes to enable things that should have been possible without a strict specification anyway because  ;)
JPMS is a change in how classes are loaded and accessed, it fixes it, and adheres to all encapsulation defined by OO and adds a new layer of encapsulation on the package horizontal layer
It's a method of class containing and loading (without container loaders ejb/war/etc) that strictly enforces access to certain packages correctly, and too associated libraries. Instead of a bundle of mud, a proper domain driven platform that is clean, contained, and internal public classes in external libraries are no accessible (oh thank gawd)
It is a full replacement for

Class Containments (The purpose for EE to exist)
OSGi (It is naturally built in)
Object Pooling (Class Data Sharing)
Downwards Injection (Using that fastest way imaginable to load classes - SPI JDK1.6 rewritten for JDK1.9)
It is not a replacement for
Distributed Computing (It is domain driven so Centralized Computing is the way to go, rest services, micro modules etc)

JPMS is enabled by added a module-info.java file to the root of your sources and has a completely new structure which you can read about everywhere with a google.
After struggling and 140 projects using this darn thing, It is fast, it is clean, the code is fantastic. The module-info in enterprise application could get disgusting as the examples up top show, but the performance impact is minimal.
Sorry for destroying the thread.

So in Java 12/13, in order to solve this warning from turning into an error I need to create a module-info.java and essentially somehow reference that I would like to use guice for my application, and then the rest of my application should continue working and this warning/error should be gone? Is that correct?

Here is a full RAW JPMS Guice Implementation, I do not know Gradle, but everything can open pom's :
guiced-jpms.zip
Output
[INFO] --- exec-maven-plugin:1.6.0:java (default-cli) @ helloworld-jpms ---
Configure Imported Module Called. This will make the warning
Configure Exported Module Called. This will not make the warning
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/c:/AESoft/Maven%20Repository/com/google/inject/guice/4.2.2/guice-4.2.2.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Calling method : interceptMe
Was annotated with : This Was Intercepted
Intercepted
Successful
Done

gitter...

Oh, No, Only for injection libraries, like guice, weld, spring, etc etc
So far my list is
opens xxx to com.fasterxml.jackson.databind, com.google.guice, javax.xml.bind
This is @Annotated fields to be read and deseriealized into JSON, XML and gets injected by Guice
Any library that reads private and protected fields is affected and will need an opens clause.
And when there is hibernate i need to open my entities for the byte buddy proxies, I'm a using an object query engine called entity assist that also reads @Column data.
opens xxx to org.hibernate.orm.core, com.fasterxml.jackson.databind, com.google.guice;

Here is the simple answer of fixing this issue after my experimenting most of today.
Assuming your code is in a folder called: org.package
module org.package {     requires com.google.guice; }
and we may need to require other dependencies, for example if we are using swing the compiler may throw this error:
Error:(15, 13) java: package javax.swing is not visible(package javax.swing is declared in module java.desktop, but module src does not read it)
then we would need to also add requires java.desktop;
then we should be able to compile our program, and the warning/error about illegal reflective access should be gone. However, I have not been able to test this as my program requires other dependencies to be declared as modules and unfortunately for example lombok does not have full module support yet.
Here is a great article for reading more about Java 9 modules: https://gorillalogic.com/blog/understanding-java-9-modules/(edited)

Lombok works fine with JPMS, the problem is elsewhere, who on earth are the "Java Experts" you got to?~?~?~?
A library does not need to be a module in order to work with JPMS, it will assume automatic naming mechanism,
Lombok is not a library nor a dependency but an annotation processor. It should never be packaged with your app AT ALL in any circumstance, or declared a dependency for any application!!!
for maven
 <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.0</version>
                <configuration>
                    <source>${project.java.version}</source>
                    <target>${project.java.version}</target>
                    <encoding>${project.build.sourceEncoding}</encoding>
                    <!--<compilerArgument>-proc:none</compilerArgument>-->
                    <annotationProcessors>
                        <annotationProcessor>lombok.launch.AnnotationProcessorHider$AnnotationProcessor</annotationProcessor>
                    </annotationProcessors>
                </configuration>
            </plugin>
</plugins>

urgh, enough.

Upon doing more research and testing, I think this may be something that the guice package maintainers can fix. For example, I was using netty-all version 4.1.13 in one of my projects and I noticed that they had fixed illegal reflective access: https://github.com/netty/netty/issues/8318 in version 4.1.30, so I upgraded to netty-all 4.1.30 and I noticed that the warning had gone away.
So, I think there is a reason why it says "please consider reporting this to the maintainers" - this is something that they should in theory be able to fix.

Tagging @sameb
Is this anything you might be able to fix (removing the reflective access, like how netty-all removed reflective access in their library by not relying on a sun.* class)? I really would like to see this get fixed so I can not have to use JPMS to avoid this warning (and eventually error, plus JPMS causes other issues for me currently) and so I can just continue using guice in Java 12 and onward. Of course this isn't particularly high priority but is this something that could possibly be done down the road?

I wouldn't consider it fixed as long as Guice (via cglib) uses the ClassLoader.defineClass(...) method. If the issue was "fixed", people would not be required to open java.base/java.lang. Apparently the cglib-people are not going to change that though, because cglib is no longer actively developed.
Interesting blog post about this: https://mydailyjava.blogspot.com/2018/04/jdk-11-and-proxies-in-world-past.html
I'm not sure how feasible it is, but have you looked into switching to Byte Buddy or Javassist?

I'm experimenting with moving Guice to Byte Buddy - early days, but no blockers yet

very neat stuart, let me know how it goes or if you'd like any help along the way.

Hey @mcculls how goes moving Guice to ByteBuddy? Is there a branch of a repository or possibly a separate issue where we can follow the progress of this or if you run into any blockers?

might as well not use modules at all

🔔 🔔 🔔
Also it would appear that injection doesn't work in my Travis environment due to this issue?

What's the current status? I'm having this with Java 12 and Guice 4.2.2.

`me@ubuntu-18.04.1:/# mvn archetype:generate                      \

"-DarchetypeGroupId=io.cucumber"
"-DarchetypeArtifactId=cucumber-archetype"
"-DarchetypeVersion=<IP_ADDRESS>"
"-DgroupId=my-stuff"
"-DartifactId=my-stuff"
"-Dpackage=my-stuff"
"-Dversion=1.0.0-SNAPSHOT"
"-DinteractiveMode=false"
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release`

Sorry for the lack of updates: I've decoupled all uses of CGLIB in an experimental branch and introduced a set of interfaces that cover what Guice needs. I'm currently implementing those with generators that work with recent versions of the JVM. Will post a bit more detail later this week.

@mcculls Can you give more details and maybe an ETA? Thanks!

How is the progress?

Hey @mcculls, thanks for tackling this.
This prohibits us at Gradle Enterprise to upgrade to JDK 11, could you please give us an update on the ByteBuddy migration progress?
Thanks! :)

Any update?

Is this problem corrected?

I found the following branch with no commits since April 6
https://github.com/mcculls/guice/tree/experiments

Yes I'm still working on this (balancing it with my day job and family commitments, which is why unfortunately it is taking longer as expected as the last few months have been very busy on both fronts)
I did find a good chunk of time last weekend which helped move things along, and hope to do the same this weekend.

I experience the same warnings with a Play Framework app running in an adoptopenjdk/openjdk11:alpine Docker container.

Any updates? @mcculls Are you still working on a fix?

Yes I'm still working on this, just sorting out the last piece of glue for enhanced classes.

@mcculls When do you think the fix could be pushed to upstream?

@mcculls  +1

@mcculls +1

Some findings:
Adding VM option --add-opens java.base/java.lang=com.google.guice,javassist as suggested above gives another warning:
WARNING: Unknown module: com.google.guice specified to --add-opens
WARNING: Unknown module: javassist specified to --add-opens

However, after adding VM option --add-opens java.base/java.lang=ALL-UNNAMED all warnings disapear.
System.setProperty("com.google.inject.internal.cglib.$experimental_asm7", "true"); is obviously not needed anymore.

Where to add  --add-opens java.base/java.lang=ALL-UNNAMED?

As an environment variable in your O.S.
The change does generate the given warning as a system wide operation, and is catered for as the standard ref (http://bugs.java.com/view_bug.do?bug_id=JDK-8170832), introduced in JDK 9 as a safe usage for having both JDK 8 and JPMS on a single system.
https://www.oracle.com/technetwork/java/javase/9-new-features-3745613.html
https://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-3B1CE181-CD30-4178-9602-230B800D4FAE
It is not a good idea to "ALL-UNNAMED" anything, although yes you can do it and it will definitely work. Your application will not be JImage compatible, a.k.a won't be able to build JMod, JLink and JPackage for distribution.

i think, that no one, can solve this problem))

It's not a problem, it's by design.
People are looking for a way to go back to open classpath's without warnings, the forward movement of Java is modularization though, so it's competing designs and lots of people aren't comfortable with it.
That's all

I don't think there is unsolvable software problem. If the solution isn't possible some way, there is one another way.

Latest status: got a sizeable application with method interception working using my locally patched version of Guice and no illegal reflective access warnings using recent JDKs :)
Just a couple of failing unit tests to fix which should be sorted tomorrow. I'll put together some instructions at the same time along with an overview of all the changes/improvements in a PR. Should have it ready for people to try out and give feedback later this week.

I experience the issue too with:
Gradle 6.2
JDK11
Guice 4.2.2

About the warning. Someone said it is "unsolvable software problem".
I am curious why Spring is OK but Guice isn't OK. Both of them are DI frameworks.

@mcculls Is there anything we can do to help out?

spring is not ok at all, it cannot run anything as modular (-m package/module)

Seeing this error when running Maven quick start on Ubutnu 18.04:
$ mvn archetype:generate -DgroupId=com.toby -DartifactId=generic-class
es-and-interfaces -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false

[...]
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
[...]

@wolf99 I assume that's using Ubuntu's own custom distribution of Maven? The official Maven distribution uses the "no-AOP" build of Guice which doesn't contain any CGLIB code. If you download an official distribution from https://maven.apache.org/ then you shouldn't see the warning.

Reporting back for others that may have stumbled across the same issue as I, namely maven installed from the 18.04 Ubuntu PPA (probably using apt install maven).
I uninstalled the Maven from the PPA (apt remove maven) and installed the package from the  Maven website (recorded instructions that worked for me here: https://github.com/wolf99/dotfiles/blob/master/how-to-update-vim.md).
This resolved the warning. Now you just need to remember that Maven needs to be updated manually.

I've temporarily deployed a unofficial beta of Guice with the new AOP code to a Maven repository under https://github.com/mcculls/guice-betas/tree/gh-pages so adventurous users can try it out and report back while other testing and reviews continue.
There's also a source archive if people want to build or look over the code locally.
This an unofficial beta for community testing purposes and shouldn't be used in production

Passes unit our internal project unit tests without issue on JDK11 and JDK13, I also deployed a test build of an internal application relying heavily on AOP with this new code on JDK11 and had no issues, looking very promising!

I've been running this in prod on JDK 14 with no issues - even without the latest 2 commits...

@mcculls Your beta runs smoothly when applied within Play Framework: https://github.com/playframework/playframework/pull/10202
Play uses Guice as default runtime DI framework, there a lot of tests, running both on JDK8 and JDK11, also cross build against Scala 2.12 and Scala 2.13:
https://travis-ci.com/github/playframework/playframework/builds/161231905
The beta looks very promising!

@mcculls +1

+1

So when is this out on maven? :)

I am waiting for this to be out too.

Have the same warning when using JDK 11 and plain maven project. The version of Guice is 4.1.

+1

I've temporarily deployed a unofficial beta of Guice with the new AOP code to a Maven repository under https://github.com/mcculls/guice-betas/tree/gh-pages so adventurous users can try it out and report back while other testing and reviews continue.
There's also a source archive if people want to build or look over the code locally.
This an unofficial beta for community testing purposes and shouldn't be used in production

Nice work with the unofficial beta!
Are there plans to roll this into an official Guice release? If so, is there any timeline that could be shared on when it would be available?

@mcculls Your beta runs smoothly when applied within Play Framework: playframework/playframework#10202
Play uses Guice as default runtime DI framework, there a lot of tests, running both on JDK8 and JDK11, also cross build against Scala 2.12 and Scala 2.13:
https://travis-ci.com/github/playframework/playframework/builds/161231905
The beta looks very promising!

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/home/mikail/.cache/coursier/v1/https/repo1.maven.org/maven2/com/google/inject/guice/4.2.3/guice-4.2.3.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Getting this with Play 2.8.2. Not sure if I have followed the above thread correctly but will the Playframework be issuing a new release with the fix.

@mikail-khan it's unlikely that any official play release has incorporated the guice change yet, since we haven't released any official guice releases with it.
we're working on incorporating it (running it against all of Google's tests and doing some code reviews).
@mcculls -- I'll be adding some comments to the PR early next week (been a busy month for me, and my daughter's bday is tomorrow, so i've been a bit backed up).  mostly just questions, no big issues.. everything looks great.

Just tested 4.2.4-20200419-NEWAOP-BETA on my project. It works fine 👍

For the record: The pull request to fix this issue is #1298

fixed in https://github.com/google/guice/commit/85e30beafe55551a649025d3c12e831214057412.

Wow I've been waiting for this for very long, thanks! When will the official version containing this fix be released?

I have been eyeing this for quite some time. Took almost 3 years but I guess the wait is finally over.

Can you cut a release so that we can actually use the fix? Thank you.

The issue repeats in #1216

Warnings still appearing:
java:
openjdk 14.0.1 2020-04-14
OpenJDK Runtime Environment (build 14.0.1+7-Ubuntu-1ubuntu1)
OpenJDK 64-Bit Server VM (build 14.0.1+7-Ubuntu-1ubuntu1, mixed mode, sharing)
os:
Description:	Ubuntu 20.04.1 LTS
./fix_engine.sh
Installing our local jbullet.jar and stack-alloc.jar into the maven local repository
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

@masuch Have you tested against a custom build of Guice? Because I see that you use /usr/share/maven/lib/guice.jar which I heavily guess seems to be a proper release, not a custom build. The fix has not been released in a proper release yet, so if you would expect the warnings to disappear, you would have to have your own custom build of Guice at the moment.

fixed in https://github.com/google/guice/commit/85e30beafe55551a649025d3c12e831214057412.

@sameb can you do a release with the fix?

If you don't use Guice for AOP (e. g. only use it for injection), then replacing
<dependency>
  <groupId>com.google.inject</groupId>
  <artifactId>guice</artifactId>
  <version>4.2.3</version>
</dependency>

with
<dependency>
  <groupId>com.google.inject</groupId>
  <artifactId>guice</artifactId>
  <version>4.2.3</version>
  <classifier>no_aop</classifier>
</dependency>

might work around this issue.
(I'll skip the almost obligatory comment on how Google's handling of the open-source project under its control reflects on it. My personal lesson is that I'm slowly phasing out the existing use of open-source libraries owned by Google and banning the adoption of new ones, because if this is how things work, then depending on some random single-developer hobby project feels like a more reliable choice.)

(I'll skip the almost obligatory comment on how Google's handling of the open-source project under its control reflects on it. My personal lesson is that I'm slowly phasing out the existing use of open-source libraries owned by Google and banning the adoption of new ones, because if this is how things work, then depending on some random single-developer hobby project feels like a more reliable choice.)

I completely agree with you.

That's not how we should celebrate the 3rd anniversary of this issue folks.
In addition, there's no other DI library out there apparently.

There is Dagger.

Oh, I just discovered that Dagger is now forked by google. The original has no commit since 3 years.

There's a beta release, peeps! 5.0.0-BETA-1
Let's try it out!

Just upgraded to 5.0.0-BETA-1 in Play Framework, looks good:
https://github.com/playframework/playframework/pull/10506

I'm using it in production since 9 days now. Works fine

Sadly, the no_aop artifact disappeared. Was this intentional?

@soc Yes, see the release notes @ https://github.com/google/guice/wiki/Guice500#guice-core

I have tested 5.0.0-BETA-1 and detected no problems

Is there a a rough roadmap or release date for the final version?

Is there a a rough roadmap or release date for the final version?

@sameb @markmarch ?

No news about a final release?

No news about a final release?

No news about a final release?

Probably in the next few weeks. The final release will be pretty close to the BETA release so in the meantime you can probably depend on the BETA version.

No news about a final release?

Probably in the next few weeks. The final release will be pretty close to the BETA release so in the meantime you can probably depend on the BETA version.

No news about a final release?

Probably in the next few weeks. The final release will be pretty close to the BETA release so in the meantime you can probably depend on the BETA version.

@markmarch So, three weeks on and no new bug reports about BETA 5[*]. The release must be imminent, no? :wink:
[*] There is https://github.com/google/guice/issues/1451 but that's been there for a while and I can't tell how serious it is.

Awaiting a final release to address this bug

I use guice:5.0.0-BETA-1 in production for months now. Try it out!

I use guice:5.0.0-BETA-1 in production for months now. Try it out!

I have, but some of us depend on other packages that depend on Guice, and whose maintainers won't release with a dependency on a beta version of something or other (and rightly so).
And so another week passes without any response from @markmarch or @sameb … Only some 5 weeks to go and we will be celebrating a whole year without any new (non-beta that is) release. :champagne:

Just FYI, Guice 5.0.1 that was released in February 2021 seems to have resolved this issue. I had to find out it was released by going to mvn repository.


Still relevant?

With the hid-sony kernel module adding better support for this device into the kernel itself, is this still relevant for normal usage, eg none of the profiles and xpad and such?

I only use it to get my controller battery percentage. Any way I can do it without ds4drv?

Yes, battery usage shows up under /sys/class/power_supply/..../capacity. For example, the battery power for my trackpad can be found at:
/sys/class/power_supply/hid-28:37:37:2e:07:82-battery/capacity

@benmoran56 Awesome tip. Thanks.

better useful if this exit as library to other programs

I have 4.3.3 kernel, and I cannot get my controller to work over bluetooth without ds4drv. I might miss something, but this really makes ds4drv still relevant.

The plug-and-play kernel driver should work nicely, but ds4drv still have many advanced features compared to it. There are two ways to use ds4drv:

Raw bluetooth mode (default) provides an alternative way to use the controller. This may be useful in case the kernel driver doesn't work or has some issues.
Hidraw mode (--hidraw) uses the kernel driver and automatically gets all its features. In addition, ds4drv also adds its features like profiles and advances keymappings.


add PageUtil interface with utility method

Issue: jhipster/generator-jhipster#9209
add PageUtil interface with method for creating a page from a list
resolve jhipster/generator-jhipster#9209

Thanks @Gigaxel


Create Backlog

There should be a backlog of questions to answer. The backlog should be maintained in the form backlog/<item>.md where <item> should be <priority>-<title-slug> for each backlog item.

/pilot Search the internet for important questions to ask wrt our project goal and populate the backlog with 4 items, each being one important question on the topic. Also create a Backlog class in backlog.py that can be used to add/remove items, list them and re-prioritize them

/pilot Search the internet for important questions to ask wrt "AI replacing human labor" and populate the backlog with 4 items, each being one important question on the topic. Also create a Backlog class in backlog.py that can be used to add/remove items, list them and re-prioritize them


Feature - dnscrypt-proxy

Feature Request:
Can we have dnscrypt-proxy installed by default and have a dedicated webpage to configure the options.

We can have this as a plugin, which means it can be installed via GUI either manually or by (maybe) config import on setup, but it'll still require someone to contribute the GUI pages for configuration. The package itself is already there as is the plugin framework. :)


Add fills

@bherd This PR add a Fill class that is used to represent a matched pair of ask and bid orders and a particular transaction price.  and quantity.  A yet to be defined auction mechanism processes ask and bid orders and generates Fill instances.  The generated Fill instances will be sent to a settlement mechanism which would handle the exchange of resources (i.e., goods for money).

@bherd-rb This PR is not longer relevant as we have already incorporated a basic Fill class into the API.


Possible improvements

[ ] Use Num (Expr a) to have available the operators *, / instead of |*|, |/|

[X] Alternative: keep them to unify the syntax with |:|, |^|, |$|

[x] Show constructions of tables separately, step by step. Present in this order: data, headers, styles
[x] Add language extensions into the example
[x] Put constant values into the builder, without intermediate records
[x] Rename Cell into CellRef
[x] Cell, Expr aren't Functors. use unsafeChangeCellType

Use DataKinds to disallow some operations like |+|, |-| on arbitrary types
data ExcelType = ExcelInt | ExcelDouble | ExcelString

class ExcelNum (a :: ExcelType)
instance ExcelNum ExcelInt
instance ExcelNum ExcelDouble

data Expr a where
  Add     :: {- ExcelNum a => -} Expr a -> Expr a -> Expr a
  Concat  :: Expr ExcelString -> Expr ExcelString -> Expr ExcelString

instance ExcelNum a => Num (Expr a) where

[ ] Add a mechanism for deriving Generic instances to get generic RowBuilders straight from data records. See optparse-generic


Make tabs in Docs sticky

Link to the Page
No response
Describe the Issue
For vertically extensive components, it might be good to make them sticky- it's always a pain to have to scroll back up to tab over to the Props page.
Are you able to create a Pull Request with the fix?
Yes

Yeah the current UI is pure utilitarian. I have some ideas to make it fancy! Perhaps as part of: https://github.com/Brain-Bones/skeleton/issues/374

I think for now I'm going to close this out. The docs will be due a visual overhaul pre-launch, but I'll tackle that as a more comprehensive pass. Thanks for the suggestion, we definitely need something like this!


Site: Turn Launch pannel logos into links

bundle
maven plugin
sbt plugin
jenkins plugin

Closing, building new website


Subscribe Form not working!

Subscribe Form in Footer not working.
https://user-images.githubusercontent.com/97230777/156583836-faecf2f1-6350-4469-b9cc-d920749aa845.mp4
@SahityaRoy

Hello sir, I am a GSSoC'22 participant. I would like to work on this issue if you can assign me.

Hello sir, I am a GSSoC'22 participant. I would like to work on this issue if you can assign me.

Tag @SahityaRoy he can assign you issues.

Hello sir, I am a GSSoC'22 participant. I would like to work on this issue if you can assign me.

@SahityaRoy

Hello @SahityaRoy Sir, I am a GSSoC'22 contributor. I can make the subscribe button workable So I want to work on this issue. Please assign me.

@KartikVerma0 if you are free then please let me know

@KartikVerma0 if you are free then please let me know

I am free and would like to work on it.

@SahityaRoy Currently i am not free you can assign this to someone else.

I would like to work on this!

Hi there,
I am Navya Bhatia and a part of GSSOC’22 as a contributor . I can solve this issue and therefore requests to please assign this issue to me .
Thank you
@SahityaRoy


bugfix/ZENKO-436 retrieve correct read location constraint

(cherry picked from commit b7fb3797030f229a6d3b04db82fc6657dcc753ed)

some typo fixes

older pr: #1264

PR has been updated. Reviewers, please be cautious.

@bert-e help

Hello alexanderchan-scality,
My role is to assist you with the merge of this
pull request. Please type @bert-e help to get
information on this process.
Status report is not available.

@bert-e help

Help page
The following options and commands are available at this time.
Options

name
description
privileged

:arrow_right: bypass_tester_approval
Bypass the pull request testers' approval
:star:

:arrow_right: bypass_commit_size
Bypass the check on the size of the changeset TBA
:star:

:arrow_right: after_pull_request
Wait for the given pull request id to be merged before continuing with the current one.

:arrow_right: bypass_incompatible_branch
Bypass the check on the source branch prefix
:star:

:arrow_right: bypass_author_approval
Bypass the pull request author's approval
:star:

:arrow_right: bypass_build_status
Bypass the build and test status
:star:

:arrow_right: wait
Instruct Bert-E not to run until further notice.

:arrow_right: create_pull_requests
Allow the creation of integration pull requests.

:arrow_right: bypass_jira_check
Bypass the Jira issue check
:star:

:arrow_right: bypass_peer_approval
Bypass the pull request peers' approval
:star:

:arrow_right: unanimity
Change review acceptance criteria from one reviewer at least to all reviewers

:arrow_right: no_octopus
Prevent Wall-E from doing any octopus merge and use multiple consecutive merge instead

Commands

name
description
privileged

:arrow_right: build
Re-start a fresh build TBA

:arrow_right: reset
Try to remove integration branches unless there are commits on them which do not appear on the source branch.

:arrow_right: status
Print Bert-E's current status in the pull request TBA

:arrow_right: retry
Re-start a fresh build TBA

:arrow_right: clear
Remove all comments from Bert-E from the history TBA

:arrow_right: help
Print Bert-E's manual in the pull request.

:arrow_right: force_reset
Delete integration branches & pull requests, and restart merge process from the beginning.

@bert-e reset

Reset complete
I have successfully deleted this pull request's integration branches.

@bert-e build

Not implemented
This command will be implemented soon.

@bert-e bypass_jira_check

@bert-e clear

Not implemented
This command will be implemented soon.
The following options are set: bypass_jira_check

@bert-e force_reset

Reset complete
I have successfully deleted this pull request's integration branches.
The following options are set: bypass_jira_check

Waiting for approval
The following approvals are needed before I can proceed with the merge:

2 peers

The following options are set: bypass_jira_check

PR has been updated. Reviewers, please be cautious.


Media converter fix

Description
Please describe your pull request:

Why is it necessary?
Under PHP 7 if NULL is passed to convertMediaStruct, e.g. if the image is missing, an unrecoverable fatal error is thrown. If this happens inside digital publishing, it can cause whole shopping worlds to fail to load. The first line of the function checks that $media is an instance of StoreFrontBundle\Struct\Media meaning the type declaration isn't strictly necessary.

What does it improve?
Fixes a bug.

Does it have side effects?
IDE auto-complete.

Questions
Answers

BC breaks?
no

Tests pass?
no

Related tickets?
n/a

How to test?
Set up a digital publishing banner with a broken image, migrate from local image storage to s3 then try and load the digital publishing banner

Hey @MFCBS and thanks for your contribution.
I think we should declare the parameter as nullable so we can get rid of the duck typing and stay consistent with other methods.
Could you change and test it, please?

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/#/issues/SW-17548.
Please use this issue to track the state of your pull request.

Hey @MFCBS,
we fixed the problem in our Digital Publishing plugin, as we don't want to change die typehint in the media converter.
Also fixed our storytelling plugin.
Best regards


Change Main_Window title #27

[ ] Change main_window's title from python to CPF

Solution:
Remove QStackedWidget


[master] Avoid incorrect cache cause IllegalArgumentException

Avoid incorrect cache cause IllegalArgumentException: method POST must have a request body

I assume something went wrong here.


added a comment in readme

added a comment in readme

Sorry i don't see how this contribute to the project but feel free to make a new pull request :)


Function does not exist in scikit_network library：membership_matrix

Hello, I tried to cite your work and reproduce your code. But I met a serious problem.
You guys use the library ‘scikit_network’ in cf_utils.py, but I find this line of code reports an error:
from sknetwork.utils import membership_matrix.
The file ‘sknetwork.utils’ does not include the function ‘membership_matrix ’ at all.
I checked all the references for this library，and I did not find this function.
At the same time，there is a version error in requirements you offered.
pytorch = 1.6.0 is too old and is not available.
I hope you guys can provide a usable code.
Thank you again for your excellent work！

Hi, thanks a lot for you interest in our work!
Regarding the membership_metrix function, I found that they changed its name to get_membership. More details can be found in this PR. Can you try using the new name when running with a newer version of scikit-network?
Regarding how to install PyTorch 1.6.0, I would suggest you to follow the instructions provided by PyTorch here.
Hope these helps :)

Closing this issue as there's no followup questions. Please feel free to open a new issue or re-open this one if you encounter other problems.


Add missing django-allauth empty View

Hello,
A NoReverseMatch exception is thrown during signup when using django-allauth and ACCOUNT_EMAIL_VERIFICATION is set to 'mandatory'.
This happen because django-allouth tries to reverse a missing route: https://github.com/pennersr/django-allauth/blob/master/allauth/account/adapter.py#L458.
I added an empty view to avoid this.
The view was already there some time ago and removed on this commit: https://github.com/Tivix/django-rest-auth/commit/0fc4d56dae860be87809d8c9368f7cae28e14a44#diff-c6d8840dbabc2fb43a1d18876004f17a. Please let me know if it was any reason for this, I can't see any.
This can also be avoided by importing django-allauth urls but I would prefer not to. Also, the documentation doesn't say you should.

Coverage remained the same at 96.365% when pulling c5970df8f8132e21fa039591ffbf265323579072 on tanoabeleyra:master into 479a40d2ccd69d69f7a05d716f30239dd3ef2343 on Tivix:master.

Given the lack of response here (and most of the PR/issues) I'll just make a fork, thanks anyway.


Upgrading Jest breaks testing

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Running jest --config tests/setup/jest.config.json --coverage --no-cache after upgrading Jest from 19.0.2 -> to anything above 20.0.0 will cause all test suites to fail with the same error:
  ● Test suite failed to run

    TypeError: Cannot read property 'ReactElement' of undefined

      at Object.<anonymous> (node_modules/jest-diff/build/index.js:19:71)
      at handle (node_modules/worker-farm/lib/child/index.js:41:8)
      at process.<anonymous> (node_modules/worker-farm/lib/child/index.js:47:3)
      at emitTwo (events.js:106:13)
      at process.emit (events.js:191:7)
      at handleMessage (internal/child_process.js:718:10)
      at Pipe.channel.onread (internal/child_process.js:444:11)

I'm not sure if this is pertinent, but this project does not use React, rather vanilla es2015 + flowtype. I tried adding react (yarn add react --dev) but this did not appear to make any difference.
If the current behavior is a bug, please provide the steps to reproduce and either a repl.it demo through https://repl.it/languages/jest or a minimal repository on GitHub that we can yarn install and yarn test.
$ git clone git@github.com:Travmatth/resume-static-aws.git
$ yarn remove jest
$ yarn add jest --dev
$ yarn test -- --coverage
What is the expected behavior?
The tests will run (prior to upgrading all tests passed, that is, when<EMAIL_ADDRESS>installed all tests run and pass as expected).
Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.
tests/setup/jest.config.json:
{
  "rootDir": "../../",
  "timers": "fake",
  "testRegex": "[A-Za-z]+\\.spec\\.js$",
  "setupFiles": [
    "<rootDir>/tests/setup/setup.js"
  ],
  "moduleNameMapper": {
    "\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/tests/mocks/fileMock.js",
    "^tests(.*)$": "<rootDir>/tests$1"
  },
  "transform": {
    "^.+\\.js?$": "babel-jest",
    ".*\\.pug$": "<rootDir>/tests/preprocessor.js"
  },
  "moduleFileExtensions": ["js"],
  "moduleDirectories": ["<rootDir>/node_modules", "<rootDir>/src"],
  "coverageDirectory": "<rootDir>/tests/coverage",
  "coveragePathIgnorePatterns": [
    "calculator/Parser",
    "tests"
  ],
  "coverageThreshold": {
    "global": {
      "statements": 95
    }
  }
}

Jest version:  Fails on versions above<EMAIL_ADDRESS>node version: v6.1.0
yarn version: 0.17.9
operating system: OSX El Capitan 10.11.6

Only errors I get are like this, caused by lack of this file in repo (it's gitignored):
 FAIL  src/localweather/__tests__/handlers.spec.js
  ● Test suite failed to run

    Cannot find module 'common/js/api_keys' from 'mockdata.js'

      at Resolver.resolveModule (node_modules/jest-resolve/build/index.js:179:17)
      at Object.<anonymous> (src/localweather/__tests__/mockdata.js:2:17)

And they're consistent between Jest 19 and 20.

I'll reopen if I can repro in a separate repo

We just updated to latest version from v19 and we're getting the same error on our CI. I can't reproduce it locally, or even in the "same" Docker image on our CI server.
We're getting the same jest-diff error:
$ jest --coverage --silent --config test/jest-config.json
/builds/app/app/node_modules/jest-diff/build/index.js:19
require('pretty-format').plugins;const ReactElement = _require$plugins.ReactElement,ReactTestComponent = _require$plugins.ReactTestComponent,AsymmetricMatcher = _require$plugins.AsymmetricMatcher,HTMLElement = _require$plugins.HTMLElement,Immutable = _require$plugins.Immutable; /**
                                                                      ^

TypeError: Cannot read property 'ReactElement' of undefined
    at Object.<anonymous> (/builds/app/app/node_modules/jest-diff/build/index.js:19:71)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/builds/app/app/node_modules/jest-snapshot/build/index.js:23:72)
    at Module._compile (module.js:570:32)

and our configuration follows (not sure it'll be of any help though):
{
  "bail": false,
  "verbose": false,
  "setupFiles": [
    "./test/_globals/dom.globals.js",
    "./test/jest-env.js"
  ],
  "setupTestFrameworkScriptFile": "./test/jest-promise.js",
  "collectCoverage": false,
  "coverageReporters": [
    "lcov",
    "text-summary"
  ],
  "moduleFileExtensions": [ "js", "coffee" ],
  "testRegex": "(\\.|/)(test|spec)\\.(js)$",
  "testEnvironment": "jsdom",
  "modulePaths": [ "<rootDir>/" ],
  "transform": {
    "^.+\\.js$": "<rootDir>/node_modules/babel-jest",
    "^.+\\.coffee$": "<rootDir>/test/jest-coffee-preprocessor.js"
  },
  "rootDir": "../",
  "roots": [
    "modules/"
  ],
  "testPathIgnorePatterns": [
    "/node_modules/"
  ],
  "transformIgnorePatterns": [
    "/node_modules/*",
    "/node_modules/jsdom",
    "/node_modules/react-dom",
    "/node_modules/*-*"
  ],
  "coveragePathIgnorePatterns": [
    "mocks/.*",
    "test/jest-env.js",
    "test/_globals/.*",
    "test/_mocks/.*"
  ],
  "cacheDirectory": ".jestCache",
  "snapshotSerializers": ["enzyme-to-json/serializer"]
}

Have you made any progress in fixing this @Travmatth, please?

I think it could be related to weirdly formatted index.js from latest jest-diff from npm.

Downgrading jest-diff only to v19 helped. I've manually set jest-diff v19 as a dependency of other jest v20 packages so I don't have to downgrade everything.

@jakubzitny this shouldn't happen and it's probably a problem with you node_modules. Can you remove the dir and reinstall the whole thing with Yarn?

@thymikee as I said, I cannot really reproduce this locally, and on our CI the node_modules folder is reinstalled automatically. There is some sort of caching going on, but install is always run before the tests.
Do you have any more details on what problem with node_modules is it exactly?

CIs have their cache too, which you should be able to purge.


chore(pipeline): update set script for npm v9

npm ^9 is no good for this mono-repo yet: npm i stalls with the most current 9.1.1, both (!) in gh actions and locally.
→ closing this PR as we have reverted to npm ^8


multi editors are assigned same custom image handler id

I think that there seems to assign always same id to custom image handler in the code below.
https://github.com/davidroyer/vue2-editor/blob/3b1ead967ecb775c02c34d15f65923f22b541155/src/components/VueEditor.vue#L7

This issue is stale because it has been open for 60 days with no activity.

This issue was closed because it has been inactive for 7 days since being marked as stale.


No such module Rswift

Followed the readme to compile locally, got an error on R.generated.swift line 7; "import Rswift" --> no such module 'Rswift'

I encountered the same problem. Though I followed the sequence of steps, it still didn't work. Emm...


patchAndFetchById() returns a String-value for decimal type

I use the following simple code
if (episode.id) {
    return Episode.query().patchAndFetchById(episode.id, episode)
}
return Episode.query().insert(episode)

when insert() path is executed, resulting episode.size contains a number value ("size": 12.34), which is OK
when patchAndFetchById() path is executed, resulting episode.size contains a String value ("size": "12.34"), while expected value should be a number (NOT OK).

In both cases size value given in the model is 12.34 (a number). The size field is a DECIMAL(8,2) in database and a number in JSON schema. This seems to be a bug in patchAndFetchById(), right?
Objection 0.8.8, MySQL 5.7.11

When you insert the value, the returned object does not come from the database. Only the id is returned from the db. The object you inspect is the one you insert. That causes the difference between the methods.
Objection does no type mapping whatsoever by default. The return types are totally up to the db driver knex uses. The db driver probably has some way to map types. Maybe this helps https://github.com/mysqljs/mysql#type-casting.

@koskimas Thanks for looking into! Your link helped. Decimal is mapped to String and after migration to float everything started to work as expected. Sorry for the noise.

Off topic: This is why I switched from MySQL :)


add endpoint for metadata only

Relates to #4
It contains the most straightforward implementation adding additional methods search_plenaryprotocol_meta and get_plenaryprotocol_meta. This however needn't be the best solution.
It generates a somewhat unfortunate mismatch when compared to the swagger UI endpoint namings.

I truly apprechiate the pull request. However it seems easier and more maintainable to add a "fulltext" parameter to those functions retrieving or searching documents or plenary protocols. I have done so in the latest version published. I will close this request, but I do value your contribution @ChristianGeng


docs/building-operators: clean up and align all operator type quickstarts

Description of the change: unify all quickstarts
Motivation for the change: the quickstarts have drifted when they should be closely aligned
/kind documentation
Checklist
If the pull request includes user-facing changes, extra documentation is required:

[ ] Add a new changelog fragment in changelog/fragments (see changelog/fragments/00-template.yaml)
[x] Add or update relevant sections of the docs website in website/content/en/docs

/cc @varshaprasad96 @jmrodri


[Enhancement] Swap these 2 arguments so they are in the correct order: expected value, actual value.[EventMeshServerTest]

Search before asking

[X] I had searched in the issues and found no similar issues.

Enhancement Request

Located at:
eventmesh-runtime/src/test/java/org/apache/eventmesh/runtime/boot/EventMeshServerTest.java line 63-87
analysis and explanation:
The standard assertions library methods such as org.junit.Assert.assertEquals, and org.junit.Assert.assertSame expect the first argument to be the expected value and the second argument to be the actual value. For AssertJ, it’s the other way around, the argument of org.assertj.core.api.Assertions.assertThat is the actual value, and the subsequent calls contain the expected values. Swap them, and your test will still have the same outcome (succeed/fail when it should) but the error messages will be confusing.
Describe the solution you'd like
Swap actual and expected values.
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Hi Alonexc,
is it still available?

@garimellasrisudha Of course, you are very welcome to pr.


New contributor error

When you type, search, select a new contributor, and delete the name from the field, it doesn't let you add the selected contributor.

Done!


Can I backup my present Cube T7 and restore it to a new Cube T8 ?

Can I backup my present Cube T7 and restore it to a new Cube T8 ?

What?


Check run test exit value, and workaround conda-build bug

When conda build ran run_tests.py our test script was giving a 0 exit value even if the tests failed. This is fixed. An example of the failure is here:
https://binstar.org/blaze/dask/builds/20/9
And in our meta.yaml we try using GIT_DESCRIBE_TAG to get the version of our package, but we seem to be effected by this bug. So this works around it.

Merging once travis okays it.


Deploying in Google App Engine

Hi,
I'm having trouble deploying tile38 to the Google App Engine. I can start the server just fine, but can't connect directly to it. I admittedly have to experience working in neither GAE or other similar services (AWS, Digital Ocean, etc.). I have looked at Google's documentation, but it really isn't helpful (at least for Go).
This is the error returned from running gcloud app deploy:
failed analyzing /home/***/tile38-source: could not get package for dir "/home/***/tile38-source": no buildable Go source files in /home/***/tile38-source
GOPATH: /home/***/gopath:/google/gopath

Am I simply doing something wrong or isn't it possible to deploy tile38 in this kind of environment?

Unfortunately, I don't have any experience with GAE and I was hoping that someone who does might chime in. I'm closing this issue for now but if anyone out there has a solution, please feel free to reopen. Thanks.


Bump to latest ruby-lsp version

Hi there!
Latest ruby-lsp version is 0.18.2 but currently ruby-lsp-rspec is blocked on 0.17.x : https://github.com/st0012/ruby-lsp-rspec/blob/f24466704f6a8c653ae7cd170ff13a3df5bab48d/ruby-lsp-rspec.gemspec#L44
Thank you!

Thanks for the ping. I've updated it in a new release.

Thank you!


Cannot find module '@miniben90/x-win-darwin-x64'

Hi, I tried to use @miniben90/x-win with electron.
While it works fine during development, when I package my app and tried to launch it, it fails with the following error
Uncaught Exception:
Error: Cannot find module '@miniben90/x-win-darwin-x64'
Require stack:
-<EMAIL_ADDRESS>
Looks like @miniben90/x-win-darwin-x64 a private package, attempted to install it but then it requires github login.
Is there anything I can do to avoid this issue?

Hi,
Thank you for your report. There is an issue with the auto-publishing workflow, and I'm looking into it.

You can try to update your project. I have published subpackages missing.
You should also ensure that the native Node package, such as @miniben90/x-win-darwin-x64, is unpacked if you're using the asar configuration with your Electron builder.

You need also to add optional packages when you run your building (https://github.com/miniben-90/x-win?tab=readme-ov-file#questions)[https://github.com/miniben-90/x-win?tab=readme-ov-file#questions]