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 Fri, 08 Jul 2005 06:16:01 GMT
Thanks for the info in this and the previous response.  For my part (and 
at this point I'm really just an observer of the WSM codebase), I would 
still go with an XML schema that matches the model you build.  WSDL is 
standard, but it seems like it's a standard for expressing a public 
interface, not a standard for this particular use.

Rich

Daryoush Mehrtash wrote:

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

Mime
View raw message