date:20071017

Hi all,

This is the scenario.
I created a WSDL and the generated the server side and client side code
using the WSDL2Java tool. After that i published the Web service in Jetty,,
as done by the generated server code.
The web service is working fine when i tested it using a standalone client.

I am having a web application which is deployed in JBoss. Now i need to
access the Web service thru a client which sits in this web application.
However, now i am now getting the following error:
11:05:26,030 FATAL [application] javax.ejb.EJBTransactionRolledbackException:
java.lang.UnsupportedOperationException: s
etProperty must be overridden by all subclasses of SOAPMessage
javax.faces.el.EvaluationException:
javax.ejb.EJBTransactionRolledbackException:
java.lang.UnsupportedOperationException
: setProperty must be overridden by all subclasses of SOAPMessage
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke
(MethodBindingMethodExpressionAdapter.java:9
1)
at com.sun.faces.application.ActionListenerImpl.processAction(
ActionListenerImpl.java:91)
at javax.faces.component.UICommand.broadcast(UICommand.java:383)

This comes up when i am calling the Webservice methods using the generated
client side stub.

This does not come when i run the Web service client in standalone.

Appreciate if someone can help or give any feedback.

Thanks in advance.

RE: Disable access to wsdl in Servlet transport

Well, perhaps you do.

Use the CXF config to hang a handler in front of the CXF handler that
filter-feeds for ?wsdl? I can't prove that jetty allows one handler to
peek into a context owned by a successor.

 -Original Message-
 From: James Mao [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, October 17, 2007 6:11 AM
 To: cxf-user@incubator.apache.org
 Subject: Re: Disable access to wsdl in Servlet transport

 If you're working with a container, i think you can do this through
 configuration of the container, to redirect the ?wsdl to a more
friendly
 page,
 say, please contact ... to get the wsdl, or list the service you
have
 etc.

 I guess we don't have this function in a standalone service, do we?

 James

  But I think we still can do it in the filter, such as:

  doFilter() {
if (URLHasWsdlSuffix()) {
  //Do the Authentication
} else {
  //access the web service  }
  }

  If you don't want to use the filter to do the security, maybe need
to
  add an interceptor or other codes before dealing with
  WSDLQueryHandler, as willem pointed out in the other mail.

  HTH..

  Thanks
  Jeff

  Glen Mazza wrote:
  Jeff,
  I think he doesn't want people to see the WSDL file.  It's not the
  service he wants to restrict, but viewing its WSDL.  I don't know
if
  that can be done.

  Glen

  Am Mittwoch, den 17.10.2007, 11:11 +0800 schrieb Jeff Yu:

  Hi,

  There is an easy way that I came up is to use a filter in web.xml
to
  restrict the access.

  Say there are three services: A,B,C  , we want to restrict the B,C
  service. we can pulish the services as following:

  http://host.com/services/secure/B
  http://host.com/services/secure/C
  http://host.com/services/A.

  And then we will config a filter to restrict the
  http://lhost.com/service/secure url to do the authentication.

  So people can access the A service without any restriction, but
need
  to get authentication to access B,C service.

  Thanks
  Jeff

  Egor Samarkhanov wrote:

  Hello !

  How can I restrict access to WSDL of my service?
  I don't want someone to access the
  http//host.com/services/myservice?wsdl content.
  And I use Servlet transport.

  Thanks,
  Egor Samarkhanov ([EMAIL PROTECTED])

Re: error when accessing Webservice client within JBoss

2007-10-17 Thread Jeff Yu


Hi,

It seems error from your web app code, since it says: 

java.lang.UnsupportedOperationException: s
etProperty must be overridden by all subclasses of SOAPMessage


can you show more codes...

Thanks
Jeff



shaminda perera wrote:

Hi all,

This is the scenario.
I created a WSDL and the generated the server side and client side code
using the WSDL2Java tool. After that i published the Web service in Jetty,,
as done by the generated server code.
The web service is working fine when i tested it using a standalone client.

I am having a web application which is deployed in JBoss. Now i need to
access the Web service thru a client which sits in this web application.
However, now i am now getting the following error:
11:05:26,030 FATAL [application] javax.ejb.EJBTransactionRolledbackException:
java.lang.UnsupportedOperationException: s
etProperty must be overridden by all subclasses of SOAPMessage
javax.faces.el.EvaluationException:
javax.ejb.EJBTransactionRolledbackException:
java.lang.UnsupportedOperationException
: setProperty must be overridden by all subclasses of SOAPMessage
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke
(MethodBindingMethodExpressionAdapter.java:9
1)
at com.sun.faces.application.ActionListenerImpl.processAction(
ActionListenerImpl.java:91)
at javax.faces.component.UICommand.broadcast(UICommand.java:383)

This comes up when i am calling the Webservice methods using the generated
client side stub.

This does not come when i run the Web service client in standalone.

Appreciate if someone can help or give any feedback.

Thanks in advance.

Re: Get SOAPEnvelope as String

2007-10-17 Thread Cencio


That works!

Just 2 questions:
the output also include 
?xml version=1.0 encoding=utf-8?
i have to manually remove it or there is some utility that do it for me?

The getTextContent() work fine or should output what i expected?
I would use saaj interface so future port to another saaj implementation is
more easy...

Thx for ur help


James Mao wrote:
 
 Try this
 
 org.apache.cxf.helpers.XMLUtils.toString(mySOAPMessage.getSOAPPart().getEnvelope())
 
 James
 
 
 i'm trying to get the SOAPEnvelope content as String. I tryed with

 mySOAPMessage.getSOAPPart().getEnvelope().getTextContent() 

 but the returned string of this envelope

 soapenv:Envelope
 xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
 xmlns:xsd=http://www.w3.org/2001/XMLSchema;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   soapenv:Body
  eseguiServizio xmlns=http://spcoop.it/cart/pdd-test;
 Richiestapersona nome=mario cognome=rossi/Richiesta
  /eseguiServizio
   /soapenv:Body
/soapenv:Envelope

 is just

 persona nome=mario cognome=rossi/


 It's correct? If is right how can i get the whole envelope as string?
 Thx
 Lorenzo
   
 
 

-- 
View this message in context: 
http://www.nabble.com/Get-SOAPEnvelope-as-String-tf4639292.html#a13251033
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Get SOAPEnvelope as String

2007-10-17 Thread James Mao

If you wish to work with the String level, then just substring the 
content you want, or just replace it with an empty string


Or

You probably should use SOAPMessage.writeTo() instead of getTextContent(),

Regards,
James


That works!

Just 2 questions:
the output also include 
?xml version=1.0 encoding=utf-8?

i have to manually remove it or there is some utility that do it for me?

The getTextContent() work fine or should output what i expected?
I would use saaj interface so future port to another saaj implementation is
more easy...

Thx for ur help


James Mao wrote:
  

Try this

org.apache.cxf.helpers.XMLUtils.toString(mySOAPMessage.getSOAPPart().getEnvelope())

James




i'm trying to get the SOAPEnvelope content as String. I tryed with

mySOAPMessage.getSOAPPart().getEnvelope().getTextContent() 


but the returned string of this envelope

soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  soapenv:Body
 eseguiServizio xmlns=http://spcoop.it/cart/pdd-test;
Richiestapersona nome=mario cognome=rossi/Richiesta
 /eseguiServizio
  /soapenv:Body
   /soapenv:Envelope

is just

persona nome=mario cognome=rossi/


It's correct? If is right how can i get the whole envelope as string?
Thx
Lorenzo

RE: Disable access to wsdl in Servlet transport

2007-10-17 Thread Beryozkin, Sergey

Can you do it using an httpj configuration ?

Cheers, Sergey

-Original Message-
From: Benson Margulies [mailto:[EMAIL PROTECTED] 
Sent: 17 October 2007 11:36
To: cxf-user@incubator.apache.org
Subject: RE: Disable access to wsdl in Servlet transport

Well, perhaps you do.

Use the CXF config to hang a handler in front of the CXF handler that
filter-feeds for ?wsdl? I can't prove that jetty allows one handler to
peek into a context owned by a successor.

 -Original Message-
 From: James Mao [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, October 17, 2007 6:11 AM
 To: cxf-user@incubator.apache.org
 Subject: Re: Disable access to wsdl in Servlet transport

 If you're working with a container, i think you can do this through
 configuration of the container, to redirect the ?wsdl to a more
friendly
 page,
 say, please contact ... to get the wsdl, or list the service you
have
 etc.

 I guess we don't have this function in a standalone service, do we?

 James

  But I think we still can do it in the filter, such as:

  doFilter() {
if (URLHasWsdlSuffix()) {
  //Do the Authentication
} else {
  //access the web service  }
  }

  If you don't want to use the filter to do the security, maybe need
to
  add an interceptor or other codes before dealing with
  WSDLQueryHandler, as willem pointed out in the other mail.

  HTH..

  Thanks
  Jeff

  Glen Mazza wrote:
  Jeff,
  I think he doesn't want people to see the WSDL file.  It's not the
  service he wants to restrict, but viewing its WSDL.  I don't know
if
  that can be done.

  Glen

  Am Mittwoch, den 17.10.2007, 11:11 +0800 schrieb Jeff Yu:

  Hi,

  There is an easy way that I came up is to use a filter in web.xml
to
  restrict the access.

  Say there are three services: A,B,C  , we want to restrict the B,C
  service. we can pulish the services as following:

  http://host.com/services/secure/B
  http://host.com/services/secure/C
  http://host.com/services/A.

  And then we will config a filter to restrict the
  http://lhost.com/service/secure url to do the authentication.

  So people can access the A service without any restriction, but
need
  to get authentication to access B,C service.

  Thanks
  Jeff

  Egor Samarkhanov wrote:

  Hello !

  How can I restrict access to WSDL of my service?
  I don't want someone to access the
  http//host.com/services/myservice?wsdl content.
  And I use Servlet transport.

  Thanks,
  Egor Samarkhanov ([EMAIL PROTECTED])

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

Re: Get SOAPEnvelope as String

2007-10-17 Thread Cencio


If the message have also some attachments SOAPMessage.writeTo() should write
them too (can't verify... got an error if i test with a message with
attachment.. Dan Kulp is checking for this) and i want only the envelope...
i'll remove it manually...


Any idea if the logic of getTextContent is correct?


Thx,
 Lorenzo



James Mao wrote:
 
 If you wish to work with the String level, then just substring the 
 content you want, or just replace it with an empty string
 
 Or
 
 You probably should use SOAPMessage.writeTo() instead of getTextContent(),
 
 Regards,
 James
 
 That works!

 Just 2 questions:
 the output also include 
 ?xml version=1.0 encoding=utf-8?
 i have to manually remove it or there is some utility that do it for me?

 The getTextContent() work fine or should output what i expected?
 I would use saaj interface so future port to another saaj implementation
 is
 more easy...

 Thx for ur help


 James Mao wrote:
   
 Try this

 org.apache.cxf.helpers.XMLUtils.toString(mySOAPMessage.getSOAPPart().getEnvelope())

 James


 
 i'm trying to get the SOAPEnvelope content as String. I tryed with

 mySOAPMessage.getSOAPPart().getEnvelope().getTextContent() 

 but the returned string of this envelope

 soapenv:Envelope
 xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
 xmlns:xsd=http://www.w3.org/2001/XMLSchema;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   soapenv:Body
  eseguiServizio xmlns=http://spcoop.it/cart/pdd-test;
 Richiestapersona nome=mario
 cognome=rossi/Richiesta
  /eseguiServizio
   /soapenv:Body
/soapenv:Envelope

 is just

 persona nome=mario cognome=rossi/


 It's correct? If is right how can i get the whole envelope as string?
 Thx
 Lorenzo
   
   
 

   
 
 

-- 
View this message in context: 
http://www.nabble.com/Get-SOAPEnvelope-as-String-tf4639292.html#a13252005
Sent from the cxf-user mailing list archive at Nabble.com.

Re: error when accessing Webservice client within JBoss


Hi,

This looks to me as if it is a library problem. If you have bundled up 
the CXF classes in a war file then this will probably be what is happening.


Explanation as follows:

The JBoss implementation of SOAPMessage is an abstract class which 
provides default implementations of get/setProperty. The implementation 
is in a jar in $JBOSS_HOME/server/servername/deploy/jbossws.sar. The 
saaj jar which implements this abstract type also provides a 
META-INF/services file to define the SOAPMessage -- SOAPMessageImpl 
mapping. The file name is the fully qualified name of the SOAPMessage 
class and the contents of the file is a single line containing the fully 
qualified name of the implementation class. The mapped version of 
SOAPMessageImpl in the saaj implementation jar provided by JBoss relies 
upon inheriting these methods.


Now, if your app bundles the cxf libs into a war file under WEBINF/lib 
then it will be picking up its implementation of SOAPMessage from a CXF 
lib which does not provide the get/setProperty methods. However, the 
SOAFPFactory finder will still be trying to instantiate the JBoss 
SOAPMessageImpl.class because the resource lookup it employs to identify 
which class to use will find the META-INF/services mapping file. You 
need to add META-INF/services files to your war which establish the 
correct mapping from the CXF saaj SOAPMessage class to the appropriate 
SOAPMessageImpl class in the CXF libs -- actually, I am not sure that 
the target for the map in CXF is called SOAPMessageImpl, perhaps Dan, 
Willem et al could advise.


You may also find that jboswws.sar remaps several other classes which 
are looked up by a factory finder. You will probably need to add remap 
files in your war for these as well.


regards,

Andrew Dinn
---
(JBoss Transactions developer)

Jeff Yu wrote:

Hi,

It seems error from your web app code, since it says: 

java.lang.UnsupportedOperationException: s
etProperty must be overridden by all subclasses of SOAPMessage


can you show more codes...

Thanks
Jeff



shaminda perera wrote:

Hi all,

This is the scenario.
I created a WSDL and the generated the server side and client side code
using the WSDL2Java tool. After that i published the Web service in 
Jetty,,

as done by the generated server code.
The web service is working fine when i tested it using a standalone 
client.


I am having a web application which is deployed in JBoss. Now i need to
access the Web service thru a client which sits in this web application.
However, now i am now getting the following error:
11:05:26,030 FATAL [application] 
javax.ejb.EJBTransactionRolledbackException:

java.lang.UnsupportedOperationException: s
etProperty must be overridden by all subclasses of SOAPMessage
javax.faces.el.EvaluationException:
javax.ejb.EJBTransactionRolledbackException:
java.lang.UnsupportedOperationException
: setProperty must be overridden by all subclasses of SOAPMessage
at 
javax.faces.component.MethodBindingMethodExpressionAdapter.invoke

(MethodBindingMethodExpressionAdapter.java:9
1)
at com.sun.faces.application.ActionListenerImpl.processAction(
ActionListenerImpl.java:91)
at javax.faces.component.UICommand.broadcast(UICommand.java:383)

This comes up when i am calling the Webservice methods using the 
generated

client side stub.

This does not come when i run the Web service client in standalone.

Appreciate if someone can help or give any feedback.

Thanks in advance.

  




--
JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod 
Street, Windsor, Berkshire,

SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David 
Owens (Ireland)

RE: simple-frontend.html

My opinion is that using the Simple front end with an interface (as
opposed to a WSDL) is a gun pointed firmly at the user's foot, and we
should prohibit it.

Jonathan, I can't prove it today, but my gut feeling is that you are
still experiencing the client constructing a different contract than the
server is using. Consuming the WSDL is the only really reliable way to
get them in sync. At least, I'd suggest trying the WSDL-consumption
alternative and see if it works, and we can go from there.

 -Original Message-
 From: Jonathan Slate [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, October 17, 2007 8:26 AM
 To: cxf-user@incubator.apache.org
 Subject: Re: simple-frontend.html
 
 Thanks Jeff for making this change, it's certainly more visible.
 However, I'm not sure that this is the same problem. The JIRA talks
 about the argument name being wrong (arg0 vs. title) but in my case,
the
 argument is arg0 and it worked fine w/out changing that. The problem
was
 the xmlns=http://example.hello/; argument appearing in the argument's
tag.
 
 I don't think someone would figure out from looking at the JIRA that
 they should use JaxWsProxyFactoryBean to avoid this problem. Or maybe
it
 *should* work with ClientProxyFactoryBean as documented and I'm doing
 something wrong, which would be nice to know. But I think it's ok,
 because that's what the Spring client example uses...
 
 -Jonathan
 
 Jeff Yu wrote:
  At the bottom of simple-frontend.html, there is a tip talked about
  this, see this JIRA for detail:
  https://issues.apache.org/jira/browse/CXF-897
 
  I updated it Others title to Well-Known issue for easily to get
  people's attention.
 
  Thanks
  Jeff
 
  Jonathan Slate wrote:
  Just wanted to ask about an issue I had and a possible problem with
  the documentation on the Web site.
 
  In trying to learn CXF, I created a HelloWorld service using Spring
,
  following the instructions on this page:
  http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html
 
  I then created a separate client application (not using Spring)
using
  the instructions on this page:
  http://cwiki.apache.org/CXF20DOC/simple-frontend.html (under
heading
  ClientProxyFactoryBean)
 
  This did not work, the text argument was null when the sayHi
method
  was called. So I set up a Spring client following the instructions
on
  the first page mentioned above. That worked. Eventually I figured
out
  that the Spring example had me creating a new JaxWsProxyFactoryBean
  whereas the simple frontend example had me creating a new
  ClientProxyFactoryBean. This resulted in slightly different SOAP
  calls, specifically in the arg0 tag:
 
  arg0 xmlns=http://example.hello/;World/arg0
  (ClientProxyFactoryBean)
  arg0World/arg0 (JaxWsProxyFactoryBean)
 
  For some reason, the former causes the method to be called with
arg0
  as null. Also, with the ClientProxyFactoryBean, the result returned
  to the client is null, despite the fact that the soap message
  contains the return value Hello null.
 
  Anyway, at this point it's working for me. But I'm wondering if
there
  is a simple explaination for this, and if perhaps the simple
frontend
  documentation should be updated to use JaxWsProxyFactoryBean.
 
  Thanks,
  Jonathan Slate

Re: error when accessing Webservice client within JBoss

Thanks Andrew and Jeff for the quick reply..

See below for some a more detailed stacktrace,,, if that helps..



12:18:05,101 FATAL [application] javax.ejb.EJBTransactionRolledbackException:
java.lang.UnsupportedOperationException: s

etProperty must be overridden by all subclasses of SOAPMessage

javax.faces.el.EvaluationException:
javax.ejb.EJBTransactionRolledbackException:
java.lang.UnsupportedOperationException

: setProperty must be overridden by all subclasses of SOAPMessage

at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke
(MethodBindingMethodExpressionAdapter.java:9

1)

at com.sun.faces.application.ActionListenerImpl.processAction(
ActionListenerImpl.java:91)

at javax.faces.component.UICommand.broadcast(UICommand.java:383)

at org.ajax4jsf.component.AjaxViewRoot.processEvents(
AjaxViewRoot.java:186)

at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(
AjaxViewRoot.java:164)

at org.ajax4jsf.component.AjaxViewRoot.processApplication(
AjaxViewRoot.java:352)

at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(
InvokeApplicationPhase.java:97)

at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java
:251)

at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java
:117)

at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:290)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at com.company.filter.doFilter(CompanyFilter.java:26)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:63)

at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java
:57)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:49)

