beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: Role of .ser file in WSM
Date Fri, 08 Jul 2005 11:34:53 GMT
I agree with Rich. PLEASE use an XML Schema for our model.

-- dims

On 7/8/05, Rich Feit <richfeit@gmail.com> wrote:
> Thanks for the info in this and the previous response.  For my part (and
> at this point I'm really just an observer of the WSM codebase), I would
> still go with an XML schema that matches the model you build.  WSDL is
> standard, but it seems like it's a standard for expressing a public
> interface, not a standard for this particular use.
> 
> Rich
> 
> Daryoush Mehrtash wrote:
> 
> >On 7/7/05, Eddie ONeil <ekoneil@gmail.com> wrote:
> >
> >
> >>  Agreed.  A WSM-specific XML file seems like the right way to go here.
> >>
> >>
> >>
> >
> >
> >
> >
> >>  Producing a partial WSDL will be weird for the user as it's just
> >>used as a transport for our own information but we use a name (wsdl)
> >>that implies more than that.
> >>
> >>
> >>
> >
> >
> >The only thing "partial" about the WSDL that we can generate at APT
> >time is that its  schema types would not be fully defined.  Or at
> >least I don't see how one can determine the  schema types unless you
> >actaully load and run the classes.   Other than schema type the WSDL
> >would be complete.
> >
> >
> >
> >
> >
> >>Eddie
> >>
> >>
> >>
> >>
> >
> >daryoush
> >
> >
> >>On 7/7/05, Davanum Srinivas <davanum@gmail.com> wrote:
> >>
> >>
> >>>-0 to wsdl. +1 to (XML schema that conforms more to the model)
> >>>
> >>>-- dims
> >>>
> >>>On 7/7/05, Rich Feit <richfeit@gmail.com> wrote:
> >>>
> >>>
> >>>>A few questions about this (again, I'm just trying to educate myself
here):
> >>>>
> >>>>    - If WSDL is the "overwrite" format, then this means deployment-time
> >>>>overwriting would have to be done through WSDL, right?
> >>>>    - Let's say that *all* the extra information you need is parameter
> >>>>names.  Can valid WSDL be sparse enough to make sense for this?
> >>>>    - Why wouldn't it be possible to generate type information during
> >>>>apt processing?  apt/Mirror gives you a superset of what you have at
> >>>>runtime.  Or is it just logically impossible to get the right
> >>>>information during the processing stage?
> >>>>    - At a root level, why is WSDL a better format than an XML schema
> >>>>that conforms more to the model?
> >>>>
> >>>>Thanks,
> >>>>Rich
> >>>>
> >>>>Daryoush Mehrtash wrote:
> >>>>
> >>>>
> >>>>
> >>>>>An idea from "sleepless night in Seattle" :)
> >>>>>
> >>>>>I think there is an overall agreement that we need *something* to
keep the
> >>>>>missing information form class files. And we all seem to agree that
the
> >>>>>serialized java file is not the right solution.
> >>>>>
> >>>>>Instead of creating yet another XML file, why not just use a WSDL
file to be
> >>>>>the additional information. We can build a WSDL (minus its type information)
> >>>>>during the APT process. In run time the code would look something
like:
> >>>>>
> >>>>>Load the object model from reflection (java.reflection or ASM)
> >>>>>
> >>>>>If there is a WSDL file
> >>>>>
> >>>>>To the extend possible use the WSDL information to over write the
JWS
> >>>>>settings
> >>>>>
> >>>>>Make sure there are no conflicts between WSDL and JWS file
> >>>>>
> >>>>>Run the web serviceā€¦.
> >>>>>
> >>>>>I don't believe it would be possible to generate the WSDL's type
information
> >>>>>during the APT processing. Furthermore, the real WSDL of the service
is
> >>>>>generate by the SOAP stack, and may be different from the WSDL file
that is
> >>>>>generated during the APT processing. Nevertheless I think the WSDL
(or a
> >>>>>subset of a complete WSDL) would be a logical format to keep the
missing
> >>>>>information.
> >>>>>
> >>>>>Thoughts?
> >>>>>
> >>>>>Daryoush
> >>>>>
> >>>>>
> >>>>>On 7/6/05, Daryoush Mehrtash <dmehrtash@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Yes. We essentially need some information that is lost when the
JWS
> >>>>>>files are compiled. The curent solution is to build the complete
> >>>>>>object model during the APT build process. The model containes
all
> >>>>>>that is needed to run the web service (information on the web
> >>>>>>servicer, every method, parameter etc). Most of the information
is
> >>>>>>available from the class file, so the serialized information
is
> >>>>>>redundant, and as Eddie has said at time the information is not
even
> >>>>>>valid.
> >>>>>>
> >>>>>>For run time I am proposing we build the model of the web service
from
> >>>>>>the JWS class file, but have a file that would over write the
> >>>>>>information in the class files.
> >>>>>>
> >>>>>>At build time we can save the missing information to this file.
We
> >>>>>>only need the parameter names, but the same mechanisem could
> >>>>>>potentially be used by a deployer to overwrite the information
in the
> >>>>>>class files.
> >>>>>>
> >>>>>>Right now we are dependent on APT process. But in my model you
can
> >>>>>>also work based on straight Javac. Although with APT you get
a more
> >>>>>>conformant (default parameter names) implementation.
> >>>>>>
> >>>>>>Daryoush
> >>>>>>
> >>>>>>On 7/6/05, Richard Feit <richard.feit@bea.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Just to make sure I'm clear on this, we're talking about
something that
> >>>>>>>*was* a Serialized object written to a ".ser" file, but that
will no
> >>>>>>>longer have anything to do with Serialization? The "overwrites"
that
> >>>>>>>you're talking about are simply the parameter names, written
to XML?
> >>>>>>>
> >>>>>>>Just trying to understand -- I haven't been involved in the
coding of
> >>>>>>>this piece, so I'm starting from scratch here.
> >>>>>>>
> >>>>>>>Thanks,
> >>>>>>>Rich
> >>>>>>>
> >>>>>>>Daryoush Mehrtash wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Beside the format of the ".ser" file we also need to
reach closure on
> >>>>>>>>its content and its role.
> >>>>>>>>
> >>>>>>>>Right now the .ser file contains the complete model and
is the sole
> >>>>>>>>means to build the object model at run time. I think
we need to change
> >>>>>>>>both aspect of the .ser file.
> >>>>>>>>
> >>>>>>>>My suggestion on this is to always build the run time
object model of
> >>>>>>>>the web service based on Reflection (or similar class
analysis e.g.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>ASM)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>and use the ".ser" (in any format you choose to keep
it) to overwrite
> >>>>>>>>the reflection information. The ".ser" then doesn't have
to be a
> >>>>>>>>complete model, rather it would only contain the overwrites.
The
> >>>>>>>>overwrites would take precedence over the class file
annotations and
> >>>>>>>>would be used by the build process, or deployment process
to control
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>final web service.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>Daryoush
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>-----Original Message-----
> >>>>>>>>>From: Eddie ONeil [mailto:ekoneil@gmail.com]
> >>>>>>>>>Sent: Wednesday, July 06, 2005 10:13 AM
> >>>>>>>>>To: Beehive Developers; mmerz@acm.org
> >>>>>>>>>Cc: Eddie O'Neil; Daryoush Mehrtash
> >>>>>>>>>Subject: Re: Role of .ser file in WSM
> >>>>>>>>>
> >>>>>>>>>And, again, I can see the value of having *something*
that conveys
> >>>>>>>>>this information (the formal argument names), but
I disagree with
> >>>>>>>>>using a serialized Java object to convey this information
-- the .ser
> >>>>>>>>>file.
> >>>>>>>>>
> >>>>>>>>>Seems to me that there are more architecturally flexible
/ loosely
> >>>>>>>>>coupled ways of conveying this information than serializing
the entire
> >>>>>>>>>object model (which includes fully-qualified paths
from the build
> >>>>>>>>>environment). Information like these fully qualified
paths shouldn't
> >>>>>>>>>be made available to the runtime side.
> >>>>>>>>>
> >>>>>>>>>That's why I was suggesting either XML or a generated
BeanInfo file.
> >>>>>>>>>
> >>>>>>>>>Hope that's clear...
> >>>>>>>>>
> >>>>>>>>>Eddie
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>On 7/6/05, Michael Merz <michael.merz@gmail.com>
wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>Hi guys,
> >>>>>>>>>>
> >>>>>>>>>>Sorry for the late response -- I've been *really*
busy for a while
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>;)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>There were reasons for using a .ser file, the
most prominent one
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>being
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>that interfaces will *not* contain the parameter
names of methods --
> >>>>>>>>>>even when compliled with the debug version. A
serialized object
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>model
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>file seemed to be the only way of capturing all
information.
> >>>>>>>>>>
> >>>>>>>>>>I agree that the .ser-file/object model needs
some clean-up since it
> >>>>>>>>>>has "grown". If you'd like to work on it, I would
suggest storing
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>all
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>metadata (as it will be used, i.e. with defaults
where applicable)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>in
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>a .ser file rather than just select/currently
required information
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>and
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>to stay closer to the way that information is
organized in 181.
> >>>>>>>>>>
> >>>>>>>>>>Cheers,
> >>>>>>>>>>
> >>>>>>>>>>-michael
> >>>>>>>>>>
> >>>>>>>>>>--
> >>>>>>>>>>Michael Merz
> >>>>>>>>>>mmerz@acm.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>Yeah -- if at all possible, it seems good to
avoid generating code
> >>>>>>>>>>in the WSM case just because we don't need to,
though it's a good
> >>>>>>>>>>point -- I'd forgotten controls did that.
> >>>>>>>>>>
> >>>>>>>>>>But, it could definitely work either way. A source
code file
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>seems
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>easier to deal with than a serialized object
for the obvious
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>reasons.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>It's just that the XML file seems sufficient
for today's needs...
> >>>>>>>>>>
> >>>>>>>>>>Eddie
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>On 6/8/05, Daryoush Mehrtash <dmehrtas@bea.com>
wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>In WSM we don't generate any source code,
so far ".ser" has been
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>our
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>only artifact that we generated.
> >>>>>>>>>>>=20
> >>>>>>>>>>>If we want to go the route of generating
any file, a XML file
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>might be
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>a
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>better option.
> >>>>>>>>>>>=20
> >>>>>>>>>>>daryoush
> >>>>>>>>>>>=20
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>-----Original Message-----
> >>>>>>>>>>>>From: Kyle Marvin [mailto:kylemarvin@gmail.com]
> >>>>>>>>>>>>Sent: Wednesday, June 08, 2005 2:34 PM
> >>>>>>>>>>>>To: Beehive Developers
> >>>>>>>>>>>>Subject: Re: Role of .ser file in WSM
> >>>>>>>>>>>>
> >>>>>>>>>>>>On 6/8/05, Daryoush Mehrtash <dmehrtas@bea.com>
wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>.ser file exist for one reason and
one reason only. JSR 181
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>says
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>that
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>name of a @WebParam by default is:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>Name of the parameter as it appears
in the argument list.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>The issue is that this name gets
lost after the class is
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>compiled.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>The
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>original WSM was based on Reflection
that there was no
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>Serialized
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>file.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>An alternative solution is to require
the JWS files to be
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>compiled
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>with
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>Debug option which preserves the
argument names.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>Is it needed? Well it depends on
your preferred method to get
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>argument name: require the user to
compile its JWS in debug,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>or
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>keep
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>the serialized file. Is there a third
option?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>The Controls runtime stores method parameter
names into
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>generated
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>code
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>associated with the original interface.
These names are used
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>to
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>support named argument lookup during
extensible method
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>invocation.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>=20
> >>>>>>>>>>>=20
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>--
> >>>>>>Daryoush
> >>>>>>
> >>>>>>Weblog: http://perlustration.blogspot.com/
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>--
> >>>Davanum Srinivas -http://blogs.cocoondev.org/dims/
> >>>
> >>>
> >>>
> >
> >
> >
> >
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Mime
View raw message