EjbJar ejbJar = EjbJar.Factory.newInstance();
AssemblyDescriptorType assemblyDescriptor = ejbJar.addNewAssemblyDescriptor();
SecurityRole securityRole = assemblyDescriptor.addNewSecurityRole();
securityRole.setRoleName("foo");
...
etc.
Cool.
Am not sure if the Factory thing is required to instantiate new beans - I hope there can be a default constructor on the bean implementations so that they really are normal beans. Though the nice thing about the Factory approach is you can just use the generated interfaces in your code & not refer to the implementation classes directly.
It looks like the factories are the bridge between the interfaces and the impls, the impls need some schema fluff passed in during construction.
If so, are there any problems which might arise from doing so?
Not that I'm aware of.
I still have a few concerns. First you mentioned the usage of xpath, when constructing an object with out xml will code that expects xpath stuff still function? Same goes for code what expects the raw xml to still be accessible?
Second, it looks like XMLBeans requires XML libs to function, even if XML is not used. Consider an embedded server which does not use XML at all... looks like we must still provide XML libraries. Granted this is an off case, but still I would like our binding framework to provide a nice clean separation between the POJOs and XML.
BTW, I am not trying to dis XMLBeans, but just trying to understand which of the current binding frameworks is best suited for global use across the project.
--jason
