Tracking trunk commits blocked wrt to the 2.0.x_fixes branch
Folks, Does anyone know if svnmerge.py can be used to report on the commits to trunk that have been "blocked" wrt to merging out to the 2.0.x_fixes branch? Its sortta like a retrospective "avail" option that I'm after, i.e. gimme all the commits that were available for merging, but were selected for blocking. The idea would be to get a definitive list of potentially backward-incompatible changes to 2.1 that may cause issues when upgrading from 2.0.x. Cheers, Eoghan IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Tracking trunk commits blocked wrt to the 2.0.x_fixes branch
Hi Eoghan, I guess what you want is "svnmerge.py avail -B", which will showthe blocked revision list. Regards Freeman Eoghan Glynn wrote: Folks, Does anyone know if svnmerge.py can be used to report on the commits to trunk that have been "blocked" wrt to merging out to the 2.0.x_fixes branch? Its sortta like a retrospective "avail" option that I'm after, i.e. gimme all the commits that were available for merging, but were selected for blocking. The idea would be to get a definitive list of potentially backward-incompatible changes to 2.1 that may cause issues when upgrading from 2.0.x. Cheers, Eoghan IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Tracking trunk commits blocked wrt to the 2.0.x_fixes branch
It's all stored as properties on the directory. Thus: svn propget svnmerge-blocked . would give you the list of revisions. THAT said, the stuff gnodet, Freeman, and Willem have merged without using svnmerge.py may appear in that list. On a related note: I'm not using subversion 1.5 and the Apache server is using subversion 1.5. Thus, we probably could stop using svnmerge.py and flip over to the tracking support in 1.5. However, that would require all the mergers to use subversion 1.5 which I'm not sure if everyone is ready to do or not. Dan On Jul 17, 2008, at 8:54 AM, Eoghan Glynn wrote: Folks, Does anyone know if svnmerge.py can be used to report on the commits to trunk that have been "blocked" wrt to merging out to the 2.0.x_fixes branch? Its sortta like a retrospective "avail" option that I'm after, i.e. gimme all the commits that were available for merging, but were selected for blocking. The idea would be to get a definitive list of potentially backward- incompatible changes to 2.1 that may cause issues when upgrading from 2.0.x. Cheers, Eoghan IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Tracking trunk commits blocked wrt to the 2.0.x_fixes branch
Thanks Dan & Freeman, Both suggested methods give exactly the same results. A total of well over blocked 500 commits ... ouch, that's a lot to go thru manually. BTW what's general feeling on the completeness of the 2.1 Migration Guide[1] wrt capturing potential compatibility issues? Cheers, Eoghan [1] http://cxf.apache.org/21-migration-guide.html Daniel Kulp wrote: It's all stored as properties on the directory. Thus: svn propget svnmerge-blocked . would give you the list of revisions. THAT said, the stuff gnodet, Freeman, and Willem have merged without using svnmerge.py may appear in that list. On a related note: I'm not using subversion 1.5 and the Apache server is using subversion 1.5. Thus, we probably could stop using svnmerge.py and flip over to the tracking support in 1.5. However, that would require all the mergers to use subversion 1.5 which I'm not sure if everyone is ready to do or not. Dan On Jul 17, 2008, at 8:54 AM, Eoghan Glynn wrote: Folks, Does anyone know if svnmerge.py can be used to report on the commits to trunk that have been "blocked" wrt to merging out to the 2.0.x_fixes branch? Its sortta like a retrospective "avail" option that I'm after, i.e. gimme all the commits that were available for merging, but were selected for blocking. The idea would be to get a definitive list of potentially backward-incompatible changes to 2.1 that may cause issues when upgrading from 2.0.x. Cheers, Eoghan IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
A CXF 2.1 CPU consumption question
Hello all I apologise for cross posting, but I was not getting much traction in the users-list and I do think that my question is worth asking and answering. Here is what I have so far: Hello Daniel I had another profiling session and this time saved the snapshot so we can have a fixed point of reference. I am using JProfiler with CPU measurement set to "Elapsed time", which according to the documentation should ignore time spent while waiting or blocking. This time I have: 74.1% PhaseInterceptorChain.doIntercept() 30.5% OutgoingChainInterceptor.handleMessage 21.3% ReadHeadersInterceptor.handleMessage 7.3% DocLiteralInInterceptor.handleMessage 5.3% ServiceInvokerInterceptor.handleMessage Regarding ReadHeadersInterceptor.handleMessage. See image at: http://drop.io/pul3us5/asset/readheadersinterceptor (The stack trace was re-rooted for display purposes to and that is why it is at 100%) It seems that most of the time is spent in xerces and wstx but what is it they do? Regarding DocLiteralInInterceptor.handleMessage. See image at: http://drop.io/pul3us5/asset/docliteralininterceptor Most work seems to be JAXB related. Regarding ServiceInvokerInterceptor.handleMessage. Here the actual business logic is invoked. This reflective invocation takes up 3% of the total of ServiceInvokerInterceptor.handleMessage. Not sure what the rest is. Snapshot image is here: http://drop.io/pul3us5/asset/serviceinvokerinterceptor Regarding OutgoingChainInterceptor.handleMessage. An image is here: http://drop.io/pul3us5/asset/outgoingchaininterceptor Would you say that 30% of the CPU is about the right slice size of the cake for CXF to take? Thanks -- david -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: 15 July 2008 23:16 To: [EMAIL PROTECTED] Subject: Re: A CXF 2.1 CPU consumption question On Jul 11, 2008, at 10:18 AM, David Soroko wrote: > > > Hi all > > We are now in profiling stages of some CXF 2.1 based web services. In > all our services we observe that most of the CPU time is not > consumed by > the service logic itself but by CXF. I attach a picture (worth 1000 > words) of a JProfiler snapshot. In the snapshot we see the > PhaseInterceptorChain.doIntercept() taking 78.4% of the CPU which is > fine as this includes the eventual service logic execution. What > happens > next is a bit strange, here is the ASCII art rendering: > > 78.4% PhaseInterceptorChain.doIntercept() > 26.4% OutgoingChainInterceptor.handleMessage This makes complete sense. The OutgoingChainInterceptor sets up the outgoing chain and invokes it. Thus, this number would include ALL of the work required to send the response including the JAXB marshalling, flushing the streams, etc > > 20.0% ServiceInvokerInterceptor.handleMessage > 16.9% ReadHeadersInterceptor.handleMessage > > > The call to ServiceInvokerInterceptor.handleMessage() ends up calling > the actual service logic which takes about 5% of the CPU time so, the > extra 15% penalty seems to excessive, That's really not good. Any chance you can dig into that one a bit furthur? > what's even more worrying are the > other two handleMessage calls (OutgoingChainInterceptor and > ReadHeadersInterceptor) that gobble up together more then 40% of the > CPU. ReadHeadersInteceptor is the first interceptor that actual reads stuff off the wire. Question: is it actually measuring CPU usage or just a "nanosecond count" or something. (raw time) Normally, this is where it would pause waiting for the message to come off the network. Everytime I see a large number hear, it's not really using the CPU, it's actually down in the ServletInputStream waiting for data from the socket. Dan > Note that we have no custom interceptors defined, our configuration > looks like this: > > > > > > > > > address="/SomeService" >implementor="#someService" > > implementorClass > ="com.betfair.services.someservice.SomeServiceServiceImp > l"> > > > > Is this behaviour expected in a properly configured system? > > Thanks > > -- david > > In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
Re: A CXF 2.1 CPU consumption question
David, the very same developers are on both lists. Best to follow up on the User's list to keep the archives clean for future searching. Glen David Soroko wrote: > > Hello all > > > > I apologise for cross posting, but I was not getting much traction in > the users-list and I do think that my question is worth asking and > answering. Here is what I have so far: > > > > > > > > > > > > > > Hello Daniel > > > > I had another profiling session and this time saved the snapshot so we > can have a fixed point of reference. I am using JProfiler with CPU > measurement set to "Elapsed time", which according to the documentation > should ignore time spent while waiting or blocking. > > > > This time I have: > > > > 74.1% PhaseInterceptorChain.doIntercept() > > 30.5% OutgoingChainInterceptor.handleMessage > > 21.3% ReadHeadersInterceptor.handleMessage > > 7.3% DocLiteralInInterceptor.handleMessage > > 5.3% ServiceInvokerInterceptor.handleMessage > > > > Regarding ReadHeadersInterceptor.handleMessage. See image at: > http://drop.io/pul3us5/asset/readheadersinterceptor > > > > (The stack trace was re-rooted for display purposes to and that is why > it is at 100%) > > > > It seems that most of the time is spent in xerces and wstx but what is > it they do? > > > > > > Regarding DocLiteralInInterceptor.handleMessage. See image at: > http://drop.io/pul3us5/asset/docliteralininterceptor > > > > Most work seems to be JAXB related. > > > > > > > > Regarding ServiceInvokerInterceptor.handleMessage. Here the actual > business logic is invoked. This reflective invocation takes up 3% of the > total of ServiceInvokerInterceptor.handleMessage. Not sure what the rest > is. Snapshot image is here: > > http://drop.io/pul3us5/asset/serviceinvokerinterceptor > > > > > > Regarding OutgoingChainInterceptor.handleMessage. An image is here: > http://drop.io/pul3us5/asset/outgoingchaininterceptor > > > > Would you say that 30% of the CPU is about the right slice size of the > cake for CXF to take? > > > > > > Thanks > > > > -- david > > > > > > > > -Original Message- > > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > > Sent: 15 July 2008 23:16 > > To: [EMAIL PROTECTED] > > Subject: Re: A CXF 2.1 CPU consumption question > > > > > > > > > > On Jul 11, 2008, at 10:18 AM, David Soroko wrote: > > > >> > >> > >> Hi all > >> > >> We are now in profiling stages of some CXF 2.1 based web services. In > >> all our services we observe that most of the CPU time is not > >> consumed by > >> the service logic itself but by CXF. I attach a picture (worth 1000 > >> words) of a JProfiler snapshot. In the snapshot we see the > >> PhaseInterceptorChain.doIntercept() taking 78.4% of the CPU which is > >> fine as this includes the eventual service logic execution. What > >> happens > >> next is a bit strange, here is the ASCII art rendering: > >> > >> 78.4% PhaseInterceptorChain.doIntercept() > >> 26.4% OutgoingChainInterceptor.handleMessage > > > > This makes complete sense. The OutgoingChainInterceptor sets up the > > outgoing chain and invokes it. Thus, this number would include ALL > > of the work required to send the response including the JAXB > > marshalling, flushing the streams, etc > > > >> > >> 20.0% ServiceInvokerInterceptor.handleMessage > >> 16.9% ReadHeadersInterceptor.handleMessage > >> > >> > >> The call to ServiceInvokerInterceptor.handleMessage() ends up calling > >> the actual service logic which takes about 5% of the CPU time so, the > >> extra 15% penalty seems to excessive, > > > > That's really not good. Any chance you can dig into that one a bit > > furthur? > > > > > >> what's even more worrying are the > >> other two handleMessage calls (OutgoingChainInterceptor and > >> ReadHeadersInterceptor) that gobble up together more then 40% of the > >> CPU. > > > > ReadHeadersInteceptor is the first interceptor that actual reads stuff > > off the wire. Question: is it actually measuring CPU usage or just a > > "nanosecond count" or something. (raw time) Normally, this is where > > it would pause waiting for the message to come off the network. > > Everytime I see a large number hear, it's not really using the CPU, > > it's actually down in the ServletInputStream waiting for data from the > > socket. > > > > > > Dan > > > > > >> Note that we have no custom interceptors defined, our configuration > >> looks like this: > >> > >> > >> > >> > >> > >> > >> > >> > >> >>address="/SomeService" > >>implementor="#someService" > >> > >> implementorClass > >> ="com.betfair.services.someservice.SomeServiceServiceImp > >> l"> > >> > >> > >> > >> Is this behaviour expected in a properly config
RE: Tracking trunk commits blocked wrt to the 2.0.x_fixes branch
I was wondering the same thing about the migration guide -Original Message- From: Eoghan Glynn [mailto:[EMAIL PROTECTED] Sent: Thursday, July 17, 2008 10:10 AM To: dev@cxf.apache.org Subject: Re: Tracking trunk commits blocked wrt to the 2.0.x_fixes branch Thanks Dan & Freeman, Both suggested methods give exactly the same results. A total of well over blocked 500 commits ... ouch, that's a lot to go thru manually. BTW what's general feeling on the completeness of the 2.1 Migration Guide[1] wrt capturing potential compatibility issues? Cheers, Eoghan [1] http://cxf.apache.org/21-migration-guide.html Daniel Kulp wrote: > > > It's all stored as properties on the directory. Thus: > > svn propget svnmerge-blocked . > > would give you the list of revisions. THAT said, the stuff gnodet, > Freeman, and Willem have merged without using svnmerge.py may appear > in that list. > > On a related note: I'm not using subversion 1.5 and the Apache server > is using subversion 1.5. Thus, we probably could stop using > svnmerge.py and flip over to the tracking support in 1.5. However, > that would require all the mergers to use subversion 1.5 which I'm not > sure if everyone is ready to do or not. > > > Dan > > > On Jul 17, 2008, at 8:54 AM, Eoghan Glynn wrote: > >> >> Folks, >> >> Does anyone know if svnmerge.py can be used to report on the commits >> to trunk that have been "blocked" wrt to merging out to the >> 2.0.x_fixes branch? >> >> Its sortta like a retrospective "avail" option that I'm after, i.e. >> gimme all the commits that were available for merging, but were >> selected for blocking. >> >> The idea would be to get a definitive list of potentially >> backward-incompatible changes to 2.1 that may cause issues when >> upgrading from 2.0.x. >> >> Cheers, >> Eoghan >> >> >> >> >> >> IONA Technologies PLC (registered in Ireland) Registered Number: >> 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin >> 4, Ireland > > --- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > > IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: A CXF 2.1 CPU consumption question
On Jul 17, 2008, at 10:10 AM, David Soroko wrote: Hello all I apologise for cross posting, but I was not getting much traction in the users-list and I do think that my question is worth asking and answering. Doesn't really matter, although I do disagree with Glen on this. This really is a "dev" thing, not a users thing so it does belong here. That said, the person that has done the most work in JProfiler (Benson) is on vacation right now.I've never used it. (That said, CXF does have license keys for project use. If any of the committers wants to jump in here, send a note to [EMAIL PROTECTED] and we can give you the key) Here is what I have so far: Hello Daniel I had another profiling session and this time saved the snapshot so we can have a fixed point of reference. I am using JProfiler with CPU measurement set to "Elapsed time", which according to the documentation should ignore time spent while waiting or blocking. This time I have: 74.1% PhaseInterceptorChain.doIntercept() 30.5% OutgoingChainInterceptor.handleMessage 21.3% ReadHeadersInterceptor.handleMessage 7.3% DocLiteralInInterceptor.handleMessage 5.3% ServiceInvokerInterceptor.handleMessage Regarding ReadHeadersInterceptor.handleMessage. See image at: http://drop.io/pul3us5/asset/readheadersinterceptor Interesting. Definitely something to dig into. My first "WTF?" moment was the 18.6% spent in StaxUtils.declare, most of which is in xerces setAttributeNS call.Looking at that code in xerces, we probably do want to avoid it. When you see comments like: // REVISIT: this is not efficient, we are creating twice the same // strings for prefix and localName. it might be best to try something else. Most likely, we can do: element .setAttributeNode(element.getOwnerDocument().createAttributeNS()); Defintely a bunch of things to dig into there. Just need some time to do it. (The stack trace was re-rooted for display purposes to and that is why it is at 100%) It seems that most of the time is spent in xerces and wstx but what is it they do? Well, wstx is the XML Parser. It has do do all the UTF-8 decoding, parsing the XML stuff into events, etc... Woodstox is one of the fastest XML parsers around and is definitely the best option for that. Unfortunately, XML is very verbose and is not exactly cheap to parse. (BTW: you could enable the fastinfoset feature which would flip to a binary XML which is faster for parsing) Xerces is the DOM that we are parsing into. We only parse PART of the soap message into the dom (just the soap:headers for the most part). The rest are parsed directly into JAXB objects (or whatever your choice is for databinding). Thus, the DOM stuff should be a "small part". That is why the setAttributeNS stuff just "jumps out" at me. :-( Regarding DocLiteralInInterceptor.handleMessage. See image at: http://drop.io/pul3us5/asset/docliteralininterceptor Most work seems to be JAXB related. Yep. If you plugin the SXC runtime (sxc.codehaus.org), this can go down significantly. Regarding ServiceInvokerInterceptor.handleMessage. Here the actual business logic is invoked. This reflective invocation takes up 3% of the total of ServiceInvokerInterceptor.handleMessage. Not sure what the rest is. Snapshot image is here: http://drop.io/pul3us5/asset/serviceinvokerinterceptor The context mapping. Was afraid of that.That's been on my "to do" list to rewrite for a while. :-(I know what the issue is and how to fix it, I just need some time to do it. Basically, up front, we current map all the CXF "keys" into JAX-WS keys (and back at the end of invoke). We do this all the time even if the service doesn't use a context. I want to rewrite this to override the get/ set calls to do the mapping during the get/set call. Thus, the expense only occurs specifically for the keys you use and ONLY for that. The normal cases would be fast. Regarding OutgoingChainInterceptor.handleMessage. An image is here: http://drop.io/pul3us5/asset/outgoingchaininterceptor Would you say that 30% of the CPU is about the right slice size of the cake for CXF to take? Probably. This is the reverse of the stuff coming in. Basically, jaxb needs to write stuff (which involves a bunch of relflection unless you use sxc), woodstox needs to encode to UTF-8, streams need to be flushed, etcThat said, there are things that jump out there as well. The 4.2% and 75,680 calls to Logger.isLoggable is not a good sign. Most likely we should call that at the beginning of the doIntercept method and store it in a boolean. Dan Thanks -- david -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: 15 July 2008 23:16 To: [EMAIL PROTECTED] Subject: Re: A CXF 2.1 CPU consumption question On Jul 11, 2008, at 10:18 A
Re: A CXF 2.1 CPU consumption question
dkulp wrote: > > > On Jul 17, 2008, at 10:10 AM, David Soroko wrote: >> Hello all >> I apologise for cross posting, but I was not getting much traction in >> the users-list and I do think that my question is worth asking and >> answering. > > Doesn't really matter, although I do disagree with Glen on this. This > really is a "dev" thing, not a users thing so it does belong here. > > Actually, you're right. It was a dev thing all along. My mistake. Glen -- View this message in context: http://www.nabble.com/A-CXF-2.1--CPU-consumption-question-tp18509340p18510531.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Tracking trunk commits blocked wrt to the 2.0.x_fixes branch
For the most part, the migration guide covers everything that I've seen people comment on in the forums. That's not saying it's 100% complete, but it's probably a good start. Feel free to add to it as you audit the commits. :-) Dan On Jul 17, 2008, at 10:22 AM, Johnson, Eric wrote: I was wondering the same thing about the migration guide -Original Message- From: Eoghan Glynn [mailto:[EMAIL PROTECTED] Sent: Thursday, July 17, 2008 10:10 AM To: dev@cxf.apache.org Subject: Re: Tracking trunk commits blocked wrt to the 2.0.x_fixes branch Thanks Dan & Freeman, Both suggested methods give exactly the same results. A total of well over blocked 500 commits ... ouch, that's a lot to go thru manually. BTW what's general feeling on the completeness of the 2.1 Migration Guide[1] wrt capturing potential compatibility issues? Cheers, Eoghan [1] http://cxf.apache.org/21-migration-guide.html Daniel Kulp wrote: It's all stored as properties on the directory. Thus: svn propget svnmerge-blocked . would give you the list of revisions. THAT said, the stuff gnodet, Freeman, and Willem have merged without using svnmerge.py may appear in that list. On a related note: I'm not using subversion 1.5 and the Apache server is using subversion 1.5. Thus, we probably could stop using svnmerge.py and flip over to the tracking support in 1.5. However, that would require all the mergers to use subversion 1.5 which I'm not sure if everyone is ready to do or not. Dan On Jul 17, 2008, at 8:54 AM, Eoghan Glynn wrote: Folks, Does anyone know if svnmerge.py can be used to report on the commits to trunk that have been "blocked" wrt to merging out to the 2.0.x_fixes branch? Its sortta like a retrospective "avail" option that I'm after, i.e. gimme all the commits that were available for merging, but were selected for blocking. The idea would be to get a definitive list of potentially backward-incompatible changes to 2.1 that may cause issues when upgrading from 2.0.x. Cheers, Eoghan IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
(moved from cxf-user) Re: configuring password for services via Spring in Apache CXF 2.1.1 (so that username, password, endpoint, etc. can be set on client bean via Spring)
Oh I see--I think you already merged the WSS4JInInterceptor one in
2.0.x, it's just the WSS4JOutInterceptor we're talking about. I'm OK
either way about changing the code because regardless, I think I can
rephrase the CXF documentation anyway and make that SAAJInterceptor
notice somewhat more minor, since it only affects 2.0.x. If some CXF
2.0'ers miss it, it can get answered for them on the mailing list when
their interceptor raises errors.
By the way, was the SAAJ Interceptor stuff primarily a kludge--i.e.,
would it be preferable for WSS4J internally to create that DOM tree it
needs (perhaps sharing code from SAAJ Interceptors to do so?)
Glen
On Thu, 2008-07-17 at 12:17 -0400, Daniel Kulp wrote:
> Glen,
>
> The reason I didn't pull it into the 2.0.x branch is that it
> technically is a binary incompatible change. The WSS4JOutIntercptor
> moves from the POST_PROTOCOL phase to the PRE_PROTOCOL phase with it's
> internal interceptor going into the POST_PROTOCOL. Thus, if a user
> has an interceptor that has a
> "addAfter(WSS4JOutInterceptor.class.getName())" type thing, that code
> would no longer work correctly.
>
> Now, that type of thing is probably quite rare and I would be willing
> to release-note it for 2.0.8 if it's important enough. I'd just like
> to see some consensus on that.
>
> The changes in WSS4JInInterceptor are minor and would have no
> impact. I'm OK merging that, but the Out stuff is a bit more of an
> issue.
>
> Dan
>
>
>
> On Jul 17, 2008, at 9:04 AM, Glen Mazza wrote:
>
> >
> > Dan, if you wouldn't mind adding the SAAJ handler to the one WSS4J
> > In/Out
> > Interceptor (one of those two) in the 2.0.x branch where it is
> > missing (the
> > other one in 2.0.x has it), we can remove this distracting moving part
> > entirely from the CXF WS-Security documentation. I'll happily do
> > the doc
> > update once a new 2.0.x is released.
> >
> > Glen
> >
> >
> > dkulp wrote:
> >>
> >> On Jul 17, 2008, at 12:40 AM, Glen Mazza wrote:
> >>
> >>>
> >>> If you're using CXF 2.1+, be sure *not* to add the SAAJ handlers as
> >>> you're
> >>> doing below. That's only a 2.0.x thing.
> >>>
> >>
> >> Actually, it's not a big deal if you do add them. It's smart enough
> >> to check if its needed or not.
> >>
> >> Dan
> >>
> >>
> >>> Also, you *might* be able to use more Spring configuration and pull
> >>> out more
> >>> of that coding, in particular the WSS4JInInterceptor--storing the
> >>> username
> >>> might be troublesome though:
> >>> http://cwiki.apache.org/CXF20DOC/ws-security.html#WS-Security-SpringXMLConfiguration
> >>>
> >>> BTW, I just finished my blog entry on this. Our code is similar,
> >>> but maybe
> >>> you can find something else to leverage:
> >>> http://www.jroller.com/gmazza/date/20080716
> >>>
> >>> Glen
> >>>
> >>>
> >>> Gary Weaver wrote:
>
> Just verified that it works to set PW_CALLBACK_REF instead of
> PW_CALLBACK_CLASS.
>
> Do you think it would help to have examples on
> http://cwiki.apache.org/CXF20DOC/ws-security.html that use
> WSHandlerConstants.PW_CALLBACK_REF in addition (or maybe
> instead?) of
> those that use WSHandlerConstants.PW_CALLBACK_CLASS?
>
> This seems like it might be a good idea, since it would probably
> increase CXF performance at little to reduce instantiation of a
> CallbackHandler via reflection on every call.
>
> HTH,
> Gary
>
>
> Gary Weaver wrote:
> > The first thing I should have done is to look at the WSS4J
> > source... ;)
> >
> > The code in WSS4J 1.5.4 to get your CallbackHandler is (
> > http://svn.apache.org/viewvc/webservices/wss4j/tags/1_5_4/src/org/apache/ws/security/handler/WSHandler.java?view=markup
> > ):
> >
> > --- start code ---
> > /**
> > * Get the password callback class and get an instance
> > *
> > */
> > protected CallbackHandler getPasswordCB(RequestData reqData)
> > throws WSSecurityException {
> >
> > Object mc = reqData.getMsgContext();
> > CallbackHandler cbHandler = null;
> > String callback =
> > getString(WSHandlerConstants.PW_CALLBACK_CLASS, mc);
> > if (callback != null) {
> > Class cbClass = null;
> > try {
> > cbClass = Loader.loadClass(getClassLoader(reqData
> > .getMsgContext()), callback);
> > } catch (ClassNotFoundException e) {
> > throw new WSSecurityException(
> > "WSHandler: cannot load password callback
> > class: "
> > + callback, e);
> > }
> > try {
> > cbHandler = (CallbackHandler) cbClass.newInstance();
> > } catch (java.lang.Exception e) {
> > throw new WSSecurityException(
> > "WSHandler: cannot create instance of pass
