First off, I wouldn't in any way characterize this with phrases like "grubby paws" and "muck", especially if we do it cleanly. :) I also think there's a huge difference between the ease of writing a custom serializer/deserializer (two classes, deep understanding of SerializationContext/SAX events/etc) and setting up a TypeDesc. I once again refer you to the way the CLR does this, with descriptors like "[XmlAttribute name='foo']" prefixing field declarations. That's both easy and embedded.
The class of developer you're talking about isn't even going to look at that stuff. If you want, we can put comments around it to the effect that "The following code controls the mapping of this class to XML and was generated to match a particular schema. Modifying it may cause applications which expect that schema to break!" But the fact is, they shouldn't be mucking around with the code in the generated .java file AT ALL, right? They could change an accessor name, and thus change the XML.... I'll say it again. I'm fine if we go with an out-of-band solution, and even if that solution is the default for generated classes. But 1) when we do that, I think we should jar up the data classes for the user so that we make it difficult to shoot yourself in the foot by forgetting to copy the metadata descriptor along with the class, and 2) I think we should still have an in-band solution. --Glen > -----Original Message----- > From: Russell Butek [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 12, 2002 10:04 AM > To: [EMAIL PROTECTED] > Subject: RE: Bean Class/Bean Class Helper Generation > > > 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 > >
