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

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

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

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?

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.

Quote:

---

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.

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

Martin -

Quote:

---

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.

Quote:

---

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:D. 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:D.

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?

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

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. :D In otherwords, the less invasive, the better.

Thanks for your suggestions, Bryan. :D Any others?

Quote:

---

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. :D In otherwords, the less invasive, the better.

Thanks for your suggestions, Bryan. :D 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