Glen, I think we're talking about 2 different types of developers, here: - the ones that know what they're doing and want to get their grubby paws in the dirt of ser/deser. - the ones that use axis just to get their real job done (I believe the greatest number of AXIS users will be in this group).
The grubby ones are the ones you are trying to make life easier for by putting meta-data in the bean. But these folks LIKE playing in the muck. If we give them a different means to ser/deser their class - call it something outlandish like 'custom serializers' - then they'll be fairly willing to muck with it. But the 2nd type of folks will just program to the interfaces we provide them. If the meta-data is part of their interfaces, they may mistakenly think that they can use them productively. But for these folks, the code was generated and should not be touched. Keeping the meta data out of the APIs would make their life less confusing, less misleading. Russell Butek [EMAIL PROTECTED] Glen Daniels <[EMAIL PROTECTED]> on 03/12/2002 08:05:11 AM Please respond to [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: Subject: RE: Bean Class/Bean Class Helper Generation 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
