The Castor team is pleased to announce its 0.9.6 release, a copy of which has been placed at the
project's new home at http://castor.codehaus.org.

Castor is an open source data binding framework for Java. It's the shortest path between Java objects, XML documents and relational tables. Castor provides Java-to-XML binding, Java-to-SQL persistence, and more.

This release is mainly a bug fix release, but adds some new features as well, including ...

    * Full support for lazy loading, including 1:1 relations for the first time.
    * Improved object creation performance through the use of cglib (http://cglib.sf.net)
    * Improvements to the jdo descriptor including the ability to specify explicit transaction demarcation
    * The ability to configure Castor JDO programmtically
    * Added pluggability of caching strategies, allowing users to role our their own implementations
    * Introduction of a Castor Source Generator Ant Task.
    * Explicit timezone support on JDBC ResultSets? via the castor.properties file
    * Extended support for the use of LIMIT/OFFSET clauses
    * Added initial support to suppress namespaces during XML marshalling.
    * Performance improvements in Castor XML's marshalling and unmarshalling functionality.

After over five years of Exolab (http://www.exolab.org) hosting Castor, the Castor team recently decided to move
the entire project to a new home (http://castor.codehaus.org) over at Codehaus (http://www.codehaus.org).
The team would like to thank Exolab and it's parent company Intalio, Inc. for it's long-standing support of
the project.

For more details, please have a look at the release notes at the release notes at
http://castor.codehaus.org/release-notes.html.

A new version of Castor.

Who cares?

I do, idiot.

I do, idiot.

Jose, I'd not waste my time with comments like the above, if I were you. Personlly, I can understand some of the emotions of the original poster (with Castor JDO having been quite inactive for some years), but 0.9.6 is going to be the last major release before 1.0. For questions and comments related to this subject, I can only invite you to join us on the mailing lists/discussion forums/irc channel over at http://castor.codehaus.org.

I used Castor in the past and it was buggy as hell... I had to patch the distribution with my own modified classes. I'll never use it again. There are far better free tools out there.

That's surprising, Castor is one of the most reliable libraries we have used here. We are using it in a number of different projects. I ran a comparison of it against some open source JAXB implementations and chose to stay with Castor for many different reasons.

I, for one, care about the new version. Thanks for posting about it.

Wow a new version! We'll how many more years until a Version 1 comes out. I just don't think I'm going to use a beta project for my production environment.

Wow a new version! We'll how many more years until a Version 1 comes out. I just don't think I'm going to use a beta project for my production environment.

Just cause it is pre 1.0 doesn't mean it is not production ready. Maybe they have higher standards than, lets say, Microsoft. :) Sometimes the release number is reflective of the funtionality they desire implement before going 1.0.

Of course, as soon as they go 1.0 people will be saying, "I'm not gonna use it till at least 1.1".

Just cause it is pre 1.0 doesn't mean it is not production ready. Maybe they have higher standards than, lets say, Microsoft. :) Sometimes the release number is reflective of the funtionality they desire implement before going 1.0.Of course, as soon as they go 1.0 people will be saying, "I'm not gonna use it till at least 1.1".

Well, lets be a tiny bit honest here, shall we? Castor has been in Beta form for literally years. There is a reason for that - Castor has big problems still. I'm currently on a project that uses it and I can't say that we have had a positive experience with it, on many levels, which is why we are redoing the persistence layer with Hibernate. Need I say more?

Just to be clear, 1.0 generally signifies that, to the best of the developers knowledge, the code that exists _works_. Don't quote garbage like they may have higher standards than MS, how would you know? I really don't understand why you would even take this stance, are you ON the castor project and just defending it because of some personal bias?

Trust you me folks, don't use a library in a production project until its at least 1.0, and don't listen to anybody that would suggest otherwise. Even then you may run into problems, but if its still beta, you have nobody to blame but yourself!

I've been using castor since 2001. Overall, I am happy with the quality of castor and find it useful. I've only skimmed jaxb2.0 spec, but one feature of Castor which jaxb2 doesn't have is java.beans support. I could be wrong, but I did a search for "propertyChange" on 2.0 early draft and didn't find anything. Having done a comparison of various schema compilers over the last 3 years, I can say with confidence Castor is reliable.

The addition of interfaces and support for jaxb API would be nice, but it's not critical for me. Having written my own schema compiler from scratch, my opinion is the castor developers have done a good job on schema support. That's not to say Castor couldn't use some improvements, but from a W3C Xml Schema compliance perspective, it easily beats XSD. .NET XSD doesn't support the full Xml Schema specification and fails to handle many cases. Not that castor supports the full spec either, but it definitely supports more of the spec.

I haven't used Castor for persistence, so I can't speak about the quality of castor jdo. Even if castor jdo doesn't match the quality and features of other tools like Hibernate, castor is still useful. As a java-xml binding tool, it provides an alternative to jaxb. My hope is the best feature from castor, jaxb and jibx will merge in 5-6 years, once the problem has been beaten to death. but that's just me.

but not for persistence, which is what I'm talking about. The fact that this one part of Castor is so bad off while the xml-binding part seems to have some support also shows serious issues with the project - if one part is actually good, they should break it out from the persistence side so that people could use it with some measure of confidence. There is certainly nothing of that feeling of confidence towards the persistence side for me, and I know this from personal experience.

I've heard about Castor going to 1.0 for a very long time now (literally years now), so I wouldn't hold my breath for a completion date at this point.

Hi,

I have been using Castor's JDO extensively since 2000, having used it in systems such as an eLearning system, building automation system (real time, though not really time critical) and in my current project, a courier system.

I must say that I have not found any major problems with Castor's OR mapper yet. I like it quite a lot and though I have every intention of moving on to hibernate, having explored it since 2003, Castor's solid performance for me is not giving me an urgent need to move on to hibernate or some other OR mapper.

Though I do like hibernate's better support of OO, I'll probably move to hibernate a bit later, maybe ver 3. Maybe.

My point is, Castor's OR mapper is solid and has served me well since 2001, in a team and solo development. I sincerely would like to know what your problems are.

Well, lets be a tiny bit honest here, shall we? Castor has been in Beta form for literally years. There is a reason for that - Castor has big problems still. I'm currently on a project that uses it and I can't say that we have had a positive experience with it, on many levels, which is why we are redoing the persistence layer with Hibernate.

Mark,

let me be quite frank here. To introduce myself properly, I am one of the current set of seven active committers on Castor JDO. You are definitely correct that Castor has been fairly inactive for quite some time and hence has not really moved on (for too long in my personal opinion).

Having said that, I am not aware of *big problems* as you state. If so, I definitely should would have heard about those via mailing lists or bug reports or any other means. I am ware that the product lacks two or three features (most noticeably support for polymorphism), but this will be delivered as part of a 1.0 release as well as other features (complete rewrite of the OQL engine, etc.).

In other words, if you are experiencing problems with Castor, I'd be the first one to offer you help. The fact that I have not seen any questions from you on any Castor-related communication channel about your problems hence does not really add to your credibility.

Does Castor JDO support foreign keys?

And many-to-many relationships?

And many-to-many relationships?

Check out their site:
http://castor.codehaus.org/jdo-mapping.html#Object-Mappings

Short answer though, is yes.

Big problems:

1) xml config file parsing can't handle out of order elements
    ie. if your entities in the config file aren't in the 'correct' order from top to bottom you get wierd xml exceptions (very tricky and time consuming to track down)
2) Unknown syncronization errors popping up during persistence
3) Difficult mappings where dependancies have to be declared on specific entities, makes it impossible to wire up certain object so cascading works properly

