schema first development
Hi all. I'm attempting to upgrade my current XFire 1.2.6 service to CXF 2.0.1 and having a few speed bumps. First off, we're doing schema first development with JAXB and using Spring for our container. For CXF, I hope to use Spring's namespace support and this is where one of my problems lie. I have taken a service, and done the following: classpath:com/kronos/taws/services/mobile/MobileService.xsd However, when I start the server, I get the following error: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Failed to import bean definitions from URL location [classpath:com/kronos/taws/services/servicesContext.xml] Offending resource: ServletContext resource [/WEB-INF/taws-services-servlet.xml]; nested exception is org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Cannot locate BeanDefinitionParser for element [schemaLocation] Offending resource: class path resource [com/kronos/taws/services/servicesContext.xml] Caused by: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Cannot locate BeanDefinitionParser for element [schemaLocation] Offending resource: class path resource [com/kronos/taws/services/servicesContext.xml] at org.springframework.beans.factory.parsing.FailFastProblemReporter.fatal(FailFastProblemReporter.java:59) at org.springframework.beans.factory.parsing.ReaderContext.fatal(ReaderContext.java:68) at org.springframework.beans.factory.parsing.ReaderContext.fatal(ReaderContext.java:55) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.findParserForElement(NamespaceHandlerSupport.java:79) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1114) at org.apache.cxf.configuration.spring.AbstractBeanDefinitionParser.getAndRegisterFirstChild(AbstractBeanDefinitionParser.java:175) at org.apache.cxf.configuration.spring.AbstractBeanDefinitionParser.setFirstChildAsProperty(AbstractBeanDefinitionParser.java:139) at org.apache.cxf.jaxws.spring.EndpointDefinitionParser.doParse(EndpointDefinitionParser.java:112) I have a few other questions, however I feel if I can fix this my others might go away :) Thanks in advance for any help. Eric
Re: schema first development
I'm using Maven2 to build my application, so I thought I probably have a dependency missing. I tried to use the cxf-bundle as it seems as though that is an all encompassing dependency, rather than identifying them in individually. I receive the same error with this as I do the other. If that's the case, how do I display my schema in a dynamically generated WSDL? Thanks, Eric On Fri, 2007-08-24 at 09:51 -0400, Eric Miles wrote: > Hi all. I'm attempting to upgrade my current XFire 1.2.6 service to CXF > 2.0.1 and having a few speed bumps. First off, we're doing schema first > development with JAXB and using Spring for our container. > > For CXF, I hope to use Spring's namespace support and this is where one > of my problems lie. I have taken a service, and done the following: > >implementor="#tawsMobileServiceImpl" name="MobileService" > address="/MobileService"> > > > > > > > classpath:com/kronos/taws/services/mobile/MobileService.xsd > > > > However, when I start the server, I get the following error: > > org.springframework.beans.factory.parsing.BeanDefinitionParsingException: > Configuration problem: Failed to import bean definitions from URL location > [classpath:com/kronos/taws/services/servicesContext.xml] > Offending resource: ServletContext resource > [/WEB-INF/taws-services-servlet.xml]; nested exception is > org.springframework.beans.factory.parsing.BeanDefinitionParsingException: > Configuration problem: Cannot locate BeanDefinitionParser for element > [schemaLocation] > Offending resource: class path resource > [com/kronos/taws/services/servicesContext.xml] > Caused by: > org.springframework.beans.factory.parsing.BeanDefinitionParsingException: > Configuration problem: Cannot locate BeanDefinitionParser for element > [schemaLocation] > Offending resource: class path resource > [com/kronos/taws/services/servicesContext.xml] > at > org.springframework.beans.factory.parsing.FailFastProblemReporter.fatal(FailFastProblemReporter.java:59) > at > org.springframework.beans.factory.parsing.ReaderContext.fatal(ReaderContext.java:68) > at > org.springframework.beans.factory.parsing.ReaderContext.fatal(ReaderContext.java:55) > at > org.springframework.beans.factory.xml.NamespaceHandlerSupport.findParserForElement(NamespaceHandlerSupport.java:79) > at > org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69) > at > org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1114) > at > org.apache.cxf.configuration.spring.AbstractBeanDefinitionParser.getAndRegisterFirstChild(AbstractBeanDefinitionParser.java:175) > at > org.apache.cxf.configuration.spring.AbstractBeanDefinitionParser.setFirstChildAsProperty(AbstractBeanDefinitionParser.java:139) > at > org.apache.cxf.jaxws.spring.EndpointDefinitionParser.doParse(EndpointDefinitionParser.java:112) > > I have a few other questions, however I feel if I can fix this my others > might go away :) > > Thanks in advance for any help. > > Eric
Re: Schema-First Development with CXF
Daniel, I posted this exact same question last week to the mailing list but have not received a response on it yet. I am receiving the exact same error as you. I attempted to look for the namespace parser that extracts the schemaLocation but couldn't find one. Hopefully I just couldn't find it rather than it hasn't been developed! Eric On Mon, 2007-08-27 at 20:26 +1000, Daniel Pike wrote: > Hi Dans, > > Sorry for the delay but I have only just got around to testing this. I have > tried this using the 2.0.1-incubator, 2.0.1-incubator-snapshot version as > well as the 2.1-snapshot version. Unfortunately, whenever I try add the xml > below, I get the following error: > > org.springframework.beans.factory.parsing.BeanDefinitionParsingException: > Configuration problem: Cannot locate BeanDefinitionParser for element > [schemaLocation] > > I have setup my endpoint as below: > > > > class="my.proto.HelloWorldImpl"> > > > > > > > /META-INF/schemas/helloWorldSchema.xsd > > > > Any ideas what might be causing this problem? > > Thanks, > > Daniel. > > On 7/11/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > > Dan, > > > > Sorry. I didn't see this till now. > > > > I'll get a new snapshot deploying now. > > > > Dan > > > > (hmm 3 Dan's I'm getting confused. Which one am I? :-) > > > > On Monday 09 July 2007 09:42, Dan Diephouse wrote: > > > Hi Daniel, > > > > > > Sorry for the delay with these changes. It turns out I need to fix > > > something else inside CXF to make this work correctly yet. I added > > > some basic support for it to though to today's SVN. Since I'm on a > > > cellular connection, I can't publish a snapshot now, but I think > > > another CXF dev probably will today. Then you'll be able to do > > > something like: > > > > > > > > > > > > /foo/bar.xsd > > > > > > > > > > > > The curent issue with the code is that CXF will parse the schemas with > > > a library called XmlSchema and it doesn't preserve things like > > > formatting or documentation. I'll be fixing this later tonight though > > > (hopefully I'll be able to get it done tonight). > > > > > > Thanks for your patience and testing! I'll keep an on eye on the > > > snapshots and let you know when one is published. > > > > > > - Dan > > > > > > On 7/4/07, Daniel Pike <[EMAIL PROTECTED]> wrote: > > > > Hi Dan, > > > > > > > > Sounds great, I will keep an eye out for it. > > > > > > > > Thanks, > > > > > > > > Daniel. > > > > > > > > On 7/5/07, Dan Diephouse <[EMAIL PROTECTED]> wrote: > > > > > Hi Daniel, > > > > > I think I might have overlooked configuration of this in the JAXB > > > > > databinding. Its just a few lines of code for me to change though. > > > > > I > > > > > > > > think > > > > > > > > > I > > > > > can probably push out a snapshot this week with the change if you > > > > > want > > > > > > > > to > > > > > > > > > try it. Then it'll get in our 2.0.1 release. Sound good? > > > > > - Dan > > > > > > > > > > On 7/4/07, Daniel Pike <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > > > > > > > I am currently looking at migrating our existing XFire web > > > > > > service > > > > > > > > > > across > > > > > > > > > > > to > > > > > > CXF. We have used schema-first development to develop this web > > > > > > > > service > > > > > > > > > > and > > > > > > are hoping to do the same with CXF > > > > > > > > > > > > The problem that I am having is that I cannot find a way to > > > > > > specify > > > > > > > > the > > > > > > > > > > location of the XSD files when configuring the app using spring. > > > > > > I noticed > > > > > > that the ServiceInfo class has a method called addSchema but > > > > > > this does > > > > > > > > > > not > > > > > > > > > > > appear to be called in the code in a way that would allow me to > > > > > > > > specify > > > > > > > > > > the > > > > > > schema. > > > > > > > > > > > > Is schema first-development supported in CXF? > > > > > > > > > > > > Regards, > > > > > > > > > > > > Daniel. > > > > > > > > > > -- > > > > > Dan Diephouse > > > > > Envoi Solutions > > > > > http://envoisolutions.com | http://netzooid.com/blog > > > > -- > > J. Daniel Kulp > > Principal Engineer > > IONA > > P: 781-902-8727C: 508-380-7194 > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog > >
Re: Schema-First Development with CXF
Dan, Thanks for the follow up. Any idea when 2.0.2 will be released? Thanks! Eric On Mon, 2007-08-27 at 18:22 -0400, Dan Diephouse wrote: > Hi Daniel (and Eric who is hopefully still listening), > > I've just fixed this problem in SVN. The problem was I added capabilities to > do this from the API, but forgot to actually write a test for the XML config > - which wasn't fully working :-(. Dan Kulp will be publishing some new > snapshots tonight I think, at which point you can test out the fixed > functionality. > > I did think of a workaround though. You could do something like this: > > > > > > > > > > > class="my.proto.HelloWorldImpl"> > > > > > > > > > > > > > > > > /META-INF/schemas/helloWorldSchema.xsd > > > > > > > > Any ideas what might be causing this problem? > > > > Thanks, > > > > Daniel. > > > > On 7/11/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > > > > Dan, > > > > > > Sorry. I didn't see this till now. > > > > > > I'll get a new snapshot deploying now. > > > > > > Dan > > > > > > (hmm 3 Dan's I'm getting confused. Which one am I? :-) > > > > > > On Monday 09 July 2007 09:42, Dan Diephouse wrote: > > > > Hi Daniel, > > > > > > > > Sorry for the delay with these changes. It turns out I need to fix > > > > something else inside CXF to make this work correctly yet. I added > > > > some basic support for it to though to today's SVN. Since I'm on a > > > > cellular connection, I can't publish a snapshot now, but I think > > > > another CXF dev probably will today. Then you'll be able to do > > > > something like: > > > > > > > > > > > > > > > > /foo/bar.xsd > > > > > > > > > > > > > > > > The curent issue with the code is that CXF will parse the schemas with > > > > a library called XmlSchema and it doesn't preserve things like > > > > formatting or documentation. I'll be fixing this later tonight though > > > > (hopefully I'll be able to get it done tonight). > > > > > > > > Thanks for your patience and testing! I'll keep an on eye on the > > > > snapshots and let you know when one is published. > > > > > > > > - Dan > > > > > > > > On 7/4/07, Daniel Pike <[EMAIL PROTECTED]> wrote: > > > > > Hi Dan, > > > > > > > > > > Sounds great, I will keep an eye out for it. > > > > > > > > > > Thanks, > > > > > > > > > > Daniel. > > > > > > > > > > On 7/5/07, Dan Diephouse <[EMAIL PROTECTED]> wrote: > > > > > > Hi Daniel, > > > > > > I think I might have overlooked configuration of this in the JAXB > > > > > > databinding. Its just a few lines of code for me to change though. > > > > > > I > > > > > > > > > > think > > > > > > > > > > > I > > > > > > can probably push out a snapshot this week with the change if you > > > > > > want > > > > > > > > > > to > > > > > > > > > > > try it. Then it'll get in our 2.0.1 release. Sound good? > > > > > > - Dan > > > > > > > > > > > > On 7/4/07, Daniel Pike <[EMAIL PROTECTED]> wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I am currently looking at migrating our existing XFire web > > > > > > > service > > > > > > > > > > > > across > > > > > > > > > > > > > to > > > > > > > CXF. We have used schema-first development to develop this web > > > > > > > > > > service > > > > > > > > > > > > and > > > > > > > are hoping to do the same with CXF > > > > > > > > > > > > > > The problem that I am having is that I cannot find a way to > > > > > > > specify > > > > > > > > > > the > > > > > > > > > > > > location of the XSD files when configuring the app using spring. > > > > > > > I noticed > > > > > > > that the ServiceInfo class has a method called addSchema but > > > > > > > this does > > > > > > > > > > > > not > > > > > > > > > > > > > appear to be called in the code in a way that would allow me to > > > > > > > > > > specify > > > > > > > > > > > > the > > > > > > > schema. > > > > > > > > > > > > > > Is schema first-development supported in CXF? > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Daniel. > > > > > > > > > > > > -- > > > > > > Dan Diephouse > > > > > > Envoi Solutions > > > > > > http://envoisolutions.com | http://netzooid.com/blog > > > > > > -- > > > J. Daniel Kulp > > > Principal Engineer > > > IONA > > > P: 781-902-8727C: 508-380-7194 > > > [EMAIL PROTECTED] > > > http://www.dankulp.com/blog > > > > > > > >
Re: Schema-First Development with CXF
Dan,
I tried this and for some reason my service isn't being registered.
Here are snippets of what I have:
Spring config:
com/kronos/taws/services/mobile/MobileService.xsd
...
Interface def:
@WebService(targetNamespace =
"http://taws.kronos.com/services/MobileService";)
public interface MobileService {
...
Impl def:
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE, style =
SOAPBinding.Style.DOCUMENT)
@WebService(serviceName = "MobileService", endpointInterface =
"com.kronos.taws.services.mobile.MobileService",
portName="MobileServicePort", name="MobileService")
public class MobileServiceImpl implements MobileService,
InitializingBean {
...
web.xml:
taws-services
org.apache.cxf.transport.servlet.CXFServlet
2
...
When I go to the services servlet, I do not have a listing for the
registered service. I also attempted to make a call (on faith) and I
receive a response back from the framework that no such service exists.
Suggestions?
Thanks!
Eric
On Mon, 2007-08-27 at 18:22 -0400, Dan Diephouse wrote:
> Hi Daniel (and Eric who is hopefully still listening),
>
> I've just fixed this problem in SVN. The problem was I added capabilities to
> do this from the API, but forgot to actually write a test for the XML config
> - which wasn't fully working :-(. Dan Kulp will be publishing some new
> snapshots tonight I think, at which point you can test out the fixed
> functionality.
>
> I did think of a workaround though. You could do something like this:
>
>
>
>
>
>
> >
> > > class="my.proto.HelloWorldImpl">
> >
> >
> >
> >
> >
> >
> >
> > /META-INF/schemas/helloWorldSchema.xsd
> >
> >
> >
> > Any ideas what might be causing this problem?
> >
> > Thanks,
> >
> > Daniel.
> >
> > On 7/11/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> > >
> > > Dan,
> > >
> > > Sorry. I didn't see this till now.
> > >
> > > I'll get a new snapshot deploying now.
> > >
> > > Dan
> > >
> > > (hmm 3 Dan's I'm getting confused. Which one am I? :-)
> > >
> > > On Monday 09 July 2007 09:42, Dan Diephouse wrote:
> > > > Hi Daniel,
> > > >
> > > > Sorry for the delay with these changes. It turns out I need to fix
> > > > something else inside CXF to make this work correctly yet. I added
> > > > some basic support for it to though to today's SVN. Since I'm on a
> > > > cellular connection, I can't publish a snapshot now, but I think
> > > > another CXF dev probably will today. Then you'll be able to do
> > > > something like:
> > > >
> > > >
> > > >
> > > > /foo/bar.xsd
> > > >
> > > >
> > > >
> > > > The curent issue with the code is that CXF will parse the schemas with
> > > > a library called XmlSchema and it doesn't preserve things like
> > > > formatting or documentation. I'll be fixing this later tonight though
> > > > (hopefully I'll be able to get it done tonight).
> > > >
> > > > Thanks for your patience and testing! I'll keep an on eye on the
> > > > snapshots and let you know when one is published.
> > > >
> > > > - Dan
> > > >
> > > > On 7/4/07, Daniel Pike <[EMAIL PROTECTED]> wrote:
> > > > > Hi Dan,
> > > > >
> > > > > Sounds great, I will keep an eye out for it.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Daniel.
> > > > >
> > > > > On 7/5/07, Dan Diephouse <[EMAIL PROTECTED]> wrote:
> > > > > > Hi Daniel,
> > > > > > I think I might have overlooked configuration of this in the JAXB
> > > > > > databinding. Its just a few lines of code for me to change though.
> > > > > > I
> > > > >
> > > > > think
> > > > >
> > > > > > I
> > > > > > can probably push out a snapshot this week with the change if you
> > > > > > want
> > > > >
> > > > > to
> > > > >
> > > > > > try it. Then it'll get in our 2.0.1 release. Sound good?
> > > > > > - Dan
> > > > > >
> > > > > > On 7/4/07, Daniel Pike <[EMAIL PROTECTED]> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I am currently looking at migrating our existing XFire web
> > > > > > > service
> > > > > >
> > > > > > across
> > > > > >
> > > > > > > to
> > > > > > > CXF. We have used schema-first development to develop this web
> > > > >
> > > > > service
> > > > >
> > > > > > > and
> > > > > > > are hoping to do the same with CXF
> > > > > > >
> > > > > > > The problem that I am having is that I cannot find a way to
> > > > > > > specify
> > > > >
> > > > > the
> > > > >
> > > > > > > location of the XSD files when configuring the app using spring.
> > > > > > > I noticed
> > > > >
Re: Schema-First Development with CXF
Dan, On the heels of the trouble I'm having with the suggestion below, I decided to give the 2.1 snapshot version a try with the fixed Spring namespace support. This actually does register my service and I can view the WSDL. However, the behavior is not as I expected. In XFire 1.2.6, when I gave my schema locations, the WSDL Generator took my schemas and added them to the generated WSDL. With CXF 2.1-SNAPSHOT, this is not happening. Is this the expected behavior? Do I need more configuration in my Spring context? Here is the configuration: classpath:com/kronos/taws/services/mobile/MobileService.xsd Attached are the 2 WSDLs. One generated from XFire 1.2.6 and one from CXF 2.1-SNAPSHOT. Keep in mind, the only thing I have changed in the interface and impl classes were the addition of the portType in the CXF version (to get around the use of the classname from the proxy class). Thanks, Eric On Mon, 2007-08-27 at 18:22 -0400, Dan Diephouse wrote: > Hi Daniel (and Eric who is hopefully still listening), > > I've just fixed this problem in SVN. The problem was I added capabilities to > do this from the API, but forgot to actually write a test for the XML config > - which wasn't fully working :-(. Dan Kulp will be publishing some new > snapshots tonight I think, at which point you can test out the fixed > functionality. > > I did think of a workaround though. You could do something like this: > > > > > > > > > > > class="my.proto.HelloWorldImpl"> > > > > > > > > > > > > > > > > /META-INF/schemas/helloWorldSchema.xsd > > > > > > > > Any ideas what might be causing this problem? > > > > Thanks, > > > > Daniel. > > > > On 7/11/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > > > > Dan, > > > > > > Sorry. I didn't see this till now. > > > > > > I'll get a new snapshot deploying now. > > > > > > Dan > > > > > > (hmm 3 Dan's I'm getting confused. Which one am I? :-) > > > > > > On Monday 09 July 2007 09:42, Dan Diephouse wrote: > > > > Hi Daniel, > > > > > > > > Sorry for the delay with these changes. It turns out I need to fix > > > > something else inside CXF to make this work correctly yet. I added > > > > some basic support for it to though to today's SVN. Since I'm on a > > > > cellular connection, I can't publish a snapshot now, but I think > > > > another CXF dev probably will today. Then you'll be able to do > > > > something like: > > > > > > > > > > > > > > > > /foo/bar.xsd > > > > > > > > > > > > > > > > The curent issue with the code is that CXF will parse the schemas with > > > > a library called XmlSchema and it doesn't preserve things like > > > > formatting or documentation. I'll be fixing this later tonight though > > > > (hopefully I'll be able to get it done tonight). > > > > > > > > Thanks for your patience and testing! I'll keep an on eye on the > > > > snapshots and let you know when one is published. > > > > > > > > - Dan > > > > > > > > On 7/4/07, Daniel Pike <[EMAIL PROTECTED]> wrote: > > > > > Hi Dan, > > > > > > > > > > Sounds great, I will keep an eye out for it. > > > > > > > > > > Thanks, > > > > > > > > > > Daniel. > > > > > > > > > > On 7/5/07, Dan Diephouse <[EMAIL PROTECTED]> wrote: > > > > > > Hi Daniel, > > > > > > I think I might have overlooked configuration of this in the JAXB > > > > > > databinding. Its just a few lines of code for me to change though. > > > > > > I > > > > > > > > > > think > > > > > > > > > > > I > > > > > > can probably push out a snapshot this week with the change if you > > > > > > want > > > > > > > > > > to > > > > > > > > > > > try it. Then it'll get in our 2.0.1 release. Sound good? > > > > > > - Dan > > > > > > > > > > > > On 7/4/07, Daniel Pike <[EMAIL PROTECTED]> wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I am currently looking at migrating our existing XFire web > > > > > > > service > > > > > > > > > > > > across > > > > > > > > > > > > > to > > > > > > > CXF. We have used schema-first development to develop this web > > > > > > > > > > service > > > > > > > > > > > > and > > > > > > > are hoping to do the same with CXF > > > > > > > > > > > > > > The problem that I am having is that I cannot find a way to > > > > > > > specify > > > > > > > > > > the > > > > > > > > > > > > location of the XSD files when configuring the app using spring. > > > > > > > I noticed > > > > > > > that the ServiceInfo class has a method called addSchema but > > > > > > > this does > > > > > > > > > > > > not > > > > > > > > > > > > > appear to be called in the code in a way that would allow me to > > > > > > > > > > specify > > > > > > > > > > > > the > > > > > > > schema. > > > > > > > > > > > > > > Is schema first-development supported in CXF?
Re: Method level authentication?
If you're using Spring and WSS4J, I'd also recommend looking at Acegi.
We're using Acegi's method interceptor along with method level
annotations to secure web services based on role and other custom
granted authorities. It's a fairly easy solution once you WSS4J and
Acegi hooked together.
On Tue, 2007-08-28 at 13:26 -0400, Daniel Kulp wrote:
> Van,
>
> The answer is both yes and no.
>
> CXF doesn't have anything "built in" that would provide that capability.
> However, it would be very easy to write an interceptor that would:
>
>
> public class AuthorizationInterceptor extends
> AbstractPhaseInterceptor {
>
> public AuthorizationInterceptor() {
> super(Phase.USER_LOGICAL);
> }
>
> public void handleMessage(Message message) throws Fault {
> AuthorizationPolicy policy =
> message.get(AuthorizationPolicy.class);
> String opName = (String)message.put(Message.WSDL_OPERATION);
>
> //use username/passwords from AuthorizationPolicy to validate.
> //Throw a fault or similar if processing should not continue.
> }
> }
>
>
> There is also:
> message.get(SecurityContext.class);
> which can provide the principal object and checks for isUserInRole if
> your deployment environment (tomcat/etc...) supports configurations of
> users and roles on that level.
>
> Dan
>
>
> On Tuesday 28 August 2007, vannguyen0 wrote:
> > Hi,
> >
> > I'm fairly new to webservices and was wondering if CXF has the ability
> > to restrict users to certain web services methods. If I have
> > PerformProductSearch and UpdateProductInformation, I want to allow
> > user A (or users that is in user group A) permission to only
> > PerformProductSearch. But user B (or users that are in user group B)
> > can access to both methods.
> >
> > Thanks,
> >
> > Van
>
>
>
Re: Schema-First Development with CXF
Any feedback on this question? On Tue, 2007-08-28 at 10:02 -0400, Eric Miles wrote: > Dan, > > On the heels of the trouble I'm having with the suggestion below, I > decided to give the 2.1 snapshot version a try with the fixed Spring > namespace support. This actually does register my service and I can > view the WSDL. However, the behavior is not as I expected. In XFire > 1.2.6, when I gave my schema locations, the WSDL Generator took my > schemas and added them to the generated WSDL. With CXF 2.1-SNAPSHOT, > this is not happening. Is this the expected behavior? Do I need more > configuration in my Spring context? > > Here is the configuration: > > implementor="#tawsMobileServiceImpl" name="MobileService" > address="/MobileService"> > > > > > > > classpath:com/kronos/taws/services/mobile/MobileService.xsd > > > > Attached are the 2 WSDLs. One generated from XFire 1.2.6 and one from > CXF 2.1-SNAPSHOT. Keep in mind, the only thing I have changed in the > interface and impl classes were the addition of the portType in the > CXF version (to get around the use of the classname from the proxy > class). > > Thanks, > Eric > > On Mon, 2007-08-27 at 18:22 -0400, Dan Diephouse wrote: > > > Hi Daniel (and Eric who is hopefully still listening), > > > > I've just fixed this problem in SVN. The problem was I added capabilities to > > do this from the API, but forgot to actually write a test for the XML config > > - which wasn't fully working :-(. Dan Kulp will be publishing some new > > snapshots tonight I think, at which point you can test out the fixed > > functionality. > > > > I did think of a workaround though. You could do something like this: > > > > > > > > > > > >> > > > > > > > > class="my.proto.HelloWorldImpl"> > > > > > > > > > > > > > > > > > > > > > > > > /META-INF/schemas/helloWorldSchema.xsd > > > > > > > > > > > > Any ideas what might be causing this problem? > > > > > > Thanks, > > > > > > Daniel. > > > > > > On 7/11/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > > > > > > Dan, > > > > > > > > Sorry. I didn't see this till now. > > > > > > > > I'll get a new snapshot deploying now. > > > > > > > > Dan > > > > > > > > (hmm 3 Dan's I'm getting confused. Which one am I? :-) > > > > > > > > On Monday 09 July 2007 09:42, Dan Diephouse wrote: > > > > > Hi Daniel, > > > > > > > > > > Sorry for the delay with these changes. It turns out I need to fix > > > > > something else inside CXF to make this work correctly yet. I added > > > > > some basic support for it to though to today's SVN. Since I'm on a > > > > > cellular connection, I can't publish a snapshot now, but I think > > > > > another CXF dev probably will today. Then you'll be able to do > > > > > something like: > > > > > > > > > > > > > > > > > > > > /foo/bar.xsd > > > > > > > > > > > > > > > > > > > > The curent issue with the code is that CXF will parse the schemas with > > > > > a library called XmlSchema and it doesn't preserve things like > > > > > formatting or documentation. I'll be fixing this later tonight though > > > > > (hopefully I'll be able to get it done tonight). > > > > > > > > > > Thanks for your patience and testing! I'll keep an on eye on the > > > > > snapshots and let you know when one is published. > > > > > > > > > > - Dan > > > > > > > > > > On 7/4/07, Daniel Pike <[EMAIL PROTECTED]> wrote: > > > > > > Hi Dan, > > > > > > > > > > > > Sounds great, I will keep an eye out for it. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Daniel. > > > > > > > > > > > > On 7/5/07, Dan Diephouse <[EMAIL PROTECTED]> wrote: > > > > > > &
Re: Schema-First Development with CXF
Daniel, I re-asked my question again last week and haven't heard anything in about 7 days on the subject. I've taken that to signal it's either a fairly big problem and it's taking them a while to look at it or it's just not that important. Unfortunately, it's such a severe issue (doesn't work), it is keeping our group from moving from XFire to CXF. Eric On Sat, 2007-09-01 at 19:35 +1000, Daniel Pike wrote: > Hi Dan & Eric, > > I have just finished testing this and have found that I am also experiencing > the same issue. When I specify the schema location, the definition does not > actually appear in the WSDL. Any ideas on what may be causing this? > > Regards, > > Daniel. > > > > On 8/30/07, Eric Miles <[EMAIL PROTECTED]> wrote: > > > > Any feedback on this question? > > > > On Tue, 2007-08-28 at 10:02 -0400, Eric Miles wrote: > > > > > Dan, > > > > > > On the heels of the trouble I'm having with the suggestion below, I > > > decided to give the 2.1 snapshot version a try with the fixed Spring > > > namespace support. This actually does register my service and I can > > > view the WSDL. However, the behavior is not as I expected. In XFire > > > 1.2.6, when I gave my schema locations, the WSDL Generator took my > > > schemas and added them to the generated WSDL. With CXF 2.1-SNAPSHOT, > > > this is not happening. Is this the expected behavior? Do I need more > > > configuration in my Spring context? > > > > > > Here is the configuration: > > > > > > > > implementor="#tawsMobileServiceImpl" name="MobileService" > > > address="/MobileService"> > > > > > > > > > > > > > > > > > > > > > > > classpath:com/kronos/taws/services/mobile/MobileService.xsd > > > > > > > > > > > > Attached are the 2 WSDLs. One generated from XFire 1.2.6 and one from > > > CXF 2.1-SNAPSHOT. Keep in mind, the only thing I have changed in the > > > interface and impl classes were the addition of the portType in the > > > CXF version (to get around the use of the classname from the proxy > > > class). > > > > > > Thanks, > > > Eric > > > > > > On Mon, 2007-08-27 at 18:22 -0400, Dan Diephouse wrote: > > > > > > > Hi Daniel (and Eric who is hopefully still listening), > > > > > > > > I've just fixed this problem in SVN. The problem was I added > > capabilities to > > > > do this from the API, but forgot to actually write a test for the XML > > config > > > > - which wasn't fully working :-(. Dan Kulp will be publishing some new > > > > snapshots tonight I think, at which point you can test out the fixed > > > > functionality. > > > > > > > > I did think of a workaround though. You could do something like this: > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > class="my.proto.HelloWorldImpl"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /META-INF/schemas/helloWorldSchema.xsd > > > > > > > > > > > > > > > > > > > > Any ideas what might be causing this problem? > > > > > > > > > > Thanks, > > > > > > > > > > Daniel. > > > > > > > > > > On 7/11/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Dan, > > > > > > > > > > > > Sorry. I didn't see this till now. > > > > > > > > > > > > I'll get a new snapshot deploying now. > > > > > > > > > > > > Dan > > > > > > > > > > > > (hmm 3 Dan's I'm getting confused. Which one am I? :-) > > > > > > > > > > > > On Monday 09 July 2007 09:42, Dan Diephouse wrote: > > > > > > > Hi Daniel, > > > > > > > > > > > > > > Sorry for the delay with these c
xfire to cxf upgrade, additional wrapping body elements?
I'm testing our upgrade from XFire 1.2.6 to CXF 2.1-SNAPSHOT and it seems there is some additional wrapping of the message body requests and responses for our services. Under XFire, a request coming from the XFire client libraries (XFireProxyFactory using JaxbServiceFactory) looks like such: http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> http://taws.kronos.com/services/MobileService"; /> Under CXF (using JaxWsProxyFactoryBean): http://schemas.xmlsoap.org/soap/envelope/";> http://mobile.services.taws.kronos.com/";> http://taws.kronos.com/services/MobileService"; /> FYI, the actual java implementation's method name is retrRefTc, so I think that's where this wrapping name is coming from. The responses are such, first the XFire response: http://schemas.xmlsoap.org/soap/envelope/";> http://taws.kronos.com/services/MobileService";> Then the CXF response: http://schemas.xmlsoap.org/soap/envelope/";> http://taws.kronos.com/services/MobileService";> http://taws.kronos.com/services/MobileService";> Again, you can see CXF is wrapping the response with a RetrRefTcResponse element. Here are the two Spring configurations. First XFire: com/kronos/taws/services/mobile/MobileService.xsd Now CXF: classpath:com/kronos/taws/services/mobile/MobileService.xsd This wrapping behavior is not desired. If there is configuration somewhere to keep this from happening, please let me know. As I've stated at the top of the post, we have not changed ANY of our java code, merely the configuration in Spring.
Re: xfire to cxf upgrade, additional wrapping body elements?
Dan,
I thought this might have to do with document vs wrapped, however I have
specified document style on the impl class as seen below:
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE, style =
SOAPBinding.Style.DOCUMENT)
@WebService(serviceName = "MobileService", endpointInterface =
"com.kronos.taws.services.mobile.MobileService",
portName="MobileServicePort", name="MobileService")
public class MobileServiceImpl implements MobileService,
InitializingBean {
...
...
}
The style property from the xfire spring configuration might be an old
artifact that was left over during prototyping...sorry if that gave any
confusion as to how the service was configured via annotations. Any
more information I can provide to help diagnose my problem?
Thanks again,
Eric
On Mon, 2007-09-10 at 15:35 -0400, Dan Diephouse wrote:
> Hi Eric,
>
> This is because you've specified "document" style on the ServiceBean
> inside xfire. Try adding this annotation to your service impl:
>
> @SOAPBinding(parameterStyle=ParameterStyle.BARE)
>
> This will tell CXF not to operate in wrapped mode, but in
> document/bare/literal.
> Cheers,
> - Dan
>
> Eric Miles wrote:
> > I'm testing our upgrade from XFire 1.2.6 to CXF 2.1-SNAPSHOT and it
> > seems there is some additional wrapping of the message body requests and
> > responses for our services. Under XFire, a request coming from the
> > XFire client libraries (XFireProxyFactory using JaxbServiceFactory)
> > looks like such:
> >
> > http://schemas.xmlsoap.org/soap/envelope/";
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> >
> > > xmlns="http://taws.kronos.com/services/MobileService"; />
> >
> >
> >
> > Under CXF (using JaxWsProxyFactoryBean):
> >
> > http://schemas.xmlsoap.org/soap/envelope/";>
> >
> > > xmlns:ns1="http://mobile.services.taws.kronos.com/";>
> > >
> > xmlns="http://taws.kronos.com/services/MobileService"; />
> >
> >
> >
> >
> > FYI, the actual java implementation's method name is retrRefTc, so I
> > think that's where this wrapping name is coming from.
> >
> > The responses are such, first the XFire response:
> >
> > http://schemas.xmlsoap.org/soap/envelope/";>
> >
> > > xmlns="http://taws.kronos.com/services/MobileService";>
> >
> >
> >
> >
> > Then the CXF response:
> >
> > http://schemas.xmlsoap.org/soap/envelope/";>
> >
> > >
> > xmlns:ns1="http://taws.kronos.com/services/MobileService";>
> > >
> > xmlns="http://taws.kronos.com/services/MobileService";>
> >
> >
> >
> >
> >
> > Again, you can see CXF is wrapping the response with a RetrRefTcResponse
> > element.
> >
> > Here are the two Spring configurations.
> >
> > First XFire:
> >
> > > class="org.codehaus.xfire.spring.ServiceBean">
> >
> > > />
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > com/kronos/taws/services/mobile/MobileService.xsd
> >
> >
> >
> >
> > Now CXF:
> >
> > > implementor="#tawsMobileServiceImpl" name="MobileService"
> > address="/MobileService">
> >
> >
> >
> >
> >
> >
> >
> > classpath:com/kronos/taws/services/mobile/MobileService.xsd
> >
> >
> >
> > This wrapping behavior is not desired. If there is configuration
> > somewhere to keep this from happening, please let me know.
> >
> > As I've stated at the top of the post, we have not changed ANY of our
> > java code, merely the configuration in Spring.
> >
> >
> >
>
>
Re: xfire to cxf upgrade, additional wrapping body elements?
Dan,
That could make sense, however the response being sent by CXF also
includes this wrapping as well, see the response section from the
original email. FYI, I'm using ethereal to sniff packets on the network
interface so I'm seeing the actual soap message hitting the wire in both
directions.
Thanks,
Eric
On Tue, 2007-09-11 at 23:19 +0200, Dan Diephouse wrote:
> So this is the client side that is sending the wrong request? Well thats
> probably because the @SOAPBinding implementation is on the server impl,
> not the interface - which the client typically uses.
>
> If you're using the xml config, I think this can be fixed
> by specifying a service class as your implementation class - in which
> case @SOAPBinding will be read.
>
> You can also trying supply the WSDL to the client proxy. I think this
> can be done via the element inside . In
> this case, CXF will look at the WSDL to see how to build the service
> model internally.
>
> Cheers,
> - Dan
>
> Eric Miles wrote:
> > Dan,
> >
> > I thought this might have to do with document vs wrapped, however I have
> > specified document style on the impl class as seen below:
> >
> > @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE, style =
> > SOAPBinding.Style.DOCUMENT)
> > @WebService(serviceName = "MobileService", endpointInterface =
> > "com.kronos.taws.services.mobile.MobileService",
> > portName="MobileServicePort", name="MobileService")
> > public class MobileServiceImpl implements MobileService,
> > InitializingBean {
> > ...
> > ...
> > }
> >
> > The style property from the xfire spring configuration might be an old
> > artifact that was left over during prototyping...sorry if that gave any
> > confusion as to how the service was configured via annotations. Any
> > more information I can provide to help diagnose my problem?
> >
> > Thanks again,
> > Eric
> >
> > On Mon, 2007-09-10 at 15:35 -0400, Dan Diephouse wrote:
> >
> >> Hi Eric,
> >>
> >> This is because you've specified "document" style on the ServiceBean
> >> inside xfire. Try adding this annotation to your service impl:
> >>
> >> @SOAPBinding(parameterStyle=ParameterStyle.BARE)
> >>
> >> This will tell CXF not to operate in wrapped mode, but in
> >> document/bare/literal.
> >> Cheers,
> >> - Dan
> >>
> >> Eric Miles wrote:
> >>> I'm testing our upgrade from XFire 1.2.6 to CXF 2.1-SNAPSHOT and it
> >>> seems there is some additional wrapping of the message body requests and
> >>> responses for our services. Under XFire, a request coming from the
> >>> XFire client libraries (XFireProxyFactory using JaxbServiceFactory)
> >>> looks like such:
> >>>
> >>> http://schemas.xmlsoap.org/soap/envelope/";
> >>> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> >>>
> >>>>>> xmlns="http://taws.kronos.com/services/MobileService"; />
> >>>
> >>>
> >>>
> >>> Under CXF (using JaxWsProxyFactoryBean):
> >>>
> >>> http://schemas.xmlsoap.org/soap/envelope/";>
> >>>
> >>>>>> xmlns:ns1="http://mobile.services.taws.kronos.com/";>
> >>>>>>
> >>> xmlns="http://taws.kronos.com/services/MobileService"; />
> >>>
> >>>
> >>>
> >>>
> >>> FYI, the actual java implementation's method name is retrRefTc, so I
> >>> think that's where this wrapping name is coming from.
> >>>
> >>> The responses are such, first the XFire response:
> >>>
> >>> http://schemas.xmlsoap.org/soap/envelope/";>
> >>>
> >>>>>> xmlns="http://taws.kronos.com/services/MobileService";>
> >>>
> >>>
> >>>
> >>>
> >>> Then the CXF response:
> >>>
> >>> http://schemas.xmlsoap.org/soap/envelope/";>
> >>>
> >>>>>>
Re: xfire to cxf upgrade, additional wrapping body elements?
Not sure why, but this email keeps getting bounced by the apache spam
software, so I'm not going to able to attach code nor copy and paste...
Sorry, my first response wasn't complete (I'm in class while trying to
write an email). As stated in the previous email, the response from the
server is also wrapped as identified in the original email in the
"responses" section. I am using a client completely outside the JVM
running the services, with no Spring configuration. This is a testing
client so how this is setup and functions is irrelevant to the
application itself. I am attaching the client so you can see how it is
being used. Even if the client was written/configured incorrectly, I
still would not expect the server to return a wrapped response. I am
using the JaxWsProxyFactoryBean to programmatically create my client.
Again, I'd attach my client code, but the Apache spam filter keeps
bouncing this email (5th time now).
Thanks again,
Eric
On Tue, 2007-09-11 at 23:19 +0200, Dan Diephouse wrote:
> So this is the client side that is sending the wrong request? Well thats
> probably because the @SOAPBinding implementation is on the server impl,
> not the interface - which the client typically uses.
>
> If you're using the xml config, I think this can be fixed
> by specifying a service class as your implementation class - in which
> case @SOAPBinding will be read.
>
> You can also trying supply the WSDL to the client proxy. I think this
> can be done via the element inside . In
> this case, CXF will look at the WSDL to see how to build the service
> model internally.
>
> Cheers,
> - Dan
>
> Eric Miles wrote:
> > Dan,
> >
> > I thought this might have to do with document vs wrapped, however I have
> > specified document style on the impl class as seen below:
> >
> > @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE, style =
> > SOAPBinding.Style.DOCUMENT)
> > @WebService(serviceName = "MobileService", endpointInterface =
> > "com.kronos.taws.services.mobile.MobileService",
> > portName="MobileServicePort", name="MobileService")
> > public class MobileServiceImpl implements MobileService,
> > InitializingBean {
> > ...
> > ...
> > }
> >
> > The style property from the xfire spring configuration might be an old
> > artifact that was left over during prototyping...sorry if that gave any
> > confusion as to how the service was configured via annotations. Any
> > more information I can provide to help diagnose my problem?
> >
> > Thanks again,
> > Eric
> >
> > On Mon, 2007-09-10 at 15:35 -0400, Dan Diephouse wrote:
> >
> >> Hi Eric,
> >>
> >> This is because you've specified "document" style on the ServiceBean
> >> inside xfire. Try adding this annotation to your service impl:
> >>
> >> @SOAPBinding(parameterStyle=ParameterStyle.BARE)
> >>
> >> This will tell CXF not to operate in wrapped mode, but in
> >> document/bare/literal.
> >> Cheers,
> >> - Dan
> >>
> >> Eric Miles wrote:
> >>> I'm testing our upgrade from XFire 1.2.6 to CXF 2.1-SNAPSHOT and it
> >>> seems there is some additional wrapping of the message body requests and
> >>> responses for our services. Under XFire, a request coming from the
> >>> XFire client libraries (XFireProxyFactory using JaxbServiceFactory)
> >>> looks like such:
> >>>
> >>> http://schemas.xmlsoap.org/soap/envelope/";
> >>> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> >>>
> >>>>>> xmlns="http://taws.kronos.com/services/MobileService"; />
> >>>
> >>>
> >>>
> >>> Under CXF (using JaxWsProxyFactoryBean):
> >>>
> >>> http://schemas.xmlsoap.org/soap/envelope/";>
> >>>
> >>>>>> xmlns:ns1="http://mobile.services.taws.kronos.com/";>
> >>>>>>
> >>> xmlns="http://taws.kronos.com/services/MobileService"; />
> >>>
> >>>
> >>>
> >>>
> >>> FYI, the actual java implementation's method name is retrRefTc, so I
> >>> think that's where this wrapping name is coming from.
> >>>
> >>>
Re: xfire to cxf upgrade, additional wrapping body elements?
Resending this, anyone with any idea?
On Wed, 2007-09-12 at 08:38 -0400, Eric Miles wrote:
> Not sure why, but this email keeps getting bounced by the apache spam
> software, so I'm not going to able to attach code nor copy and paste...
>
> Sorry, my first response wasn't complete (I'm in class while trying to
> write an email). As stated in the previous email, the response from the
> server is also wrapped as identified in the original email in the
> "responses" section. I am using a client completely outside the JVM
> running the services, with no Spring configuration. This is a testing
> client so how this is setup and functions is irrelevant to the
> application itself. I am attaching the client so you can see how it is
> being used. Even if the client was written/configured incorrectly, I
> still would not expect the server to return a wrapped response. I am
> using the JaxWsProxyFactoryBean to programmatically create my client.
> Again, I'd attach my client code, but the Apache spam filter keeps
> bouncing this email (5th time now).
>
> Thanks again,
> Eric
>
> On Tue, 2007-09-11 at 23:19 +0200, Dan Diephouse wrote:
>
> > So this is the client side that is sending the wrong request? Well thats
> > probably because the @SOAPBinding implementation is on the server impl,
> > not the interface - which the client typically uses.
> >
> > If you're using the xml config, I think this can be fixed
> > by specifying a service class as your implementation class - in which
> > case @SOAPBinding will be read.
> >
> > You can also trying supply the WSDL to the client proxy. I think this
> > can be done via the element inside . In
> > this case, CXF will look at the WSDL to see how to build the service
> > model internally.
> >
> > Cheers,
> > - Dan
> >
> > Eric Miles wrote:
> > > Dan,
> > >
> > > I thought this might have to do with document vs wrapped, however I have
> > > specified document style on the impl class as seen below:
> > >
> > > @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE, style =
> > > SOAPBinding.Style.DOCUMENT)
> > > @WebService(serviceName = "MobileService", endpointInterface =
> > > "com.kronos.taws.services.mobile.MobileService",
> > > portName="MobileServicePort", name="MobileService")
> > > public class MobileServiceImpl implements MobileService,
> > > InitializingBean {
> > > ...
> > > ...
> > > }
> > >
> > > The style property from the xfire spring configuration might be an old
> > > artifact that was left over during prototyping...sorry if that gave any
> > > confusion as to how the service was configured via annotations. Any
> > > more information I can provide to help diagnose my problem?
> > >
> > > Thanks again,
> > > Eric
> > >
> > > On Mon, 2007-09-10 at 15:35 -0400, Dan Diephouse wrote:
> > >
> > >> Hi Eric,
> > >>
> > >> This is because you've specified "document" style on the ServiceBean
> > >> inside xfire. Try adding this annotation to your service impl:
> > >>
> > >> @SOAPBinding(parameterStyle=ParameterStyle.BARE)
> > >>
> > >> This will tell CXF not to operate in wrapped mode, but in
> > >> document/bare/literal.
> > >> Cheers,
> > >> - Dan
> > >>
> > >> Eric Miles wrote:
> > >>> I'm testing our upgrade from XFire 1.2.6 to CXF 2.1-SNAPSHOT and it
> > >>> seems there is some additional wrapping of the message body requests and
> > >>> responses for our services. Under XFire, a request coming from the
> > >>> XFire client libraries (XFireProxyFactory using JaxbServiceFactory)
> > >>> looks like such:
> > >>>
> > >>> http://schemas.xmlsoap.org/soap/envelope/";
> > >>> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> > >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> > >>>
> > >>> > >>>
> > >>> xmlns="http://taws.kronos.com/services/MobileService"; />
> > >>>
> > >>>
> > >>>
> > >>> Under CXF (using JaxWsProxyFactoryBean):
> > >>>
> > >>> http://schemas.xmlsoap.org/soap/envelope/";
Re: CXF+ACEGI + Anybody out there?
Dan, What sort of solution are you looking for? We are using an Acegi/Spring/CXF implementation at our company where we are using WS-Security and Acegi for authentication and AOP/Acegi for authorization. We could be interested in contributing. Thanks, Eric On Tue, 2007-09-18 at 00:15 +0200, Dan Diephouse wrote: > And I want somebody to contribute a cleaner solution :-D > > I know there is a lot of stuff we could do with Spring Security/Acegi > that would be super cool. It'd be a real low barrier way to contribute > some stuff if anyone is interested. > > Cheers, > - Dan > > mattmadhavan wrote: > > Hi Ray, > > No I do not want the client side to tell the server! Thats my point. Some > > good blogs I have seen, do that! Where the client 'tells' which handler to > > use! > > > > I want a cleaner ACEGI+ XFIRE solution! > > > > Thanks > > Matt > > > > > > > > Ray Krueger wrote: > > > > > You want the client to tell the server how to do security? That sounds > > > crazy :) > > > > > > Your client side should either be doing http based security or > > > ws-security. That doesn't have anything to do with Acegi at that > > > point. > > > > > > On 9/14/07, Zarar Siddiqi <[EMAIL PROTECTED]> wrote: > > > > > > > I'm trying to understand what you're saying but am having difficulty. > > > > But > > > > here goes: > > > > > > > > > > > > > Can some one point me to some docs on the CXF and ACEGI integration > > > > > or CXF and security like authentication and authorization. > > > > > > > > > I use Acegi for authorization purposes only. IMHO it doesn't really make > > > > sense for authentication (WS-Security can do that). So I use the > > > > MethodSecurityInterceptor and BeanNameAutoProxyCreator to manage calls > > > > to > > > > my > > > > service level methods. The Acegi docs can help you there, the only > > > > difference I think is that you have to set the authentication token > > > > yourself, e.g.: > > > > > > > > UsernamePasswordAuthenticationToken token = new > > > > UsernamePasswordAuthenticationToken( > > > >user.getUsername(), user.getPassword(), user.getAuthorities()); > > > > // Populate Acegi Security Context > > > > SecurityContextHolder.getContext().setAuthentication(token); > > > > > > > > > > > > > I found some blogs on the CXF+ACEGI, but it is Java centric. On the > > > > > > > > > client > > > > > > > > > side > > > > > we need to set the which class handles the security on the Server > > > > > side! > > > > > But if > > > > > I am using some other language for clients like C# it doesn't seem to > > > > > > > > > be > > > > > > > > > the proper way! > > > > > > > > > You can pass the class name which handles security to the server (crazy > > > > thought I think!) using a header element and then parse it using CXF > > > > interceptors. > > > > > > > > Zarar > > > > > > > > > > > > > > > > > > > > mattmadhavan wrote: > > > > > > > > > Any Help will be appreciated! > > > > > > > > > > > > > > > > > > > > mattmadhavan wrote: > > > > > > > > > > > Hello, > > > > > > Can some one point me to some docs on the CXF and ACEGI integration > > > > > > or > > > > > > CXF and security like authentication and authorization. Some sample > > > > > > > > > > app > > > > > > > > > > will even be great. > > > > > > > > > > > > I found some blogs on the CXF+ACEGI, but it is Java centric. On the > > > > > > client side we need to set the which class handles the security on > > > > > > the > > > > > > Server side! But if I am using some other language for clients like > > > > > > C# > > > > > > > > > > it > > > > > > > > > > does n't seem to be the proper way! > > > > > > > > > > > > Any ideas will be greatly appreciated. > > > > > > > > > > > > Thanks > > > > > > Matt > > > > > > > > > > > > > > > > -- > > > > View this message in context: > > > > http://www.nabble.com/CXF%2BACEGI-tf4436973.html#a12677582 > > > > Sent from the cxf-user mailing list archive at Nabble.com. > > > > > > > > > > > > > > > > > > > -- > Dan Diephouse > MuleSource > http://mulesource.com | http://netzooid.com/blog
RE: contract-first with only xsd
We're using the Maven2 JAXB plugin. You need stubs for the schema to manipulate the objects within your endpoint implementation. On Tue, 2007-09-18 at 10:05 -0400, Mulligan, Patrick wrote: > What are you using to generate the jaxb stubs? > > Can't the annotations drive it all? > > -Original Message- > From: Eric Miles [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 18, 2007 10:00 AM > To: cxf-user@incubator.apache.org > Subject: Re: contract-first with only xsd > > Los, > > It is just as easy to define contract first, without having to create a > WSDL. For our project, we create our XSDs, generate stubs with JAXB, > create our endpoint implementations (we use annotations), and wire it > all up with Spring. CXF takes care of the WSDL generation. It really > is easy. I'm not sure there is an example within the CXF toolkit but I > could probably come up with one fairly fast if you need one. > > Eric > > > > On Tue, 2007-09-18 at 06:49 -0700, moraleslos wrote: > > Hi-- > > > > Having gone through the Spring Web Services (SWS) manifesto about > > contract-first as well as their sample examples, I wonder how CXF > matches up > > with SWS. I know that CXF allows contract-first development, but is > it as > > simple as SWS? For example, with SWS, all I need to do is define the > XSD > > for my types (the messages and such being passed or returned). I can > then > > have SWS generate the WSDL using basic conventions and the XSDs > defined. The > > only other thing to do is to implement the endpoints (Java) that will > handle > > the service. From looking through the CXF site, it looks that if you > do > > contract-first, you must define the WSDL along with the XSDs and Java > > service implementations (probably using JSR-181). Is this the case? > > > > Thanks in advance! > > > > -los
Re: contract-first with only xsd
Los, It is just as easy to define contract first, without having to create a WSDL. For our project, we create our XSDs, generate stubs with JAXB, create our endpoint implementations (we use annotations), and wire it all up with Spring. CXF takes care of the WSDL generation. It really is easy. I'm not sure there is an example within the CXF toolkit but I could probably come up with one fairly fast if you need one. Eric On Tue, 2007-09-18 at 06:49 -0700, moraleslos wrote: > Hi-- > > Having gone through the Spring Web Services (SWS) manifesto about > contract-first as well as their sample examples, I wonder how CXF matches up > with SWS. I know that CXF allows contract-first development, but is it as > simple as SWS? For example, with SWS, all I need to do is define the XSD > for my types (the messages and such being passed or returned). I can then > have SWS generate the WSDL using basic conventions and the XSDs defined. The > only other thing to do is to implement the endpoints (Java) that will handle > the service. From looking through the CXF site, it looks that if you do > contract-first, you must define the WSDL along with the XSDs and Java > service implementations (probably using JSR-181). Is this the case? > > Thanks in advance! > > -los
Re: contract-first with only xsd
Here's just a quick sample. I'm not stating this is the proper or correct way to do anything. However, this is how we are currently using CXF. The CXF guys can provide you with better direction on how you SHOULD be creating your services. They might tell you this approach is a bad approach. Eric On Tue, 2007-09-18 at 06:49 -0700, moraleslos wrote: > Hi-- > > Having gone through the Spring Web Services (SWS) manifesto about > contract-first as well as their sample examples, I wonder how CXF matches up > with SWS. I know that CXF allows contract-first development, but is it as > simple as SWS? For example, with SWS, all I need to do is define the XSD > for my types (the messages and such being passed or returned). I can then > have SWS generate the WSDL using basic conventions and the XSDs defined. The > only other thing to do is to implement the endpoints (Java) that will handle > the service. From looking through the CXF site, it looks that if you do > contract-first, you must define the WSDL along with the XSDs and Java > service implementations (probably using JSR-181). Is this the case? > > Thanks in advance! > > -los cxftest.tar.gz Description: application/compressed-tar
RE: contract-first with only xsd
Are you talking about the annotations on your JAXB stubs? Or on your service endpoints? FWIW, we're not using JaxMe, we're using the JAXB2 maven plugin from dev.java.net: https://maven-jaxb2-plugin.dev.java.net/ On Tue, 2007-09-18 at 10:25 -0400, Mulligan, Patrick wrote: > I suppose that would be using the JaxMe plugin. > > I see there are other toolkits as well to do this. Anyone care to > comment on those? > > I guess I was wondering if there was a tool to take the type info, the > annotations, etc, all in one shot? > > -----Original Message- > From: Eric Miles [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 18, 2007 10:18 AM > To: cxf-user@incubator.apache.org > Subject: RE: contract-first with only xsd > > We're using the Maven2 JAXB plugin. You need stubs for the schema to > manipulate the objects within your endpoint implementation. > > > > On Tue, 2007-09-18 at 10:05 -0400, Mulligan, Patrick wrote: > > What are you using to generate the jaxb stubs? > > > > Can't the annotations drive it all? > > > > -Original Message- > > From: Eric Miles [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, September 18, 2007 10:00 AM > > To: cxf-user@incubator.apache.org > > Subject: Re: contract-first with only xsd > > > > Los, > > > > It is just as easy to define contract first, without having to create > a > > WSDL. For our project, we create our XSDs, generate stubs with JAXB, > > create our endpoint implementations (we use annotations), and wire it > > all up with Spring. CXF takes care of the WSDL generation. It really > > is easy. I'm not sure there is an example within the CXF toolkit but > I > > could probably come up with one fairly fast if you need one. > > > > Eric > > > > > > > > On Tue, 2007-09-18 at 06:49 -0700, moraleslos wrote: > > > Hi-- > > > > > > Having gone through the Spring Web Services (SWS) manifesto about > > > contract-first as well as their sample examples, I wonder how CXF > > matches up > > > with SWS. I know that CXF allows contract-first development, but is > > it as > > > simple as SWS? For example, with SWS, all I need to do is define > the > > XSD > > > for my types (the messages and such being passed or returned). I > can > > then > > > have SWS generate the WSDL using basic conventions and the XSDs > > defined. The > > > only other thing to do is to implement the endpoints (Java) that > will > > handle > > > the service. From looking through the CXF site, it looks that if > you > > do > > > contract-first, you must define the WSDL along with the XSDs and > Java > > > service implementations (probably using JSR-181). Is this the case? > > > > > > > Thanks in advance! > > > > > > -los
Re: CXF+ACEGI + Anybody out there?
It was a bit of extra coding, as there is some dis join between what
WS-Security wants to do and what Acegi wants to do (at least for
UsernameToken authentication). We also have a business requirement due
to some legacy data setup that proved to be problematic with WSS4J.
WSS4J wants you to return the password and it perform the password
comparison. Acegi security also wants to perform the password
comparison. Two separate process that you're trying to integrate that
both want to run the show...problem there :) Our business requirement
issue with WSS4J is we keep our passwords hashed in our DB. Allowing
WSS4J to perform our authentication would never work as we need to hash
the password in the token and compare that against the hashed password
in the DB. From my understanding, I can not change this process with
WSS4J. Acegi is nice in this regard as it allows you to provide a
password encoder that it will use against the provided password.
With all these factors, our strategy was to allow WSS4J to process the
UsernameToken to provide a Principal object with a username/password
that was provided in the header. Then after the processing for WSS4J we
have our own interceptor in the interceptor chain that will use the
Principal object to delegate authentication to the Acegi authentication
manager. Here's a snippet of our interceptor (apologize if formatting
turns out crappy):
// get the principal object
WSUsernameTokenPrincipal principal = (WSUsernameTokenPrincipal)
secRes.getPrincipal();
Authentication auth = new
UsernamePasswordAuthenticationToken(principal.getName(),
principal.getPassword());
auth = authenticationManager.authenticate(auth);
if(!auth.isAuthenticated()) {
throw new AuthorizationException("This user is not authentic");
}
SecurityContextHolder.getContext().setAuthentication(auth);
Now that the authentication object has been set within the context, you
can use Acegi throughout your code like you would any other webapp. It
really is nice. We even use Acegi annotations on our endpoints and use
AOP and a Role voter to authorize our web services. It makes for a
fairly clean solution. We use the same service classes for our web
services and our web application without any code change to support
authorization from each entry point. Code reuse bliss.
I am not all that familiar with WSS4J, so I could be wrong in some of my
understandings of how it works with WS-Security. Does anyone else have
a different experience or understanding of UsernameToken authentication
with WSS4J? Does this seem like a reasonable approach?
Eric
On Tue, 2007-09-18 at 10:50 +0200, Dan Diephouse wrote:
> I guess I'm interesting in seeing any code that could be shared between
> users come into CXF. Specifically, if I remember correctly from the
> solutions that I've seen, the WS-Security integration in particular
> takes an extra bit of coding. Would be very happy to include your
> contributions.
> Cheers,
> - Dan
>
> Eric Miles wrote:
> > Dan,
> >
> > What sort of solution are you looking for? We are using an
> > Acegi/Spring/CXF implementation at our company where we are using
> > WS-Security and Acegi for authentication and AOP/Acegi for
> > authorization. We could be interested in contributing.
> >
> > Thanks,
> > Eric
> >
> >
> > On Tue, 2007-09-18 at 00:15 +0200, Dan Diephouse wrote:
> >
> >> And I want somebody to contribute a cleaner solution :-D
> >>
> >> I know there is a lot of stuff we could do with Spring Security/Acegi
> >> that would be super cool. It'd be a real low barrier way to contribute
> >> some stuff if anyone is interested.
> >>
> >> Cheers,
> >> - Dan
> >>
> >> mattmadhavan wrote:
> >>
> >>> Hi Ray,
> >>> No I do not want the client side to tell the server! Thats my point. Some
> >>> good blogs I have seen, do that! Where the client 'tells' which handler to
> >>> use!
> >>>
> >>> I want a cleaner ACEGI+ XFIRE solution!
> >>>
> >>> Thanks
> >>> Matt
> >>>
> >>>
> >>>
> >>> Ray Krueger wrote:
> >>>
> >>>
> >>>> You want the client to tell the server how to do security? That sounds
> >>>> crazy :)
> >>>>
> >>>> Your client side should either be doing http based security or
> >>>> ws-security. That doesn't have anything to do with Acegi at that
>
Re: CXF+ACEGI + Anybody out there?
Actually, here is the code. Attached is the WSS4J callback class and the CXF interceptor that uses the Acegi authentication manager for authentication. Pretty simple and straight forward. If you look at the callback handler, you can see my comment regarding the WSS4J engine. I do have one concern in that this solution might not have worked for a digest UT. I'll have to revisit as it has been several months since we first looked at it. However, this is a spring board for any discussions. (Spring pun not intended) Eric On Tue, 2007-09-18 at 08:10 -0700, mattmadhavan wrote: > Eric, > Do you mind posting a complete example. May be we can have a very > constructive discussions based on that. > > Thanks > Matt > > > > > BigEHokie wrote: > > > > Dan, > > > > What sort of solution are you looking for? We are using an > > Acegi/Spring/CXF implementation at our company where we are using > > WS-Security and Acegi for authentication and AOP/Acegi for > > authorization. We could be interested in contributing. > > > > Thanks, > > Eric > > > > > > On Tue, 2007-09-18 at 00:15 +0200, Dan Diephouse wrote: > >> And I want somebody to contribute a cleaner solution :-D > >> > >> I know there is a lot of stuff we could do with Spring Security/Acegi > >> that would be super cool. It'd be a real low barrier way to contribute > >> some stuff if anyone is interested. > >> > >> Cheers, > >> - Dan > >> > >> mattmadhavan wrote: > >> > Hi Ray, > >> > No I do not want the client side to tell the server! Thats my point. > >> Some > >> > good blogs I have seen, do that! Where the client 'tells' which handler > >> to > >> > use! > >> > > >> > I want a cleaner ACEGI+ XFIRE solution! > >> > > >> > Thanks > >> > Matt > >> > > >> > > >> > > >> > Ray Krueger wrote: > >> > > >> > > You want the client to tell the server how to do security? That > >> sounds > >> > > crazy :) > >> > > > >> > > Your client side should either be doing http based security or > >> > > ws-security. That doesn't have anything to do with Acegi at that > >> > > point. > >> > > > >> > > On 9/14/07, Zarar Siddiqi <[EMAIL PROTECTED]> wrote: > >> > > > >> > > > I'm trying to understand what you're saying but am having > >> difficulty. But > >> > > > here goes: > >> > > > > >> > > > > >> > > > > Can some one point me to some docs on the CXF and ACEGI > >> integration > >> > > > > or CXF and security like authentication and authorization. > >> > > > > > >> > > > I use Acegi for authorization purposes only. IMHO it doesn't really > >> make > >> > > > sense for authentication (WS-Security can do that). So I use the > >> > > > MethodSecurityInterceptor and BeanNameAutoProxyCreator to manage > >> calls to > >> > > > my > >> > > > service level methods. The Acegi docs can help you there, the only > >> > > > difference I think is that you have to set the authentication token > >> > > > yourself, e.g.: > >> > > > > >> > > > UsernamePasswordAuthenticationToken token = new > >> > > > UsernamePasswordAuthenticationToken( > >> > > >user.getUsername(), user.getPassword(), user.getAuthorities()); > >> > > > // Populate Acegi Security Context > >> > > > SecurityContextHolder.getContext().setAuthentication(token); > >> > > > > >> > > > > >> > > > > I found some blogs on the CXF+ACEGI, but it is Java centric. On > >> the > >> > > > > > >> > > > client > >> > > > > >> > > > > side > >> > > > > we need to set the which class handles the security on the Server > >> side! > >> > > > > But if > >> > > > > I am using some other language for clients like C# it doesn't > >> seem to > >> > > > > > >> > > > be > >> > > > > >> > > > > the proper way! > >> > > > > > >> > > > You can pass the class name which handles security to the server > >> (crazy > >> > > > thought I think!) using a header element and then parse it using > >> CXF > >> > > > interceptors. > >> > > > > >> > > > Zarar > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > mattmadhavan wrote: > >> > > > > >> > > > > Any Help will be appreciated! > >> > > > > > >> > > > > > >> > > > > > >> > > > > mattmadhavan wrote: > >> > > > > > >> > > > > > Hello, > >> > > > > > Can some one point me to some docs on the CXF and ACEGI > >> integration or > >> > > > > > CXF and security like authentication and authorization. Some > >> sample > >> > > > > > > >> > > > app > >> > > > > >> > > > > > will even be great. > >> > > > > > > >> > > > > > I found some blogs on the CXF+ACEGI, but it is Java centric. On > >> the > >> > > > > > client side we need to set the which class handles the security > >> on the > >> > > > > > Server side! But if I am using some other language for clients > >> like C# > >> > > > > > > >> > > > it > >> > > > > >> > > > > > does n't seem to be the proper way! > >> > > > > > > >> > > > > > Any ideas will be greatly appreciated. > >> > > > > > > >> > > > >
Re: Schema-First Development with CXF
Dan, I found out a few things, that my services WERE actually working as expected, provided I made sure I did a few things. When looking at the WSDL, notice the wsdl:import statement. You should see that it points to servlet generated WSDL and should contain your imported schema. Secondly (this is a problem I had as well), ensure that the @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE, style = SOAPBinding.Style.DOCUMENT) is on the INTERFACE. I'm not sure if this is a bug or not, but it wasn't required by XFire however it is required by CXF. I had it on my Impl and the framework was wrapping all of my requests, when it shouldn't have been. Good luck, Eric On Wed, 2007-09-19 at 19:25 +1000, Daniel Pike wrote: > Hi, > > Just wondering if there was any further update on this? > > Daniel. > > On 9/5/07, Dan Diephouse <[EMAIL PROTECTED]> wrote: > > > > Hi Eric, > > > > I'll do some more digging into this today - I lost track of the thread. > > Provided you aren't too frustrated with me/us, I'll see if I can't dig out > > the problem and get things working for you. > > > > - Dan > > > > Eric Miles wrote: > > > > Daniel, > > > > I re-asked my question again last week and haven't heard anything in > > about 7 days on the subject. I've taken that to signal it's either a > > fairly big problem and it's taking them a while to look at it or it's > > just not that important. Unfortunately, it's such a severe issue > > (doesn't work), it is keeping our group from moving from XFire to CXF. > > > > Eric > > > > > > On Sat, 2007-09-01 at 19:35 +1000, Daniel Pike wrote: > > > >Hi Dan & Eric, > > > > I have just finished testing this and have found that I am also experiencing > > the same issue. When I specify the schema location, the definition does not > > actually appear in the WSDL. Any ideas on what may be causing this? > > > > Regards, > > > > Daniel. > > > > > > > > On 8/30/07, Eric Miles <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: > > > > Any feedback on this question? > > > > On Tue, 2007-08-28 at 10:02 -0400, Eric Miles wrote: > > > >Dan, > > > > On the heels of the trouble I'm having with the suggestion below, I > > decided to give the 2.1 snapshot version a try with the fixed Spring > > namespace support. This actually does register my service and I can > > view the WSDL. However, the behavior is not as I expected. In XFire > > 1.2.6, when I gave my schema locations, the WSDL Generator took my > > schemas and added them to the generated WSDL. With CXF 2.1-SNAPSHOT, > > this is not happening. Is this the expected behavior? Do I need more > > configuration in my Spring context? > > > > Here is the configuration: > > > > > implementor="#tawsMobileServiceImpl" name="MobileService" > > address="/MobileService"> > > > > > > > > > > > > > > > > > > classpath:com/kronos/taws/services/mobile/MobileService.xsd > > > > > > > > > > Attached are the 2 WSDLs. One generated from XFire 1.2.6 and one from > > CXF 2.1-SNAPSHOT. Keep in mind, the only thing I have changed in the > > interface and impl classes were the addition of the portType in the > > CXF version (to get around the use of the classname from the proxy > > class). > > > > Thanks, > > Eric > > > > On Mon, 2007-08-27 at 18:22 -0400, Dan Diephouse wrote: > > > > Hi Daniel (and Eric who is hopefully still listening), > > > > I've just fixed this problem in SVN. The problem was I added > > > > capabilities to > > > > do this from the API, but forgot to actually write a test for the XML > > > > config > > > > - which wasn't fully working :-(. Dan Kulp will be publishing some new > > snapshots tonight I think, at which point you can test out the fixed > > functionality. > > > > I did think of a workaround though. You could do something like this: > > > > > > > > > > > >> > > > > > class="my.proto.HelloWorldImpl"> > > > > > > > > > > > > > > > > > > > > /META-INF/schemas/helloWorldSchema.xsd > > > >
Re: CXF+ACEGI + Anybody out there?
We started some discussion the other day about CXF+Acegi out there the other day, but hadn't seen anything since. Any discussion after I sent the source code or my findings with integrating the two? On Tue, 2007-09-18 at 11:18 -0400, Eric Miles wrote: > Actually, here is the code. Attached is the WSS4J callback class and > the CXF interceptor that uses the Acegi authentication manager for > authentication. > > Pretty simple and straight forward. If you look at the callback > handler, you can see my comment regarding the WSS4J engine. I do have > one concern in that this solution might not have worked for a digest UT. > I'll have to revisit as it has been several months since we first looked > at it. > > However, this is a spring board for any discussions. (Spring pun not > intended) > > Eric > > > On Tue, 2007-09-18 at 08:10 -0700, mattmadhavan wrote: > > Eric, > > Do you mind posting a complete example. May be we can have a very > > constructive discussions based on that. > > > > Thanks > > Matt > > > > > > > > > > BigEHokie wrote: > > > > > > Dan, > > > > > > What sort of solution are you looking for? We are using an > > > Acegi/Spring/CXF implementation at our company where we are using > > > WS-Security and Acegi for authentication and AOP/Acegi for > > > authorization. We could be interested in contributing. > > > > > > Thanks, > > > Eric > > > > > > > > > On Tue, 2007-09-18 at 00:15 +0200, Dan Diephouse wrote: > > >> And I want somebody to contribute a cleaner solution :-D > > >> > > >> I know there is a lot of stuff we could do with Spring Security/Acegi > > >> that would be super cool. It'd be a real low barrier way to contribute > > >> some stuff if anyone is interested. > > >> > > >> Cheers, > > >> - Dan > > >> > > >> mattmadhavan wrote: > > >> > Hi Ray, > > >> > No I do not want the client side to tell the server! Thats my point. > > >> Some > > >> > good blogs I have seen, do that! Where the client 'tells' which handler > > >> to > > >> > use! > > >> > > > >> > I want a cleaner ACEGI+ XFIRE solution! > > >> > > > >> > Thanks > > >> > Matt > > >> > > > >> > > > >> > > > >> > Ray Krueger wrote: > > >> > > > >> > > You want the client to tell the server how to do security? That > > >> sounds > > >> > > crazy :) > > >> > > > > >> > > Your client side should either be doing http based security or > > >> > > ws-security. That doesn't have anything to do with Acegi at that > > >> > > point. > > >> > > > > >> > > On 9/14/07, Zarar Siddiqi <[EMAIL PROTECTED]> wrote: > > >> > > > > >> > > > I'm trying to understand what you're saying but am having > > >> difficulty. But > > >> > > > here goes: > > >> > > > > > >> > > > > > >> > > > > Can some one point me to some docs on the CXF and ACEGI > > >> integration > > >> > > > > or CXF and security like authentication and authorization. > > >> > > > > > > >> > > > I use Acegi for authorization purposes only. IMHO it doesn't really > > >> make > > >> > > > sense for authentication (WS-Security can do that). So I use the > > >> > > > MethodSecurityInterceptor and BeanNameAutoProxyCreator to manage > > >> calls to > > >> > > > my > > >> > > > service level methods. The Acegi docs can help you there, the only > > >> > > > difference I think is that you have to set the authentication token > > >> > > > yourself, e.g.: > > >> > > > > > >> > > > UsernamePasswordAuthenticationToken token = new > > >> > > > UsernamePasswordAuthenticationToken( > > >> > > >user.getUsername(), user.getPassword(), user.getAuthorities()); > > >> > > > // Populate Acegi Security Context > > >> > > > SecurityContextHolder.getContext().setAuthentication(token)
Re: contract-first with only xsd
Dan, I do not do any schema validation so I can't help you on this one. Someone more experienced with JAXB and CXF is going to have to respond. Eric On Thu, 2007-09-27 at 18:40 +0200, Daniel Dienhardt wrote: > Thanks for that nice example, > > I tried to enable schema validation, but it did not work. > > my beans.xml: > >address="/MyService"> > > > classpath:com/mycompany/test/MyService.xsd > > > > > > > > I added a restriction to SomeType/id and it was correctly rejected with > invalid data -- but also with correct data this is the stack trace: > > INFO: Interceptor has thrown exception, unwinding now > org.apache.cxf.interceptor.Fault: Marshalling Error: cvc-elt.1: Cannot > find the declaration of element 'SomeOperationResponse'. > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:179) > at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:42) > at > org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:84) > at > org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutInterceptor.java:68) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207) > at > org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:74) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:73) > at > org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79) > at > org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:236) > at > org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:141) > at > org.apache.cxf.transport.servlet.CXFServlet.invoke(CXFServlet.java:278) > at > org.apache.cxf.transport.servlet.CXFServlet.doPost(CXFServlet.java:256) > > > Do you have any idea what I'm doing wrong? > > Thanks in advance > > Daniel Dienhardt > > moraleslos schrieb: > > Thanks Eric. > > > > Just what I needed! I'll use your sample as a template. Thanks again! > > > > -los > > > > > > > > BigEHokie wrote: > >> Here's just a quick sample. > >> > >> I'm not stating this is the proper or correct way to do anything. > >> However, this is how we are currently using CXF. > >> > >> The CXF guys can provide you with better direction on how you SHOULD be > >> creating your services. They might tell you this approach is a bad > >> approach. > >> > >> Eric > >> > >> On Tue, 2007-09-18 at 06:49 -0700, moraleslos wrote: > >>> Hi-- > >>> > >>> Having gone through the Spring Web Services (SWS) manifesto about > >>> contract-first as well as their sample examples, I wonder how CXF matches > >>> up > >>> with SWS. I know that CXF allows contract-first development, but is it > >>> as > >>> simple as SWS? For example, with SWS, all I need to do is define the XSD > >>> for my types (the messages and such being passed or returned). I can > >>> then > >>> have SWS generate the WSDL using basic conventions and the XSDs defined. > >>> The > >>> only other thing to do is to implement the endpoints (Java) that will > >>> handle > >>> the service. From looking through the CXF site, it looks that if you do > >>> contract-first, you must define the WSDL along with the XSDs and Java > >>> service implementations (probably using JSR-181). Is this the case? > >>> > >>> Thanks in advance! > >>> > >>> -los > >> > >> > > > > >
Re: contract-first with only xsd
Yeah, that's a bug that is fixed in CXF 2.0.2. Upgrade to that version and you should be good. On Mon, 2007-10-01 at 06:54 -0700, gdprao wrote: > Hi, > > I have tried contract-first XSD approach in my service. I have generated > JAXB mappings from the XSD and used them in my service. The service is > working fine without specifying . If I use that, I am > getting the following exception at startup. I am using CXF2.0.1. Any help > is appreciated. > > applictionContext-cxf.xml: > http://www.springframework.org/schema/beans"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:jaxws="http://cxf.apache.org/jaxws"; > xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd > http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";> > > > > > > resource="classpath:META-INF/cxf/cxf-extension-http-binding.xml" /> > > >implementor="#serviceImplementor" address="/MyService"> > > > classpath:com/mydomain/schemas/serviceSchema.xsd > > > > > 007-10-01 06:34:16,346 - ERROR > (org.apache.catalina.core.StandardContext:listenerStart:3767) - Exception > sending context initialized event to listener instance of class > org.springframework.web.context.ContextLoaderListener > org.springframework.beans.factory.parsing.BeanDefinitionParsingException: > Configuration problem: Cannot locate BeanDefinitionParser for element > [schemaLocation] > Offending resource: ServletContext resource > [/WEB-INF/applicationContext-cxf.xml] > at > org.springframework.beans.factory.parsing.FailFastProblemReporter.fatal(FailFastProblemReporter.java:59) > at > org.springframework.beans.factory.parsing.ReaderContext.fatal(ReaderContext.java:68) > at > org.springframework.beans.factory.parsing.ReaderContext.fatal(ReaderContext.java:55) > at > org.springframework.beans.factory.xml.NamespaceHandlerSupport.findParserForElement(NamespaceHandlerSupport.java:79) > at > org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69) > at > org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1114) > at > org.apache.cxf.configuration.spring.AbstractBeanDefinitionParser.getAndRegisterFirstChild(AbstractBeanDefinitionParser.java:175) > at > org.apache.cxf.configuration.spring.AbstractBeanDefinitionParser.setFirstChildAsProperty(AbstractBeanDefinitionParser.java:139) > at > org.apache.cxf.jaxws.spring.EndpointDefinitionParser.doParse(EndpointDefinitionParser.java:112) > at > org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser.parseInternal(AbstractSingleBeanDefinitionParser.java:81) > at > org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:56) > at > org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69) > at > org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1114) > > > > > > > > BigEHokie wrote: > > > > Here's just a quick sample. > > > > I'm not stating this is the proper or correct way to do anything. > > However, this is how we are currently using CXF. > > > > The CXF guys can provide you with better direction on how you SHOULD be > > creating your services. They might tell you this approach is a bad > > approach. > > > > Eric > > > > On Tue, 2007-09-18 at 06:49 -0700, moraleslos wrote: > >> Hi-- > >> > >> Having gone through the Spring Web Services (SWS) manifesto about > >> contract-first as well as their sample examples, I wonder how CXF matches > >> up > >> with SWS. I know that CXF allows contract-first development, but is it > >> as > >> simple as SWS? For example, with SWS, all I need to do is define the XSD > >> for my types (the messages and such being passed or returned). I can > >> then > >> have SWS generate the WSDL using basic conventions and the XSDs defined. > >> The > >> only other thing to do is to implement the endpoints (Java) that will > >> handle > >> the service. From looking through the CXF site, it looks that if you do > >> contract-first, you must define the WSDL along with the XSDs and Java > >> service implementations (probably using JSR-181). Is this the case? > >> > >> Thanks in advance! > >> > >> -los > > > > > > >
Re: Ensuring CXF soap is behind SSL
If you're using Spring and Acegi, you could use a secure channel filter. On Tue, 2008-02-05 at 12:44 -0500, [EMAIL PROTECTED] wrote: > I want to make sure any messages not encrypted with SSL are rejected by the > CXF container. What configuration is neccessary for this? > > I've tried setting the location to an https address but this is unsufficient. > The only documentation I've found on the subject refers to client, not > server, configuration. > > ? > ??? name="HelloWorldService"> > ? https://localhost:8080/HelloWorldService"/> > ??? > ? > > Thanks! > > > > > More new features than ever. Check out the new AOL Mail ! - > http://webmail.aol.com
Services documentation
All, I know the WSDL is to service as a documentation tool to identify what services are available and how to connect them, but I'm looking for something a little more that I could hand over to clients. I was looking at a couple of tools that take the WSDL and generate some javadoc like documentation that seemed to work OK, however I have a small issue. I have placed xsd:documentation throughout my schema and it seems as though the WSDL that is being generated by CXF, all documentation elements have been removed. Is there a way to control this? Also, do any of you have any recommendations for tools/products to look at? Does CXF have anything built in for this? Thanks all, Eric
Re: Services documentation
Well, I was mistaken that CXF was stripping the documentation elements. Sorry for the false alarm. :) However, is there a way to add documentation elements to the generated WSDL? I thought XFire provided this (there is a link on the old XFire site to documenting the WSDL), has this feature made it's way over to CXF? If so, how does one go about doing this? Thanks again, Eric On Thu, 2008-02-21 at 12:22 -0500, Eric Miles wrote: > All, > > I know the WSDL is to service as a documentation tool to identify what > services are available and how to connect them, but I'm looking for > something a little more that I could hand over to clients. I was > looking at a couple of tools that take the WSDL and generate some > javadoc like documentation that seemed to work OK, however I have a > small issue. I have placed xsd:documentation throughout my schema and > it seems as though the WSDL that is being generated by CXF, all > documentation elements have been removed. Is there a way to control > this? > > Also, do any of you have any recommendations for tools/products to look > at? Does CXF have anything built in for this? > > Thanks all, > Eric
