beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie ONeil <ekon...@gmail.com>
Subject Re: Role of .ser file in WSM
Date Thu, 07 Jul 2005 15:38:59 GMT
  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.

Eddie



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/
>
Mime
View raw message