I have a composite condition like this:
static class OnJndiOrProperty extends AnyNestedCondition {
OnJndiOrProperty() {
super(ConfigurationPhase.PARSE_CONFIGURATION);
}
#ConditionalOnJndi()
static class OnJndi {}
#ConditionalOnProperty("something")
static class OnProperty {}
}
How do I, for example, reuse one of the nested conditions elsewhere? The following would not even compile:
#Conditional(OnJndiOrProperty.OnProperty.class)
because OnProperty is not a Condition, rather something that is interpreted as one thanks to the [package-private] OnPropertyCondition utility.
I could perhaps make it extend a custom Condition implementation and get rid of the #ConditionalOnProperty annotation, but that would effectively be the same as implementing the OnPropertyCondition, so it's just rewriting what's already supported.
Related
As we know, every entity of ElasticsearchEntityMapper requires annotation
#Document(indexName="foo")
public class Foo {...}
, so that we can use convenient methods, like:
<T> Page<T> queryForPage(SearchQuery query, Foo.class);
But it is very common, that the indices of elasticsearch were designed time-based or language-based. i.e.
#Document(indexName="2019")
public class Foo {...}
#Document(indexName="2020")
public class Foo {...}
or
#Document(indexName="english")
public class Foo {...}
#Document(indexName="german")
public class Foo {...}
Of course, we can't create classes like this, one class with different indices.
What should we do in this case? One class each index, Foo2019, Foo2020? <- Very bad idea.
I am wondering, why does spring-data-elasticsearch design entity in this way? It's not really flexible. Or I misunderstand the usage?
Thanks for your help in advance! :)
You are right in that using this with fix Strings is not flexible.
But you can also use a SpEL Expression for the index name. And when using the ElasticsearchOperations methods and not the repository methods, you can pass in the name of the index, this is overriding the name defined in the #Documentannotation.
I am having two implementations of my component.
public interface MyComponent {
}
imple1
#Component("impCompf")
#Lazy
#RequestScope
public class ImpComp1 implements MyComponent {
}
imple2
#Component("impComps")
#Lazy
#RequestScope
public class ImpComp2 implements MyComponent {
}
What I did so far is to create two conditions like so:
imple1
public class FirstCondition implements Condition {
#Override
public boolean matches(ConditionContext arg0, AnnotatedTypeMetadata arg1) {
return staticVariable.contains("impCompf");
}
}
Same goes for imple2
and define a configuration class
#Configuration
public class MyConfiguration {
#Bean
#Conditional(FirstCondition .class)
#Primary
public MyComponent getComp1() {
return new ImpComp1();
}
public static String staticVariable= "impCompf";
and in My main controller:
#RequestMapping(value="api/{co}", method=RequestMethod.POST)
public ResponseEntity<Modelx> postSe(#PathVariable("co") String co) {
if(co.contains("impCompf"))
staticVariable = "impCompf";
else (co.contains("impComps"))
staticVariable = "impComps";
What I want: for every http request I want to load proper implementation
But however what I am getting is the implementation defined first in the static variable.
If is there another elegant and better way, i'd like to know about it.
I think there is some confusion here about the purpose of the conditions. These aren't being used at the time your requests arrive to autowire the candidate bean into your controller. These are being used when the application is started to configure the application context based on the environment and classpath etc...
There is no need for the conditional classes that you have created. This is defining the configuration of the beans when the context starts and not on a per request basis at runtime.
The use of the static variable is also problematic is a scenario with one or more concurrent requests or in a case where multiple threads may observe different values unless some other mechanism in the java memory model is being used (such as volatile or establishing a happens before relationship, e.g. with sychnronized)
There are a number of ways to do what you appear to be trying to achieve. Since ultimately, you appear to be using a path parameter supplied by a client to determine which service you want to invoke you could use a classic factory pattern to return the correct interface implementation based on the string input programmatically.
Alternatively you could create two distinct controller methods which are distinguished by a query parameter or endpoint name or path match etc. You could then have the appropriate service injected by a qualified bean name
Although perhaps generally recommended, you could also inject an application context instance and search the it looking for the relevant bean by name or class: https://brunozambiazi.wordpress.com/2016/01/16/getting-spring-beans-programmatically/ - although This is more cumbersome and you'd need to handle things like org.springframework.beans.factory.NoSuchBeanDefinitionException or casting in some cases - best avoided in favour of one of the other methods.
I need a flexible filters for FooEvents for multiple EventListeners all over my code.
I can use #EventListener(condition="event.enabled"), but my filters require many attributes of fooEvent to be analysed.
I was hoping that I could use a Predicate-Bean from my Application Context:
#Component
public class FooPredicate implements Predicate<FooEvent> {
public boolean test(FooEvent event) {...}
}
...
#EventListener(condition="${fooPredicate.test(event)}")
public void handle(FooEvent event) { ... }
But I get:
org.springframework.expression.spel.SpelEvaluationException: EL1011E:
Method call: Attempted to call method
test(org.springframework.context.PayloadApplicationEvent) on null
context object
Is it possible to use external, complex conditions for EventListerns? Or at least to define global listeners with complex conditions and inherit their behavior without repeating the full conditions?
You're using the wrong definition, as fooPredicate is a spring bean you need to use '#' instead of '#' to resolve it as a bean. see 10.5.13 Bean references
#EventListener(condition="#fooPredicate.test(#event)")
public void handle(FooEvent event) {
System.out.println();
}
I was playing with the following question: Using Java 8's Optional with Stream::flatMap and wanted to add a method to a custom Optional<T> and then check if it worked.
More precise, I wanted to add a stream() to my CustomOptional<T> that returns an empty stream if no value is present, or a stream with a single element if it is present.
However, I came to the conclusion that Optional<T> is declared as final.
Why is this so? There are loads of classes that are not declared as final, and I personally do not see a reason here to declare Optional<T> final.
As a second question, why can not all methods be final, if the worry is that they would be overridden, and leave the class non-final?
According to this page of the Java SE 8 API docs, Optional<T> is a value based class. According to this page of the API docs, value-based classes have to be immutable.
Declaring all the methods in Optional<T> as final will prevent the methods from being overridden, but that will not prevent an extending class from adding fields and methods. Extending the class and adding a field together with a method that changes the value of that field would make that subclass mutable and hence would allow the creation of a mutable Optional<T>. The following is an example of such a subclass that could be created if Optional<T> would not be declared final.
//Example created by #assylias
public class Sub<T> extends Optional<T> {
private T t;
public void set(T t) {
this.t = t;
}
}
Declaring Optional<T> final prevents the creation of subclasses like the one above and hence guarantees Optional<T> to be always immutable.
As others have stated Optional is a value based class and since it is a value based class it should be immutable which needs it to be final.
But we missed the point for this. One of the main reason why value based classes are immutable is to guarantee thread safety. Making it immutable makes it thread safe. Take for eg String or primitive wrappers like Integer or Float. They are declared final for similar reasons.
Probably, the reason is the same as why String is final; that is, so that all users of the Optional class can be assured that the methods on the instance they receive keep to their contract of always returning the same value.
Though we could not extend the Optional class, we could create our own wrapper class.
public final class Opt {
private Opt() {
}
public static final <T> Stream<T> filledOrEmpty(T t) {
return Optional.ofNullable(t).isPresent() ? Stream.of(t) : Stream.empty();
}
}
Hope it might helps you. Glad to see the reaction!
As Bloch states in Item 3 ("Enforce the singleton property with a private constructor or an enum type") of Effective Java 2nd Edition, a single-element enum type is the best way to implement a singleton. Unfortunately the old private constructor pattern is still very widespread and entrenched, to the point that many developers don't understand what I'm doing when I create enum singletons.
A simple // Enum Singleton comment above the class declaration helps, but it still leaves open the possibility that another programmer could come along later and add a second constant to the enum, breaking the singleton property. For all the problems that the private constructor approach has, in my opinion it is somewhat more self-documenting than an enum singleton.
I think what I need is an annotation which both states that the enum type is a singleton and ensures at compile-time that only one constant is ever added to the enum. Something like this:
#EnumSingleton // Annotation complains if > 1 enum element on EnumSingleton
public enum EnumSingleton {
INSTANCE;
}
Has anyone run across such an annotation for standard Java in public libraries anywhere? Or is what I'm asking for impossible under Java's current annotation system?
UPDATE
One workaround I'm using, at least until I decide to actually bother with rolling my own annotations, is to put #SuppressWarnings("UnusedDeclaration") directly in front of the INSTANCE field. It does a decent job of making the code look distinct from a straightforward enum type.
You can use something like this -
public class SingletonClass {
private SingletonClass() {
// block external instantiation
}
public static enum SingletonFactory {
INSTANCE {
public SingletonClass getInstance() {
return instance;
}
};
private static SingletonClass instance = new SingletonClass();
private SingletonFactory() {
}
public abstract SingletonClass getInstance();
}
}
And you can access in some other class as -
SingletonClass.SingletonFactory.INSTANCE.getInstance();
I'm not aware of such an annotation in public java libraries, but you can define yourself such a compile time annotation to be used for your projects. Of course, you need to write an annotation processor for it and invoke somehow APT (with ant or maven) to check your #EnumSingleton annoted enums at compile time for the intended structure.
Here is a resource on how to write and use compile time annotations.