at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(
HotDeployFilter.java:60)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:49)

at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java
:45)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:49)

at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java
:79)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:49)

at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java
:141)

at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(
ReplyHeaderFilter.java:96)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:230)

at org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:175)

at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(
SecurityAssociationValve.java:179)

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
AuthenticatorBase.java:433)

at org.jboss.web.tomcat.security.JaccContextValve.invoke(
JaccContextValve.java:84)

at org.apache.catalina.core.StandardHostValve.invoke(
StandardHostValve.java:128)

at org.apache.catalina.valves.ErrorReportValve.invoke(
ErrorReportValve.java:104)

at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(
CachedConnectionValve.java:157)

at org.apache.catalina.core.StandardEngineValve.invoke(
StandardEngineValve.java:109)

at org.apache.catalina.connector.CoyoteAdapter.service(
CoyoteAdapter.java:241)

at org.apache.coyote.http11.Http11Processor.process(
Http11Processor.java:844)

at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
Http11Protocol.java:580)

at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(
JIoEndpoint.java:447)

at java.lang.Thread.run(Thread.java:619)

Caused by: javax.ejb.EJBTransactionRolledbackException:

Re: simple-frontend.html

2007-10-17 Thread Jonathan Slate

Ok, now I think I understand the crux of the issue. As it's working for 
me now, I have to wonder... should I change it or go ahead with the old 
if it ain't broke don't fix it? No need to answer, rhetorical question. :)


It is a nice idea that you can setup your services/clients using CXF and 
not worry about all the hairy details, requiring that the client use the 
WSDL seems to interfere with that goal a bit, but as the WSDL is the 
real contract I guess it will be hard to guarantee that the server and 
client will match up when building both off of the interface. So maybe 
it's unavoidable.


Anyway, thanks for the gut feeling explanation, we can now make an 
intelligent choice on how to handle this, I hope. :)


-Jonathan

Benson Margulies wrote:

My opinion is that using the Simple front end with an interface (as
opposed to a WSDL) is a gun pointed firmly at the user's foot, and we
should prohibit it.

Jonathan, I can't prove it today, but my gut feeling is that you are
still experiencing the client constructing a different contract than the
server is using. Consuming the WSDL is the only really reliable way to
get them in sync. At least, I'd suggest trying the WSDL-consumption
alternative and see if it works, and we can go from there.

  

-Original Message-
From: Jonathan Slate [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 17, 2007 8:26 AM
To: cxf-user@incubator.apache.org
Subject: Re: simple-frontend.html

Thanks Jeff for making this change, it's certainly more visible.
However, I'm not sure that this is the same problem. The JIRA talks
about the argument name being wrong (arg0 vs. title) but in my case,


the
  

argument is arg0 and it worked fine w/out changing that. The problem


was
  

the xmlns=http://example.hello/; argument appearing in the argument's


tag.
  

I don't think someone would figure out from looking at the JIRA that
they should use JaxWsProxyFactoryBean to avoid this problem. Or maybe


it
  

*should* work with ClientProxyFactoryBean as documented and I'm doing
something wrong, which would be nice to know. But I think it's ok,
because that's what the Spring client example uses...

-Jonathan

Jeff Yu wrote:


At the bottom of simple-frontend.html, there is a tip talked about
this, see this JIRA for detail:
https://issues.apache.org/jira/browse/CXF-897

I updated it Others title to Well-Known issue for easily to get
people's attention.

Thanks
Jeff

Jonathan Slate wrote:
  

Just wanted to ask about an issue I had and a possible problem with
the documentation on the Web site.

In trying to learn CXF, I created a HelloWorld service using Spring


,
  

following the instructions on this page:
http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html

I then created a separate client application (not using Spring)


using
  

the instructions on this page:
http://cwiki.apache.org/CXF20DOC/simple-frontend.html (under


heading
  

ClientProxyFactoryBean)

This did not work, the text argument was null when the sayHi


method
  

was called. So I set up a Spring client following the instructions


on
  

the first page mentioned above. That worked. Eventually I figured


out
  

that the Spring example had me creating a new JaxWsProxyFactoryBean
whereas the simple frontend example had me creating a new
ClientProxyFactoryBean. This resulted in slightly different SOAP
calls, specifically in the arg0 tag:

arg0 xmlns=http://example.hello/;World/arg0
(ClientProxyFactoryBean)
arg0World/arg0 (JaxWsProxyFactoryBean)

For some reason, the former causes the method to be called with


arg0
  

as null. Also, with the ClientProxyFactoryBean, the result returned
to the client is null, despite the fact that the soap message
contains the return value Hello null.

Anyway, at this point it's working for me. But I'm wondering if


there
  

is a simple explaination for this, and if perhaps the simple


frontend
  

documentation should be updated to use JaxWsProxyFactoryBean.

Thanks,
Jonathan Slate

Re: error when accessing Webservice client within JBoss

Oops, one more slip of the pasting finger! Here is the correct version 
of those last three mappings


  META-INF/services/javax.xml.soap.MetaFactory
  META-INF/services/javax.xml.soap.SOAPFactory
  META-INF/services/javax.xml.ws.spi.Provider

should each contain a single line, respectively,

  com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl
  com.sun.xml.messaging.saaj.soap.SOAPFactoryImpl
  org.apache.cxf.jaxws.spi.ProviderImpl

regards,


Andrew Dinn
---

Andrew Dinn wrote:

Hi shaminda,

Actually, I believe I have misled you slightly. The required mapping is 
for MessageFactory, not SOAPMessage. The mapping is provided by jboss in 
file jboss-saaj.jar which provides a file called


  META-INF/services/javax.xml.soap.MessageFactory

You need to remap this by installing a corresponding file in your .war 
file. It needs to contain the following single line of text


  com.sun.xml.messaging.saaj.soap.DynamicMessageFactoryImpl

I also added the following resource map files to my .war file in order 
to get the bundled cxf libs to operate correctly


  META-INF/services/javax.xml.soap.MetaFactory
  META-INF/services/javax.xml.soap.SOAPFactory
  META-INF/services/javax.xml.ws.spi.Provider

The appropriate mapping targets were, respectively,

  com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl
  com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl
  com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl

regards,


Andrew Dinn
---

shaminda perera wrote:

Thanks Andrew and Jeff for the quick reply..

See below for some a more detailed stacktrace,,, if that helps..



12:18:05,101 FATAL [application] 
javax.ejb.EJBTransactionRolledbackException:

java.lang.UnsupportedOperationException: s

etProperty must be overridden by all subclasses of SOAPMessage

javax.faces.el.EvaluationException:
javax.ejb.EJBTransactionRolledbackException:
java.lang.UnsupportedOperationException

: setProperty must be overridden by all subclasses of SOAPMessage

at 
javax.faces.component.MethodBindingMethodExpressionAdapter.invoke

(MethodBindingMethodExpressionAdapter.java:9

1)

at com.sun.faces.application.ActionListenerImpl.processAction(
ActionListenerImpl.java:91)

at javax.faces.component.UICommand.broadcast(UICommand.java:383)

at org.ajax4jsf.component.AjaxViewRoot.processEvents(
AjaxViewRoot.java:186)

at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(
AjaxViewRoot.java:164)

at org.ajax4jsf.component.AjaxViewRoot.processApplication(
AjaxViewRoot.java:352)

at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(
InvokeApplicationPhase.java:97)

at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java
:251)

at 
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java

:117)

at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)

at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(

ApplicationFilterChain.java:290)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at com.company.filter.doFilter(CompanyFilter.java:26)

at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(

ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:63)

at 
org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java

:57)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:49)

at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(
HotDeployFilter.java:60)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:49)

at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java
:45)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:49)

at 
org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java

:79)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:49)

at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84)

at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(

ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at 
org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java

:141)

at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)

at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(

ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(
ReplyHeaderFilter.java:96)

at

Re: error when accessing Webservice client within JBoss


Hi shaminda,

Actually, I believe I have misled you slightly. The required mapping is 
for MessageFactory, not SOAPMessage. The mapping is provided by jboss in 
file jboss-saaj.jar which provides a file called


  META-INF/services/javax.xml.soap.MessageFactory

You need to remap this by installing a corresponding file in your .war 
file. It needs to contain the following single line of text


  com.sun.xml.messaging.saaj.soap.DynamicMessageFactoryImpl

I also added the following resource map files to my .war file in order 
to get the bundled cxf libs to operate correctly


  META-INF/services/javax.xml.soap.MetaFactory
  META-INF/services/javax.xml.soap.SOAPFactory
  META-INF/services/javax.xml.ws.spi.Provider

The appropriate mapping targets were, respectively,

  com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl
  com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl
  com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl

regards,


Andrew Dinn
---

shaminda perera wrote:

Thanks Andrew and Jeff for the quick reply..

See below for some a more detailed stacktrace,,, if that helps..



12:18:05,101 FATAL [application] javax.ejb.EJBTransactionRolledbackException:
java.lang.UnsupportedOperationException: s

etProperty must be overridden by all subclasses of SOAPMessage

javax.faces.el.EvaluationException:
javax.ejb.EJBTransactionRolledbackException:
java.lang.UnsupportedOperationException

: setProperty must be overridden by all subclasses of SOAPMessage

at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke
(MethodBindingMethodExpressionAdapter.java:9

1)

at com.sun.faces.application.ActionListenerImpl.processAction(
ActionListenerImpl.java:91)

at javax.faces.component.UICommand.broadcast(UICommand.java:383)

at org.ajax4jsf.component.AjaxViewRoot.processEvents(
AjaxViewRoot.java:186)

at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(
AjaxViewRoot.java:164)

at org.ajax4jsf.component.AjaxViewRoot.processApplication(
AjaxViewRoot.java:352)

at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(
InvokeApplicationPhase.java:97)

at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java
:251)

at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java
:117)

at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:290)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at com.company.filter.doFilter(CompanyFilter.java:26)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:63)

at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java
:57)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:49)

at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(
HotDeployFilter.java:60)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:49)

at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java
:45)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:49)

at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java
:79)

at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
SeamFilter.java:49)

at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java
:141)

at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(
ReplyHeaderFilter.java:96)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)

at org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:230)

at org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:175)

at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(
SecurityAssociationValve.java:179)

at

Re: error when accessing Webservice client within JBoss

Thanks Andrew,,
But i didnt bundle any of the CXF jars in my WAR file to start with

comments?


On 10/17/07, Andrew Dinn [EMAIL PROTECTED] wrote:

 Oops, one more slip of the pasting finger! Here is the correct version
 of those last three mappings

   META-INF/services/javax.xml.soap.MetaFactory
   META-INF/services/javax.xml.soap.SOAPFactory
   META-INF/services/javax.xml.ws.spi.Provider

 should each contain a single line, respectively,

   com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl
   com.sun.xml.messaging.saaj.soap.SOAPFactoryImpl
   org.apache.cxf.jaxws.spi.ProviderImpl

 regards,


 Andrew Dinn
 ---

 Andrew Dinn wrote:
  Hi shaminda,
 
  Actually, I believe I have misled you slightly. The required mapping is
  for MessageFactory, not SOAPMessage. The mapping is provided by jboss in
  file jboss-saaj.jar which provides a file called
 
META-INF/services/javax.xml.soap.MessageFactory
 
  You need to remap this by installing a corresponding file in your .war
  file. It needs to contain the following single line of text
 
com.sun.xml.messaging.saaj.soap.DynamicMessageFactoryImpl
 
  I also added the following resource map files to my .war file in order
  to get the bundled cxf libs to operate correctly
 
META-INF/services/javax.xml.soap.MetaFactory
META-INF/services/javax.xml.soap.SOAPFactory
META-INF/services/javax.xml.ws.spi.Provider
 
  The appropriate mapping targets were, respectively,
 
com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl
com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl
com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl
 
  regards,
 
 
  Andrew Dinn
  ---
 
  shaminda perera wrote:
  Thanks Andrew and Jeff for the quick reply..
 
  See below for some a more detailed stacktrace,,, if that helps..
 
  
 
  12:18:05,101 FATAL [application]
  javax.ejb.EJBTransactionRolledbackException:
  java.lang.UnsupportedOperationException: s
 
  etProperty must be overridden by all subclasses of SOAPMessage
 
  javax.faces.el.EvaluationException:
  javax.ejb.EJBTransactionRolledbackException:
  java.lang.UnsupportedOperationException
 
  : setProperty must be overridden by all subclasses of SOAPMessage
 
  at
  javax.faces.component.MethodBindingMethodExpressionAdapter.invoke
  (MethodBindingMethodExpressionAdapter.java:9
 
  1)
 
  at com.sun.faces.application.ActionListenerImpl.processAction(
  ActionListenerImpl.java:91)
 
  at javax.faces.component.UICommand.broadcast(UICommand.java
 :383)
 
  at org.ajax4jsf.component.AjaxViewRoot.processEvents(
  AjaxViewRoot.java:186)
 
  at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(
  AjaxViewRoot.java:164)
 
  at org.ajax4jsf.component.AjaxViewRoot.processApplication(
  AjaxViewRoot.java:352)
 
  at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(
  InvokeApplicationPhase.java:97)
 
  at com.sun.faces.lifecycle.LifecycleImpl.phase(
 LifecycleImpl.java
  :251)
 
  at
  com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java
  :117)
 
  at javax.faces.webapp.FacesServlet.service(FacesServlet.java
 :244)
 
  at
  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
  ApplicationFilterChain.java:290)
 
  at org.apache.catalina.core.ApplicationFilterChain.doFilter(
  ApplicationFilterChain.java:206)
 
  at com.company.filter.doFilter(CompanyFilter.java:26)
 
  at
  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
  ApplicationFilterChain.java:235)
 
  at org.apache.catalina.core.ApplicationFilterChain.doFilter(
  ApplicationFilterChain.java:206)
 
  at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
  SeamFilter.java:63)
 
  at
  org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java
  :57)
 
  at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
  SeamFilter.java:49)
 
  at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(
  HotDeployFilter.java:60)
 
  at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
  SeamFilter.java:49)
 
  at org.jboss.seam.web.RedirectFilter.doFilter(
 RedirectFilter.java
  :45)
 
  at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
  SeamFilter.java:49)
 
  at
  org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java
  :79)
 
  at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(
  SeamFilter.java:49)
 
  at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84)
 
  at
  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
  ApplicationFilterChain.java:235)
 
  at org.apache.catalina.core.ApplicationFilterChain.doFilter(
  ApplicationFilterChain.java:206)
 
  at
  org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java
  :141)
 
  at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)

Re: MTOM and @XmlMimeType(application/octet-stream) annotation.


Just FYI, I've logged a bug for the XmlSchema project:

http://issues.apache.org/jira/browse/WSCOMMONS-261

Dan


On Tuesday 16 October 2007, James Mao wrote:
 Sorry,

 False alarm, I'm testing against with the old distribution which not
 included Dan's fix
 The java2ws works perfect, I'll commit a test in java2ws soon

 Cheers,
 James

  Hi Dan,
 
  Is it fix the java2ws tools as well, or just the runtime?
  in the runtime the http header now should contain the
  application/octet-stream, right?
 
  But I tested with the java2ws, it's not working. the
  expectedContentTypes=image/png still missing in the schema
 
 
  James
 
  It's definitely a bug in XmlSchema.   Updating to the latest
  version of XmlSchema helped a little bit, but not enough.   It at
  least attempts to write the extensors.   The problem is the parsing
  only saves the last extensor.I've worked around that bug by
  writing a Deserializer that actually works correctly so it should
  work now. Just committed the fix to trunk.
 
  Dan
 
  On Tuesday 16 October 2007, Daniel Kulp wrote:
  OK.   Not a JAXB issue.   Seems to be an XmlSchema issue.   The
  DOM we feed into XmlSchema contains the contenttype stuff.   If I
  immediately print the schema, it's gone.   :-(
 
  Dan
 
  On Tuesday 16 October 2007, Daniel Kulp wrote:
  No, this is different.   That thread talks about parameters to
  the SEI methods that should be attachments.In this case, this
  is a field inside one of the objects that is a parameter.   This
  SHOULD work. We just pass the object class as-is to JAXB so this
  seems to be a JAXB issue.
 
  Dan
 
  On Tuesday 16 October 2007, Jim Ma wrote:
  This is not supported in CXF .
  This thread FYI:
  http://www.nabble.com/MTOM-sample-generated-WSDL-with-DataHandle
 r- on -s erver-t4210895.html
 
  imorales wrote:
  Hi all.
 
  I´m trying to implemente a web service that uses MTOM
  Attachments. The way I´m doing is Annotation if JAXB bean.
  The problem is that the wsdl that I generate with ant task
  java2wsdl doesn´t add the annotation
  @XmlMimeType(application/octet-stream) in the wsdl:types.
 
  My bean is:
  ---
 - -- --  @XmlType
  public class FicheroXML {
 
  private String title;
 
  @XmlMimeType(application/octet-stream)
  private DataHandler xmlData;
 
  public String getTitle() {return title;}
  public void setTitle(String title) {this.title = title;   
  } @XmlTransient public DataHandler getXmlData() {return
  xmlData;} public void setXmlData(DataHandler xmlData)
  {this.xmlData = xmlData;} }
  ---
 - -- -- 
 
  My service is:
  ---
 - -- --  @WebService
  public interface ServicioFormularios {
  @WebResult(name=uuid)
  String guardaFormulario(@WebParam(name=xml)FicheroXML
  xml); }
  ---
 - -- -- 
 
 
  My cxf configuration is:
  ---
 - -- --  beans
  xmlns=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-2.0.xs
 d http://cxf.apache.org/jaxws
  http://cxf.apache.org/schemas/jaxws.xsd;
 
   import resource=classpath:META-INF/cxf/cxf.xml/
   import
  resource=classpath:META-INF/cxf/cxf-extension-soap.xml/
  import resource=classpath:META-INF/cxf/cxf-servlet.xml/
 
  jaxws:endpoint
id=servicioFormulario
implementor=com.servicios.ServicioFormulariosImpl
address=/servicioFormulario
jaxws:properties
entry key=mtom-enabled value=true/
/jaxws:properties
  /jaxws:endpoint
  /beans
  ---
 - -- -- 
 
  The wsdl generated whit java2wsdl:
  ---
 - -- --  .
  ..
  ...
  xs:complexType name=ficheroXML
  xs:sequence
  xs:element minOccurs=0 name=xmlData
  type=xs:base64Binary/ xs:element minOccurs=0 name=title
  type=xs:string/ /xs:sequence
  /xs:complexType
  ...
  ..
  .
  xs:complexType name=guardaFormulario
  xs:sequence
  xs:element minOccurs=0 name=xml type=ficheroXML/
  /xs:sequence
  /xs:complexType
  ...
  ..
  .
  ---
 - -- -- 
 
  Why the attribute
  (xmime:expectedContentTypes=application/octet-stream) isn´t
  in the xmlData element of FicheroXML ?
 
  Any ideas ...  it seam like the annotation @XmlMimeType it´s
  not running.
 
  Thanks in advance.



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Re: simple-frontend.html

2007-10-17 Thread Jeff Yu

Oops... My bad, I didn't read it carefully. ;-), but I havent seen this 
case before, I will try it to see if I can have this problem as you did 
as soon as I get a chance.


Thanks
Jeff

Jonathan Slate wrote:
Thanks Jeff for making this change, it's certainly more visible. 
However, I'm not sure that this is the same problem. The JIRA talks 
about the argument name being wrong (arg0 vs. title) but in my case, 
the argument is arg0 and it worked fine w/out changing that. The 
problem was the xmlns=http://example.hello/; argument appearing in 
the argument's tag.


I don't think someone would figure out from looking at the JIRA that 
they should use JaxWsProxyFactoryBean to avoid this problem. Or maybe 
it *should* work with ClientProxyFactoryBean as documented and I'm 
doing something wrong, which would be nice to know. But I think it's 
ok, because that's what the Spring client example uses...


-Jonathan

Jeff Yu wrote:
At the bottom of simple-frontend.html, there is a tip talked about 
this, see this JIRA for detail: 
https://issues.apache.org/jira/browse/CXF-897


I updated it Others title to Well-Known issue for easily to get 
people's attention.


Thanks
Jeff

Jonathan Slate wrote:
Just wanted to ask about an issue I had and a possible problem with 
the documentation on the Web site.


In trying to learn CXF, I created a HelloWorld service using Spring 
, following the instructions on this page:

http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html

I then created a separate client application (not using Spring) 
using the instructions on this page:
http://cwiki.apache.org/CXF20DOC/simple-frontend.html (under heading 
ClientProxyFactoryBean)


This did not work, the text argument was null when the sayHi 
method was called. So I set up a Spring client following the 
instructions on the first page mentioned above. That worked. 
Eventually I figured out that the Spring example had me creating a 
new JaxWsProxyFactoryBean whereas the simple frontend example had me 
creating a new ClientProxyFactoryBean. This resulted in slightly 
different SOAP calls, specifically in the arg0 tag:


arg0 xmlns=http://example.hello/;World/arg0   
(ClientProxyFactoryBean)

arg0World/arg0 (JaxWsProxyFactoryBean)

For some reason, the former causes the method to be called with arg0 
as null. Also, with the ClientProxyFactoryBean, the result returned 
to the client is null, despite the fact that the soap message 
contains the return value Hello null.


Anyway, at this point it's working for me. But I'm wondering if 
there is a simple explaination for this, and if perhaps the simple 
frontend documentation should be updated to use JaxWsProxyFactoryBean.


Thanks,
Jonathan Slate

ResourceInjector/Jsr250BeanPostProcessor NPE

2007-10-17 Thread Adrian C


Hi,

I am trying to migrate a XFire project to CXF and seem to have fallen quiet
early on.

I have alot of spring configuration that used to get loaded up by
ContextLoaderListener before any of the xfire context were loaded up. I
loaded up my XFire service contexts using the XFireConfigurableServlet. Now
that I am trying to migrate, it appears I have no way to load up CXF after
the all my context have loaded (if I try to do this now using the config
location param for the servlet defintion I get a no bean cxf found
exception).

So I am forced to load my CXF services with my main spring configuration,
but this doesn't work because I have a statically initialized bean - my
problem seems to be with the Jsr250BeanPostProcessor  a bean which is
created using a factory method at startup.

i.e.
bean id=dummy.factory class=demo.spring.DummyFactory
factory-method=createInstance lazy-init=false
...

This bean causes a NullPointerException (see below), so any suggestions as
to what to do. I have a attached a source code to recreate this problem.

Thanks

828 [main] ERROR org.springframework.web.context.ContextLoader  - Context
initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'dummy.factory ' defined in class path resource
[demo/spring/bean-defs.xml]: Initialization of bean failed; nested exception
is java.lang.NullPointerException
Caused by:
java.lang.NullPointerException
at org.apache.cxf.common.injection.ResourceInjector.getAnnotatedMethods
(ResourceInjector.java:333)
at
org.apache.cxf.common.injection.ResourceInjector.getPostConstructMethods(ResourceInjector.java:323)
at
org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(ResourceInjector.java
:284)
at
org.apache.cxf.common.injection.ResourceInjector.construct(ResourceInjector.java:84)
at
org.apache.cxf.bus.spring.Jsr250BeanPostProcessor.postProcessBeforeInitialization(Jsr250BeanPostProcessor.java
:44)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:301)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean
(AbstractAutowireCapableBeanFactory.java:1167)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:425)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject
(AbstractBeanFactory.java:251)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:156)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean
(AbstractBeanFactory.java:248)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons
(DefaultListableBeanFactory.java:287)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352)
at
org.springframework.web.context.ContextLoader.createWebApplicationContext
(ContextLoader.java:244)
at
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:187)
at
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java
:49)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3764)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4216)
at org.apache.catalina.core.ContainerBase.addChildInternal
(ContainerBase.java:760)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
at org.apache.catalina.startup.HostConfig.deployDescriptor
(HostConfig.java:626)
at
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
at org.apache.catalina.startup.HostConfig.start (HostConfig.java:1138)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at org.apache.catalina.core.ContainerBase.start
(ContainerBase.java:1022)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
at org.apache.catalina.core.StandardEngine.start
(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:448)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
at org.apache.catalina.startup.Catalina.start (Catalina.java:552)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at

Re: Get SOAPEnvelope as String


According to the DOM spec:  (see the javadoc for org.w3c.dom.Node)

concatenation of the textContent attribute value of every child node, 
excluding COMMENT_NODE and PROCESSING_INSTRUCTION_NODE nodes. This is 
the empty string if the node has no children.

Thus, this is working per spec, although it does suck.

That said, starting with SAAJ 1.2, the SAAJ model extends the DOM model.   
Thus, ANY utility you having for printing a DOM should work.   

Dan


On Wednesday 17 October 2007, Cencio wrote:
 Hi all,

 i'm trying to get the SOAPEnvelope content as String. I tryed with

 mySOAPMessage.getSOAPPart().getEnvelope().getTextContent()

 but the returned string of this envelope

 soapenv:Envelope
 xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
 xmlns:xsd=http://www.w3.org/2001/XMLSchema;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   soapenv:Body
  eseguiServizio xmlns=http://spcoop.it/cart/pdd-test;
 Richiestapersona nome=mario
 cognome=rossi/Richiesta /eseguiServizio
   /soapenv:Body
/soapenv:Envelope

 is just

 persona nome=mario cognome=rossi/


 It's correct? If is right how can i get the whole envelope as string?
 Thx
 Lorenzo



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Re: error when accessing Webservice client within JBoss


shaminda perera wrote:

Thanks Andrew,,
But i didnt bundle any of the CXF jars in my WAR file to start with


Ok, we'll come back to that in a second. Irrespective of this when using 
CXF within a JBoss server you are still going to face problems with the 
fact that CXF and JBoss employ competing versions of some libraries. 
Depending upon where you have placed the CXF libs you may interpose the 
CXF versions before or after the JBoss ones in the classloader lookup 
path. If you do it one way you may upset JBoss. If you do it another way 
you may upset CXF. Welcome to classloader hell :-)


Given that you are getting the symptoms you described it looks as if the 
classloader is finding the CXF libraries first but is still being 
snookered by the JBoss resource mappings. Have you placed the CXF 
libraries in $JBOSS_HOME/lib? I believe this is the first place the 
classloader looks for an implementation class (after looking at a war 
/WEB-INF/lib, that is).


Whatever you have done, the reason I claim this is that i) you are 
getting incompatible super and subclasses and ii) the super class in 
question does not implement getProperty. So, the super class must be 
from the CXF jar. This means the incompatible subclass must be from the 
JBoss implementation jar. Although you have enabled prior access to the 
CXF saaj jar you have not disabled the resource mappings which load the 
JBoss saaj implementation jar. That is because none of the CXF libs 
contain a mapping file so none of them overrides the one provided by JBoss.


Another problem which occurs when you install the CXF libs this way is 
that legitimate JBoss apps which do not want to use CXF will be getting 
CXF versions of some classes. This is probably ok -- the latest (2.0+) 
CXF libs are likely to be later than the latest (4.2.1+) release JBoss 
libs -- but it is not the best way to organize things and, although it 
may work, there is no guarantee that there is no incompatibility here.


Now, conversely, if you were to place the CXF libs in the deploy 
directory or the server/servername/lib directory they would get loaded 
after the ones in $JBOSS_HOME/lib. This way round you would run the 
opposite risk that CXF code would get the wrong version of its libs 
since they would be preceded by alternatives found first in the JBoss 
lib directory. This is likely to be a worse problem since CXF needs some 
later versions of APIs than JBoss. Also, I think you would clobber some 
of the libs of the same name in the JBoss directory, i.e. you would 
still enforce a partial upgrade of the libs used by JBoss.


So, if your app is using CXF then it is probably best to ensure that it 
gets the libraries CXF wants it to have by bundling them in a .war file 
along with your app code. This also ensures that other apps do *not* get 
CXF libraries that they do not want. Of course, it also means a copy of 
the CXF libraries in every .war file . . .


If you want to persist in placing the CXF apps in the $JBOSS_HOME/lib 
directory rather than scoping the app libs inside a .war file then you 
will have to ensure that suitable resources are defined to map the 
MessageFactory and other classes to the appropriate implementations. 
i.e. you cannot just install the libs you also have to ensure that the 
factory mappings provided by the jboss implementation libs are correctly 
remapped.


regards,


Andrew Dinn
---

RE: Disable access to wsdl in Servlet transport

2007-10-17 Thread Willem2

I do not think httpj configuration can do that .
Because we add the service url context when we add the servant to the Jetty
Engine.
As Benson just mentioned , I don't think a common Jetty handler can filter
all the ?wsdl request.

Maybe we need to do some hacking work in the QueryHandlerRegisty for a
common solution of the Servlet and Jetty HTTP transports.

Willem.

Sergey Beryozkin wrote:

Can you do it using an httpj configuration ?

Cheers, Sergey

-Original Message-
From: Benson Margulies [mailto:[EMAIL PROTECTED]
Sent: 17 October 2007 11:36
To: cxf-user@incubator.apache.org
Subject: RE: Disable access to wsdl in Servlet transport

Well, perhaps you do.

Use the CXF config to hang a handler in front of the CXF handler that
filter-feeds for ?wsdl? I can't prove that jetty allows one handler to
peek into a context owned by a successor.

-Original Message-
From: James Mao [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 17, 2007 6:11 AM
To: cxf-user@incubator.apache.org
Subject: Re: Disable access to wsdl in Servlet transport

If you're working with a container, i think you can do this through
configuration of the container, to redirect the ?wsdl to a more
friendly
page,
say, please contact ... to get the wsdl, or list the service you
have
etc.

I guess we don't have this function in a standalone service, do we?

James

But I think we still can do it in the filter, such as:

doFilter() {
if (URLHasWsdlSuffix()) {
//Do the Authentication
} else {
//access the web service }
}

If you don't want to use the filter to do the security, maybe need
to
add an interceptor or other codes before dealing with
WSDLQueryHandler, as willem pointed out in the other mail.

HTH..

Thanks
Jeff

Glen Mazza wrote:
Jeff,
I think he doesn't want people to see the WSDL file. It's not the
service he wants to restrict, but viewing its WSDL. I don't know
if
that can be done.

Glen

Am Mittwoch, den 17.10.2007, 11:11 +0800 schrieb Jeff Yu:

Hi,

There is an easy way that I came up is to use a filter in web.xml
to
restrict the access.

Say there are three services: A,B,C , we want to restrict the B,C
service. we can pulish the services as following:

http://host.com/services/secure/B
http://host.com/services/secure/C
http://host.com/services/A.

And then we will config a filter to restrict the
http://lhost.com/service/secure url to do the authentication.

So people can access the A service without any restriction, but
need
to get authentication to access B,C service.

Thanks
Jeff

Egor Samarkhanov wrote:

Hello !

How can I restrict access to WSDL of my service?
I don't want someone to access the
http//host.com/services/myservice?wsdl content.
And I use Servlet transport.

Thanks,
Egor Samarkhanov ([EMAIL PROTECTED])

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

--
View this message in context:
http://www.nabble.com/Disable-access-to-wsdl-in-Servlet-transport-tf4636104.html#a13254817
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Error with temporary files


Hmm  

 Caused by: java.io.IOException: No such file or directory
   at java.io.WinNTFileSystem.createFileExclusively(Native Method)
   at java.io.File.checkAndCreate(File.java:1345)
   at java.io.File.createTempFile(File.java:1434)
   at java.io.File.createTempFile(File.java:1471)

It's having issues creating a temp file.   Can you check to make sure 
your temp directory is available and is writable and has space?   Maybe 
write a simple program that does just File.createTempFile(cxf, null); 
or similar to see if that works?

I did do a bit of work in this area, so you might want to try tha latest 
2.0.3 snapshots.   With that, I can provide a system property to control 
where the temp files are created.

Dan



On Wednesday 17 October 2007, Jean-François Daune wrote:
 Hi,

 I got this error in some of my tests. I use version 2.0.1.

 The problem seems to relate more to Woodstox than CXF.

 Any idea?

 Cheers,

 J-F


 org.apache.cxf.binding.soap.SoapFault: Error writing to
 XMLStreamWriter. at
 org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndi
ngInterceptor.handleMessage(SoapOutInterceptor.java:244) at
 org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndi
ngInterceptor.handleMessage(SoapOutInterceptor.java:226) at
 org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
rChain.java:207) at
 org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessa
ge(AbstractFaultChainInitiatorObserver.java:90) at
 org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
rChain.java:224) at
 org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Outg
oingChainInterceptor.java:73) at
 org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
rChain.java:207) at
 org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia
tionObserver.java:73) at
 org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletD
estination.java:78) at
 org.apache.cxf.transport.servlet.ServletController.invokeDestination(S
ervletController.java:231) at
 org.apache.cxf.transport.servlet.ServletController.invoke(ServletContr
oller.java:139) at
 org.apache.cxf.transport.servlet.CXFServlet.invoke(CXFServlet.java:271
) at
 org.apache.cxf.transport.servlet.CXFServlet.doPost(CXFServlet.java:249
) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at
 javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:269) at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
lterChain.java:188) at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa
lve.java:213) at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextVa
lve.java:174) at
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.ja
va:127) at
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.ja
va:117) at
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValv
e.java:108) at
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java
:151) at
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
874) at
 org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.pr
ocessConnection(Http11BaseProtocol.java:665) at
 org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoi
nt.java:528) at
 org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFoll
owerWorkerThread.java:81) at
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPo
ol.java:689) at java.lang.Thread.run(Thread.java:595)
 Caused by: com.ctc.wstx.exc.WstxIOException: No such file or directory
   at
 com.ctc.wstx.sw.BaseStreamWriter.finishDocument(BaseStreamWriter.java:
1687) at
 com.ctc.wstx.sw.BaseStreamWriter.writeEndDocument(BaseStreamWriter.jav
a:585) at
 org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndi
ngInterceptor.handleMessage(SoapOutInterceptor.java:239) ... 28 more
 Caused by: java.io.IOException: No such file or directory
   at java.io.WinNTFileSystem.createFileExclusively(Native Method)
   at java.io.File.checkAndCreate(File.java:1345)
   at java.io.File.createTempFile(File.java:1434)
   at java.io.File.createTempFile(File.java:1471)
   at
 org.apache.cxf.io.CachedOutputStream.createFileOutputStream(CachedOutp
utStream.java:248) at
 org.apache.cxf.io.CachedOutputStream.write(CachedOutputStream.java:222
) at
 org.apache.cxf.io.CacheAndWriteOutputStream.write(CacheAndWriteOutputS
tream.java:60) at com.ctc.wstx.io.UTF8Writer.flush(UTF8Writer.java:96)
   at
 com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:214)
 at
 com.ctc.wstx.sw.BufferingXmlWriter.close(BufferingXmlWriter.java:194)
 at
 com.ctc.wstx.sw.BaseStreamWriter.finishDocument(BaseStreamWriter.java:
1685) ... 30 more



-- 
J. Daniel Kulp
Principal Engineer
IONA
P:

Re: error when accessing Webservice client within JBoss

Thanks andrew for the detailed mail.

This is what i am doing currently:
I created a Web service client side related classes using the WSDL2Java tool
provided by CXF, and then put just put these classes in a suitable package
in the main web application. I didnt put any of the CXF provided
jars/libraries in to the web application.
Now when calling the web service i am getting this error ,,, that we are
talking about.

Just thinking,,, the jdk's rt.jar also has some webservices/xml related
classes,,, is my web service client using any of those as well? ,, or is it
picking the libs from JBoss only..

I havent placed any CXF libraries in $JBOSS_HOME/lib ,, actually i havent
placed them anywhere in Jboss or anywhere in my web application.

I will try to do what you are mentioning in this mail, and get back to you..

On 10/17/07, Andrew Dinn [EMAIL PROTECTED] wrote:

 shaminda perera wrote:
  Thanks Andrew,,
  But i didnt bundle any of the CXF jars in my WAR file to start with

 Ok, we'll come back to that in a second. Irrespective of this when using
 CXF within a JBoss server you are still going to face problems with the
 fact that CXF and JBoss employ competing versions of some libraries.
 Depending upon where you have placed the CXF libs you may interpose the
 CXF versions before or after the JBoss ones in the classloader lookup
 path. If you do it one way you may upset JBoss. If you do it another way
 you may upset CXF. Welcome to classloader hell :-)

 Given that you are getting the symptoms you described it looks as if the
 classloader is finding the CXF libraries first but is still being
 snookered by the JBoss resource mappings. Have you placed the CXF
 libraries in $JBOSS_HOME/lib? I believe this is the first place the
 classloader looks for an implementation class (after looking at a war
 /WEB-INF/lib, that is).

 Whatever you have done, the reason I claim this is that i) you are
 getting incompatible super and subclasses and ii) the super class in
 question does not implement getProperty. So, the super class must be
 from the CXF jar. This means the incompatible subclass must be from the
 JBoss implementation jar. Although you have enabled prior access to the
 CXF saaj jar you have not disabled the resource mappings which load the
 JBoss saaj implementation jar. That is because none of the CXF libs
 contain a mapping file so none of them overrides the one provided by
 JBoss.

 Another problem which occurs when you install the CXF libs this way is
 that legitimate JBoss apps which do not want to use CXF will be getting
 CXF versions of some classes. This is probably ok -- the latest (2.0+)
 CXF libs are likely to be later than the latest (4.2.1+) release JBoss
 libs -- but it is not the best way to organize things and, although it
 may work, there is no guarantee that there is no incompatibility here.

 Now, conversely, if you were to place the CXF libs in the deploy
 directory or the server/servername/lib directory they would get loaded
 after the ones in $JBOSS_HOME/lib. This way round you would run the
 opposite risk that CXF code would get the wrong version of its libs
 since they would be preceded by alternatives found first in the JBoss
 lib directory. This is likely to be a worse problem since CXF needs some
 later versions of APIs than JBoss. Also, I think you would clobber some
 of the libs of the same name in the JBoss directory, i.e. you would
 still enforce a partial upgrade of the libs used by JBoss.

 So, if your app is using CXF then it is probably best to ensure that it
 gets the libraries CXF wants it to have by bundling them in a .war file
 along with your app code. This also ensures that other apps do *not* get
 CXF libraries that they do not want. Of course, it also means a copy of
 the CXF libraries in every .war file . . .

 If you want to persist in placing the CXF apps in the $JBOSS_HOME/lib
 directory rather than scoping the app libs inside a .war file then you
 will have to ensure that suitable resources are defined to map the
 MessageFactory and other classes to the appropriate implementations.
 i.e. you cannot just install the libs you also have to ensure that the
 factory mappings provided by the jboss implementation libs are correctly
 remapped.

 regards,


 Andrew Dinn
 ---

Re: ResourceInjector/Jsr250BeanPostProcessor NPE


Adrian,

Just FYI:  I can reproduce this with your testcase.I'll start digging 
into it now.   The testcase is a HUGE help.   Thanks!

Can you also send a similar testcase that shows the other problem?   (the 
no cxf bean thing?)   I can dig into that as well.
 
Dan   (who is actually finally learning all the spring things.)   :-)



On Wednesday 17 October 2007, Adrian C wrote:
 Hi,

 I am trying to migrate a XFire project to CXF and seem to have fallen
 quiet early on.

 I have alot of spring configuration that used to get loaded up by
 ContextLoaderListener before any of the xfire context were loaded up.
 I loaded up my XFire service contexts using the
 XFireConfigurableServlet. Now that I am trying to migrate, it appears
 I have no way to load up CXF after the all my context have loaded (if
 I try to do this now using the config location param for the servlet
 defintion I get a no bean cxf found exception).

 So I am forced to load my CXF services with my main spring
 configuration, but this doesn't work because I have a statically
 initialized bean - my problem seems to be with the
 Jsr250BeanPostProcessor  a bean which is created using a factory
 method at startup.

 i.e.
 bean id=dummy.factory class=demo.spring.DummyFactory
 factory-method=createInstance lazy-init=false
 ...

 This bean causes a NullPointerException (see below), so any
 suggestions as to what to do. I have a attached a source code to
 recreate this problem.

 Thanks

 828 [main] ERROR org.springframework.web.context.ContextLoader  -
 Context initialization failed
 org.springframework.beans.factory.BeanCreationException: Error
 creating bean with name 'dummy.factory ' defined in class path
 resource
 [demo/spring/bean-defs.xml]: Initialization of bean failed; nested
 exception is java.lang.NullPointerException
 Caused by:
 java.lang.NullPointerException
 at
 org.apache.cxf.common.injection.ResourceInjector.getAnnotatedMethods
 (ResourceInjector.java:333)
 at
 org.apache.cxf.common.injection.ResourceInjector.getPostConstructMetho
ds(ResourceInjector.java:323) at
 org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(R
esourceInjector.java

 :284)

 at
 org.apache.cxf.common.injection.ResourceInjector.construct(ResourceInj
ector.java:84) at
 org.apache.cxf.bus.spring.Jsr250BeanPostProcessor.postProcessBeforeIni
tialization(Jsr250BeanPostProcessor.java

 :44)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanF
actory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapa
bleBeanFactory.java:301) at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanF
actory.initializeBean (AbstractAutowireCapableBeanFactory.java:1167)
 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanF
actory.createBean(AbstractAutowireCapableBeanFactory.java:425) at
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObj
ect (AbstractBeanFactory.java:251)
 at
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry
.getSingleton(DefaultSingletonBeanRegistry.java:156) at
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean
 (AbstractBeanFactory.java:248)
 at
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(
AbstractBeanFactory.java:160) at
 org.springframework.beans.factory.support.DefaultListableBeanFactory.p
reInstantiateSingletons (DefaultListableBeanFactory.java:287)
 at
 org.springframework.context.support.AbstractApplicationContext.refresh
(AbstractApplicationContext.java:352) at
 org.springframework.web.context.ContextLoader.createWebApplicationCont
ext (ContextLoader.java:244)
 at
 org.springframework.web.context.ContextLoader.initWebApplicationContex
t(ContextLoader.java:187) at
 org.springframework.web.context.ContextLoaderListener.contextInitializ
ed(ContextLoaderListener.java

 :49)

 at
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext
.java:3764) at
 org.apache.catalina.core.StandardContext.start(StandardContext.java:42
16) at org.apache.catalina.core.ContainerBase.addChildInternal
 (ContainerBase.java:760)
 at
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740
) at
 org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
 at org.apache.catalina.startup.HostConfig.deployDescriptor
 (HostConfig.java:626)
 at
 org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.ja
va:553) at
 org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
 at org.apache.catalina.startup.HostConfig.start
 (HostConfig.java:1138) at
 org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:
311) at
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycle
Support.java:120) at org.apache.catalina.core.ContainerBase.start
 (ContainerBase.java:1022)
 at
 org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at

RE: simple-frontend.html

The 'nice idea' is fine if you understand the constraints. The two ends
have to come up with the same answer for the hidden internal model of
the service. If this is your situation, my suggestion is to avoid
interfaces and stick with classes in terms of communicating with CXF or
any similar toolkit. 

 -Original Message-
 From: Jonathan Slate [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, October 17, 2007 9:04 AM
 To: cxf-user@incubator.apache.org
 Subject: Re: simple-frontend.html

 Ok, now I think I understand the crux of the issue. As it's working
for
 me now, I have to wonder... should I change it or go ahead with the
old
 if it ain't broke don't fix it? No need to answer, rhetorical
 question. :)

 It is a nice idea that you can setup your services/clients using CXF
and
 not worry about all the hairy details, requiring that the client use
the
 WSDL seems to interfere with that goal a bit, but as the WSDL is the
 real contract I guess it will be hard to guarantee that the server and
 client will match up when building both off of the interface. So maybe
 it's unavoidable.

 Anyway, thanks for the gut feeling explanation, we can now make an
 intelligent choice on how to handle this, I hope. :)

 -Jonathan

 Benson Margulies wrote:
  My opinion is that using the Simple front end with an interface (as
  opposed to a WSDL) is a gun pointed firmly at the user's foot, and
we
  should prohibit it.

  Jonathan, I can't prove it today, but my gut feeling is that you are
  still experiencing the client constructing a different contract than
the
  server is using. Consuming the WSDL is the only really reliable way
