Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: cxf-dev@incubator.apache.org
Subject: Re: Questions on CXF-884.  (Was Re: Graduating.....)
Date: Fri, 17 Aug 2007 18:09:37 -0400
User-Agent: KMail/1.9.7
Cc: Glen Mazza <glen.mazza@verizon.net>
References: <200708071251.56797.dkulp@apache.org>
 <1187103273.8397.1.camel@gmazza-desktop>
 <1187126581.30793.25.camel@gmazza-desktop>
In-Reply-To: <1187126581.30793.25.camel@gmazza-desktop>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200708171809.37583.dkulp@apache.org>


Glen,

On Tuesday 14 August 2007, Glen Mazza wrote:
> Thanks Dan K, CXF-884[1] has been quite helpful in understanding the
> code more.  I have a few questions so far:

Sorry I missed this.  I'm still catching up.     Go away for a few days 
and get deluged with email.   :-(

>
> 1.) In the simple.xsd[2] and jaxws.xsd[3] configuration files, which
> top-level elements need to have a "qualifyWrapperSchema" attribute
> added?  I think it is *both* server and endpoint in jaxws.xsd, and
> just server in simple.xsd, correct?  This attribute has no purpose in
> the "client" element, correct?

Hmm... good question.   It probably does have a purpose there.   If you 
are doing completely code first development (no wsdl) and you create the 
proxy client from an interface, you probably need to make sure the 
settings are the same as what you have on the server side so the 
messages it creates are what the server expects.

Actually, looking at the code now, this may be a bit more involved than I 
originally thought.    Sorry about that.   :-(     The 
getInParameterName/getOutParameterName methods may need to be updated to 
return QNames that honor the qualified/not qualified thing.     Maybe.  
I'm not really sure on that.   Maybe the stuff in the 
initializeWrappedSchema could just be updated to modify the ELEMENT_NAME 
things based on the qualified or not stuff.   That might be easiest.


> [Also, if I need to add this attribute to the endpoint element, which
> class should be modified to handle this value?  (I'm assuming the ones
> given below--ReflectionServiceFactoryBean and JaxWsServiceFactoryBean
> take care of just the server element, right?)]

I think it configures the org.apache.cxf.jaxws.EndpointImpl  directly.   
The getServer call then configures the factories and stuff.

For the client, it would be the ClientProxyFactoryBean.


> 2.) When you say below, "the JaxWsServiceFactoryBean would need to be
> changed from returning the hardcoded true/false to pulling info from
> the configs", basically, you're just saying to remove the hardcoded
> method and add a vanilla getter and setter, correct?  I believe Spring
> handles the population of this value via dependency injection.

I think so, yes. 

> 3.) AFAICT, I need to be updating java2wsdl to handle this -qualified
> property before testing this change, correct?  (I don't know how I can
> test it otherwise.)  What is a good test plan for this change?

You actually can write a system test for this.   Take the 
DocLitWrappedCodeFirstServiceImpl class and configure a spring thing to 
start it up.  Do an HttpURLConnection thing on the "?wsdl" and check to 
see if the schema is qualified or not.   No code gen stuff needed yet.


> 4.) Perhaps a digression, but ReflectionServiceFactoryBean ideally
> should be abstract, correct?  Outside of the test code, I don't see it
> directly initialized anywhere--and am uncertain if it ever should be.

It's used in the non-JAX-WS Pojo cases.    If you have classes that 
aren't JAX-WS compliant (aka: no @WebService annotation), you can 
create/start services with just the "simple" frontend.   The 
ReflectionServiceFactoryBean provides sensible defaults for everything.  

If this seems like a bit much, I can probably go through some JIRA's and 
find other things if you want.    Other than that, feel free to ask more 
questions.    Your questions above were great.  

Thanks!
Dan


> Thanks,
> Glen
>
> [1] https://issues.apache.org/jira/browse/CXF-884
> [2] http://tinyurl.com/2jlqsm
> [3] http://tinyurl.com/33f6j8
>
> Am Dienstag, den 14.08.2007, 10:54 -0400 schrieb Glen Mazza:
> > OK, I'm back and looking at this issue now...
> >
> > Glen
> >
> > Am Donnerstag, den 09.08.2007, 10:45 -0400 schrieb Daniel Kulp:
> > > Glen,
> > >
> > > On Wednesday 08 August 2007 21:19, Glen Mazza wrote:
> > > > Am Dienstag, den 07.08.2007, 21:49 -0400 schrieb Daniel Kulp:
> > > > > So, the question becomes: what can we do to help others get
> > > > > more involved in the CXF code?   That question is open to the
> > > > > non-commiters as well. What can we do to help you?
> > > >
> > > > Personally speaking, I would very much like to move beyond my
> > > > usual grammar checking and coding suggestions.  If people know
> > > > of simpler tasks that are rather independent of other people's
> > > > work, things I can do to start moving up the next few steps,
> > > > emailing me privately or on this list would be appreciated.  I
> > > > plan on spending more time looking at the JIRA's myself next
> > > > week.
> > >
> > > Just a thought, but CXF-884, while not "trivial", is not very hard
> > > either.   The runtime itself already supports it, it's just a
> > > matter of wiring it into the spring config and there should be a
> > > bunch of examples of that.
> > >
> > > Basically, in the ReflectionServiceFactoryBean (simple frontend),
> > > line 500, the method:
> > >     protected boolean qualifyWrapperSchema() {
> > >         return true;
> > >     }
> > > and the over-ridden method in the JaxWsServiceFactoryBean would
> > > need to be changed from return the hardcoded true/false to pulling
> > > info from the configs.    A svn log on the jaxws.xsd whould
> > > probably yield a couple past commits that showed how to add config
> > > entries.   One of those could be used as a model.   (this should
> > > be added to the "simple.xsd" processing as well)
> > >
> > > The next step, once that is working, would be to add a
> > > "-qualified=true" flag to the java2wsdl tool.    :-)
> > >
> > >
> > > Anyway, just throwing that out as an idea if you're interested.  
> > > The fact that the JAX-WS TCK pretty much requires we use
> > > unqualified schemas really kind of sucks.  I'm not sure if that
> > > interests you or not.
> > >
> > > Once we switch to working on JAX-WS 2.1, more stuff should pop up
> > > as well.   Theres a bunch of commented out methods in the jaxws
> > > frontend that will need implementations for 2.1.      (grep JAX-WS
> > > 2.1)   Even going through the 2.1 changelog and grabbing anything
> > > there is a start.


-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog