Hi Russell!
> Yeah, the proliferation of files DOES worry me. Perhaps > whatever solution > we end up with should continue along the path you set? Right now the > meta-data ONLY exists if we have attributes, so whether it's inline or > outline, the meta data will only be generated when we need it > (though I > fear we'll start needing it everywhere). Actually, if you look at the current code, the metadata exists whenever there are attributes OR there is a "non-standard" field<->QName mapping. So if we mangle a name to remove underscores, for instance (as in the problem dims was having last week), we used to produce the wrong element name because the mangling isn't reversible. Now we notice the mangling caused information loss, and record the correct QName in the metadata. This also covers the case where the namespace of an embedded field might be different from that of the enclosing class. Default serialization will often be just fine, but we really want to have the flexibility to change it. > What I meant by "if this non-bean stuff changes" is if the AXIS APIs > change. The generated bean now has a static typeDesc and a > static block of > code that initializes it. At best, when the APIs change, > there will be an > addition and the old static code won't fill in everything the runtime > expects. At worst, the APIs actually change and the old > static code simply > won't compile. But this isn't my biggest worry. As you > said, we have this > same problem with Stubs/Skeletons. What I really worry about > is keeping > the beans clean and clear of anything that's non-bean, so AXIS can use > non-AXIS beans and AXIS beans can be used outside of AXIS. Axis using non-axis beans is certainly important, and as I said I want to support that with some kind of external metadata for sure. Using Axis beans outside of Axis is, I think, a less critical use case, since again, you generated the bean specifically to use with our databinding framework, and I think it logically makes sense to consider the XML serialization configuration a part of the end-result. > I read your note to Greg. Give me a real-world scenario > where the client > will need the meta-data. My understanding of the meta-data > stuff is that > it is necessary for serialization/deserialization, NOTHING > MORE. Clients > shouldn't get involved in ser/deser. This info is GENERATED > code, meaning > it came from WSDL. We don't want the client mucking with the > meta-data > because then they're essentially modifying the WSDL contract. > You suggest > supporting both a unified model and a separation model, but since the > unified model exposes stuff to the client we don't want > exposed, I don't > think that's a good idea. First of all, let's get straight who we're talking about here. It's *developers*, right? And the use-case that I'm really interested in is the "Java first" one, where they are writing some java class and want to control the serialization of said class. Maybe this is because they want to match some wire format which they've seen but don't have a WSDL document sitting around to codegen from, or because they want the XML to look a certain way for some other reason which isn't doable with the default serialization. So they need a way of configuring this. As I said before, whether they do this by writing a little bit of code (see test.encoding.AttributeBean for an example, I hand-coded that), by writing xdoclet tags into their JavaDoc, or by writing a separate config file or class, the point is that they have control and the knobs are exposed to them. I believe we're just debating how those knobs work, or do you really believe that it's a bad idea to let them control this at all? > [rest of earlier conversation elided for brevity] --Glen
