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 Thu, 07 Jul 2005 15:04:03 GMT
-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