Announcement Announcement Module
Collapse
No announcement yet.
Spring for a Dynamic Extensibility Framework Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring for a Dynamic Extensibility Framework

    Hello all, I plan to utilize Spring extensively for a new project of mine and am anxious to hear your feedback on a few design/implementation issues I've come across so far.

    The project of mine is a build tool inspired by Ant and Maven. An extension/plug-in-based architecture is obviously suited for this type of application, and I have come to the thought that Spring and IoC would be perfect for the task.

    My initial thoughts on how I would like to implement the architecture are roughly as follows. I'd like individual extensions to be isolated in their own JAR files, and be implemented using Spring-managed beans. I'd also like to use Spring's AOP features for cross-cutting concerns such as logging and error handling. The thing I don't know how to do though is how to wire together contexts and beans from multiple JARs at runtime and have them all work together nicely.

    Anyway, that is my first concern I'd like to discuss. I'm sure more will come as I go along. Thanks in advance for your feedback.

  • #2
    A Generalization

    I'd like to generalize my first thoughts a little more. The architecture I'm talking about, I'll just refer to it as a plugin-oriented architecture, or POA, from now on. I think that in the last several years this type of architecture has gained substantial momentum in all types of projects, from smaller-scale, standalone tools like Ant and Maven to large-scale solutions like Eclipse. I believe it would benefit the community greatly to create an archetypal framework for POA, and I think that IoC is certainly one of the better roads to take for this.

    Now I'll admit to you all right now, I'm not a scholar and I'm not a professional. I have been self-taught in various software engineering areas for the last six years and now that I'm out of high school, I finally have the opportunity to go to school for the field. So with that said, please excuse me if some of what I say seems ignorant or not very well put together. I thrive on high-level concepts, such as the one that I'd like to discuss in this thread, and I look forward to the guidance of those here who have much more solid experience than I do. Once again, thanks in advance for your feedback and I look forward to hearing from you all.

    Comment


    • #3
      Further Discussion

      I have been looking through the entire forum, searching on 'dynamic' and I found your question most similiar to the one I want to ask. (Sorry, I do not have an answer to your specific question.)

      I too, am looking for a way to dynamically plugin features to my app. More specifically, I want to plugin functionality that has begin and end dates. That is, have specific plugin's do their part until they expire and the next version of 'rules' take over. This will allow future rules to be implemented ahead of time while having the app function appropriatly until a cut-over date.

      Our app has to change based on governmental specifics over time. I would love to somehow configure spring dynamically via a set of database tables Vs. an XML file.

      I found some discussion about this in a supposed 1.3 version of spring at the following link.

      http://developers.sun.com/learning/j...e/TS-3744.html

      But the Spring site seems to show the next version as 2.0.

      Is database configuration supported in 2.0?

      thanks in advance

      James
      @ Southwest Airlines

      Comment


      • #4
        Database Bean Factory

        Hello jlawrence, thanks for your reply. While you didn't have a direct answer to my question, you've brought something up that I've been considering for several days now, that being the notion of database-managed versus xml-managed beans. If beans were managed from a database table instead of XML files that are found per-JAR, then it would seem that it'd be fairly easy to plug new beans into that central repository of sorts. I believe that with Spring this would warrant the implementation of a database bean factory as you said. As it seems we're both rather new to Spring though, it'd be nice to hear some feedback on this from more experienced members of the Spring community. I look forward to discussing this issue further with you though.

        Comment


        • #5
          I did see ways of dynamically registering new beans to the Beanfactory in the forum.

          Many times, there is an answer to these questions, but you don't know how to ask the right question.

          What did you make of the link I included. Is there a 1.3 release?

          There is one alternative I though of, though not as elegant as a true database solution.

          Let me start off my saying that when I use Spring, I use the Service Locator pattern. That is, I have a class which returns services (instances of classes that implement defined interfaces) and hides the fact that they are coming from Spring. Until now, I have just hard-coded the name of the spring file. You could in theory, 'version' (starting with somehting like 'spring-myapp-1.0.xml') your Spring configuration files and have the name of the file stored in a db table. You deploy (or patch; make available in the classpath of the app) a new configuration file with 1.1 in the filename. Then send a message to the Service locator to recreate the context based on the updated value which you have changed in the database.

          If this was a web-app, you could upload the file to the server (to a location in the classpath), update the db, and reset the Service locator.

          Just a thought.

          James

          Comment


          • #6
            Plug-in frameworks: A Plug-in framework is a very big project. Using Spring to do it would take a lot of Spring know how. Would be great as a research project of course.

            The state of the art of this is probably OSGi; thats probably why it was used in Eclipse. OSGi is coming to Spring in the 2.1 release time, I read. Another one is: JPF an Eclipse-like pre-OSGi flavor, see: http://jpf.sourceforge.net/index.html.
            A JMX based plug-in framework is: JuMix, see: http://www.trillian.ee/jumix/index-eng.html

            I'm sure there are many more.

            Spring contexts from DB: This has been discussed on the forum. There is code out there for this, and perhaps there is something in the sandbox too.
            One problem is that you have to access the db to get the configuration. So, the db could not be part of the main configuration via Spring (or must be a bootstrap config).

            Comment


            • #7
              What about a more a more "lightweight" solution, namely simply exposing a core bean model and allowing extensions to use that?

              Comment

              Working...
              X