Announcement Announcement Module
Collapse
No announcement yet.
Retrieving Beans from Spring Containter which are not defined explicitely Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Retrieving Beans from Spring Containter which are not defined explicitely

    Hi,

    I want to try to load some serive classes via the Spring container but I don't
    want to create a bean definition for evey domain class.
    Therefore I want to realize the following with Spring:

    Use something like a PatternBeanFactory which is able to output beans by
    defining a pattern for classes in the classpath. The factory creates a bean
    automatically for every matching class and names it say with the class name.

    I found this but I think this inly works for beans already defined with <bean...

    http://static.springframework.org/sp...#aop-autoproxy

    Does anyone know whether something like this already exists?

    thanks

  • constv
    replied
    Actually, I can see one possible rationale behind what he is trying to do. Imagine, you have a DAO that reads a generic result set and then needs to construct an instance of a particular domain object based on the value in the particular column. Such cases are rare, but sometimes it is a good solution if your domain model must support some very generic database schema. Who knows, perhaps the domain objects share the same set of properties, and then differ by a collection of attributes (name value pairs that are stored as strings in the database but completely different for different types of objects; I have seen this before.) And, perhaps, each such domain object actually provides a strongly-typed getter for each underlying attribute. This means, you have very different domain objects with very different getters, but those domain objects may be populated by the same DAO (resultset mapper) code - via some setAttributes(Map<String, String>) method or something like that. In such case, your result set mapper could, for example, implement the BeanFactoryAware interface, derive the correct bean ID from the column that identifies which type of entity is retrieved in this particular RS row, and query the app context for a new instance of the domain bean that corresponds to that entity. The bean's scope would have to be defined as "prototype", not singleton, obviously. But if you have tons of such domain bean definitions in your Spring context, things could get hairy. Like I said, such situation won't happen often, but never say never...

    Leave a comment:


  • lumpynose
    replied
    The spring beans you define with xml are the logic and code of your application. They are normally singleton since the logic and code doesn't change. The domain objects are the data and state; your code, or the database, etc. creates them and stuffs them with data and passes them around. So, as Marten points out, it doesn't make sense to have spring manage them since it's your code that should be creating and managing them.

    Leave a comment:


  • Marten Deinum
    replied
    Why would you even want to define your domain classes? Normally only your services and dao's. If you don't want bother creating an xml you might want to look into the @Service and @Repository annotations.

    Leave a comment:

Working...
X