Robert, > > # 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.
Take a look at http://jakarta.apache.org/commons/betwixt/dependencies and note the following line: " The following is a list of dependencies for this project. These dependencies are required to compile and run the application". It may be not your fault, but once i want to use betwixt, i'm stuck with all these jars. > > > # 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 Ay > > # the marshaler and the unmarshaler require > specifying > > root xml tag name > > this is inaccurate. betwixt does not require specific > root tags. Taken from http://jakarta.apache.org/commons/betwixt/guide/examples.html : // Write example bean as base element 'person' beanWriter.write("person", new PersonBean("John Smith", 21)); // Register beans so that betwixt knows what the xml is to be converted to // Since the element mapped to a PersonBean isn't called the same, // need to register the path as well beanReader.registerBeanClass("person", PersonBean.class); > > 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? Have you ever heard of something called setAccessible() function on a Method and a Constructor? You don't even have to set your own SecurityManager with checkPermission overriden: public static void main(String[] args) { try { Class inClazz = Class.forName("test.Test$Inner"); Constructor ctr = inClazz.getConstructor(new Class[0]); ctr.setAccessible(true); Object instance = ctr.newInstance(new Object[0]); System.out.println(instance.getClass().getName()); Method getter = inClazz.getMethod("getMember", new Class[0]); getter.setAccessible(true); Method setter = inClazz.getMethod("setMember", new Class[] { int.class }); setter.setAccessible(true); setter.invoke(instance, new Object[] { new Integer(27) }); System.out.println(getter.invoke(instance, new Object[0])); } catch (Exception exc) { exc.printStackTrace(); } } where package test; public class Test { private static class Inner { private int member; public Inner() { } public int getMember() { return member; } public void setMember(int member) { this.member = member; } } } If you remove setAccessible, you get access exception, but with them (silly me), it works like magic. > > 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. Except that in this case you just could go all the way (silly me for noticing this). > 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. How about a link from the main page at https://bindmark.dev.java.net/ (to Ronald Bourret site)? > > # 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. Back to http://jakarta.apache.org/commons/betwixt/guide/examples.html and write example. Can you spot a close() for me? > > > # default log level for BeanReader is INFO > > this is inaccurate. the default log level depends on your > environment. And my environment is pretty standard (it has commons logging and JDK 5.0). > > > 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. JCK is not a major negative point as long as it *doesn't* produce results when everything is OK. If something's up - let me see it, if not - why should i care if some function had empty options popped from the stack? And that C24 use of commons logging caused OutOfMemoryError since the logging infrastructure never released the resources (after about 8000 marshalings). > i'll be interested to see whether you decide to correct > the inaccuracies > in your summary listed above. Am i missing something to correct (silly me)? Kirill ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
