Deploying to Weblogic 10.3.1

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Deploying to Weblogic 10.3.1

Carl Roberts

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

> 

Reply | Threaded
Open this post in threaded view
|

Re: Deploying to Weblogic 10.3.1

Harold Carr
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]

Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Carl Roberts
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]]
Sent: Thursday, July 09, 2009 2:49 PM
To: '[hidden email]'
Subject: Deploying to Weblogic 10.3.1

 

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

> 

Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Glen Mazza
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:
Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Carl Roberts
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]

Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Glen Mazza
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

Carl Roberts wrote
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:glen.mazza@gmail.com]
Sent: Thursday, July 09, 2009 7:03 PM
To: users@metro.dev.java.net
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: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net
Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Carl Roberts
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]

Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Glen Mazza
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> 
-  
- <servlet>
  <servlet-name>DocumentServiceSoap11</servlet-name> 
-  
  <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:carl.roberts@oracle.com]
Sent: Friday, July 10, 2009 8:58 AM
To: glen.mazza@gmail.com
Cc: users@metro.dev.java.net
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:glen.mazza@gmail.com]
Sent: Thursday, July 09, 2009 7:03 PM
To: users@metro.dev.java.net
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: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net
Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Carl Roberts
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]

Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Glen Mazza
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: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:glen.mazza@gmail.com]
Sent: Friday, July 10, 2009 12:35 PM
To: users@metro.dev.java.net
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>
> -
> - <servlet>
>   <servlet-name>DocumentServiceSoap11</servlet-name>
> -
>
> <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. 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:carl.roberts@oracle.com]
> Sent: Friday, July 10, 2009 8:58 AM
> To: glen.mazza@gmail.com
> Cc: users@metro.dev.java.net
> 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:glen.mazza@gmail.com]
> Sent: Thursday, July 09, 2009 7:03 PM
> To: users@metro.dev.java.net
> 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: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net
>
>
>

--
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: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net
Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Carl Roberts
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]

Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Carl Roberts
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]

Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Carl Roberts
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]

Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Carl Roberts
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]

Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Carl Roberts
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]

Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Carl Roberts
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]

Reply | Threaded
Open this post in threaded view
|

Re: Deploying to Weblogic 10.3.1

Potociar Marek
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]

Reply | Threaded
Open this post in threaded view
|

Re: Deploying to Weblogic 10.3.1

Andreas Loew
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]

Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Carl Roberts
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]

Reply | Threaded
Open this post in threaded view
|

RE: Deploying to Weblogic 10.3.1

Carl Roberts
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]

12