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)
>
>
>
>
