Deploying to Weblogic 10.3.1
Locked
12
12
 
|
How do you deploy a web application / service that uses
Metro to Weblogic 10.3.1? Do you guys have someone that tests this and has documented
it? Reason I am asking is that I have spent the better part of
today trying this and can’t deploy my test application that was running
fine on tomcat. I tried some of the suggestions out there but no luck: 1- Tried
deploying the war and Weblogic would not respond. 2 – Tried creating an ear and
including the war and also including this file: earName\META-INF\weblogic-application.xml <?xml
version='1.0' encoding='UTF-8'?> <weblogic-application
xmlns="http://xmlns.oracle.com/weblogic/weblogic-application"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-application
http://xmlns.oracle.com/weblogic/weblogic-application/1.0/weblogic-application.xsd"> <application-param> <param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
<package-name>javax.xml.soap.*</package-name> </prefer-application-packages> </weblogic-application> The deployment process in Weblogic then
complains that my service implementation class does not have @WebService or
@WebServiceProvider annotation, but it does: Here are my annotations: @WebService(endpointInterface="com.oracle.webservices.documentservice.DocumentServicePortType") @SchemaValidation(handler=com.oracle.webservices.documentservice.schema.validation.SchemaValidationErrorHandler.class) @HandlerChain(file="handlers.xml") @StreamingAttachment(parseEagerly=false,
memoryThreshold=2000000L) @MTOM 3 – Tried also including a warName\WEB-INF\weblogic.xml
file: <?xml version="1.0"
encoding="UTF-8" ?> <weblogic-web-app
xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app
http://xmlns.oracle.com/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"> <context-root>DocumentServiceSoap11</context-root>
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
</weblogic-web-app> I then get a different error during
deployment (I did include Sun’s Saaj-impl-1.3.jar file under WEB-INF\lib
of the war file) <Jul 9, 2009 2:37:16 PM EDT>
<Warning> <Deployer> <BEA-149078> <Stack trace for message 149004 weblogic.application.ModuleException:
at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.jav a:1376)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:452)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleSta teDriver.java:204)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineD river.java:37)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStat eDriver.java:60)
Truncated. see log file for complete stacktrace java.lang.IllegalArgumentException:
com.sun.xml.internal.messaging.saaj.soap.LocalStrings !=
com.sun.xml.messaging.saaj.soap.LocalStrings
at java.util.logging.Logger.getLogger(Logger.java:328)
at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.<clinit>(SAAJMeta FactoryImpl.java:35)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct orAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC onstructorAccessorImpl.java:27)
Truncated. see log file for complete stacktrace > |
|
|
Hello Carl,
> How do you deploy a web application / service that uses Metro to > Weblogic 10.3.1? > > > Do you guys have someone that tests this and has documented it? The Metro team only tests against GlassFish v2 and v3 - and against Tomcat. We do know that a number of Metro users deploy Metro on Weblogic (not sure what version). Hopefully one of them will speak up and help you. Also, look through previous mails - it has been discussed in the past. Regards, Harold --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
RE: Deploying to Weblogic 10.3.1
|
|
In reply to this post by Carl Roberts
Hi Harold, Thanks for your reply. I did look
for a solution in the history and older emails but couldn’t find
one. I have also just tried going back to removing weblogic.xml from
warName\WEB-INF\ and just using earName\META-INF\weblogic-application.xml and
by also copying the webservices-*.jar files from metro 2.0 to
earName\APP-INF\lib but I am back to the error I mentioned in #2 below: Message icon - Error An error occurred
during activation of changes, please see the log for details. Message icon - Error
weblogic.application.ModuleException: Message icon - Error class
com.oracle.webservices.documentservice.server.DocumentServiceImpl has neither
@WebSerivce nor @WebServiceProvider annotation. I don’t understand why it complains
about the missing annotation since my class has @WebService: @WebService(endpointInterface="com.oracle.webservices.documentservice.DocumentServicePortType") @SchemaValidation(handler=com.oracle.webservices.documentservice.schema.validation.SchemaValidationErrorHandler.class) @HandlerChain(file="handlers.xml") @StreamingAttachment(parseEagerly=false,
memoryThreshold=2000000L) @MTOM Hopefully some kind soul out there will be
able to help me with this…J Hello Carl, > How do you deploy a web
application / service that uses Metro to > Weblogic 10.3.1? > > > Do you guys have
someone that tests this and has documented it? The Metro team only tests
against GlassFish v2 and v3 - and against Tomcat. We do know that a number of
Metro users deploy Metro on Weblogic (not sure what version). Hopefully
one of them will speak up and help you. Also, look through previous
mails - it has been discussed in the past. Regards, Harold From: Carl Roberts
[mailto:[hidden email]] How do you deploy a web application / service that uses
Metro to Weblogic 10.3.1? Do you guys have someone that tests this and has documented
it? Reason I am asking is that I have spent the better part of
today trying this and can’t deploy my test application that was running
fine on tomcat. I tried some of the suggestions out there but no luck: 1- Tried
deploying the war and Weblogic would not respond. 2 – Tried creating an ear and including the war and
also including this file:
earName\META-INF\weblogic-application.xml <?xml
version='1.0' encoding='UTF-8'?>
<weblogic-application
xmlns="http://xmlns.oracle.com/weblogic/weblogic-application"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-application
http://xmlns.oracle.com/weblogic/weblogic-application/1.0/weblogic-application.xsd">
<application-param>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
<package-name>javax.xml.soap.*</package-name>
</prefer-application-packages> </weblogic-application> The deployment process in Weblogic
then complains that my service implementation class does not have @WebService
or @WebServiceProvider annotation, but it does: Here are my annotations: @WebService(endpointInterface="com.oracle.webservices.documentservice.DocumentServicePortType") @SchemaValidation(handler=com.oracle.webservices.documentservice.schema.validation.SchemaValidationErrorHandler.class) @HandlerChain(file="handlers.xml") @StreamingAttachment(parseEagerly=false,
memoryThreshold=2000000L) @MTOM 3 – Tried also including a
warName\WEB-INF\weblogic.xml file: <?xml version="1.0"
encoding="UTF-8" ?> <weblogic-web-app
xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app
http://xmlns.oracle.com/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd">
<context-root>DocumentServiceSoap11</context-root>
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor> </weblogic-web-app> I then get a different error during
deployment (I did include Sun’s Saaj-impl-1.3.jar file under WEB-INF\lib
of the war file) <Jul 9, 2009 2:37:16 PM EDT>
<Warning> <Deployer> <BEA-149078> <Stack trace for message 149004 weblogic.application.ModuleException:
at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.jav a:1376)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:452)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleSta teDriver.java:204)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineD river.java:37)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStat eDriver.java:60)
Truncated. see log file for complete stacktrace java.lang.IllegalArgumentException:
com.sun.xml.internal.messaging.saaj.soap.LocalStrings !=
com.sun.xml.messaging.saaj.soap.LocalStrings
at java.util.logging.Logger.getLogger(Logger.java:328)
at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.<clinit>(SAAJMeta FactoryImpl.java:35)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct orAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC onstructorAccessorImpl.java:27)
Truncated. see log file for complete stacktrace > |
|
|
I used somewhat different <p-a-p/s>--perhaps my list would help:
http://www.jroller.com/gmazza/entry/deploying_metro_and_cxf_based Glen
|
RE: Deploying to Weblogic 10.3.1
|
|
Hi Glen,
Thanks for your response. Much appreciated. I tried your package names per the link you gave me instead of mine. Here are the ones I am using now: <package-name>com.sun.xml.*</package-name> <package-name>javax.xml.bind.*</package-name> But I am back to a different error that I saw before: Message icon - Error An error occurred during activation of changes, please see the log for details. Message icon - Error weblogic.application.ModuleException: Message icon - Error com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings I noticed the saaj-impl namespace is also com.sun.xml.* so I am wondering if it has to do with this. I have also tried including the saaj-impl-1.3.jar file in the WEB-INF\lib directory of the war inside the ear and redeploying but I get the same error. Have you seen this error before? Do you have a sample ear file that you used for testing that I could try to deploy on my instance of Weblogic Server 10.3.1? Thanks, Joe -----Original Message----- From: Glen Mazza [mailto:[hidden email]] Sent: Thursday, July 09, 2009 7:03 PM To: [hidden email] Subject: RE: Deploying to Weblogic 10.3.1 I used somewhat different <p-a-p/s>--perhaps my list would help: http://www.jroller.com/gmazza/entry/deploying_metro_and_cxf_based Glen Carl Roberts wrote: > > <prefer-application-packages> > > <package-name>javax.jws.*</package-name> > > <package-name>javax.xml.soap.*</package-name> > > </prefer-application-packages> > > </weblogic-application> > > The deployment process in Weblogic then complains that my service > implementation class does not have @WebService or @WebServiceProvider > annotation, but it does: > -- View this message in context: http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24419290.html Sent from the Metro - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
|
Yes, I suspect there's something different between the SAAJ that BEAWLS is using and the SAAJ that Metro is expecting.
Yes, my blog entry at the link below has the final source code (if not the included JARs--but Maven should be able to retrieve those for you). Click on the link on the 2nd paragraph from the top. My entry is also a bit old, so things may have changed over the past year. Glen
|
RE: Deploying to Weblogic 10.3.1
|
|
In reply to this post by Carl Roberts
Thanks Glen,
I will try your setup. BTW, since Oracle WebLogic claims to follow the Glassfish implementation and I couldn't get any further with my previous approach, I figured why not remove the metro webservices-*.jar files from my WEB-INF\lib directory and just go with the Weblogic implementation of Glassfish. Theoretically this should work. Well, I changed the web.xml to run the Implementation class directly by commenting out the listener: <?xml version="1.0" encoding="UTF-8" ?> - <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/j2ee"> <display-name>DocumentServiceSoap11</display-name> - <!-- <listener> <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class> </listener> --> - <servlet> <servlet-name>DocumentServiceSoap11</servlet-name> - <!-- <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> --> <servlet-class>com.oracle.webservices.documentservice.server.DocumentServiceImpl</servlet-class> <load-on-startup>0</load-on-startup> </servlet> - <servlet-mapping> <servlet-name>DocumentServiceSoap11</servlet-name> <url-pattern>/DocumentService</url-pattern> </servlet-mapping> - <session-config> <session-timeout>60</session-timeout> </session-config> </web-app> And I am getting a little further I think, but now I am getting this error, indicating the Weblogic schema validator is not up to par with Metro's 2.0 one, because it is complaining about default attribute for xsd:element not being valid? Isn't default attribute for xsd:element a standard attribute? It seems like a schema that worked fine before under tomcat now has problems under Weblogic. Here is the error from weblogic: Message icon - Error An error occurred during activation of changes, please see the log for details. Message icon - Error [HTTP:101216]Servlet: "DocumentServiceSoap11" failed to preload on startup in Web application: "DocumentServiceImpl". javax.xml.ws.WebServiceException: org.xml.sax.SAXParseException: s4s-att-not-allowed: Attribute 'default' cannot appear in element 'element'. at com.sun.xml.ws.server.ServerSchemaValidationTube.<init>(ServerSchemaValidationTube.java:69) at com.sun.xml.ws.api.pipe.ServerTubeAssemblerContext.createValidationTube(ServerTubeAssemblerContext.java:221) at weblogic.wsee.jaxws.tubeline.standard.StandardTubelineDeploymentListener$13.createServer(StandardTubelineDeploymentListener.java:158) at weblogic.wsee.jaxws.WLSTubelineAssemblerFactory$TubelineAssemblerImpl.createServer(WLSTubelineAssemblerFactory.java:105) at com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:158) at weblogic.wsee.jaxws.WLSContainer$WLSEndpointFactory$WLSEndpointImpl.<init>(WLSContainer.java:413) at '' This is getting a little frustrating. I guess I am going to try going back to including the webservies-*.jar files and using saaj-impl-3.2.jar from Sun instead of 3.1 version. I noticed the 3.2 version contains a META-INF\services directory with some factory classes while the 3.1 version I was using does not. I am hoping this solves the problem. -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Friday, July 10, 2009 8:58 AM To: [hidden email] Cc: [hidden email] Subject: RE: Deploying to Weblogic 10.3.1 Hi Glen, Thanks for your response. Much appreciated. I tried your package names per the link you gave me instead of mine. Here are the ones I am using now: <package-name>com.sun.xml.*</package-name> <package-name>javax.xml.bind.*</package-name> But I am back to a different error that I saw before: Message icon - Error An error occurred during activation of changes, please see the log for details. Message icon - Error weblogic.application.ModuleException: Message icon - Error com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings I noticed the saaj-impl namespace is also com.sun.xml.* so I am wondering if it has to do with this. I have also tried including the saaj-impl-1.3.jar file in the WEB-INF\lib directory of the war inside the ear and redeploying but I get the same error. Have you seen this error before? Do you have a sample ear file that you used for testing that I could try to deploy on my instance of Weblogic Server 10.3.1? Thanks, Joe -----Original Message----- From: Glen Mazza [mailto:[hidden email]] Sent: Thursday, July 09, 2009 7:03 PM To: [hidden email] Subject: RE: Deploying to Weblogic 10.3.1 I used somewhat different <p-a-p/s>--perhaps my list would help: http://www.jroller.com/gmazza/entry/deploying_metro_and_cxf_based Glen Carl Roberts wrote: > > <prefer-application-packages> > > <package-name>javax.jws.*</package-name> > > <package-name>javax.xml.soap.*</package-name> > > </prefer-application-packages> > > </weblogic-application> > > The deployment process in Weblogic then complains that my service > implementation class does not have @WebService or @WebServiceProvider > annotation, but it does: > -- View this message in context: http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24419290.html Sent from the Metro - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
|
Looking at your error stack, it appears that you're relying on BEAWLS' own jax-ws implementation (weblogic.wsee.jaxws...) instead of Metro. I might advise against removing the Metro jars from the WEB-INF/lib for that reason, but as that is not working for you either, I'm not sure what else to suggest other than trying CXF (which comes with no guarantees on BEAWLS either[1]) or switching to Glassfish or Tomcat. I'm pretty confident that Metro 2.0 will work on BEAWLS but simply don't know the <prefer-application-packages/> library overrides necessary for that to happen.
Sorry, Glen [1] http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-WebLogic
|
RE: Deploying to Weblogic 10.3.1
|
|
OK,
I've gotten a little further by doing this: I replaced the Sun JVM used by Weblogic Server 10.3.1 from version 1.6 build 11 to 1.6 build 14 and this resolved the error: com.sun.xml.internal.messaging.saaj.soap.LocalStrings > != com.sun.xml.messaging.saaj.soap.LocalStrings However, I am now running into another error which I think stems from the fact that the following two schemas don't support the <display-name> or <description> elements under the <servlet> element of a web deployment descriptor (web.xml): http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd Here is what works in Metro and Tomcat (section of web.xml): <servlet> <servlet-name>DocumentServiceSoap11</servlet-name> <display-name>DocumentServiceSoap11</display-name> <description>DocumentService SOAP 1.1</description> <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> However, when I use Weblogic and try to deploy using the same entries in the web.xml I get this: Message icon - Error An error occurred during activation of changes, please see the log for details. Message icon - Error [HTTP:101064][WebAppModule(DocumentServiceImplSoap11:DocumentServiceImplSoap11)] Error parsing descriptor in Web appplication "C:\oracle\Middleware\home_LOAD16F\user_projects\domains\domain1\servers\AdminServer\tmp\_WL_user\DocumentServiceImplSoap11\cvh7s\com\oracle\webservices\documentservice\server\DocumentServiceImplSoap11.war" weblogic.application.ModuleException: VALIDATION PROBLEMS WERE FOUND problem: cvc-complex-type.2.4a: Expected elements 'servlet-class@http://java.sun.com/xml/ns/javaee jsp-file@http://java.sun.com/xml/ns/javaee' instead of 'display-name@http://java.sun.com/xml/ns/javaee' here in element servlet@http://java.sun.com/xml/ns/javaee:<null> problem: cvc-complex-type.2.4a: Expected elements 'servlet-class@http://java.sun.com/xml/ns/javaee jsp-file@http://java.sun.com/xml/ns/javaee' instead of 'description@http://java.sun.com/xml/ns/javaee' here in element servlet@http://java.sun.com/xml/ns/javaee:<null> at weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.java:1201) at weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:335) at weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedModuleDriver.java:176) at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93) at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:387) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:58) at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:42) at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:609) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:185) at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:53) at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:154) at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60) at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:197) at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:89) at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:217) at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:747) at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1216) at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:250) at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:159) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:157) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45) at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) Caused by: weblogic.descriptor.DescriptorException: VALIDATION PROBLEMS WERE FOUND problem: cvc-complex-type.2.4a: Expected elements 'servlet-class@http://java.sun.com/xml/ns/javaee jsp-file@http://java.sun.com/xml/ns/javaee' instead of 'display-name@http://java.sun.com/xml/ns/javaee' here in element servlet@http://java.sun.com/xml/ns/javaee:<null> problem: cvc-complex-type.2.4a: Expected elements 'servlet-class@http://java.sun.com/xml/ns/javaee jsp-file@http://java.sun.com/xml/ns/javaee' instead of 'description@http://java.sun.com/xml/ns/javaee' here in element servlet@http://java.sun.com/xml/ns/javaee:<null> at weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(MarshallerFactory.java:241) at weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(MarshallerFactory.java:228) at weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(MarshallerFactory.java:153) at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:323) at weblogic.application.descriptor.AbstractDescriptorLoader2.getDescriptorBeanFromReader(AbstractDescriptorLoader2.java:788) at weblogic.application.descriptor.AbstractDescriptorLoader2.createDescriptorBean(AbstractDescriptorLoader2.java:409) at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBeanWithoutPlan(AbstractDescriptorLoader2.java:759) at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBean(AbstractDescriptorLoader2.java:768) at weblogic.servlet.internal.WebAppDescriptor.getWebAppBean(WebAppDescriptor.java:141) at weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.java:1193) ... 26 more weblogic.application.ModuleException: VALIDATION PROBLEMS WERE FOUND problem: cvc-complex-type.2.4a: Expected elements 'servlet-class@http://java.sun.com/xml/ns/javaee jsp-file@http://java.sun.com/xml/ns/javaee' instead of 'display-name@http://java.sun.com/xml/ns/javaee' here in element servlet@http://java.sun.com/xml/ns/javaee:<null> problem: cvc-complex-type.2.4a: Expected elements 'servlet-class@http://java.sun.com/xml/ns/javaee jsp-file@http://java.sun.com/xml/ns/javaee' instead of 'description@http://java.sun.com/xml/ns/javaee' here in element servlet@http://java.sun.com/xml/ns/javaee:<null> Message icon - Error VALIDATION PROBLEMS WERE FOUND problem: cvc-complex-type.2.4a: Expected elements 'servlet-class@http://java.sun.com/xml/ns/javaee jsp-file@http://java.sun.com/xml/ns/javaee' instead of 'display-name@http://java.sun.com/xml/ns/javaee' here in element servlet@http://java.sun.com/xml/ns/javaee:<null> problem: cvc-complex-type.2.4a: Expected elements 'servlet-class@http://java.sun.com/xml/ns/javaee jsp-file@http://java.sun.com/xml/ns/javaee' instead of 'description@http://java.sun.com/xml/ns/javaee' here in element servlet@http://java.sun.com/xml/ns/javaee:<null> So it appears that Tomcat does no validation against the web.xml but J2EE containers do (are required) and cannot validate the web.xml with the <display-name> and <description> elements. If I take out these elements then validation succeeds in Weblogic but then Metro throws this exception: ####<Jul 10, 2009 4:24:09 PM EDT> <Error> <Console> <idocumaker> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <> <1247257449500> <BEA-240003> <Console encountered the following error weblogic.application.ModuleException: at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1376) at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:452) at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) 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:37) at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60) at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27) at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:629) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:206) at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:53) at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161) at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79) at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:569) at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:140) at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:106) at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:323) at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844) at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253) at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440) at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:181) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:12) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:67) at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) Caused by: java.lang.NullPointerException: at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:362) at com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl.java:104) at com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:262) at com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:335) at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:198) at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:504) at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:253) at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147) at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:108) at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:465) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:175) at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1799) at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3041) at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1374) > It seems to me this is a bug in Metro: If <display-name> and <description> aren't supported under the <servlet> element in the schemas for a web.xml, then why are we relying on them to be there and throwing a NullpointerException when they are not. At the very least they should be made optional. This way I can take them out in the web.xml when deploying to a J2EE container and not have to worry about Metro throwing this exception. It is possible I am missing some sort of crucial piece of information but I don't see that this elements are supported under the <servlet> element in the following two schemas: http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd or http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd Please advise, Carl -----Original Message----- From: Glen Mazza [mailto:[hidden email]] Sent: Friday, July 10, 2009 12:35 PM To: [hidden email] Subject: RE: Deploying to Weblogic 10.3.1 Looking at your error stack, it appears that you're relying on BEAWLS' own jax-ws implementation (weblogic.wsee.jaxws...) instead of Metro. I might advise against removing the Metro jars from the WEB-INF/lib for that reason, but as that is not working for you either, I'm not sure what else to suggest other than trying CXF (which comes with no guarantees on BEAWLS either[1]) or switching to Glassfish or Tomcat. I'm pretty confident that Metro 2.0 will work on BEAWLS but simply don't know the <prefer-application-packages/> library overrides necessary for that to happen. Sorry, Glen [1] http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-WebLogic Carl Roberts wrote: > > Thanks Glen, > > I will try your setup. > > BTW, since Oracle WebLogic claims to follow the Glassfish > implementation and I couldn't get any further with my previous > approach, I figured why not remove the metro webservices-*.jar files > from my WEB-INF\lib directory and just go with the Weblogic > implementation of Glassfish. Theoretically this should work. > > Well, > > I changed the web.xml to run the Implementation class directly by > commenting out the listener: > > <?xml version="1.0" encoding="UTF-8" ?> > - <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/j2ee"> > <display-name>DocumentServiceSoap11</display-name> > - <!-- > <listener> > > <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class> > </listener> > > > --> > - <servlet> > <servlet-name>DocumentServiceSoap11</servlet-name> > - <!-- > <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> > --> > > <servlet-class>com.oracle.webservices.documentservice.server.DocumentServiceImpl</servlet-class> > <load-on-startup>0</load-on-startup> > </servlet> > - <servlet-mapping> > <servlet-name>DocumentServiceSoap11</servlet-name> > <url-pattern>/DocumentService</url-pattern> > </servlet-mapping> > - <session-config> > <session-timeout>60</session-timeout> > </session-config> > </web-app> > > And I am getting a little further I think, but now I am getting this > error, indicating the Weblogic schema validator is not up to par with > Metro's 2.0 one, because it is complaining about default attribute for > xsd:element not being valid? Isn't default attribute for xsd:element > a standard attribute? It seems like a schema that worked fine before > under tomcat now has problems under Weblogic. > > Here is the error from weblogic: > > Message icon - Error An error occurred during activation of changes, > please see the log for details. > Message icon - Error [HTTP:101216]Servlet: "DocumentServiceSoap11" > failed to preload on startup in Web application: "DocumentServiceImpl". > javax.xml.ws.WebServiceException: org.xml.sax.SAXParseException: > s4s-att-not-allowed: Attribute 'default' cannot appear in element > 'element'. at > com.sun.xml.ws.server.ServerSchemaValidationTube.<init>(ServerSchemaVa > lidationTube.java:69) > at > com.sun.xml.ws.api.pipe.ServerTubeAssemblerContext.createValidationTub > e(ServerTubeAssemblerContext.java:221) > at > weblogic.wsee.jaxws.tubeline.standard.StandardTubelineDeploymentListen > er$13.createServer(StandardTubelineDeploymentListener.java:158) > at > weblogic.wsee.jaxws.WLSTubelineAssemblerFactory$TubelineAssemblerImpl. > createServer(WLSTubelineAssemblerFactory.java:105) > at > com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:158) > at > weblogic.wsee.jaxws.WLSContainer$WLSEndpointFactory$WLSEndpointImpl.<i > nit>(WLSContainer.java:413) > at '' > > This is getting a little frustrating. I guess I am going to try going > back to including the webservies-*.jar files and using > saaj-impl-3.2.jar from Sun instead of 3.1 version. I noticed the 3.2 > version contains a META-INF\services directory with some factory > classes while the 3.1 version I was using does not. I am hoping this solves the problem. > > > > -----Original Message----- > From: Carl Roberts [mailto:[hidden email]] > Sent: Friday, July 10, 2009 8:58 AM > To: [hidden email] > Cc: [hidden email] > Subject: RE: Deploying to Weblogic 10.3.1 > > Hi Glen, > > Thanks for your response. Much appreciated. I tried your package > names per the link you gave me instead of mine. Here are the ones I > am using > now: > > <package-name>com.sun.xml.*</package-name> > <package-name>javax.xml.bind.*</package-name> > > But I am back to a different error that I saw before: > > Message icon - Error An error occurred during activation of changes, > please see the log for details. > Message icon - Error weblogic.application.ModuleException: > Message icon - Error > com.sun.xml.internal.messaging.saaj.soap.LocalStrings > != com.sun.xml.messaging.saaj.soap.LocalStrings > > I noticed the saaj-impl namespace is also com.sun.xml.* so I am > wondering if it has to do with this. > > I have also tried including the saaj-impl-1.3.jar file in the > WEB-INF\lib directory of the war inside the ear and redeploying but I > get the same error. Have you seen this error before? > > Do you have a sample ear file that you used for testing that I could > try to deploy on my instance of Weblogic Server 10.3.1? > > Thanks, > > Joe > > -----Original Message----- > From: Glen Mazza [mailto:[hidden email]] > Sent: Thursday, July 09, 2009 7:03 PM > To: [hidden email] > Subject: RE: Deploying to Weblogic 10.3.1 > > > I used somewhat different <p-a-p/s>--perhaps my list would help: > http://www.jroller.com/gmazza/entry/deploying_metro_and_cxf_based > > Glen > > > Carl Roberts wrote: >> >> <prefer-application-packages> >> >> <package-name>javax.jws.*</package-name> >> >> <package-name>javax.xml.soap.*</package-name> >> >> </prefer-application-packages> >> >> </weblogic-application> >> >> The deployment process in Weblogic then complains that my service >> implementation class does not have @WebService or @WebServiceProvider >> annotation, but it does: >> > > -- > View this message in context: > http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24419290 > .html Sent from the Metro - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > -- View this message in context: http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24430825.html Sent from the Metro - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
|
No--I don't think Metro cares about that display-name/description stuff--the NPE you're getting with Metro you would probably be getting anyway if Weblogic could handle the display-name/description tags at the location you are placing them.
I'm guessing that the display-name/description stuff really *is* invalid with respect to the schema of the particular web.xml you're using, which is proving an unnecessary distraction to your problem. First make sure you indeed have a schema-valid web.xml (those two tags are mostly noise under <servlet> anyway--you don't need them) before proceeding. There's a slight chance the Xerces in use by Weblogic is old--that can sometimes cause wacky things to happen, you may want to override it with the latest Xerces, but I guess I would be grasping at straws here at this stage. Glen
|
RE: Deploying to Weblogic 10.3.1
|
|
You are right Glen, I debugged the code and the issue is related to this function (I added some System.out.println statements):
/*package*/ void freeze(WSDLPortImpl portType) { this.wsdlOperation = portType.getBinding().get(new QName(portType.getBinding().getPortType().getName().getNamespaceURI(),operationName)); // TODO: replace this with proper error handling if(wsdlOperation ==null) throw new Error("Undefined operation name "+operationName); //so far, the inputAction, outputAction and fault actions are set from the @Action and @FaultAction //set the values from WSDLModel, if such annotations are not present or defaulted if(inputAction.equals("")) { inputAction = wsdlOperation.getOperation().getInput().getAction(); } else if(!inputAction.equals(wsdlOperation.getOperation().getInput().getAction())) //TODO input action might be from @Action or WebMethod(action) LOGGER.warning("Input Action from WSDL definitions and @Action for operation .... did not match, and willc ause problems in dispatching the requests"); if (!mep.isOneWay()) { if (outputAction.equals("")) WSLDOperationImpl op = wsdlOperation.getOperation(); if (op == null){ System.out.println("*****op is NULL"); } WSDLOutputImpl output = op.getOutput(); if (output == null){ System.out.println("*****output is NULL"); } outputAction = output.getAction(); for (CheckedExceptionImpl ce : exceptions) { if (ce.getFaultAction().equals("")) { QName detailQName = ce.getDetailType().tagName; ce.setFaultAction(wsdlOperation.getOperation().getFault(detailQName).getAction()); } } } } From the output in the console right before the NPE is thrown, it looks like the code in metro is processing doCallIDSOneWay which has no output operation defined in the WSDL: <wsdl:operation name="doCallIDSOneWay"> <wsdl:input message="tns:DoCallIDSOneWayRequest" wsaw:Action="doCallIDSOneWay"/> </wsdl:operation> But the code above seems to be failing on the check !mep.isOneWay() and tries to get the output for it and throws the NPE, so it looks like running on WebLogic the behavior is different, probably because of the XML parsing. BTW, I tried to place the lates xalan jars in the WEB-INF\Lib directory and modifying the weblogic-applcation.xml file to use: <package-name>javax.xml.*</package-name> Instead of <package-name>javax.xml.bind.*</package-name> But then I get this error: com.ctc.wstx.stax.WstxInputFactory cannot be cast to javax.xml.stream.XMLInputFactory -----Original Message----- From: Glen Mazza [mailto:[hidden email]] Sent: Friday, July 10, 2009 5:10 PM To: [hidden email] Subject: RE: Deploying to Weblogic 10.3.1 No--I don't think Metro cares about that display-name/description stuff--the NPE you're getting with Metro you would probably be getting anyway if Weblogic could handle the display-name/description tags at the location you are placing them. I'm guessing that the display-name/description stuff really *is* invalid with respect to the schema of the particular web.xml you're using, which is proving an unnecessary distraction to your problem. First make sure you indeed have a schema-valid web.xml (those two tags are mostly noise under <servlet> anyway--you don't need them) before proceeding. There's a slight chance the Xerces in use by Weblogic is old--that can sometimes cause wacky things to happen, you may want to override it with the latest Xerces, but I guess I would be grasping at straws here at this stage. Glen Carl Roberts wrote: > > OK, > > I've gotten a little further by doing this: > > I replaced the Sun JVM used by Weblogic Server 10.3.1 from version 1.6 > build 11 to 1.6 build 14 and this resolved the error: > > com.sun.xml.internal.messaging.saaj.soap.LocalStrings >> != com.sun.xml.messaging.saaj.soap.LocalStrings > > However, I am now running into another error which I think stems from > the fact that the following two schemas don't support the > <display-name> or <description> elements under the <servlet> element > of a web deployment descriptor (web.xml): > > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd > > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd > > > Here is what works in Metro and Tomcat (section of web.xml): > > <servlet> > <servlet-name>DocumentServiceSoap11</servlet-name> > <display-name>DocumentServiceSoap11</display-name> > <description>DocumentService SOAP 1.1</description> > > <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> > <load-on-startup>1</load-on-startup> > </servlet> > > However, when I use Weblogic and try to deploy using the same entries > in the web.xml I get this: > > Message icon - Error An error occurred during activation of changes, > please see the log for details. > Message icon - Error > [HTTP:101064][WebAppModule(DocumentServiceImplSoap11:DocumentServiceIm > plSoap11)] Error parsing descriptor in Web appplication > "C:\oracle\Middleware\home_LOAD16F\user_projects\domains\domain1\servers\AdminServer\tmp\_WL_user\DocumentServiceImplSoap11\cvh7s\com\oracle\webservices\documentservice\server\DocumentServiceImplSoap11.war" > weblogic.application.ModuleException: VALIDATION PROBLEMS WERE FOUND > problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> at > weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav > a:1201) at > weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:335) > at > weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedMo > duleDriver.java:176) > at > weblogic.application.internal.flow.ModuleListenerInvoker.prepare(Modul > eListenerInvoker.java:93) > at > weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(Deplo > ymentCallbackFlow.java:387) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDr > iver.java:37) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(Depl > oymentCallbackFlow.java:58) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(Depl > oymentCallbackFlow.java:42) > at > weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.jav > a:609) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDr > iver.java:37) > at > weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.ja > va:185) > at > weblogic.application.internal.EarDeployment.prepare(EarDeployment.java > :53) > at > weblogic.application.internal.DeploymentStateChecker.prepare(Deploymen > tStateChecker.java:154) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppC > ontainerInvoker.java:60) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.cre > ateAndPrepareContainer(ActivateOperation.java:197) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doP > repare(ActivateOperation.java:89) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.pre > pare(AbstractOperation.java:217) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeployme > ntPrepare(DeploymentManager.java:747) > at > weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploym > entList(DeploymentManager.java:1216) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare( > DeploymentManager.java:250) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prep > are(DeploymentServiceDispatcher.java:159) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java > :157) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuning > WorkManagerImpl.java:516) at > weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at > weblogic.work.ExecuteThread.run(ExecuteThread.java:173) Caused by: > weblogic.descriptor.DescriptorException: VALIDATION PROBLEMS WERE > FOUND > problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> at > weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(Marsh > allerFactory.java:241) > at > weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(Marsh > allerFactory.java:228) > at > weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(Mars > hallerFactory.java:153) > at > weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescr > iptorManager.java:323) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.getDescripto > rBeanFromReader(AbstractDescriptorLoader2.java:788) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.createDescri > ptorBean(AbstractDescriptorLoader2.java:409) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescript > orBeanWithoutPlan(AbstractDescriptorLoader2.java:759) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescript > orBean(AbstractDescriptorLoader2.java:768) > at > weblogic.servlet.internal.WebAppDescriptor.getWebAppBean(WebAppDescrip > tor.java:141) > at > weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav > a:1193) ... 26 more weblogic.application.ModuleException: VALIDATION > PROBLEMS WERE FOUND problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> > Message icon - Error VALIDATION PROBLEMS WERE FOUND problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> > > > > So it appears that Tomcat does no validation against the web.xml but > J2EE containers do (are required) and cannot validate the web.xml with > the <display-name> and <description> elements. If I take out these > elements then validation succeeds in Weblogic but then Metro throws this exception: > > ####<Jul 10, 2009 4:24:09 PM EDT> <Error> <Console> <idocumaker> > <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: > 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <> > <1247257449500> <BEA-240003> <Console encountered the following error > weblogic.application.ModuleException: > at > weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1376) > at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:452) > at > weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) > 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:37) > at > weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60) > at > weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27) > at > weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:629) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) > at > weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:206) > at > weblogic.application.internal.EarDeployment.activate(EarDeployment.java:53) > at > weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:569) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:140) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:106) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:323) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844) > at > weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:181) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:12) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:67) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) > Caused by: java.lang.NullPointerException: > at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:362) > at > com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl.java:104) > at > com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:262) > at > com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:335) > at > com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:198) > at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:504) > at > com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:253) > at > com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147) > at > com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:108) > at > weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:465) > at > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) > at > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) > at > weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:175) > at > weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1799) > at > weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3041) > at > weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java > :1374) >> > > > It seems to me this is a bug in Metro: > > If <display-name> and <description> aren't supported under the > <servlet> element in the schemas for a web.xml, then why are we > relying on them to be there and throwing a NullpointerException when > they are not. At the very least they should be made optional. This > way I can take them out in the web.xml when deploying to a J2EE > container and not have to worry about Metro throwing this exception. > It is possible I am missing some sort of crucial piece of information > but I don't see that this elements are supported under the <servlet> element in the following two schemas: > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd > > or > > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd > > Please advise, > > Carl > > > > -----Original Message----- > From: Glen Mazza [mailto:[hidden email]] > Sent: Friday, July 10, 2009 12:35 PM > To: [hidden email] > Subject: RE: Deploying to Weblogic 10.3.1 > > > Looking at your error stack, it appears that you're relying on BEAWLS' > own jax-ws implementation (weblogic.wsee.jaxws...) instead of Metro. > I might advise against removing the Metro jars from the WEB-INF/lib > for that reason, but as that is not working for you either, I'm not > sure what else to suggest other than trying CXF (which comes with no > guarantees on BEAWLS > either[1]) or switching to Glassfish or Tomcat. I'm pretty confident > that Metro 2.0 will work on BEAWLS but simply don't know the > <prefer-application-packages/> library overrides necessary for that to > happen. > > Sorry, > Glen > > [1] > http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-We > bLogic > > > Carl Roberts wrote: >> >> Thanks Glen, >> >> I will try your setup. >> >> BTW, since Oracle WebLogic claims to follow the Glassfish >> implementation and I couldn't get any further with my previous >> approach, I figured why not remove the metro webservices-*.jar files >> from my WEB-INF\lib directory and just go with the Weblogic >> implementation of Glassfish. Theoretically this should work. >> >> Well, >> >> I changed the web.xml to run the Implementation class directly by >> commenting out the listener: >> >> <?xml version="1.0" encoding="UTF-8" ?> >> - <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/j2ee"> >> <display-name>DocumentServiceSoap11</display-name> >> - <!-- >> <listener> >> >> <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class> >> </listener> >> >> >> --> >> - <servlet> >> <servlet-name>DocumentServiceSoap11</servlet-name> >> - <!-- >> <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> >> --> >> >> <servlet-class>com.oracle.webservices.documentservice.server.DocumentServiceImpl</servlet-class> >> <load-on-startup>0</load-on-startup> >> </servlet> >> - <servlet-mapping> >> <servlet-name>DocumentServiceSoap11</servlet-name> >> <url-pattern>/DocumentService</url-pattern> >> </servlet-mapping> >> - <session-config> >> <session-timeout>60</session-timeout> >> </session-config> >> </web-app> >> >> And I am getting a little further I think, but now I am getting this >> error, indicating the Weblogic schema validator is not up to par with >> Metro's 2.0 one, because it is complaining about default attribute >> for xsd:element not being valid? Isn't default attribute for >> xsd:element a standard attribute? It seems like a schema that worked >> fine before under tomcat now has problems under Weblogic. >> >> Here is the error from weblogic: >> >> Message icon - Error An error occurred during activation of changes, >> please see the log for details. >> Message icon - Error [HTTP:101216]Servlet: "DocumentServiceSoap11" >> failed to preload on startup in Web application: "DocumentServiceImpl". >> javax.xml.ws.WebServiceException: org.xml.sax.SAXParseException: >> s4s-att-not-allowed: Attribute 'default' cannot appear in element >> 'element'. at >> com.sun.xml.ws.server.ServerSchemaValidationTube.<init>(ServerSchemaV >> a >> lidationTube.java:69) >> at >> com.sun.xml.ws.api.pipe.ServerTubeAssemblerContext.createValidationTu >> b >> e(ServerTubeAssemblerContext.java:221) >> at >> weblogic.wsee.jaxws.tubeline.standard.StandardTubelineDeploymentListe >> n >> er$13.createServer(StandardTubelineDeploymentListener.java:158) >> at >> weblogic.wsee.jaxws.WLSTubelineAssemblerFactory$TubelineAssemblerImpl. >> createServer(WLSTubelineAssemblerFactory.java:105) >> at >> com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:158) >> at >> weblogic.wsee.jaxws.WLSContainer$WLSEndpointFactory$WLSEndpointImpl. >> nit>(WLSContainer.java:413) >> at '' >> >> This is getting a little frustrating. I guess I am going to try >> going back to including the webservies-*.jar files and using >> saaj-impl-3.2.jar from Sun instead of 3.1 version. I noticed the 3.2 >> version contains a META-INF\services directory with some factory >> classes while the 3.1 version I was using does not. I am hoping this >> solves the problem. >> >> >> >> -----Original Message----- >> From: Carl Roberts [mailto:[hidden email]] >> Sent: Friday, July 10, 2009 8:58 AM >> To: [hidden email] >> Cc: [hidden email] >> Subject: RE: Deploying to Weblogic 10.3.1 >> >> Hi Glen, >> >> Thanks for your response. Much appreciated. I tried your package >> names per the link you gave me instead of mine. Here are the ones I >> am using >> now: >> >> <package-name>com.sun.xml.*</package-name> >> <package-name>javax.xml.bind.*</package-name> >> >> But I am back to a different error that I saw before: >> >> Message icon - Error An error occurred during activation of changes, >> please see the log for details. >> Message icon - Error weblogic.application.ModuleException: >> Message icon - Error >> com.sun.xml.internal.messaging.saaj.soap.LocalStrings >> != com.sun.xml.messaging.saaj.soap.LocalStrings >> >> I noticed the saaj-impl namespace is also com.sun.xml.* so I am >> wondering if it has to do with this. >> >> I have also tried including the saaj-impl-1.3.jar file in the >> WEB-INF\lib directory of the war inside the ear and redeploying but I >> get the same error. Have you seen this error before? >> >> Do you have a sample ear file that you used for testing that I could >> try to deploy on my instance of Weblogic Server 10.3.1? >> >> Thanks, >> >> Joe >> >> -----Original Message----- >> From: Glen Mazza [mailto:[hidden email]] >> Sent: Thursday, July 09, 2009 7:03 PM >> To: [hidden email] >> Subject: RE: Deploying to Weblogic 10.3.1 >> >> >> I used somewhat different <p-a-p/s>--perhaps my list would help: >> http://www.jroller.com/gmazza/entry/deploying_metro_and_cxf_based >> >> Glen >> >> >> Carl Roberts wrote: >>> >>> <prefer-application-packages> >>> >>> <package-name>javax.jws.*</package-name> >>> >>> <package-name>javax.xml.soap.*</package-name> >>> >>> </prefer-application-packages> >>> >>> </weblogic-application> >>> >>> The deployment process in Weblogic then complains that my service >>> implementation class does not have @WebService or >>> @WebServiceProvider annotation, but it does: >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p2441929 >> 0 .html Sent from the Metro - Users mailing list archive at >> Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> > > -- > View this message in context: > http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24430825 > .html Sent from the Metro - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > -- View this message in context: http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24434406.html Sent from the Metro - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
RE: Deploying to Weblogic 10.3.1
|
|
Sorry,
Forgot to mention the actual class that contains the code: com.sun.xml.ws.model.JavaMethodImpl -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 10:47 AM To: '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 You are right Glen, I debugged the code and the issue is related to this function (I added some System.out.println statements): /*package*/ void freeze(WSDLPortImpl portType) { this.wsdlOperation = portType.getBinding().get(new QName(portType.getBinding().getPortType().getName().getNamespaceURI(),operationName)); // TODO: replace this with proper error handling if(wsdlOperation ==null) throw new Error("Undefined operation name "+operationName); //so far, the inputAction, outputAction and fault actions are set from the @Action and @FaultAction //set the values from WSDLModel, if such annotations are not present or defaulted if(inputAction.equals("")) { inputAction = wsdlOperation.getOperation().getInput().getAction(); } else if(!inputAction.equals(wsdlOperation.getOperation().getInput().getAction())) //TODO input action might be from @Action or WebMethod(action) LOGGER.warning("Input Action from WSDL definitions and @Action for operation .... did not match, and willc ause problems in dispatching the requests"); if (!mep.isOneWay()) { if (outputAction.equals("")) WSLDOperationImpl op = wsdlOperation.getOperation(); if (op == null){ System.out.println("*****op is NULL"); } WSDLOutputImpl output = op.getOutput(); if (output == null){ System.out.println("*****output is NULL"); } outputAction = output.getAction(); for (CheckedExceptionImpl ce : exceptions) { if (ce.getFaultAction().equals("")) { QName detailQName = ce.getDetailType().tagName; ce.setFaultAction(wsdlOperation.getOperation().getFault(detailQName).getAction()); } } } } From the output in the console right before the NPE is thrown, it looks like the code in metro is processing doCallIDSOneWay which has no output operation defined in the WSDL: <wsdl:operation name="doCallIDSOneWay"> <wsdl:input message="tns:DoCallIDSOneWayRequest" wsaw:Action="doCallIDSOneWay"/> </wsdl:operation> But the code above seems to be failing on the check !mep.isOneWay() and tries to get the output for it and throws the NPE, so it looks like running on WebLogic the behavior is different, probably because of the XML parsing. BTW, I tried to place the lates xalan jars in the WEB-INF\Lib directory and modifying the weblogic-applcation.xml file to use: <package-name>javax.xml.*</package-name> Instead of <package-name>javax.xml.bind.*</package-name> But then I get this error: com.ctc.wstx.stax.WstxInputFactory cannot be cast to javax.xml.stream.XMLInputFactory -----Original Message----- From: Glen Mazza [mailto:[hidden email]] Sent: Friday, July 10, 2009 5:10 PM To: [hidden email] Subject: RE: Deploying to Weblogic 10.3.1 No--I don't think Metro cares about that display-name/description stuff--the NPE you're getting with Metro you would probably be getting anyway if Weblogic could handle the display-name/description tags at the location you are placing them. I'm guessing that the display-name/description stuff really *is* invalid with respect to the schema of the particular web.xml you're using, which is proving an unnecessary distraction to your problem. First make sure you indeed have a schema-valid web.xml (those two tags are mostly noise under <servlet> anyway--you don't need them) before proceeding. There's a slight chance the Xerces in use by Weblogic is old--that can sometimes cause wacky things to happen, you may want to override it with the latest Xerces, but I guess I would be grasping at straws here at this stage. Glen Carl Roberts wrote: > > OK, > > I've gotten a little further by doing this: > > I replaced the Sun JVM used by Weblogic Server 10.3.1 from version 1.6 > build 11 to 1.6 build 14 and this resolved the error: > > com.sun.xml.internal.messaging.saaj.soap.LocalStrings >> != com.sun.xml.messaging.saaj.soap.LocalStrings > > However, I am now running into another error which I think stems from > the fact that the following two schemas don't support the > <display-name> or <description> elements under the <servlet> element > of a web deployment descriptor (web.xml): > > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd > > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd > > > Here is what works in Metro and Tomcat (section of web.xml): > > <servlet> > <servlet-name>DocumentServiceSoap11</servlet-name> > <display-name>DocumentServiceSoap11</display-name> > <description>DocumentService SOAP 1.1</description> > > <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> > <load-on-startup>1</load-on-startup> > </servlet> > > However, when I use Weblogic and try to deploy using the same entries > in the web.xml I get this: > > Message icon - Error An error occurred during activation of changes, > please see the log for details. > Message icon - Error > [HTTP:101064][WebAppModule(DocumentServiceImplSoap11:DocumentServiceIm > plSoap11)] Error parsing descriptor in Web appplication > "C:\oracle\Middleware\home_LOAD16F\user_projects\domains\domain1\servers\AdminServer\tmp\_WL_user\DocumentServiceImplSoap11\cvh7s\com\oracle\webservices\documentservice\server\DocumentServiceImplSoap11.war" > weblogic.application.ModuleException: VALIDATION PROBLEMS WERE FOUND > problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> at > weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav > a:1201) at > weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:335) > at > weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedMo > duleDriver.java:176) > at > weblogic.application.internal.flow.ModuleListenerInvoker.prepare(Modul > eListenerInvoker.java:93) > at > weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(Deplo > ymentCallbackFlow.java:387) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDr > iver.java:37) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(Depl > oymentCallbackFlow.java:58) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(Depl > oymentCallbackFlow.java:42) > at > weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.jav > a:609) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDr > iver.java:37) > at > weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.ja > va:185) > at > weblogic.application.internal.EarDeployment.prepare(EarDeployment.java > :53) > at > weblogic.application.internal.DeploymentStateChecker.prepare(Deploymen > tStateChecker.java:154) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppC > ontainerInvoker.java:60) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.cre > ateAndPrepareContainer(ActivateOperation.java:197) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doP > repare(ActivateOperation.java:89) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.pre > pare(AbstractOperation.java:217) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeployme > ntPrepare(DeploymentManager.java:747) > at > weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploym > entList(DeploymentManager.java:1216) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare( > DeploymentManager.java:250) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prep > are(DeploymentServiceDispatcher.java:159) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java > :157) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuning > WorkManagerImpl.java:516) at > weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at > weblogic.work.ExecuteThread.run(ExecuteThread.java:173) Caused by: > weblogic.descriptor.DescriptorException: VALIDATION PROBLEMS WERE > FOUND > problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> at > weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(Marsh > allerFactory.java:241) > at > weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(Marsh > allerFactory.java:228) > at > weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(Mars > hallerFactory.java:153) > at > weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescr > iptorManager.java:323) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.getDescripto > rBeanFromReader(AbstractDescriptorLoader2.java:788) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.createDescri > ptorBean(AbstractDescriptorLoader2.java:409) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescript > orBeanWithoutPlan(AbstractDescriptorLoader2.java:759) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescript > orBean(AbstractDescriptorLoader2.java:768) > at > weblogic.servlet.internal.WebAppDescriptor.getWebAppBean(WebAppDescrip > tor.java:141) > at > weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav > a:1193) ... 26 more weblogic.application.ModuleException: VALIDATION > PROBLEMS WERE FOUND problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> > Message icon - Error VALIDATION PROBLEMS WERE FOUND problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> > > > > So it appears that Tomcat does no validation against the web.xml but > J2EE containers do (are required) and cannot validate the web.xml with > the <display-name> and <description> elements. If I take out these > elements then validation succeeds in Weblogic but then Metro throws this exception: > > ####<Jul 10, 2009 4:24:09 PM EDT> <Error> <Console> <idocumaker> > <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: > 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <> > <1247257449500> <BEA-240003> <Console encountered the following error > weblogic.application.ModuleException: > at > weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1376) > at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:452) > at > weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) > 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:37) > at > weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60) > at > weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27) > at > weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:629) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) > at > weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:206) > at > weblogic.application.internal.EarDeployment.activate(EarDeployment.java:53) > at > weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:569) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:140) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:106) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:323) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844) > at > weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:181) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:12) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:67) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) > Caused by: java.lang.NullPointerException: > at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:362) > at > com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl.java:104) > at > com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:262) > at > com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:335) > at > com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:198) > at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:504) > at > com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:253) > at > com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147) > at > com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:108) > at > weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:465) > at > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) > at > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) > at > weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:175) > at > weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1799) > at > weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3041) > at > weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java > :1374) >> > > > It seems to me this is a bug in Metro: > > If <display-name> and <description> aren't supported under the > <servlet> element in the schemas for a web.xml, then why are we > relying on them to be there and throwing a NullpointerException when > they are not. At the very least they should be made optional. This > way I can take them out in the web.xml when deploying to a J2EE > container and not have to worry about Metro throwing this exception. > It is possible I am missing some sort of crucial piece of information > but I don't see that this elements are supported under the <servlet> element in the following two schemas: > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd > > or > > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd > > Please advise, > > Carl > > > > -----Original Message----- > From: Glen Mazza [mailto:[hidden email]] > Sent: Friday, July 10, 2009 12:35 PM > To: [hidden email] > Subject: RE: Deploying to Weblogic 10.3.1 > > > Looking at your error stack, it appears that you're relying on BEAWLS' > own jax-ws implementation (weblogic.wsee.jaxws...) instead of Metro. > I might advise against removing the Metro jars from the WEB-INF/lib > for that reason, but as that is not working for you either, I'm not > sure what else to suggest other than trying CXF (which comes with no > guarantees on BEAWLS > either[1]) or switching to Glassfish or Tomcat. I'm pretty confident > that Metro 2.0 will work on BEAWLS but simply don't know the > <prefer-application-packages/> library overrides necessary for that to > happen. > > Sorry, > Glen > > [1] > http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-We > bLogic > > > Carl Roberts wrote: >> >> Thanks Glen, >> >> I will try your setup. >> >> BTW, since Oracle WebLogic claims to follow the Glassfish >> implementation and I couldn't get any further with my previous >> approach, I figured why not remove the metro webservices-*.jar files >> from my WEB-INF\lib directory and just go with the Weblogic >> implementation of Glassfish. Theoretically this should work. >> >> Well, >> >> I changed the web.xml to run the Implementation class directly by >> commenting out the listener: >> >> <?xml version="1.0" encoding="UTF-8" ?> >> - <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/j2ee"> >> <display-name>DocumentServiceSoap11</display-name> >> - <!-- >> <listener> >> >> <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class> >> </listener> >> >> >> --> >> - <servlet> >> <servlet-name>DocumentServiceSoap11</servlet-name> >> - <!-- >> <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> >> --> >> >> <servlet-class>com.oracle.webservices.documentservice.server.DocumentServiceImpl</servlet-class> >> <load-on-startup>0</load-on-startup> >> </servlet> >> - <servlet-mapping> >> <servlet-name>DocumentServiceSoap11</servlet-name> >> <url-pattern>/DocumentService</url-pattern> >> </servlet-mapping> >> - <session-config> >> <session-timeout>60</session-timeout> >> </session-config> >> </web-app> >> >> And I am getting a little further I think, but now I am getting this >> error, indicating the Weblogic schema validator is not up to par with >> Metro's 2.0 one, because it is complaining about default attribute >> for xsd:element not being valid? Isn't default attribute for >> xsd:element a standard attribute? It seems like a schema that worked >> fine before under tomcat now has problems under Weblogic. >> >> Here is the error from weblogic: >> >> Message icon - Error An error occurred during activation of changes, >> please see the log for details. >> Message icon - Error [HTTP:101216]Servlet: "DocumentServiceSoap11" >> failed to preload on startup in Web application: "DocumentServiceImpl". >> javax.xml.ws.WebServiceException: org.xml.sax.SAXParseException: >> s4s-att-not-allowed: Attribute 'default' cannot appear in element >> 'element'. at >> com.sun.xml.ws.server.ServerSchemaValidationTube.<init>(ServerSchemaV >> a >> lidationTube.java:69) >> at >> com.sun.xml.ws.api.pipe.ServerTubeAssemblerContext.createValidationTu >> b >> e(ServerTubeAssemblerContext.java:221) >> at >> weblogic.wsee.jaxws.tubeline.standard.StandardTubelineDeploymentListe >> n >> er$13.createServer(StandardTubelineDeploymentListener.java:158) >> at >> weblogic.wsee.jaxws.WLSTubelineAssemblerFactory$TubelineAssemblerImpl. >> createServer(WLSTubelineAssemblerFactory.java:105) >> at >> com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:158) >> at >> weblogic.wsee.jaxws.WLSContainer$WLSEndpointFactory$WLSEndpointImpl. >> nit>(WLSContainer.java:413) >> at '' >> >> This is getting a little frustrating. I guess I am going to try >> going back to including the webservies-*.jar files and using >> saaj-impl-3.2.jar from Sun instead of 3.1 version. I noticed the 3.2 >> version contains a META-INF\services directory with some factory >> classes while the 3.1 version I was using does not. I am hoping this >> solves the problem. >> >> >> >> -----Original Message----- >> From: Carl Roberts [mailto:[hidden email]] >> Sent: Friday, July 10, 2009 8:58 AM >> To: [hidden email] >> Cc: [hidden email] >> Subject: RE: Deploying to Weblogic 10.3.1 >> >> Hi Glen, >> >> Thanks for your response. Much appreciated. I tried your package >> names per the link you gave me instead of mine. Here are the ones I >> am using >> now: >> >> <package-name>com.sun.xml.*</package-name> >> <package-name>javax.xml.bind.*</package-name> >> >> But I am back to a different error that I saw before: >> >> Message icon - Error An error occurred during activation of changes, >> please see the log for details. >> Message icon - Error weblogic.application.ModuleException: >> Message icon - Error >> com.sun.xml.internal.messaging.saaj.soap.LocalStrings >> != com.sun.xml.messaging.saaj.soap.LocalStrings >> >> I noticed the saaj-impl namespace is also com.sun.xml.* so I am >> wondering if it has to do with this. >> >> I have also tried including the saaj-impl-1.3.jar file in the >> WEB-INF\lib directory of the war inside the ear and redeploying but I >> get the same error. Have you seen this error before? >> >> Do you have a sample ear file that you used for testing that I could >> try to deploy on my instance of Weblogic Server 10.3.1? >> >> Thanks, >> >> Joe >> >> -----Original Message----- >> From: Glen Mazza [mailto:[hidden email]] >> Sent: Thursday, July 09, 2009 7:03 PM >> To: [hidden email] >> Subject: RE: Deploying to Weblogic 10.3.1 >> >> >> I used somewhat different <p-a-p/s>--perhaps my list would help: >> http://www.jroller.com/gmazza/entry/deploying_metro_and_cxf_based >> >> Glen >> >> >> Carl Roberts wrote: >>> >>> <prefer-application-packages> >>> >>> <package-name>javax.jws.*</package-name> >>> >>> <package-name>javax.xml.soap.*</package-name> >>> >>> </prefer-application-packages> >>> >>> </weblogic-application> >>> >>> The deployment process in Weblogic then complains that my service >>> implementation class does not have @WebService or >>> @WebServiceProvider annotation, but it does: >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p2441929 >> 0 .html Sent from the Metro - Users mailing list archive at >> Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> > > -- > View this message in context: > http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24430825 > .html Sent from the Metro - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > -- View this message in context: http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24434406.html Sent from the Metro - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
RE: Deploying to Weblogic 10.3.1
|
|
Here is the output from the console:
<Jul 13, 2009 10:41:58 AM EDT> <Warning> <netuix> <BEA-423420> <Redirect is exec uted in begin or refresh action. Redirect url is /console/console.portal?_nfpb=t rue&_pageLabel=AppDeploymentsControlPage.> *****Freeze <doCallIDS> *****Freeze <doCallIDSOneWay> *****output is NULL Jul 13, 2009 10:43:10 AM com.sun.xml.ws.transport.http.servlet.WSServletContextL istener contextInitialized SEVERE: WSSERVLET11: failed to parse runtime descriptor: java.lang.NullPointerEx ception java.lang.NullPointerException at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:375) at com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 10:48 AM To: '[hidden email]'; '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 Sorry, Forgot to mention the actual class that contains the code: com.sun.xml.ws.model.JavaMethodImpl -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 10:47 AM To: '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 You are right Glen, I debugged the code and the issue is related to this function (I added some System.out.println statements): /*package*/ void freeze(WSDLPortImpl portType) { this.wsdlOperation = portType.getBinding().get(new QName(portType.getBinding().getPortType().getName().getNamespaceURI(),operationName)); // TODO: replace this with proper error handling if(wsdlOperation ==null) throw new Error("Undefined operation name "+operationName); //so far, the inputAction, outputAction and fault actions are set from the @Action and @FaultAction //set the values from WSDLModel, if such annotations are not present or defaulted if(inputAction.equals("")) { inputAction = wsdlOperation.getOperation().getInput().getAction(); } else if(!inputAction.equals(wsdlOperation.getOperation().getInput().getAction())) //TODO input action might be from @Action or WebMethod(action) LOGGER.warning("Input Action from WSDL definitions and @Action for operation .... did not match, and willc ause problems in dispatching the requests"); if (!mep.isOneWay()) { if (outputAction.equals("")) WSLDOperationImpl op = wsdlOperation.getOperation(); if (op == null){ System.out.println("*****op is NULL"); } WSDLOutputImpl output = op.getOutput(); if (output == null){ System.out.println("*****output is NULL"); } outputAction = output.getAction(); for (CheckedExceptionImpl ce : exceptions) { if (ce.getFaultAction().equals("")) { QName detailQName = ce.getDetailType().tagName; ce.setFaultAction(wsdlOperation.getOperation().getFault(detailQName).getAction()); } } } } From the output in the console right before the NPE is thrown, it looks like the code in metro is processing doCallIDSOneWay which has no output operation defined in the WSDL: <wsdl:operation name="doCallIDSOneWay"> <wsdl:input message="tns:DoCallIDSOneWayRequest" wsaw:Action="doCallIDSOneWay"/> </wsdl:operation> But the code above seems to be failing on the check !mep.isOneWay() and tries to get the output for it and throws the NPE, so it looks like running on WebLogic the behavior is different, probably because of the XML parsing. BTW, I tried to place the lates xalan jars in the WEB-INF\Lib directory and modifying the weblogic-applcation.xml file to use: <package-name>javax.xml.*</package-name> Instead of <package-name>javax.xml.bind.*</package-name> But then I get this error: com.ctc.wstx.stax.WstxInputFactory cannot be cast to javax.xml.stream.XMLInputFactory -----Original Message----- From: Glen Mazza [mailto:[hidden email]] Sent: Friday, July 10, 2009 5:10 PM To: [hidden email] Subject: RE: Deploying to Weblogic 10.3.1 No--I don't think Metro cares about that display-name/description stuff--the NPE you're getting with Metro you would probably be getting anyway if Weblogic could handle the display-name/description tags at the location you are placing them. I'm guessing that the display-name/description stuff really *is* invalid with respect to the schema of the particular web.xml you're using, which is proving an unnecessary distraction to your problem. First make sure you indeed have a schema-valid web.xml (those two tags are mostly noise under <servlet> anyway--you don't need them) before proceeding. There's a slight chance the Xerces in use by Weblogic is old--that can sometimes cause wacky things to happen, you may want to override it with the latest Xerces, but I guess I would be grasping at straws here at this stage. Glen Carl Roberts wrote: > > OK, > > I've gotten a little further by doing this: > > I replaced the Sun JVM used by Weblogic Server 10.3.1 from version 1.6 > build 11 to 1.6 build 14 and this resolved the error: > > com.sun.xml.internal.messaging.saaj.soap.LocalStrings >> != com.sun.xml.messaging.saaj.soap.LocalStrings > > However, I am now running into another error which I think stems from > the fact that the following two schemas don't support the > <display-name> or <description> elements under the <servlet> element > of a web deployment descriptor (web.xml): > > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd > > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd > > > Here is what works in Metro and Tomcat (section of web.xml): > > <servlet> > <servlet-name>DocumentServiceSoap11</servlet-name> > <display-name>DocumentServiceSoap11</display-name> > <description>DocumentService SOAP 1.1</description> > > <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> > <load-on-startup>1</load-on-startup> > </servlet> > > However, when I use Weblogic and try to deploy using the same entries > in the web.xml I get this: > > Message icon - Error An error occurred during activation of changes, > please see the log for details. > Message icon - Error > [HTTP:101064][WebAppModule(DocumentServiceImplSoap11:DocumentServiceIm > plSoap11)] Error parsing descriptor in Web appplication > "C:\oracle\Middleware\home_LOAD16F\user_projects\domains\domain1\servers\AdminServer\tmp\_WL_user\DocumentServiceImplSoap11\cvh7s\com\oracle\webservices\documentservice\server\DocumentServiceImplSoap11.war" > weblogic.application.ModuleException: VALIDATION PROBLEMS WERE FOUND > problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> at > weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav > a:1201) at > weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:335) > at > weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedMo > duleDriver.java:176) > at > weblogic.application.internal.flow.ModuleListenerInvoker.prepare(Modul > eListenerInvoker.java:93) > at > weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(Deplo > ymentCallbackFlow.java:387) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDr > iver.java:37) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(Depl > oymentCallbackFlow.java:58) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(Depl > oymentCallbackFlow.java:42) > at > weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.jav > a:609) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDr > iver.java:37) > at > weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.ja > va:185) > at > weblogic.application.internal.EarDeployment.prepare(EarDeployment.java > :53) > at > weblogic.application.internal.DeploymentStateChecker.prepare(Deploymen > tStateChecker.java:154) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppC > ontainerInvoker.java:60) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.cre > ateAndPrepareContainer(ActivateOperation.java:197) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doP > repare(ActivateOperation.java:89) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.pre > pare(AbstractOperation.java:217) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeployme > ntPrepare(DeploymentManager.java:747) > at > weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploym > entList(DeploymentManager.java:1216) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare( > DeploymentManager.java:250) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prep > are(DeploymentServiceDispatcher.java:159) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java > :157) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuning > WorkManagerImpl.java:516) at > weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at > weblogic.work.ExecuteThread.run(ExecuteThread.java:173) Caused by: > weblogic.descriptor.DescriptorException: VALIDATION PROBLEMS WERE > FOUND > problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> at > weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(Marsh > allerFactory.java:241) > at > weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(Marsh > allerFactory.java:228) > at > weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(Mars > hallerFactory.java:153) > at > weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescr > iptorManager.java:323) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.getDescripto > rBeanFromReader(AbstractDescriptorLoader2.java:788) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.createDescri > ptorBean(AbstractDescriptorLoader2.java:409) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescript > orBeanWithoutPlan(AbstractDescriptorLoader2.java:759) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescript > orBean(AbstractDescriptorLoader2.java:768) > at > weblogic.servlet.internal.WebAppDescriptor.getWebAppBean(WebAppDescrip > tor.java:141) > at > weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav > a:1193) ... 26 more weblogic.application.ModuleException: VALIDATION > PROBLEMS WERE FOUND problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> > Message icon - Error VALIDATION PROBLEMS WERE FOUND problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> > > > > So it appears that Tomcat does no validation against the web.xml but > J2EE containers do (are required) and cannot validate the web.xml with > the <display-name> and <description> elements. If I take out these > elements then validation succeeds in Weblogic but then Metro throws this exception: > > ####<Jul 10, 2009 4:24:09 PM EDT> <Error> <Console> <idocumaker> > <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: > 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <> > <1247257449500> <BEA-240003> <Console encountered the following error > weblogic.application.ModuleException: > at > weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1376) > at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:452) > at > weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) > 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:37) > at > weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60) > at > weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27) > at > weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:629) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) > at > weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:206) > at > weblogic.application.internal.EarDeployment.activate(EarDeployment.java:53) > at > weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:569) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:140) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:106) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:323) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844) > at > weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:181) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:12) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:67) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) > Caused by: java.lang.NullPointerException: > at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:362) > at > com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl.java:104) > at > com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:262) > at > com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:335) > at > com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:198) > at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:504) > at > com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:253) > at > com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147) > at > com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:108) > at > weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:465) > at > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) > at > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) > at > weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:175) > at > weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1799) > at > weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3041) > at > weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java > :1374) >> > > > It seems to me this is a bug in Metro: > > If <display-name> and <description> aren't supported under the > <servlet> element in the schemas for a web.xml, then why are we > relying on them to be there and throwing a NullpointerException when > they are not. At the very least they should be made optional. This > way I can take them out in the web.xml when deploying to a J2EE > container and not have to worry about Metro throwing this exception. > It is possible I am missing some sort of crucial piece of information > but I don't see that this elements are supported under the <servlet> element in the following two schemas: > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd > > or > > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd > > Please advise, > > Carl > > > > -----Original Message----- > From: Glen Mazza [mailto:[hidden email]] > Sent: Friday, July 10, 2009 12:35 PM > To: [hidden email] > Subject: RE: Deploying to Weblogic 10.3.1 > > > Looking at your error stack, it appears that you're relying on BEAWLS' > own jax-ws implementation (weblogic.wsee.jaxws...) instead of Metro. > I might advise against removing the Metro jars from the WEB-INF/lib > for that reason, but as that is not working for you either, I'm not > sure what else to suggest other than trying CXF (which comes with no > guarantees on BEAWLS > either[1]) or switching to Glassfish or Tomcat. I'm pretty confident > that Metro 2.0 will work on BEAWLS but simply don't know the > <prefer-application-packages/> library overrides necessary for that to > happen. > > Sorry, > Glen > > [1] > http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-We > bLogic > > > Carl Roberts wrote: >> >> Thanks Glen, >> >> I will try your setup. >> >> BTW, since Oracle WebLogic claims to follow the Glassfish >> implementation and I couldn't get any further with my previous >> approach, I figured why not remove the metro webservices-*.jar files >> from my WEB-INF\lib directory and just go with the Weblogic >> implementation of Glassfish. Theoretically this should work. >> >> Well, >> >> I changed the web.xml to run the Implementation class directly by >> commenting out the listener: >> >> <?xml version="1.0" encoding="UTF-8" ?> >> - <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/j2ee"> >> <display-name>DocumentServiceSoap11</display-name> >> - <!-- >> <listener> >> >> <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class> >> </listener> >> >> >> --> >> - <servlet> >> <servlet-name>DocumentServiceSoap11</servlet-name> >> - <!-- >> <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> >> --> >> >> <servlet-class>com.oracle.webservices.documentservice.server.DocumentServiceImpl</servlet-class> >> <load-on-startup>0</load-on-startup> >> </servlet> >> - <servlet-mapping> >> <servlet-name>DocumentServiceSoap11</servlet-name> >> <url-pattern>/DocumentService</url-pattern> >> </servlet-mapping> >> - <session-config> >> <session-timeout>60</session-timeout> >> </session-config> >> </web-app> >> >> And I am getting a little further I think, but now I am getting this >> error, indicating the Weblogic schema validator is not up to par with >> Metro's 2.0 one, because it is complaining about default attribute >> for xsd:element not being valid? Isn't default attribute for >> xsd:element a standard attribute? It seems like a schema that worked >> fine before under tomcat now has problems under Weblogic. >> >> Here is the error from weblogic: >> >> Message icon - Error An error occurred during activation of changes, >> please see the log for details. >> Message icon - Error [HTTP:101216]Servlet: "DocumentServiceSoap11" >> failed to preload on startup in Web application: "DocumentServiceImpl". >> javax.xml.ws.WebServiceException: org.xml.sax.SAXParseException: >> s4s-att-not-allowed: Attribute 'default' cannot appear in element >> 'element'. at >> com.sun.xml.ws.server.ServerSchemaValidationTube.<init>(ServerSchemaV >> a >> lidationTube.java:69) >> at >> com.sun.xml.ws.api.pipe.ServerTubeAssemblerContext.createValidationTu >> b >> e(ServerTubeAssemblerContext.java:221) >> at >> weblogic.wsee.jaxws.tubeline.standard.StandardTubelineDeploymentListe >> n >> er$13.createServer(StandardTubelineDeploymentListener.java:158) >> at >> weblogic.wsee.jaxws.WLSTubelineAssemblerFactory$TubelineAssemblerImpl. >> createServer(WLSTubelineAssemblerFactory.java:105) >> at >> com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:158) >> at >> weblogic.wsee.jaxws.WLSContainer$WLSEndpointFactory$WLSEndpointImpl. >> nit>(WLSContainer.java:413) >> at '' >> >> This is getting a little frustrating. I guess I am going to try >> going back to including the webservies-*.jar files and using >> saaj-impl-3.2.jar from Sun instead of 3.1 version. I noticed the 3.2 >> version contains a META-INF\services directory with some factory >> classes while the 3.1 version I was using does not. I am hoping this >> solves the problem. >> >> >> >> -----Original Message----- >> From: Carl Roberts [mailto:[hidden email]] >> Sent: Friday, July 10, 2009 8:58 AM >> To: [hidden email] >> Cc: [hidden email] >> Subject: RE: Deploying to Weblogic 10.3.1 >> >> Hi Glen, >> >> Thanks for your response. Much appreciated. I tried your package >> names per the link you gave me instead of mine. Here are the ones I >> am using >> now: >> >> <package-name>com.sun.xml.*</package-name> >> <package-name>javax.xml.bind.*</package-name> >> >> But I am back to a different error that I saw before: >> >> Message icon - Error An error occurred during activation of changes, >> please see the log for details. >> Message icon - Error weblogic.application.ModuleException: >> Message icon - Error >> com.sun.xml.internal.messaging.saaj.soap.LocalStrings >> != com.sun.xml.messaging.saaj.soap.LocalStrings >> >> I noticed the saaj-impl namespace is also com.sun.xml.* so I am >> wondering if it has to do with this. >> >> I have also tried including the saaj-impl-1.3.jar file in the >> WEB-INF\lib directory of the war inside the ear and redeploying but I >> get the same error. Have you seen this error before? >> >> Do you have a sample ear file that you used for testing that I could >> try to deploy on my instance of Weblogic Server 10.3.1? >> >> Thanks, >> >> Joe >> >> -----Original Message----- >> From: Glen Mazza [mailto:[hidden email]] >> Sent: Thursday, July 09, 2009 7:03 PM >> To: [hidden email] >> Subject: RE: Deploying to Weblogic 10.3.1 >> >> >> I used somewhat different <p-a-p/s>--perhaps my list would help: >> http://www.jroller.com/gmazza/entry/deploying_metro_and_cxf_based >> >> Glen >> >> >> Carl Roberts wrote: >>> >>> <prefer-application-packages> >>> >>> <package-name>javax.jws.*</package-name> >>> >>> <package-name>javax.xml.soap.*</package-name> >>> >>> </prefer-application-packages> >>> >>> </weblogic-application> >>> >>> The deployment process in Weblogic then complains that my service >>> implementation class does not have @WebService or >>> @WebServiceProvider annotation, but it does: >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p2441929 >> 0 .html Sent from the Metro - Users mailing list archive at >> Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> > > -- > View this message in context: > http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24430825 > .html Sent from the Metro - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > -- View this message in context: http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24434406.html Sent from the Metro - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
RE: Deploying to Weblogic 10.3.1
|
|
Just FYI,
I added a call to print the Xalan version from the same method: void freeze(WSDLPortImpl portType) { this.wsdlOperation = portType.getBinding().get(new QName(portType.getBinding().getPortType().getName().getNamespaceURI(),operationName)); // TODO: replace this with proper error handling if(wsdlOperation ==null) throw new Error("Undefined operation name "+operationName); PrintWriter writer = new PrintWriter(System.out); boolean environmentOK = (new EnvironmentCheck()).checkEnvironment (writer); System.out.println(environmentOK); System.out.println("*****Freeze <" + operationName + ">"); //so far, the inputAction, outputAction and fault actions are set from the @Action and @FaultAction //set the values from WSDLModel, if such annotations are not present or defaulted if(inputAction.equals("")) { inputAction = wsdlOperation.getOperation().getInput().getAction(); } else if(!inputAction.equals(wsdlOperation.getOperation().getInput().getAction())) //TODO input action might be from @Action or WebMethod(action) LOGGER.warning("Input Action from WSDL definitions and @Action for operation .... did not match, and willc ause problems in dispatching the requests"); if (!mep.isOneWay()) { if (outputAction.equals("")){ WSDLOperationImpl op = wsdlOperation.getOperation(); if (op == null){ System.out.println("*****op is NULL"); } WSDLOutputImpl output = op.getOutput(); if (output == null){ System.out.println("*****output is NULL"); } outputAction = output.getAction(); } for (CheckedExceptionImpl ce : exceptions) { if (ce.getFaultAction().equals("")) { QName detailQName = ce.getDetailType().tagName; ce.setFaultAction(wsdlOperation.getOperation().getFault(detailQName).getAction()); } } } } which prints this so it appears the code is using Xalan 2.7.1? version.JAXP=1.1 or higher java.ext.dirs=C:\jdk1.6.0_14\jre\lib\ext;C:\WINDOWS\Sun\Java\lib\ext version.xerces2=Xerces-J 2.9.0 version.xerces1=not-present version.xalan2_2=Xalan Java 2.7.1 version.xalan1=not-present version.ant=Apache Ant version 1.7.0 compiled on December 13 2006 java.version=1.6.0_14 version.DOM=2.0 version.crimson=not-present sun.boot.class.path=C:\jdk1.6.0_14\jre\lib\resources.jar;C:\jdk1.6.0_14\jre\lib\ rt.jar;C:\jdk1.6.0_14\jre\lib\sunrsasign.jar;C:\jdk1.6.0_14\jre\lib\jsse.jar;C:\ jdk1.6.0_14\jre\lib\jce.jar;C:\jdk1.6.0_14\jre\lib\charsets.jar;C:\jdk1.6.0_14\j re\classes version.SAX=2.0 version.xalan2x=Xalan Java 2.7.1 #----- END writeEnvironmentReport: Useful properties found: ----- # YAHOO! Your environment seems to be OK. true *****Freeze <doCallIDSOneWay> -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 10:49 AM To: '[hidden email]'; '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 Here is the output from the console: <Jul 13, 2009 10:41:58 AM EDT> <Warning> <netuix> <BEA-423420> <Redirect is exec uted in begin or refresh action. Redirect url is /console/console.portal?_nfpb=t rue&_pageLabel=AppDeploymentsControlPage.> *****Freeze <doCallIDS> *****Freeze <doCallIDSOneWay> *****output is NULL Jul 13, 2009 10:43:10 AM com.sun.xml.ws.transport.http.servlet.WSServletContextL istener contextInitialized SEVERE: WSSERVLET11: failed to parse runtime descriptor: java.lang.NullPointerEx ception java.lang.NullPointerException at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:375) at com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 10:48 AM To: '[hidden email]'; '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 Sorry, Forgot to mention the actual class that contains the code: com.sun.xml.ws.model.JavaMethodImpl -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 10:47 AM To: '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 You are right Glen, I debugged the code and the issue is related to this function (I added some System.out.println statements): /*package*/ void freeze(WSDLPortImpl portType) { this.wsdlOperation = portType.getBinding().get(new QName(portType.getBinding().getPortType().getName().getNamespaceURI(),operationName)); // TODO: replace this with proper error handling if(wsdlOperation ==null) throw new Error("Undefined operation name "+operationName); //so far, the inputAction, outputAction and fault actions are set from the @Action and @FaultAction //set the values from WSDLModel, if such annotations are not present or defaulted if(inputAction.equals("")) { inputAction = wsdlOperation.getOperation().getInput().getAction(); } else if(!inputAction.equals(wsdlOperation.getOperation().getInput().getAction())) //TODO input action might be from @Action or WebMethod(action) LOGGER.warning("Input Action from WSDL definitions and @Action for operation .... did not match, and willc ause problems in dispatching the requests"); if (!mep.isOneWay()) { if (outputAction.equals("")) WSLDOperationImpl op = wsdlOperation.getOperation(); if (op == null){ System.out.println("*****op is NULL"); } WSDLOutputImpl output = op.getOutput(); if (output == null){ System.out.println("*****output is NULL"); } outputAction = output.getAction(); for (CheckedExceptionImpl ce : exceptions) { if (ce.getFaultAction().equals("")) { QName detailQName = ce.getDetailType().tagName; ce.setFaultAction(wsdlOperation.getOperation().getFault(detailQName).getAction()); } } } } From the output in the console right before the NPE is thrown, it looks like the code in metro is processing doCallIDSOneWay which has no output operation defined in the WSDL: <wsdl:operation name="doCallIDSOneWay"> <wsdl:input message="tns:DoCallIDSOneWayRequest" wsaw:Action="doCallIDSOneWay"/> </wsdl:operation> But the code above seems to be failing on the check !mep.isOneWay() and tries to get the output for it and throws the NPE, so it looks like running on WebLogic the behavior is different, probably because of the XML parsing. BTW, I tried to place the lates xalan jars in the WEB-INF\Lib directory and modifying the weblogic-applcation.xml file to use: <package-name>javax.xml.*</package-name> Instead of <package-name>javax.xml.bind.*</package-name> But then I get this error: com.ctc.wstx.stax.WstxInputFactory cannot be cast to javax.xml.stream.XMLInputFactory -----Original Message----- From: Glen Mazza [mailto:[hidden email]] Sent: Friday, July 10, 2009 5:10 PM To: [hidden email] Subject: RE: Deploying to Weblogic 10.3.1 No--I don't think Metro cares about that display-name/description stuff--the NPE you're getting with Metro you would probably be getting anyway if Weblogic could handle the display-name/description tags at the location you are placing them. I'm guessing that the display-name/description stuff really *is* invalid with respect to the schema of the particular web.xml you're using, which is proving an unnecessary distraction to your problem. First make sure you indeed have a schema-valid web.xml (those two tags are mostly noise under <servlet> anyway--you don't need them) before proceeding. There's a slight chance the Xerces in use by Weblogic is old--that can sometimes cause wacky things to happen, you may want to override it with the latest Xerces, but I guess I would be grasping at straws here at this stage. Glen Carl Roberts wrote: > > OK, > > I've gotten a little further by doing this: > > I replaced the Sun JVM used by Weblogic Server 10.3.1 from version 1.6 > build 11 to 1.6 build 14 and this resolved the error: > > com.sun.xml.internal.messaging.saaj.soap.LocalStrings >> != com.sun.xml.messaging.saaj.soap.LocalStrings > > However, I am now running into another error which I think stems from > the fact that the following two schemas don't support the > <display-name> or <description> elements under the <servlet> element > of a web deployment descriptor (web.xml): > > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd > > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd > > > Here is what works in Metro and Tomcat (section of web.xml): > > <servlet> > <servlet-name>DocumentServiceSoap11</servlet-name> > <display-name>DocumentServiceSoap11</display-name> > <description>DocumentService SOAP 1.1</description> > > <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> > <load-on-startup>1</load-on-startup> > </servlet> > > However, when I use Weblogic and try to deploy using the same entries > in the web.xml I get this: > > Message icon - Error An error occurred during activation of changes, > please see the log for details. > Message icon - Error > [HTTP:101064][WebAppModule(DocumentServiceImplSoap11:DocumentServiceIm > plSoap11)] Error parsing descriptor in Web appplication > "C:\oracle\Middleware\home_LOAD16F\user_projects\domains\domain1\servers\AdminServer\tmp\_WL_user\DocumentServiceImplSoap11\cvh7s\com\oracle\webservices\documentservice\server\DocumentServiceImplSoap11.war" > weblogic.application.ModuleException: VALIDATION PROBLEMS WERE FOUND > problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> at > weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav > a:1201) at > weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:335) > at > weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedMo > duleDriver.java:176) > at > weblogic.application.internal.flow.ModuleListenerInvoker.prepare(Modul > eListenerInvoker.java:93) > at > weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(Deplo > ymentCallbackFlow.java:387) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDr > iver.java:37) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(Depl > oymentCallbackFlow.java:58) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(Depl > oymentCallbackFlow.java:42) > at > weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.jav > a:609) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDr > iver.java:37) > at > weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.ja > va:185) > at > weblogic.application.internal.EarDeployment.prepare(EarDeployment.java > :53) > at > weblogic.application.internal.DeploymentStateChecker.prepare(Deploymen > tStateChecker.java:154) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppC > ontainerInvoker.java:60) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.cre > ateAndPrepareContainer(ActivateOperation.java:197) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doP > repare(ActivateOperation.java:89) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.pre > pare(AbstractOperation.java:217) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeployme > ntPrepare(DeploymentManager.java:747) > at > weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploym > entList(DeploymentManager.java:1216) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare( > DeploymentManager.java:250) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prep > are(DeploymentServiceDispatcher.java:159) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java > :157) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuning > WorkManagerImpl.java:516) at > weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at > weblogic.work.ExecuteThread.run(ExecuteThread.java:173) Caused by: > weblogic.descriptor.DescriptorException: VALIDATION PROBLEMS WERE > FOUND > problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> at > weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(Marsh > allerFactory.java:241) > at > weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(Marsh > allerFactory.java:228) > at > weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(Mars > hallerFactory.java:153) > at > weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescr > iptorManager.java:323) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.getDescripto > rBeanFromReader(AbstractDescriptorLoader2.java:788) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.createDescri > ptorBean(AbstractDescriptorLoader2.java:409) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescript > orBeanWithoutPlan(AbstractDescriptorLoader2.java:759) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescript > orBean(AbstractDescriptorLoader2.java:768) > at > weblogic.servlet.internal.WebAppDescriptor.getWebAppBean(WebAppDescrip > tor.java:141) > at > weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav > a:1193) ... 26 more weblogic.application.ModuleException: VALIDATION > PROBLEMS WERE FOUND problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> > Message icon - Error VALIDATION PROBLEMS WERE FOUND problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> > > > > So it appears that Tomcat does no validation against the web.xml but > J2EE containers do (are required) and cannot validate the web.xml with > the <display-name> and <description> elements. If I take out these > elements then validation succeeds in Weblogic but then Metro throws this exception: > > ####<Jul 10, 2009 4:24:09 PM EDT> <Error> <Console> <idocumaker> > <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: > 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <> > <1247257449500> <BEA-240003> <Console encountered the following error > weblogic.application.ModuleException: > at > weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1376) > at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:452) > at > weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) > 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:37) > at > weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60) > at > weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27) > at > weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:629) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) > at > weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:206) > at > weblogic.application.internal.EarDeployment.activate(EarDeployment.java:53) > at > weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:569) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:140) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:106) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:323) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844) > at > weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:181) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:12) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:67) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) > Caused by: java.lang.NullPointerException: > at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:362) > at > com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl.java:104) > at > com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:262) > at > com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:335) > at > com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:198) > at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:504) > at > com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:253) > at > com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147) > at > com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:108) > at > weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:465) > at > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) > at > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) > at > weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:175) > at > weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1799) > at > weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3041) > at > weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java > :1374) >> > > > It seems to me this is a bug in Metro: > > If <display-name> and <description> aren't supported under the > <servlet> element in the schemas for a web.xml, then why are we > relying on them to be there and throwing a NullpointerException when > they are not. At the very least they should be made optional. This > way I can take them out in the web.xml when deploying to a J2EE > container and not have to worry about Metro throwing this exception. > It is possible I am missing some sort of crucial piece of information > but I don't see that this elements are supported under the <servlet> element in the following two schemas: > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd > > or > > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd > > Please advise, > > Carl > > > > -----Original Message----- > From: Glen Mazza [mailto:[hidden email]] > Sent: Friday, July 10, 2009 12:35 PM > To: [hidden email] > Subject: RE: Deploying to Weblogic 10.3.1 > > > Looking at your error stack, it appears that you're relying on BEAWLS' > own jax-ws implementation (weblogic.wsee.jaxws...) instead of Metro. > I might advise against removing the Metro jars from the WEB-INF/lib > for that reason, but as that is not working for you either, I'm not > sure what else to suggest other than trying CXF (which comes with no > guarantees on BEAWLS > either[1]) or switching to Glassfish or Tomcat. I'm pretty confident > that Metro 2.0 will work on BEAWLS but simply don't know the > <prefer-application-packages/> library overrides necessary for that to > happen. > > Sorry, > Glen > > [1] > http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-We > bLogic > > > Carl Roberts wrote: >> >> Thanks Glen, >> >> I will try your setup. >> >> BTW, since Oracle WebLogic claims to follow the Glassfish >> implementation and I couldn't get any further with my previous >> approach, I figured why not remove the metro webservices-*.jar files >> from my WEB-INF\lib directory and just go with the Weblogic >> implementation of Glassfish. Theoretically this should work. >> >> Well, >> >> I changed the web.xml to run the Implementation class directly by >> commenting out the listener: >> >> <?xml version="1.0" encoding="UTF-8" ?> >> - <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/j2ee"> >> <display-name>DocumentServiceSoap11</display-name> >> - <!-- >> <listener> >> >> <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class> >> </listener> >> >> >> --> >> - <servlet> >> <servlet-name>DocumentServiceSoap11</servlet-name> >> - <!-- >> <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> >> --> >> >> <servlet-class>com.oracle.webservices.documentservice.server.DocumentServiceImpl</servlet-class> >> <load-on-startup>0</load-on-startup> >> </servlet> >> - <servlet-mapping> >> <servlet-name>DocumentServiceSoap11</servlet-name> >> <url-pattern>/DocumentService</url-pattern> >> </servlet-mapping> >> - <session-config> >> <session-timeout>60</session-timeout> >> </session-config> >> </web-app> >> >> And I am getting a little further I think, but now I am getting this >> error, indicating the Weblogic schema validator is not up to par with >> Metro's 2.0 one, because it is complaining about default attribute >> for xsd:element not being valid? Isn't default attribute for >> xsd:element a standard attribute? It seems like a schema that worked >> fine before under tomcat now has problems under Weblogic. >> >> Here is the error from weblogic: >> >> Message icon - Error An error occurred during activation of changes, >> please see the log for details. >> Message icon - Error [HTTP:101216]Servlet: "DocumentServiceSoap11" >> failed to preload on startup in Web application: "DocumentServiceImpl". >> javax.xml.ws.WebServiceException: org.xml.sax.SAXParseException: >> s4s-att-not-allowed: Attribute 'default' cannot appear in element >> 'element'. at >> com.sun.xml.ws.server.ServerSchemaValidationTube.<init>(ServerSchemaV >> a >> lidationTube.java:69) >> at >> com.sun.xml.ws.api.pipe.ServerTubeAssemblerContext.createValidationTu >> b >> e(ServerTubeAssemblerContext.java:221) >> at >> weblogic.wsee.jaxws.tubeline.standard.StandardTubelineDeploymentListe >> n >> er$13.createServer(StandardTubelineDeploymentListener.java:158) >> at >> weblogic.wsee.jaxws.WLSTubelineAssemblerFactory$TubelineAssemblerImpl. >> createServer(WLSTubelineAssemblerFactory.java:105) >> at >> com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:158) >> at >> weblogic.wsee.jaxws.WLSContainer$WLSEndpointFactory$WLSEndpointImpl. >> nit>(WLSContainer.java:413) >> at '' >> >> This is getting a little frustrating. I guess I am going to try >> going back to including the webservies-*.jar files and using >> saaj-impl-3.2.jar from Sun instead of 3.1 version. I noticed the 3.2 >> version contains a META-INF\services directory with some factory >> classes while the 3.1 version I was using does not. I am hoping this >> solves the problem. >> >> >> >> -----Original Message----- >> From: Carl Roberts [mailto:[hidden email]] >> Sent: Friday, July 10, 2009 8:58 AM >> To: [hidden email] >> Cc: [hidden email] >> Subject: RE: Deploying to Weblogic 10.3.1 >> >> Hi Glen, >> >> Thanks for your response. Much appreciated. I tried your package >> names per the link you gave me instead of mine. Here are the ones I >> am using >> now: >> >> <package-name>com.sun.xml.*</package-name> >> <package-name>javax.xml.bind.*</package-name> >> >> But I am back to a different error that I saw before: >> >> Message icon - Error An error occurred during activation of changes, >> please see the log for details. >> Message icon - Error weblogic.application.ModuleException: >> Message icon - Error >> com.sun.xml.internal.messaging.saaj.soap.LocalStrings >> != com.sun.xml.messaging.saaj.soap.LocalStrings >> >> I noticed the saaj-impl namespace is also com.sun.xml.* so I am >> wondering if it has to do with this. >> >> I have also tried including the saaj-impl-1.3.jar file in the >> WEB-INF\lib directory of the war inside the ear and redeploying but I >> get the same error. Have you seen this error before? >> >> Do you have a sample ear file that you used for testing that I could >> try to deploy on my instance of Weblogic Server 10.3.1? >> >> Thanks, >> >> Joe >> >> -----Original Message----- >> From: Glen Mazza [mailto:[hidden email]] >> Sent: Thursday, July 09, 2009 7:03 PM >> To: [hidden email] >> Subject: RE: Deploying to Weblogic 10.3.1 >> >> >> I used somewhat different <p-a-p/s>--perhaps my list would help: >> http://www.jroller.com/gmazza/entry/deploying_metro_and_cxf_based >> >> Glen >> >> >> Carl Roberts wrote: >>> >>> <prefer-application-packages> >>> >>> <package-name>javax.jws.*</package-name> >>> >>> <package-name>javax.xml.soap.*</package-name> >>> >>> </prefer-application-packages> >>> >>> </weblogic-application> >>> >>> The deployment process in Weblogic then complains that my service >>> implementation class does not have @WebService or >>> @WebServiceProvider annotation, but it does: >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p2441929 >> 0 .html Sent from the Metro - Users mailing list archive at >> Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> > > -- > View this message in context: > http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24430825 > .html Sent from the Metro - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > -- View this message in context: http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24434406.html Sent from the Metro - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
RE: Deploying to Weblogic 10.3.1
|
|
Just FYI,
I got past the error. My Web method was missing the @Oneway annotation. Strangely enough, it still works on Tomcat without it but it is a no-no when deploying under Weblogic. I am running into another now: Caused by: java.lang.ClassCastException: at java.lang.Class.cast(Class.java:2990) at com.sun.xml.ws.util.ServiceFinder$LazyIterator.next(ServiceFinder.java:374) at com.sun.xml.ws.api.pipe.TubelineAssemblerFactory.create(TubelineAssemblerFactory.java:104) at com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:159) at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:229) at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:504) at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:253) at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147) at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:108) at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:465) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:175) at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1799) at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3041) at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1374) I will try to resolve that one and then send an update with all the steps required to deploy on Weblogic 10.3.1.0. Thanks, Joe -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 11:31 AM To: '[hidden email]'; '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 Just FYI, I added a call to print the Xalan version from the same method: void freeze(WSDLPortImpl portType) { this.wsdlOperation = portType.getBinding().get(new QName(portType.getBinding().getPortType().getName().getNamespaceURI(),operationName)); // TODO: replace this with proper error handling if(wsdlOperation ==null) throw new Error("Undefined operation name "+operationName); PrintWriter writer = new PrintWriter(System.out); boolean environmentOK = (new EnvironmentCheck()).checkEnvironment (writer); System.out.println(environmentOK); System.out.println("*****Freeze <" + operationName + ">"); //so far, the inputAction, outputAction and fault actions are set from the @Action and @FaultAction //set the values from WSDLModel, if such annotations are not present or defaulted if(inputAction.equals("")) { inputAction = wsdlOperation.getOperation().getInput().getAction(); } else if(!inputAction.equals(wsdlOperation.getOperation().getInput().getAction())) //TODO input action might be from @Action or WebMethod(action) LOGGER.warning("Input Action from WSDL definitions and @Action for operation .... did not match, and willc ause problems in dispatching the requests"); if (!mep.isOneWay()) { if (outputAction.equals("")){ WSDLOperationImpl op = wsdlOperation.getOperation(); if (op == null){ System.out.println("*****op is NULL"); } WSDLOutputImpl output = op.getOutput(); if (output == null){ System.out.println("*****output is NULL"); } outputAction = output.getAction(); } for (CheckedExceptionImpl ce : exceptions) { if (ce.getFaultAction().equals("")) { QName detailQName = ce.getDetailType().tagName; ce.setFaultAction(wsdlOperation.getOperation().getFault(detailQName).getAction()); } } } } which prints this so it appears the code is using Xalan 2.7.1? version.JAXP=1.1 or higher java.ext.dirs=C:\jdk1.6.0_14\jre\lib\ext;C:\WINDOWS\Sun\Java\lib\ext version.xerces2=Xerces-J 2.9.0 version.xerces1=not-present version.xalan2_2=Xalan Java 2.7.1 version.xalan1=not-present version.ant=Apache Ant version 1.7.0 compiled on December 13 2006 java.version=1.6.0_14 version.DOM=2.0 version.crimson=not-present sun.boot.class.path=C:\jdk1.6.0_14\jre\lib\resources.jar;C:\jdk1.6.0_14\jre\lib\ rt.jar;C:\jdk1.6.0_14\jre\lib\sunrsasign.jar;C:\jdk1.6.0_14\jre\lib\jsse.jar;C:\ jdk1.6.0_14\jre\lib\jce.jar;C:\jdk1.6.0_14\jre\lib\charsets.jar;C:\jdk1.6.0_14\j re\classes version.SAX=2.0 version.xalan2x=Xalan Java 2.7.1 #----- END writeEnvironmentReport: Useful properties found: ----- # YAHOO! Your environment seems to be OK. true *****Freeze <doCallIDSOneWay> -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 10:49 AM To: '[hidden email]'; '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 Here is the output from the console: <Jul 13, 2009 10:41:58 AM EDT> <Warning> <netuix> <BEA-423420> <Redirect is exec uted in begin or refresh action. Redirect url is /console/console.portal?_nfpb=t rue&_pageLabel=AppDeploymentsControlPage.> *****Freeze <doCallIDS> *****Freeze <doCallIDSOneWay> *****output is NULL Jul 13, 2009 10:43:10 AM com.sun.xml.ws.transport.http.servlet.WSServletContextL istener contextInitialized SEVERE: WSSERVLET11: failed to parse runtime descriptor: java.lang.NullPointerEx ception java.lang.NullPointerException at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:375) at com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 10:48 AM To: '[hidden email]'; '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 Sorry, Forgot to mention the actual class that contains the code: com.sun.xml.ws.model.JavaMethodImpl -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 10:47 AM To: '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 You are right Glen, I debugged the code and the issue is related to this function (I added some System.out.println statements): /*package*/ void freeze(WSDLPortImpl portType) { this.wsdlOperation = portType.getBinding().get(new QName(portType.getBinding().getPortType().getName().getNamespaceURI(),operationName)); // TODO: replace this with proper error handling if(wsdlOperation ==null) throw new Error("Undefined operation name "+operationName); //so far, the inputAction, outputAction and fault actions are set from the @Action and @FaultAction //set the values from WSDLModel, if such annotations are not present or defaulted if(inputAction.equals("")) { inputAction = wsdlOperation.getOperation().getInput().getAction(); } else if(!inputAction.equals(wsdlOperation.getOperation().getInput().getAction())) //TODO input action might be from @Action or WebMethod(action) LOGGER.warning("Input Action from WSDL definitions and @Action for operation .... did not match, and willc ause problems in dispatching the requests"); if (!mep.isOneWay()) { if (outputAction.equals("")) WSLDOperationImpl op = wsdlOperation.getOperation(); if (op == null){ System.out.println("*****op is NULL"); } WSDLOutputImpl output = op.getOutput(); if (output == null){ System.out.println("*****output is NULL"); } outputAction = output.getAction(); for (CheckedExceptionImpl ce : exceptions) { if (ce.getFaultAction().equals("")) { QName detailQName = ce.getDetailType().tagName; ce.setFaultAction(wsdlOperation.getOperation().getFault(detailQName).getAction()); } } } } From the output in the console right before the NPE is thrown, it looks like the code in metro is processing doCallIDSOneWay which has no output operation defined in the WSDL: <wsdl:operation name="doCallIDSOneWay"> <wsdl:input message="tns:DoCallIDSOneWayRequest" wsaw:Action="doCallIDSOneWay"/> </wsdl:operation> But the code above seems to be failing on the check !mep.isOneWay() and tries to get the output for it and throws the NPE, so it looks like running on WebLogic the behavior is different, probably because of the XML parsing. BTW, I tried to place the lates xalan jars in the WEB-INF\Lib directory and modifying the weblogic-applcation.xml file to use: <package-name>javax.xml.*</package-name> Instead of <package-name>javax.xml.bind.*</package-name> But then I get this error: com.ctc.wstx.stax.WstxInputFactory cannot be cast to javax.xml.stream.XMLInputFactory -----Original Message----- From: Glen Mazza [mailto:[hidden email]] Sent: Friday, July 10, 2009 5:10 PM To: [hidden email] Subject: RE: Deploying to Weblogic 10.3.1 No--I don't think Metro cares about that display-name/description stuff--the NPE you're getting with Metro you would probably be getting anyway if Weblogic could handle the display-name/description tags at the location you are placing them. I'm guessing that the display-name/description stuff really *is* invalid with respect to the schema of the particular web.xml you're using, which is proving an unnecessary distraction to your problem. First make sure you indeed have a schema-valid web.xml (those two tags are mostly noise under <servlet> anyway--you don't need them) before proceeding. There's a slight chance the Xerces in use by Weblogic is old--that can sometimes cause wacky things to happen, you may want to override it with the latest Xerces, but I guess I would be grasping at straws here at this stage. Glen Carl Roberts wrote: > > OK, > > I've gotten a little further by doing this: > > I replaced the Sun JVM used by Weblogic Server 10.3.1 from version 1.6 > build 11 to 1.6 build 14 and this resolved the error: > > com.sun.xml.internal.messaging.saaj.soap.LocalStrings >> != com.sun.xml.messaging.saaj.soap.LocalStrings > > However, I am now running into another error which I think stems from > the fact that the following two schemas don't support the > <display-name> or <description> elements under the <servlet> element > of a web deployment descriptor (web.xml): > > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd > > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd > > > Here is what works in Metro and Tomcat (section of web.xml): > > <servlet> > <servlet-name>DocumentServiceSoap11</servlet-name> > <display-name>DocumentServiceSoap11</display-name> > <description>DocumentService SOAP 1.1</description> > > <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> > <load-on-startup>1</load-on-startup> > </servlet> > > However, when I use Weblogic and try to deploy using the same entries > in the web.xml I get this: > > Message icon - Error An error occurred during activation of changes, > please see the log for details. > Message icon - Error > [HTTP:101064][WebAppModule(DocumentServiceImplSoap11:DocumentServiceIm > plSoap11)] Error parsing descriptor in Web appplication > "C:\oracle\Middleware\home_LOAD16F\user_projects\domains\domain1\servers\AdminServer\tmp\_WL_user\DocumentServiceImplSoap11\cvh7s\com\oracle\webservices\documentservice\server\DocumentServiceImplSoap11.war" > weblogic.application.ModuleException: VALIDATION PROBLEMS WERE FOUND > problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> at > weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav > a:1201) at > weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:335) > at > weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedMo > duleDriver.java:176) > at > weblogic.application.internal.flow.ModuleListenerInvoker.prepare(Modul > eListenerInvoker.java:93) > at > weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(Deplo > ymentCallbackFlow.java:387) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDr > iver.java:37) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(Depl > oymentCallbackFlow.java:58) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(Depl > oymentCallbackFlow.java:42) > at > weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.jav > a:609) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDr > iver.java:37) > at > weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.ja > va:185) > at > weblogic.application.internal.EarDeployment.prepare(EarDeployment.java > :53) > at > weblogic.application.internal.DeploymentStateChecker.prepare(Deploymen > tStateChecker.java:154) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppC > ontainerInvoker.java:60) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.cre > ateAndPrepareContainer(ActivateOperation.java:197) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doP > repare(ActivateOperation.java:89) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.pre > pare(AbstractOperation.java:217) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeployme > ntPrepare(DeploymentManager.java:747) > at > weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploym > entList(DeploymentManager.java:1216) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare( > DeploymentManager.java:250) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prep > are(DeploymentServiceDispatcher.java:159) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java > :157) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuning > WorkManagerImpl.java:516) at > weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at > weblogic.work.ExecuteThread.run(ExecuteThread.java:173) Caused by: > weblogic.descriptor.DescriptorException: VALIDATION PROBLEMS WERE > FOUND > problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> at > weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(Marsh > allerFactory.java:241) > at > weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(Marsh > allerFactory.java:228) > at > weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(Mars > hallerFactory.java:153) > at > weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescr > iptorManager.java:323) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.getDescripto > rBeanFromReader(AbstractDescriptorLoader2.java:788) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.createDescri > ptorBean(AbstractDescriptorLoader2.java:409) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescript > orBeanWithoutPlan(AbstractDescriptorLoader2.java:759) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescript > orBean(AbstractDescriptorLoader2.java:768) > at > weblogic.servlet.internal.WebAppDescriptor.getWebAppBean(WebAppDescrip > tor.java:141) > at > weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav > a:1193) ... 26 more weblogic.application.ModuleException: VALIDATION > PROBLEMS WERE FOUND problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> > Message icon - Error VALIDATION PROBLEMS WERE FOUND problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> > > > > So it appears that Tomcat does no validation against the web.xml but > J2EE containers do (are required) and cannot validate the web.xml with > the <display-name> and <description> elements. If I take out these > elements then validation succeeds in Weblogic but then Metro throws this exception: > > ####<Jul 10, 2009 4:24:09 PM EDT> <Error> <Console> <idocumaker> > <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: > 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <> > <1247257449500> <BEA-240003> <Console encountered the following error > weblogic.application.ModuleException: > at > weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1376) > at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:452) > at > weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) > 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:37) > at > weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60) > at > weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27) > at > weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:629) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) > at > weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:206) > at > weblogic.application.internal.EarDeployment.activate(EarDeployment.java:53) > at > weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:569) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:140) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:106) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:323) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844) > at > weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:181) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:12) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:67) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) > Caused by: java.lang.NullPointerException: > at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:362) > at > com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl.java:104) > at > com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:262) > at > com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:335) > at > com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:198) > at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:504) > at > com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:253) > at > com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147) > at > com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:108) > at > weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:465) > at > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) > at > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) > at > weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:175) > at > weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1799) > at > weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3041) > at > weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java > :1374) >> > > > It seems to me this is a bug in Metro: > > If <display-name> and <description> aren't supported under the > <servlet> element in the schemas for a web.xml, then why are we > relying on them to be there and throwing a NullpointerException when > they are not. At the very least they should be made optional. This > way I can take them out in the web.xml when deploying to a J2EE > container and not have to worry about Metro throwing this exception. > It is possible I am missing some sort of crucial piece of information > but I don't see that this elements are supported under the <servlet> element in the following two schemas: > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd > > or > > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd > > Please advise, > > Carl > > > > -----Original Message----- > From: Glen Mazza [mailto:[hidden email]] > Sent: Friday, July 10, 2009 12:35 PM > To: [hidden email] > Subject: RE: Deploying to Weblogic 10.3.1 > > > Looking at your error stack, it appears that you're relying on BEAWLS' > own jax-ws implementation (weblogic.wsee.jaxws...) instead of Metro. > I might advise against removing the Metro jars from the WEB-INF/lib > for that reason, but as that is not working for you either, I'm not > sure what else to suggest other than trying CXF (which comes with no > guarantees on BEAWLS > either[1]) or switching to Glassfish or Tomcat. I'm pretty confident > that Metro 2.0 will work on BEAWLS but simply don't know the > <prefer-application-packages/> library overrides necessary for that to > happen. > > Sorry, > Glen > > [1] > http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-We > bLogic > > > Carl Roberts wrote: >> >> Thanks Glen, >> >> I will try your setup. >> >> BTW, since Oracle WebLogic claims to follow the Glassfish >> implementation and I couldn't get any further with my previous >> approach, I figured why not remove the metro webservices-*.jar files >> from my WEB-INF\lib directory and just go with the Weblogic >> implementation of Glassfish. Theoretically this should work. >> >> Well, >> >> I changed the web.xml to run the Implementation class directly by >> commenting out the listener: >> >> <?xml version="1.0" encoding="UTF-8" ?> >> - <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/j2ee"> >> <display-name>DocumentServiceSoap11</display-name> >> - <!-- >> <listener> >> >> <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class> >> </listener> >> >> >> --> >> - <servlet> >> <servlet-name>DocumentServiceSoap11</servlet-name> >> - <!-- >> <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> >> --> >> >> <servlet-class>com.oracle.webservices.documentservice.server.DocumentServiceImpl</servlet-class> >> <load-on-startup>0</load-on-startup> >> </servlet> >> - <servlet-mapping> >> <servlet-name>DocumentServiceSoap11</servlet-name> >> <url-pattern>/DocumentService</url-pattern> >> </servlet-mapping> >> - <session-config> >> <session-timeout>60</session-timeout> >> </session-config> >> </web-app> >> >> And I am getting a little further I think, but now I am getting this >> error, indicating the Weblogic schema validator is not up to par with >> Metro's 2.0 one, because it is complaining about default attribute >> for xsd:element not being valid? Isn't default attribute for >> xsd:element a standard attribute? It seems like a schema that worked >> fine before under tomcat now has problems under Weblogic. >> >> Here is the error from weblogic: >> >> Message icon - Error An error occurred during activation of changes, >> please see the log for details. >> Message icon - Error [HTTP:101216]Servlet: "DocumentServiceSoap11" >> failed to preload on startup in Web application: "DocumentServiceImpl". >> javax.xml.ws.WebServiceException: org.xml.sax.SAXParseException: >> s4s-att-not-allowed: Attribute 'default' cannot appear in element >> 'element'. at >> com.sun.xml.ws.server.ServerSchemaValidationTube.<init>(ServerSchemaV >> a >> lidationTube.java:69) >> at >> com.sun.xml.ws.api.pipe.ServerTubeAssemblerContext.createValidationTu >> b >> e(ServerTubeAssemblerContext.java:221) >> at >> weblogic.wsee.jaxws.tubeline.standard.StandardTubelineDeploymentListe >> n >> er$13.createServer(StandardTubelineDeploymentListener.java:158) >> at >> weblogic.wsee.jaxws.WLSTubelineAssemblerFactory$TubelineAssemblerImpl. >> createServer(WLSTubelineAssemblerFactory.java:105) >> at >> com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:158) >> at >> weblogic.wsee.jaxws.WLSContainer$WLSEndpointFactory$WLSEndpointImpl. >> nit>(WLSContainer.java:413) >> at '' >> >> This is getting a little frustrating. I guess I am going to try >> going back to including the webservies-*.jar files and using >> saaj-impl-3.2.jar from Sun instead of 3.1 version. I noticed the 3.2 >> version contains a META-INF\services directory with some factory >> classes while the 3.1 version I was using does not. I am hoping this >> solves the problem. >> >> >> >> -----Original Message----- >> From: Carl Roberts [mailto:[hidden email]] >> Sent: Friday, July 10, 2009 8:58 AM >> To: [hidden email] >> Cc: [hidden email] >> Subject: RE: Deploying to Weblogic 10.3.1 >> >> Hi Glen, >> >> Thanks for your response. Much appreciated. I tried your package >> names per the link you gave me instead of mine. Here are the ones I >> am using >> now: >> >> <package-name>com.sun.xml.*</package-name> >> <package-name>javax.xml.bind.*</package-name> >> >> But I am back to a different error that I saw before: >> >> Message icon - Error An error occurred during activation of changes, >> please see the log for details. >> Message icon - Error weblogic.application.ModuleException: >> Message icon - Error >> com.sun.xml.internal.messaging.saaj.soap.LocalStrings >> != com.sun.xml.messaging.saaj.soap.LocalStrings >> >> I noticed the saaj-impl namespace is also com.sun.xml.* so I am >> wondering if it has to do with this. >> >> I have also tried including the saaj-impl-1.3.jar file in the >> WEB-INF\lib directory of the war inside the ear and redeploying but I >> get the same error. Have you seen this error before? >> >> Do you have a sample ear file that you used for testing that I could >> try to deploy on my instance of Weblogic Server 10.3.1? >> >> Thanks, >> >> Joe >> >> -----Original Message----- >> From: Glen Mazza [mailto:[hidden email]] >> Sent: Thursday, July 09, 2009 7:03 PM >> To: [hidden email] >> Subject: RE: Deploying to Weblogic 10.3.1 >> >> >> I used somewhat different <p-a-p/s>--perhaps my list would help: >> http://www.jroller.com/gmazza/entry/deploying_metro_and_cxf_based >> >> Glen >> >> >> Carl Roberts wrote: >>> >>> <prefer-application-packages> >>> >>> <package-name>javax.jws.*</package-name> >>> >>> <package-name>javax.xml.soap.*</package-name> >>> >>> </prefer-application-packages> >>> >>> </weblogic-application> >>> >>> The deployment process in Weblogic then complains that my service >>> implementation class does not have @WebService or >>> @WebServiceProvider annotation, but it does: >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p2441929 >> 0 .html Sent from the Metro - Users mailing list archive at >> Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> > > -- > View this message in context: > http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24430825 > .html Sent from the Metro - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > -- View this message in context: http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24434406.html Sent from the Metro - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
RE: Deploying to Weblogic 10.3.1
|
|
Here is a better description of the error:
Jul 13, 2009 12:12:38 PM com.sun.xml.ws.transport.http.servlet.WSServletContextListener contextInitialized SEVERE: WSSERVLET11: failed to parse runtime descriptor: com.sun.xml.ws.util.ServiceConfigurationError: com.sun.xml.ws.a pi.pipe.TubelineAssemblerFactory: Provider weblogic.wsee.jaxws.WLSTubelineAssemblerFactory is specified in jar:file:/C:/ oracle/Middleware/home_LOAD16F/wlserver_10.3/server/lib/weblogic.jar!/META-INF/services/com.sun.xml.ws.api.pipe.Tubeline AssemblerFactory but could not be instantiated: java.lang.ClassCastException com.sun.xml.ws.util.ServiceConfigurationError: com.sun.xml.ws.api.pipe.TubelineAssemblerFactory: Provider weblogic.wsee. jaxws.WLSTubelineAssemblerFactory is specified in jar:file:/C:/oracle/Middleware/home_LOAD16F/wlserver_10.3/server/lib/w eblogic.jar!/META-INF/services/com.sun.xml.ws.api.pipe.TubelineAssemblerFactorybut could not be instantiated: java.lang. ClassCastException Please let me know if you guys have seen this or if you have any suggestions? Thanks, Joe -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 12:00 PM To: [hidden email]; [hidden email] Subject: RE: Deploying to Weblogic 10.3.1 Just FYI, I got past the error. My Web method was missing the @Oneway annotation. Strangely enough, it still works on Tomcat without it but it is a no-no when deploying under Weblogic. I am running into another now: Caused by: java.lang.ClassCastException: at java.lang.Class.cast(Class.java:2990) at com.sun.xml.ws.util.ServiceFinder$LazyIterator.next(ServiceFinder.java:374) at com.sun.xml.ws.api.pipe.TubelineAssemblerFactory.create(TubelineAssemblerFactory.java:104) at com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:159) at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:229) at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:504) at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:253) at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147) at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:108) at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:465) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:175) at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1799) at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3041) at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1374) I will try to resolve that one and then send an update with all the steps required to deploy on Weblogic 10.3.1.0. Thanks, Joe -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 11:31 AM To: '[hidden email]'; '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 Just FYI, I added a call to print the Xalan version from the same method: void freeze(WSDLPortImpl portType) { this.wsdlOperation = portType.getBinding().get(new QName(portType.getBinding().getPortType().getName().getNamespaceURI(),operationName)); // TODO: replace this with proper error handling if(wsdlOperation ==null) throw new Error("Undefined operation name "+operationName); PrintWriter writer = new PrintWriter(System.out); boolean environmentOK = (new EnvironmentCheck()).checkEnvironment (writer); System.out.println(environmentOK); System.out.println("*****Freeze <" + operationName + ">"); //so far, the inputAction, outputAction and fault actions are set from the @Action and @FaultAction //set the values from WSDLModel, if such annotations are not present or defaulted if(inputAction.equals("")) { inputAction = wsdlOperation.getOperation().getInput().getAction(); } else if(!inputAction.equals(wsdlOperation.getOperation().getInput().getAction())) //TODO input action might be from @Action or WebMethod(action) LOGGER.warning("Input Action from WSDL definitions and @Action for operation .... did not match, and willc ause problems in dispatching the requests"); if (!mep.isOneWay()) { if (outputAction.equals("")){ WSDLOperationImpl op = wsdlOperation.getOperation(); if (op == null){ System.out.println("*****op is NULL"); } WSDLOutputImpl output = op.getOutput(); if (output == null){ System.out.println("*****output is NULL"); } outputAction = output.getAction(); } for (CheckedExceptionImpl ce : exceptions) { if (ce.getFaultAction().equals("")) { QName detailQName = ce.getDetailType().tagName; ce.setFaultAction(wsdlOperation.getOperation().getFault(detailQName).getAction()); } } } } which prints this so it appears the code is using Xalan 2.7.1? version.JAXP=1.1 or higher java.ext.dirs=C:\jdk1.6.0_14\jre\lib\ext;C:\WINDOWS\Sun\Java\lib\ext version.xerces2=Xerces-J 2.9.0 version.xerces1=not-present version.xalan2_2=Xalan Java 2.7.1 version.xalan1=not-present version.ant=Apache Ant version 1.7.0 compiled on December 13 2006 java.version=1.6.0_14 version.DOM=2.0 version.crimson=not-present sun.boot.class.path=C:\jdk1.6.0_14\jre\lib\resources.jar;C:\jdk1.6.0_14\jre\lib\ rt.jar;C:\jdk1.6.0_14\jre\lib\sunrsasign.jar;C:\jdk1.6.0_14\jre\lib\jsse.jar;C:\ jdk1.6.0_14\jre\lib\jce.jar;C:\jdk1.6.0_14\jre\lib\charsets.jar;C:\jdk1.6.0_14\j re\classes version.SAX=2.0 version.xalan2x=Xalan Java 2.7.1 #----- END writeEnvironmentReport: Useful properties found: ----- # YAHOO! Your environment seems to be OK. true *****Freeze <doCallIDSOneWay> -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 10:49 AM To: '[hidden email]'; '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 Here is the output from the console: <Jul 13, 2009 10:41:58 AM EDT> <Warning> <netuix> <BEA-423420> <Redirect is exec uted in begin or refresh action. Redirect url is /console/console.portal?_nfpb=t rue&_pageLabel=AppDeploymentsControlPage.> *****Freeze <doCallIDS> *****Freeze <doCallIDSOneWay> *****output is NULL Jul 13, 2009 10:43:10 AM com.sun.xml.ws.transport.http.servlet.WSServletContextL istener contextInitialized SEVERE: WSSERVLET11: failed to parse runtime descriptor: java.lang.NullPointerEx ception java.lang.NullPointerException at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:375) at com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 10:48 AM To: '[hidden email]'; '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 Sorry, Forgot to mention the actual class that contains the code: com.sun.xml.ws.model.JavaMethodImpl -----Original Message----- From: Carl Roberts [mailto:[hidden email]] Sent: Monday, July 13, 2009 10:47 AM To: '[hidden email]' Subject: RE: Deploying to Weblogic 10.3.1 You are right Glen, I debugged the code and the issue is related to this function (I added some System.out.println statements): /*package*/ void freeze(WSDLPortImpl portType) { this.wsdlOperation = portType.getBinding().get(new QName(portType.getBinding().getPortType().getName().getNamespaceURI(),operationName)); // TODO: replace this with proper error handling if(wsdlOperation ==null) throw new Error("Undefined operation name "+operationName); //so far, the inputAction, outputAction and fault actions are set from the @Action and @FaultAction //set the values from WSDLModel, if such annotations are not present or defaulted if(inputAction.equals("")) { inputAction = wsdlOperation.getOperation().getInput().getAction(); } else if(!inputAction.equals(wsdlOperation.getOperation().getInput().getAction())) //TODO input action might be from @Action or WebMethod(action) LOGGER.warning("Input Action from WSDL definitions and @Action for operation .... did not match, and willc ause problems in dispatching the requests"); if (!mep.isOneWay()) { if (outputAction.equals("")) WSLDOperationImpl op = wsdlOperation.getOperation(); if (op == null){ System.out.println("*****op is NULL"); } WSDLOutputImpl output = op.getOutput(); if (output == null){ System.out.println("*****output is NULL"); } outputAction = output.getAction(); for (CheckedExceptionImpl ce : exceptions) { if (ce.getFaultAction().equals("")) { QName detailQName = ce.getDetailType().tagName; ce.setFaultAction(wsdlOperation.getOperation().getFault(detailQName).getAction()); } } } } From the output in the console right before the NPE is thrown, it looks like the code in metro is processing doCallIDSOneWay which has no output operation defined in the WSDL: <wsdl:operation name="doCallIDSOneWay"> <wsdl:input message="tns:DoCallIDSOneWayRequest" wsaw:Action="doCallIDSOneWay"/> </wsdl:operation> But the code above seems to be failing on the check !mep.isOneWay() and tries to get the output for it and throws the NPE, so it looks like running on WebLogic the behavior is different, probably because of the XML parsing. BTW, I tried to place the lates xalan jars in the WEB-INF\Lib directory and modifying the weblogic-applcation.xml file to use: <package-name>javax.xml.*</package-name> Instead of <package-name>javax.xml.bind.*</package-name> But then I get this error: com.ctc.wstx.stax.WstxInputFactory cannot be cast to javax.xml.stream.XMLInputFactory -----Original Message----- From: Glen Mazza [mailto:[hidden email]] Sent: Friday, July 10, 2009 5:10 PM To: [hidden email] Subject: RE: Deploying to Weblogic 10.3.1 No--I don't think Metro cares about that display-name/description stuff--the NPE you're getting with Metro you would probably be getting anyway if Weblogic could handle the display-name/description tags at the location you are placing them. I'm guessing that the display-name/description stuff really *is* invalid with respect to the schema of the particular web.xml you're using, which is proving an unnecessary distraction to your problem. First make sure you indeed have a schema-valid web.xml (those two tags are mostly noise under <servlet> anyway--you don't need them) before proceeding. There's a slight chance the Xerces in use by Weblogic is old--that can sometimes cause wacky things to happen, you may want to override it with the latest Xerces, but I guess I would be grasping at straws here at this stage. Glen Carl Roberts wrote: > > OK, > > I've gotten a little further by doing this: > > I replaced the Sun JVM used by Weblogic Server 10.3.1 from version 1.6 > build 11 to 1.6 build 14 and this resolved the error: > > com.sun.xml.internal.messaging.saaj.soap.LocalStrings >> != com.sun.xml.messaging.saaj.soap.LocalStrings > > However, I am now running into another error which I think stems from > the fact that the following two schemas don't support the > <display-name> or <description> elements under the <servlet> element > of a web deployment descriptor (web.xml): > > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd > > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd > > > Here is what works in Metro and Tomcat (section of web.xml): > > <servlet> > <servlet-name>DocumentServiceSoap11</servlet-name> > <display-name>DocumentServiceSoap11</display-name> > <description>DocumentService SOAP 1.1</description> > > <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> > <load-on-startup>1</load-on-startup> > </servlet> > > However, when I use Weblogic and try to deploy using the same entries > in the web.xml I get this: > > Message icon - Error An error occurred during activation of changes, > please see the log for details. > Message icon - Error > [HTTP:101064][WebAppModule(DocumentServiceImplSoap11:DocumentServiceIm > plSoap11)] Error parsing descriptor in Web appplication > "C:\oracle\Middleware\home_LOAD16F\user_projects\domains\domain1\servers\AdminServer\tmp\_WL_user\DocumentServiceImplSoap11\cvh7s\com\oracle\webservices\documentservice\server\DocumentServiceImplSoap11.war" > weblogic.application.ModuleException: VALIDATION PROBLEMS WERE FOUND > problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> at > weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav > a:1201) at > weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:335) > at > weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedMo > duleDriver.java:176) > at > weblogic.application.internal.flow.ModuleListenerInvoker.prepare(Modul > eListenerInvoker.java:93) > at > weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(Deplo > ymentCallbackFlow.java:387) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDr > iver.java:37) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(Depl > oymentCallbackFlow.java:58) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(Depl > oymentCallbackFlow.java:42) > at > weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.jav > a:609) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDr > iver.java:37) > at > weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.ja > va:185) > at > weblogic.application.internal.EarDeployment.prepare(EarDeployment.java > :53) > at > weblogic.application.internal.DeploymentStateChecker.prepare(Deploymen > tStateChecker.java:154) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppC > ontainerInvoker.java:60) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.cre > ateAndPrepareContainer(ActivateOperation.java:197) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doP > repare(ActivateOperation.java:89) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.pre > pare(AbstractOperation.java:217) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeployme > ntPrepare(DeploymentManager.java:747) > at > weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploym > entList(DeploymentManager.java:1216) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare( > DeploymentManager.java:250) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prep > are(DeploymentServiceDispatcher.java:159) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java > :157) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallba > ckDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuning > WorkManagerImpl.java:516) at > weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at > weblogic.work.ExecuteThread.run(ExecuteThread.java:173) Caused by: > weblogic.descriptor.DescriptorException: VALIDATION PROBLEMS WERE > FOUND > problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> at > weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(Marsh > allerFactory.java:241) > at > weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(Marsh > allerFactory.java:228) > at > weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(Mars > hallerFactory.java:153) > at > weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescr > iptorManager.java:323) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.getDescripto > rBeanFromReader(AbstractDescriptorLoader2.java:788) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.createDescri > ptorBean(AbstractDescriptorLoader2.java:409) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescript > orBeanWithoutPlan(AbstractDescriptorLoader2.java:759) > at > weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescript > orBean(AbstractDescriptorLoader2.java:768) > at > weblogic.servlet.internal.WebAppDescriptor.getWebAppBean(WebAppDescrip > tor.java:141) > at > weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav > a:1193) ... 26 more weblogic.application.ModuleException: VALIDATION > PROBLEMS WERE FOUND problem: cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> > Message icon - Error VALIDATION PROBLEMS WERE FOUND problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'display-name@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> problem: > cvc-complex-type.2.4a: Expected elements > 'servlet-class@http://java.sun.com/xml/ns/javaee > jsp-file@http://java.sun.com/xml/ns/javaee' instead of > 'description@http://java.sun.com/xml/ns/javaee' here in element > servlet@http://java.sun.com/xml/ns/javaee:<null> > > > > So it appears that Tomcat does no validation against the web.xml but > J2EE containers do (are required) and cannot validate the web.xml with > the <display-name> and <description> elements. If I take out these > elements then validation succeeds in Weblogic but then Metro throws this exception: > > ####<Jul 10, 2009 4:24:09 PM EDT> <Error> <Console> <idocumaker> > <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: > 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <> > <1247257449500> <BEA-240003> <Console encountered the following error > weblogic.application.ModuleException: > at > weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1376) > at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:452) > at > weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) > 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:37) > at > weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60) > at > weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27) > at > weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:629) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37) > at > weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:206) > at > weblogic.application.internal.EarDeployment.activate(EarDeployment.java:53) > at > weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:569) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:140) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:106) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:323) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844) > at > weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:181) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:12) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:67) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) > Caused by: java.lang.NullPointerException: > at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:362) > at > com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl.java:104) > at > com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:262) > at > com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:335) > at > com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:198) > at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:504) > at > com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:253) > at > com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147) > at > com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:108) > at > weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:465) > at > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) > at > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) > at > weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:175) > at > weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1799) > at > weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3041) > at > weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java > :1374) >> > > > It seems to me this is a bug in Metro: > > If <display-name> and <description> aren't supported under the > <servlet> element in the schemas for a web.xml, then why are we > relying on them to be there and throwing a NullpointerException when > they are not. At the very least they should be made optional. This > way I can take them out in the web.xml when deploying to a J2EE > container and not have to worry about Metro throwing this exception. > It is possible I am missing some sort of crucial piece of information > but I don't see that this elements are supported under the <servlet> element in the following two schemas: > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd > > or > > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd > > Please advise, > > Carl > > > > -----Original Message----- > From: Glen Mazza [mailto:[hidden email]] > Sent: Friday, July 10, 2009 12:35 PM > To: [hidden email] > Subject: RE: Deploying to Weblogic 10.3.1 > > > Looking at your error stack, it appears that you're relying on BEAWLS' > own jax-ws implementation (weblogic.wsee.jaxws...) instead of Metro. > I might advise against removing the Metro jars from the WEB-INF/lib > for that reason, but as that is not working for you either, I'm not > sure what else to suggest other than trying CXF (which comes with no > guarantees on BEAWLS > either[1]) or switching to Glassfish or Tomcat. I'm pretty confident > that Metro 2.0 will work on BEAWLS but simply don't know the > <prefer-application-packages/> library overrides necessary for that to > happen. > > Sorry, > Glen > > [1] > http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-We > bLogic > > > Carl Roberts wrote: >> >> Thanks Glen, >> >> I will try your setup. >> >> BTW, since Oracle WebLogic claims to follow the Glassfish >> implementation and I couldn't get any further with my previous >> approach, I figured why not remove the metro webservices-*.jar files >> from my WEB-INF\lib directory and just go with the Weblogic >> implementation of Glassfish. Theoretically this should work. >> >> Well, >> >> I changed the web.xml to run the Implementation class directly by >> commenting out the listener: >> >> <?xml version="1.0" encoding="UTF-8" ?> >> - <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/j2ee"> >> <display-name>DocumentServiceSoap11</display-name> >> - <!-- >> <listener> >> >> <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class> >> </listener> >> >> >> --> >> - <servlet> >> <servlet-name>DocumentServiceSoap11</servlet-name> >> - <!-- >> <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class> >> --> >> >> <servlet-class>com.oracle.webservices.documentservice.server.DocumentServiceImpl</servlet-class> >> <load-on-startup>0</load-on-startup> >> </servlet> >> - <servlet-mapping> >> <servlet-name>DocumentServiceSoap11</servlet-name> >> <url-pattern>/DocumentService</url-pattern> >> </servlet-mapping> >> - <session-config> >> <session-timeout>60</session-timeout> >> </session-config> >> </web-app> >> >> And I am getting a little further I think, but now I am getting this >> error, indicating the Weblogic schema validator is not up to par with >> Metro's 2.0 one, because it is complaining about default attribute >> for xsd:element not being valid? Isn't default attribute for >> xsd:element a standard attribute? It seems like a schema that worked >> fine before under tomcat now has problems under Weblogic. >> >> Here is the error from weblogic: >> >> Message icon - Error An error occurred during activation of changes, >> please see the log for details. >> Message icon - Error [HTTP:101216]Servlet: "DocumentServiceSoap11" >> failed to preload on startup in Web application: "DocumentServiceImpl". >> javax.xml.ws.WebServiceException: org.xml.sax.SAXParseException: >> s4s-att-not-allowed: Attribute 'default' cannot appear in element >> 'element'. at >> com.sun.xml.ws.server.ServerSchemaValidationTube.<init>(ServerSchemaV >> a >> lidationTube.java:69) >> at >> com.sun.xml.ws.api.pipe.ServerTubeAssemblerContext.createValidationTu >> b >> e(ServerTubeAssemblerContext.java:221) >> at >> weblogic.wsee.jaxws.tubeline.standard.StandardTubelineDeploymentListe >> n >> er$13.createServer(StandardTubelineDeploymentListener.java:158) >> at >> weblogic.wsee.jaxws.WLSTubelineAssemblerFactory$TubelineAssemblerImpl. >> createServer(WLSTubelineAssemblerFactory.java:105) >> at >> com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:158) >> at >> weblogic.wsee.jaxws.WLSContainer$WLSEndpointFactory$WLSEndpointImpl. >> nit>(WLSContainer.java:413) >> at '' >> >> This is getting a little frustrating. I guess I am going to try >> going back to including the webservies-*.jar files and using >> saaj-impl-3.2.jar from Sun instead of 3.1 version. I noticed the 3.2 >> version contains a META-INF\services directory with some factory >> classes while the 3.1 version I was using does not. I am hoping this >> solves the problem. >> >> >> >> -----Original Message----- >> From: Carl Roberts [mailto:[hidden email]] >> Sent: Friday, July 10, 2009 8:58 AM >> To: [hidden email] >> Cc: [hidden email] >> Subject: RE: Deploying to Weblogic 10.3.1 >> >> Hi Glen, >> >> Thanks for your response. Much appreciated. I tried your package >> names per the link you gave me instead of mine. Here are the ones I >> am using >> now: >> >> <package-name>com.sun.xml.*</package-name> >> <package-name>javax.xml.bind.*</package-name> >> >> But I am back to a different error that I saw before: >> >> Message icon - Error An error occurred during activation of changes, >> please see the log for details. >> Message icon - Error weblogic.application.ModuleException: >> Message icon - Error >> com.sun.xml.internal.messaging.saaj.soap.LocalStrings >> != com.sun.xml.messaging.saaj.soap.LocalStrings >> >> I noticed the saaj-impl namespace is also com.sun.xml.* so I am >> wondering if it has to do with this. >> >> I have also tried including the saaj-impl-1.3.jar file in the >> WEB-INF\lib directory of the war inside the ear and redeploying but I >> get the same error. Have you seen this error before? >> >> Do you have a sample ear file that you used for testing that I could >> try to deploy on my instance of Weblogic Server 10.3.1? >> >> Thanks, >> >> Joe >> >> -----Original Message----- >> From: Glen Mazza [mailto:[hidden email]] >> Sent: Thursday, July 09, 2009 7:03 PM >> To: [hidden email] >> Subject: RE: Deploying to Weblogic 10.3.1 >> >> >> I used somewhat different <p-a-p/s>--perhaps my list would help: >> http://www.jroller.com/gmazza/entry/deploying_metro_and_cxf_based >> >> Glen >> >> >> Carl Roberts wrote: >>> >>> <prefer-application-packages> >>> >>> <package-name>javax.jws.*</package-name> >>> >>> <package-name>javax.xml.soap.*</package-name> >>> >>> </prefer-application-packages> >>> >>> </weblogic-application> >>> >>> The deployment process in Weblogic then complains that my service >>> implementation class does not have @WebService or >>> @WebServiceProvider annotation, but it does: >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p2441929 >> 0 .html Sent from the Metro - Users mailing list archive at >> Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> > > -- > View this message in context: > http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24430825 > .html Sent from the Metro - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > -- View this message in context: http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24434406.html Sent from the Metro - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Re: Deploying to Weblogic 10.3.1
|
|
Hello Joe,
does your weblogic.wsee.jaxws.WLSTubelineAssemblerFactory extend from com.sun.xml.ws.api.pipe.TubelineAssemblerFactory? If not, that could be the reason for the class cast exception. Also, make sure that the weblogic.wsee.jaxws.WLSTubelineAssemblerFactory has an empty public constructor. Hope it helps. Thanks, Marek On 13.7.2009, at 18:20, Carl Roberts wrote: > Here is a better description of the error: > > Jul 13, 2009 12:12:38 PM > com.sun.xml.ws.transport.http.servlet.WSServletContextListener > contextInitialized > SEVERE: WSSERVLET11: failed to parse runtime descriptor: > com.sun.xml.ws.util.ServiceConfigurationError: com.sun.xml.ws.a > pi.pipe.TubelineAssemblerFactory: Provider > weblogic.wsee.jaxws.WLSTubelineAssemblerFactory is specified in > jar:file:/C:/ > oracle/Middleware/home_LOAD16F/wlserver_10.3/server/lib/ > weblogic.jar!/META-INF/services/com.sun.xml.ws.api.pipe.Tubeline > AssemblerFactory but could not be instantiated: > java.lang.ClassCastException > com.sun.xml.ws.util.ServiceConfigurationError: > com.sun.xml.ws.api.pipe.TubelineAssemblerFactory: Provider > weblogic.wsee. > jaxws.WLSTubelineAssemblerFactory is specified in jar:file:/C:/ > oracle/Middleware/home_LOAD16F/wlserver_10.3/server/lib/w > eblogic.jar!/META-INF/services/ > com.sun.xml.ws.api.pipe.TubelineAssemblerFactorybut could not be > instantiated: java.lang. > ClassCastException > > Please let me know if you guys have seen this or if you have any > suggestions? > > Thanks, > > Joe > > -----Original Message----- > From: Carl Roberts [mailto:[hidden email]] > Sent: Monday, July 13, 2009 12:00 PM > To: [hidden email]; [hidden email] > Subject: RE: Deploying to Weblogic 10.3.1 > > Just FYI, > > I got past the error. My Web method was missing the @Oneway > annotation. Strangely enough, it still works on Tomcat without it > but it is a no-no when deploying under Weblogic. > > I am running into another now: > > Caused by: java.lang.ClassCastException: > at java.lang.Class.cast(Class.java:2990) > at com.sun.xml.ws.util.ServiceFinder > $LazyIterator.next(ServiceFinder.java:374) > at > com > .sun > .xml > .ws > .api > .pipe.TubelineAssemblerFactory.create(TubelineAssemblerFactory.java: > 104) > at com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java: > 159) > at > com > .sun > .xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java: > 229) > at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:504) > at > com > .sun > .xml > .ws > .transport > .http > .DeploymentDescriptorParser > .parseAdapters(DeploymentDescriptorParser.java:253) > at > com > .sun > .xml > .ws > .transport > .http > .DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147) > at > com > .sun > .xml > .ws > .transport > .http > .servlet > .WSServletContextListener > .contextInitialized(WSServletContextListener.java:108) > at weblogic.servlet.internal.EventsManager > $FireContextListenerAction.run(EventsManager.java:465) > at > weblogic > .security > .acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) > at > weblogic.security.service.SecurityManager.runAs(SecurityManager.java: > 121) > at > weblogic > .servlet > .internal.EventsManager.notifyContextCreatedEvent(EventsManager.java: > 175) > at > weblogic > .servlet > .internal > .WebAppServletContext.preloadResources(WebAppServletContext.java:1799) > at > weblogic > .servlet > .internal.WebAppServletContext.start(WebAppServletContext.java:3041) > at > weblogic > .servlet.internal.WebAppModule.startContexts(WebAppModule.java:1374) > > I will try to resolve that one and then send an update with all the > steps required to deploy on Weblogic 10.3.1.0. > > Thanks, > > Joe > > -----Original Message----- > From: Carl Roberts [mailto:[hidden email]] > Sent: Monday, July 13, 2009 11:31 AM > To: '[hidden email]'; '[hidden email]' > Subject: RE: Deploying to Weblogic 10.3.1 > > Just FYI, > > I added a call to print the Xalan version from the same method: > > void freeze(WSDLPortImpl portType) { > this.wsdlOperation = portType.getBinding().get(new > QName > (portType > .getBinding > ().getPortType().getName().getNamespaceURI(),operationName)); > // TODO: replace this with proper error handling > if(wsdlOperation ==null) > throw new Error("Undefined operation name "+operationName); > > PrintWriter writer = new PrintWriter(System.out); > > boolean environmentOK = (new EnvironmentCheck()).checkEnvironment > (writer); > > System.out.println(environmentOK); > > System.out.println("*****Freeze <" + operationName + ">"); > > //so far, the inputAction, outputAction and fault actions are > set from the @Action and @FaultAction > //set the values from WSDLModel, if such annotations are not > present or defaulted > if(inputAction.equals("")) { > inputAction = > wsdlOperation.getOperation().getInput().getAction(); > } else if(! > inputAction > .equals(wsdlOperation.getOperation().getInput().getAction())) > //TODO input action might be from @Action or > WebMethod(action) > LOGGER.warning("Input Action from WSDL definitions > and @Action for operation .... did not match, and willc ause > problems in dispatching the requests"); > > if (!mep.isOneWay()) { > if (outputAction.equals("")){ > > WSDLOperationImpl op = wsdlOperation.getOperation(); > if (op == null){ > System.out.println("*****op is NULL"); > } > WSDLOutputImpl output = op.getOutput(); > if (output == null){ > System.out.println("*****output is NULL"); > } > outputAction = output.getAction(); > } > > for (CheckedExceptionImpl ce : exceptions) { > if (ce.getFaultAction().equals("")) { > QName detailQName = ce.getDetailType().tagName; > > ce > .setFaultAction > (wsdlOperation.getOperation().getFault(detailQName).getAction()); > } > } > } > } > > which prints this so it appears the code is using Xalan 2.7.1? > > version.JAXP=1.1 or higher > java.ext.dirs=C:\jdk1.6.0_14\jre\lib\ext;C:\WINDOWS\Sun\Java\lib\ext > version.xerces2=Xerces-J 2.9.0 > version.xerces1=not-present > version.xalan2_2=Xalan Java 2.7.1 > version.xalan1=not-present > version.ant=Apache Ant version 1.7.0 compiled on December 13 2006 > java.version=1.6.0_14 > version.DOM=2.0 > version.crimson=not-present > sun.boot.class.path=C:\jdk1.6.0_14\jre\lib\resources.jar;C: > \jdk1.6.0_14\jre\lib\ > rt.jar;C:\jdk1.6.0_14\jre\lib\sunrsasign.jar;C:\jdk1.6.0_14\jre\lib > \jsse.jar;C:\ > jdk1.6.0_14\jre\lib\jce.jar;C:\jdk1.6.0_14\jre\lib\charsets.jar;C: > \jdk1.6.0_14\j > re\classes > version.SAX=2.0 > version.xalan2x=Xalan Java 2.7.1 > #----- END writeEnvironmentReport: Useful properties found: ----- # > YAHOO! Your environment seems to be OK. > true > *****Freeze <doCallIDSOneWay> > > > > > -----Original Message----- > From: Carl Roberts [mailto:[hidden email]] > Sent: Monday, July 13, 2009 10:49 AM > To: '[hidden email]'; '[hidden email]' > Subject: RE: Deploying to Weblogic 10.3.1 > > Here is the output from the console: > > <Jul 13, 2009 10:41:58 AM EDT> <Warning> <netuix> <BEA-423420> > <Redirect is exec uted in begin or refresh action. Redirect url is / > console/console.portal?_nfpb=t > rue&_pageLabel=AppDeploymentsControlPage.> > *****Freeze <doCallIDS> > *****Freeze <doCallIDSOneWay> > *****output is NULL > Jul 13, 2009 10:43:10 AM > com.sun.xml.ws.transport.http.servlet.WSServletContextL > istener contextInitialized > SEVERE: WSSERVLET11: failed to parse runtime descriptor: > java.lang.NullPointerEx ception java.lang.NullPointerException > at > com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java:375) > at > com.sun.xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl > > > -----Original Message----- > From: Carl Roberts [mailto:[hidden email]] > Sent: Monday, July 13, 2009 10:48 AM > To: '[hidden email]'; '[hidden email]' > Subject: RE: Deploying to Weblogic 10.3.1 > > Sorry, > > Forgot to mention the actual class that contains the code: > > com.sun.xml.ws.model.JavaMethodImpl > > -----Original Message----- > From: Carl Roberts [mailto:[hidden email]] > Sent: Monday, July 13, 2009 10:47 AM > To: '[hidden email]' > Subject: RE: Deploying to Weblogic 10.3.1 > > You are right Glen, I debugged the code and the issue is related to > this function (I added some System.out.println statements): > > > /*package*/ void freeze(WSDLPortImpl portType) { > this.wsdlOperation = portType.getBinding().get(new > QName > (portType > .getBinding > ().getPortType().getName().getNamespaceURI(),operationName)); > // TODO: replace this with proper error handling > if(wsdlOperation ==null) > throw new Error("Undefined operation name "+operationName); > > //so far, the inputAction, outputAction and fault actions are > set from the @Action and @FaultAction > //set the values from WSDLModel, if such annotations are not > present or defaulted > if(inputAction.equals("")) { > inputAction = > wsdlOperation.getOperation().getInput().getAction(); > } else if(! > inputAction > .equals(wsdlOperation.getOperation().getInput().getAction())) > //TODO input action might be from @Action or > WebMethod(action) > LOGGER.warning("Input Action from WSDL definitions > and @Action for operation .... did not match, and willc ause > problems in dispatching the requests"); > > if (!mep.isOneWay()) { > if (outputAction.equals("")) > > WSLDOperationImpl op = wsdlOperation.getOperation(); > if (op == null){ > System.out.println("*****op is NULL"); > } > WSDLOutputImpl output = op.getOutput(); > if (output == null){ > System.out.println("*****output is NULL"); > } > outputAction = output.getAction(); > > for (CheckedExceptionImpl ce : exceptions) { > if (ce.getFaultAction().equals("")) { > QName detailQName = ce.getDetailType().tagName; > > ce > .setFaultAction > (wsdlOperation.getOperation().getFault(detailQName).getAction()); > } > } > } > } > > From the output in the console right before the NPE is thrown, it > looks like the code in metro is processing doCallIDSOneWay which has > no output operation defined in the WSDL: > > <wsdl:operation name="doCallIDSOneWay"> > <wsdl:input message="tns:DoCallIDSOneWayRequest" > wsaw:Action="doCallIDSOneWay"/> > </wsdl:operation> > > > But the code above seems to be failing on the check !mep.isOneWay() > and tries to get the output for it and throws the NPE, so it looks > like running on WebLogic the behavior is different, probably because > of the XML parsing. BTW, I tried to place the lates xalan jars in > the WEB-INF\Lib directory and modifying the weblogic-applcation.xml > file to use: > > <package-name>javax.xml.*</package-name> > > Instead of > > <package-name>javax.xml.bind.*</package-name> > > But then I get this error: > > com.ctc.wstx.stax.WstxInputFactory cannot be cast to > javax.xml.stream.XMLInputFactory > > > -----Original Message----- > From: Glen Mazza [mailto:[hidden email]] > Sent: Friday, July 10, 2009 5:10 PM > To: [hidden email] > Subject: RE: Deploying to Weblogic 10.3.1 > > > No--I don't think Metro cares about that display-name/description > stuff--the NPE you're getting with Metro you would probably be > getting anyway if Weblogic could handle the display-name/description > tags at the location you are placing them. > > I'm guessing that the display-name/description stuff really *is* > invalid with respect to the schema of the particular web.xml you're > using, which is proving an unnecessary distraction to your problem. > First make sure you indeed have a schema-valid web.xml (those two > tags are mostly noise under <servlet> anyway--you don't need them) > before proceeding. > > There's a slight chance the Xerces in use by Weblogic is old--that > can sometimes cause wacky things to happen, you may want to override > it with the latest Xerces, but I guess I would be grasping at straws > here at this stage. > > Glen > > > Carl Roberts wrote: >> >> OK, >> >> I've gotten a little further by doing this: >> >> I replaced the Sun JVM used by Weblogic Server 10.3.1 from version >> 1.6 >> build 11 to 1.6 build 14 and this resolved the error: >> >> com.sun.xml.internal.messaging.saaj.soap.LocalStrings >>> != com.sun.xml.messaging.saaj.soap.LocalStrings >> >> However, I am now running into another error which I think stems from >> the fact that the following two schemas don't support the >> <display-name> or <description> elements under the <servlet> element >> of a web deployment descriptor (web.xml): >> >> >> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd >> >> http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd >> >> >> Here is what works in Metro and Tomcat (section of web.xml): >> >> <servlet> >> <servlet-name>DocumentServiceSoap11</servlet-name> >> <display-name>DocumentServiceSoap11</display-name> >> <description>DocumentService SOAP 1.1</description> >> >> <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</ >> servlet-class> >> <load-on-startup>1</load-on-startup> >> </servlet> >> >> However, when I use Weblogic and try to deploy using the same entries >> in the web.xml I get this: >> >> Message icon - Error An error occurred during activation of changes, >> please see the log for details. >> Message icon - Error >> [HTTP:101064] >> [WebAppModule(DocumentServiceImplSoap11:DocumentServiceIm >> plSoap11)] Error parsing descriptor in Web appplication >> "C:\oracle\Middleware\home_LOAD16F\user_projects\domains >> \domain1\servers\AdminServer\tmp\_WL_user >> \DocumentServiceImplSoap11\cvh7s\com\oracle\webservices >> \documentservice\server\DocumentServiceImplSoap11.war" >> weblogic.application.ModuleException: VALIDATION PROBLEMS WERE FOUND >> problem: cvc-complex-type.2.4a: Expected elements >> 'servlet-class@http://java.sun.com/xml/ns/javaee >> jsp-file@http://java.sun.com/xml/ns/javaee' instead of >> 'display-name@http://java.sun.com/xml/ns/javaee' here in element >> servlet@http://java.sun.com/xml/ns/javaee:<null> problem: >> cvc-complex-type.2.4a: Expected elements >> 'servlet-class@http://java.sun.com/xml/ns/javaee >> jsp-file@http://java.sun.com/xml/ns/javaee' instead of >> 'description@http://java.sun.com/xml/ns/javaee' here in element >> servlet@http://java.sun.com/xml/ns/javaee:<null> at >> weblogic >> .servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav >> a:1201) at >> weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:335) >> at >> weblogic >> .application.internal.flow.ScopedModuleDriver.prepare(ScopedMo >> duleDriver.java:176) >> at >> weblogic >> .application.internal.flow.ModuleListenerInvoker.prepare(Modul >> eListenerInvoker.java:93) >> at >> weblogic.application.internal.flow.DeploymentCallbackFlow >> $1.next(Deplo >> ymentCallbackFlow.java:387) >> at >> weblogic >> .application.utils.StateMachineDriver.nextState(StateMachineDr >> iver.java:37) >> at >> weblogic >> .application.internal.flow.DeploymentCallbackFlow.prepare(Depl >> oymentCallbackFlow.java:58) >> at >> weblogic >> .application.internal.flow.DeploymentCallbackFlow.prepare(Depl >> oymentCallbackFlow.java:42) >> at >> weblogic.application.internal.BaseDeployment >> $1.next(BaseDeployment.jav >> a:609) >> at >> weblogic >> .application.utils.StateMachineDriver.nextState(StateMachineDr >> iver.java:37) >> at >> weblogic >> .application.internal.BaseDeployment.prepare(BaseDeployment.ja >> va:185) >> at >> weblogic >> .application.internal.EarDeployment.prepare(EarDeployment.java >> :53) >> at >> weblogic >> .application.internal.DeploymentStateChecker.prepare(Deploymen >> tStateChecker.java:154) >> at >> weblogic >> .deploy.internal.targetserver.AppContainerInvoker.prepare(AppC >> ontainerInvoker.java:60) >> at >> weblogic >> .deploy.internal.targetserver.operations.ActivateOperation.cre >> ateAndPrepareContainer(ActivateOperation.java:197) >> at >> weblogic >> .deploy.internal.targetserver.operations.ActivateOperation.doP >> repare(ActivateOperation.java:89) >> at >> weblogic >> .deploy.internal.targetserver.operations.AbstractOperation.pre >> pare(AbstractOperation.java:217) >> at >> weblogic >> .deploy.internal.targetserver.DeploymentManager.handleDeployme >> ntPrepare(DeploymentManager.java:747) >> at >> weblogic >> .deploy.internal.targetserver.DeploymentManager.prepareDeploym >> entList(DeploymentManager.java:1216) >> at >> weblogic >> .deploy.internal.targetserver.DeploymentManager.handlePrepare( >> DeploymentManager.java:250) >> at >> weblogic >> .deploy.internal.targetserver.DeploymentServiceDispatcher.prep >> are(DeploymentServiceDispatcher.java:159) >> at >> weblogic >> .deploy.service.internal.targetserver.DeploymentReceiverCallba >> ckDeliverer >> .doPrepareCallback(DeploymentReceiverCallbackDeliverer.java >> :157) >> at >> weblogic >> .deploy.service.internal.targetserver.DeploymentReceiverCallba >> ckDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12) >> at >> weblogic >> .deploy.service.internal.targetserver.DeploymentReceiverCallba >> ckDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45) >> at >> weblogic.work.SelfTuningWorkManagerImpl >> $WorkAdapterImpl.run(SelfTuning >> WorkManagerImpl.java:516) at >> weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at >> weblogic.work.ExecuteThread.run(ExecuteThread.java:173) Caused by: >> weblogic.descriptor.DescriptorException: VALIDATION PROBLEMS WERE >> FOUND >> problem: cvc-complex-type.2.4a: Expected elements >> 'servlet-class@http://java.sun.com/xml/ns/javaee >> jsp-file@http://java.sun.com/xml/ns/javaee' instead of >> 'display-name@http://java.sun.com/xml/ns/javaee' here in element >> servlet@http://java.sun.com/xml/ns/javaee:<null> problem: >> cvc-complex-type.2.4a: Expected elements >> 'servlet-class@http://java.sun.com/xml/ns/javaee >> jsp-file@http://java.sun.com/xml/ns/javaee' instead of >> 'description@http://java.sun.com/xml/ns/javaee' here in element >> servlet@http://java.sun.com/xml/ns/javaee:<null> at >> weblogic.descriptor.internal.MarshallerFactory >> $1.evaluateResults(Marsh >> allerFactory.java:241) >> at >> weblogic.descriptor.internal.MarshallerFactory >> $1.evaluateResults(Marsh >> allerFactory.java:228) >> at >> weblogic.descriptor.internal.MarshallerFactory >> $1.createDescriptor(Mars >> hallerFactory.java:153) >> at >> weblogic >> .descriptor.BasicDescriptorManager.createDescriptor(BasicDescr >> iptorManager.java:323) >> at >> weblogic >> .application.descriptor.AbstractDescriptorLoader2.getDescripto >> rBeanFromReader(AbstractDescriptorLoader2.java:788) >> at >> weblogic >> .application.descriptor.AbstractDescriptorLoader2.createDescri >> ptorBean(AbstractDescriptorLoader2.java:409) >> at >> weblogic >> .application.descriptor.AbstractDescriptorLoader2.loadDescript >> orBeanWithoutPlan(AbstractDescriptorLoader2.java:759) >> at >> weblogic >> .application.descriptor.AbstractDescriptorLoader2.loadDescript >> orBean(AbstractDescriptorLoader2.java:768) >> at >> weblogic >> .servlet.internal.WebAppDescriptor.getWebAppBean(WebAppDescrip >> tor.java:141) >> at >> weblogic >> .servlet.internal.WebAppModule.loadDescriptor(WebAppModule.jav >> a:1193) ... 26 more weblogic.application.ModuleException: VALIDATION >> PROBLEMS WERE FOUND problem: cvc-complex-type.2.4a: Expected elements >> 'servlet-class@http://java.sun.com/xml/ns/javaee >> jsp-file@http://java.sun.com/xml/ns/javaee' instead of >> 'display-name@http://java.sun.com/xml/ns/javaee' here in element >> servlet@http://java.sun.com/xml/ns/javaee:<null> problem: >> cvc-complex-type.2.4a: Expected elements >> 'servlet-class@http://java.sun.com/xml/ns/javaee >> jsp-file@http://java.sun.com/xml/ns/javaee' instead of >> 'description@http://java.sun.com/xml/ns/javaee' here in element >> servlet@http://java.sun.com/xml/ns/javaee:<null> >> Message icon - Error VALIDATION PROBLEMS WERE FOUND problem: >> cvc-complex-type.2.4a: Expected elements >> 'servlet-class@http://java.sun.com/xml/ns/javaee >> jsp-file@http://java.sun.com/xml/ns/javaee' instead of >> 'display-name@http://java.sun.com/xml/ns/javaee' here in element >> servlet@http://java.sun.com/xml/ns/javaee:<null> problem: >> cvc-complex-type.2.4a: Expected elements >> 'servlet-class@http://java.sun.com/xml/ns/javaee >> jsp-file@http://java.sun.com/xml/ns/javaee' instead of >> 'description@http://java.sun.com/xml/ns/javaee' here in element >> servlet@http://java.sun.com/xml/ns/javaee:<null> >> >> >> >> So it appears that Tomcat does no validation against the web.xml but >> J2EE containers do (are required) and cannot validate the web.xml >> with >> the <display-name> and <description> elements. If I take out these >> elements then validation succeeds in Weblogic but then Metro throws >> this exception: >> >> ####<Jul 10, 2009 4:24:09 PM EDT> <Error> <Console> <idocumaker> >> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: >> 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <> >> <1247257449500> <BEA-240003> <Console encountered the following error >> weblogic.application.ModuleException: >> at >> weblogic >> .servlet.internal.WebAppModule.startContexts(WebAppModule.java:1376) >> at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java: >> 452) >> at >> weblogic.application.internal.flow.ModuleStateDriver >> $3.next(ModuleStateDriver.java:204) >> at >> weblogic >> .application >> .utils.StateMachineDriver.nextState(StateMachineDriver.java:37) >> 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:37) >> at >> weblogic >> .application >> .internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60) >> at >> weblogic >> .application >> .internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27) >> at >> weblogic.application.internal.BaseDeployment >> $2.next(BaseDeployment.java:629) >> at >> weblogic >> .application >> .utils.StateMachineDriver.nextState(StateMachineDriver.java:37) >> at >> weblogic >> .application.internal.BaseDeployment.activate(BaseDeployment.java: >> 206) >> at >> weblogic >> .application.internal.EarDeployment.activate(EarDeployment.java:53) >> at >> weblogic >> .application >> .internal >> .DeploymentStateChecker.activate(DeploymentStateChecker.java:161) >> at >> weblogic >> .deploy >> .internal >> .targetserver.AppContainerInvoker.activate(AppContainerInvoker.java: >> 79) >> at >> weblogic >> .deploy >> .internal >> .targetserver >> .operations.AbstractOperation.activate(AbstractOperation.java:569) >> at >> weblogic >> .deploy >> .internal >> .targetserver >> .operations >> .ActivateOperation.activateDeployment(ActivateOperation.java:140) >> at >> weblogic >> .deploy >> .internal >> .targetserver >> .operations.ActivateOperation.doCommit(ActivateOperation.java:106) >> at >> weblogic >> .deploy >> .internal >> .targetserver >> .operations.AbstractOperation.commit(AbstractOperation.java:323) >> at >> weblogic >> .deploy >> .internal >> .targetserver >> .DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844) >> at >> weblogic >> .deploy >> .internal >> .targetserver >> .DeploymentManager.activateDeploymentList(DeploymentManager.java: >> 1253) >> at >> weblogic >> .deploy >> .internal >> .targetserver.DeploymentManager.handleCommit(DeploymentManager.java: >> 440) >> at >> weblogic >> .deploy >> .internal >> .targetserver >> .DeploymentServiceDispatcher >> .commit(DeploymentServiceDispatcher.java:163) >> at >> weblogic >> .deploy >> .service >> .internal >> .targetserver >> .DeploymentReceiverCallbackDeliverer >> .doCommitCallback(DeploymentReceiverCallbackDeliverer.java:181) >> at >> weblogic >> .deploy >> .service >> .internal.targetserver.DeploymentReceiverCallbackDeliverer.access >> $100(DeploymentReceiverCallbackDeliverer.java:12) >> at >> weblogic >> .deploy >> .service.internal.targetserver.DeploymentReceiverCallbackDeliverer >> $2.run(DeploymentReceiverCallbackDeliverer.java:67) >> at >> weblogic.work.SelfTuningWorkManagerImpl >> $WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516) >> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) >> at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) >> Caused by: java.lang.NullPointerException: >> at com.sun.xml.ws.model.JavaMethodImpl.freeze(JavaMethodImpl.java: >> 362) >> at >> com >> .sun >> .xml.ws.model.AbstractSEIModelImpl.freeze(AbstractSEIModelImpl.java: >> 104) >> at >> com >> .sun >> .xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java: >> 262) >> at >> com >> .sun >> .xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java: >> 335) >> at >> com >> .sun >> .xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java: >> 198) >> at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:504) >> at >> com >> .sun >> .xml >> .ws >> .transport >> .http >> .DeploymentDescriptorParser >> .parseAdapters(DeploymentDescriptorParser.java:253) >> at >> com >> .sun >> .xml >> .ws >> .transport >> .http >> .DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java: >> 147) >> at >> com >> .sun >> .xml >> .ws >> .transport >> .http >> .servlet >> .WSServletContextListener >> .contextInitialized(WSServletContextListener.java:108) >> at >> weblogic.servlet.internal.EventsManager >> $FireContextListenerAction.run(EventsManager.java:465) >> at >> weblogic >> .security >> .acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java: >> 321) >> at >> weblogic >> .security.service.SecurityManager.runAs(SecurityManager.java:121) >> at >> weblogic >> .servlet >> .internal >> .EventsManager.notifyContextCreatedEvent(EventsManager.java:175) >> at >> weblogic >> .servlet >> .internal >> .WebAppServletContext.preloadResources(WebAppServletContext.java: >> 1799) >> at >> weblogic >> .servlet >> .internal.WebAppServletContext.start(WebAppServletContext.java:3041) >> at >> weblogic >> .servlet.internal.WebAppModule.startContexts(WebAppModule.java >> :1374) >>> >> >> >> It seems to me this is a bug in Metro: >> >> If <display-name> and <description> aren't supported under the >> <servlet> element in the schemas for a web.xml, then why are we >> relying on them to be there and throwing a NullpointerException when >> they are not. At the very least they should be made optional. This >> way I can take them out in the web.xml when deploying to a J2EE >> container and not have to worry about Metro throwing this exception. >> It is possible I am missing some sort of crucial piece of information >> but I don't see that this elements are supported under the >> <servlet> element in the following two schemas: >> >> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd >> >> or >> >> http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd >> >> Please advise, >> >> Carl >> >> >> >> -----Original Message----- >> From: Glen Mazza [mailto:[hidden email]] >> Sent: Friday, July 10, 2009 12:35 PM >> To: [hidden email] >> Subject: RE: Deploying to Weblogic 10.3.1 >> >> >> Looking at your error stack, it appears that you're relying on >> BEAWLS' >> own jax-ws implementation (weblogic.wsee.jaxws...) instead of Metro. >> I might advise against removing the Metro jars from the WEB-INF/lib >> for that reason, but as that is not working for you either, I'm not >> sure what else to suggest other than trying CXF (which comes with no >> guarantees on BEAWLS >> either[1]) or switching to Glassfish or Tomcat. I'm pretty confident >> that Metro 2.0 will work on BEAWLS but simply don't know the >> <prefer-application-packages/> library overrides necessary for that >> to >> happen. >> >> Sorry, >> Glen >> >> [1] >> http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide- >> We >> bLogic >> >> >> Carl Roberts wrote: >>> >>> Thanks Glen, >>> >>> I will try your setup. >>> >>> BTW, since Oracle WebLogic claims to follow the Glassfish >>> implementation and I couldn't get any further with my previous >>> approach, I figured why not remove the metro webservices-*.jar files >>> from my WEB-INF\lib directory and just go with the Weblogic >>> implementation of Glassfish. Theoretically this should work. >>> >>> Well, >>> >>> I changed the web.xml to run the Implementation class directly by >>> commenting out the listener: >>> >>> <?xml version="1.0" encoding="UTF-8" ?> >>> - <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/j2ee"> >>> <display-name>DocumentServiceSoap11</display-name> >>> - <!-- >>> <listener> >>> >>> <listener- >>> class >>> >com.sun.xml.ws.transport.http.servlet.WSServletContextListener</ >>> listener-class> >>> </listener> >>> >>> >>> --> >>> - <servlet> >>> <servlet-name>DocumentServiceSoap11</servlet-name> >>> - <!-- >>> <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</ >>> servlet-class> >>> --> >>> >>> <servlet- >>> class >>> > >>> com.oracle.webservices.documentservice.server.DocumentServiceImpl</ >>> servlet-class> >>> <load-on-startup>0</load-on-startup> >>> </servlet> >>> - <servlet-mapping> >>> <servlet-name>DocumentServiceSoap11</servlet-name> >>> <url-pattern>/DocumentService</url-pattern> >>> </servlet-mapping> >>> - <session-config> >>> <session-timeout>60</session-timeout> >>> </session-config> >>> </web-app> >>> >>> And I am getting a little further I think, but now I am getting this >>> error, indicating the Weblogic schema validator is not up to par >>> with >>> Metro's 2.0 one, because it is complaining about default attribute >>> for xsd:element not being valid? Isn't default attribute for >>> xsd:element a standard attribute? It seems like a schema that >>> worked >>> fine before under tomcat now has problems under Weblogic. >>> >>> Here is the error from weblogic: >>> >>> Message icon - Error An error occurred during activation of changes, >>> please see the log for details. >>> Message icon - Error [HTTP:101216]Servlet: "DocumentServiceSoap11" >>> failed to preload on startup in Web application: >>> "DocumentServiceImpl". >>> javax.xml.ws.WebServiceException: org.xml.sax.SAXParseException: >>> s4s-att-not-allowed: Attribute 'default' cannot appear in element >>> 'element'. at >>> com >>> .sun.xml.ws.server.ServerSchemaValidationTube.<init>(ServerSchemaV >>> a >>> lidationTube.java:69) >>> at >>> com >>> .sun.xml.ws.api.pipe.ServerTubeAssemblerContext.createValidationTu >>> b >>> e(ServerTubeAssemblerContext.java:221) >>> at >>> weblogic >>> .wsee.jaxws.tubeline.standard.StandardTubelineDeploymentListe >>> n >>> er$13.createServer(StandardTubelineDeploymentListener.java:158) >>> at >>> weblogic.wsee.jaxws.WLSTubelineAssemblerFactory >>> $TubelineAssemblerImpl. >>> createServer(WLSTubelineAssemblerFactory.java:105) >>> at >>> com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:158) >>> at >>> weblogic.wsee.jaxws.WLSContainer$WLSEndpointFactory$WLSEndpointImpl. >>> nit>(WLSContainer.java:413) >>> at '' >>> >>> This is getting a little frustrating. I guess I am going to try >>> going back to including the webservies-*.jar files and using >>> saaj-impl-3.2.jar from Sun instead of 3.1 version. I noticed the >>> 3.2 >>> version contains a META-INF\services directory with some factory >>> classes while the 3.1 version I was using does not. I am hoping >>> this >>> solves the problem. >>> >>> >>> >>> -----Original Message----- >>> From: Carl Roberts [mailto:[hidden email]] >>> Sent: Friday, July 10, 2009 8:58 AM >>> To: [hidden email] >>> Cc: [hidden email] >>> Subject: RE: Deploying to Weblogic 10.3.1 >>> >>> Hi Glen, >>> >>> Thanks for your response. Much appreciated. I tried your package >>> names per the link you gave me instead of mine. Here are the ones I >>> am using >>> now: >>> >>> <package-name>com.sun.xml.*</package-name> >>> <package-name>javax.xml.bind.*</package-name> >>> >>> But I am back to a different error that I saw before: >>> >>> Message icon - Error An error occurred during activation of changes, >>> please see the log for details. >>> Message icon - Error weblogic.application.ModuleException: >>> Message icon - Error >>> com.sun.xml.internal.messaging.saaj.soap.LocalStrings >>> != com.sun.xml.messaging.saaj.soap.LocalStrings >>> >>> I noticed the saaj-impl namespace is also com.sun.xml.* so I am >>> wondering if it has to do with this. >>> >>> I have also tried including the saaj-impl-1.3.jar file in the >>> WEB-INF\lib directory of the war inside the ear and redeploying >>> but I >>> get the same error. Have you seen this error before? >>> >>> Do you have a sample ear file that you used for testing that I could >>> try to deploy on my instance of Weblogic Server 10.3.1? >>> >>> Thanks, >>> >>> Joe >>> >>> -----Original Message----- >>> From: Glen Mazza [mailto:[hidden email]] >>> Sent: Thursday, July 09, 2009 7:03 PM >>> To: [hidden email] >>> Subject: RE: Deploying to Weblogic 10.3.1 >>> >>> >>> I used somewhat different <p-a-p/s>--perhaps my list would help: >>> http://www.jroller.com/gmazza/entry/deploying_metro_and_cxf_based >>> >>> Glen >>> >>> >>> Carl Roberts wrote: >>>> >>>> <prefer-application-packages> >>>> >>>> <package-name>javax.jws.*</package-name> >>>> >>>> <package-name>javax.xml.soap.*</package-name> >>>> >>>> </prefer-application-packages> >>>> >>>> </weblogic-application> >>>> >>>> The deployment process in Weblogic then complains that my service >>>> implementation class does not have @WebService or >>>> @WebServiceProvider annotation, but it does: >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Deploying-to-Weblogic-10.3.1- >>> tp24415730p2441929 >>> 0 .html Sent from the Metro - Users mailing list archive at >>> Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [hidden email] >>> For additional commands, e-mail: [hidden email] >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [hidden email] >>> For additional commands, e-mail: [hidden email] >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [hidden email] >>> For additional commands, e-mail: [hidden email] >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Deploying-to-Weblogic-10.3.1- >> tp24415730p24430825 >> .html Sent from the Metro - Users mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> >> > > -- > View this message in context: http://www.nabble.com/Deploying-to-Weblogic-10.3.1-tp24415730p24434406.html > Sent from the Metro - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Re: Deploying to Weblogic 10.3.1
|
|
Hi Joe,
to me, it looks like you might inadvertently be mixing the JAX-WS RI build that comes with Weblogic and the independent Metro build you want to be using: How did you set up your classloading hierarchy? You must set things up in a way such that all classes from the independent Metro JARs override all JAX-WS RI classes from the weblocgic.jar. With older Weblogic versions like 8.1, I think there was a setting like "prefer-web-inf-classes" or so in the weblogic.xml of your web app. I don't know unfortunately how this must be done in WLS 10.x. But from your stack trace, you can see that Metro tries to load a TubelineAssemblerFactory implementation class named weblogic.wsee.jaxws.WLSTubelineAssemblerFactory because it finds this information in the C:/oracle/Middleware/home_LOAD16F/wlserver_10.3/server/lib/weblogic.jar!/META-INF/services/com.sun.xml.ws.api.pipe.TubelineAssemblerFactory which most probably is not what you intend: The weblogic.wsee.jaxws.* classes are loaded from a different classloader than "local" Metro classes provided with the web app and therefore reference a different copy of the TubelineAssemblerFactory from this different classloader... I would expect that you want the /META-INF/services/com.sun.xml.ws.api.pipe.TubelineAssemblerFactory from the independent Metro webservices-rt.jar bundled with your web app to be used instead. You have to check how to make this happen - most probably, there is still something wrong with your classloader hierarchy setup... Hope this helps & best regards, Andreas Note: As I am currently on an extended sick leave and will have to go back to the hospital later this week, I might not be able to reply further, but I hope that the above puts you on the right track... Potociar Marek schrieb: > Hello Joe, > does your weblogic.wsee.jaxws.WLSTubelineAssemblerFactory extend from > com.sun.xml.ws.api.pipe.TubelineAssemblerFactory? If not, that could be > the reason for the class cast exception. Also, make sure that the > weblogic.wsee.jaxws.WLSTubelineAssemblerFactory has an empty public > constructor. > > Hope it helps. > > Thanks, > Marek > > On 13.7.2009, at 18:20, Carl Roberts wrote: > >> Here is a better description of the error: >> >> Jul 13, 2009 12:12:38 PM >> com.sun.xml.ws.transport.http.servlet.WSServletContextListener >> contextInitialized >> SEVERE: WSSERVLET11: failed to parse runtime descriptor: >> com.sun.xml.ws.util.ServiceConfigurationError: com.sun.xml.ws.a >> pi.pipe.TubelineAssemblerFactory: Provider >> weblogic.wsee.jaxws.WLSTubelineAssemblerFactory is specified in >> jar:file:/C:/ >> oracle/Middleware/home_LOAD16F/wlserver_10.3/server/lib/weblogic.jar!/META-INF/services/com.sun.xml.ws.api.pipe.Tubeline >> >> AssemblerFactory but could not be instantiated: >> java.lang.ClassCastException >> com.sun.xml.ws.util.ServiceConfigurationError: >> com.sun.xml.ws.api.pipe.TubelineAssemblerFactory: Provider weblogic.wsee. >> jaxws.WLSTubelineAssemblerFactory is specified in >> jar:file:/C:/oracle/Middleware/home_LOAD16F/wlserver_10.3/server/lib/w >> eblogic.jar!/META-INF/services/com.sun.xml.ws.api.pipe.TubelineAssemblerFactorybut >> could not be instantiated: java.lang. >> ClassCastException >> >> Please let me know if you guys have seen this or if you have any >> suggestions? >> >> Thanks, >> >> Joe -- Andreas Loew Senior Java Architect Sun Microsystems (Germany) --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
RE: Deploying to Weblogic 10.3.1
|
|
Thanks Andreas and Marek, I will try to resolve this today. Your advice, as always, is much appreciated. Hope you get better Andreas...best of luck with everything at the hospital...:)
-----Original Message----- From: [hidden email] [mailto:[hidden email]] Sent: Tuesday, July 14, 2009 5:42 AM To: [hidden email] Subject: Re: Deploying to Weblogic 10.3.1 Hi Joe, to me, it looks like you might inadvertently be mixing the JAX-WS RI build that comes with Weblogic and the independent Metro build you want to be using: How did you set up your classloading hierarchy? You must set things up in a way such that all classes from the independent Metro JARs override all JAX-WS RI classes from the weblocgic.jar. With older Weblogic versions like 8.1, I think there was a setting like "prefer-web-inf-classes" or so in the weblogic.xml of your web app. I don't know unfortunately how this must be done in WLS 10.x. But from your stack trace, you can see that Metro tries to load a TubelineAssemblerFactory implementation class named weblogic.wsee.jaxws.WLSTubelineAssemblerFactory because it finds this information in the C:/oracle/Middleware/home_LOAD16F/wlserver_10.3/server/lib/weblogic.jar!/META-INF/services/com.sun.xml.ws.api.pipe.TubelineAssemblerFactory which most probably is not what you intend: The weblogic.wsee.jaxws.* classes are loaded from a different classloader than "local" Metro classes provided with the web app and therefore reference a different copy of the TubelineAssemblerFactory from this different classloader... I would expect that you want the /META-INF/services/com.sun.xml.ws.api.pipe.TubelineAssemblerFactory from the independent Metro webservices-rt.jar bundled with your web app to be used instead. You have to check how to make this happen - most probably, there is still something wrong with your classloader hierarchy setup... Hope this helps & best regards, Andreas Note: As I am currently on an extended sick leave and will have to go back to the hospital later this week, I might not be able to reply further, but I hope that the above puts you on the right track... Potociar Marek schrieb: > Hello Joe, > does your weblogic.wsee.jaxws.WLSTubelineAssemblerFactory extend from > com.sun.xml.ws.api.pipe.TubelineAssemblerFactory? If not, that could > be the reason for the class cast exception. Also, make sure that the > weblogic.wsee.jaxws.WLSTubelineAssemblerFactory has an empty public > constructor. > > Hope it helps. > > Thanks, > Marek > > On 13.7.2009, at 18:20, Carl Roberts wrote: > >> Here is a better description of the error: >> >> Jul 13, 2009 12:12:38 PM >> com.sun.xml.ws.transport.http.servlet.WSServletContextListener >> contextInitialized >> SEVERE: WSSERVLET11: failed to parse runtime descriptor: >> com.sun.xml.ws.util.ServiceConfigurationError: com.sun.xml.ws.a >> pi.pipe.TubelineAssemblerFactory: Provider >> weblogic.wsee.jaxws.WLSTubelineAssemblerFactory is specified in >> jar:file:/C:/ >> oracle/Middleware/home_LOAD16F/wlserver_10.3/server/lib/weblogic.jar! >> /META-INF/services/com.sun.xml.ws.api.pipe.Tubeline >> >> AssemblerFactory but could not be instantiated: >> java.lang.ClassCastException >> com.sun.xml.ws.util.ServiceConfigurationError: >> com.sun.xml.ws.api.pipe.TubelineAssemblerFactory: Provider weblogic.wsee. >> jaxws.WLSTubelineAssemblerFactory is specified in >> jar:file:/C:/oracle/Middleware/home_LOAD16F/wlserver_10.3/server/lib/ >> w >> eblogic.jar!/META-INF/services/com.sun.xml.ws.api.pipe.TubelineAssemb >> lerFactorybut could not be instantiated: java.lang. >> ClassCastException >> >> Please let me know if you guys have seen this or if you have any >> suggestions? >> >> Thanks, >> >> Joe -- Andreas Loew Senior Java Architect Sun Microsystems (Germany) --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
RE: Deploying to Weblogic 10.3.1
|
|
Ok,
I have this working in Weblogic 10.3.1. Basically I had to figure out a way to override the META-INF\services from weblogic.jar file without removing them from weblogic.jar file or touching the weblogic startup script as to not affect the application server globally with my changes to override the Oracle web services implementation of Glassfish with Metro's. This way, other services that wish to use Oracle's implementation still can. I looked at the code for ServiceFinder.java in Metro, since that is the class that was throwing the class cast exception. Basically this class was looking in META-INF\services using the ClassLoader getResources() method, which per the javadoc states that it does a resource lookup same as getResource() method, which asks the parent class loader first. So since webglogic.jar file was being loaded first, I think this explains why the WEB-INF\services entries in weblogic.jar file were winning over the ones in webservices-rt.jar. So, as a workaround, in my ear file, I copied the META-INF\services directory from webservices-rt.jar to earFile\META-INF\metro-services and I then renamed the lookup path inside ServiceFinder.java to be META-INF\metro-services instead of META-INF\services. This is the only way I could override the META-INF\services entries in weblogic.jar without touching that jar file or modifying the startup script for Weblogic. I also used this earFile\META-INF\weblogic-application.xml file: <?xml version='1.0' encoding='UTF-8'?> <weblogic-application xmlns="http://xmlns.oracle.com/weblogic/weblogic-application" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.0/weblogic-application.xsd"> <application-param> <param-name>webapp.encoding.default</param-name> <param-value>UTF-8</param-value> </application-param> <prefer-application-packages> <package-name>com.sun.xml.*</package-name> <package-name>javax.jws.*</package-name> <package-name>javax.xml.bind.*</package-name> <package-name>javax.xml.soap.*</package-name> <package-name>javax.xml.stream.*</package-name> <package-name>javax.xml.ws.*</package-name> <package-name>javax.xml.activation.*</package-name> <package-name>javax.xml.annotation.*</package-name> <package-name>javax.xml.mail.*</package-name> <package-name>javax.xml.security.*</package-name> <package-name>javax.xml.registry.*</package-name> <package-name>javax.xml.rpc.*</package-name> <package-name>javax.xml.crypto.*</package-name> <package-name>javanet.staxutils.*</package-name> <package-name>jp.gr.xml.*</package-name> <package-name>org.codehaus.stax2.*</package-name> <package-name>org.glassfish.gmbal.*</package-name> <package-name>org.iso_relax.*</package-name> <package-name>org.jcp.xml.dsig.*</package-name> <package-name>org.jvnet.*</package-name> <package-name>org.relaxng.*</package-name> </prefer-application-packages> </weblogic-application> I then copied the following jars under earFile\APP-INF\lib webservices-api.jar webservices-extra-api.jar webservices-extra.jar webservices-rt.jar webservices-tools.jar And the rest of the jars files under warFile\WEB-INF\lib And used this earFile\WEB-INF\weblogic.xml file: <?xml version='1.0' encoding='UTF-8'?> <weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd" xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app"> <container-descriptor> <prefer-web-inf-classes>true</prefer-web-inf-classes> </container-descriptor> </weblogic-web-app> So far mtom, fastinfoset, streaming, asynchronous client calls, oneway services, http compresion, an ws-addressing are working fine. I haven't began testing WS-Security, WS-Trust or WS-SecureConverstation on WebLogic or Tomcat yet but I am a little more optimistic now...:) --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
«
Return to Metro - Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |