@BeanValidation - new annotation

I want to proposal a new annotation for using Hibernate Validation on service layer.
Similar to @NonNull  but use javax.validation API
public class Model {
    @NotNull
    private String text;
    @Max(10)
    private Integer number;
    //
}

public void process(@BeanValidation Model model)  {
        //
 }

public void process(@BeanValidation Model model) {
       ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
       Validator validator = factory.getValidator();
       Set<ConstraintViolation<Model>> violations = validator.validate(model);
        if (!violations.isEmpty()) {
             throw new ConstraintViolationException("......");
        }
}

To be honest this is a great idea! Aaaand it seems like lombok lacks of new impressive ideas last years.
So, this one is really great I would say as Lombok anyways does a lot of non-usual stuff and adds many custom code to class-files - this one is really great (Can't wait for @SuperBuilder if it happens anytime soon @rzwitserloot `
Now people have to use AspectJ or more modern ByteBuddy agent to enable executable validation for example.
BUT
It should be something like
@BeanValidation(uses = ValidatorFactoryProvider.class)
Where it could be one and only one method returning ValidatorFactory.class or smth like that..
Because building  ValidatorFactory should occur once. It is expensive. You should never build ValidatorFactory for each, even method / constructor validation.

@andrelugomes I'm lost. Validation is surely a nice thing, but what code should Lombok generate? Your process method takes Model as an argument, so I guess, it doesn't belong to Model at all. The Validator probably uses reflection to access the fields, so again, no Lombok needed.
AFAIK the only thing Lombok could meaningfully do is calling a validating method from the generated constructors and/or setters. Or simply just call a method.
Lombok itself won't probably ever do any advanced validation itself as this is just too complicated at this level. Letting it call something from the generated code is a long wished feature. AFAIK the last feedback we got on it is this comment.

@andrelugomes

but what code should Lombok generate?

This code
    @BeanValidation(uses = ValidatorFactoryProvider.class)
    /*public*/ class Stub {
         /*@Tolerate*/
        @ParametersScriptAssert(script = "arg0.before(arg1)", lang = "javascript")
        @SomeCustomCrossParameterAnnotation("...")
        /*public*/ Stub(@NotNull Localdate d1, @NotNull LocalDate) {
            this.d1 = d1;
            this.d2 = d2;
        }
        ...
        /*@Tolerate*/
        @ParametersScriptAssert(script = "arg0 > arg1)", lang = "javascript")
        @SomeAnotherCustomCrossParameterAnnotation("...")
        /*public*/ Result method(@NotBlank String s1, @NotBlank String s2) {
            // do stuff
           return result;
        }
    }

or to just validate particular methods / constructors
@RequiredArgsConstructor(onConstructor_ = {@BeanValidation(uses = ValidatorFactoryProvider.class)}
class Stub { /*fields etc*/ }

generates
     /*public*/ class Stub {
    @ParametersScriptAssert(script = "arg0.before(arg1)", lang = "javascript")
    @SomeCustomCrossParameterAnnotation("...")
        /*public*/ Stub(@NotNull Localdate d1, @NotNull LocalDate) {
            final Constructor<?> constructor = Stub.class.getDeclaredConstructor(String.class);
            final Object[] parameters = new Object[]{ d1, d2 };
            final Set<ConstraintViolation<Object>> constraintViolations =
                    // see my comment above
                    ValidatorFactoryProvider.getExecutableValidator()
                            .validateConstructorParameters(constructor, parameters);
            if (!constraintViolations.isEmpty()) {
                throw new ConstraintViolationException(constraintViolations);
            }
            this.d1 = d1;
            this.d2 = d2;

        }
        ....
        @ParametersScriptAssert(script = "arg0 > arg1)", lang = "javascript")
        @SomeAnotherCustomCrossParameterAnnotation("...")
        /*public*/ Result method(@NotBlank String s1, @NotBlank String s2) {
            final Method method = ... //getExec method,
            final Object[] parameters = new Object[]{ s1, s2 };
            final Set<ConstraintViolation<Object>> constraintViolations =
                    ValidatorFactoryProvider.getExecutableValidator()
                            .validateParameters(this, method, parameters);
            if (!constraintViolations.isEmpty()) {
                throw new ConstraintViolationException(constraintViolations);
            }
            // do stuff
           return result;
        }
    }

@rzwitserloot  Is this realistic?

@soberich, I will get your code and give it some tweaks.
First, let't start with an approach that, although attractive, won't work:
package lombok;

import java.annotation.Retention;
import java.annotation.RetentionPolicy;
import java.annotation.Target;
import java.annotation.ElementType;
import javax.validation.executable.ExecutableValidator;

@Retention(value = RetentionPolicy.SOURCE)
@Target({ElementType.TYPE, ElementType.CONSTRUCTOR, ElementType.METHOD})
public @interface BeanValidation {
    public Class<? extends BeanValidatorProvider> getExecutableValidator();

    public static interface BeanValidatorProvider {
        public ExecutableValidator getValidator();
    }
}

This don't work and there iss no easy way to fix it due to several reasons:

Lombok has a policy to not add any runtime dependencies to its users, and that is exactly what that BeanValidatorProvider is. So, we will need some approach that do not depends on a custom interface.

Trying to work around that by using java.util.function.Supplier or a method reference is another no-no because lombok should still be runnable with (nowadays ancient) Java 6. Switching to Java 7 will not really improve the situation here, at least Java 8 would be needed.

Using Class<?> will allow the class type be anything, including non-sense things in this context like String.class, int.class and void.class.

Using Class<? extends javax.validation.executable.ExecutableValidator> means that the user would be responsible for creating a class that implements ExecutableValidator. It would need to be instantiable with the default parameterless constructor, should be very light (likely an implementation of the flyweight pattern) and also encapsulate all the complicated validation logic (likely to be a implementation of the decorator pattern). On other words, it would be a heavy burden for the user.

Using Class<? extends javax.validation.Validator> or Class<? extends javax.validation.ValidatorFactory> would only make the burden for the user still heavier.

Using the name of a static parameterless method as a String works, but is a brittle approach. A refactoring operation that renames the method would forget the annotation untouched. Changing the method signature would also cause bad things. At least, since lombok is a compile-time tool, if the given method name is bad, you'll still get a compiler error instead of having it compiled and then getting a runtime error.

That is quite unfortunate, if we could either add runtime dependencies or use at least Java 8 for sure, we would be able to work out this easily.
But we need to choose some approach anyway, even if it is not as good as we would it like to be. So I'll choose for the method name as a String. With that, the annotation would be:
package lombok;

import java.annotation.Retention;
import java.annotation.RetentionPolicy;
import java.annotation.Target;
import java.annotation.ElementType;

@Retention(value = RetentionPolicy.SOURCE)
@Target({ElementType.TYPE, ElementType.CONSTRUCTOR, ElementType.METHOD})
public @interface BeanValidation {
    public String methodName();
}

That value is the name of a parameterless static method that should be present to the declaring class and should return a javax.validation.executable.ExecutableValidator. Ugh, I hate to simulate method references as strings, but didn't found a way to work around that without having some other gotcha.
We would also have this:
package lombok;
import java.annotation.Retention;
import java.annotation.RetentionPolicy;
import java.annotation.Target;
import java.annotation.ElementType;

// This is implied by @Tolerate.
// But differently than @Tolerate this makes the method invisible
// only to @BeanValidation instead of lombok as a whole.
@Retention(value = RetentionPolicy.SOURCE)
@Target({ElementType.TYPE, ElementType.CONSTRUCTOR, ElementType.METHOD})
public @interface DisableBeanValidation {
}

So, let's go to the user code:
package com.example;

import acme.somepackage.CustomFancyValidation;
import acme.somepackage.CustomMamboJambo;
import acme.somepackage.Result;
import acme.somepackage.SomeAnotherCustomCrossParameterAnnotation;
import java.time.LocalDate;
import javax.validation.executable.ExecutableValidator;
import lombok.BeanValidation;
import lombok.DisableBeanValidation;
import lombok.NonNull;
import org.hibernate.validator.constraints.ParametersScriptAssert;
import org.hibernate.validator.constraints.NotBlank;

@BeanValidation(methodName = "myCustomMethod")
/*public*/ class MyCustomClass {

    @NonNull
    private final LocalDate d1;

    @NonNull
    private final LocalDate d2;

    @ParametersScriptAssert(script = "arg0.before(arg1)", lang = "javascript")
    @SomeCustomCrossParameterAnnotation("...")
    /*public*/ MyCustomClass(@NotNull LocalDate d1, @NotNull LocalDate d2) {
        this.d1 = d1;
        this.d2 = d2;
    }

    @ParametersScriptAssert(script = "arg0 > arg1)", lang = "javascript")
    @SomeAnotherCustomCrossParameterAnnotation("...")
    /*public*/ Result method(@NotBlank String s1, @NotBlank String s2) {
       // do stuff
       return result;
    }

    @BeanValidation(methodName = "myOtherCustomMethod")
    @CustomFancyValidation("...")
    /*public*/ Result otherMethod(@CustomMamboJambo String s1) {
        // do stuff
        return result;
    }

    @DisableBeanValidation
    /*public*/ Result defaultValidationMethod(@NonNull String s1) {
        // do stuff
        return result;
    }

    private static ExecutableValidator myCustomMethod() {
        // do some sort of dance to get an ExecutableValidator.
        return validator;
    }

    private static ExecutableValidator myOtherCustomMethod() {
        // do some other sort of dance to get an ExecutableValidator.
        return validator;
    }
}

Could be delombokized onto this:
package com.example;

import acme.somepackage.CustomFancyValidation;
import acme.somepackage.CustomMamboJambo;
import acme.somepackage.Result;
import acme.somepackage.SomeAnotherCustomCrossParameterAnnotation;
import java.time.LocalDate;
import javax.validation.executable.ExecutableValidator;
import lombok.NonNull;
import org.hibernate.validator.constraints.ParametersScriptAssert;
import org.hibernate.validator.constraints.NotBlank;

/*public*/ class MyCustomClass {

    private static abstract class Lombok$ValidationHelper {
        public void validateConstructor(javax.validation.executable.ExecutableValidator validator, java.lang.Object... params) {
            check(validator.validateConstructorParameters(getClass().getEnclosingConstructor(), params));
        }

        public void validateMethod(javax.validation.executable.ExecutableValidator validator, java.lang.Object... params) {
            check(validator.validateParameters(getClass().getEnclosingMethod(), params));
        }

        private void check(java.util.Set<javax.validation.ConstraintViolation<?>> set) {
            if (!set.isEmpty()) throw new javax.validation.ConstraintViolationException(set);
        }
    }

    @ParametersScriptAssert(script = "arg0.before(arg1)", lang = "javascript")
    @SomeCustomCrossParameterAnnotation("...")
    /*public*/ Stub(@NotNull LocalDate d1, @NotNull LocalDate d2) {
        (new Lombok$ValidationHelper() {}).validateConstructor(myCustomMethod(), d1, d2);
        this.d1 = d1;
        this.d2 = d2;
    }

    @ParametersScriptAssert(script = "arg0 > arg1)", lang = "javascript")
    @SomeAnotherCustomCrossParameterAnnotation("...")
    /*public*/ Result method(@NotBlank String s1, @NotBlank String s2) {
        (new Lombok$ValidationHelper() {}).validateMethod(myCustomMethod(), s1, s2);
        // do stuff
        return result;
    }

    @CustomFancyValidation("...")
    /*public*/ Result otherMethod(@CustomMamboJambo String s1) {
        (new Lombok$ValidationHelper() {}).validateMethod(myOtherCustomMethod(), s1);
        // do stuff
        return result;
    }

    /*public*/ Result defaultValidationMethod(@NonNull String s1) {
        if (s1 == null) throw new NullPointerException("s1 is marked @NonNull but is null");
        // i.e. this uses the traditional simple lombok @NonNull validation.
        // do stuff
        return result;
    }

    private static ExecutableValidator myCustomMethod() {
        // do some sort of dance to get an ExecutableValidator.
        return validator;
    }

    private static ExecutableValidator myOtherCustomMethod() {
        // do some other sort of dance to get an ExecutableValidator.
        return validator;
    }
}

The first downside is that the @BeanValidation annotation uses a string as the method name instead something more refactoring-proof.
The second downside is that there is no default method for getting an ExecutableValidator. The user has to write it all. Lombok could generate one like this:
    private static javax.validation.executable.ExecutableValidator lombok$defaultValidator() {
        return javax.validation.Validation.buildDefaultValidatorFactory().getValidator().forExecutables();
    }

But this would not be a good idea because it is a very heavy object to be produced that way for each method call requiring validation. Caching it won't work either because lombok can't tell clearly how, when or where to cache it. So, I see no way other than forcing the user to write a method for getting that somehow.
The third downside is that we would have a Lombok$ValidationHelper class for each top-level class that uses bean validation. This is somewhat wasteful because they all have the very same code that works independently of the enclosing class, resulting in a bunch of compiled classes that all does the exact same thing (plus all the anonymous subclasses). This would be solved if lombok could provide it as a runtime dependency, but it can't.

The first downside is that the @BeanValidation annotation uses a string as the method name instead something more refactoring-proof.

This could be solved by placing the annotation on the method instead:
@BeanValidationSupplier
private static ExecutableValidator myCustomMethod() {
    // do some sort of dance to get an ExecutableValidator.
    return validator;
}

This wouldn't allow things like myOtherCustomMethod, but do we need it?

But this would not be a good idea because it is a very heavy object to be produced that way for each method call requiring validation.

Right, this is the user's responsibility and decision. I don't know much about how it exactly works and why it's heavyweight, what parts are thread-safe and so on. But someone surely does and could provide a good example...

The third downside is that we would have a Lombok$ValidationHelper

There must be a better solution. Yours would generate an anonymous class for every method, which would add quite some memory and runtime overhead, probably sufficient to kill Android. Maybe something like
private static final Method[] lombok$methodArray = MyCustomClass.class.getDeclaredMethods();
private static final Constructor[] lombok$constructorArray  = MyCustomClass.class.getDeclaredConstructors();

private void lombok$check(java.util.Set<javax.validation.ConstraintViolation<?>> set) {
      if (!set.isEmpty()) throw new javax.validation.ConstraintViolationException(set);
}

@ParametersScriptAssert(script = "arg0 > arg1)", lang = "javascript")
@SomeAnotherCustomCrossParameterAnnotation("...")
Result method(@NotBlank String s1, @NotBlank String s2) {
        lombok$check(myCustomMethod().validateParameters(
               lombok$methodArray[###theMagicallyRightIndex###], s1, s2));
        // do stuff
        return result;
}

could work. The hard part would be the determination of ###theMagicallyRightIndex### as there's no guarantee of reflection returning methods in the right order. This would probably require a static initializer block possibly reordering the arrays so that they match the source code order.

I guess, the best solution would be another project providing all the necessary utilities and making validation easy to use. Lombok would then just generate the calls of helpers from the other project.

@Maaartinus Very clever about putting the annotation in the method and using ###theMagicallyRightIndex###. So, I will try again:
package lombok;

import java.annotation.Retention;
import java.annotation.RetentionPolicy;
import java.annotation.Target;
import java.annotation.ElementType;

@Retention(RetentionPolicy.SOURCE)
@Target({ElementType.TYPE, ElementType.CONSTRUCTOR, ElementType.METHOD})
public @interface BeanValidation {}

[Keep the @DisableBeanValidation from my previous message as is]
package lombok;

import java.annotation.Retention;
import java.annotation.RetentionPolicy;
import java.annotation.Target;
import java.annotation.ElementType;

@Retention(RetentionPolicy.SOURCE)
@Target(ElementType.METHOD)
public @interface BeanValidationSupplier {}

The user class:
package com.example;

import acme.somepackage.CustomFancyValidation;
import acme.somepackage.CustomMamboJambo;
import acme.somepackage.Result;
import acme.somepackage.SomeAnotherCustomCrossParameterAnnotation;
import java.lang.reflect.Executable;
import java.time.LocalDate;
import javax.validation.executable.ExecutableValidator;
import lombok.BeanValidation;
import lombok.BeanValidationSupplier;
import lombok.DisableBeanValidation;
import lombok.NonNull;
import org.hibernate.validator.constraints.ParametersScriptAssert;
import org.hibernate.validator.constraints.NotBlank;

@BeanValidation
/*public*/ class MyCustomClass {

    @NonNull
    private final LocalDate d1;

    @NonNull
    private final LocalDate d2;

    @ParametersScriptAssert(script = "arg0.before(arg1)", lang = "javascript")
    @SomeCustomCrossParameterAnnotation("...")
    /*public*/ MyCustomClass(@NotNull LocalDate d1, @NotNull LocalDate d2) {
        this.d1 = d1;
        this.d2 = d2;
    }

    @ParametersScriptAssert(script = "arg0 > arg1)", lang = "javascript")
    @SomeAnotherCustomCrossParameterAnnotation("...")
    /*public*/ Result method(@NotBlank String s1, @NotBlank String s2) {
       // do stuff
       return result;
    }

    @CustomFancyValidation("...")
    /*public*/ Result otherMethod(@CustomMamboJambo String s1) {
        // do stuff
        return result;
    }

    @DisableBeanValidation
    /*public*/ Result defaultValidationMethod(@NonNull String s1) {
        // do stuff
        return result;
    }

    @BeanValidationSupplier
    private static ExecutableValidator myCustomMethod(Executable where) {
        // do some sort of dance to get an ExecutableValidator.
        return validator;
    }
}

That myCustomMethod might either not have any parameter or have a parameter representing the method or constructor. This gives a chance to myCustomMethod to inspect the method or constructor in which it is applied to selectively choose or configure the returned ExecutableValidator. In the majority of the cases, where this isn't needed, that method would simply have no parameters. Java 7 and below do not have java.lang.reflect.Executable, but in this case, java.lang.reflect.Member, java.lang.reflect.AnnotatedElement or even java.lang.Object could be used instead, as long it is some type compatible both with Method and Constructor.
That would be delomboked into:
package com.example;

import acme.somepackage.CustomFancyValidation;
import acme.somepackage.CustomMamboJambo;
import acme.somepackage.Result;
import acme.somepackage.SomeAnotherCustomCrossParameterAnnotation;
import java.lang.reflect.Executable;
import java.time.LocalDate;
import javax.validation.executable.ExecutableValidator;
import lombok.NonNull;
import org.hibernate.validator.constraints.ParametersScriptAssert;
import org.hibernate.validator.constraints.NotBlank;

/*public*/ class MyCustomClass {

    private static final java.lang.reflect.Method[] lombok$methodArray = new java.lang.reflect.Method[2];
    private static final java.lang.reflect.Constructor<?>[] lombok$constructorArray = new java.lang.reflect.Constructor<?>[2];

    static {
        try {
            lombok$methodArray[0] = MyCustomClass.getDeclaredMethod("method", java.lang.String.class, java.lang.String.class);
            lombok$methodArray[1] = MyCustomClass.getDeclaredMethod("otherMethod", java.lang.String.class);
            lombok$constructorArray[0] = MyCustomClass.getDeclaredConstructor(java.time.LocalDate.class, java.time.LocalDate.class);
        } catch (java.lang.Exception e) {
            throw new java.lang.ExceptionInInitializerError(e);
        }
    }

    @NonNull
    private final LocalDate d1;

    @NonNull
    private final LocalDate d2;

    @ParametersScriptAssert(script = "arg0.before(arg1)", lang = "javascript")
    @SomeCustomCrossParameterAnnotation("...")
    /*public*/ MyCustomClass(@NotNull LocalDate d1, @NotNull LocalDate d2) {
        java.util.Set<javax.validation.ConstraintViolation<?>> $temp0 = myCustomMethod(lombok$constructorArray[0]).validateConstructorParameters(lombok$constructorArray[0], new Object[] {d1, d2});
        if (!$temp0.isEmpty()) throw new javax.validation.ConstraintViolationException($temp0);
        this.d1 = d1;
        this.d2 = d2;
    }

    @ParametersScriptAssert(script = "arg0 > arg1)", lang = "javascript")
    @SomeAnotherCustomCrossParameterAnnotation("...")
    /*public*/ Result method(@NotBlank String s1, @NotBlank String s2) {
        java.util.Set<javax.validation.ConstraintViolation<?>> $temp0 = myCustomMethod(lombok$methodArray[0]).validateParameters(lombok$methodArray[0], new Object[] {s1, s2});
        if (!$temp0.isEmpty()) throw new javax.validation.ConstraintViolationException($temp0);
        // do stuff
        return result;
    }

    @CustomFancyValidation("...")
    /*public*/ Result otherMethod(@CustomMamboJambo String s1) {
        java.util.Set<javax.validation.ConstraintViolation<?>> $temp0 = myCustomMethod(lombok$methodArray[1]).validateParameters(lombok$methodArray[1], new Object[] {s1});
        if (!$temp0.isEmpty()) throw new javax.validation.ConstraintViolationException($temp0);
        // do stuff
        return result;
    }

    /*public*/ Result defaultValidationMethod(@NonNull String s1) {
        if (s1 == null) throw new NullPointerException("s1 is marked @NonNull but is null");
        // i.e. this uses the traditional simple lombok @NonNull validation.
        // do stuff
        return result;
    }

    private static ExecutableValidator myCustomMethod(Executable where) {
        // do some sort of dance to get an ExecutableValidator.
        return validator;
    }
}

I guess, the best solution would be another project providing all the necessary utilities and making validation easy to use. Lombok would then just generate the calls of helpers from the other project.

Not sure yet what to think about that.

I think this whole thing already exists in another project. I mean, as far
as I am aware implementing validations nowadays is a matter of annotating
your fields properly and then supplying spring with a validator that can
handle the annotations. Autowiring does the rest.
So I don't quite understand what this functionality is supposed to achieve.
Maybe that's just me, but this thing already exists as far as I know.
Without requiring any help from lombok.
On Thu, Jun 7, 2018 at 6:09 PM, Victor Williams Stafusa da Silva <
<EMAIL_ADDRESS>wrote:

@Maaartinus https://github.com/Maaartinus Very clever about putting the
annotation in the method and using ###theMagicallyRightIndex###. So, I
will try again:
package lombok;
import java.annotation.Retention;import java.annotation.RetentionPolicy;import java.annotation.Target;import java.annotation.ElementType;
@Retention(RetentionPolicy.SOURCE)@Target({ElementType.TYPE, ElementType.CONSTRUCTOR, ElementType.METHOD})public @interface BeanValidation {}
[Keep the @DisableBeanValidation from my previous message as is]
package lombok;
import java.annotation.Retention;import java.annotation.RetentionPolicy;import java.annotation.Target;import java.annotation.ElementType;
@Retention(RetentionPolicy.SOURCE)@Target(ElementType.METHOD)public @interface BeanValidationSupplier {}
The user class:
package com.example;
import acme.somepackage.CustomFancyValidation;import acme.somepackage.CustomMamboJambo;import acme.somepackage.Result;import acme.somepackage.SomeAnotherCustomCrossParameterAnnotation;import java.lang.reflect.Executable;import java.time.LocalDate;import javax.validation.executable.ExecutableValidator;import lombok.BeanValidation;import lombok.BeanValidationSupplier;import lombok.DisableBeanValidation;import lombok.NonNull;import org.hibernate.validator.constraints.ParametersScriptAssert;import org.hibernate.validator.constraints.NotBlank;
@BeanValidation/public/ class MyCustomClass {
@NonNull
private final LocalDate d1;

@NonNull
private final LocalDate d2;

@ParametersScriptAssert(script = "arg0.before(arg1)", lang = "javascript")
@SomeCustomCrossParameterAnnotation("...")
/*public*/ MyCustomClass(@NotNull LocalDate d1, @NotNull LocalDate d2) {
    this.d1 = d1;
    this.d2 = d2;
}

@ParametersScriptAssert(script = "arg0 > arg1)", lang = "javascript")
@SomeAnotherCustomCrossParameterAnnotation("...")
/*public*/ Result method(@NotBlank String s1, @NotBlank String s2) {
   // do stuff
   return result;
}

@CustomFancyValidation("...")
/*public*/ Result otherMethod(@CustomMamboJambo String s1) {
    // do stuff
    return result;
}

@DisableBeanValidation
/*public*/ Result defaultValidationMethod(@NonNull String s1) {
    // do stuff
    return result;
}

@BeanValidationSupplier
private static ExecutableValidator myCustomMethod(Executable where) {
    // do some sort of dance to get an ExecutableValidator.
    return validator;
}

}
That myCustomMethod might either not have any parameter or have a
parameter representing the method or constructor. This gives a chance to
myCustomMethod to inspect the method or constructor in which it is
applied to selectively choose or configure the returned
ExecutableValidator. In the majority of the cases, where this isn't
needed, that method would simply have no parameters. Java 7 and below do
not have java.lang.reflect.Executable, but in this case,
java.lang.reflect.Member, java.lang.reflect.AnnotatedElement or even
java.lang.Object could be used instead, as long it is some type
compatible both with Method and Constructor.
That would be delomboked into:
package com.example;
import acme.somepackage.CustomFancyValidation;import acme.somepackage.CustomMamboJambo;import acme.somepackage.Result;import acme.somepackage.SomeAnotherCustomCrossParameterAnnotation;import java.lang.reflect.Executable;import java.time.LocalDate;import javax.validation.executable.ExecutableValidator;import lombok.NonNull;import org.hibernate.validator.constraints.ParametersScriptAssert;import org.hibernate.validator.constraints.NotBlank;
/public/ class MyCustomClass {
private static final java.lang.reflect.Method[] lombok$methodArray = new java.lang.reflect.Method[2];
private static final java.lang.reflect.Constructor<?>[] lombok$constructorArray = new java.lang.reflect.Constructor<?>[2];

static {
    try {
        lombok$methodArray[0] = MyCustomClass.getDeclaredMethod("method", java.lang.String.class, java.lang.String.class);
        lombok$methodArray[1] = MyCustomClass.getDeclaredMethod("otherMethod", java.lang.String.class);
        lombok$constructorArray[0] = MyCustomClass.getDeclaredConstructor(java.time.LocalDate.class, java.time.LocalDate.class);
    } catch (java.lang.Exception e) {
        throw new java.lang.ExceptionInInitializerError(e);
    }
}

@NonNull
private final LocalDate d1;

@NonNull
private final LocalDate d2;

@ParametersScriptAssert(script = "arg0.before(arg1)", lang = "javascript")
@SomeCustomCrossParameterAnnotation("...")
/*public*/ MyCustomClass(@NotNull LocalDate d1, @NotNull LocalDate d2) {
    java.util.Set<javax.validation.ConstraintViolation<?>> $temp0 = myCustomMethod(lombok$constructorArray[0]).validateConstructorParameters(lombok$constructorArray[0], new Object[] {d1, d2});
    if (!$temp0.isEmpty()) throw new javax.validation.ConstraintViolationException($temp0);
    this.d1 = d1;
    this.d2 = d2;
}

@ParametersScriptAssert(script = "arg0 > arg1)", lang = "javascript")
@SomeAnotherCustomCrossParameterAnnotation("...")
/*public*/ Result method(@NotBlank String s1, @NotBlank String s2) {
    java.util.Set<javax.validation.ConstraintViolation<?>> $temp0 = myCustomMethod(lombok$methodArray[0]).validateParameters(lombok$methodArray[0], new Object[] {s1, s2});
    if (!$temp0.isEmpty()) throw new javax.validation.ConstraintViolationException($temp0);
    // do stuff
    return result;
}

@CustomFancyValidation("...")
/*public*/ Result otherMethod(@CustomMamboJambo String s1) {
    java.util.Set<javax.validation.ConstraintViolation<?>> $temp0 = myCustomMethod(lombok$methodArray[1]).validateParameters(lombok$methodArray[1], new Object[] {s1});
    if (!$temp0.isEmpty()) throw new javax.validation.ConstraintViolationException($temp0);
    // do stuff
    return result;
}

/*public*/ Result defaultValidationMethod(@NonNull String s1) {
    if (s1 == null) throw new NullPointerException("s1 is marked @NonNull but is null");
    // i.e. this uses the traditional simple lombok @NonNull validation.
    // do stuff
    return result;
}

private static ExecutableValidator myCustomMethod(Executable where) {
    // do some sort of dance to get an ExecutableValidator.
    return validator;
}

}
I guess, the best solution would be another project providing all the
necessary utilities and making validation easy to use. Lombok would then
just generate the calls of helpers from the other project.
Not sure yet what to think about that.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1701#issuecomment-395477319,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCRTtE7S8yrfS3V-pGifTOfzqwSk0nks5t6VAvgaJpZM4UO4V1
.

--
"Don't only practice your art, but force your way into it's secrets, for it
and knowledge can raise men to the divine."
-- Ludwig von Beethoven

@randakar
talk is about executable validation. Explore.

@victorwss maybe at least push to avoid static initializer block (if possible) at, again, at least "design time". I mean this makes class to be not usable for instrumentation (with some agent) which is quite limiting overall. But you better know about ASM and relevant stuff here.

Well, that's quite the helpful explanation there.
So, you want to put validation annotations on method arguments and have
those automatically run through a validator. Does this include
lombok-generated method arguments, or not? If it doesn't, what is lombok
supposed to do? Produce a factory for the validator itself and hook the
validator up in such a way that it is automatically applied properly? Why
can't this be be solved with spring, exactly?
Why is it common enough that you want lombok to do that?
On Fri, Jun 8, 2018 at 12:58 AM, soberich<EMAIL_ADDRESS>wrote:

@randakar https://github.com/randakar
talk is about executable validation. Explore.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1701#issuecomment-395591754,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCRRTa279psypCRCbyo68AJ0ql3Waiks5t6bASgaJpZM4UO4V1
.

--
"Don't only practice your art, but force your way into it's secrets, for it
and knowledge can raise men to the divine."
-- Ludwig von Beethoven

@soberich

I mean this makes class to be not usable for instrumentation (with some agent)

How exactly does this happen? The above initializer block could be trivially replaced by
private static final java.lang.reflect.Method[] lombok$methodArray = {
    MyCustomClass.getDeclaredMethod("method", java.lang.String.class, java.lang.String.class),
    MyCustomClass.getDeclaredMethod("otherMethod", java.lang.String.class),
};
private static final java.lang.reflect.Constructor<?>[] lombok$constructorArray = {
     MyCustomClass.getDeclaredConstructor(java.time.LocalDate.class, java.time.LocalDate.class),
};

if there weren't those stupid checked exceptions (a helper method would help). Anyway, I can't imagine that it'd change anything w.r.t. the instrumentation.

Alright. Thanks for this explanation. It makes sense. Given those
constraints.
For the kind of projects I work on, it usually doesn't really apply though.
And that example.. For basic web endpoints at least, none of that is
necessy given spring boot. In that context it's a matter of some
annotations and writing your own validator for anything that isn't covered
by the javax.validation annotations.
But fine, if that approach does not work for other people, feel free.
My main fear here is that people will slowly turn lombok from a small
targeted single purpose library into soms massive monster people use only a
fraction of, in the name of killing boilerplate. So if it seems to be the
case that a specific piece is already covered by soms other (small,
ideally) library or framework, I prefer Lombok to not reinvent it.
Op za 9 jun. 2018 09:22 schreef Victor Williams Stafusa da Silva <
<EMAIL_ADDRESS>
@randakar https://github.com/randakar
Note that parameter validation and bean validation are different things
and we are so far only talking about parameter validation. IMO, bean
validation might come in later, specially when combined with @Data and
@Value, but let's take one step at a time. At least about bean
validation, as you said, there is a lot of frameworks that do that.
The idea is to validate the parameters in the same way that lombok
validates @NonNull. The programmer just puts the annotations on the
parameters (or in the method or the class if needed) and voila, its done.
No need to write the boilerplate to actually do that validation. Most
parameter validation code is boilerplate and lombok's purpose is to
eliminate boilerplate code, so it's a match.
See this page about spring
http://www.baeldung.com/javax-validation-method-constraints. The code
for parameter validation there is this:
ReservationManagement object = new ReservationManagement();Method method = ReservationManagement.class
.getMethod("createReservation", LocalDate.class, int.class, Customer.class);Object[] parameterValues = { LocalDate.now(), 0, null };Set<ConstraintViolation> violations
= executableValidator.validateParameters(object, method, parameterValues);
This is a boilerplate code that is extremely cumbersome and error-prone to
be written manually over and over again. For this reason, it is recommended
to use AOP or proxies to handle that transparently. Lombok would be a third
approach that won't need neither AOP nor proxies for that stuff. Nor
dependency injection. Nor relying on some container that magically manages
beans. Nor demanding strange codification practices or imposing
restrictions on the code like EJB 2 did. Further, it should be usable on
android.
Parameter validation is a very frequent case of programmers having to
manually write boilerplate code, be it with javax.validation or not, so
this is something interesting for lombok. However, autogenerating that
boilerplate code is something hard because there is too much variability in
them. Anyway, the proposal should be able to solve this problem at least
partially, generating the boilerplate code that invokes some validator,
which would be responsible for actually handling validation. If it could
also generate the validator itself, it would be a big win, but let's take
one step at a time.
@soberich https://github.com/soberich I didn't understand what is
really the problem with the static block and instrumentation agents. Can
you elaborate more on that?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1701#issuecomment-395947304,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCRZ5MWodSGhHMldI8iwxyDFeSgnCaks5t63fOgaJpZM4UO4V1
.

@victorwss
If someone (like me) aims to transformation loaded classes redefining them (which btw ALL monitoring tolls / libraries do - that's the point) it will fail completely because such transformation HAVE TO keep class schema unchanged, but as already said this can be achieved only with redefinition of the class which CAN NOT happen if Lombok did put static block there, because this block needs to be copied into an extra method as @Maaartinus said. (see legendary JEP 159)

@soberich So, what about replacing this:
    private static final java.lang.reflect.Method[] lombok$methodArray = new java.lang.reflect.Method[2];
    private static final java.lang.reflect.Constructor<?>[] lombok$constructorArray = new java.lang.reflect.Constructor<?>[1];

    static {
        try {
            lombok$methodArray[0] = MyCustomClass.class.getDeclaredMethod("method", java.lang.String.class, java.lang.String.class);
            lombok$methodArray[1] = MyCustomClass.class.getDeclaredMethod("otherMethod", java.lang.String.class);
            lombok$constructorArray[0] = MyCustomClass.class.getDeclaredConstructor(java.time.LocalDate.class, java.time.LocalDate.class);
        } catch (java.lang.Exception e) {
            throw new java.lang.ExceptionInInitializerError(e);
        }
    }

By this:
    private static final java.lang.reflect.Method[] lombok$methodArray = lombok$getMethodArray();
    private static final java.lang.reflect.Constructor<?>[] lombok$constructorArray = lombok$getConstructorArray();

    private static java.lang.reflect.Method[] lombok$getMethodArray() {
        try {
            return new java.lang.reflect.Method[] {
                MyCustomClass.class.getDeclaredMethod("method", java.lang.String.class, java.lang.String.class),
                MyCustomClass.class.getDeclaredMethod("otherMethod", java.lang.String.class)
            }
        } catch (java.lang.Exception e) {
            throw new java.lang.ExceptionInInitializerError(e);
        }
    }

    private static java.lang.reflect.Constructor<?>[] lombok$getConstructorArray() {
        try {
            return new java.lang.reflect.Constructor<?>[] {
                MyCustomClass.class.getDeclaredConstructor(java.time.LocalDate.class, java.time.LocalDate.class)
            };
        } catch (java.lang.Exception e) {
            throw new java.lang.ExceptionInInitializerError(e);
        }
    }

Would it be ok now?

@victorwss yes. Only static initializer block have such an "honor".

@Maaartinus, the inicial idea were makes lombok generate static validation of Hibernate Validatior as @BeanValidation provider using:
        ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
        javax.validation.Validator validator = factory.getValidator();
        Set<ConstraintViolation<T>> violations = validator.validate(vo);
        if ( violations.size() > 0) {
             throw new ConstraintViolationException("......");
        }

We use and mainteing a opensource projet that do the same thing, but using Aspect.
https://github.com/opensanca/service-validator


Add kv provider

Issues affected
Resolves #123

This change is

Reviewed 33 of 33 files at r1.
Review status: all files reviewed at latest revision, 2 unresolved discussions.

providers/kv/basic.go, line 55 [r1] (raw file):

	}

	return kvp.Data, nil, nil

We want to be returning the kvp so that we can keep track of the index for later modifications. Also to be in line with what getAll returns.

providers/kv/basic_test.go, line 89 [r1] (raw file):

		}

		result, ok := res.([]byte)

See comment on the get handler

Comments from Reviewable

Review status: all files reviewed at latest revision, 2 unresolved discussions.

providers/kv/basic.go, line 55 [r1] (raw file):
Previously, TauZero (Brian Bickerton) wrote…
> We want to be returning the `kvp` so that we can keep track of the index for later modifications. Also to be in line with what `getAll` returns.

woops, good call

Comments from Reviewable

Review status: 31 of 33 files reviewed at latest revision, 2 unresolved discussions.

providers/kv/basic.go, line 55 [r1] (raw file):
Previously, mmlb (Manuel Mendez) wrote…
> woops, good call

Done.

providers/kv/basic_test.go, line 89 [r1] (raw file):
Previously, TauZero (Brian Bickerton) wrote…
> See comment on the `get` handler

Done.

Comments from Reviewable

Reviewed 2 of 2 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

@tauzero PTAL
Previously, mmlb (Manuel Mendez) wrote…
> #### Add kv provider
>
> #### Issues affected
>
>
>
> Resolves #123
>
>
>

Review status: 32 of 33 files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Reviewed 1 of 1 files at r3.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Sessionmanager not detecting logged in state changes correctly

(might be documentation?)
Scenario: (after building simple OP and client using this exaple: http://docs.identityserver.io/en/release/quickstarts/7_javascript_client.html)
Start:
Client - not logged in
OP - not logged in
When: logging in with OP (not client) and refreshing client
Expecting: client showing user details
Result: "User not logged in"

I changed the sample app,

adding a silent login callback html
changing the config (add silent_redirect_uri)
changed the mgr.getUser function:

mgr.getUser().then(function (user) {
    if (user) {
        mgr.querySessionStatus().then(
            function () {
                log("User logged in ", user.profile);
            },
            function () {
                log("Session expired ", user.profile);
                mgr.removeUser();
            }
        );
    }
    else {
        log("User not logged in, trying silent login");
        mgr.signinSilent().then(function (user) {
            if (user) {
                log("User logged in silent", user.profile);
            }
        }, function () {
        });
    }
});

The only issue I end up with is that the client does not get automatically notified when a user logs in. After a refresh it is ok now.

When: logging in with OP (not client) and refreshing client
Expecting: client showing user details

Yea, this is not how it's expected to work. The event is for notifications when a authenticated user's status has changed at the OP.

Is my change to my local example a good practice? Or is there a better way to check the users login state?

Well, getUser tells you if you have a local "session" in your JS app, and the choice to use or not use that if up to your client logic. That local session is unrelated to the SSO session at the OP. How you want to associate those lifetimes is up to your requirements. I can't answer that for you.

My question is answered. So I'll close the issue. Thanks for the info.

np


introduce cargo make

Closes https://github.com/internet2-org/rust-aluvm/issues/38

Codecov Report

Merging #39 (bb06de4) into master (75db200) will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master     #39   +/-   ##
======================================
  Coverage    14.8%   14.8%
======================================
  Files          18      18
  Lines        3904    3904
======================================
  Hits          579     579
  Misses       3325    3325

Impacted Files
Coverage Δ

src/lib.rs
4.6% <0.0%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 75db200...bb06de4. Read the comment docs.


A few items to consider (and possible pull requests)

Minko, I just wanted to relay a few minor tweaks I've made to my project to see if you'd have any interest in seeing pull requests for these:

A separate watch-start.build.dev Gulp task that runs only once during serve.dev. This way, extra tasks like clean and tslint will run once, but afterwards the faster build.dev is run on subsequent watch triggers.
A separate build.test.quick Gulp task that is run during Karma watch triggers. This one omits the tslint to speed up the test build.
(In reference to both of the above) Those might be better handled with a tslint.once task, so that linting can run, but only once?
Applying the same TYPED_COMPILE_INTERVAL from the build.js.dev to build.js.test to further speed up the test compile.
I have a simple code generator task working, using node-plop. It's not amazing but I do find it handy to spit out components+specs, services+specs, update some index.ts files, etc. Not sure if you'd actually want to include this with the seed, because the type of code one wants to generate probably differs alot between developers, but it could be a wiki page topic.

Running clean.dev before serve.dev definitely makes sense, not sure about tslint. I believe text editors are the tool to report/autofix linting errors, which helps us speed up the build.
It makes sense to drop tslint from build.test too.
node-plop also sounds like a great suggestion. What bothers me is that we'll expand the scope of the project a lot which will introduce additional complexity and a lot of feature requests. We will later need to introduce some AST tools for generation of routes and basically we'll go in the direction of the CLI.
What do you think about introducing clean.dev as first task of serve.dev, drop tslint from build.test and

Applying the same TYPED_COMPILE_INTERVAL from the build.js.dev to build.js.test to further speed up the test compile

Sorry for the delay, Minko. I'll try to look at these items (dropping tslint from build.test, adding the compile interval to build.js.test, and adding clean.dev to the servie.dev sequence) in the next few days.
My only thinking with running tslint once when starting a serve was just to provide that info at least once. It only slows the serve task by a few seconds, and only does it one time. Text editors are the ideal place to identify things like that, but with a large codebase it's easy to have sections of code that aren't looked at frequently, which doesn't give an IDE/editor much of a chance to flag problems. Since tslint includes the whole codebase, it seemed like a worthwhile sanity check.

My point against running tslint before you run the production build and server is that at this point you're in the beginning of a coding session which will, most likely, introduce new linting errors. I'm also trying to keep the set of tasks as small as possible, that is why I suggested making modifications to already existing ones instead of introducing new.
What do you think? Does this make sense?

Sure, makes sense. I was just trying to expand on my logic. No worries! :-)


unable to install package because of permission access

Describe the bug
I try to create an angular app but command line says it doesn't have permission access
Link to the Bolt URL that caused the error
http://localhost:5173/chat/angular-app-2
Steps to reproduce
docker or local installation
ask to create an angular app
Expected behavior
this should install (I guess ) packages as my last try was using docker
Screen Recording / Screenshot

Platform

OS: Mac os sequoia
Browser: firefox
Version: [e.g. 91.1]

Provider Used
huggingface
Model Used
No response
Additional context
No response

What is your exact prompt?
I testet with "Initialize a basic angular app" (same model but on openrouter) and it created a basic app structure and was able to npm install
Just got an error then which resolving but thats on step further and could be fixed by the ai (did not test further)

I fixed the issue by authorising docker to find for devices on my local network and communicate with them


feat: instantiation support

Proposed changes
I was struggling to find a way to instantiate a referenced Object. I created some extension methods that allow you to instantiate the referenced Object and return the interface.
Types of changes

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Refactoring (no functional changes, no api changes)
[ ] Code style update (formatting, renaming)
[ ] Build related changes (workflow changes)
[ ] Documentation Update (readme, changelog)
[ ] Other, please describe:

Issue
Link
What is the current behavior?
Cannot instantiate referenced Object
What is the new behavior?
Added support for instantiating Objects
Checklist

[x] The code compiles
[x] I have tested that this doesn't break existing code (unless it is an explicit breaking change)
[ ] I have tested that the (new) functionality/fix works as intended
[ ] I have added necessary documentation (if appropriate)

Further comments
I'm pretty sure there may be additional safety checks required for edge cases.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Bug in functions schema

What seems off:
The functions key isn't nested inside properties here:
https://github.com/serverlessworkflow/specification/blob/8a7152e0931a5f41a1c4abaf344d7ce1fd92410f/schema/functions.json#L6
I think it is meant to be?
What you expected to be:
Nested inside properties.
Anything else we need to know?:
It might be a good idea to run all the schemas through a strict validator. ajv's strict mode would fit the bill, it reports:
Error: strict mode: unknown keyword: "functions"

Environment:

Specification version used:

Which spec version? Main? Yes, we are missing a CI to validate our schemas indeed.

Just follow my link and click "blame" to see it was introduced in bb5fa9f2f5a1ca2508faa776bd89ef68cd886dbd. No idea which spec versions that covers, 0.6+?

The functions is a parent object defined in a separate file. So when validating, one should use all the files including in https://github.com/serverlessworkflow/specification/tree/main/schema directory. I have a few SDKs using these files to validate and generate workflows, and no one has reported a bug like this before. Do you mind giving more details of how are you validating on your end?
I'll try to do something on my side too using AJV.

Ah, I see, if you use workflow.json then the reference resolves correctly.
I got confused because functions.json contains top-level keys type and required so it looks like you could use it as a standalone schema, but these settings aren't actually ever used since the top level isn't referenced anywhere, correct? Instead functions.json is a "library" useful only when referenced from workflow.json.
You could consider removing these top-level keys, and perhaps adding a comment, to make it more clear that the file isn't meant to be used standalone.

But then I would lose the functions.json independent file.

@jscheid @cdavernas I made the oneOf work:
"oneOf": [
    {
      "type": "string",
      "format": "uri",
      "description": "URI to a resource containing function definitions (json or yaml)"
    },
    {
      "type": "array",
      "description": "Workflow function definitions",
      "items": {
        "type": "object",
        "$ref": "#/definitions/function"
      },
      "additionalItems": false,
      "minItems": 1
    }
  ]

Just had to remove type.

But arent't you moving the oneOf in the validation instead then ? Because if I understand, the function definition would be either { "ref": "an-uri" } or { "name": "my-func", "type": "rest", ... }

In this case, we can add all the properties and require everything (like name, type, operation) only when ref is null.


Carousel - Add "wrap"-option

Hey there,
on bootstrap you can stop an carousel from endless cycling by set "wrap" to "false".
Looking into the sources here https://github.com/angular-ui/bootstrap/blob/master/src/carousel/carousel.js#L82 I think this is currently not possible for angular js bootstrap ui, isn't it?
Would be nice to have such an Option.

To clarify, you mean that it will stop on the last slide instead of going back to the first?

Yes, sorry for beeing unclear ... :)

When this feature will be available?


left sidebar: stop composebox from opening when topic clicked. Fixes …

…#3886

Looked it over and it looks good @lonerz!

So I need to think about this a bit more -- there's a lot of conditionals around that, and maybe this isn't exactly right.  Will play with it in the next day or so.
BTW @lonerz we usually put the Fixes: part on its own line by itself, rather than in the first line of the commit.

@timabbott how do you put the commit message on another line? Do you have to git commit --amend and put it onto another line?

Yeah you can't do it with git commit -m

In many cases, you want a multi-line commit message anyway to explain your reasoning, so I don't tend to use git commit -m very often anyway.

@timabbott fixed the issue. Updated PR with new commit message also :)

Can you explain how the new logic works?  I don't understand it and kinda suspect it's not right in all cases :)

If the compose box is open and switch topics, the compose box should stay open no matter if it is empty or not. This is why I added !compose.composing().
The deleted portion of the code would open the compose box when the compose box was empty, which was what we didn't want.

Doesn't !compose.composing imply !had_message_content?  Also, I think we still want to change the recipient for an empty compose when switching narrows?  I think the old code did that, and the new code will not.
I guess you can just test the various cases.

@timabbott doesn't !compose.composing tell you if the compose box is open?

Right, so there's definitely not going to be anything in the compose box if it's closed...

Ah, so I don't need !had_message_content.
Currently, bringing back the deleted code because I understand what I was missing.

@timabbott updated the PR. Sorry for the misunderstanding

@timabbott any tips on how to fix front-end failures

#3886

#3992

#3992

Hmm, I'm not sure what's happening there.  Reproducible locally, though, so I think something is actually broken.  Try watching the JS console and playing around with narrowing/unnarrowing/reloading with this change and I bet you'll find the issue.

@timabbott I think the issue is the compose box is open and when you narrow to a topic, the compose box is still open. Then when you try to unnarrow, it closes the compose box only and doesn't unnarrow. Am I understanding this correct? If so, I don't know what to actually fix. Should I change the tests, since we are technically changing how the compose box works.


Kit edit bug???

Expected behavior
Items can be successfully changed.
Observed/Actual behavior
/
How to Recreate (if known)
Video
https://youtu.be/cSutUEhXLcQ
Stack trace
https://pastebin.com/eY8HA585
Plugin list

use CarbonSpigot 3.4
Frost version
11.5
Agreements

[X] I have searched for and ensured there isn't already an open issue regarding this.

Other
No response

Incomplete stacktrace, though, that is caused by one of the anticheats you're using together (Intave and Matrix).
I'd suggest trying every check individually until you find the one that causes that issue to occur.

We removed all AntiCheat and AntiCrash plugins. but it still has the problem.

warn.txt
Video（All AntiCheat and AntiCrash were uninstalled at the time the video was shot.）：https://www.youtube.com/watch?v=IJHS6-djCaQ

Then there’s another plugin causing it, since it doesn’t happen on any other server running Frost.
Try removing plugins one by one until you find the one that causes it.

We've culled to this, but the problem persists, could this be a database or Spigot issue?

Something is interfering with Frost, the stacktrace isn't complete so I can't tell what's causing it.

[08:14:35] [WARN]: Exception in thread "Craft Scheduler Thread - 0" org.apache.commons.lang.UnhandledException: Plugin Frost v11.5 generated an exception while executing task 24
[08:14:35] [WARN]: 	at org.bukkit.craftbukkit.v1_8_R3.scheduler.CraftAsyncTask.run(SourceFile:57)
[08:14:35] [WARN]: 	at org.github.paperspigot.ServerSchedulerReportingWrapper.run(SourceFile:22)
[08:14:35] [WARN]: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[08:14:35] [WARN]: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[08:14:35] [WARN]: 	at java.lang.Thread.run(Thread.java:748)
[08:14:35] [WARN]: Caused by: java.util.ConcurrentModificationException
[08:14:35] [WARN]: 	at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:911)
[08:14:35] [WARN]: 	at java.util.ArrayList$Itr.next(ArrayList.java:861)
[08:14:35] [WARN]: 	at com.bizarrealex.aether.Aether$1.run(Aether.java:109)
[08:14:35] [WARN]: 	at org.bukkit.craftbukkit.v1_8_R3.scheduler.CraftTask.run(SourceFile:59)
[08:14:35] [WARN]: 	at org.bukkit.craftbukkit.v1_8_R3.scheduler.CraftAsyncTask.run(SourceFile:53)
[08:14:35] [WARN]: 	... 4 more
[08:14:53] [WARN]: Exception in thread "Craft Scheduler Thread - 6" org.apache.commons.lang.UnhandledException: Plugin Frost v11.5 generated an exception while executing task 108
[08:14:53] [WARN]: 	at org.bukkit.craftbukkit.v1_8_R3.scheduler.CraftAsyncTask.run(SourceFile:57)
[08:14:53] [WARN]: 	at org.github.paperspigot.ServerSchedulerReportingWrapper.run(SourceFile:22)
[08:14:53] [WARN]: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[08:14:53] [WARN]: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[08:14:53] [WARN]: 	at java.lang.Thread.run(Thread.java:748)
[08:14:53] [WARN]: Caused by: net.minecraft.server.v1_8_R3.CancelledPacketHandleException
There is a longer warn here, and the rest of the warn are as short as the one above. There is a phenomenon that there is no problem to edit KIT for the first time after the server is opened, but if you save it and edit it again, there will be a problem.
https://www.youtube.com/watch?v=AeX8cmYGaYo

I need the full stacktrace for this one:
[08:14:53] [WARN]: Exception in thread "Craft Scheduler Thread - 6" org.apache.commons.lang.UnhandledException: Plugin Frost v11.5 generated an exception while executing task 108
[08:14:53] [WARN]: at org.bukkit.craftbukkit.v1_8_R3.scheduler.CraftAsyncTask.run(SourceFile:57)
[08:14:53] [WARN]: at org.github.paperspigot.ServerSchedulerReportingWrapper.run(SourceFile:22)
[08:14:53] [WARN]: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[08:14:53] [WARN]: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[08:14:53] [WARN]: at java.lang.Thread.run(Thread.java:748)
[08:14:53] [WARN]: Caused by: net.minecraft.server.v1_8_R3.CancelledPacketHandleException

The first stacktrace is unrelated, that's caused by the scoreboard.
Try running Frost alone with just the KnockbackController and see if it happens, if it does, then it's something from the Spigot you're using.

It's really weird, we tried carbonspigot and ispigot, even regenerated paper.yml, spigot.yml, bukkit.yml files, reset the database, the problem still exists. plugin has been trimmed down to the bare minimum.

[08:14:53] [WARN]: Exception in thread "Craft Scheduler Thread - 6" org.apache.commons.lang.UnhandledException: Plugin Frost v11.5 generated an exception while executing task 108
[08:14:53] [WARN]: at org.bukkit.craftbukkit.v1_8_R3.scheduler.CraftAsyncTask.run(SourceFile:57)
[08:14:53] [WARN]: at org.github.paperspigot.ServerSchedulerReportingWrapper.run(SourceFile:22)
[08:14:53] [WARN]: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[08:14:53] [WARN]: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[08:14:53] [WARN]: at java.lang.Thread.run(Thread.java:748)
[08:14:53] [WARN]: Caused by: net.minecraft.server.v1_8_R3.CancelledPacketHandleException
That's all that popped up on the server.
I also found that when this happens, it quits in the kitedit interface no matter which item bar is clicked.
https://youtu.be/f2U0BTv6SEM

You probably made some changes to the Kit Editor code since nobody else is having this issue, compare yours to the one in the Frost repository.

Just tested, it seems to be working fine.


fix(Search): fix definition of resultRenderer prop in typings

I believe the resultRenderer expects a single react element not an array of them. See related issue:
#2960

Released in<EMAIL_ADDRESS>


License comment block

Hi!
Could you please use a comment block like /*! foo */ for the license? This way we can ignore it when using Uglify or other minifiers.

+1

All that information being in the file is redundant since it's in package.json - I've removed it instead.


Minor doc fixes

Coverage remained the same at 80.108% when pulling 39365d69abfc6b6dc07dd8f9af96663c900af754 on jpdna:docfix2 into f8c441a4a126154f2258ab60b41fc7b43a43ead3 on bigdatagenomics:master.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/mango-prb/868/
Test PASSed.

Thanks @jpdna!


📃: Poker Hand Prediction

:red_circle: Title :  Poker Hand Prediction
:red_circle: Aim : Predict poker hand using machine learning algorithms
:red_circle: Brief Explanation : Prediction of various poker hands like full house, straight, flush etc. using machine learning algorithms.
Screenshots 📷
 N/A

:white_check_mark: To be Mentioned while taking the issue :

Full name :  Aviral Garg
What is your participant role? (Mention the Open Source Program name. Eg. GSOC, GSSOC, SSOC, JWOC, etc.) SSOC Contributor

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎

@aviralgarg05 go ahead.


Update SECURITY.md

Checklist for tasks done

[x] I have performed a self-review of my code
[x] Ready for merge

except? or do you mean expect?

i mean except


Fix flaky tests caused by nondeterministic of HashSets and HashMaps

The tests below were found flaky because of the ordering of HashSets and HashMaps. The orders of elements in the HashSets and HashMaps are not the same every time the test being called. In this case, HashSet is changed into LinkedHashSet, and the unordered results from HashMap are sorted for comparing. This code change is trying to fix the flaky tests mentioned above, because they sometimes fail (as the picture showed) and sometimes pass when comparing the strings. The failure could be reproduced by the commands above by using the tool of NonDex. The code change is to make sure the tests will always pass in this case.

org.modelmapper.internal.converter.ArrayConverterTest.shouldConvertFromSet
org.modelmapper.internal.TypeInfoImplTest.shouldProduceMutators
org.modelmapper.internal.TypeInfoImplTest.shouldProduceAccessors

The test failures could be reproduced by

mvn install -pl . -am -DskipTests
run tests with NonDex
mvn -pl core edu.illinois:nondex-maven-plugin:1.1.2:nondex   -Dtest=org.modelmapper.internal.TypeInfoImplTest#shouldProduceAccessors

@chhsiao90  Hello. Can I know if I can get this PR reviewed? Thank you!


Dark mode menu issues

Dark mode has some issues with dropdown menus because the text turns white but the background remains white.

Also happens in the resolve menu

Seems to be browser specific. Here's Linux/Firefox:

Windows/Firefox has the same issue


feat: linking phrase to term via join table

Resolves #21
Proposed Changes

[x] linking phrase to term via join table

This pull request is now managed with CodeReviewHub. Refresh.


Adding a Prepare stage for the sprite pipeline

Objective
The entire logic for rendering preparation is in the queue stage and should be moved in a prepare stage.
Solution
Add a prepare stage.

The separation logic between white and colored sprites is move to the extraction stage
The new prepare stage spawns the sprite batches and computes the vertex data
The queue stage only handles bind groups and render phases

I also added some documentation.
Related MRs:

#5103 would allow cleaner code
#5213 needs this MR to be performant

Output from many_sprites stress test:
This branch:
2022-07-07T18:51:54.244366Z  INFO many_sprites: Sprites: 102400
2022-07-07T18:51:54.244426Z  INFO bevy diagnostic: frame_time                      :    0.047533s (avg 0.047724s)
2022-07-07T18:51:54.244438Z  INFO bevy diagnostic: fps                             :   21.038135  (avg 20.982425)
2022-07-07T18:51:54.244443Z  INFO bevy diagnostic: frame_count                     : 507.000000

Main:
2022-07-07T18:53:37.460995Z  INFO many_sprites: Sprites: 102400
2022-07-07T18:53:37.461047Z  INFO bevy diagnostic: frame_time                      :    0.048746s (avg 0.050301s)
2022-07-07T18:53:37.461059Z  INFO bevy diagnostic: fps                             :   20.514588  (avg 19.940816)
2022-07-07T18:53:37.461063Z  INFO bevy diagnostic: frame_count                     : 504.000000

~1 FPS gain

New output from many_sprites stress test:
This branch:
2022-07-09T11:27:08.678547Z  INFO many_sprites: Sprites: 102400
2022-07-09T11:27:08.678605Z  INFO bevy diagnostic: frame_time                      :    0.047834s (avg 0.042740s)
2022-07-09T11:27:08.678612Z  INFO bevy diagnostic: fps                             :   20.905776  (avg 23.421536)
2022-07-09T11:27:08.678617Z  INFO bevy diagnostic: frame_count                     : 500.000000

main:
2022-07-09T11:28:57.559113Z  INFO many_sprites: Sprites: 102400
2022-07-09T11:28:57.559164Z  INFO bevy diagnostic: frame_time                      :    0.050723s (avg 0.050071s)
2022-07-09T11:28:57.559171Z  INFO bevy diagnostic: fps                             :   19.714747  (avg 20.006181)
2022-07-09T11:28:57.559176Z  INFO bevy diagnostic: frame_count                     : 500.000000

~3 FPS gain

New output from many_sprites stress test:
This branch:
2022-07-09T11:27:08.678547Z  INFO many_sprites: Sprites: 102400
2022-07-09T11:27:08.678605Z  INFO bevy diagnostic: frame_time                      :    0.047834s (avg 0.042740s)
2022-07-09T11:27:08.678612Z  INFO bevy diagnostic: fps                             :   20.905776  (avg 23.421536)
2022-07-09T11:27:08.678617Z  INFO bevy diagnostic: frame_count                     : 500.000000

main:
2022-07-09T11:28:57.559113Z  INFO many_sprites: Sprites: 102400
2022-07-09T11:28:57.559164Z  INFO bevy diagnostic: frame_time                      :    0.050723s (avg 0.050071s)
2022-07-09T11:28:57.559171Z  INFO bevy diagnostic: fps                             :   19.714747  (avg 20.006181)
2022-07-09T11:28:57.559176Z  INFO bevy diagnostic: frame_count                     : 500.000000

~3 FPS gain

Cool. :) Could you get set up to use Tracy for profiling and publish the frame time graphs comparing the run from main and from this PR? There is documentation here: https://github.com/bevyengine/bevy/blob/main/docs/profiling.md#backend-trace_tracy and use Tracy 0.8.1 as that works with current bevy main. I have copied one of the CI testing ron files like: .github/example-run/breakout.ron to ../benchmark.ron and edited the number of frames to execute to 1500. Then for each branch of interest, I run the Tracy capture tool outputting to an appropriately-named file like ./capture-release -o TOPIC-BRANCH-date +%Y%m%d-%H%M.tracy (renaming TOPIC and BRANCH as appropriate) and then run an example like CI_TESTING_CONFIG=../benchmark.ron cargo run --release --features bevy_ci_testing,trace_tracy --example many_sprites and leave it focused and let it run. Then switch branches and run again. Then open the reference trace and click the compare button at the top and open the other trace, select the frames radio button and screenshot the graph and timing statistics.

@superdump

do you want me to do the same test without the color separation?

@superdump
Red: main branch Yellow: This branch

Cool! This is why I like seeing the Tracy graphs of the frame time distribution. It makes the differences much more clear than a sliding window average fps. :)

do you want me to do the same test without the color separation?

Ideally it would be good to see if the PR in its current state incurs a cost or benefit for the sorting/batching systems in the render app sort stage. I don't have a good gut feeling for that at the moment. And then yes, I suppose it would be good to compare before/after the split. This is performance-sensitive code and is 'hard-won' so it's great that this PR brings a performance benefit, but we should also check that it doesn't introduce a regression in a more varied and real-world-ish test.

It feels like this MR brings perf gains but also a more consistent framerate

Yup, it's looking very good so far! :) A 10% frame time reduction is awesome!

I'll have to try it out. That looks great if true! :)

If the separation I did works correctly I think ExtractedSprites should store a HashMap<Color, Vec<ExtractedSprite>> intead

IIRC, sorting all the sprites was one of the major bottlenecks in the sprites renderer. It makes sense to me that splitting the sprites preemptively to sort them as multiple smaller arrays, rather than one huge array, would improve perf.
Potentially, now that there are multiple separate buckets of data, these sorts could also be done in parallel (maybe just if the arrays are large). Maybe that could further improve perf?

The other major bottleneck for sprites rendering is the memory bandwidth bloat from all the data in vertex attributes. However, afaik, we have all thought hard about that area and haven't found ways to reduce it much, without moving to a different rendering approach using storage buffers (incompatible with WebGL2).

Could you update this on top of main please? :)

It's in progress, #5310 brought some conflicts

@superdump do you think this is worth keeping in the milestone as we draw close to release? Seems great but not critical to me?

It isn't critical, but it is a night and day enormous performance improvement for many_sprites when using many separate batches.
I just tested on an M1 Max and I see similar performance uplift.

Yellow - main at the root of the PR branch at the time of testing.
Red - this PR.

This does look suspicious though. I've been trying to figure out what I'm missing. I just thought I would compare the statistics for main at the root of the PR for queue_sprites + system commands overhead + main_pass_2d, and then this PR with prepare_sprites + system commands overhead + queue_sprites + system command overhead + main_pass_2d. Everything but prepare_sprites takes very little time, which seems very odd. So now my guess is that the batching logic was broken and everything is being drawn in one batch but we didn't notice. :) This needs to be investigated. @ManevilleF
I did see some z-fighting on one sprite in one run of many_sprites but I thought it was just that they had the same z and the same texture, so their order could vary. I think if the z is the same and the image handle the same, then we should also compare the entity id perhaps? Anyway, that's a separate issue to this PR.

I'm not sure I understand, are you saying that this PR is fixing batching logic?
If so I think we should compare bevy 0.7, main and this PR. Maybe the logic was broken on main ?

I'm not sure I understand, are you saying that this PR is fixing batching logic? If so I think we should compare bevy 0.7, main and this PR. Maybe the logic was broken on main ?

I was saying that this PR breaks batching logic. See above. :)

So the prepare stage should spawn one batch per ExtractedSprite ? With a range of 1? When are the batches merged together?

No, it’s rather that you add a SpriteBatch for each sprite with the batch range that is to the best of your knowledge. So in this case the plain sprites would have just 0, then 0 to 1 inclusive, 0 to 2, etc. and the tinted ones would also have something similar. But I think each has its own index within the batch and its own sort key. Then all the plain and tinted and mesh2d and everything get sorted so now they’re interleaved with each other. And then the batch system will merge / split batches based on whether there are other things that are from other batches or that are non-batchable between. So if you have sprite batches with plain index 0 batch 0 to 0, then tinted index 0 batch 0 to 0, then plain index 1 batch 0 to 1, then it would have to split the plain batch because there is a tinted batch item between. I’d suggest to look closely at how the previous code worked.

I know this PR is closed now, but i just have a comment regarding the phase item batching. @superdump @ManevilleF
It is not strictly necessary to have one phase item per sprite for correct sorting and batching.
As you have said previously, the problem is that other non-sprite items (like Mesh2d or Text2d or whatever) could exist, and if their Z coordinate is in-between sprites, then those batches have to be broken up.
So the thing is, what we actually care about are the Z coordinates. Respecting the Z layering.
So you could preemptively batch things somewhat and spawn a pre-batched phase item of sprites, as long as they have the same Z coordinate. Group the sprites based on Z coordinate. This should still work correctly (allow other things to be rendered sandwiched between sprites) and also reduce the work for the phase item batching stage somewhat, when there are many sprites at the same Z.

I know this PR is closed now, but i just have a comment regarding the phase item batching. @superdump @ManevilleF
It is not strictly necessary to have one phase item per sprite for correct sorting and batching.
As you have said previously, the problem is that other non-sprite items (like Mesh2d or Text2d or whatever) could exist, and if their Z coordinate is in-between sprites, then those batches have to be broken up.
So the thing is, what we actually care about are the Z coordinates. Respecting the Z layering.
So you could preemptively batch things somewhat and spawn a pre-batched phase item of sprites, as long as they have the same Z coordinate. Group the sprites based on Z coordinate. This should still work correctly (allow other things to be rendered sandwiched between sprites) and also reduce the work for the phase item batching stage somewhat, when there are many sprites at the same Z.

I closed this in favor of https://github.com/bevyengine/bevy/pull/6621 which doesn't try to change any logic ( since I ended up breaking the batching)
But from what you are saying there could be a way to spawn the sprite batchs in the prepare stage and then handle the phases in the queue stage?
Btw I'm only doing this in order to implement Slicing and tiling (https://github.com/bevyengine/bevy/pull/5213) But I'm in way over my head here, as my understanding of the render pipeline is not great

@ManevilleF
I'm just trying to help you understand why sprites are represented in phase items the way they are. :)
Conceptually, you can think of each phase item is a "thing to draw". Bevy's phase items are the abstraction that allows the engine to generically optimize the entire set of objects to be rendered in the whole scene, without having to know the details of how each one is to be rendered exactly.
The original purpose for all this phase items stuff (and the PhaseSort render stage) is to be able to sort everything in the entire scene (front-to-back for opaque render passes to reduce overdraw, back-to-front for blended render passes for correct transparency / alpha blending).
Everything that needs to be rendered (sprites, meshes, shapes, other custom user things, ...) represents itself as some sort of phase item. This is the job of the Queue systems: to generate "phase items" for the things they want to render, and add them to bevy.
Each phase item contains a "sort key" (typically the Z distance from the camera) and other metadata, as well as the "draw function", which is what contains the code to do the actual rendering (wgpu draw calls).
During the PhaseSort stage, Bevy will sort all the phase items. During the Render stage, it will call their "draw functions", so they can render themselves however they like.
When sprite batching was implemented in Bevy, PhaseSort/PhaseItems were extended to also do batching as well as sorting. After all the items in the scene are sorted, there is a system that will try to opportunistically batch them together. It will check if successive items are "compatible" and merge them. For now, this is only used for sprites (AFAIK), but it is a general abstraction that could be extended to other things, too.
So, this is how sprites become "batched". If there are many "sprite" phase items one after another, and there is nothing in between, they get merged into a single phase item (whose draw function will then render them all using one draw call).
There can be other 2d things, besides sprites. For example, Mesh2d, Text2d, shapes/tilemaps from 3rd party plugins, some sort of custom things implemented by users, ... the list goes on. These things would also have their own phase items.
Imagine you have 5 sprites at Z = 1.0, and 15 sprites at Z = 3.0. All of these 20 sprites can be batched together.
Now, imagine that the user spawns some Text2d with Z = 2.0. It has to be rendered in-between. Now, Bevy needs to batch the first 5 sprites together, then draw the text, and then batch the remaining 15 sprites. If you draw all 20 sprites as one batch, the result will be incorrect.
If every individual sprite is a separate phase item, all of this "just works". Bevy just iterates through all phase items and merges together what it can, replacing the phase items of the sprites with phase items that draw a whole batch at once.
Now, the question is, could you "pre-batch" things? Could you create these "sprite batch" phase items ahead of time? Instead of the queue system creating one phase item per sprite (which would then be merged by the general "phase batching" system), could it create already-batched phase items to begin with?
And the answer is: yes, but only if it respects all the aforementioned considerations. It must respect the fact that other non-sprite items might exist.
What this really means is that you can group sprites together by Z coordinate, but no more than that. Using the example from above, the queue system could have created a phase item for the 5 sprites at Z=1.0, and another phase item for the 15 sprites at Z=3.0. Bevy will then happily merge those two phase items into one big 20-sprite batch, if it can (when there are no non-sprite items in between). This would have been just as correct as creating one phase item for each individual sprite.

@inodentry Thank you very much ! This explanation is very clear and helps a lot.


update to node 20 in extensions action before merging latest from setup-node

before merging #182

Looks like it's already on 20!


test: improve language picker coverage

By validating that on change methods are actually run

Codecov Report

Merging #225 (731dcce) into main (7ba7f08) will increase coverage by 1.74%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #225      +/-   ##
==========================================
+ Coverage   85.31%   87.06%   +1.74%
==========================================
  Files          28       28
  Lines         286      286
  Branches       60       60
==========================================
+ Hits          244      249       +5
+ Misses         42       37       -5

Impacted Files
Coverage Δ

src/contexts/LanguageContext.ts
100.00% <0.00%> (+33.33%)
:arrow_up:

