Hi, in the following block of example code, I'm able to get the bean id "studentslist" loaded from the config.xml file. The nice thing here is the list of students can be re-configured after compile time and the code can automatically load as many students as defined in config.xml.
But what if I want to normalize the config.xml a bit as shown below? The catch for me now is while I'm making the xml easier to read and less bulky, I need to know all the bean ids (studentslistMale9, studentslistFemale9, etc) before I compile the code so I can call the context.getBean method for all these bean ids. If there's a way to do this without having to know before hand how many beans and the names of these bean ids, can someone show me how?
For starters Student does not strike me as an object that should be a Spring bean. By default Spring beans are singletons (slightly different then the Singleton pattern in that the bean name is unique within a context). Typically these objects should be services or repositories which do not have state.
If you do have multiple beans of a certain type you can @Autowire them into a collection by type. You can also annotate the bean class with any of the stereotype annotations @Service, @Repository, @Component etc. and use the component scanning facility to pick them up and create the bean. This makes your XML files much less verbose. Students seem like they belong in some sort of a database, whether that me in memory or otherwise. That information can then be queried and your collections can be populated in whatever fashion makes sense to your application.
Hi, I searched online for @component and can't find anything suitable for my needs, which is to permit configuring the list of Students by someone else after compiling the code without use of dB. Can you show me some examples of this component scanning feature in this specific case, maintaining the variable list of students in XML? Thanks.
Okay the more I read into this the more I think @Service, @Repository, @Component aren't suitable. The auto scan feature appears to enable the Spring framework to load all the Java Classes annotated with the @Component annotation simply providing the following single line.
<context:component-scan base-package="package names where the Java Classes are" />
This actually implies I need to create all the students in my Java code (hard coding to me) or in a dB as you suggested but not something I'd like to use as I don't want to have an extra dependency.
If all I want is a structure way of providing a means for someone to configure the list of students, is the first two block of codes I posted in the original post the only way to do this with Spring?
If you want to pre-configure java objects in XML then yes, what you were doing is how you would do it. However...
Let me re-iterate what you are doing is going to be problematic
1. How are you going to handle 100,000 students? Configure each one in XML?
2. If you change these at run-time each time you start the application it will default right back to what is hard coded.
3. All of these objects are singletons so they will be loaded at application start and stay in memory for the life of the application. Once again what if you had 100,000 students?.
4. Since there is only one instance of each student if you have concurrent use of your application you are going to have multiple threads messing with the same instance of a stateful object.
The typical Spring bean is a singleton (in a certain sense of the word) as I mentioned before this means they should be stateless objects like services or repositories. In this case you typically have only one implementation of the interface and can share that one stateless instance. In this case component scanning works perfectly. What you are doing is not really how it was intended to be used. For mutable stateful objects you should really consider using a database even a light weight one.
What you are doing was more intended for creating a bean of some type of constant unchanging value. Say like a Map of immutable Color objects where the colors will always be red, green, and blue with their RGB values.
Thanks for confirming. Actually the objects being created aren't really students. I just re-labelled my code to students as I thought that's easier to understand without a lot of background information. The requirement is that this program needs to be provided to multiple teams who can then configure the objects applicable to them, thus it needs to remain in an external editable file, and once the objects are created remain to be stateful for the life of the program. And yes I think by default it'd create them as singletons. Haven't thought about that being singleton only but yes that'd be what needs to be done.