Announcement Announcement Module
Collapse
No announcement yet.
Developing API w/Spring and Hibernate - how to package? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Developing API w/Spring and Hibernate - how to package?

    We're currently developing a custom API which we're going to be using not only internally, but distributing to customers as well. The API is being build using Spring and Hibernate.

    We're trying to figure out how we should go about packaging this product so that it will:

    1) require as little configuration as possible
    2) be as non-invasive as possible
    3) be as self contained (inside of a one JAR) as possible

    So, a few questions:

    Considering we have the following setup for Hibernate:

    Code:
    <bean id="sessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
      <property name="dataSource"><ref bean="dataSource"/></property>
      <property name="mappingResources">
        <list>
          <value>foo/bar/Baz.hbm.xml</value>
        </list>
      </property>
      ... more Hibernate set up ...
    </bean>
    Notice the dataSource property...some user's of the API might already have a suitable DataSource defined in a Spring context - if so, great - our app can use it. But how do we handle this if they're not already using Spring for the rest of their app, and they don't want to start using it just to use our API? Is there another way to set this DataSource?

    Also, what if the user's system is already using Hibernate? We'd like to ship a dataAccessContext.xml file which does all of our Hibernate configuration inside of our JAR file...but what happens when the user is already using Hibernate (maybe with Spring, maybe without) in their project?

    I think what this really comes down to is: How do we integrate our Spring context definitions with another user's - or for that matter, how do we package our API so that, regardless of the combination of Spring/Hibernate the end user has, our package can drop in gracefully and with minimum inpact?

    Any experience or advice would be greatly appreciated!

    Jon

  • #2
    I have no such experience, but just an idea:
    You can build an administration client (Swing it may be) to let the user select his own applicationContext.xml file if he is already using Spring, and his datasource definitions if he is already using Hibernate...

    Then with this info, you can build your Spring definitions (by using JDOM or another framework to modify the xml files).

    HTH,
    Turgay Zengin

    Comment


    • #3
      Would this work?

      <property name="dataSource"><ref bean="${deployedDatasource}"/></property>

      The user just edits an external property file where the variable above is predefined to get the spring stuff or if they don't use Spring the property points to a non-Spring adaptor class (which they or you supply).



      --- Josef Betancourt

      Comment


      • #4
        turgayz -
        Thanks for the idea of creating the Swing client to manage the context definitions. However, I don't believe we're going to go down that road because: 1) that'd be a lot more software for us to maintain, and 2) clients would still need edit the context files - even if not by hand.

        Josef -
        Your idea has me interested - could you explain a bit more how you see it working?

        Comment


        • #5
          Another question is:

          - Who is gonna use your API?

          It looks like that you try to cook something by placing a fish and a piece of meat in the same bowl. You have to decide. Letting the user of the API (would be a developer right?) have to understand the set up or not.

          So I guess the users of your API will have to consider diffrent setups. Trying to hide the configuration is almost a source for bugging the support team and also spread frustration all over.

          I think what this really comes down to is: How do we integrate our Spring context definitions with another user's - or for that matter, how do we package our API so that, regardless of the combination of Spring/Hibernate the end user has, our package can drop in gracefully and with minimum inpact?
          I have to admit, I don't fully understand your intension. Mostly it is nice to see such kind of setup-decission as optional rather then to force it. It seams that you need some additional ways to configure your API. Think about the way Hibernate does it (guess you are familar with it). You may go for properties, compose it or with the help of the Spring API, you may use a Spring bean factory/definition.

          I guess to minimize the impact, just let the requirements drive you. Try to build a sample demonstrating the normal usage of your API (I guess you already have) and try to configure the sample with and also without Spring. Check how it does feel. Put out a beta release (or alpha) and check how the people react.

          Also you have to aware of diffrent hibernate versions, since Hibernate 3 will be incompatible for example.

          Try it out, play with it, ask the people. Spring is a funny thing, it may mimic most of the ways things are configured by using a bean factory. So try to simplify the configuration without using Spring and provide a bean-factory as an adapter of this configuration process. I guess this is how most stuff starts.

          Spring makes things easy, but the things usally has to exist before the Spring fun can start.

          Comment


          • #6
            Jon:

            In our app we already have a MessageSource class, but Spring has one too. I had to create a message source adaptor to go from one to the other. Yea, ugly, but reality bites.

            So, this could be made configurable in the bean files by using the property pull or push factorybeans in Spring to get the deployed configuration from a properties file. That is, use the adaptor or not.

            Another option is to just have more config beans files, the startup class pulls in the correct one.

            btw, what is the term for the 'beans' definition files?


            --- Josef

            Comment


            • #7
              Martin -

              Originally posted by Martin Kersten
              - Who is gonna use your API?
              Unfortunately, it's tough to say. To begin, we'll be using it internally, so we can follow your advice and develop it to conform to our current environment on an as needed basis. Later on, it will be sold commercially - who will use it is anyone's guess - all we can assume is that the users will be relatively experienced Java developers.

              Originally posted by Martin Kersten
              Trying to hide the configuration is almost a source for bugging the support team and also spread frustration all over....I guess to minimize the impact, just let the requirements drive you.
              I completely agree with this - we don't want to cause any confusion on the user's part by attempting to make the usage/configuration of this API "overly convinient".

              At this point, we are early in the planning process - and I think we know little enough about how to package an API like this for use with other systems that we still have a lot to learn before we can make the best decision. I also agree with you when you say we're just going to have to start doing some development and see where it takes us.

              Although Spring is so easy to use, I suppose it still has its nuances. For instance, the issue we're having: releasing an API, one that is built on top of Spring, poses a lot of questions - many that I'm not aware have been addressed yet by the Spring community: how do we package configuration files, how do we work with the user's current environment, regardless of what it is, etc.?

              Spring brings a lot of flexibility, but also imposes a large responsibility to make sure you do things right.

              I'd be interested to hear more from some of the seasoned Spring developers - how would you guys go about packaging an (database) API that is Spring-dependant?

              Comment


              • #8
                the *best* solution

                Ok I am in the exact same situation.

                Here is my solution

                Use the java Preferences API ....

                I have written this small tool to config it from command line or as ant task.

                https://jestate.dev.java.net/source/...viewcvs-markup

                Here is ant build file ( this will not work inside IDE due to i/o issues
                but will work from any command line )

                https://jestate.dev.java.net/source/...viewcvs-markup

                Here is my spring config file,

                https://jestate.dev.java.net/source/...viewcvs-markup

                I use the org.springframework.beans.factory.config.Preferenc esPlaceholderConfigurer
                to load the values from the registry ....

                Now what would be really fscking cool would be if spring supported
                conditional processing like ANT in order to pull in optional config
                files.

                It doesn't and when I suggested it, I was met by a stony silence ....

                Whoops ... my bad , apparently it took httpinvoker an age to
                get included as well .....


                All the best

                Bryan

                Comment


                • #9
                  Re: the *best* solution

                  Bryan,

                  Your approach looks sound, but I've got a few questions. If someone integrates our API (and the programs you provided) into their fat client that they distribute to users, would that mean that every user would have to perform this setup?

                  Although the above would work, the complexity is something I want to avoid. Not only do I want to make it as painless as possible for users to integrate with our API, I also want to make it as painless as possible for us to design/develop/support it. In otherwords, the less invasive, the better.

                  Thanks for your suggestions, Bryan. Any others?

                  Comment


                  • #10
                    Re: the *best* solution

                    Originally posted by Jon Chase
                    Bryan,

                    Your approach looks sound, but I've got a few questions. If someone integrates our API (and the programs you provided) into their fat client that they distribute to users, would that mean that every user would have to perform this setup?

                    Although the above would work, the complexity is something I want to avoid. Not only do I want to make it as painless as possible for users to integrate with our API, I also want to make it as painless as possible for us to design/develop/support it. In otherwords, the less invasive, the better.

                    Thanks for your suggestions, Bryan. Any others?
                    The thing about it Jon is that it (Java prefs API) uses the windows registry or platform specific storage on linux/Mac etc.

                    Getting and setting values is as simple as

                    prefs.put(key, value);

                    and retrieving them is as simple as

                    prefs.get(key, "")); //the empty string is the default used if value isn't found.

                    I have a fancy little program for manipulating these values but you
                    can do it any way you want.

                    I just made the command line version because I see people as predominantly going to use it on linux and command line config
                    programs are the fashion over there.

                    It would be simple to just create a gui version.

                    --b




                    specific alter

                    Comment


                    • #11
                      bryanhunt:

                      Cool stuff!

                      Question: We are using our simple implementation of Preferences (pre 1.4), but now that we are finally moving to 1.4 we can use the 'standard'. However, we need the pref to come from the database (legacy requirements and cluster issues). Do you by chance know of an extension of Preferences that uses a db backing store? I'd hate to reinvent the wheel. Search on web shows nothing, but it could be under my nose, or is this another one line Spring change?

                      Regarding conditional spring config files. In another thread, I made a suggestion of making contexts part of a composite pattern, thus they would have an id, and so could be manipulated just like beans. This would allow conditional stuff and more, IMHO: http://forum.springframework.org/showthread.php?t=9891


                      --- jbetancourt
                      Last edited by robyn; May 14th, 2006, 05:52 PM.

                      Comment


                      • #12
                        Sorry guys, but it looks like I don't see the point. By using Perferences stores , in what way does it help you to package your API+Spring? Can you give me an example?

                        Comment


                        • #13
                          I don't see it either.

                          I see it more like allowing one to store configuration information in a more accessible place. Of course, there are property files for this but they tend to be a pain in some situations (or why invent the Prefs api), or not even accessible, as in EAR application distribution.

                          Comment


                          • #14
                            We've been investigating a way to package our API more...and at this point, we're going to go with the simplest for us - JAR up our class files, and provide Spring context files templates - if the users need to modify them for their specific situation, they can - otherwise, the default template will configure our application for the most common usage scenario. This incurs the (small) overhead of having the user be responsible for making sure the Spring context is configured correctly, but so far that's looking like the best trade off.

                            Comment

                            Working...
                            X