to
  get them in sync. At least, I'd suggest trying the WSDL-consumption
  alternative and see if it works, and we can go from there.

  -Original Message-
  From: Jonathan Slate [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, October 17, 2007 8:26 AM
  To: cxf-user@incubator.apache.org
  Subject: Re: simple-frontend.html

  Thanks Jeff for making this change, it's certainly more visible.
  However, I'm not sure that this is the same problem. The JIRA talks
  about the argument name being wrong (arg0 vs. title) but in my
case,

  the

  argument is arg0 and it worked fine w/out changing that. The
problem

  was

  the xmlns=http://example.hello/; argument appearing in the
argument's

  tag.

  I don't think someone would figure out from looking at the JIRA
that
  they should use JaxWsProxyFactoryBean to avoid this problem. Or
maybe

  it

  *should* work with ClientProxyFactoryBean as documented and I'm
doing
  something wrong, which would be nice to know. But I think it's ok,
  because that's what the Spring client example uses...

  -Jonathan

  Jeff Yu wrote:

  At the bottom of simple-frontend.html, there is a tip talked about
  this, see this JIRA for detail:
  https://issues.apache.org/jira/browse/CXF-897

  I updated it Others title to Well-Known issue for easily to
get
  people's attention.

  Thanks
  Jeff

  Jonathan Slate wrote:

  Just wanted to ask about an issue I had and a possible problem
with
  the documentation on the Web site.

  In trying to learn CXF, I created a HelloWorld service using
Spring

  ,

  following the instructions on this page:

http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html

  I then created a separate client application (not using Spring)

  using

  the instructions on this page:
  http://cwiki.apache.org/CXF20DOC/simple-frontend.html (under

  heading

  ClientProxyFactoryBean)

  This did not work, the text argument was null when the sayHi

  method

  was called. So I set up a Spring client following the
instructions

  on

  the first page mentioned above. That worked. Eventually I figured

  out

  that the Spring example had me creating a new
JaxWsProxyFactoryBean
  whereas the simple frontend example had me creating a new
  ClientProxyFactoryBean. This resulted in slightly different SOAP
  calls, specifically in the arg0 tag:

  arg0 xmlns=http://example.hello/;World/arg0
  (ClientProxyFactoryBean)
  arg0World/arg0 (JaxWsProxyFactoryBean)

  For some reason, the former causes the method to be called with

  arg0

  as null. Also, with the ClientProxyFactoryBean, the result
returned
  to the client is null, despite the fact that the soap message
  contains the return value Hello null.

  Anyway, at this point it's working for me. But I'm wondering if

  there

  is a simple explaination for this, and if perhaps the simple

  frontend

  documentation should be updated to use JaxWsProxyFactoryBean.

  Thanks,
  Jonathan Slate

CXF Exception: DefaultNamespaceHandlerResolver

2007-10-17 Thread narend


Hi
I was able to get the webservice up and working inside a container...but I
get these warnings on deployment.. Am I  missing any jars..? Is there a way
I can turn off these warnings
I have all the jars listed in the CXF user guide below
http://cwiki.apache.org/CXF20DOC/a-simple-jax-ws-service.html

Find the Full stack trace here - 
http://www.nabble.com/file/p13255668/stack_trace.txt stack_trace.txt 

10:02:07,360 DEBUG [DefaultNamespaceHandlerResolver] ::: Ignoring namespace
handler [org.springframework.scripting.config.LangNamespaceHandler]: handler
class not found
java.lang.ClassNotFoundException:
org.springframework.scripting.config.LangNamespaceHandler


 10:02:07,360 DEBUG [DefaultNamespaceHandlerResolver] ::: Ignoring
namespace handler
[org.springframework.scripting.config.LangNamespaceHandler]: handler class
not found
java.lang.ClassNotFoundException:
org.springframework.scripting.config.LangNamespaceHandler


 10:02:07,498 DEBUG [DefaultNamespaceHandlerResolver] ::: Ignoring
namespace handler
[org.springframework.transaction.config.TxNamespaceHandler]: handler class
not found
java.lang.ClassNotFoundException:
org.springframework.transaction.config.TxNamespaceHandler
  
10:02:07,507 DEBUG [DefaultNamespaceHandlerResolver] ::: Ignoring namespace
handler [org.springframework.aop.config.AopNamespaceHandler]: handler class
not found
java.lang.ClassNotFoundException:
org.springframework.aop.config.AopNamespaceHandler


-- 
View this message in context: 
http://www.nabble.com/CXF-Exception%3A-DefaultNamespaceHandlerResolver-tf4641174.html#a13255668
Sent from the cxf-user mailing list archive at Nabble.com.

Parameters in Restful services

2007-10-17 Thread Tolan, Michael E

I'm having trouble with parameters in a RESTful service. 

After going over the User's guide, I think I understand that the {}
element in a HttpResource annotation should name a bean property on the
object argument to the implementation function. However, when I try to
set this up, it doesn't seem that the bean is ever initialized
correctly.

 

I suspect I'm doing something wrong, and would appreciate it if someone
could point me at what that might be.

In case it's relevant, I'm using the 2.0.2 version of cxf.

 

-Mike

 

 

SEI:

--

import org.codehaus.jra.Get;

import org.codehaus.jra.HttpResource;

 

@Get

@HttpResource(location=/channelName/{id})

public String getChannelName(GetChannel getChannel);

 

 

 

GetChannel.java:

--

public class GetChannel {

private String id;

public GetChannel() {}

public String getId() {return id;}

public void setId(String id) {this.id = id;}

}

 

 

Implementaiton:

---

public String getChannelName(GetChannel getChannel) {

Logger log = Logger.getLogger(BoardServiceImpl.class);

log.debug(getChannelName: +getChannel); //getChannel
is null

}

Re: Do we have a snapshot with the WSDL 'parameters' fix?

On Wednesday 17 October 2007, Benson Margulies wrote:
 Has Dan's fix to part names been snapshotted as yet?

The latest 2.0.3 snapshot should have it.   I did that yesterday 
afternoon.   I don't remember the last time I did the 2.1's so they may 
not.   I'll try and do a 2.1 snapshot at some point today.

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Do we have a snapshot with the WSDL 'parameters' fix?

Has Dan's fix to part names been snapshotted as yet?

Re: CXF Exception: DefaultNamespaceHandlerResolver

2007-10-17 Thread narend


Okie dok.. here's a resolution. We really don't need these handler
references.. so I opened the spring.handlers file inside spring-beans.jar
under META-INF, removed the references to the below handlers and repackaged
the jar back.
Thanks to the below nabble post that helped me on this path
http://www.nabble.com/-cocoon-2.2.xHow-to-trace-what-is-going-on-tf4025801.html#a11461980


narend wrote:
 
 Hi
 I was able to get the webservice up and working inside a container...but I
 get these warnings on deployment.. Am I  missing any jars..? Is there a
 way I can turn off these warnings
 I have all the jars listed in the CXF user guide below
 http://cwiki.apache.org/CXF20DOC/a-simple-jax-ws-service.html
 
 Find the Full stack trace here - 
 http://www.nabble.com/file/p13255668/stack_trace.txt stack_trace.txt 
 
 10:02:07,360 DEBUG [DefaultNamespaceHandlerResolver] ::: Ignoring
 namespace handler
 [org.springframework.scripting.config.LangNamespaceHandler]: handler class
 not found
 java.lang.ClassNotFoundException:
 org.springframework.scripting.config.LangNamespaceHandler
 
 
  10:02:07,360 DEBUG [DefaultNamespaceHandlerResolver] ::: Ignoring
 namespace handler
 [org.springframework.scripting.config.LangNamespaceHandler]: handler class
 not found
 java.lang.ClassNotFoundException:
 org.springframework.scripting.config.LangNamespaceHandler
 
 
  10:02:07,498 DEBUG [DefaultNamespaceHandlerResolver] ::: Ignoring
 namespace handler
 [org.springframework.transaction.config.TxNamespaceHandler]: handler class
 not found
 java.lang.ClassNotFoundException:
 org.springframework.transaction.config.TxNamespaceHandler
   
 10:02:07,507 DEBUG [DefaultNamespaceHandlerResolver] ::: Ignoring
 namespace handler [org.springframework.aop.config.AopNamespaceHandler]:
 handler class not found
 java.lang.ClassNotFoundException:
 org.springframework.aop.config.AopNamespaceHandler
 
 
 

-- 
View this message in context: 
http://www.nabble.com/CXF-Exception%3A-DefaultNamespaceHandlerResolver-tf4641174.html#a13259140
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Disable access to wsdl in Servlet transport


Programatically, you can grab the Bus, get the QueryHandlerRegistry 
extension from it, and then remove the WSDLQueryHandler.   Kind of 
sucks.

I'm changing the spring config so the WSDLQueryHandler is added via 
spring instead of a hardcoded new WSDLQueryHandler() in the code.   
Thus, you might be able to specify a different configuration.

Dan

On Tuesday 16 October 2007, Egor Samarkhanov wrote:
 Hello !

 How can I restrict access to WSDL of my service?
 I don't want someone to access the
 http//host.com/services/myservice?wsdl content.
 And I use Servlet transport.

 Thanks,
 Egor Samarkhanov ([EMAIL PROTECTED])



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Re: JAXB error on wsdl2java ....