Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of glen.mazza@verizon.net
 designates 206.46.252.44 as permitted sender)
Date: Tue, 14 Aug 2007 17:23:01 -0400
From: Glen Mazza <glen.mazza@verizon.net>
Subject: Questions on CXF-884.  (Was Re: Graduating.....)
In-reply-to: <1187103273.8397.1.camel@gmazza-desktop>
To: cxf-dev@incubator.apache.org
Message-id: <1187126581.30793.25.camel@gmazza-desktop>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7bit
References: <200708071251.56797.dkulp@apache.org>
	<200708072149.01876.dkulp@apache.org>
	<1186622346.7389.49.camel@gmazza-desktop>
	<200708091045.33819.dkulp@apache.org>
	<1187103273.8397.1.camel@gmazza-desktop>

Thanks Dan K, CXF-884[1] has been quite helpful in understanding the
code more.  I have a few questions so far:

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?

[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?)]

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.

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?

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.

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