Re: Failed to deploy the sample helloworld.war to WebLogic Server 9.2
Hi, William I would recommend that you build a "FULL WAR", which includes all the required jars in the $WAR/WEB-INF/lib, instead of copying all the libraries to the weblogic system libraries. You might need to get the updated common_build.xml[1] to replace the old one in apache-cxf-2.0.1-incubator, and then run the "ANT WAR" to get the "FULL WAR", and then deploy the WAR to weblogic/webapps, remember to remove the libs from weblogic system libraries folder. You can refer to BUG JIRA[2] for detail, and if you can read chinese, here is a thread[3] discussed about it. BTW, in the 2.0.2 release, we build the "FULL WAR" by default, if it is possible, you can give it a try against apache-cxf-2.0.2-incubator[4], although it is in voting now. Thanks Jeff [1] https://svn.apache.org/repos/asf/incubator/cxf/trunk/distribution/src/main/release/samples/common_build.xml [2] http://issues.apache.org/jira/browse/CXF-901 [3] http://groups.google.com/group/cxf-zh/browse_thread/thread/9101cb751fa13376?hl=en [4] http://people.apache.org/~dkulp/stage_cxf/2.0.2-incubator-take1/dist/ william_w_hu wrote: I'm using apache-cxf-2.0.1-incubaor and WebLogic Server 9.2. I was able to run the helloworld sample coming from cxf in tomcat smoothly. But when i tried to deploy it to WLS 9.2 I always got a ClassNotFoundException as following. Anyone has encounterred similar problem? Help is highly appreciated. Thanks. ps. i build helloworld using "ant war" command according to the README. And copied all files in lib and modules except for modules/integration to "C:\Program Files\bea\weblogic92\samples\domains\wl_server\lib". I deployed the helloworld.war using WLS admin console into the examplesServer. === Stack trace=== <[STANDBY] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1189664354656> (StubLifecycleHelper.java:48) at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:504) at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletContext.java:1698) at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(WebAppServletContext.java:1675) at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1595) at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2734) at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:892) at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:336) at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60) at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200) at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:117) at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60) at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:26) at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:641) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:229) at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:154) org.springframework.beans.FatalBeanException: Could not load class: demo.hw.server.GreeterImpl; nested exception is java.lang.ClassNotFoundException: demo.hw.server.GreeterImpl at org.apache.cxf.jaxws.spring.EndpointDefinitionParser.loadImplementor(EndpointDefinitionParser.java:133) at org.apache.cxf.jaxws.spring.EndpointDefinitionParser.doParse(EndpointDefinitionParser.java:84) at org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser.parseInternal(AbstractSingleBeanDefinitionParser.java:70) 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) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1104) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefini
Re: WS-Security Single Sign On
Hi Fred, With "Single Sign On" I meant a mechanism to have a series of messages authenticated only once (with the first of the series) and treated as a conversation, instead of autenthicate each message. I some way I would want to emulate something similar to initial login followed by and exchange of messages. Maybe this pertains the WS-SecureConversation specification, that I've seen will be covered in CXF 2.1. There is a way to use Kerberos authentication token in wss4j ?! David Fred Dushin-3 wrote: > > No question is silly or bad. > > CXF itself provides no single sign-on capabilities, though one could > certainly try to implement one over CXF. > > The challenge is to do it in a way that provides reasonable assurance > and protection from replay and man-in-the-middle attacks. The naive > approach is to grant the client a "cookie" in virtue of a login > event, and then for the client to present that cookie as "evidence" > of its identity. This way, the client is just using an opaque token > in lieu of otherwise sensitive security information. (I presume this > is what you mean by "single sign-on"). To do this, you need to lock > down your communications channels, presumably in your case, using > SSL. And you need to ensure that the dispensed cookies can't be > stolen or hijacked. That's a lot of trust you need to place in how > you deploy your infrastructure, and it only gets you so far. > > The more compelling solution (IMO) is to use SSO technologies that > are already out there, such as Kerberos (which is arguably the most > deployed SSO solution going). But I'm guessing that's not what > you're after. > > -Fred > > On Sep 12, 2007, at 9:04 AM, Davide Gesino wrote: > >> >> Hi, >> >> may be a silly or bad question but >> there is a way to have a single sign on mechanism in CXF (in WS in >> general) >> or I have to check the user credentials each time for each message? >> There is a way to estabilish something similar to the Http Session >> between >> WS client and server?!? >> In my app I have CXF deployed on Tomcat and the transport is Http. >> >> David >> -- >> View this message in context: http://www.nabble.com/WS-Security- >> Single-Sign-On-tf4429137.html#a12634942 >> Sent from the cxf-user mailing list archive at Nabble.com. >> >> > > > -- View this message in context: http://www.nabble.com/WS-Security-Single-Sign-On-tf4429137.html#a12650564 Sent from the cxf-user mailing list archive at Nabble.com.
Re: Hibernate and cxf 2.01 problem.
Thanks Juan, this solved the problem with the 2.0.1-incubator version.
Now my cxf dependencies are:
org.apache.cxf
cxf-rt-frontend-jaxws
${cxf.version}
asm
asm
org.apache.cxf
cxf-rt-transports-http
${cxf.version}
org.apache.cxf
cxf-rt-bindings-soap
${cxf.version}
asm
asm-all
3.0
cglib
cglib-nodep
2.1_3
Now Jetty starts correctly but when I try to call a service using the
Spring+Hibernate service layer I get the exception:
Sep 13, 2007 10:20:41 AM org.apache.cxf.phase.PhaseInterceptorChaindoIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault:
org.springframework.util.ClassUtils.getMostSpe
cificMethod(Ljava/lang/reflect/Method;Ljava/lang/Class;)Ljava/lang/reflect/Metho
d;
Someone with the same problem?
Thanks,
Vicio.
On 9/12/07, Juan José Vázquez Delgado <[EMAIL PROTECTED]> wrote:
>
> I had to add this dependencies:
>
>
> asm
> asm-all
> 3.0
>
>
> cglib
> cglib-nodep
> 2.1_3
>
>
> On 9/12/07, Vincenzo Vitale <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > in my project I use Hibernate 3.2.4.sp1 and with cxf 2.0.1-incubator I
> get
> > the exception:
> >
> > org.springframework.beans.factory.BeanCreationException: Error creating
> > bean
> > with name 'sessionFactory' defined in class path resource [
> > oasis-db-context.xml]: Invocation of init method failed; nested
> exception
> > is
> > java.lang.NoClassDefFoundError
> > Caused by:
> > java.lang.NoClassDefFoundError
> > at
> org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.getProxyFactory
> > (
> > CGLIBLazyInitializer.java :117)
> >
> > when the server starts.
> >
> > Here I have red it could be for the asm library but also excluding it in
> > the
> > pom file the problem persist.
> >
> > I solved it just using cxf 2.0-incubator but maybe there is another
> > solution
> > using the last cxf release.
> >
> >
> > Someone with the same problem?
> >
> >
> >
> > Ciao,
> > V.
> >
>
SOAPFactory thread safe?
Hi,
Is the following code thread safe? In other words, can we reuse the
same soapFactory for different threads (concurrently) and within
different MEPs?
Thanks,
Guy
private static SOAPFactory soapFactory = null;
static {
try {
soapFactory = SOAPFactory.newInstance();
}
catch ( Exception e ) {
Configuration.logWarning ( "Failed to create
SOAPFactory" , e );
}
}
Re: SOAPFactory thread safe?
Seems to be perfectly thread-safe, VM guarantees that the static initializer is
executed in a thread-safe manne,
unless SOAPFactory.newInstance() has some global sideeffects.
Do you see transient failures ?
Cheers, Sergey
- Original Message -
From: "Guy Pardon" <[EMAIL PROTECTED]>
To:
Sent: Thursday, September 13, 2007 9:40 AM
Subject: SOAPFactory thread safe?
> Hi,
>
> Is the following code thread safe? In other words, can we reuse the
> same soapFactory for different threads (concurrently) and within
> different MEPs?
>
> Thanks,
> Guy
>
>
> private static SOAPFactory soapFactory = null;
>
> static {
> try {
> soapFactory = SOAPFactory.newInstance();
> }
> catch ( Exception e ) {
> Configuration.logWarning ( "Failed to create SOAPFactory" , e );
> }
> }
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: SOAPFactory thread safe?
Thanks,
Actually, my worry is more about the implementation of the factory
class. Is it designed for concurrency?
Tnx
Guy
On 13-sep-07, at 10:46, Sergey Beryozkin wrote:
Seems to be perfectly thread-safe, VM guarantees that the static
initializer is executed in a thread-safe manne,
unless SOAPFactory.newInstance() has some global sideeffects.
Do you see transient failures ?
Cheers, Sergey
- Original Message -
From: "Guy Pardon" <[EMAIL PROTECTED]>
To:
Sent: Thursday, September 13, 2007 9:40 AM
Subject: SOAPFactory thread safe?
Hi,
Is the following code thread safe? In other words, can we reuse the
same soapFactory for different threads (concurrently) and within
different MEPs?
Thanks,
Guy
private static SOAPFactory soapFactory = null;
static {
try {
soapFactory = SOAPFactory.newInstance();
}
catch ( Exception e ) {
Configuration.logWarning ( "Failed to create SOAPFactory" , e );
}
}
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland
Re: SOAPFactory thread safe?
I think I misunderstood your question, you're asking if the static instance shown in your code fragment can be reused afterwords
concurrently, but I though you were asking if the block itsef was thread-safe, sorry
Cheers, Sergey
Hi,
Is the following code thread safe? In other words, can we reuse the
same soapFactory for different threads (concurrently) and within
different MEPs?
Thanks,
Guy
private static SOAPFactory soapFactory = null;
static {
try {
soapFactory = SOAPFactory.newInstance();
}
catch ( Exception e ) {
Configuration.logWarning ( "Failed to create SOAPFactory" , e );
}
}
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
No conduit initiator
Hi, I am trying to create a client, com.none.SportsClient. When I ran it, the following exceptions occur. Any idea what are those? What is conduit initiator ? Thanks. Exception in thread "main" *javax.xml.ws.soap.SOAPFaultException*: No conduit initiator was fond for the namespace http://schemas.xmlsoap.org/soap/http. at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(*JaxWsClientProxy.java:175*) at $Proxy26.getData(Unknown Source) at com.none.SportsClient.main(*SportsClient.java:39*) Caused by: org.apache.cxf.interceptor.Fault: No conduit initiator was found for the namespace http://schemas.xmlsoap.org/soap/http. at org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(* AbstractConduitSelector.java:89*) at org.apache.cxf.endpoint.UpfrontConduitSelector.prepare(* UpfrontConduitSelector.java:61*) at org.apache.cxf.endpoint.ClientImpl.prepareConduitSelector(* ClientImpl.java:417*) at org.apache.cxf.endpoint.ClientImpl.invoke(*ClientImpl.java:251*) at org.apache.cxf.endpoint.ClientImpl.invoke(*ClientImpl.java:205*) at org.apache.cxf.frontend.ClientProxy.invokeSync(*ClientProxy.java:73*) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(*JaxWsClientProxy.java:135*) ... 2 more Caused by: *org.apache.cxf.BusException*: No conduit initiator was found for the namespace http://schemas.xmlsoap.org/soap/http. at org.apache.cxf.transport.ConduitInitiatorManagerImpl.getConduitInitiator( *ConduitInitiatorManagerImpl.java:96*) at org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(* AbstractConduitSelector.java:70*) ... 8 more
Re: UsernameToken Authentication with WSS4J
The password comparison happens I believe in the UsernameToken class. Why
don't you do a check like
String passwordDigest =
UsernameToken.doPasswordDigest(principal.getNonce(),
principal.getCreatedTime(), "REAL PASSWORD");
if (!principal.getPassword().equals(passwordDigest)) {
throw new RuntimeException("Invalid credentials");
}
or just the following if there's no digest being used:
if (!principal.getPassword().equals("REAL PASSWORD")) {
throw new RuntimeException("Invalid credentials");
}
gdprao wrote:
>
> Hi Zarar,
>
> Thanks for the reply. I have added SAAJInInterceptor() to the interceptor
> chain and error has gone. But the problem is that the service is getting
> invoked eventhough the passwords are not matching. I want to understand
> where does the password comparison occurs. From logs I have the
> following:
>
> - Inside ValidateUserTokenInterceptor..
> - principal.isPasswordDigest()= false
> - principal.getNonce()= null
> - principal.getPassword()= test
> - principal.getCreatedTime()= null
>
> The client is sending the password "test" while the CallbackHandler that
> is registered with the server is setting the password "test123".
>
> Thanks,
> Durga
>
>
> Zarar Siddiqi wrote:
>>
>> You're probably not adding SAAJInInterceptor() to your interceptor chain.
>>
>>
>>
>> gdprao wrote:
>>>
>>> Hi Zarar,
>>>
>>> Thanks for the link. I have changed my configurations with the
>>> @InInterceptors in the service implementation class and also coded
>>> WSSecurityInterceptor and ValidateUserTokenInterceptor as shown in the
>>> blog. Still I am getting the following exception when I try to invoke
>>> the service. Any clues are appreciated.
>>>
>>> 2007-09-12 16:37:43,562 - DEBUG
>>> (com.mydomain.cxfauth.interceptors.WSSecurityInterceptor:handleMessage:25)
>>> - Inside handleMessage() of WSSecurityInterceptor.
>>> Sep 12, 2007 4:37:43 PM org.apache.cxf.phase.PhaseInterceptorChain
>>> doIntercept
>>> INFO: Interceptor has thrown exception, unwinding now
>>> org.apache.cxf.binding.soap.SoapFault: NO_SAAJ_DOC
>>> at
>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:116)
>>> at
>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:59)
>>> 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:78)
>>> at
>>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:231)
>>> at
>>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.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:709)
>>>
>>>
>>> Further, I want to know where the passwords comparison occurs. From the
>>> following code snippet of ValidateUserTokenInterceptor:
>>>
>>> if (!principal.isPasswordDigest() ||
>>> principal.getNonce() == null ||
>>> principal.getPassword() == null ||
>>> principal.getCreatedTime() == null) {
>>> throw new RuntimeException("Invalid Security
>>> Header");
>>> } else {
>>>
>>> //Where does the passwords compared??
>>>
>>> userTokenValidated = true;
>>> }
>>>
>>>
>>> Thanks,
>>> Durga
>>>
>>>
>>>
>>>
>>> Zarar Siddiqi wrote:
You'll need a ValidateUserTokenInterceptor as shown here:
http://arsenalist.com/2007/07/31/cxf-ws-security-using-jsr-181-interceptor-annotations-xfire-migration/
gdprao wrote:
>
> I am facing a problem with the password comparison using WSS4J
> interceptors. I see the username and password are passed from the
> client to the server correctly and invoking PasswordCallbackHandler
> from SOAP message logs. As per my understanding the actual password
> comparison is done by WSS4J. The problem I am facing is that the
> service is getting invoked even if the passwords are not matching
> while I am expecting the SOAP fault to be thrown. The client is
> sending the password "test" while the server is expecting "test123"
> for the user "admin". Here are my logs and configuration. Please let
> me know if I am missing anything.
>
> Server side applicationContext-cxf.xml:
>
> implementor="com.mydomain.cxfauth.HelloWorldImpl"
> address="/HelloWorld">
>
>
>
>
RE: UsernameToken Authentication with WSS4J
Hi,
The problem lies in WSS4J's processing of the password. If the incoming
password is hashed, then the CallbackHandler is used to retrieve a
password, which is then compared in the UsernameTokenProcessor. However,
if the password is in plaintext, as yours is, then all validation is
delegated to the CallbackHandler implementation.
See the javadoc here for further explanation:
http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/processor/User
nameTokenProcessor.html#handleUsernameToken(org.w3c.dom.Element,%20javax
.security.auth.callback.CallbackHandler)
A JIRA has already been raised in WSS4J to improve the processing of
password:
http://issues.apache.org/jira/browse/WSS-54
Colm.
-Original Message-
From: gdprao [mailto:[EMAIL PROTECTED]
Sent: 13 September 2007 01:59
To: cxf-user@incubator.apache.org
Subject: Re: UsernameToken Authentication with WSS4J
Hi Zarar,
Thanks for the reply. I have added SAAJInInterceptor() to the
interceptor
chain and error has gone. But the problem is that the service is
getting
invoked eventhough the passwords are not matching. I want to understand
where does the password comparison occurs. From logs I have the
following:
- Inside ValidateUserTokenInterceptor..
- principal.isPasswordDigest()= false
- principal.getNonce()= null
- principal.getPassword()= test
- principal.getCreatedTime()= null
The client is sending the password "test" while the CallbackHandler that
is
registered with the server is setting the password "test123".
Thanks,
Durga
Zarar Siddiqi wrote:
>
> You're probably not adding SAAJInInterceptor() to your interceptor
chain.
>
>
>
> gdprao wrote:
>>
>> Hi Zarar,
>>
>> Thanks for the link. I have changed my configurations with the
>> @InInterceptors in the service implementation class and also coded
>> WSSecurityInterceptor and ValidateUserTokenInterceptor as shown in
the
>> blog. Still I am getting the following exception when I try to
invoke
>> the service. Any clues are appreciated.
>>
>> 2007-09-12 16:37:43,562 - DEBUG
>>
(com.mydomain.cxfauth.interceptors.WSSecurityInterceptor:handleMessage:2
5)
>> - Inside handleMessage() of WSSecurityInterceptor.
>> Sep 12, 2007 4:37:43 PM org.apache.cxf.phase.PhaseInterceptorChain
>> doIntercept
>> INFO: Interceptor has thrown exception, unwinding now
>> org.apache.cxf.binding.soap.SoapFault: NO_SAAJ_DOC
>> at
>>
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JI
nInterceptor.java:116)
>> at
>>
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JI
nInterceptor.java:59)
>> at
>>
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
hain.java:207)
>> at
>>
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiati
onObserver.java:73)
>> at
>>
org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDes
tination.java:78)
>> at
>>
org.apache.cxf.transport.servlet.ServletController.invokeDestination(Ser
vletController.java:231)
>> at
>>
org.apache.cxf.transport.servlet.ServletController.invoke(ServletControl
ler.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:709)
>>
>>
>> Further, I want to know where the passwords comparison occurs. From
the
>> following code snippet of ValidateUserTokenInterceptor:
>>
>> if (!principal.isPasswordDigest() ||
>> principal.getNonce() == null ||
>> principal.getPassword() == null ||
>> principal.getCreatedTime() == null) {
>> throw new RuntimeException("Invalid Security
>> Header");
>> } else {
>>
>> //Where does the passwords compared??
>>
>> userTokenValidated = true;
>> }
>>
>>
>> Thanks,
>> Durga
>>
>>
>>
>>
>> Zarar Siddiqi wrote:
>>>
>>> You'll need a ValidateUserTokenInterceptor as shown here:
>>>
>>>
http://arsenalist.com/2007/07/31/cxf-ws-security-using-jsr-181-intercept
or-annotations-xfire-migration/
>>>
>>>
>>>
>>>
>>>
>>>
>>> gdprao wrote:
I am facing a problem with the password comparison using WSS4J
interceptors. I see the username and password are passed from the
client to the server correctly and invoking PasswordCallbackHandler
from SOAP message logs. As per my understanding the actual
password
comparison is done by WSS4J. The problem I am facing is that the
service is getting invoked even if the passwords are not matching
while
I am expecting the SOAP fault to be thrown. The client is sending
the
password "test" while the server is expecting "test123" for the
user
"admin". Here are my logs and configuration. Please let me know
if I
am missing anything.
>>>
Re: No conduit initiator
Hi Kevin， You need to include the cxf-rt-transports-http-jetty-*-incubator.jar in you class path, or add the cxf-rt-transports-http-jetty dependency in you pom.xml. Willem. kevin Wong wrote: Hi, I am trying to create a client, com.none.SportsClient. When I ran it, the following exceptions occur. Any idea what are those? What is conduit initiator ? Thanks. Exception in thread "main" *javax.xml.ws.soap.SOAPFaultException*: No conduit initiator was fond for the namespace http://schemas.xmlsoap.org/soap/http. at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(*JaxWsClientProxy.java:175*) at $Proxy26.getData(Unknown Source) at com.none.SportsClient.main(*SportsClient.java:39*) Caused by: org.apache.cxf.interceptor.Fault: No conduit initiator was found for the namespace http://schemas.xmlsoap.org/soap/http. at org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(* AbstractConduitSelector.java:89*) at org.apache.cxf.endpoint.UpfrontConduitSelector.prepare(* UpfrontConduitSelector.java:61*) at org.apache.cxf.endpoint.ClientImpl.prepareConduitSelector(* ClientImpl.java:417*) at org.apache.cxf.endpoint.ClientImpl.invoke(*ClientImpl.java:251*) at org.apache.cxf.endpoint.ClientImpl.invoke(*ClientImpl.java:205*) at org.apache.cxf.frontend.ClientProxy.invokeSync(*ClientProxy.java:73*) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(*JaxWsClientProxy.java:135*) ... 2 more Caused by: *org.apache.cxf.BusException*: No conduit initiator was found for the namespace http://schemas.xmlsoap.org/soap/http. at org.apache.cxf.transport.ConduitInitiatorManagerImpl.getConduitInitiator( *ConduitInitiatorManagerImpl.java:96*) at org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(* AbstractConduitSelector.java:70*) ... 8 more
Re: Failed to deploy the sample helloworld.war to WebLogic Server 9.2
JUST FYI , Here is a related thread[1] in the CXF Chinese Google group cxf-zh. [1] http://groups.google.com/group/cxf-zh/browse_thread/thread/5a31ac860999df2 Willem. william_w_hu wrote: I'm using apache-cxf-2.0.1-incubaor and WebLogic Server 9.2. I was able to run the helloworld sample coming from cxf in tomcat smoothly. But when i tried to deploy it to WLS 9.2 I always got a ClassNotFoundException as following. Anyone has encounterred similar problem? Help is highly appreciated. Thanks. ps. i build helloworld using "ant war" command according to the README. And copied all files in lib and modules except for modules/integration to "C:\Program Files\bea\weblogic92\samples\domains\wl_server\lib". I deployed the helloworld.war using WLS admin console into the examplesServer. === Stack trace=== <[STANDBY] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1189664354656> (StubLifecycleHelper.java:48) at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:504) at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletContext.java:1698) at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(WebAppServletContext.java:1675) at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1595) at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2734) at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:892) at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:336) at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60) at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200) at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:117) at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60) at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:26) at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:641) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:229) at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:154) org.springframework.beans.FatalBeanException: Could not load class: demo.hw.server.GreeterImpl; nested exception is java.lang.ClassNotFoundException: demo.hw.server.GreeterImpl at org.apache.cxf.jaxws.spring.EndpointDefinitionParser.loadImplementor(EndpointDefinitionParser.java:133) at org.apache.cxf.jaxws.spring.EndpointDefinitionParser.doParse(EndpointDefinitionParser.java:84) at org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser.parseInternal(AbstractSingleBeanDefinitionParser.java:70) 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) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1104) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:133) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:90) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:458) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:353) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:303) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:280) at org.apache.cxf.transport.servlet.CXFServlet.loadAdditionalConfig(CXFServlet.java:194) at org.apache.cxf.transport.servlet.CXFServlet.loadSpringBus(CXFServlet.java:164) at org.apache.cxf.transport.servlet.CXF
Invoking a service based on service URL, not WSL URL
Hi, How can I invoke a service whose address is only known at runtime (i.e., whose address is not in the WSDL)? Thanks, Guy
Re: Invoking a service based on service URL, not WSL URL
Hi Guy, Please refer to http://www.nabble.com/Client-question-tf4357978.html#a12419843, several options to set address dynamically on client side. Best Regards Freeman Guy Pardon wrote: Hi, How can I invoke a service whose address is only known at runtime (i.e., whose address is not in the WSDL)? Thanks, Guy
RE: Not able to catch desired Fault type
Your WSDL snippet and the response message look ok. You may want to send out your WSDL file and client/server code (or paste them in a JIRA), so that we can have a quick debug to see whats going wrong there. Thanks, Jervis > -Original Message- > From: Richard Mixon [mailto:[EMAIL PROTECTED] > Sent: 2007?9?13? 11:16 > To: cxf-user@incubator.apache.org > Subject: Not able to catch desired Fault type > > > I would appreciate some help trying to understand how to > catch faults that > are defined in my WSDL in a Java client. > > My web service appears to be correctly throwing a specific Fault - > MemberExistsFault - when trying to add a record and the member already > exists. > > However when I catch it on the client, I am not able to catch a > MemberExistsFault. Instead the exception can be caught as a > javax.xml.ws.soap.SOAPFaultException > which in turn has a cause of > org.apache.cxf.binding.soap.SoapFault. > > > Here is what the log shows on the server: > INFO: Outbound Message > -- > http://www.w3.org/2003/05/soap-envelope";> > > > > soap:Receiver > > > > Member cannot be added, it is already in the database > > > > xmlns:ns2="http://service.webservice.acme.com/";> > [EMAIL PROTECTED] > myLastName > myFirstName3 > > > > > > -- > > Below are the key parts of the WSDL (I can send the whole thing if > necessary). > > Thanks in advance - Richard > > >targetNamespace="http://service.webservice.acme.com/"; > xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"; > xmlns:ns1="http://service.webservice.acme.com/"; > xmlns:tns="http://types.webservice.firedrum.com/"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";> > > http://www.w3.org/2001/XMLSchema"; > xmlns:tns="http://types.webservice.acme.com/"; > attributeFormDefault="unqualified" > elementFormDefault="unqualified" > targetNamespace="http://types.webservice.acme.com/";> > ... >type="tns:MemberIdInfoType"> > > > >type="xs:string"> > > > > > > > > ... > > > > > > ... > > > > > > message="ns1:addMemberResponse"> > > message="ns1:InvalidClientFault"> > > message="ns1:MemberExistsFault"> > > message="ns1:InvalidEmailAddressFault"> > > message="ns1:CategoryNotFoundFault"> > > message="ns1:CustomFieldTypeNotFoundFault"> > > message="ns1:AddMemberUnknownFault"> > > > > type="ns1:MemberService"> > > transport="http://www.w3.org/2003/05/soap/bindings/HTTP/"; /> > > > > > > > > > > > > > > > > > > > > binding="ns1:MemberServiceServiceSoapBinding"> >location="http://localhost:8080/services/MemberService"; /> > > > > > > IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: jaxws:endpoint wsdlLocation attribute -- form for class path reference?
I have CXFServlet loading "WEB-INF/wsdl/hello.wsdl" just fine. not sure why it didn't work for me yesterday, possibly because I was using an absolute "/WEB-INF/wsdl/hello.wsdl" form... So things are cool. Cheers, Sergey > > Hi > > I was about to ask a question if a wsdl document should always be located > inside WEB-INF/classes or WEB-INF/libs, and then I found this thread... > > I agree it's a pain having to relocate a resource like > WEB-INF/wsdl/hello.wsdl into WEB-INF/classes/wsdl/hello.wsdl just to make it > work, esppecially when one deal with prepackaged wars. > > Unfortunately I have little knowledge of Spring at this stage, but the idea > of using some Spring webapp-aware context classes looked promising so that > resources like "/WEB-INF/wsdl/hello.wsdl" could also be resolved. Is it > where CXFServlet can be enhanced a bit ? > > By the way, I'm using Tomcat 5.5.25, Windows XP. > > Thanks, Sergey > > > CMoesel wrote: >> >> I ran into this very same issue when trying to run the war using the >> maven jetty plugin. It also searched from the working directory instead >> of the root of the application context. It worked however, when I tried >> it in Tomcat 5.5 and Jboss 4.0 standalone. >> >> In order to get it working in the maven jetty plugin though, I had to >> put my wsdl in the classpath (WEB-INF/classes/myservice.wsdl) and then >> refer to it in the as wsdlLocation="myservice.wsdl" >> (note the lack of "classpath:" prefix). >> >> If you don't mind putting it in the classpath, that may be the best >> solution for you right now (assuming it works!). >> >> -Chris >> >> -Original Message- >> From: Steven E. Harris [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, May 02, 2007 11:32 PM >> To: cxf-user@incubator.apache.org >> Subject: Re: jaxws:endpoint wsdlLocation attribute -- form for class >> path reference? >> >> "Jiang, Ning \(Willem\)" <[EMAIL PROTECTED]> writes: >> >>> I just try the latest kit's (build with latest trunk) helloworld >>> sample with the wsdlLocation="WEB-INF/wsdl/hello_world.wsdl". >>> >>> It is workable. >> >> That's good to hear. >> >>> Can you check your wsdl in the war or try the CXF helloworld sample? >> >> Actually, I'm deploying via an explode WAR directory, but my WSDL is >> in the proper place in the directory. I just tried deploying via an >> actual WAR file as well. The files are in the directory and in the >> WAR. I tried matching your location specification above: >> "WEB-INF/wsdl/myfile.wsdl". No matter what, the search fails, >> apparently taking the current working directory as the base for the >> search: >> >> Caused by: javax.wsdl.WSDLException: WSDLException: >> faultCode=PARSER_ERROR: Problem parsing 'WEB-INF/wsdl/myfile.wsdl'.: >> java.io.FileNotFoundException: C:\Program >> Files\Java\add-ons\apache-tomcat-6.0.10\bin\WEB-INF\wsdl\myfile.wsdl >> (The system cannot find the path specified) >> at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source) >> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >> at >> org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.jav >> a:177) >> at >> org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java >> :141) >> at >> org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java: >> 81) >> ... 42 more >> Caused by: java.io.FileNotFoundException: C:\Program >> Files\Java\add-ons\apache-tomcat-6.0.10\bin\WEB-INF\wsdl\myfile.wsdl >> (The system cannot find the path specified) >> at java.io.FileInputStream.open(Native Method) >> at java.io.FileInputStream.(FileInputStream.java:106) >> at java.io.FileInputStream.(FileInputStream.java:66) >> at >> sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.ja >> va:70) >> at >> sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnec >> tion.java:161) >> at >> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEnt >> ity(XMLEntityManager.java:653) >> at >> com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocV >> ersion(XMLVersionDetector.java:186) >> at >> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML1 >> 1Configuration.java:771) >> at >> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML1 >> 1Configuration.java:737) >> at >> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.jav >> a:107) >> at >> com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.jav >> a:225) >> at >> com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Docume >> ntBuilderImpl.java:283) >> ... 48 more >> >> >> If I start Tomcat from a shell, the same error arises, but the current >> working directory matches that of the shell that called startup.sh. >> >> I'll give up for now and try again with tomorrow's snapshots. >> >> -- >> Steven E. Harris >> >> > > -- > View this message in context:
Re: jaxws:endpoint wsdlLocation attribute -- form for class path reference?
phew...I thought I was going to loose my mind. I had two webapps, absolutely identical in structure, one loading "WEB-INF/wsdl/hello.wsdl" just fine yet another one failing to load "WEB-INF/wsdl/greetMe.wsdl". cxf-servlet.xmls were absolutely identical in format too...or so I thought. Fortunately, I was saved, I was pointed out that one cxf-servlet.xml had the following import statements, which I copied from the docs : These import statements upset CXFServler and "WEB-INF/wsdl/greetMe.wsdl" can not be loaded. Without these imports "WEB-INF/wsdl/greetMe.wsdl" is loaded just fine... Cheers, Sergey - Original Message - From: "Sergey Beryozkin" <[EMAIL PROTECTED]> To: Sent: Thursday, September 13, 2007 12:19 PM Subject: Re: jaxws:endpoint wsdlLocation attribute -- form for class path reference? I have CXFServlet loading "WEB-INF/wsdl/hello.wsdl" just fine. not sure why it didn't work for me yesterday, possibly because I was using an absolute "/WEB-INF/wsdl/hello.wsdl" form... So things are cool. Cheers, Sergey > > Hi > > I was about to ask a question if a wsdl document should always be located > inside WEB-INF/classes or WEB-INF/libs, and then I found this thread... > > I agree it's a pain having to relocate a resource like > WEB-INF/wsdl/hello.wsdl into WEB-INF/classes/wsdl/hello.wsdl just to make it > work, esppecially when one deal with prepackaged wars. > > Unfortunately I have little knowledge of Spring at this stage, but the idea > of using some Spring webapp-aware context classes looked promising so that > resources like "/WEB-INF/wsdl/hello.wsdl" could also be resolved. Is it > where CXFServlet can be enhanced a bit ? > > By the way, I'm using Tomcat 5.5.25, Windows XP. > > Thanks, Sergey > > > CMoesel wrote: >> >> I ran into this very same issue when trying to run the war using the >> maven jetty plugin. It also searched from the working directory instead >> of the root of the application context. It worked however, when I tried >> it in Tomcat 5.5 and Jboss 4.0 standalone. >> >> In order to get it working in the maven jetty plugin though, I had to >> put my wsdl in the classpath (WEB-INF/classes/myservice.wsdl) and then >> refer to it in the as wsdlLocation="myservice.wsdl" >> (note the lack of "classpath:" prefix). >> >> If you don't mind putting it in the classpath, that may be the best >> solution for you right now (assuming it works!). >> >> -Chris >> >> -Original Message- >> From: Steven E. Harris [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, May 02, 2007 11:32 PM >> To: cxf-user@incubator.apache.org >> Subject: Re: jaxws:endpoint wsdlLocation attribute -- form for class >> path reference? >> >> "Jiang, Ning \(Willem\)" <[EMAIL PROTECTED]> writes: >> >>> I just try the latest kit's (build with latest trunk) helloworld >>> sample with the wsdlLocation="WEB-INF/wsdl/hello_world.wsdl". >>> >>> It is workable. >> >> That's good to hear. >> >>> Can you check your wsdl in the war or try the CXF helloworld sample? >> >> Actually, I'm deploying via an explode WAR directory, but my WSDL is >> in the proper place in the directory. I just tried deploying via an >> actual WAR file as well. The files are in the directory and in the >> WAR. I tried matching your location specification above: >> "WEB-INF/wsdl/myfile.wsdl". No matter what, the search fails, >> apparently taking the current working directory as the base for the >> search: >> >> Caused by: javax.wsdl.WSDLException: WSDLException: >> faultCode=PARSER_ERROR: Problem parsing 'WEB-INF/wsdl/myfile.wsdl'.: >> java.io.FileNotFoundException: C:\Program >> Files\Java\add-ons\apache-tomcat-6.0.10\bin\WEB-INF\wsdl\myfile.wsdl >> (The system cannot find the path specified) >> at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source) >> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >> at >> org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.jav >> a:177) >> at >> org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java >> :141) >> at >> org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java: >> 81) >> ... 42 more >> Caused by: java.io.FileNotFoundException: C:\Program >> Files\Java\add-ons\apache-tomcat-6.0.10\bin\WEB-INF\wsdl\myfile.wsdl >> (The system cannot find the path specified) >> at java.io.FileInputStream.open(Native Method) >> at java.io.FileInputStream.(FileInputStream.java:106) >> at java.io.FileInputStream.(FileInputStream.java:66) >> at >> sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.ja >> va:70) >> at >> sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnec >> tion.java:161) >> at >> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEnt >> ity(XMLEntityManager.java:653) >> at >> com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocV >> ersion(XMLVersionDetector.java:186) >>
Re: cxf servlet and jaxws:endpoint questions
By the way, using jaxws:endpoint/@implementorClass does not work at all for me in a servlet env, but when I use 'implementor' to point to a fuly-qualified class then things are fine. I'm inclined to open a bug, is it really bug though ? Cheers, Sergey - Original Message - From: "Sergey Beryozkin" <[EMAIL PROTECTED]> To: Sent: Wednesday, September 12, 2007 1:35 PM Subject: Re: cxf servlet and jaxws:endpoint questions HI Just a follow-up question... So is the rule of thumb is to use wildcard url patterns, like "/services/*" and then use jaxws:endpoint/@address values like "/GreetMe" ? I'm wondering why specifying a pattern like "/services/GreetMe" doesn work...Casually glancing through a servler code didn't give me an answer so I'll probably have to look harder :-). Cheers, Sergey - Original Message - From: "Sergey Beryozkin" <[EMAIL PROTECTED]> To: Sent: Wednesday, September 12, 2007 1:22 PM Subject: Re: cxf servlet and jaxws:endpoint questions Hi Chris It does work, super ! Thanks for a quick reply, Sergey - Original Message - From: "Christopher Moesel" <[EMAIL PROTECTED]> To: Sent: Wednesday, September 12, 2007 1:14 PM Subject: RE: cxf servlet and jaxws:endpoint questions Hi Sergey, The following combination *should* work... In web.xml, the url-pattern for the servlet-mapping: /hello/* In the jaxws:endpoint/@address: /world I believe that the difference between implementor and implementorClass is this: implementor: a reference to an *instance* of your SEI implementation (in Spring, you use this style: #myServiceEndpointImp) implementorClass: the fully qualified classname of your SEI implementation, which must have a default constructor (for example, com.mycompany.MyServiceEndpointImpl) I hope that helps! -Chris -Original Message- From: Sergey Beryozkin [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 12, 2007 7:55 AM To: cxf-user@incubator.apache.org Subject: cxf servlet and jaxws:endpoint questions Hi I have few questions with respect to deploying a cxf servlet into tomcat : * how to use/combine correctly a servlet's url pattern and an jaxws:endpoint/@address values ? For example, suppose I have a webapp "test" and I want my servlet to recognize this pattern : /hello/world As such, I'd like GET http://localhost:8080/test/hello/world?wsdl to return me a wsdl. In web.xml I've tried /hello/* /hello/world and in jaxws:endpoint/@address I tried /hello/world /world with no luck, the above request returns no service is available * what is the difference between jaxws:endpoint/@implementer and jaxws:endpoint/@implementerClass attributes ? Thanks, Sergey IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Error when trying to contact service over SSL on a specific port
That's what I understood but according to CXF-922 that isn't the case right
now. I did get this to work but had to do it programatically. I changed my
client call to be this:
QName SERVICE_NAME = new QName("http://com.comments.client/";,
"ClientCommentsService");
URL wsdlURL = new
URL("https://somedomain:1040/clientservices/ClientCommentsService.asmx?WSDL";);
ClientCommentsService ss = new ClientCommentsService(wsdlURL, SERVICE_NAME);
ClientCommentsServiceSoap port = ss.getClientCommentsServiceSoap();
Client c = ClientProxy.getClient(port);
HTTPConduit conduit = (HTTPConduit)c.getConduit();
HTTPClientPolicy httpPolicy = new HTTPClientPolicy();
httpPolicy.setConnection(ConnectionType.KEEP_ALIVE);
httpPolicy.setMaxRetransmits(1);
httpPolicy.setAllowChunking(false);
httpPolicy.setContentType("text/xml");
conduit.setClient(httpPolicy);
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.setSecureSocketProtocol("SSL");
FiltersType filters = new FiltersType();
filters.getInclude().add(".*_EXPORT_.*");
filters.getInclude().add(".*_EXPORT1024_.*");
filters.getInclude().add(".*_WITH_DES_.*");
filters.getInclude().add(".*_WITH_NULL_.*");
filters.getInclude().add(".*_DH_anon_.*");
filters.getInclude().add("SSL_RSA_WITH_RC4_128_MD5");
filters.getInclude().add("SSL_RSA_WITH_RC4_128_SHA");
tlsParams.setCipherSuitesFilter(filters);
conduit.setTlsClientParameters(tlsParams);
SaveCommentResponseType _saveComment__return =
port.saveComment("4823048230484203",
"48230482304",
"Note",
"Note",
"My Name",
"09/11/2007");
As you can see I added the FilterTypes to the TLSClientParameters and that
allows me to make the call now without error.
When I still make the call from a spring context I receive the error that is
in CXF-922. I haven't tried the workaround b/c I would rather wait for a
complete fix to that error then have a workaround. Since I have this
working it's good enough at this moment.
Let me know if there is other information that you guys would need to help
out with the issue.
Thanks
Ryan Moquin wrote:
>
> So is this saying that in every case that you have an SSL config in
> cxf.xml,
> it will not be applied to your request unless you do it programmatically?
>
> On 9/12/07, pdog <[EMAIL PROTECTED]> wrote:
>>
>>
>> When I try to call the service without the ssl socket wrap it gives an
>> error
>> saying it can't communicate with the service, which makes sense since
>> it's
>> not accessible over non-ssl:
>>
>> javax.xml.ws.soap.SOAPFaultException: Could not send Message.
>> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(
>> JaxWsClientProxy.java:175)
>> at $Proxy131.saveComment(Unknown Source)
>> at
>> com.cc.spring.actions.employee.ClaimCenterDashAction.viewOrDisplay(
>> ClaimCenterDashAction.java:109)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
>> :39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:585)
>> at
>> org.springframework.webflow.util.DispatchMethodInvoker.invoke(
>> DispatchMethodInvoker.java:103)
>> at
>> org.springframework.webflow.action.MultiAction.doExecute(MultiAction.java
>> :136)
>> at
>> org.springframework.webflow.action.AbstractAction.execute(
>> AbstractAction.java:203)
>> at
>> org.springframework.webflow.engine.AnnotatedAction.execute(
>> AnnotatedAction.java:142)
>> at
>> org.springframework.webflow.engine.ActionExecutor.execute(
>> ActionExecutor.java:61)
>> at
>> org.springframework.webflow.engine.ActionList.execute(ActionList.java:160)
>> at org.springframework.webflow.engine.State.enter(State.java:199)
>> at org.springframework.webflow.engine.Flow.start(Flow.java:557)
>> at
>> org.springframework.webflow.engine.impl.RequestControlContextImpl.start(
>> RequestControlContextImpl.java:196)
>> at
>> org.springframework.webflow.engine.impl.FlowExecutionImpl.start(
>> FlowExecutionImpl.java:189)
>> at
>> org.springframework.webflow.executor.FlowExecutorImpl.launch(
>> FlowExecutorImpl.java:206)
>> at
>>
>> org.springframework.webflow.executor.support.FlowRequestHandler.handleFlowRequest
>> (FlowRequestHandler.java:131)
>> at
>>
>> org.springframework.webflow.executor.mvc.FlowController.handleRequestInternal
>> (FlowController.java:172)
>> at
>> org.springframework.web.servlet.mvc.AbstractController.handleRequest(
>> AbstractController.java:153)
>> at
>> org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(
>> SimpleControllerHandlerAdapter.java:45)
>> at
>> org.springframework.web.servlet.DispatcherServlet.doDispatch(
>> DispatcherServlet.java:820)
>> at
>> org.
Re: WSDL part name incorrect. How do you change it?
This has to be a problem because although the WSDL snippet is this:
during a fault the SOAP returned is this:
http://schemas.xmlsoap.org/soap/envelope/";>
soap:Server
...
http://arsenalist.com";>
5001
Now IMHO this is wrong because using any client the exception's QName is
{http://arsenalist.com}fault but the actual QName that's needed to serialize
it is {http://arsenalist.com}WebServiceException. If I change the generated
client code (try any client: XFire, CXF, Axis2 etc.) to have
WebServiceException as the local part instead of fault, it works.
Any ideas?
Zarar Siddiqi wrote:
>
> I'm seeing the following behavior. I have an exception which is annotated
> with:
>
> @WebFault(name="WebServiceException")
> @XmlType(name="WebServiceException", namespace="http://arsenalist.com";)
> public class MyWebServiceException extends Exception {...}
>
> but the WSDL that is generated is:
>
>
>
>
>
> IMHO, the name of the part should be "WebServiceException" and not
> "fault". Is my thinking correct? If not, how do you change the WSDL part
> name? Are there any Aegis annotations that can be used at the class level
> to change this?
>
> Thanks,
> Zarar
>
--
View this message in context:
http://www.nabble.com/WSDL-part-name-incorrect.-How-do-you-change-it--tf4432101.html#a12655879
Sent from the cxf-user mailing list archive at Nabble.com.
CXF exception
I just wrote a web service using CXF. It works okay. However, every time it gets called, it throws an exception shown below. Am I missing something? Regards, Ramanand Singh Architecture Team GEICO IBU Service 301.986.2791 2007-09-13 11:36:09,773 [main] [] INFO support.ClassPathXmlApplicationContext - Refreshing [EMAIL PROTECTED] c9e: display name [EMAIL PROTECTED] 5c9e]; startup date [Thu Sep 13 11:36:09 EDT 2007]; root of context hierarchy 2007-09-13 11:36:09,883 [main] [] INFO xml.XmlBeanDefinitionReader - Loading XML bean definitions from class path resource [conf/spring/eauthClientContext.xml] 2007-09-13 11:36:10,148 [main] [] WARN xml.DefaultNamespaceHandlerResolver - Ignoring namespace handler [org.apache.cxf.bus.spring.NamespaceHandler]: problem with handler class file or dependent class java.lang.VerifyError: final method overridden (class: org/apache/cxf/bus/spring/BusDefinitionParser method: getIdOrName(Lorg/w3c/dom/Element;)Ljava/lang/String;) at pc: 0 at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:228) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148) at java.net.URLClassLoader.defineClass(URLClassLoader.java:556) at java.net.URLClassLoader.access$400(URLClassLoader.java:119) at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:961) at java.security.AccessController.doPrivileged(AccessController.java:275) at java.net.URLClassLoader.findClass(URLClassLoader.java:487) at java.lang.ClassLoader.loadClass(ClassLoader.java:607) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:327) at java.lang.ClassLoader.loadClass(ClassLoader.java:573) at org.apache.cxf.bus.spring.NamespaceHandler.init(NamespaceHandler.java:27 ) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.in itHandlerMappings(DefaultNamespaceHandlerResolver.java:123) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.(DefaultNamespaceHandlerResolver.java:96) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.(DefaultNamespaceHandlerResolver.java:82) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createDefa ultNamespaceHandlerResolver(XmlBeanDefinitionReader.java:489) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createRead erContext(XmlBeanDefinitionReader.java:478) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBe anDefinitions(XmlBeanDefinitionReader.java:458) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBean Definitions(XmlBeanDefinitionReader.java:353) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDe finitions(XmlBeanDefinitionReader.java:303) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDe finitions(XmlBeanDefinitionReader.java:280) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.l oadBeanDefinitions(AbstractBeanDefinitionReader.java:131) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.l oadBeanDefinitions(AbstractBeanDefinitionReader.java:147) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.l oadBeanDefinitions(AbstractBeanDefinitionReader.java:173) at org.springframework.context.support.AbstractXmlApplicationContext.loadBe anDefinitions(AbstractXmlApplicationContext.java:112) at org.springframework.context.support.AbstractXmlApplicationContext.loadBe anDefinitions(AbstractXmlApplicationContext.java:79) at org.springframework.context.support.AbstractRefreshableApplicationContex t.refreshBeanFactory(AbstractRefreshableApplicationContext.java:100) at org.springframework.context.support.AbstractApplicationContext.refresh(A bstractApplicationContext.java:313) at org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:91) at org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:75) at com.geico.ibu.service.insite.common.authentication.EAuthClient.main(EAut hClient.java:31) 2007-09-13 11:36:10,180 [main] [] INFO support.ClassPathXmlApplicationContext - Bean factory for application context [EMAIL PROTECTED] 5c9e]: [EMAIL PROTECTED] e439e 2007-09-13 11:36:10,195 [main] [] INFO support.DefaultListableBeanFactory - Pre-instantiating singletons in [EMAIL PROTECTED] e439e: defining beans [eauthClient,clientFactory]; root of factory hierarchy 2007-09-13 11:36:10,367 [main] [] INFO spring.BusApplicationContext - Refreshing [EMAIL PROTECTED]: display name [EMAIL PROTECTED]; startup date [Thu Sep 13 11:36:10 EDT 2007]; root of context hierarchy 2007-09-13 11:36:10,383 [main] [] WARN xml.DefaultNamespaceHandlerResolver - Ignoring
CXF simple front end and HTTPS ?
I cannot figure out how to use SSL in a simple front end client like the following JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean(); factory.setBus( bus ); factory.setAddress( "https://somewhere/service"; ); factory.setServiceClass( Service.class ); Service = (Service) factory.create(); I see examples where people are adding new TLSClientParameters() to the HTTPConduit, but I cannot figure out how to get the HTTPConduit in this example.
CXF+ACEGI
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#a12658821 Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-Security SAML and X.509 authentication token
Consult the WSS4J documentation (i.e., source code) for handling SAML Assertions. There is limited support for SAML 1.0 Assertions in the runtime, but note that there is no support for the processing requirements dictated by the SAML SOAP profile (e.g., for processing the SubjectConfirmation element of a SAML Assertion). You're also pretty much limited to using types as provided by OpenSAML, which provides a collection of hand-coded types based off the SAML schema -- nothing sophisticated there, and something our code generators could write in a few milliseconds. For X.509, you should be able to use the DirectReference key identifier in WSS4J, which will override the default (IssuerSerial), and embed the signing certificate directly in the SOAP security header. You could, of course, just pass an X.509 certificate through a security header, but that provides no assurance of the identity of the sender, since X.509 certificates are public documents. The sender needs to prove something about his/her identity (in particular, that she possesses the private key cryptographically bound to the public key in the sent certificate. -Fred On Sep 12, 2007, at 9:15 AM, Davide Gesino wrote: Hi, another question about WS-Security again. In CXF how can I configure a SAML or X.509 authentication tokens?! David -- View this message in context: http://www.nabble.com/WS-Security- SAML-and-X.509-authentication-token-tf4429143.html#a12634954 Sent from the cxf-user mailing list archive at Nabble.com.
Wsdl Versioning
We have recently migrated our web services offering from xfire to cxf and everything is going well. Now the issue is that we have several clients who would like different features and I am wondering how best to accomplish this. The changes being requested will likely result in a different wsdl so I would like to be able to version our wsdls with different namespaces. The question is where do I inspect the wsdl namespace and then how do I provide different functionality depending on the incoming namespace? I am using aegis bindings and cxf.xml with the cxf servlet. Any ideas would be appreciated. -- Dave Kallstrom
Re: WSDL part name incorrect. How do you change it?
I've created a JIRA and also supplied a patch which fixes this. This is also
now backwards compatible with XFire.
https://issues.apache.org/jira/browse/CXF-1002
Thanks,
Zarar
Zarar Siddiqi wrote:
>
> This has to be a problem because although the WSDL snippet is this:
>
>
>
>
>
>
> during a fault the SOAP returned is this:
>
> http://schemas.xmlsoap.org/soap/envelope/";>
>
>
> soap:Server
> ...
>
> http://arsenalist.com";>
>5001
>
>
>
>
>
> Now IMHO this is wrong because using any client the exception's QName is
> {http://arsenalist.com}fault but the actual QName that's needed to
> serialize it is {http://arsenalist.com}WebServiceException. If I change
> the generated client code (try any client: XFire, CXF, Axis2 etc.) to have
> WebServiceException as the local part instead of fault, it works.
>
> Any ideas?
>
>
>
>
> Zarar Siddiqi wrote:
>>
>> I'm seeing the following behavior. I have an exception which is
>> annotated with:
>>
>> @WebFault(name="WebServiceException")
>> @XmlType(name="WebServiceException", namespace="http://arsenalist.com";)
>> public class MyWebServiceException extends Exception {...}
>>
>> but the WSDL that is generated is:
>>
>>
>>
>>
>>
>> IMHO, the name of the part should be "WebServiceException" and not
>> "fault". Is my thinking correct? If not, how do you change the WSDL part
>> name? Are there any Aegis annotations that can be used at the class
>> level to change this?
>>
>> Thanks,
>> Zarar
>>
>
>
--
View this message in context:
http://www.nabble.com/WSDL-part-name-incorrect.-How-do-you-change-it--tf4432101.html#a12662501
Sent from the cxf-user mailing list archive at Nabble.com.
Re: cxf servlet and jaxws:endpoint questions
Hi Sergey, It is a long story. As you know jaxws:endpoint came form the RI's endpoint.xml, it only specifies the implementor's class name. So jaxws:endpoint/@implementor support implementor class name and Spring bean's reference. Because of Spring 's AOP will use proxy to do some enhance work , if we specify a Spring bean's reference with the AOP involved , we can't get the SEI class from the implementor class. And then we add the jaxws:endpoint/@implementorClass . If you take a look at the ServerFactoryBean (CXF internal API) , You can take the directly mapping the implementor to the serviceBean , and implementor class to the serviceClass. Cheers, Willem. Sergey Beryozkin wrote: By the way, using jaxws:endpoint/@implementorClass does not work at all for me in a servlet env, but when I use 'implementor' to point to a fuly-qualified class then things are fine. I'm inclined to open a bug, is it really bug though ? Cheers, Sergey - Original Message - From: "Sergey Beryozkin" <[EMAIL PROTECTED]> To: Sent: Wednesday, September 12, 2007 1:35 PM Subject: Re: cxf servlet and jaxws:endpoint questions HI Just a follow-up question... So is the rule of thumb is to use wildcard url patterns, like "/services/*" and then use jaxws:endpoint/@address values like "/GreetMe" ? I'm wondering why specifying a pattern like "/services/GreetMe" doesn work...Casually glancing through a servler code didn't give me an answer so I'll probably have to look harder :-). Cheers, Sergey - Original Message - From: "Sergey Beryozkin" <[EMAIL PROTECTED]> To: Sent: Wednesday, September 12, 2007 1:22 PM Subject: Re: cxf servlet and jaxws:endpoint questions Hi Chris It does work, super ! Thanks for a quick reply, Sergey - Original Message - From: "Christopher Moesel" <[EMAIL PROTECTED]> To: Sent: Wednesday, September 12, 2007 1:14 PM Subject: RE: cxf servlet and jaxws:endpoint questions Hi Sergey, The following combination *should* work... In web.xml, the url-pattern for the servlet-mapping: /hello/* In the jaxws:endpoint/@address: /world I believe that the difference between implementor and implementorClass is this: implementor: a reference to an *instance* of your SEI implementation (in Spring, you use this style: #myServiceEndpointImp) implementorClass: the fully qualified classname of your SEI implementation, which must have a default constructor (for example, com.mycompany.MyServiceEndpointImpl) I hope that helps! -Chris -Original Message- From: Sergey Beryozkin [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 12, 2007 7:55 AM To: cxf-user@incubator.apache.org Subject: cxf servlet and jaxws:endpoint questions Hi I have few questions with respect to deploying a cxf servlet into tomcat : * how to use/combine correctly a servlet's url pattern and an jaxws:endpoint/@address values ? For example, suppose I have a webapp "test" and I want my servlet to recognize this pattern : /hello/world As such, I'd like GET http://localhost:8080/test/hello/world?wsdl to return me a wsdl. In web.xml I've tried /hello/* /hello/world and in jaxws:endpoint/@address I tried /hello/world /world with no luck, the above request returns no service is available * what is the difference between jaxws:endpoint/@implementer and jaxws:endpoint/@implementerClass attributes ? Thanks, Sergey IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: CXF exception
Hi Ramanand Can you tell us the Spring version and CXF version that you currently use? I just checked the code, CXF trunk version and Spring 2.0.4, there are no any final method definitions of getIdOrName in BusDefinitionParser or its parent class. It is just protected String getIdOrName(Element elem) Willem. Singh, Ramanand wrote: I just wrote a web service using CXF. It works okay. However, every time it gets called, it throws an exception shown below. Am I missing something? Regards, Ramanand Singh Architecture Team GEICO IBU Service 301.986.2791 2007-09-13 11:36:09,773 [main] [] INFO support.ClassPathXmlApplicationContext - Refreshing [EMAIL PROTECTED] c9e: display name [EMAIL PROTECTED] 5c9e]; startup date [Thu Sep 13 11:36:09 EDT 2007]; root of context hierarchy 2007-09-13 11:36:09,883 [main] [] INFO xml.XmlBeanDefinitionReader - Loading XML bean definitions from class path resource [conf/spring/eauthClientContext.xml] 2007-09-13 11:36:10,148 [main] [] WARN xml.DefaultNamespaceHandlerResolver - Ignoring namespace handler [org.apache.cxf.bus.spring.NamespaceHandler]: problem with handler class file or dependent class java.lang.VerifyError: final method overridden (class: org/apache/cxf/bus/spring/BusDefinitionParser method: getIdOrName(Lorg/w3c/dom/Element;)Ljava/lang/String;) at pc: 0 at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:228) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148) at java.net.URLClassLoader.defineClass(URLClassLoader.java:556) at java.net.URLClassLoader.access$400(URLClassLoader.java:119) at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:961) at java.security.AccessController.doPrivileged(AccessController.java:275) at java.net.URLClassLoader.findClass(URLClassLoader.java:487) at java.lang.ClassLoader.loadClass(ClassLoader.java:607) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:327) at java.lang.ClassLoader.loadClass(ClassLoader.java:573) at
RE: Wsdl Versioning
Hi Dave, we've had a very basic versioning implementation. Basically how it works is an interceptor sitting at the beginning of in-bound interceptor chain as a mediator to inspect then dispatch the coming request to different endpoints. An example can be found from a system test sample: \trunk\systests\src\test\java\org\apache\cxf\systest\versioning. Let me know if you have any further questions. Willem Jiang is currently working on adding a much more powerful routing support using Apache Camel, hopefully this will provide a better foundation for implementing versioning in CXF once it is done. Cheers, Jervis > -Original Message- > From: Dave Kallstrom [mailto:[EMAIL PROTECTED] > Sent: 2007?9?14? 2:53 > To: cxf-user@incubator.apache.org > Subject: Wsdl Versioning > > > We have recently migrated our web services offering from > xfire to cxf and > everything is going well. Now the issue is that we have > several clients who > would like different features and I am wondering how best to > accomplish > this. The changes being requested will likely result in a > different wsdl so > I would like to be able to version our wsdls with different > namespaces. The > question is where do I inspect the wsdl namespace and then > how do I provide > different functionality depending on the incoming namespace? > I am using > aegis bindings and cxf.xml with the cxf servlet. > Any ideas would be appreciated. > > -- > Dave Kallstrom > IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: CXF simple front end and HTTPS ?
Hi , You can get the HttpConduit with these codes after creating the service object. Client client = ClientProxy.getClient(service); HttpConduit conduit = (HttpConduit) client.getConduit(); Willem. Chris Campbell wrote: I cannot figure out how to use SSL in a simple front end client like the following JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean(); factory.setBus( bus ); factory.setAddress( "https://somewhere/service"; ); factory.setServiceClass( Service.class ); Service = (Service) factory.create(); I see examples where people are adding new TLSClientParameters() to the HTTPConduit, but I cannot figure out how to get the HTTPConduit in this example.
Re: Failed to deploy the sample helloworld.war to WebLogic Server 9.2
Thanks. I will give it a try. I mean the "full war". Jeff.Yu wrote: > > Hi, William > > I would recommend that you build a "FULL WAR", which includes all the > required jars in the $WAR/WEB-INF/lib, instead of copying all the > libraries to the weblogic system libraries. > > You might need to get the updated common_build.xml[1] to replace the old > one in apache-cxf-2.0.1-incubator, and then run the "ANT WAR" to get the > "FULL WAR", and then deploy the WAR to weblogic/webapps, remember to > remove the libs from weblogic system libraries folder. > > You can refer to BUG JIRA[2] for detail, and if you can read chinese, > here is a thread[3] discussed about it. BTW, in the 2.0.2 release, we > build the "FULL WAR" by default, if it is possible, you can give it a > try against apache-cxf-2.0.2-incubator[4], although it is in voting now. > > > Thanks > Jeff > > [1] > https://svn.apache.org/repos/asf/incubator/cxf/trunk/distribution/src/main/release/samples/common_build.xml > [2] http://issues.apache.org/jira/browse/CXF-901 > [3] > http://groups.google.com/group/cxf-zh/browse_thread/thread/9101cb751fa13376?hl=en > [4] http://people.apache.org/~dkulp/stage_cxf/2.0.2-incubator-take1/dist/ > > > william_w_hu wrote: >> I'm using apache-cxf-2.0.1-incubaor and WebLogic Server 9.2. I was able >> to >> run the helloworld sample coming from cxf in tomcat smoothly. But when i >> tried to deploy it to WLS 9.2 I always got a ClassNotFoundException as >> following. Anyone has encounterred similar problem? Help is highly >> appreciated. Thanks. >> >> ps. i build helloworld using "ant war" command according to the README. >> And >> copied all files in lib and modules except for modules/integration to >> "C:\Program Files\bea\weblogic92\samples\domains\wl_server\lib". I >> deployed >> the helloworld.war using WLS admin console into the examplesServer. >> >> === Stack trace=== >> <[STANDBY] ExecuteThread: '2' >> for >> queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> >> <1189664354656> > in >> Web application: "helloworld". >> org.springframework.beans.factory.BeanDefinitionStoreException: >> Unexpected >> exception parsing XML document from /WEB-INF/cxf-servlet.xml; nested >> exception is org.springframework.beans.FatalBeanException: Could not load >> class: demo.hw.server.GreeterImpl; nested exception is >> java.lang.ClassNotFoundException: demo.hw.server.GreeterImpl >> at >> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:375) >> at >> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:303) >> at >> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:280) >> at >> org.apache.cxf.transport.servlet.CXFServlet.loadAdditionalConfig(CXFServlet.java:194) >> at >> org.apache.cxf.transport.servlet.CXFServlet.loadSpringBus(CXFServlet.java:164) >> at org.apache.cxf.transport.servlet.CXFServlet.init(CXFServlet.java:98) >> at >> weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:276) >> at >> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) >> at >> weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) >> at >> weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityHelper.java:68) >> at >> weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLifecycleHelper.java:58) >> at >> weblogic.servlet.internal.StubLifecycleHelper.(StubLifecycleHelper.java:48) >> at >> weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:504) >> at >> weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletContext.java:1698) >> at >> weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(WebAppServletContext.java:1675) >> at >> weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1595) >> at >> weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2734) >> at >> weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:892) >> at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:336) >> at >> weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204) >> at >> weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) >> at >> weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60) >> at >> weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200) >> at >> weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:117) >> at >> weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204)
