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.
Anyways I hope that helps you.