be the reason for the class cast exception. Also, make sure that the
> 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]
>
Locked
