beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryoush Mehrtash <dmehrt...@gmail.com>
Subject Re: Role of .ser file in WSM
Date Thu, 07 Jul 2005 17:09:21 GMT
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/
> >
> 


-- 
Daryoush

Weblog:  http://perlustration.blogspot.com/
Mime
View raw message