Its just too much, Hibernate works much cleaner and easier.

Best,

Mark

Big problems: ...[snipped]

Mark, feel free to stay with Hibernate, as clearly it is a very solid product. For the problems mentioned, I can only invite you to file a couple of bug reports with us (given that your problems are reproducible), even if you would not be able to benefit of their resolution.

Best,
Werner

hi all
first, congratulations for the new release
i have a suggestion,i know that castor proud of its API and it was the basis for ideas of many standards but actually these days too many standards and apis are arising every day and developers cannot afford time and effort to learn them all, so even with a really high quality product like castor, it may someday dismiss because nobody have time to learn its api so I SUGGEST:
support the standard JDO JSR api and JAXB api on top of the existing api so the transition to castor will b smooth and easy
this is my opinion and i wanna know your official statment

this is my opinion and i wanna know your official statment

We are currently debating this question internally (not really religiously, to be honest .. ;-)), and if you happen to have an opinion you'd like to be considered, please join us at the project's communication channels over at http://castor.codehaus.org.

Will someone at Castor please decide whether to implement Sun's JDO 1.0 or drop the JDO part of "Castor JDO"? I would really not like to see a return of the confusion of several years ago, when everyone was confused between JSR 12's JDO and Castor's JDO.

Will someone from Castor please comment, given that the following is still present on the Castor site?
http://castor.codehaus.org/jdo-faq.html#Does-Castor-JDO-comply-with-the-SUN-JSR-000012-specification?

Thanks,
Matthew
(JDO 1.0 & 2.0 EG Member)

Is SQL binding fixed or will

+--------+1 +--------+
| ClassA +------*| ClassB |
+---+----+ +--------+
    |1 +--------+
    +-----------*| ClassC |
                 +--------+
still cause a million row result set if B & C are 1000 rows each?

Oops forgot code tag /blush.

Is SQL binding fixed or will ...

Jan, please drop by at e.g. the project's discussion forum, and I am sure we'll be able to adrdess your problem/answer your question. Without any proper information about the version of Castor you are using, etc., I won't be able to assist you in any way. And imho, this news board is not the right place to discuss.

Will someone at Castor please decide whether to implement Sun's JDO 1.0 or drop the JDO part of "Castor JDO"?

Matthew, we are currently discussing of supporting JDO 2.0 internally.

Regards
Werner