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 Thu, 07 Jul 2005 14:51:20 GMT
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/
>>
>>    
>>
>
>
>  
>

Mime
View raw message