Graduating.....

[dkulp]

In the July board report (see http://wiki.apache.org/incubator/July2007),
one of the comments presented directly in the summary was:
"CXF should probably be starting to push for graduation, too, except for
diversity being a concern"

Since the IPMC seems to think we're getting close, I definitely think we
should start seriously talking about it.


My thoughts:
In the last year, the CXF community has made huge milestones towards
acting like an Apache Community and following Apache guidelines.    
We've successfully released two milestone releases and one full release,
and a patch release is pending.   In all cases, we've done as much as
possible of the work design work on this list, in the JIRA, and on the
Wiki.  

We've tried hard to to respond to our users to make them successful with
CXF.   Several of them have submitted back patches and we've received a
TON of good suggestions and reports.   2.0.1 is a testament to how well
we were able to do that.


The main concern, of course, is diversity.   There are a bunch of IONA
folks, however, we do meet the criteria of 3 or more independent
commiters with IBM represented, obviously Envoi Solutions,  a couple of
independents.   We also have a couple folks that have been submitting
patches and are getting "close".       That all said, despite having a
lot of IONA folks, I think we've done a good job keeping the development
open and in the community.   That's the more important thing.


Anyway, how do the rest of you feel?    Are we there?

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

[jgenender]

I think we are there.  This community seems very healthy to me.  The
lists are active, you have decent representation, and the inter-project
communication with other Apache projects is excellent.  I would love to
see CXF graduated.

Jeff

Daniel Kulp wrote:

> In the July board report (see http://wiki.apache.org/incubator/July2007),
> one of the comments presented directly in the summary was:
> "CXF should probably be starting to push for graduation, too, except for
> diversity being a concern"
>
> Since the IPMC seems to think we're getting close, I definitely think we
> should start seriously talking about it.
>
>
> My thoughts:
> In the last year, the CXF community has made huge milestones towards
> acting like an Apache Community and following Apache guidelines.    
> We've successfully released two milestone releases and one full release,
> and a patch release is pending.   In all cases, we've done as much as
> possible of the work design work on this list, in the JIRA, and on the
> Wiki.  
>
> We've tried hard to to respond to our users to make them successful with
> CXF.   Several of them have submitted back patches and we've received a
> TON of good suggestions and reports.   2.0.1 is a testament to how well
> we were able to do that.
>
>
> The main concern, of course, is diversity.   There are a bunch of IONA
> folks, however, we do meet the criteria of 3 or more independent
> commiters with IBM represented, obviously Envoi Solutions,  a couple of
> independents.   We also have a couple folks that have been submitting
> patches and are getting "close".       That all said, despite having a
> lot of IONA folks, I think we've done a good job keeping the development
> open and in the community.   That's the more important thing.
>
>
> Anyway, how do the rest of you feel?    Are we there?
>

[Jim Jagielski]

On Aug 7, 2007, at 12:51 PM, Daniel Kulp wrote:

>
> The main concern, of course, is diversity.   There are a bunch of IONA
> folks, however, we do meet the criteria of 3 or more independent
> commiters with IBM represented, obviously Envoi Solutions,  a  
> couple of
> independents.   We also have a couple folks that have been submitting
> patches and are getting "close".       That all said, despite having a
> lot of IONA folks, I think we've done a good job keeping the  
> development
> open and in the community.   That's the more important thing.
>

Keeping the development open and in community is all good.
But, imo, as mentor, the diversity simply is not there
yet. My general feeling is that if IONA were to drop
its interest in CXF, many people currently involved
in CXF would go away.

I see progress being made in increasing diversity,
but CXF is not there yet.

[dkulp]

Jim,

I really appreciate the candid response.   Thanks for that.

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?

I was sitting around trying to brainstorm with some folks this afternoon
and thought of one idea (I'll give Debbie credit for this):  is there a
way to mark tasks in Jira with an difficulty level?    If we could mark
some tasks as "Easy" as opposed to "Yea Right", that could make it much
easier for a new person to find something to get their feet wet.  Jim:
since you're probably the only one with Jira admin access, is that
something that can be done?  Add a "Difficulty" or "Complexity"
attribute with levels like "Unknown, Trivial, Easy, Medium, Difficult,
Yea Right"?   (I know VERY little about what Jira can do.)   If we
decide this is a good idea, is this something we need to file through
Infrastructure?

Anyway, to all the non-commiters: I highly encourage you to reach out to
the developers, ask questions, dig into the code, etc...  If you want
some pointers or need help finding where the code that does something
is, please ask.  

Thanks!
Dan



On Tuesday 07 August 2007 17:00, Jim Jagielski wrote:

> On Aug 7, 2007, at 12:51 PM, Daniel Kulp wrote:
> > The main concern, of course, is diversity.   There are a bunch of
> > IONA folks, however, we do meet the criteria of 3 or more
> > independent commiters with IBM represented, obviously Envoi
> > Solutions,  a couple of
> > independents.   We also have a couple folks that have been
> > submitting patches and are getting "close".       That all said,
> > despite having a lot of IONA folks, I think we've done a good job
> > keeping the development
> > open and in the community.   That's the more important thing.
>
> Keeping the development open and in community is all good.
> But, imo, as mentor, the diversity simply is not there
> yet. My general feeling is that if IONA were to drop
> its interest in CXF, many people currently involved
> in CXF would go away.
>
> I see progress being made in increasing diversity,
> but CXF is not there yet.

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

[Liu, Jervis]

I wonder if we can categorize CXF developers (or potential CXF developers) into following types:

1.      Developers who were sent by their employers to work on CXF.
2.      Developers who is the current user of CXF. They run into bugs or missing features in CXF which may block their own project. Instead of sitting back and waiting, they would like to get these bugs/features done by themselves.
3.      Developers who is generally interested in contributing to CXF, but different from #2, they do not have any thing specific/immediate to start with.

I wouldn't worry about type #1 users at all, they shall have initiative strong enough that if there is anything coming out of their way, they will shout out. For #2, I believe we've been doing good so far, through mailing list, JIRAs, IRC etc. Anything we can improve to help them getting involved more easily?

For the #3 type of users, the story is a bit different. This is the area I believe we should put more care on. As this type of potential developers don't have any specific areas to start with in the mind, they often have problems to find an appropriate task as starting point. Of course they can still watch the commit emails to understand who is changing what code, they can walk through JIRAs to know what stories are available, but this doesn't help them too much to draw the big picture. I.e., what are the main stores CXF community is working with, what are the schedules and status of these stories, what has been finished, what left, who is working on what. This kind o information is crucial to a new person in order to know what areas he/she can start with, what stories he/she can pick up which is relatively independent from other stories and he/she also wants to make sure the story is not on others immediate to-do-list to avoid conflicts.

Any thoughts on this? One of my comments is we need to make a better use of Jira. The description in Jira has to be more specific and in details. For example, "Make handler chain working" would not work. Secondly the ownership of Jira story's needs to be clear and precise. What strikes a new person mostly is how to find a Jira story that is "available". What we often see is there are tons JIRAs assigned under one developer's name, which are not intended to work on immediately. On the other hand, a JIRA without assignee does not necessarily mean one can pick up this story without conflicting with others, we often see the commit has been done without corresponding Jira being started or even assigned. Thirdly, an initial evaluation given by a senior committer on the difficulty and priority of the story would be helpful. For example, as Dan Kulp suggested, mark the start as "easy/intermediate/hard" etc. The priority normally is hard to get it right from a new person, as this sometimes involves in the historical info of that features/bug, who is requesting this fix etc. The correct use of priority in Jira would be helpful, a new person probably want to play with some low priority/non-urgent issues as a start.


Cheers,
Jervis

> -----Original Message-----
> From: Daniel Kulp [ mailto:dkulp@...]
> Sent: 2007?8?8? 9:49
> To: cxf-dev@...
> Cc: Jim Jagielski
> Subject: Re: Graduating.....
>
>
>
> Jim,
>
> I really appreciate the candid response.   Thanks for that.
>
> 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?
>
> I was sitting around trying to brainstorm with some folks
> this afternoon
> and thought of one idea (I'll give Debbie credit for this):
> is there a
> way to mark tasks in Jira with an difficulty level?    If we
> could mark
> some tasks as "Easy" as opposed to "Yea Right", that could
> make it much
> easier for a new person to find something to get their feet
> wet.  Jim:
> since you're probably the only one with Jira admin access, is that
> something that can be done?  Add a "Difficulty" or "Complexity"
> attribute with levels like "Unknown, Trivial, Easy, Medium,
> Difficult,
> Yea Right"?   (I know VERY little about what Jira can do.)   If we
> decide this is a good idea, is this something we need to file through
> Infrastructure?
>
> Anyway, to all the non-commiters: I highly encourage you to
> reach out to
> the developers, ask questions, dig into the code, etc...  If you want
> some pointers or need help finding where the code that does something
> is, please ask.  
>
> Thanks!
> Dan
>
>
>
> On Tuesday 07 August 2007 17:00, Jim Jagielski wrote:
> > On Aug 7, 2007, at 12:51 PM, Daniel Kulp wrote:
> > > The main concern, of course, is diversity.   There are a bunch of
> > > IONA folks, however, we do meet the criteria of 3 or more
> > > independent commiters with IBM represented, obviously Envoi
> > > Solutions,  a couple of
> > > independents.   We also have a couple folks that have been
> > > submitting patches and are getting "close".       That all said,
> > > despite having a lot of IONA folks, I think we've done a good job
> > > keeping the development
> > > open and in the community.   That's the more important thing.
> >
> > Keeping the development open and in community is all good.
> > But, imo, as mentor, the diversity simply is not there
> > yet. My general feeling is that if IONA were to drop
> > its interest in CXF, many people currently involved
> > in CXF would go away.
> >
> > I see progress being made in increasing diversity,
> > but CXF is not there yet.
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727    C: 508-380-7194
> daniel.kulp@...
> http://www.dankulp.com/blog
>

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

[Glen Mazza-2]

Am Dienstag, den 07.08.2007, 21:49 -0400 schrieb Daniel Kulp:

> Jim,
>
> I really appreciate the candid response.   Thanks for that.
>
> 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.

(BTW, I will out of town Friday thru Monday, not returning until Tuesday
morning Wash DC time, so after tomorrow will not be able to respond to
anything until then.)

> I was sitting around trying to brainstorm with some folks this afternoon
> and thought of one idea (I'll give Debbie credit for this):  is there a
> way to mark tasks in Jira with an difficulty level?    If we could mark
> some tasks as "Easy" as opposed to "Yea Right", that could make it much
> easier for a new person to find something to get their feet wet.  Jim:
> since you're probably the only one with Jira admin access, is that
> something that can be done?  Add a "Difficulty" or "Complexity"
> attribute with levels like "Unknown, Trivial, Easy, Medium, Difficult,
> Yea Right"?   (I know VERY little about what Jira can do.)   If we
> decide this is a good idea, is this something we need to file through
> Infrastructure?

Well, it might not look good for a user to be submitting a patch, and
for us to declare it "difficult" or "complex" or whatever.  I don't see
this as that important anyway.  As contributors start looking around
JIRA, and also study more, they can start to figure out more of where
they can be of help.

Also, frequently, it is not just "easy" or "hard"--it is also
"interesting" or "applicable to what I want to focus on", etc.

Regards,
Glen

[dkulp]

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@...
http://www.dankulp.com/blog

[Balaji Ravi]

The developers will not come to cxf, it is with the collaboration with
different projects that we can invite other developers.

We need to look externally to other projects as well as internally within
our project.

External:
What are the projects currently using cxf? Can we ask the developers in this
project to participate in the design aspect of cxf? Are there more projects
that are potential users of cxf?

Internal:
Can we publish to other projects some of the feature list that we want to
finish with cxf? Can we go actively look at the features of other projects?
Maybe we can use the features developed in other projects and integrate with
cxf better yet ask other developers to contribute in that way.

It is not just the JIRA that we should focus on. We should cross-pollinate
design ideas with other projects.

- Balaji

On 8/8/07, Glen Mazza <glen.mazza@...> wrote:

>
> Am Dienstag, den 07.08.2007, 21:49 -0400 schrieb Daniel Kulp:
>
> > Jim,
> >
> > I really appreciate the candid response.   Thanks for that.
> >
> > 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.
>
> (BTW, I will out of town Friday thru Monday, not returning until Tuesday
> morning Wash DC time, so after tomorrow will not be able to respond to
> anything until then.)
>
> > I was sitting around trying to brainstorm with some folks this afternoon
> > and thought of one idea (I'll give Debbie credit for this):  is there a
> > way to mark tasks in Jira with an difficulty level?    If we could mark
> > some tasks as "Easy" as opposed to "Yea Right", that could make it much
> > easier for a new person to find something to get their feet wet.  Jim:
> > since you're probably the only one with Jira admin access, is that
> > something that can be done?  Add a "Difficulty" or "Complexity"
> > attribute with levels like "Unknown, Trivial, Easy, Medium, Difficult,
> > Yea Right"?   (I know VERY little about what Jira can do.)   If we
> > decide this is a good idea, is this something we need to file through
> > Infrastructure?
>
> Well, it might not look good for a user to be submitting a patch, and
> for us to declare it "difficult" or "complex" or whatever.  I don't see
> this as that important anyway.  As contributors start looking around
> JIRA, and also study more, they can start to figure out more of where
> they can be of help.
>
> Also, frequently, it is not just "easy" or "hard"--it is also
> "interesting" or "applicable to what I want to focus on", etc.
>
> Regards,
> Glen
>
>
>
>

[Jim Jagielski]

I also chatted with Dan about advertising better the various
ways to *test* CXF, even if you aren't *using* it. There are
many developers who like to plug holes, improve efficiency
and even add features, even if they don't really use the
codebase all that much. But for that to happen, there
needs to be good, active and well-documented testing
options for them (they won't see that they broke stuff since
they don't run the code, at least not significantly)...

On Aug 10, 2007, at 10:01 AM, Balaji Ravi wrote:

> The developers will not come to cxf, it is with the collaboration with
> different projects that we can invite other developers.
>
> We need to look externally to other projects as well as internally  
> within
> our project.
>
> External:
> What are the projects currently using cxf? Can we ask the  
> developers in this
> project to participate in the design aspect of cxf? Are there more  
> projects
> that are potential users of cxf?
>
> Internal:
> Can we publish to other projects some of the feature list that we  
> want to
> finish with cxf? Can we go actively look at the features of other  
> projects?
> Maybe we can use the features developed in other projects and  
> integrate with
> cxf better yet ask other developers to contribute in that way.
>
> It is not just the JIRA that we should focus on. We should cross-
> pollinate
> design ideas with other projects.
>
> - Balaji
>
> On 8/8/07, Glen Mazza <glen.mazza@...> wrote:
>>
>> Am Dienstag, den 07.08.2007, 21:49 -0400 schrieb Daniel Kulp:
>>
>>> Jim,
>>>
>>> I really appreciate the candid response.   Thanks for that.
>>>
>>> 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.
>>
>> (BTW, I will out of town Friday thru Monday, not returning until  
>> Tuesday
>> morning Wash DC time, so after tomorrow will not be able to  
>> respond to
>> anything until then.)
>>
>>> I was sitting around trying to brainstorm with some folks this  
>>> afternoon
>>> and thought of one idea (I'll give Debbie credit for this):  is  
>>> there a
>>> way to mark tasks in Jira with an difficulty level?    If we  
>>> could mark
>>> some tasks as "Easy" as opposed to "Yea Right", that could make  
>>> it much
>>> easier for a new person to find something to get their feet wet.  
>>> Jim:
>>> since you're probably the only one with Jira admin access, is that
>>> something that can be done?  Add a "Difficulty" or "Complexity"
>>> attribute with levels like "Unknown, Trivial, Easy, Medium,  
>>> Difficult,
>>> Yea Right"?   (I know VERY little about what Jira can do.)   If we
>>> decide this is a good idea, is this something we need to file  
>>> through
>>> Infrastructure?
>>
>> Well, it might not look good for a user to be submitting a patch, and
>> for us to declare it "difficult" or "complex" or whatever.  I  
>> don't see
>> this as that important anyway.  As contributors start looking around
>> JIRA, and also study more, they can start to figure out more of where
>> they can be of help.
>>
>> Also, frequently, it is not just "easy" or "hard"--it is also
>> "interesting" or "applicable to what I want to focus on", etc.
>>
>> Regards,
>> Glen
>>
>>
>>
>>

[dkulp]

From my discussion with Jim, I think the CXF developers kind of take our
Maven for granted in some senses.   It's setup pretty well (caveat: I'm
very biased) so you pretty much just type "mvn" and it does the building
and testing all at once.   There are various flags to turn off things,
but the default is to do as much testing as it can.

Most likely, the page at:
http://cwiki.apache.org/confluence/display/CXF/Building
and the page at:
http://cwiki.apache.org/confluence/display/CXF/Getting+Involved

need some updating to make a lot of this more clear.   Running mvn runs
checkstyle, PMD, a bunch of unit tests, and a bunch of system tests
(some may say too many considering how long it takes to build).   If
successful, you should be fairly confident that nothing is broken.

That said, the pages also need some additional information such as the
code style guidelines (we use checkstyle/pmd to enforce things, but it's
not really documented), how to add unit tests,  some docs around the
Client/Server test framework for the system tests, etc....  

Anyway, I'm off on vacation till late next week so won't be able to spend
time on them till then.  I'll log in monday at some point to publish the
release providing there are no -1 votes or new issues raised by that
point, but I won't be doing any real work.

Dan



On Friday 10 August 2007 10:52, Jim Jagielski wrote:

> I also chatted with Dan about advertising better the various
> ways to *test* CXF, even if you aren't *using* it. There are
> many developers who like to plug holes, improve efficiency
> and even add features, even if they don't really use the
> codebase all that much. But for that to happen, there
> needs to be good, active and well-documented testing
> options for them (they won't see that they broke stuff since
> they don't run the code, at least not significantly)...
>
> On Aug 10, 2007, at 10:01 AM, Balaji Ravi wrote:
> > The developers will not come to cxf, it is with the collaboration
> > with different projects that we can invite other developers.
> >
> > We need to look externally to other projects as well as internally
> > within
> > our project.
> >
> > External:
> > What are the projects currently using cxf? Can we ask the
> > developers in this
> > project to participate in the design aspect of cxf? Are there more
> > projects
> > that are potential users of cxf?
> >
> > Internal:
> > Can we publish to other projects some of the feature list that we
> > want to
> > finish with cxf? Can we go actively look at the features of other
> > projects?
> > Maybe we can use the features developed in other projects and
> > integrate with
> > cxf better yet ask other developers to contribute in that way.
> >
> > It is not just the JIRA that we should focus on. We should cross-
> > pollinate
> > design ideas with other projects.
> >
> > - Balaji
> >
> > On 8/8/07, Glen Mazza <glen.mazza@...> wrote:
> >> Am Dienstag, den 07.08.2007, 21:49 -0400 schrieb Daniel Kulp:
> >>> Jim,
> >>>
> >>> I really appreciate the candid response.   Thanks for that.
> >>>
> >>> 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.
> >>
> >> (BTW, I will out of town Friday thru Monday, not returning until
> >> Tuesday
> >> morning Wash DC time, so after tomorrow will not be able to
> >> respond to
> >> anything until then.)
> >>
> >>> I was sitting around trying to brainstorm with some folks this
> >>> afternoon
> >>> and thought of one idea (I'll give Debbie credit for this):  is
> >>> there a
> >>> way to mark tasks in Jira with an difficulty level?    If we
> >>> could mark
> >>> some tasks as "Easy" as opposed to "Yea Right", that could make
> >>> it much
> >>> easier for a new person to find something to get their feet wet.
> >>> Jim:
> >>> since you're probably the only one with Jira admin access, is that
> >>> something that can be done?  Add a "Difficulty" or "Complexity"
> >>> attribute with levels like "Unknown, Trivial, Easy, Medium,
> >>> Difficult,
> >>> Yea Right"?   (I know VERY little about what Jira can do.)   If we
> >>> decide this is a good idea, is this something we need to file
> >>> through
> >>> Infrastructure?
> >>
> >> Well, it might not look good for a user to be submitting a patch,
> >> and for us to declare it "difficult" or "complex" or whatever.  I
> >> don't see
> >> this as that important anyway.  As contributors start looking
> >> around JIRA, and also study more, they can start to figure out more
> >> of where they can be of help.
> >>
> >> Also, frequently, it is not just "easy" or "hard"--it is also
> >> "interesting" or "applicable to what I want to focus on", etc.
> >>
> >> Regards,
> >> Glen

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

[Glen Mazza-2]

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

[Glen Mazza-2]

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

[Glen Mazza-2]

According to another email, Dan K will be out on vacation for a few more
days.  I'm available to look at other issues until he returns to answer
my questions on this one.

Glen

Am Dienstag, den 14.08.2007, 17:23 -0400 schrieb Glen Mazza:

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

[Bozhong Lin-2]

Hi Glen,

Following JIRA issues might be of your interest:

https://issues.apache.org/jira/browse/CXF-908
https://issues.apache.org/jira/browse/CXF-874
https://issues.apache.org/jira/browse/CXF-896
https://issues.apache.org/jira/browse/CXF-826

Regards,
Bo

Glen Mazza wrote:

> According to another email, Dan K will be out on vacation for a few more
> days.  I'm available to look at other issues until he returns to answer
> my questions on this one.
>
> Glen
>
> Am Dienstag, den 14.08.2007, 17:23 -0400 schrieb Glen Mazza:
>  
>> 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.
>>>>
>>>>
>>>>        

[Glen Mazza-2]

OK, I'm also looking at CXF-908 right now.

Thanks,
Glen

Am Donnerstag, den 16.08.2007, 08:57 +0800 schrieb Bozhong Lin:

> Hi Glen,
>
> Following JIRA issues might be of your interest:
>
> https://issues.apache.org/jira/browse/CXF-908
> https://issues.apache.org/jira/browse/CXF-874
> https://issues.apache.org/jira/browse/CXF-896
> https://issues.apache.org/jira/browse/CXF-826
>
> Regards,
> Bo
>
> Glen Mazza wrote:
> > According to another email, Dan K will be out on vacation for a few more
> > days.  I'm available to look at other issues until he returns to answer
> > my questions on this one.
> >
> > Glen
> >
> > Am Dienstag, den 14.08.2007, 17:23 -0400 schrieb Glen Mazza:
> >  
> >> 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.
> >>>>
> >>>>
> >>>>        

[dkulp]

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@...
http://www.dankulp.com/blog

[Glen Mazza-2]

Am Freitag, den 17.08.2007, 18:09 -0400 schrieb Daniel Kulp:

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

<snip/>

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

Right now, I'd rather a more veteran team member handle this, especially
since the proper solution is somewhat ambiguous at this stage, and the
fact that this change cascades to other parts of the code, requiring
testing beyond my current grasp of the system.  (If nobody else tackles
this however, and as my knowledge of the system increases, perhaps I can
take a second look at this change in the future.)

There are two other issues Bozhong had recommended for me (the other two
are out pending for feedback from the reporter), plus reasonable level
tasks you can spot would be appreciated.  I will be looking myself.

Thanks,
Glen