beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <richf...@gmail.com>
Subject Re: Role of .ser file in WSM
Date Wed, 06 Jul 2005 17:41:59 GMT
+1 from me too... it's the way the Page Flow annotation processor 
communicates this kind of stuff to the runtime, too, FWIW.

Rich

Davanum Srinivas wrote:

>+1 to "XML or a generated BeanInfo".
>
>-- dims
>
>On 7/6/05, Eddie ONeil <ekoneil@gmail.com> wrote:
>  
>
>>  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
>>>>        
>>>>
>
>
>  
>

Mime
View raw message