Tapio Niemela

Help please with understanding Spring boot 3 bean overriding. To my understanding Spring boot creates some beans OOTB and then uses them in their own "Services".
If I create my own bean with same type as OOTB Spring bean (to be used only for my custom service), can it "accidentially" be used in place of OOTB beans (for Spring ootb "Services")?
How I've understood is that if the type and name of the bean matches it will override OOTB bean, but that doesn't seem to be the case always..

I made some testing and declared my own DataSource @Bean (actually just returned null from the method) within my @Configuration with custom name, @Qualifier and even lowest Order and I get exception at startup that Datasource should not be null by the Spring OOTB classes (I even attempted to use spring.main.allow-bean-definition-overriding=false). So clearly OOTB classes are using my custom bean

After that I made endpoint to list all beans from the ApplicationContext AND the list contained both the OOTB LocaleResolver AND the custom LocaleResolver I created (as Bean with custom name). So it seems that in that case 2 beans of same type can co-exist

Thanks!

Hi folks,

As you probably know, Spring JDBC is an attempt to create framework which would 'force' the user to comply to DDD tactical patterns

Now, I'm very puzzled why Spring JDBC (https://docs.spring.io/spring-data/jdbc/docs/current/reference/html/) recommends using immutable objects as entities.
"Try to stick to immutable objects — Immutable objects are straightforward to create as materializing an object is then a matter of calling its constructor only. Also, this avoids your domain objects to be littered with setter methods that allow client code to manipulate the objects state."

Yes, I agree, setters must be avoided, BUT this suggestion seems to go into direction where entities are just data holders and thus advocate anemic domain model (which is totally against DDD) (for Value Objects java 14 records are fine)

Am I misinterpating this? If not, have you had any success complying to this suggestion? Any good resources on this?

Campbell Ritchie wrote:That isn't a use case. If you want help, we shall want to know what you want to do, and we can't work that out from code.

Sorry, I cannot give you exact details from my project or even the actual use case. Vaguely speaking my "use case" is that I'm given a list of things from which I have to deduct list of things I need to "invert". Those "inverted" things are consumed somewhere else. What I was trying to achieve with generics here was to force the compiler to make sure "invert" method returns same instance of the class of instance which accepted the method (so BooleanInvertable invert method  doesn't return StringInvertable). Thanks anyway

Stephan van Hulst wrote:Maybe if you explain your actual use-case, then we can suggest something for you.

