On Sun, 2005-08-07 at 07:06 -0700, Kirill Grouchnikov wrote: > Robert, kirill
> # xml-commons jar files (resolver.jar and which.jar) have > common names which can easily lead to jar name collision > The jar naming *is* a big concern once you start to use > open source libraries *and* your own. The names should be > clear and unequivocal. this is inaccurate: betwixt ships only one jar commons-betwixt. > # the marshaler needs to explicitly add xml header > Call this petty, but why should i add this by myself? this is accurate but is a feature :) betwixt deals with fragments not documents > # the marshaler and the unmarshaler require specifying > root xml tag name this is inaccurate. betwixt does not require specific root tags. > Once again, may sound petty, but why should i treat root as > something different? If the an object of the same class > appears elsewhere in the hierarchy, you are not requiring > me to provide you the name, so what's different? it isn't different: dynamic binders make a guess and may have to be corrected through configuration > # can not correctly handle private static inner classes this is accurate but misleading. the java language prevents construction. don't you feel a little silly listing that as a negative point? > I understand the reflection limitations, but the marshaler > goes half way (emits the attribute names, but not values, > and doesn't provide errors at all), while the unmarshaller > fails completely. It's either all go, or no go. i disagree (and i'm in good company). start-from-java binders typically adopt a do-what-you-can approach. this is why start-from-java binders do not guarantee to be able to round trip. IMO it would be much more illuminating if you listed the natural weaknesses of start-from-java binders (as you see them) separately and then just classify those which adopt this approach. > # if ByteArrayOutputStream is used for marshaling, the > BeanWriter must be close()'d to see the xml, unlike > StringWriter > The documentation in its current state says nothing about > using BAOS and need to explicitly close BeanWriter. I had > to figure out this one by myself. inaccurate: *all* streams and readers should be closed. > # default log level for BeanReader is INFO this is inaccurate. the default log level depends on your environment. > and it > produces messages on the examples (and real code) which can > be turned off only via configuration > Now this *is* a major issue. I don't want a 3rd party to > pollute my logs, especially since everything went smoothly. > In addition, commons logging is *way* too complicated. You > can say here that it figures out everything on its own, but > there is simply no option to turn it off in every possible > system configuration except creating your own logger and > putting it on BeanReader). it's clear from comments about other libraries that you view the use of JCL as a major negative point. fine. IMO it would be much clearer just to say 'uses commons-logging' as a negative for each that does rather than list some inaccurate specific. i'll be interested to see whether you decide to correct the inaccuracies in your summary listed above. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
