Hi Greg!
It seems that the position you're putting forth (and that, I gather, of Rich and Russell as well) is that it's a good idea to at least encourage, and perhaps enforce, a logical separation of the type-mapping metadata from the implementation of a data class. I don't disagree that such a separation is sometimes valuable, I just don't think it's always necessary. You're quite right in that we're exposing this stuff to the end user. One of the points of a metadata system like this, whether it be via classes (internal or external to a data class) or file-based configuration, is to enable a Java programmer to easily control the XML serialization of their classes. We need to expose something to the end user for that to be possible. I don't think it's a particularly difficult problem for most cases. In answer to your #1, I think the APIs we're talking about are pretty straightforward and yes, I think they're certainly as ready for prime-time as, say, JAX-RPC is. :) In answer to your #2, I have two comments - first, we have exactly the same problem with Stubs and Skeletons (I'm actually in the process of attempting to obviate the need for Skeletons). Second, why would a recompile be necessary? If the XML format needed to change? That seems like a reasonable time to recompile to me. Another thing to note here; let's say we do have an external descriptor, or another class. That makes life clean and easy in some ways - it makes the original data class completely independent and usable in other contexts without axis.jar, which is cool. But if you DO want to use the XML metadata, you now need to make sure that you copy the helper class, or the config file, along with the class whenever you want to use it or put it in a jar file. That seems like a usability tradeoff to me, especially in the common case where you actually generated this class from XML (and thus clearly are planning to use it in an XML context). Let me make very clear my position here. I'm for flexibility - my "devil's advocate" note, and the points made above, are primarily to indicate that I think there are some good reasons why you might want an embedded metadata solution. I definitely don't want that to be the ONLY solution, since for one thing that would make custom serialization of classes to which you don't have the source code rather tricky. I like the config-file solution better than the auxilliary-class solution as the "external" metadata source, but I'd also like to keep the "internal" one around. Castor uses xml files, .NET uses embedded metadata - both are good models, let's do both! Will you be able to make the chat tomorrow? I think it would be good if we could spend some time on this topic there. --Glen > -----Original Message----- > From: Greg Truty [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 11, 2002 8:27 PM > To: [EMAIL PROTECTED] > Subject: RE: Bean Class/Bean Class Helper Generation > > > Glen, > > I think we all feel that having the metadata to the runtime > is a good idea > (and in some sense, required). I also agree that to make the metadata > available for an XML-aware piece is goodness (but I would add to that > statement an XML-aware piece of runtime code). I believe some of the > concerns stem from the fact that we are exposing to the end user this > metadata vs. exposing this to the runtime infrastructure. > Questions that > come to mind at this point in time are: > 1) If these are exposed to the end user, will customers try > to code to > them? By making them public, you are formally exposing these APIs. > Therefore, there needs to be some amount of stability to > these APIs. Do > we feel that this is ready for prime time? > 2) These artifacts, by being in the code that a client App compiles > against, it's difficult to force a client to recompile their > apps (vs., > changing some deployment-time generated artifacts). > I think the rationale of introducing these as separate > artifacts (as Rich > described in the Helper class) may allow a regeneration of some of the > helper classes... (to correspond to runtime changes) but not > necessarily a > recompiliation of the client code. Just my 2 cents... > > Regards...Greg > > Greg Truty > > > > > > Glen Daniels > > <gdaniels@macrome To: > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > dia.com> cc: > > Subject: RE: > Bean Class/Bean Class Helper Generation > 03/11/2002 04:59 > > PM > > Please respond to > > axis-dev > > > > > > > > > > Well, on the one hand I agree it should be possible to do > this, but let me > play devil's advocate for a minute. > > If we're generating a class from an XML template, the > assumption is that > we're going to, at some point, be serializing/deserializing that class > to/from XML. If that's the case, doesn't it make sense to keep the > metadata about that mapping tied closely to the class itself? For > instance, .NET does this by embedding the metadata right into the CLR > bytecode, which I think is a great idea. That way any > XML-aware piece of > the system can do the right thing with these classes without > any external > configuration. What's so wrong about embedding it? > > "If we expose the meta-data to the users, we are going to > regret it..." > > Hm. Let's say I'm starting from Java, and I want to control > how my class > is represented in XML... how do I do that without having some > knobs I can > twist on the metadata? Whether that be in a separate file or > in the java > itself, I need to be able to have that functionality somehow! > > (Longer-term, I think that xdoclet tags are the right way to do this > stuff.) > > --Glen > > > -----Original Message----- > > From: Richard Sitze [mailto:[EMAIL PROTECTED]] > > Sent: Monday, March 11, 2002 5:33 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Bean Class/Bean Class Helper Generation > > > > > > +1 to stepping back and designing (ie. cease code-checking > on current > > direction) > > > > It's critical that we isolate JAX-RPC implementation details > > (Meta-data) > > from the classes exposed to the user. We need a design that > > reflects this > > in place ASAP, and we need to be writing to the design to minimize > > unnecessary rework later. I'm all for refactoring, but I'm > > even more for > > starting off on the right foot for the users. > > > > If we expose the meta-data to the users, we are going to > regret it... > > > > > > +1 on an interface. > > > > +0 on this specific interface. Those who are dealing with > > this section of > > code need to agree on this. > > > > <ras> > > > > > > ******************************************* > > Richard A. Sitze [EMAIL PROTECTED] > > CORBA Interoperability & WebServices > > IBM WebSphere Development > > > > > > > > > > R J Scheuerle > > > > Jr/Austin/IBM@IB To: > > [EMAIL PROTECTED] > > MUS cc: > > > > Subject: Bean > > Class/Bean Class Helper Generation > > 03/11/2002 04:14 > > > > PM > > > > Please respond > > > > to axis-dev > > > > > > > > > > > > > > > > > > > > There have been several recent changes to the Bean Class > generation to > > support more advanced > > xml features...namely attributes. > > > > I applaud the new functionality, but we need to step back and > > consider a > > more flexible architectural direction. > > > > I would like to see all of the meta data information removed > > from the java > > bean class and placed in a > > Helper class that extends a Helper interface. Here is a > > first pass at the > > Helper interface: > > > > interface Helper { > > public org.apache.axis.description.TypeDesc getTypeDesc(); > > > > public org.apache.axis.encoding.Serializer getSerializerAs(String > > mechanismType); > > > > public org.apache.axis.encoding.Deserializer > > getDeserializerAs(String > > mechanismType); > > } > > > > The generated bean class should contain ONLY the > > getters/setters describing > > the bean (and perhaps > > the equals() method...which needs some work). This would > adequately > > decouple > > the logical bean from the serialization/deserialization of the bean. > > > > The BeanSerializerFactory/BeanDeserializerFactory could be > tweaked to > > always look for a corresponding > > Helper class to find the meta data or find the custom > > serializer/deserializer. The generic serializer/deserializer > > classes should use default behaviour if the helper class is > > not available. > > (In fact I am in favor of having > > separate meta data aware serializers/deserializers.) > > > > Separating the bean and the bean helper would allow users to > > provide custom > > Helper emitters to > > add custom serializers etc. > > > > Please comment. > > > > Rich Scheuerle > > XML & Web Services Development > > 512-838-5115 (IBM TL 678-5115) > > > > > > > > > > >