Well, I figured out that I don't actually need the type information from Invertable things
So it is basically something like this
   public void execute(List<Thing> things){        List<Invertable<?>> invertables = calculateFrom(things);        for(Invertable<?> invertable : invertables){            Invertable<?> inverted = invertable.invert();            processInverted(inverted);        }    }    List<Invertable<?>> calculateFrom(List<Thing> getInvertableThings){        //return things mapped to Invertables using collaborator 'calculator'..        return null;    }        void processInverted(Invertable<?> invertable){        //processed somewhere else    }

Thank you still  

Stephan van Hulst wrote:I'm with Campbell. It looks like you've grokked why casting in the world of generics is usually a bad idea, but your latest bit of code is probably still not the best solution to whatever it is that you want to achieve.

Yes, thank you, I think I finally got it. And thank you for the code, it seems clean. My actual motivation is bit more complex than the simplified example I've provided. What I wanted in the first place is just to have interface where I could use recursive type bounds to force the compiler to check that the "invert" method returns instance of same type as the actual class implementing the interface. But I guess I'll anyhow drop that idea as it causes more confusion

So, the final solution to my problem would be actually something like this
public class MyTest {    public static void main(String...args){        MyTest test = new MyTest();        test.invert(BooleanInvertable.class);    }    public <T extends Invertable<T>> void invert(Class<T> type){        List<T> invertables = getInvertables(type);        for(T t : invertables){            System.out.println(t.invert());        }    }    private <T extends Invertable<T>> List<T> getInvertables(Class<T> type){        List<T> list = new ArrayList<>();        if(type == BooleanInvertable.class){            list.add( type.cast(new BooleanInvertable(true)) );            list.add( type.cast(new BooleanInvertable(false)) );        }        else if(type == StringInvertable.class){            list.add( type.cast(new StringInvertable("hello")) );            list.add( type.cast(new StringInvertable("world")) );        }        return list;    } } interface Invertable<T extends Invertable<T>>{    T invert(); } class BooleanInvertable implements Invertable<BooleanInvertable>{    private final boolean value;    public BooleanInvertable(boolean value) {        this.value = value;    }    public BooleanInvertable invert(){        return new BooleanInvertable(!value);    } } class StringInvertable implements Invertable<StringInvertable>{    private final String value;    public StringInvertable(String value) {        this.value = value;    }    public StringInvertable invert(){        return new StringInvertable(new StringBuilder(value).reverse().toString());    } }

Thanks for replies, sure I have to read more about java generics. However, with my simple example (giveMeNumber) I was trying to tell that I figured out the "problem I had about why I 'need' explicit cast (Integer is subtype of Number after all)". The problem manifastes (with such example) if it is "misused" by the client (expecting giveMeNumber to return Long). Of course, such method should not exist in the first place, to be "misused" by the client. Somehow I didn't realize earlier on that I can assign the return value directly to ANY subclass of Number (not just into Number). (as you said "I am also a bit surprised that you got your line 3 to compile")

Also, I'm grateful for examples you are giving here, it helps me to figure out the "missing pieces"  

My original issue could be fixed with figuring out the actual implementing class of my interface, passing that type parameter to all methods involved and then finally casting my interface implementation instances to the correct instance. (Actually, my original issue wasn't about combining lists, just generating list of objects of single type of interface)

So, thanks again for help, my text is quite confusing, but my "issue" is resolved

I finally figured it out

   void test() {        Number z = giveMeNumber();//OK!        Long x = giveMeNumber();//CRASH at runtime!    }    <T extends Number> T giveMeNumber(){        return (T)Integer.valueOf(1);    }

Tapio Niemela wrote:True, I didn't remember that fact

However, the thing is that in the project I'm working on, I actually want that List of interfaces, not implementations

True, I didn't remember that fact

However, the thing is that in the project I'm working on, I actually want that List of interfaces, not implementations

Stephand and Campbell, thank you for replies

I still cannot understand why I cannot do this

<T extends MyThing<T>> T thing(){  T t  =new MyConcreteThing(); //implemetns MyThing  return t; }

Thanks for the reply, but that's not exatcly I was searching for. I have rather complicated case which I oversimplified with my example

My problem is that I have interface (oversimplified again! but the thing to notice is that it uses recursive bounded generics to make the compiler force that toggleSwith always returns correct type)
public interface Mything<T extends Mything<T>> {    T toggleSwitch(); }

And I'm producing instances of actual implementations of such interfaces, actually multiple implementations

So I have
public class MyThingCalculator<T extends Mything<T>> {    private MyConcreteThingProducer myConcreteThingProducer;    private MyOtherConcreteThingProducer myOtherConcreteThingProducer;    List<T> calculate(){        List<MyConcreteThing> concreteThings = myConcreteThingProducer.produce();        List<MyOtherConcreteThing> moreStuff = myOtherConcreteThingProducer.produce();        List<T> returnList = new ArrayList<>();        returnList.addAll(concreteThings);//wont'compile, needs (List<T> cast)        returnList.addAll(moreStuff);//wont'compile, needs (List<T> cast)        return returnList;    } }

So if MyConcreteThingProducer returns List of actual implementations I need to cast it to List<T>

I'm also bit surprised that I cannot cast MyConcreteThing to <T extends Mything<T>> (MyConcreteThing implements it!) without warning

Any help appreciated

Hello ranchers

I have trouble understanding generics properly

public class NumberCalc {    public static <T extends Number> List<T> calc(){        List<T> numbers = new ArrayList<>();        numbers.addAll((List<T>)ints());        numbers.addAll((List<T>)longs()); //numbers.addAll((List<T>)strings()); //uh        return numbers;    }    private static List<Long> longs(){        return List.of(1L);    }            private static List<Integer> ints(){        return List.of(1);    }    private static List<String> strings(){        return List.of("a");    }     }

Why do I need to make explicit cast to List<T> ? And why I cannot "force" the compiler to cast List<String> to List of T?

Thanks in advance!

hello,

I've been struggling configuring spring security for too many hours. What I'm trying to accomplish is that authentication process could be toggled on/off at runtime. My idea was that I could extend FilterSecurityInterceptor and override it's doFilter-method to check whether authentication is "enabled"..(yes I know security shouldn't probably be toggled on/off at runtime..)

However, I'm in trouble figuring out how security namespace and "traditional" bean configurations mix..Or do they mix at all?

I've tried to provide bean with id 'filterSecurityInterceptor'. As far as I'm concerned this is the way it should be, right? I mean that those security namespace auto-created beans should/could be overriden in spring.xml with specific id, sort of callback...Or are I'm lost here? Anyhow if that's not the case, I can give custom-filter in position 'FilterSecurityInterceptor' to http-element. But that doesn't seem to work either...filterSecurityInterceptor requires something called 'securityMetadataSource' which in turns seems to be related to sec:http-element / intercept-url -mapping..However, If I don't use security namespace config, do I really need to make all bean definitions by hand? That doesn't sound right either..

<sec:http pattern="/login" security="none"/> <sec:http auto-config="true"> <sec:intercept-url pattern="/**" access="ROLE_USER" /> <sec:form-login /> </sec:http> <sec:authentication-manager alias="authenticationManager"> <sec:authentication-provider ref='secondLdapProvider' /> </sec:authentication-manager> <bean id="accessDecisionManager" class="org.springframework.security.access.vote.AffirmativeBased"> <property name="decisionVoters"> <list> <bean class="org.springframework.security.access.vote.RoleVoter" /> </list> </property> </bean> <bean id="filterSecurityInterceptor" class="com.acme.MyInterceptor"> <property name="observeOncePerRequest" value="true"/> <property name="authenticationManager" ref="authenticationManager" /> <property name="accessDecisionManager" ref="accessDecisionManager" /> </bean>

big thanks in advance for all replies

Hi, I've recently been pondering about the YAGNI principle. Basically it warns about over-engineering and premature over-optimization. I agree somewhat to that principle, but at my current project I'm working with legacy code which could have benefited of *some premature* design. Now code-base is filled with classes with static methods. Methods which iterate through similar-like structures and apply some invocation (like calculate something) to applicable objects in the structure. Sounds bit like visitor or functional programming (or it's counterpart implemented in java), especially predicates, or what do you think?

The problem is that the code-base should have been implemented differently in the first place (maybe using visitor or FP). Now when I have to make changes I have two options:
- apply same methodology as used previously. E.g. everything is static something();. (Need I say more..)
- try to apply *some* design within the change. The problem is that it should have already been made; it's like post-over-engineering the implementation, also concern is it "necessary" or "(re)-usable". Code changes where I have taken this road have probably become more complicated.

Especially I think that acyclic visitor "hooks" could have been put into important classes. Some say it will complicate the code. Maybe, but then it would exist, thus enabling adding functionality afterwards

So, in my opinion, YAGNI doesn't always apply. Sometimes it might be better to design the code before jumping to the coding activity. But this should take place in the first phases of the project, not in late phases. Big question remains : WHEN are you actually gonna need it, or not?