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:[EMAIL PROTECTED]
Sent: Wednesday, July 06, 2005 10:13 AM
To: Beehive Developers; [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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
