Re: [GSOC] Simple and lightweight HTML-based browser for surveying Apache CXF logs
Hi, I've just committed basic version of logbrowser [1] (described by my proposal). I also created sample application [2] for easy testing all parts of the project. However it's more or less what user have to do to integrate logbrowser into his application. Detailed description, how to run sample application, is here [3]. I'm staring work on [4] and [5] (i.e. refactoring, clean up and writing documentation) and I'm going to finished those tasks before mid-term evaluations deadline (i.e. 16.07.2010). Next I will add optional features [6]. [1] http://svn.apache.org/viewvc?rev=960895&view=rev [2] ./distribution/src/main/release/samples/logbrowser [3] ./distribution/src/main/release/samples/logbrowser/README.txt [4] https://issues.apache.org/jira/browse/CXF-2881 [5] https://issues.apache.org/jira/browse/CXF-2882 [6] https://issues.apache.org/jira/browse/CXF-2883 On Mon, Jun 21, 2010 at 6:55 PM, Tomasz Oponowicz wrote: > Hi, > > I've just commit changes at repository [1]. Changes from last version: > > - Created Maven project structure; > - Configured 'maven-gwt-plugin' for automatic execute GWT compiler (to > convert Java to JavaScript); > - Added draft implementation of 'BootstrapStorage'; > - Create sample configuration of 'AtomPullServer'; > - Added support for HTTP basic authentication (temporary solution, at > the end I will replace it with UsernameToken); > - Added support for JSON web service (client-side - in GWT); > - Added support for XML web service (client-side - in GWT); > - Removed GWT-RPC mock web services; > > Additionally you can easily run application by downloading source code and > type: > > $ mvn gwt:run > > Authentication details: > > username: "admin" > password:"admin"; > > It'll start in debug mode - it's much more slower than production mode. > > At the moment I'm working to move all source code to Apache CXF sandbox. > > [1] svn checkout http://cxf-log-browser.googlecode.com/svn/trunk/ > cxf-log-browser-read-only > > On Fri, Jun 18, 2010 at 3:29 PM, Daniel Kulp wrote: >> On Thursday 17 June 2010 5:15:24 pm Tomasz Oponowicz wrote: >>> Hi, >>> >>> On Thu, Jun 17, 2010 at 7:43 PM, Daniel Kulp wrote: >>> > On Thursday 17 June 2010 1:31:30 pm Sergey Beryozkin wrote: >>> >> Just for the record, Tomasz's project is also going well >>> > >>> >Well, for the record, I haven't seen anything on the dev list about it >>> >yet. Thus, from CXF/Apache's point of view, it's not going well. >>> >Definitely encourage him to get involved here and not send you anything >>> >off list. >>> >>> I have created project site and blog, few weeks ago. >>> Sorry that I didn't announce about it at mailing list. >>> >>> I will store documentation and source code on Google Code Project [1]. >>> Additionally I will announce important events and changes through blog >>> [2], which I created for this occasion. >> >> One of the aspects of GSoC, and in particular Apache's involvement in it, >> that >> is often missed is teaching the students how the community works. It's not >> supposed to be "just do this coding project". For Apache, it's also >> getting >> the student involved in the community and keeping the entire community up to >> date with what is happening. >> >> I would strongly suggest that any "import events" and any questions and stuff >> get posted here on the dev list. You can add it to the blog as well, but >> make sure they appear on the dev list. >> >> There is a saying in Apache: "if it didn't happen on the dev list, it didn't >> happen". >> >> Dan >> >> >> >> >>> Currently repository [1] contain draft of all features (on my roadmap >>> it's milestone 1). >>> There is also "Software Requirements Specification" document >>> and "Software Design Description" document. At the moment I'm working to >>> fix and refactor source code. >>> >>> When I finish I will move all source code to CXF sandbox. >>> >>> Once again sorry for my misunderstanding. >>> >>> [1] http://code.google.com/p/cxf-log-browser/ >>> [2] http://cxf-log-browser.blogspot.com/ >>> >>> Best regards, >>> Tomasz Oponowicz >> >> -- >> Daniel Kulp >> dk...@apache.org >> http://dankulp.com/blog >> > > > > -- > Pozdrawiam, > Tomasz Oponowicz > -- Best regards, Tomasz Oponowicz
WSDLPublish capablities
What are the current WSDLPublish capabilities in CXF? Obviously WSDL can be obtained by adding ?wsdl to a service URL, but I was wondering if it is possible to configure CXF to have a separate port dedicated to serving WSDL information. This is particularly useful when serving up WSDL for a secure endpoint via an insecure port. Regards, Seumas
Re: PolicyVerificationInterceptor
Jim, My gut feeling is that this validation and exception belong in the MAPAggregator, not the PolicyInInterceptor. If Addressing is required, the addressing layer should throw the appropriate addressing fault. Dan On Jul 5, 2010, at 4:02 AM, jim ma wrote: > Hi all , > > When I ran a service with ws addressing policy enabled and an handler > which always throw exception configured in > server side . When I sent a soap request WITHOUT wsa header , > I saw the SOAPHandlerInterceptor in server side eat the WS addressing > violation exception and just throw the exception > in handler chain thrown . > > Below is the intercetor chain sequence in server side and my analysis > comments : > > ---org.apache.cxf.ws.policy.policyinintercep...@184b5c4 > > #Add the wsa policy interceptorProvider and > PolicyVerificationIntercetor > > ---org.apache.cxf.interceptor.attachmentinintercep...@8f299 > ---org.apache.cxf.transport.https.certconstraintsintercep...@88e798 > ---org.apache.cxf.interceptor.staxinintercep...@4757b > --- org.apache.cxf.binding.soap.interceptor.readheadersintercep...@fe0e2e > --- org.apache.cxf.binding.soap.interceptor.soapactioninintercep...@568915 > --- org.apache.cxf.binding.soap.interceptor.startbodyintercep...@141dc8b > --- org.apache.cxf.binding.soap.interceptor.mustunderstandintercep...@f638ae > ---org.apache.cxf.ws.addressing.soap.mapco...@178fce9 > > #Here compose the WSA maps and already > know there is no wsa header in inbound soap message > > ---org.apache.cxf.jaxws.handler.soap.soaphandlerintercep...@187ab2d > > # Here will call the Handler and throw > exception , the execute path will be directed to fault chain, > hence the WS addressing policy error > will not be reported. > > --- org.apache.cxf.jaxws.handler.logical.logicalhandlerinintercep...@ca2f5c > --- org.apache.cxf.binding.soap.interceptor.checkfaultintercep...@1eb416b > --- org.apache.cxf.jaxb.attachment.jaxbattachmentschemavalidationh...@1405eb > ---org.apache.cxf.interceptor.urimappingintercep...@90baa1 > ---org.apache.cxf.interceptor.docliteralinintercep...@1ccd087 > --- org.apache.cxf.binding.soap.interceptor.soapheaderintercep...@1611006 > ---org.apache.cxf.ws.addressing.mapaggrega...@1b97041 > ---org.apache.cxf.interceptor.onewayprocessorintercep...@162fdb2 > --- org.apache.cxf.jaxws.interceptors.wrapperclassinintercep...@1fded53 > ---org.apache.cxf.jaxws.interceptors.swainintercep...@133c109 > ---org.apache.cxf.jaxws.interceptors.holderinintercep...@c63783 > ---org.apache.cxf.ws.policy.policyverificationinintercep...@166979a > > #This will not be executed because > SOAPHandlerInterceptor throws exception > > ---org.apache.cxf.interceptor.serviceinvokerintercep...@172ff2b > > The above interceptor list is the normal execution path without > exception thrown in SOAPHandlerInterceptor. As you can see , > CXF actually can detect the ws addressing policy violation in MAPCodec > and throws the policy error immediately and not pass in > the SOAPHandlerInterceptor. > So far our policy check uses AssertionInfoMap to log the policy error > and checks the policy error in "one point" > PolicyVerification*Interceptor, > The actual policy errors will not be displayed or reported when the > other intercetors throws exceptoin before the check point > So how can we enable our current policy framework to check error in > the interceptor and report it immediately when there is policy error ? > > Cheers, > Jim -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: PolicyVerificationInterceptor
On Wed, Jul 7, 2010 at 8:48 AM, Daniel Kulp wrote: > Jim, > > My gut feeling is that this validation and exception belong in the > MAPAggregator, not the PolicyInInterceptor. The validation part is in PolicyVerificationInterceptor not PolicyInInterceptor. The MAPAgggregator tracks the adderssing policy error in AssertionInfoMap and PolicyVerificationInterceptor will finally compute and check the policy configuration to decide if these errors are needed to be cast to PolicyException and throw. > If Addressing is required, the > addressing layer should throw the appropriate addressing fault. As you can see from the interceptor chain list , the current chain will NOT reach MAPAggregator which can validate the incoming addressing properties when there is error in SOAPHandlerInterceptor. I tried to validate the incoming message in MAPCodec, there is no BindingOperationInfo set in exchange which stops me to get the normalized policy. > > Dan > > > On Jul 5, 2010, at 4:02 AM, jim ma wrote: > >> Hi all , >> >> When I ran a service with ws addressing policy enabled and an handler >> which always throw exception configured in >> server side . When I sent a soap request WITHOUT wsa header , >> I saw the SOAPHandlerInterceptor in server side eat the WS addressing >> violation exception and just throw the exception >> in handler chain thrown . >> >> Below is the intercetor chain sequence in server side and my analysis >> comments : >> >> ---org.apache.cxf.ws.policy.policyinintercep...@184b5c4 >> >> #Add the wsa policy interceptorProvider and >> PolicyVerificationIntercetor >> >> ---org.apache.cxf.interceptor.attachmentinintercep...@8f299 >> ---org.apache.cxf.transport.https.certconstraintsintercep...@88e798 >> ---org.apache.cxf.interceptor.staxinintercep...@4757b >> --- > org.apache.cxf.binding.soap.interceptor.readheadersintercep...@fe0e2e >> --- > org.apache.cxf.binding.soap.interceptor.soapactioninintercep...@568915 >> --- > org.apache.cxf.binding.soap.interceptor.startbodyintercep...@141dc8b >> --- > org.apache.cxf.binding.soap.interceptor.mustunderstandintercep...@f638ae >> ---org.apache.cxf.ws.addressing.soap.mapco...@178fce9 >> >> #Here compose the WSA maps and already >> know there is no wsa header in inbound soap message >> >> ---org.apache.cxf.jaxws.handler.soap.soaphandlerintercep...@187ab2d >> >> # Here will call the Handler and throw >> exception , the execute path will be directed to fault chain, >> hence the WS addressing policy error >> will not be reported. >> >> --- > org.apache.cxf.jaxws.handler.logical.logicalhandlerinintercep...@ca2f5c >> --- > org.apache.cxf.binding.soap.interceptor.checkfaultintercep...@1eb416b >> --- > org.apache.cxf.jaxb.attachment.jaxbattachmentschemavalidationh...@1405eb >> ---org.apache.cxf.interceptor.urimappingintercep...@90baa1 >> ---org.apache.cxf.interceptor.docliteralinintercep...@1ccd087 >> --- > org.apache.cxf.binding.soap.interceptor.soapheaderintercep...@1611006 >> ---org.apache.cxf.ws.addressing.mapaggrega...@1b97041 >> ---org.apache.cxf.interceptor.onewayprocessorintercep...@162fdb2 >> --- > org.apache.cxf.jaxws.interceptors.wrapperclassinintercep...@1fded53 >> ---org.apache.cxf.jaxws.interceptors.swainintercep...@133c109 >> ---org.apache.cxf.jaxws.interceptors.holderinintercep...@c63783 >> ---org.apache.cxf.ws.policy.policyverificationinintercep...@166979a >> >> #This will not be executed because >> SOAPHandlerInterceptor throws exception >> >> ---org.apache.cxf.interceptor.serviceinvokerintercep...@172ff2b >> >> The above interceptor list is the normal execution path without >> exception thrown in SOAPHandlerInterceptor. As you can see , >> CXF actually can detect the ws addressing policy violation in MAPCodec >> and throws the policy error immediately and not pass in >> the SOAPHandlerInterceptor. >> So far our policy check uses AssertionInfoMap to log the policy error >> and checks the policy error in "one point" >> PolicyVerification*Interceptor, >> The actual policy errors will not be displayed or reported when the >> other intercetors throws exceptoin before the check point >> So how can we enable our current policy framework to check error in >> the interceptor and report it immediately when there is policy error ? >> >> Cheers, >> Jim > > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog >
Re: PolicyVerificationInterceptor
Sorry, was reading it on my iPhone and the traces didn't display very well. I would challenge the test. There isn't anything in the spec that says the addressing stuff needs to be processed before calling the handlers. (example: addressing COULD be implemented as handlers) Thus, the handler in the test should not be throwing the exception or the test should be updated to allow it. Dan On Tuesday 06 July 2010 10:05:16 pm jim ma wrote: > On Wed, Jul 7, 2010 at 8:48 AM, Daniel Kulp wrote: > > Jim, > > > > My gut feeling is that this validation and exception belong in the > > MAPAggregator, not the PolicyInInterceptor. > > The validation part is in PolicyVerificationInterceptor not > PolicyInInterceptor. > The MAPAgggregator tracks the adderssing policy error in AssertionInfoMap > and PolicyVerificationInterceptor will finally compute and check the > policy configuration to decide if these errors > are needed to be cast to PolicyException and throw. > > > If Addressing is required, the > > addressing layer should throw the appropriate addressing fault. > > As you can see from the interceptor chain list , the current chain > will NOT reach MAPAggregator which can validate the incoming > addressing properties when there is error in SOAPHandlerInterceptor. I > tried to validate the incoming message in MAPCodec, > there is no BindingOperationInfo set in exchange which stops me to get > the normalized policy. > > > Dan > > > > On Jul 5, 2010, at 4:02 AM, jim ma wrote: > >> Hi all , > >> > >> When I ran a service with ws addressing policy enabled and an handler > >> which always throw exception configured in > >> server side . When I sent a soap request WITHOUT wsa header , > >> I saw the SOAPHandlerInterceptor in server side eat the WS addressing > >> violation exception and just throw the exception > >> in handler chain thrown . > >> > >> Below is the intercetor chain sequence in server side and my analysis > >> comments : > >> > >> ---org.apache.cxf.ws.policy.policyinintercep...@184b5c4 > >> > >> #Add the wsa policy interceptorProvider and > >> PolicyVerificationIntercetor > >> > >> ---org.apache.cxf.interceptor.attachmentinintercep...@8f299 > >> ---org.apache.cxf.transport.https.certconstraintsintercep...@88e > >> 798 ---org.apache.cxf.interceptor.staxinintercep...@4757b > >> --- > > > > org.apache.cxf.binding.soap.interceptor.readheadersintercep...@fe0e2e > > > >> --- > > > > org.apache.cxf.binding.soap.interceptor.soapactioninintercep...@568915 > > > >> --- > > > > org.apache.cxf.binding.soap.interceptor.startbodyintercep...@141dc8b > > > >> --- > > > > org.apache.cxf.binding.soap.interceptor.mustunderstandintercep...@f638ae > > > >> ---org.apache.cxf.ws.addressing.soap.mapco...@178fce9 > >> > >> #Here compose the WSA maps and already > >> know there is no wsa header in inbound soap message > >> > >> ---org.apache.cxf.jaxws.handler.soap.soaphandlerintercep...@187a > >> b2d > >> > >> # Here will call the Handler and throw > >> exception , the execute path will be directed to fault chain, > >> hence the WS addressing policy error > >> will not be reported. > >> > >> --- > > > > org.apache.cxf.jaxws.handler.logical.logicalhandlerinintercep...@ca2f5c > > > >> --- > > > > org.apache.cxf.binding.soap.interceptor.checkfaultintercep...@1eb416b > > > >> --- > > > > org.apache.cxf.jaxb.attachment.jaxbattachmentschemavalidationh...@1405eb > > > >> ---org.apache.cxf.interceptor.urimappingintercep...@90baa1 > >> ---org.apache.cxf.interceptor.docliteralinintercep...@1ccd087 > >> --- > > > > org.apache.cxf.binding.soap.interceptor.soapheaderintercep...@1611006 > > > >> ---org.apache.cxf.ws.addressing.mapaggrega...@1b97041 > >> ---org.apache.cxf.interceptor.onewayprocessorintercep...@162fdb2 > >> --- > > > > org.apache.cxf.jaxws.interceptors.wrapperclassinintercep...@1fded53 > > > >> ---org.apache.cxf.jaxws.interceptors.swainintercep...@133c109 > >> ---org.apache.cxf.jaxws.interceptors.holderinintercep...@c63783 > >> ---org.apache.cxf.ws.policy.policyverificationinintercep...@1669 > >> 79a > >> > >> #This will not be executed because > >> SOAPHandlerInterceptor throws exception > >> > >> ---org.apache.cxf.interceptor.serviceinvokerintercep...@172ff2b > >> > >> The above interceptor list is the normal execution path without > >> exception thrown in SOAPHandlerInterceptor. As you can see , > >> CXF actually can detect the ws addressing policy violation in MAPCodec > >> and throws the policy error immediately and not pass in > >> the SOAPHandlerInterceptor. > >> So far our policy check uses AssertionInfoMap to log the policy error > >> and checks the policy error in
[JiBX DataBinding] Code generation API
I've restructured the JiBX code generation from schema to make it easier to use from other tools. Nilupa, you should be able to use this to integrate JiBX code and binding generation in with CXF's code generation from WSDL. JiBX code generation still uses the org.jibx.schema.codegen.CodeGen class, but no longer assumes command line usage. The guts of the core generation have been moved into the static generate() method, which takes a pair of interfaces and a list of schema resolvers as input. The first interface is to provide code generation parameters, the second is to handle reporting of problems and status information during generation. The list of schema resolvers provides the means for the code generation to get at the actual schemas - in normal generation these are generally coming from the file system or internet and use org.jibx.schema.UrlResolver instances, but for working from WSDL you may need to work with embedded schemas which can be handled using org.jibx.schema.MemoryResolver. It'll probably be next week before I can release JiBX 1.2.3 including these changes, but I've uploaded the latest SNAPSHOT jars to the maven1 repository if you want to try them out. You can get the source code from the JiBX CVS on SourceForge. - Dennis
