Mailing-List: contact beehive-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <beehive-dev@incubator.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <42CCAC10.5050701@bea.com>
Date: Wed, 06 Jul 2005 22:14:08 -0600
From: Richard Feit <richard.feit@bea.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Beehive Developers <beehive-dev@incubator.apache.org>
Subject: Re: Role of .ser file in WSM
References: <4B2B4C417991364996F035E1EE39E2E1027C26F2@uskiex01.amer.bea.com>
In-Reply-To: <4B2B4C417991364996F035E1EE39E2E1027C26F2@uskiex01.amer.bea.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>>>>        
>>>>
>
>
>
>  
>