src/components/LanguagePicker/index.tsx
100.00% <0.00%> (+33.33%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7ba7f08...731dcce. Read the comment docs.


e2e: Fix authentication issue when connecting to the OCP image registry

Signed-off-by: timflannagan<EMAIL_ADDRESS>
Description of the change:
#2690 updated this test case to avoid creating the requisite testing resources in the same global operators namespace as the rest of the CatalogSource e2e tests, but we neglected to update how we generate the auth bearer token that's used in the skopeo Pod to authenticate to the internal OCP image registry.
Motivation for the change:
Fix failing/flaky e2e tests.
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /doc
[ ] Commit messages sensible and descriptive
[ ] Tests marked as [FLAKE] are truly flaky
[ ] Tests that remove the [FLAKE] tag are no longer flaky

/lgtm
Surprised this didn't stop https://github.com/operator-framework/operator-lifecycle-manager/pull/2693 from merging


Helm: Add Wireguard support

This PR is to add the Wireguard support to the Helm charts.
Following comment from PR #15383 some refactoring has been done for the
encryption part: we are now having two subchoices: IPSec or Wireguard for
the encryption.
Fixes: #15483
Signed-off-by: Youssef Azrak<EMAIL_ADDRESS>Helm: Add Wireguard support

Not sure if this is the best approach but I tried to make it clean from a user perspective. Also would be it be good to add a comment like "IPSec and Wireguard are mutually exclusive"?

Converting it to draft. @youssefazrak Please ping once you have addressed the comments.

@youssefazrak Friendly ping as we are getting closer to v1.10 release. Are you going to work on addressing comments?

@brb Apologies guys I got sick. I have no ETA for my return. Could be Friday could be next week. If the release is imminent please assign it to someone else. If it's in two weeks I will take care.

@youssefazrak Ouch, take care! No problem, @jibi will finish the PR.

I'm closing this and opening a new one as I can't push commits to youssefazrak:helm_wireguarg

@youssefazrak take care! :heart:


There are hidden users in our influxdb 2 server

After migrating from Influxdb 1 to 2, there are hidden users.
This authorizes:
curl "http://influx.example.nl:8086/query?db=telegraf&u=nagios3&p=$PASSWORD&q=SELECT+%2A+FROM+bla+ORDER+BY+DESC+LIMIT+1&epoch=s"
{"results":[{"statement_id":0,"error":"database not found: telegraf"}]}

But when I change the user or password:
curl "http://influx.example.nl:8086/query?db=telegraf&u=nagios3&p=${PASSWORD}suffix&q=SELECT+%2A+FROM+bla+ORDER+BY+DESC+LIMIT+1&epoch=s"
{"code":"unauthorized","message":"Unauthorized"}

curl "http://influx.example.nl:8086/query?db=telegraf&u=nagios3z&p=$PASSWORD&q=SELECT+%2A+FROM+bla+ORDER+BY+DESC+LIMIT+1&epoch=s"
{"code":"unauthorized","message":"Unauthorized"}

But I can't find the 'nagios3` user:
influx user list|grep -Fi nagios || echo "nothing"
nothing

influx auth list|grep -Fi nagios || echo "nothing"
nothing

Also can't find it with v1:
influx v1 auth list
Error: Authorization not found.
See 'influx v1 auth list -h' for help

Expected behavior:
Be able to manage all authorizations.
Actual behavior:
You can authorize with hidden users.
Environment info:

Linux 4.15.0-72-generic x86_64
Ubuntu 18.04
Installed from deb https://repos.influxdata.com/ubuntu bionic stable
Influx version: Influx CLI 2.0.1 (git: 37cc047) build_date: 2020-11-11T03:53:31Z
aptitude show influxdb: 2.0.1

Logs:
Only during influx v1 auth list I see something:
dec 07 14:29:07 spire influxd[9525]: ts=2020-12-07T13:29:07.177993Z lvl=error msg="api error encountered" log_id=0QwI7bB0000 error="authorization not found"

Hi @wiebeytec, thanks for the report. I'd expect the nagios3 user to appear in the output of influx v1 auth list. Can you try a few things for me?

What's the output of influx v1 auth list on its own?
Does the problem reproduce if you use 2.0.2 instead of 2.0.1?

I had posted the output of influx v1 auth list. But, the fault seems our own. We had INFLUX_USERNAME and INFLUX_PASSWORD in our Bash environment. We noticed because one team member uses Fish, not Bash.
Removing those env vars made everything work.


PHOENIX-6579 ACL check doesn't honor the namespace mapping for mapped…

… views.

This got me thinking that we should in fact
use "^"+tableName.getNameWithNamespaceInclAsString()+"$"
to avoid a similar stituation, where we have permission for ns:prefixTable, and we do not add the required new permission for ns:prefixTableFoo because we THINK we already have it.
I think I'm going to open am HBase ticket about the horrific API design (if one doesn't exist yet).

Closing as this has been merged.


add ssl tests (this is just to test against the CI)

I think I fixed the hang.
The tests still fail sometimes though.

so locally (linux), I have a 10% failure rate but travis consistently fails one of the tests.

So, I have a couple thoughts that may make it easier to get things passing:

I see the port 12345 specified in the test, but no where else. It seems like the port doesn't need to be specific, and so to prevent concerns with the port being busy in the next tests, it could be better to use a port of 0, and then after the listener is bound, grap the local addr to check what port is being used.
I actually wouldn't use a hyper server for this. It doesn't have the ability to shutdown (listening.close() is a lie).
Instead of panic!(e), try panic!("{:?}", e). The message should be better, hopefully.

I'm going to close as in-active.


[FLINK-23412][table][docs] - Description improvement of dynamic table sink and full stack example

What is the purpose of the change

Dynamic table sink and full stack example description improvement.

Brief change log

Improved description of dynamic table sink and full stack example.

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper:  no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

@flinkbot run azure

@leonardBang @wuchong @Airblader - Can you please review this minor enhancement ?  Thanksi


CI Build fix

Fix for Too long with no output (exceeded 10m0s): context deadline exceeded in circleci
Fix for errors like:
https://app.circleci.com/pipelines/github/gruntwork-io/terragrunt/1248/workflows/c75fd373-b1c2-4074-8a49-81b3954dbf59/jobs/8399
https://app.circleci.com/pipelines/github/gruntwork-io/terragrunt/1246/workflows/952023d5-f81c-4870-8fd1-df981720d7de/jobs/8393

From execution history looks like after upgrading to Terraform 1.1 integration tests started to take more time:
Before upgrade:
6:37
https://app.circleci.com/pipelines/github/gruntwork-io/terragrunt/1222/workflows/b399e73e-8ec2-40f6-be19-c16f7b78075a/jobs/8283
6:41
https://app.circleci.com/pipelines/github/gruntwork-io/terragrunt/1231/workflows/975d727c-fa24-49b8-85a9-858110f21aec/jobs/8316
After upgrade:
10:01
https://app.circleci.com/pipelines/github/gruntwork-io/terragrunt/1250/workflows/20f2d25f-ca52-4c70-b874-a4ef658347af/jobs/8412
10:23
https://app.circleci.com/pipelines/github/gruntwork-io/terragrunt/1249/workflows/45305c4f-eeef-40d1-a132-8ac1ec5c3bad/jobs/8409


Defined new revisions for golang dep: github.com/op/go-logging

Ran component through the scanners since I noticed it had not been harvested yet and it correctly declared the license. Closing PR as it is no longer needed.


Changes to use OpenSearch 1.0.0-alpha1

Signed-off-by: Ravi Thaluru<EMAIL_ADDRESS>Issue #, if available:
Description of changes:
Changes to use OpenSearch 1.0.0-alpha1 and some minor refactor
CheckList:
[x] Commits are signed per the DCO using --signoff
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@1cfb418). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #5   +/-   ##
=======================================
  Coverage        ?   77.06%
  Complexity      ?     1552
=======================================
  Files           ?      199
  Lines           ?     8325
  Branches        ?     1323
=======================================
  Hits            ?     6416
  Misses          ?     1192
  Partials        ?      717

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1cfb418...81829cc. Read the comment docs.


Collection replace and replaceRecursively functions

I think replacing in collections is not needed by the framework,
a PR was declined on this functionality recently if i remember correctly
You should use map function instead.

No plans to add this.

@taylorotwell
Thanks for you comment. Can you please give a hint that what sort of things are planed? In the collection there are a number of  non-essential methods (e.g. median()) while the "replacing" items is such important that php has two build-in function for that. (or is there any downside for including replace)
BTW, the last year that I pushed this for the first time it seems the reaction to that was positive #15157


Feature Request: Allow filtering accounts by asset and is_authorized.

What problem does your feature solve?
Right now you can filter all accounts who have a trust line to an asset using the ?asset query parameter in /accounts. This end points return both accounts who are authorized and accounts which are not authorized.
What would you like to see?
We should have an extra query parameter to show  only authorized or unauthorized.
I think we could have a query param called is_asset_authorized which takes 1 for true or 0 for false.
The following request will return all the accounts with a trust line to the given asset pending authorization.
accounts?asset=COP:GAEDLNMCQZOSLY7Y4NW3DTEWQEVVCXYYMBDNGPPGBMQH4GFYECBI7YVK&is_asset_authorized=0
What alternatives are there?
Right now you can find all the authorized or unauthorized accounts by loading all the pages and filtering by `is_authorized.

I like this idea. I think it's more standard to have boolean query params as true|false rather than numbers though.

Github API example
Sane restful API design guidelines
StackOverflow question

Could the consistency issue here: https://github.com/stellar/go/issues/2200 be addressed as well please!

This requires an extra index and there isn't much interest in this feature. Closing for now.


Max number of days for Get-MessageTrace

Description under article states the Get-MessageTrace can search upto past 30 days results.
This is not true. Only past 10 days results can be fetched using this command line.

Docs Build status updates of commit 89c810a:
:clock10: Full build: the average full build time is 11 min(s) 54 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit 89c810a:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/mail-flow/Get-MessageTrace.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit dab7ab2:
:clock10: Full build: the average full build time is 11 min(s) 54 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit dab7ab2:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/mail-flow/Get-MessageTrace.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit bf63b6f:
:clock10: Full build: the average full build time is 11 min(s) 54 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit bf63b6f:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/mail-flow/Get-MessageTrace.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit f552ef8:
:clock10: Full build: the average full build time is 11 min(s) 54 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit f552ef8:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/mail-flow/Get-MessageTrace.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


platform dependencies lead to wrong composer version being used

Package manager/ecosystem
composer
Manifest contents prior to update
n/a
Updated dependency
n/a
What you expected to see, versus what you actually saw
correct composer version is used
Images of the diff or a link to the PR, issue or logs
n/a
Composer supports requiring platform packages to verify the state of the system during install.
As per the example
{
    "require" : {
        "php" : ">=7.4",
        "ext-mbstring": "*",
        "lib-libxml": "*"
    }
}

is valid.
Dependabot.Composer.Helpers.invalid_v2_requirement checks all package names against the regex for valid composer v2 package names or if the name is php.
Any required platform packages will cause dependabot to default to composer v1.

I've implemented a fix in https://github.com/kasn/dependabot-core/commit/c233e52ae0555529d83f1312261263ddc7d8e7ee but my ruby/rspec experience is to limited to write meaningful tests. If anyone could point me into the right direction I would appreciate it.

I've implemented a fix in https://github.com/kasn/dependabot-core/commit/c233e52ae0555529d83f1312261263ddc7d8e7ee but my ruby/rspec experience is to limited to write meaningful tests. If anyone could point me into the right direction I would appreciate it.

fixed with https://github.com/dependabot/dependabot-core/pull/3004

fixed with https://github.com/dependabot/dependabot-core/pull/3004


Update core-data.yaml

GET operations cannot have a requestBody.
found this error,when I import core-data.yaml to https://editor.swagger.io/

please open an issue to write down the problem before opening the PR
for the PR, the commit message need to comply with the community standard
https://wiki.edgexfoundry.org/display/FA/Committing+Code+Guidelines#CommittingCodeGuidelines-CommitMessages
also, for this PR, we do implement the GET API with the payload.  it is workable technically.


201704 init venv check fix

Addressing a couple things as per this issue.

Made get_current_venv a static method so that init doesn't need to create a temp Zappa instance just to call that
Added a profile detection bit in init

Coverage increased (+0.2%) to 79.17% when pulling a86ed31d09903cc9c0273e03350782ede31b6d25 on pdpol:201704_init_venv_check_fix into 89ea028ec3bce35543cc98415448677d85f50507 on Miserlou:master.

Hey @pdpol - thanks submitting this!
The changes look good, but I'd prefer it if the behavior will only emerge if there are multiple profiles or no profile at all. It is unnecessary to ask if the choice of default is okay:
AWS Lambda and API Gateway are only available in certain regions. Let's check to make sure you have a profile set up in one that will work.

We only found one profile: default. Is this okay? (default 'y') [y/n]: y

Also, please format the text so that there is no extra linebreak, so that each "section" of init corresponds to a different field of the generated config.
Thank you for participating in this fun media project!

@Miserlou Cool, PR updated with changes.

Coverage increased (+1.0%) to 79.152% when pulling 98b5c027c715629aa603fd46f97ec0a60c866dd7 on pdpol:201704_init_venv_check_fix into 7e157b9de5772a70ad34af78ffb82e70e46b1137 on Miserlou:master.

Coverage increased (+1.0%) to 79.152% when pulling 98b5c027c715629aa603fd46f97ec0a60c866dd7 on pdpol:201704_init_venv_check_fix into 7e157b9de5772a70ad34af78ffb82e70e46b1137 on Miserlou:master.

Coverage increased (+1.0%) to 79.152% when pulling 98b5c027c715629aa603fd46f97ec0a60c866dd7 on pdpol:201704_init_venv_check_fix into 7e157b9de5772a70ad34af78ffb82e70e46b1137 on Miserlou:master.

Coverage increased (+1.0%) to 79.152% when pulling 98b5c027c715629aa603fd46f97ec0a60c866dd7 on pdpol:201704_init_venv_check_fix into 7e157b9de5772a70ad34af78ffb82e70e46b1137 on Miserlou:master.

Coverage increased (+1.0%) to 79.152% when pulling 98b5c027c715629aa603fd46f97ec0a60c866dd7 on pdpol:201704_init_venv_check_fix into 7e157b9de5772a70ad34af78ffb82e70e46b1137 on Miserlou:master.

Coverage increased (+1.0%) to 79.152% when pulling 98b5c027c715629aa603fd46f97ec0a60c866dd7 on pdpol:201704_init_venv_check_fix into 7e157b9de5772a70ad34af78ffb82e70e46b1137 on Miserlou:master.