(I was actually going to post about the –skip-grant-tables –user=root parameters, but I didn’t realize you could do it differently on Windows)

Did you use the exact same version of hibernate core and hibernate annotations in those environments ?

In any case, please report the resource problem in our jira and i’ll look at them.

It also arguably scales better. Nutch (nutch.apache.org - based on Lucene, with a distributed file system etc) can search across billions of documents and scales across thousands of machines.

Another option is a “search server”. Things like Verity or Solr (http://incubator.apache.org/solr/) run as stand alone apps, and give you an HTTP/XML based API for indexing and querying.

I could switch to Hessian as the transport protocol - there’s a C# implementation of that. My gut feeling is still that a Java GUI will take longer to implement than a .NET one, hiccups notwithstanding. There a large amount of personal comfort in that estimation though.

Time will tell I suppose.

I decided to wrap the XPath functionality in a very simple wrapper class so if I ever need to switch out XPath engines again, I wouldn’t have to dig through every app’s code again.

A little off-topic, but I thought I would share what little wisdom I have …

Basically, for editing bean definitions you get:
- Auto-complete of bean class names
- Auto-complete of bean property names
- Validation (for example, if a property doesn’t exist, as you said).
- With Intellij, automatic refactoring of your Spring configuration XML when your source changes.

Without such automatic refactoring, yes, if you refactor your component source you *may* have to go update the XML. If that is the case and you don’t you’ll get a *descriptive* runtime error pointing to the line in the file that caused the exception.

Now perhaps I’m unique here, but I don’t mind this. I like treating my “system configuration blueprint” separate from my application code–a distinct, externalized concern, one not magically changed because of refactoring that goes on in my source. It’s not like we’re talking about changes in internal logic affecting these externalized files, either, it’s only changes in the external configuration interface, which in my experience, changes less frequently.

In addition, with a proper JUnit system configuration test, you get error notification in subsecond speed telling you *exactly* what the problem was in each case, so you know exactly where you need to go to make the change.

One of the general points about Spring I haven’t seen mentioned much is the careful attention placed to error reporting. And Spring IDE on Eclipse and Intellij both provide great Spring tooling support.

Keep in mind also since Spring configuration elements are represented in a standard form of metadata, they’re also easily engineerable into visual diagrams (just like what Spring BeanDoc does, for graphically illustrating subsystem dependencies, and how systems relate to other systems).

Regarding the library versioning issues you were having, Spring ships with a document that notes exactly what versions of other libraries are supported and when they are required. To use the base container, all you need is spring-core.jar, spring-beans.jar, and commons-logging.jar.

Also, it is on the Spring release roadmap to more generally in the future use an automated jar dependency manager to assist with managing its dependencies (providing a document is one thing, but offering an automatic solution for common developer configurations is even better). Spring Web Flow, another project from the Spring community, is already taking the lead here, using a product called Ivy to manage it’s supported configurations.

Cheers,

Keith