Announcement Announcement Module
No announcement yet.
Dependency Injection and Threads Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dependency Injection and Threads

    I've got an application that listens on a port, and when a new connection is made, it instantiates a new custom java class that handles the connection and passes the new connection to that class. Once created, I spin that class off on it's own thread to process the conversation with the client.

    I'd like to use dependency injection, however, I'm passing the new connection as a constructor argument of the new class before spinning the class off on it's own thread. I'm not sure if I can do this with spring. Here's what it looks like, pre-spring:

                Socket clientSocket = null;
                try {
                    clientSocket = serverSocket.accept();
                    Thread clientThread = new Thread(new SocketConnectionHandler(clientSocket));
                } catch (IOException ioe) {  }
    So "SocketConnectionHandler" is the custom class I've written to handle the communication between the server and this one connection. Theoretically, I'd like to be able to have different classes that handle the communication in different ways. However, I only get the client socket at run-time, so I can't put it as a "ref" tag in Spring, and even if I could, I don't know if I can pass it to the construction of the new handler.

    Any suggestions?

  • #2
    Maybe you could use an approach I suggested here. It would allow the combination of a Spring defined bean with providing runtime parameters.

    Hope that helps,


    • #3
      Do you have an example of it's usage?


      • #4

        Attached are the sources of a minimalistic example. Though it does not do much, you should see how to use it as the concept is not difficult.

        A more sophisticated example is the SFSB support, already included in the attached to the Jira report.

        Note that the package names (of the files attached to Jira) are just suggestions from me and might not be final (if the extension is to be approved at all, that is).

        Hope that helps,