Discussions

News: eXist 1.0: Open Source XML Database

  1. eXist 1.0: Open Source XML Database (12 messages)

    The eXist project has released the second beta of eXist 1.0. eXist is an open source native XML database, featuring index-based XQuery processing, XUpdate support, and much more. It is published under the LGPL.

    This release benefits from a lot of testing done by other projects, and fixes many instabilities and database corruptions that were still present in the previous version.

    In particular, the XUpdate implementation should now have reached a stable state. Concurrent XUpdates are fully supported. The XQuery implementation has matured, adding support for collations, computed constructors, and more. Module loading has been improved, allowing more complex web interfaces to be written entirely in XQuery (see new admin interface). Finally, there's a new WebDAV module, a reindex/repair option and support for running eXist as a system service.

    To learn more about eXist and it's features, have a look at the various demos available on the website:

    View the home page: http://exist-db.org

    Threaded Messages (12)

  2. Using Cocoon+XQuery+XUpdate you abstract completely from the underlying platform. If there were a .NET implementation of these technologies you may move an applicacation from a j2ee to a .net server and viceversa, without modifications.
  3. Would it be difficult to port this stuff (eXist, Cocoon, etc.) to .NET?

    I understand that Microsoft's Java Language Conversion Assistant may be used to translate Java source files into C# source files. And I believe that somebody published the results of such a conversion effort (Lucene) in Dr. Dobbs magazine a while back. However, I haven't attempted such an effort myself yet.

    I'm interested in this question because I prefer .NET and C# over Java, but .NET has nowhere near the number of useful libraries, frameworks and other stuff available for it that Java has. Java seems to enjoy much broader support from the open source community than .NET does.
  4. Would it be difficult to port this stuff (eXist, Cocoon, etc.) to .NET?I understand that Microsoft's Java Language Conversion Assistant may be used to translate Java source files into C# source files.

    I've never had a look at the source code of eXist, Cocoon etc., so I can't comment on that. I've used JLCA (the version that ships with Visual Studio 2003, there are newer ones!) on a non-trivial project comprising something around 400 classes/interfaces.

    Will it be difficult? Yes it will, but not 'too' difficult. The JLCA version I used had some serious bugs and there a lot of Java APIs it doesn't know how to convert. So be prepared that you'd have to check actually each line of converted code and there is much coding left that has to be done by you. Furthermore, I wouldn't advise it if you don't have a thorough knowledge of both languages, Java and C#.

    For me, it worked and I would do it again that way if the code base is substantial. It might be worth to have a look at some newer JLCA version. Be prepared to face thousands of C# compilation errors :)

    Regards,
    Stefan
  5. Thanks for the information.

    Overall, I'd say that your experience sounds like it went well enough that attempting to use the JLCA might be worthwhile.

    The one problem that the JLCA doesn't solve, however, is the community-building problem. In other words, translating a Java code base to C# is effectively a fork. So, even if I converted the Java code, fixed all of the compilation problems, and then posted the resulting code as a new Sourceforge project, there's no guarantee that a community would form around the new code. So, the new code might stagnate while the Java codebase continued to move forward.

    Do you have any ideas about how to solve this problem?

    Doug
  6. I coded myself an implementation of Cocoon in C#. It supports all the basic pluggability framework and shows up some components such as I18n transformer, web service transformer, basic generators and renderers. At the moment the project is closed and belongs to my company.
  7. How difficult was it to re-implement Cocoon in C#?
  8. The point is that Cocoon is made of a core and of many so called blocks, which are a sort of plugins. These blocks usually rely on third party libraries, for example the block that transform fo to pdf.

    So, the core is rather simple to port, in a couple of weeks I had something running. Instead of course, blocks are hard to port because you would need an implementation of the third party library too.

    Actually my implementation has not met much success, since the c# developers preferred coding using .NET native frameworks. So maybe I will ask my boss If I can publish my work on sourceforge.

    Carlo.
  9. The point is that Cocoon is made of a core and of many so called blocks, which are a sort of plugins. These blocks usually rely on third party libraries, for example the block that transform fo to pdf.So, the core is rather simple to port, in a couple of weeks I had something running. Instead of course, blocks are hard to port because you would need an implementation of the third party library too.Actually my implementation has not met much success, since the c# developers preferred coding using .NET native frameworks. So maybe I will ask my boss If I can publish my work on sourceforge.Carlo.

    I know how you feel. Not to over generalize, but that's one cultural difference between java and .NET developers. Even though Log4Net is easier to use and more flexible, many developers I know won't even consider it. Instead they use Microsoft's framework.

    The other thing I see, which is really the corporate culture is re-inventing the wheel. Companies that do not like open source often end up re-inventing existing applications in the open source world. I recently saw this happen and the resulting code was no where near as mature or robust as existing java open source code. Once the other developers starte to use it, all the problems started appearing and the deficiencies became apparent. The code had to be thrown away, because it was designed without understanding the current state of art. Given another 16 months, that particular tool could have evolved to the point where it's half as good as open source equivalent, but that's not productive time.

    I like the idea of using IKVM to build dll's from jar's, though I haven't done it yet. In theory it can save a lot of time.
  10. my experience with JLC[ Go to top ]

    I tried to convert a non-trivial Java application to C# and it blew. I then tried it on Joram and OpenJMS and it still blew. In the case of something like Joram and OpenJMS, the hard part is there are so many things missing like JNDI and all the other java libraries the projects uses that it wasn't worth the effort. Especially since many people in the company distrust open source and felt it would be as good as biztalk or msmq.

    in some cases, it may be better off to use IKVM to generate Dll's and write a wrapper instead.
  11. my experience with JLC[ Go to top ]

    Thanks for the information and the suggestion.

    Which version of JLCA did you use for your conversion attempts? My understanding is that JLCA v3 is supposed to have some ability to convert code that references J2EE apis such as JMS. Perhaps v3 would do a better job than the current version of converting something like OpenJMS.
  12. JLCA 2 and 3[ Go to top ]

    I think it was version 2 and 3. to be fair, doing that kind of conversion isn't necessarily easy for an automated tool. The nice thing about JLCA is it does generate a detailed report of what worked and what didn't.

    I'm totally bias, but I think it's more reliable to have an experienced developer who understands Java and C# doing the port manually. In some cases, it's better to start from scratch. when I needed JAXB style schema compilation, I couldn't find one in .NET. Rather than port JaxMe or Castor, I decided to take advantage of .NET Xml serialization and write a new one from scratch. The schema compiler took me 5-6 weeks of coding at night and weekends. Once I got far enough, I open sourced the tool http://dingo.sourceforge.net/.

    by borrowing good ideas from jaxb, castor and other open source tools, I was able to build something that meets my needs. It may not meet the needs of others, but it does meet my requirements. Porting Castor, which has much more features would have taken me several months of consistent work to get a usable port.

    the same is true of JaxMe. now I'm considering getting involved with JaxMe to add the plugin features I designed for Dingo schema compiler.
  13. eXist 1.0: Open Source XML Database[ Go to top ]

    I'm concerned about connection pooling and transactions. Most of the commercial XML Database vendors (Tamino, Sonic, etc) seem to use JCA for thier J2EE application API. Can XML:DB provide the same services? Does eXist even belong in a J2EE environment?