Announcement Announcement Module
No announcement yet.
Different type of collection injection Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Different type of collection injection

    I have a class that looks like

    public interface AttributeList {
      void addAttribute(Attribute a, boolean isSignificant);
      Attribute getAttribute(int index);
      int getAttributesCount();
      boolean isAttributeSignificant(int index);
    which I want to wire together using spring. Is there any way to do this? If not, it means I will have to re-write my interfaces in order to fit into the container.

  • #2
    Take a look at the sample app provided with Spring - the framework is non-intrusive which means you don't have to modify your application to accomodate Spring. The cleaner your code is in regards to testing and OOP the better - Spring helps you decouple the relations between your components.

    You can wire your classes that implement that interface w/o a problem (you can wire pure classes for that matter). Check the reference documentation - it will answer a lot of questions.


    • #3
      I am already a minor spring user. I have written 10 or so app context files, and used them in junit tests. I have the Pro Spring book. I haven't seen any way to easily wire together "non-bean" classes. If you could give me the right word to google on, or the right word to look in the index of the book, or the right word to look for in the spring dtd, or whatever, I'm willing to do the footwork, but I haven't been able to find what I'm looking for, and I don't know what real starting point there is. Telling me to "Check the reference documentation" just isn't helping me at all.


      • #4
        What are you trying to achieve, by that I mean what is the concrete use case you want to accomplish with Spring.



        • #5
          For this particular need, I would like to use spring as my configuration layer to provide all properties/wiring for my objects. I could write my own xml with my own xml assembler to populate my objects, but since I'm already using spring, I'd like to use it for all "bean" assembly. Except not all my objects look like beans. So, I'm hoping to find some way to assemble/configure those non-beans without having to write any new java code. It seems strange that I'm not getting this across. Imagine this simplified example where I'm using an existing "non-bean", but want spring to provide the configuration for it

          public interface NonBeanUser {
            String getFirstName();
            String getLastName();
            void setName(String first, String last);
          Spring would love to do this if it was a pure bean interface, but since it isn't suddenly I'm totally out of luck?? That's the essence of what I'm getting at...


          • #6
            Vjave I undestand better your problem now. AFAIK you cannot inject your dependencies on setters by specifing them individually (like in case of the constructor) - I tried a few examples but it didn't quite work - the documentation and the DTD require that you pass an object or a container with several objects(like map, properties, lists).
            I guess you can request this as an improvement on JIRA.


            • #7
              Perhaps a custom property editor can help.


              • #8
                I have been in a number of situations similar to vjave's. The essence of the problem (mine at least) is when you are too much of an encapsulation freak :-) to expose an API like:
                setItems(List itemList);
                and instead only have something like:
                addItem(Item item);
                How do you inject into this class in a Spring context?

                So far the only workaround I can think of is to have a holder bean that holds the collection, then the same holder bean would implement the post processor interface so that it gets a chance to call the real bean's addItem() in a loop.

                It would be neat for the <list> element (and its cousins) to support an "incremental" way of injecting collection elements.



                • #9
                  What a coincidence. During an analysis it may be that I too have a requirement to wire-up an object that only exposes an addRole(x) method.

                  Off the top of my head an approach could be, using a similar approach used by many scripting languages like Python and Perl:

                  <apply  method="addRole">
                        <value><bean local="RoleA"/></value>
                  Something like that.

                  J. Betancourt