subject:"Re\: websphere web service deployment problem"

Re: websphere web service deployment problem

2007-09-28 Thread Jean-Sebastien Delfino


Radim Kolarik wrote:

Hi,

just wanted you to know that I have managed to solve the problem now.
It was all about other files, which were on our classpath and which
were not supposed to be there (our product jars). That caused
classloader to load classes where they were not supposed to be loaded.

The problem doesn't appear anymore.

Thanks,
Radim
  


That's good news, as I was not able to reproduce the issue in my 
environment... I had tweaked a test case to do a "new InitialContext()" 
similar to what I saw in your stack trace, and it was working for me :)


Thanks

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-28 Thread Radim Kolarik

Hi,

just wanted you to know that I have managed to solve the problem now.
It was all about other files, which were on our classpath and which
were not supposed to be there (our product jars). That caused
classloader to load classes where they were not supposed to be loaded.

The problem doesn't appear anymore.

Thanks,
Radim

On 9/28/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am suspecting that this has something to do with the application
> settings "change classloader properties of your Webapp to parent-last
> / single". Have anyone been able to reproduce the problem?
>
> Sebastian, did you have a chance to have a look if there is anything wrong?
>
> Thanks a lot,
> Radim
>
> On 9/27/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> > Hi Sebastien,
> >
> > You are right, I mean the "change classloader properties of your Webapp
> > to parent-last / single" update.
> >
> > I am calling the AdminService.getAttribute() from the web app, server
> > itself starts without problems.
> >
> > Here is the complete stack trace:
> >
> > java.lang.ClassCastException:
> > org.apache.xerces.jaxp.SAXParserFactoryImpl incompatible with
> > javax.xml.parsers.SAXParserFactory
> >at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source)
> >at 
> > org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.makeParser(XMLLoadImpl.java:299)
> >at 
> > org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:140)
> >at 
> > org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:179)
> >at 
> > org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.basicDoLoad(CompatibilityXMIResourceImpl.java:180)
> >at 
> > org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.doLoad(CompatibilityXMIResourceImpl.java:173)
> >at 
> > org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1094)
> >at 
> > org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:900)
> >at 
> > org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.load(CompatibilityXMIResourceImpl.java:259)
> >at 
> > com.ibm.websphere.resource.WASResourceImpl.load(WASResourceImpl.java:61)
> >at 
> > org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:249)
> >at 
> > org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:264)
> >at 
> > org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:390)
> >at 
> > com.ibm.websphere.resource.WASResourceSetImpl.getResource(WASResourceSetImpl.java:158)
> >at 
> > com.ibm.websphere.resource.WASResourceSetImpl.getResource(WASResourceSetImpl.java:143)
> >at 
> > com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:325)
> >at 
> > com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:298)
> >at 
> > com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:274)
> >at 
> > com.ibm.ws.runtime.component.EndPointMgrImpl.getNodeHostName(EndPointMgrImpl.java:488)
> >at 
> > com.ibm.ws.management.AdminHelperImpl.getNodeHostName(AdminHelperImpl.java:116)
> >at 
> > com.ibm.ws.management.component.JVMMBean.getJVMNode(JVMMBean.java:167)
> >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >at 
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> >at 
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >at java.lang.reflect.Method.invoke(Method.java:615)
> >at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:62)
> >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >at 
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> >at 
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >at java.lang.reflect.Method.invoke(Method.java:615)
> >at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:265)
> >at 
> > javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1089)
> >at 
> > javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:971)
> >at 
> > javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBean.java:1373)
> >at 
> > com.sun.jmx.mbeanserver.DynamicMetaDataImpl.getAttribute(DynamicMetaDataImpl.java:114)
> >at 
> > com.sun.jmx.mbeanserver.MetaDataImpl.getAttribute(MetaDataImpl.java:199)
> >at 
> > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:656)
> >at 
> > com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:677)
> >at 
> > com.ibm.ws.management.AdminServiceImp

Re: websphere web service deployment problem

2007-09-28 Thread Radim Kolarik

Hi,

I am suspecting that this has something to do with the application
settings "change classloader properties of your Webapp to parent-last
/ single". Have anyone been able to reproduce the problem?

Sebastian, did you have a chance to have a look if there is anything wrong?

Thanks a lot,
Radim

On 9/27/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> Hi Sebastien,
>
> You are right, I mean the "change classloader properties of your Webapp
> to parent-last / single" update.
>
> I am calling the AdminService.getAttribute() from the web app, server
> itself starts without problems.
>
> Here is the complete stack trace:
>
> java.lang.ClassCastException:
> org.apache.xerces.jaxp.SAXParserFactoryImpl incompatible with
> javax.xml.parsers.SAXParserFactory
>at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source)
>at 
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.makeParser(XMLLoadImpl.java:299)
>at 
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:140)
>at 
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:179)
>at 
> org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.basicDoLoad(CompatibilityXMIResourceImpl.java:180)
>at 
> org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.doLoad(CompatibilityXMIResourceImpl.java:173)
>at 
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1094)
>at 
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:900)
>at 
> org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.load(CompatibilityXMIResourceImpl.java:259)
>at 
> com.ibm.websphere.resource.WASResourceImpl.load(WASResourceImpl.java:61)
>at 
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:249)
>at 
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:264)
>at 
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:390)
>at 
> com.ibm.websphere.resource.WASResourceSetImpl.getResource(WASResourceSetImpl.java:158)
>at 
> com.ibm.websphere.resource.WASResourceSetImpl.getResource(WASResourceSetImpl.java:143)
>at 
> com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:325)
>at 
> com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:298)
>at 
> com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:274)
>at 
> com.ibm.ws.runtime.component.EndPointMgrImpl.getNodeHostName(EndPointMgrImpl.java:488)
>at 
> com.ibm.ws.management.AdminHelperImpl.getNodeHostName(AdminHelperImpl.java:116)
>at 
> com.ibm.ws.management.component.JVMMBean.getJVMNode(JVMMBean.java:167)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:615)
>at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:62)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:615)
>at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:265)
>at 
> javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1089)
>at 
> javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:971)
>at 
> javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBean.java:1373)
>at 
> com.sun.jmx.mbeanserver.DynamicMetaDataImpl.getAttribute(DynamicMetaDataImpl.java:114)
>at 
> com.sun.jmx.mbeanserver.MetaDataImpl.getAttribute(MetaDataImpl.java:199)
>at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:656)
>at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:677)
>at 
> com.ibm.ws.management.AdminServiceImpl.getAttribute(AdminServiceImpl.java:687)
>at 
> com.company.core.container.websphere.WebSphereServerHelper.initialise(Unknown
> Source)
>at 
> com.company.core.container.websphere.WebSphereServerHelper.(Unknown
> Source)
>at java.lang.Class.newInstanceImpl(Native Method)
>at java.lang.Class.newInstance(Class.java:1300)
>at com.company.core.container.ServerHelperFactory.initialise(Unknown 
> Source)
>at com.company.core.container.ServerHelperFactory.(Unknown 
> Source)
>at 
> com.company.core.container.Server

Re: websphere web service deployment problem

2007-09-27 Thread Radim Kolarik

Hi Sebastien,

You are right, I mean the "change classloader properties of your Webapp
to parent-last / single" update.

I am calling the AdminService.getAttribute() from the web app, server
itself starts without problems.

Here is the complete stack trace:

java.lang.ClassCastException:
org.apache.xerces.jaxp.SAXParserFactoryImpl incompatible with
javax.xml.parsers.SAXParserFactory
at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source)
at 
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.makeParser(XMLLoadImpl.java:299)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:140)
at 
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:179)
at 
org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.basicDoLoad(CompatibilityXMIResourceImpl.java:180)
at 
org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.doLoad(CompatibilityXMIResourceImpl.java:173)
at 
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1094)
at 
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:900)
at 
org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.load(CompatibilityXMIResourceImpl.java:259)
at 
com.ibm.websphere.resource.WASResourceImpl.load(WASResourceImpl.java:61)
at 
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:249)
at 
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:264)
at 
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:390)
at 
com.ibm.websphere.resource.WASResourceSetImpl.getResource(WASResourceSetImpl.java:158)
at 
com.ibm.websphere.resource.WASResourceSetImpl.getResource(WASResourceSetImpl.java:143)
at 
com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:325)
at 
com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:298)
at 
com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:274)
at 
com.ibm.ws.runtime.component.EndPointMgrImpl.getNodeHostName(EndPointMgrImpl.java:488)
at 
com.ibm.ws.management.AdminHelperImpl.getNodeHostName(AdminHelperImpl.java:116)
at 
com.ibm.ws.management.component.JVMMBean.getJVMNode(JVMMBean.java:167)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:265)
at 
javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1089)
at 
javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:971)
at 
javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBean.java:1373)
at 
com.sun.jmx.mbeanserver.DynamicMetaDataImpl.getAttribute(DynamicMetaDataImpl.java:114)
at 
com.sun.jmx.mbeanserver.MetaDataImpl.getAttribute(MetaDataImpl.java:199)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:656)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:677)
at 
com.ibm.ws.management.AdminServiceImpl.getAttribute(AdminServiceImpl.java:687)
at 
com.company.core.container.websphere.WebSphereServerHelper.initialise(Unknown
Source)
at 
com.company.core.container.websphere.WebSphereServerHelper.(Unknown
Source)
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1300)
at com.company.core.container.ServerHelperFactory.initialise(Unknown 
Source)
at com.company.core.container.ServerHelperFactory.(Unknown Source)
at 
com.company.core.container.ServerHelperFactory.getServerHelperFactory(Unknown
Source)
at 
com.company.core.ldap.LDAPServerListHelper.(LDAPServerListHelper.java:85)
at 
com.company.core.ldap.LDAPServerListHelper.getInstance(LDAPServerListHelper.java:68)
at 
com.company.core.ldap.LDAPContextFactory.getInitialContext(LDAPContextFactory.java:134)
at 
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:679)
at 
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:25

Re: websphere web service deployment problem

2007-09-27 Thread Jean-Sebastien Delfino


Radim Kolarik wrote:

Hi,

We are experiencing a problem on Websphere 6.1.0.11 with Tuscany 1.0.
When we set all classloader properties, as mentioned before,


I'm assuming that you mean: change classloader properties of your Webapp 
to parent-last / single, correct?



we are
getting the following exception when we try to call Websphere's
AdminService.getAttribute:

Stack Dump = java.lang.ClassCastException:
org.apache.xerces.jaxp.SAXParserFactoryImpl incompatible with
javax.xml.parsers.SAXParserFactory
at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source)
at 
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.makeParser(XMLLoadImpl.java:299)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:140)
at 
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:179)
at 
org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.basicDoLoad(CompatibilityXMIResourceImpl.java:180)
at 
org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.doLoad(CompatibilityXMIResourceImpl.java:173)
at 
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1094)
at 
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:900)
at 
org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.load(CompatibilityXMIResourceImpl.java:259)
at 
com.ibm.websphere.resource.WASResourceImpl.load(WASResourceImpl.java:61)
at 
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:249)
at 
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:264)
at 
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:390)
at 
com.ibm.websphere.resource.WASResourceSetImpl.getResource(WASResourceSetImpl.java:158)
at 
com.ibm.websphere.resource.WASResourceSetImpl.getResource(WASResourceSetImpl.java:143)
at 
com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:325)
at 
com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:298)
at 
com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:274)
at 
com.ibm.ws.runtime.component.EndPointMgrImpl.getNodeHostName(EndPointMgrImpl.java:488)
at 
com.ibm.ws.management.AdminHelperImpl.getNodeHostName(AdminHelperImpl.java:116)
at 
com.ibm.ws.management.component.JVMMBean.getJVMNode(JVMMBean.java:167)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:265)
at 
javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1089)
at 
javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:971)
at 
javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBean.java:1373)
at 
com.sun.jmx.mbeanserver.DynamicMetaDataImpl.getAttribute(DynamicMetaDataImpl.java:114)
at 
com.sun.jmx.mbeanserver.MetaDataImpl.getAttribute(MetaDataImpl.java:199)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:656)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:677)
at 
com.ibm.ws.management.AdminServiceImpl.getAttribute(AdminServiceImpl.java:687)
at com.company.websphere.WebSphereServerHelper.initialise(Unknown 
Source)
   .

It is really strange, because
org.apache.xerces.jaxp.SAXParserFactoryImpl is derived from
SAXParserFactory as far as I know.
  


Can you give me a little more context?

Are you calling AdminService.getAttribute() from your Webapp or are you 
running into this issue when starting the server, independent of the Webapp?


Can you show me the complete stack trace from the log or the FFDC 
created when you get the exception... usually the answer to all stack 
traces lies in the  part :)



Does anybody have an idea what could be causing the problem?
  


Probably but it'll depend on your answer to my above questions :)


Thanks,
Radim

  

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
F

Re: websphere web service deployment problem

2007-09-27 Thread Radim Kolarik

Hi,

We are experiencing a problem on Websphere 6.1.0.11 with Tuscany 1.0.
When we set all classloader properties, as mentioned before, we are
getting the following exception when we try to call Websphere's
AdminService.getAttribute:

Stack Dump = java.lang.ClassCastException:
org.apache.xerces.jaxp.SAXParserFactoryImpl incompatible with
javax.xml.parsers.SAXParserFactory
at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source)
at 
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.makeParser(XMLLoadImpl.java:299)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:140)
at 
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:179)
at 
org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.basicDoLoad(CompatibilityXMIResourceImpl.java:180)
at 
org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.doLoad(CompatibilityXMIResourceImpl.java:173)
at 
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1094)
at 
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:900)
at 
org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.load(CompatibilityXMIResourceImpl.java:259)
at 
com.ibm.websphere.resource.WASResourceImpl.load(WASResourceImpl.java:61)
at 
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:249)
at 
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:264)
at 
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:390)
at 
com.ibm.websphere.resource.WASResourceSetImpl.getResource(WASResourceSetImpl.java:158)
at 
com.ibm.websphere.resource.WASResourceSetImpl.getResource(WASResourceSetImpl.java:143)
at 
com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:325)
at 
com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:298)
at 
com.ibm.ws.runtime.service.ConfigRootImpl.getResource(ConfigRootImpl.java:274)
at 
com.ibm.ws.runtime.component.EndPointMgrImpl.getNodeHostName(EndPointMgrImpl.java:488)
at 
com.ibm.ws.management.AdminHelperImpl.getNodeHostName(AdminHelperImpl.java:116)
at 
com.ibm.ws.management.component.JVMMBean.getJVMNode(JVMMBean.java:167)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:265)
at 
javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1089)
at 
javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:971)
at 
javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBean.java:1373)
at 
com.sun.jmx.mbeanserver.DynamicMetaDataImpl.getAttribute(DynamicMetaDataImpl.java:114)
at 
com.sun.jmx.mbeanserver.MetaDataImpl.getAttribute(MetaDataImpl.java:199)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:656)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:677)
at 
com.ibm.ws.management.AdminServiceImpl.getAttribute(AdminServiceImpl.java:687)
at com.company.websphere.WebSphereServerHelper.initialise(Unknown 
Source)
   .

It is really strange, because
org.apache.xerces.jaxp.SAXParserFactoryImpl is derived from
SAXParserFactory as far as I know.

Does anybody have an idea what could be causing the problem?

Thanks,
Radim

On 9/20/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Radim Kolarik wrote:
> > Hi Sebastien,
> >
> > I can confirm that you are right, that was the problem. I would swear
> > I saw many examples that had the implementation element as last one in
> > the composite file ;-).
> >
> > Thanks again,
> > Radim
> >
> >
>
> Yeah I had to fix them all for the 1.0 release :) I guess it shows that
> this automatic validation is useful.
>
> I'm going to put together a small Eclipse plugin that will register the
> same XMLSchemas in the Eclipse WTP XML catalog. It'll help people edit
> correct .composite and .componentType files using the Eclipse XML editor
> and validate them in their IDE.
>
> --
> Jean-Seb

Re: websphere web service deployment problem

2007-09-20 Thread Jean-Sebastien Delfino


Radim Kolarik wrote:

Hi Sebastien,

I can confirm that you are right, that was the problem. I would swear
I saw many examples that had the implementation element as last one in
the composite file ;-).

Thanks again,
Radim

  


Yeah I had to fix them all for the 1.0 release :) I guess it shows that 
this automatic validation is useful.


I'm going to put together a small Eclipse plugin that will register the 
same XMLSchemas in the Eclipse WTP XML catalog. It'll help people edit 
correct .composite and .componentType files using the Eclipse XML editor 
and validate them in their IDE.


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-20 Thread Simon Nash

According to the SCDL schema, the implementation.* element must come
first in a service or reference. This is what the

line in the schema is saying.

The message is telling you that the SCDL has elements appearing in a
different order. (See TUSCANY-1738.) The message is only a warning,
and the SCDL will be processed successfully. To eliminate the message,
reorder the SCDL so that the implementation.java element comes first.

Simon

Radim Kolarik wrote:

Hi Sebastien,

thanks for your help! It was the the custom Web container property as
described in the WebSphere fixpack.

I can also confirm now that it works with 6.1.0.11 fixpack as well, if
the property is set.

In the log file, however, we are getting something I am not sure we
were getting before:

[20/09/07 10:47:17:187 BST] 0036 ValidatingXML W XMLSchema
validation problem in:
file:/c:/Program%20Files/IBM/WebSphere/AppServer/profiles/vws/installedApps/vws/example-sc-0_0_1_war.ear/example-sc-0.0.1.war/WEB-INF/classes/example-sc.composite,
line: 12, column: 7
cvc-complex-type.2.4.a: Invalid content was found starting with
element 'implementation.java'. One of
'{"http://www.osoa.org/xmlns/sca/1.0":service,
"http://www.osoa.org/xmlns/sca/1.0":reference,
"http://www.osoa.org/xmlns/sca/1.0":property}' is expected.

Do you have an idea what could be wrong?

It looks to me that in http://www.osoa.org/xmlns/sca/1.0/sca-core.xsd
the following code suggests that only service, reference or property
elements are possible within the component:

We also have implementation.java there and it seems to be a valid
option based on several examples, including examples in the spec.

Thanks,
Radim

On 9/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:

Radim Kolarik wrote:

Hi Simon,

unfortunatelly I am seeing the same problem on WAS 6.1.0.9.

Sebastien, do you still have the WAS environment? Could you try to
deploy RC3 based example web service on it?

Thanks a lot,
Radim

It works for me.

I need more precise information to be able to help.

- which web service based sample? helloworld? calculator? built
yourself? using mvn or ant?
- the steps you are following to install and run the sample and the
exact output you are getting when you run it
- whether or not you have configured the WAR classloader "parent last"
and "single classloader"
- whether or not you have configured the custom Web container property
as described in the WebSphere fixpack at [1]
- the time of the error
- your SystemOut.log and SystemError.log files
- the FFDC files created in yout logs directory at the time of the error

Could you please put that information in a JIRA. I'm watching the JIRA
notifications so I'll get notified when you do so, and will investigate
quickly. Thanks.

[1] http://www-1.ibm.com/support/docview.wss?uid=swg24014758

Thanks.

--
Jean-Sebastien

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-20 Thread Radim Kolarik

Hi Sebastien,

I can confirm that you are right, that was the problem. I would swear
I saw many examples that had the implementation element as last one in
the composite file ;-).

Thanks again,
Radim

On 9/20/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Simon Laws wrote:
> > On 9/20/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> >
> >> Hi Sebastien,
> >>
> >> thanks for your help! It was the the custom Web container property as
> >> described in the WebSphere fixpack.
> >>
> >> I can also confirm now that it works with 6.1.0.11 fixpack as well, if
> >> the property is set.
> >>
> >> In the log file, however, we are getting something I am not sure we
> >> were getting before:
> >>
> >> [20/09/07 10:47:17:187 BST] 0036 ValidatingXML W   XMLSchema
> >> validation problem in:
> >>
> >> file:/c:/Program%20Files/IBM/WebSphere/AppServer/profiles/vws/installedApps/vws/example-sc-0_0_1_war.ear/example-
> >> sc-0.0.1.war/WEB-INF/classes/example-sc.composite,
> >> line: 12, column: 7
> >> cvc-complex-type.2.4.a: Invalid content was found starting with
> >> element 'implementation.java'. One of
> >> '{"http://www.osoa.org/xmlns/sca/1.0":service,
> >> "http://www.osoa.org/xmlns/sca/1.0":reference,
> >> "http://www.osoa.org/xmlns/sca/1.0":property}' is expected.
> >>
> >> Do you have an idea what could be wrong?
> >>
> >> It looks to me that in http://www.osoa.org/xmlns/sca/1.0/sca-core.xsd
> >> the following code suggests that only service, reference or property
> >> elements are possible within the component:
> >>
> >> - 
> >>   
> >> - 
> >>   
> >>   
> >>   
> >>   
> >>>> maxOccurs="unbounded" />
> >>   
> >>
> >> We also have implementation.java there and it seems to be a valid
> >> option based on several examples, including examples in the spec.
> >>
> >> Thanks,
> >> Radim
> >>
> >>
> >> On 9/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >>
> >>> Radim Kolarik wrote:
> >>>
>  Hi Simon,
> 
>  unfortunatelly I am seeing the same problem on WAS 6.1.0.9.
> 
>  Sebastien, do you still have the WAS environment? Could you try to
>  deploy RC3 based example web service on it?
> 
>  Thanks a lot,
>  Radim
> 
> 
> 
> >>> It works for me.
> >>>
> >>> I need more precise information to be able to help.
> >>>
> >>> - which web service based sample? helloworld? calculator? built
> >>> yourself? using mvn or ant?
> >>> - the steps you are following to install and run the sample and the
> >>> exact output you are getting when you run it
> >>> - whether or not you have configured the WAR classloader "parent last"
> >>> and "single classloader"
> >>> - whether or not you have configured the custom Web container property
> >>> as described in the WebSphere fixpack at [1]
> >>> - the time of the error
> >>> - your SystemOut.log and SystemError.log files
> >>> - the FFDC files created in yout logs directory at the time of the error
> >>>
> >>> Could you please put that information in a JIRA. I'm watching the JIRA
> >>> notifications so I'll get notified when you do so, and will investigate
> >>> quickly. Thanks.
> >>>
> >>> [1] http://www-1.ibm.com/support/docview.wss?uid=swg24014758
> >>>
> >>> Thanks.
> >>>
> >>> --
> >>> Jean-Sebastien
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >> Hi Radim
> >>
> >
> > You're seeing this output now because Sebastien recently implemented schema
> > validation against the SCA files.
> >
> > What the schema is saying is that you can have an  element
> > (implementation.java in your case) which can then be followed by a choice of
> > any number of service, reference or property elements.
> >
> > Can you check in your .composite file that you have the default namespace
> > xmlns="http://www.osoa.org/xmlns/sca/1.0"; and that the 
> > element appears as the first child element in your component definition.
> >
> > Regards
> >
> > Simon
> >
> >
>
> A common bug I've seen in many composites is that the 
> element must appear first under .
>
> Hope you find the validation useful :)
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-20 Thread Jean-Sebastien Delfino

Simon Laws wrote:

On 9/20/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:

Hi Sebastien,

thanks for your help! It was the the custom Web container property as
described in the WebSphere fixpack.

I can also confirm now that it works with 6.1.0.11 fixpack as well, if
the property is set.

In the log file, however, we are getting something I am not sure we
were getting before:

[20/09/07 10:47:17:187 BST] 0036 ValidatingXML W XMLSchema
validation problem in:

file:/c:/Program%20Files/IBM/WebSphere/AppServer/profiles/vws/installedApps/vws/example-sc-0_0_1_war.ear/example-
sc-0.0.1.war/WEB-INF/classes/example-sc.composite,
line: 12, column: 7
cvc-complex-type.2.4.a: Invalid content was found starting with
element 'implementation.java'. One of
'{"http://www.osoa.org/xmlns/sca/1.0":service,
"http://www.osoa.org/xmlns/sca/1.0":reference,
"http://www.osoa.org/xmlns/sca/1.0":property}' is expected.

Do you have an idea what could be wrong?

It looks to me that in http://www.osoa.org/xmlns/sca/1.0/sca-core.xsd
the following code suggests that only service, reference or property
elements are possible within the component:

We also have implementation.java there and it seems to be a valid
option based on several examples, including examples in the spec.

Thanks,
Radim

On 9/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:

Radim Kolarik wrote:

Hi Simon,

unfortunatelly I am seeing the same problem on WAS 6.1.0.9.

Sebastien, do you still have the WAS environment? Could you try to
deploy RC3 based example web service on it?

Thanks a lot,
Radim

It works for me.

I need more precise information to be able to help.

Could you please put that information in a JIRA. I'm watching the JIRA
notifications so I'll get notified when you do so, and will investigate
quickly. Thanks.

[1] http://www-1.ibm.com/support/docview.wss?uid=swg24014758

Thanks.

--
Jean-Sebastien

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Hi Radim

You're seeing this output now because Sebastien recently implemented schema
validation against the SCA files.

What the schema is saying is that you can have an element
(implementation.java in your case) which can then be followed by a choice of
any number of service, reference or property elements.

Can you check in your .composite file that you have the default namespace
xmlns="http://www.osoa.org/xmlns/sca/1.0"; and that the
element appears as the first child element in your component definition.

Regards

Simon

A common bug I've seen in many composites is that the
element must appear first under .

Hope you find the validation useful :)

--
Jean-Sebastien

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-20 Thread Simon Laws

On 9/20/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
>
> Hi Sebastien,
>
> thanks for your help! It was the the custom Web container property as
> described in the WebSphere fixpack.
>
> I can also confirm now that it works with 6.1.0.11 fixpack as well, if
> the property is set.
>
> In the log file, however, we are getting something I am not sure we
> were getting before:
>
> [20/09/07 10:47:17:187 BST] 0036 ValidatingXML W   XMLSchema
> validation problem in:
>
> file:/c:/Program%20Files/IBM/WebSphere/AppServer/profiles/vws/installedApps/vws/example-sc-0_0_1_war.ear/example-
> sc-0.0.1.war/WEB-INF/classes/example-sc.composite,
> line: 12, column: 7
> cvc-complex-type.2.4.a: Invalid content was found starting with
> element 'implementation.java'. One of
> '{"http://www.osoa.org/xmlns/sca/1.0":service,
> "http://www.osoa.org/xmlns/sca/1.0":reference,
> "http://www.osoa.org/xmlns/sca/1.0":property}' is expected.
>
> Do you have an idea what could be wrong?
>
> It looks to me that in http://www.osoa.org/xmlns/sca/1.0/sca-core.xsd
> the following code suggests that only service, reference or property
> elements are possible within the component:
>
> - 
>   
> - 
>   
>   
>   
>   
>maxOccurs="unbounded" />
>   
>
> We also have implementation.java there and it seems to be a valid
> option based on several examples, including examples in the spec.
>
> Thanks,
> Radim
>
>
> On 9/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > Radim Kolarik wrote:
> > > Hi Simon,
> > >
> > > unfortunatelly I am seeing the same problem on WAS 6.1.0.9.
> > >
> > > Sebastien, do you still have the WAS environment? Could you try to
> > > deploy RC3 based example web service on it?
> > >
> > > Thanks a lot,
> > > Radim
> > >
> > >
> >
> > It works for me.
> >
> > I need more precise information to be able to help.
> >
> > - which web service based sample? helloworld? calculator? built
> > yourself? using mvn or ant?
> > - the steps you are following to install and run the sample and the
> > exact output you are getting when you run it
> > - whether or not you have configured the WAR classloader "parent last"
> > and "single classloader"
> > - whether or not you have configured the custom Web container property
> > as described in the WebSphere fixpack at [1]
> > - the time of the error
> > - your SystemOut.log and SystemError.log files
> > - the FFDC files created in yout logs directory at the time of the error
> >
> > Could you please put that information in a JIRA. I'm watching the JIRA
> > notifications so I'll get notified when you do so, and will investigate
> > quickly. Thanks.
> >
> > [1] http://www-1.ibm.com/support/docview.wss?uid=swg24014758
> >
> > Thanks.
> >
> > --
> > Jean-Sebastien
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Hi Radim

You're seeing this output now because Sebastien recently implemented schema
validation against the SCA files.

What the schema is saying is that you can have an  element
(implementation.java in your case) which can then be followed by a choice of
any number of service, reference or property elements.

Can you check in your .composite file that you have the default namespace
xmlns="http://www.osoa.org/xmlns/sca/1.0"; and that the 
element appears as the first child element in your component definition.

Regards

Simon

Re: websphere web service deployment problem

2007-09-20 Thread Radim Kolarik

Hi Sebastien,

thanks for your help! It was the the custom Web container property as
described in the WebSphere fixpack.

I can also confirm now that it works with 6.1.0.11 fixpack as well, if
the property is set.

In the log file, however, we are getting something I am not sure we
were getting before:

[20/09/07 10:47:17:187 BST] 0036 ValidatingXML W   XMLSchema
validation problem in:
file:/c:/Program%20Files/IBM/WebSphere/AppServer/profiles/vws/installedApps/vws/example-sc-0_0_1_war.ear/example-sc-0.0.1.war/WEB-INF/classes/example-sc.composite,
line: 12, column: 7
cvc-complex-type.2.4.a: Invalid content was found starting with
element 'implementation.java'. One of
'{"http://www.osoa.org/xmlns/sca/1.0":service,
"http://www.osoa.org/xmlns/sca/1.0":reference,
"http://www.osoa.org/xmlns/sca/1.0":property}' is expected.

Do you have an idea what could be wrong?

It looks to me that in http://www.osoa.org/xmlns/sca/1.0/sca-core.xsd
the following code suggests that only service, reference or property
elements are possible within the component:

- 

- 

We also have implementation.java there and it seems to be a valid
option based on several examples, including examples in the spec.

Thanks,
Radim

On 9/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Radim Kolarik wrote:
> > Hi Simon,
> >
> > unfortunatelly I am seeing the same problem on WAS 6.1.0.9.
> >
> > Sebastien, do you still have the WAS environment? Could you try to
> > deploy RC3 based example web service on it?
> >
> > Thanks a lot,
> > Radim
> >
> >
>
> It works for me.
>
> I need more precise information to be able to help.
>
> - which web service based sample? helloworld? calculator? built
> yourself? using mvn or ant?
> - the steps you are following to install and run the sample and the
> exact output you are getting when you run it
> - whether or not you have configured the WAR classloader "parent last"
> and "single classloader"
> - whether or not you have configured the custom Web container property
> as described in the WebSphere fixpack at [1]
> - the time of the error
> - your SystemOut.log and SystemError.log files
> - the FFDC files created in yout logs directory at the time of the error
>
> Could you please put that information in a JIRA. I'm watching the JIRA
> notifications so I'll get notified when you do so, and will investigate
> quickly. Thanks.
>
> [1] http://www-1.ibm.com/support/docview.wss?uid=swg24014758
>
> Thanks.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-19 Thread Jean-Sebastien Delfino


Radim Kolarik wrote:

Hi Simon,

unfortunatelly I am seeing the same problem on WAS 6.1.0.9.

Sebastien, do you still have the WAS environment? Could you try to
deploy RC3 based example web service on it?

Thanks a lot,
Radim

  


It works for me.

I need more precise information to be able to help.

- which web service based sample? helloworld? calculator? built 
yourself? using mvn or ant?
- the steps you are following to install and run the sample and the 
exact output you are getting when you run it
- whether or not you have configured the WAR classloader "parent last" 
and "single classloader"
- whether or not you have configured the custom Web container property 
as described in the WebSphere fixpack at [1]

- the time of the error
- your SystemOut.log and SystemError.log files
- the FFDC files created in yout logs directory at the time of the error

Could you please put that information in a JIRA. I'm watching the JIRA 
notifications so I'll get notified when you do so, and will investigate 
quickly. Thanks.


[1] http://www-1.ibm.com/support/docview.wss?uid=swg24014758

Thanks.

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-19 Thread Radim Kolarik

Hi Simon,

unfortunatelly I am seeing the same problem on WAS 6.1.0.9.

Sebastien, do you still have the WAS environment? Could you try to
deploy RC3 based example web service on it?

Thanks a lot,
Radim

On 9/19/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> Hi Simon,
>
> thanks for your reply. We will test it now with 6.1.0.9 and I will let
> you know the result of that.
>
> Thanks,
> Radim
>
> On 9/19/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> > As it's night time in California, I'll answer this question.
> > Sebastien told me that he had tested on 6.1.0.9.  Can you use that
> > level instead of 6.1.0.11?
> >
> >   Simon
> >
> > Radim Kolarik wrote:
> >
> > > Hi Sebastien,
> > >
> > > I am having problems making the app work on Websphere 6.1.0.11. Did
> > > you try that particular fixpack, or did you try 6.1.0.9?
> > >
> > > In the 6.1.0.11 WAS the service is not being picked up at all, nothing
> > > at all is logged to the log file if I try to access the service URL. I
> > > tried it with the release candidate RC3.
> > >
> > > Thanks,
> > > Radim
> > >
> > >
> > > On 9/14/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > >
> > >>Jean-Sebastien Delfino wrote:
> > >>
> > >>>Jean-Sebastien Delfino wrote:
> > >>>
> > Radim Kolarik wrote:
> > 
> > >Hi Sebastian,
> > >
> > >I received the latest code from ant and I can confirm that the service
> > >generates the WSDL file now. The  element doesn't even
> > >need uri attribute, it works without any attributes!
> > >
> > >However, there is still some problem, the generated WSDL contains
> > >
> > >Error 404: SRVE0190E: File not found: /ComponentName
> > >
> > >at it's end, right after the . I have created a
> > >JIRA for this: https://issues.apache.org/jira/browse/TUSCANY-1702.
> > >
> > >Are you seeing the same problem?
> > >
> > >Best regards,
> > >Radim
> > >
> > >
> > 
> > I just checked and am seeing this issue too (I had just not noticed
> > that additional line at the end of the WSDL). However, the Web
> > Service binding actually works for me on both references and services
> > so if you manage to workaround that additional line at the end of the
> > generated WSDL it should work for you too.
> > 
> > I think it's another of these small behavior differences. On
> > WebSphere we probably need to force a close of the response
> > outputStream before returning from the servlet filter. I'm
> > experimenting with that right now and will give an update soon...
> > 
> > >>>
> > >>>Radim, after a fun debugging session and some digging around here's an
> > >>>update:
> > >>>
> > >>>- The issue you're seeing is the same as [1].
> > >>>
> > >>>- This is a WebSphere 6.1 bug, a fix is available at [2].
> > >>>
> > >>>I'm going to try some of the workarounds suggested in [1] and see if
> > >>>they work for Tuscany. It would be good if you could also try the
> > >>>WebSphere fix [2] as well if possible.
> > >>>
> > >>>[1] https://issues.apache.org/struts/browse/WW-1839
> > >>>[2] http://www-1.ibm.com/support/docview.wss?uid=swg24014758
> > >>>
> > >>>Hope this helps.
> > >>>
> > >>
> > >>Radim,
> > >>
> > >>It doesn't look like I can workaround this WebSphere bug in the Tuscany
> > >>code. Your best bet is to install the fix at [2].
> > >>
> > >>Could you please let us know the results after you do that? Thanks.
> > >>
> > >>--
> > >>Jean-Sebastien
> > >>
> > >>
> > >>-
> > >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >>For additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >>
> > >
> > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-19 Thread Radim Kolarik

Hi Simon,

thanks for your reply. We will test it now with 6.1.0.9 and I will let
you know the result of that.

Thanks,
Radim

On 9/19/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> As it's night time in California, I'll answer this question.
> Sebastien told me that he had tested on 6.1.0.9.  Can you use that
> level instead of 6.1.0.11?
>
>   Simon
>
> Radim Kolarik wrote:
>
> > Hi Sebastien,
> >
> > I am having problems making the app work on Websphere 6.1.0.11. Did
> > you try that particular fixpack, or did you try 6.1.0.9?
> >
> > In the 6.1.0.11 WAS the service is not being picked up at all, nothing
> > at all is logged to the log file if I try to access the service URL. I
> > tried it with the release candidate RC3.
> >
> > Thanks,
> > Radim
> >
> >
> > On 9/14/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >
> >>Jean-Sebastien Delfino wrote:
> >>
> >>>Jean-Sebastien Delfino wrote:
> >>>
> Radim Kolarik wrote:
> 
> >Hi Sebastian,
> >
> >I received the latest code from ant and I can confirm that the service
> >generates the WSDL file now. The  element doesn't even
> >need uri attribute, it works without any attributes!
> >
> >However, there is still some problem, the generated WSDL contains
> >
> >Error 404: SRVE0190E: File not found: /ComponentName
> >
> >at it's end, right after the . I have created a
> >JIRA for this: https://issues.apache.org/jira/browse/TUSCANY-1702.
> >
> >Are you seeing the same problem?
> >
> >Best regards,
> >Radim
> >
> >
> 
> I just checked and am seeing this issue too (I had just not noticed
> that additional line at the end of the WSDL). However, the Web
> Service binding actually works for me on both references and services
> so if you manage to workaround that additional line at the end of the
> generated WSDL it should work for you too.
> 
> I think it's another of these small behavior differences. On
> WebSphere we probably need to force a close of the response
> outputStream before returning from the servlet filter. I'm
> experimenting with that right now and will give an update soon...
> 
> >>>
> >>>Radim, after a fun debugging session and some digging around here's an
> >>>update:
> >>>
> >>>- The issue you're seeing is the same as [1].
> >>>
> >>>- This is a WebSphere 6.1 bug, a fix is available at [2].
> >>>
> >>>I'm going to try some of the workarounds suggested in [1] and see if
> >>>they work for Tuscany. It would be good if you could also try the
> >>>WebSphere fix [2] as well if possible.
> >>>
> >>>[1] https://issues.apache.org/struts/browse/WW-1839
> >>>[2] http://www-1.ibm.com/support/docview.wss?uid=swg24014758
> >>>
> >>>Hope this helps.
> >>>
> >>
> >>Radim,
> >>
> >>It doesn't look like I can workaround this WebSphere bug in the Tuscany
> >>code. Your best bet is to install the fix at [2].
> >>
> >>Could you please let us know the results after you do that? Thanks.
> >>
> >>--
> >>Jean-Sebastien
> >>
> >>
> >>-
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-19 Thread Simon Nash


As it's night time in California, I'll answer this question.
Sebastien told me that he had tested on 6.1.0.9.  Can you use that
level instead of 6.1.0.11?

  Simon

Radim Kolarik wrote:


Hi Sebastien,

I am having problems making the app work on Websphere 6.1.0.11. Did
you try that particular fixpack, or did you try 6.1.0.9?

In the 6.1.0.11 WAS the service is not being picked up at all, nothing
at all is logged to the log file if I try to access the service URL. I
tried it with the release candidate RC3.

Thanks,
Radim


On 9/14/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Jean-Sebastien Delfino wrote:


Jean-Sebastien Delfino wrote:


Radim Kolarik wrote:


Hi Sebastian,

I received the latest code from ant and I can confirm that the service
generates the WSDL file now. The  element doesn't even
need uri attribute, it works without any attributes!

However, there is still some problem, the generated WSDL contains

Error 404: SRVE0190E: File not found: /ComponentName

at it's end, right after the . I have created a
JIRA for this: https://issues.apache.org/jira/browse/TUSCANY-1702.

Are you seeing the same problem?

Best regards,
Radim




I just checked and am seeing this issue too (I had just not noticed
that additional line at the end of the WSDL). However, the Web
Service binding actually works for me on both references and services
so if you manage to workaround that additional line at the end of the
generated WSDL it should work for you too.

I think it's another of these small behavior differences. On
WebSphere we probably need to force a close of the response
outputStream before returning from the servlet filter. I'm
experimenting with that right now and will give an update soon...



Radim, after a fun debugging session and some digging around here's an
update:

- The issue you're seeing is the same as [1].

- This is a WebSphere 6.1 bug, a fix is available at [2].

I'm going to try some of the workarounds suggested in [1] and see if
they work for Tuscany. It would be good if you could also try the
WebSphere fix [2] as well if possible.

[1] https://issues.apache.org/struts/browse/WW-1839
[2] http://www-1.ibm.com/support/docview.wss?uid=swg24014758

Hope this helps.



Radim,

It doesn't look like I can workaround this WebSphere bug in the Tuscany
code. Your best bet is to install the fix at [2].

Could you please let us know the results after you do that? Thanks.

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]









-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-19 Thread Radim Kolarik

Hi Sebastien,

I am having problems making the app work on Websphere 6.1.0.11. Did
you try that particular fixpack, or did you try 6.1.0.9?

In the 6.1.0.11 WAS the service is not being picked up at all, nothing
at all is logged to the log file if I try to access the service URL. I
tried it with the release candidate RC3.

Thanks,
Radim


On 9/14/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Jean-Sebastien Delfino wrote:
> > Jean-Sebastien Delfino wrote:
> >> Radim Kolarik wrote:
> >>> Hi Sebastian,
> >>>
> >>> I received the latest code from ant and I can confirm that the service
> >>> generates the WSDL file now. The  element doesn't even
> >>> need uri attribute, it works without any attributes!
> >>>
> >>> However, there is still some problem, the generated WSDL contains
> >>>
> >>> Error 404: SRVE0190E: File not found: /ComponentName
> >>>
> >>> at it's end, right after the . I have created a
> >>> JIRA for this: https://issues.apache.org/jira/browse/TUSCANY-1702.
> >>>
> >>> Are you seeing the same problem?
> >>>
> >>> Best regards,
> >>> Radim
> >>>
> >>>
> >>
> >> I just checked and am seeing this issue too (I had just not noticed
> >> that additional line at the end of the WSDL). However, the Web
> >> Service binding actually works for me on both references and services
> >> so if you manage to workaround that additional line at the end of the
> >> generated WSDL it should work for you too.
> >>
> >> I think it's another of these small behavior differences. On
> >> WebSphere we probably need to force a close of the response
> >> outputStream before returning from the servlet filter. I'm
> >> experimenting with that right now and will give an update soon...
> >>
> >
> > Radim, after a fun debugging session and some digging around here's an
> > update:
> >
> > - The issue you're seeing is the same as [1].
> >
> > - This is a WebSphere 6.1 bug, a fix is available at [2].
> >
> > I'm going to try some of the workarounds suggested in [1] and see if
> > they work for Tuscany. It would be good if you could also try the
> > WebSphere fix [2] as well if possible.
> >
> > [1] https://issues.apache.org/struts/browse/WW-1839
> > [2] http://www-1.ibm.com/support/docview.wss?uid=swg24014758
> >
> > Hope this helps.
> >
>
> Radim,
>
> It doesn't look like I can workaround this WebSphere bug in the Tuscany
> code. Your best bet is to install the fix at [2].
>
> Could you please let us know the results after you do that? Thanks.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-14 Thread Jean-Sebastien Delfino


Jean-Sebastien Delfino wrote:

Jean-Sebastien Delfino wrote:

Radim Kolarik wrote:

Hi Sebastian,

I received the latest code from ant and I can confirm that the service
generates the WSDL file now. The  element doesn't even
need uri attribute, it works without any attributes!

However, there is still some problem, the generated WSDL contains

Error 404: SRVE0190E: File not found: /ComponentName

at it's end, right after the . I have created a
JIRA for this: https://issues.apache.org/jira/browse/TUSCANY-1702.

Are you seeing the same problem?

Best regards,
Radim

  


I just checked and am seeing this issue too (I had just not noticed 
that additional line at the end of the WSDL). However, the Web 
Service binding actually works for me on both references and services 
so if you manage to workaround that additional line at the end of the 
generated WSDL it should work for you too.


I think it's another of these small behavior differences. On 
WebSphere we probably need to force a close of the response 
outputStream before returning from the servlet filter. I'm 
experimenting with that right now and will give an update soon...




Radim, after a fun debugging session and some digging around here's an 
update:


- The issue you're seeing is the same as [1].

- This is a WebSphere 6.1 bug, a fix is available at [2].

I'm going to try some of the workarounds suggested in [1] and see if 
they work for Tuscany. It would be good if you could also try the 
WebSphere fix [2] as well if possible.


[1] https://issues.apache.org/struts/browse/WW-1839
[2] http://www-1.ibm.com/support/docview.wss?uid=swg24014758

Hope this helps.



Radim,

It doesn't look like I can workaround this WebSphere bug in the Tuscany 
code. Your best bet is to install the fix at [2].


Could you please let us know the results after you do that? Thanks.

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-14 Thread Jean-Sebastien Delfino


Jean-Sebastien Delfino wrote:

Radim Kolarik wrote:

Hi Sebastian,

I received the latest code from ant and I can confirm that the service
generates the WSDL file now. The  element doesn't even
need uri attribute, it works without any attributes!

However, there is still some problem, the generated WSDL contains

Error 404: SRVE0190E: File not found: /ComponentName

at it's end, right after the . I have created a
JIRA for this: https://issues.apache.org/jira/browse/TUSCANY-1702.

Are you seeing the same problem?

Best regards,
Radim

  


I just checked and am seeing this issue too (I had just not noticed 
that additional line at the end of the WSDL). However, the Web Service 
binding actually works for me on both references and services so if 
you manage to workaround that additional line at the end of the 
generated WSDL it should work for you too.


I think it's another of these small behavior differences. On WebSphere 
we probably need to force a close of the response outputStream before 
returning from the servlet filter. I'm experimenting with that right 
now and will give an update soon...




Radim, after a fun debugging session and some digging around here's an 
update:


- The issue you're seeing is the same as [1].

- This is a WebSphere 6.1 bug, a fix is available at [2].

I'm going to try some of the workarounds suggested in [1] and see if 
they work for Tuscany. It would be good if you could also try the 
WebSphere fix [2] as well if possible.


[1] https://issues.apache.org/struts/browse/WW-1839
[2] http://www-1.ibm.com/support/docview.wss?uid=swg24014758

Hope this helps.

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-14 Thread Jean-Sebastien Delfino


Radim Kolarik wrote:

Hi Sebastian,

I received the latest code from ant and I can confirm that the service
generates the WSDL file now. The  element doesn't even
need uri attribute, it works without any attributes!

However, there is still some problem, the generated WSDL contains

Error 404: SRVE0190E: File not found: /ComponentName

at it's end, right after the . I have created a
JIRA for this: https://issues.apache.org/jira/browse/TUSCANY-1702.

Are you seeing the same problem?

Best regards,
Radim

  


I just checked and am seeing this issue too (I had just not noticed that 
additional line at the end of the WSDL). However, the Web Service 
binding actually works for me on both references and services so if you 
manage to workaround that additional line at the end of the generated 
WSDL it should work for you too.


I think it's another of these small behavior differences. On WebSphere 
we probably need to force a close of the response outputStream before 
returning from the servlet filter. I'm experimenting with that right now 
and will give an update soon...


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-14 Thread Radim Kolarik

Hi Sebastian,

I received the latest code from ant and I can confirm that the service
generates the WSDL file now. The  element doesn't even
need uri attribute, it works without any attributes!

However, there is still some problem, the generated WSDL contains

Error 404: SRVE0190E: File not found: /ComponentName

at it's end, right after the . I have created a
JIRA for this: https://issues.apache.org/jira/browse/TUSCANY-1702.

Are you seeing the same problem?

Best regards,
Radim

On 9/14/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Radim Kolarik wrote:
> > Hi Yang,
> >
> > unfortunatelly, that didn't help either.
> >
> > Thanks,
> > Radim
> >
> > On 9/14/07, Yang Lei <[EMAIL PROTECTED]> wrote:
> >
> >> Try remove the contextRoot and see if you can get the values.
> >>
> >> Yang
> >>
> >>
> >> On 9/13/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> >>
> >>> Hi Simon,
> >>>
> >>> please ignore the --, it was just added to thread by accident. The
> >>> file I work with is a valid XML file.
> >>>
> >>> The URI even gets picked up from the .composite file during
> >>> inicialization, I get the addServletMapping:
> >>> /contextroot/ExampleComponent/ExampleService in the log file.
> >>>
> >>> But I do not see any initContextPath: in the log, maybe that could be
> >>> signaling the problem?
> >>>
> >>> Thanks,
> >>> Radim
> >>>
> >>>
> Hi Radim,
>
> I did some investigation, here's what I found:
>
> - If you're not seeing initContextPath but seeing addServletMapping in
> the log, that's probably because you're using a level of code prior to
> the addition of initContextPath, I'm guessing that you're using the last
> published snapshot? Anyway, don't worry about it, that's not the issue.
>
> - The issue you've run into is caused by different behavior of
> HttpServletRequest.getServletPath() between WebSphere and Tomcat/Jetty
> when invoked from a ServletFilter. In your example, on Tomcat/Jetty
> getServletPath() will return "/ExampleComponent", on WebSphere
> getServletPath() returns "" and "/ExampleComponent" can be found in
> request.getPathInfo() instead. I am not sure which one is correct,
> WebSphere or Tomcat/Jetty, but for now I've changed TuscanyServletFilter
> to tolerate both.
>
> - If your component has a single service, it will be available at
> http://localhost:9080/contextRoot/ExampleComponent instead of
> http://localhost:9080/contextRoot/ExampleComponent/ExampleService. I
> think that this is consistent with what the SCA spec 1.0 says about URIs
> of deployed bindings.
>
> - You should have xalan-2.7.0.jar in your WAR WEB-INF/lib and make sure
> that you don't have any servlet-api JAR in there.
>
> - Finally, in the WebSphere admin console, you should configure your
> Webapp with Webapp Class Loader order = "Classes loaded with application
> class loader first" and WAR ClassLoader policy = "Single class loader
> for application".
>
> With this configuration, and the few fixes I just committed in SVN
> revision 575610, I am able to run the calculator-webapp (a JSP calling
> the calculator component locally) and calculator-webapp-ws (exercising
> both a reference a service with WS bindings) samples on WebSphere 6.1.
>
> Hope this helps...
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-14 Thread Jean-Sebastien Delfino


Radim Kolarik wrote:

Hi Yang,

unfortunatelly, that didn't help either.

Thanks,
Radim

On 9/14/07, Yang Lei <[EMAIL PROTECTED]> wrote:
  

Try remove the contextRoot and see if you can get the values.

Yang


On 9/13/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:


Hi Simon,

please ignore the --, it was just added to thread by accident. The
file I work with is a valid XML file.

The URI even gets picked up from the .composite file during
inicialization, I get the addServletMapping:
/contextroot/ExampleComponent/ExampleService in the log file.

But I do not see any initContextPath: in the log, maybe that could be
signaling the problem?

Thanks,
Radim

  

Hi Radim,

I did some investigation, here's what I found:

- If you're not seeing initContextPath but seeing addServletMapping in 
the log, that's probably because you're using a level of code prior to 
the addition of initContextPath, I'm guessing that you're using the last 
published snapshot? Anyway, don't worry about it, that's not the issue.


- The issue you've run into is caused by different behavior of 
HttpServletRequest.getServletPath() between WebSphere and Tomcat/Jetty 
when invoked from a ServletFilter. In your example, on Tomcat/Jetty 
getServletPath() will return "/ExampleComponent", on WebSphere 
getServletPath() returns "" and "/ExampleComponent" can be found in 
request.getPathInfo() instead. I am not sure which one is correct, 
WebSphere or Tomcat/Jetty, but for now I've changed TuscanyServletFilter 
to tolerate both.


- If your component has a single service, it will be available at 
http://localhost:9080/contextRoot/ExampleComponent instead of 
http://localhost:9080/contextRoot/ExampleComponent/ExampleService. I 
think that this is consistent with what the SCA spec 1.0 says about URIs 
of deployed bindings.


- You should have xalan-2.7.0.jar in your WAR WEB-INF/lib and make sure 
that you don't have any servlet-api JAR in there.


- Finally, in the WebSphere admin console, you should configure your 
Webapp with Webapp Class Loader order = "Classes loaded with application 
class loader first" and WAR ClassLoader policy = "Single class loader 
for application".


With this configuration, and the few fixes I just committed in SVN 
revision 575610, I am able to run the calculator-webapp (a JSP calling 
the calculator component locally) and calculator-webapp-ws (exercising 
both a reference a service with WS bindings) samples on WebSphere 6.1.


Hope this helps...

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-14 Thread Radim Kolarik

Hi Yang,

unfortunatelly, that didn't help either.

Thanks,
Radim

On 9/14/07, Yang Lei <[EMAIL PROTECTED]> wrote:
> Try remove the contextRoot and see if you can get the values.
>
> Yang
>
>
> On 9/13/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> >
> > Hi Simon,
> >
> > please ignore the --, it was just added to thread by accident. The
> > file I work with is a valid XML file.
> >
> > The URI even gets picked up from the .composite file during
> > inicialization, I get the addServletMapping:
> > /contextroot/ExampleComponent/ExampleService in the log file.
> >
> > But I do not see any initContextPath: in the log, maybe that could be
> > signaling the problem?
> >
> > Thanks,
> > Radim
> >
> > On 9/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> > > Radim,
> > > What actually happens when you put this URI into a browser?
> > >
> > > I'm slightly surprised by the --> at the end of the binding.ws
> > > element.  I've only seen this in comments.
> > >
> > >   Simon
> > >
> > > Radim Kolarik wrote:
> > >
> > > > Hi Ant,
> > > >
> > > > I have specified absolute URI and it still doesn't work on Websphere:
> > > >
> > > > 
> > > > http://www.osoa.org/xmlns/sca/1.0";
> > > >   targetNamespace="http://company/examples/example-sc";
> > > >   xmlns:ex="http://company/examples/example-sc";
> > > > name="example-sc">
> > > >
> > > > 
> > > >   
> > > >   
> > > >> > > uri="http://localhost:9201/contextroot/ExampleComponent/ExampleService
> > "/-->
> > > >   
> > > >   
> > > > 
> > > >
> > > > 
> > > >
> > > > Do you have an idea what could be the problem?
> > > >
> > > > Thanks,
> > > > Radim
> > > >
> > > >
> > > > On 9/13/07, ant elder <[EMAIL PROTECTED]> wrote:
> > > >
> > > >>On 9/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> > > >>
> > > >>>
> > > >>>ant elder wrote:
> > > >>>
> > > On 9/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> > > 
> > > 
> > > >See inline.
> > > >
> > > >  Simon
> > > >
> > > >Radim Kolarik wrote:
> > > >
> > > >
> > > >
> > > >>Oh, sorry about the stack trace, it only occurs with older version
> > of
> > > >>Tuscany when TuscanyServlet is used instead of filters.
> > > >>
> > > >>I am now using Tuscany snapshot from the Maven repository dated
> > 4th
> > > >>September, with filters set up in web.xml, but still no luck on
> > > >>Websphere. There is now no warning or exception in the log, but
> > the
> > > >>service is not being picked up. It is being picked up in Tomcat.
> > > >>
> > > >>Do you have any ideas?
> > > >>
> > > >>Thanks,
> > > >>Radim
> > > >>
> > > >>On 9/13/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Hi Yang,
> > > >>>
> > > >>>thank you for your suggestions.
> > > >>>
> > > >>>I am sure I use the correct root context, because I can access a
> > JSP
> > > >>>within the application successfully. It seems to me that the axis
> > > >>>service is not being recognized at
> > > >>>http://localhost:9201/contextRoot/componentName/serviceName.
> > > >>>
> > > >
> > > >I think this might be connected with the port number.  If your
> > > >.composite file just uses the  element with dynamic
> > WSDL
> > > >generation and no "uri" attribute, then Tuscany will construct a
> > default
> > > >URI.  There's a hardcoded port number of 8085 in the
> > > >>>
> > > >>>Axis2ServiceProvider
> > > >>>
> > > >code, but I think in a webapp environment Tuscany would look for
> > the
> > > >webapp server's configured port or fall back to 8080 if it doesn't
> > know
> > > >what this is.  (I'm not 100% sure of the details of how this
> > works.)
> > > 
> > > 
> > > 
> > > That Axis2ServiceProvider has port 8085 hard coded is a bug.
> > > Axis2ServiceProvider should only be registering the servlet with an
> > > >>>
> > > >>>explicit
> > > >>>
> > > port if  specifies an explicit port. If 
> > doesn't
> > > specify the port then its down to the ServletHost impl to use the
> > > >>>
> > > >>>default
> > > >>>
> > > one, and thats what our WebAppServletHost will do. If we remove the
> > > hardcoded port 8085 in Axis2ServiceProvider this all works fine. The
> > > Tuscany-Geronimo integration also has this problem which is why I
> > was
> > > >>>
> > > >>>trying
> > > >>>
> > > to remove the hard coded port :)
> > > 
> > > >>>
> > > >>>A couple of questions:
> > > >>>
> > > >>>1. In a WebSphere environment, can the WebAppServletHost get hold of
> > the
> > > >>>port number configured by WebSphere (9021 in this case)?
> > > >>
> > > >>
> > > >>Its in the ServletRequest when a request comes in, but its not so easy
> > to
> > > >>find before a request (eg during init).
> > > >>
> > > >>2. Do you think at the moment it would try to use port 8085 in this
> > case
> > > >>
> > > >>>

Re: websphere web service deployment problem

2007-09-13 Thread Yang Lei

Try remove the contextRoot and see if you can get the values.

Yang


On 9/13/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
>
> Hi Simon,
>
> please ignore the --, it was just added to thread by accident. The
> file I work with is a valid XML file.
>
> The URI even gets picked up from the .composite file during
> inicialization, I get the addServletMapping:
> /contextroot/ExampleComponent/ExampleService in the log file.
>
> But I do not see any initContextPath: in the log, maybe that could be
> signaling the problem?
>
> Thanks,
> Radim
>
> On 9/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> > Radim,
> > What actually happens when you put this URI into a browser?
> >
> > I'm slightly surprised by the --> at the end of the binding.ws
> > element.  I've only seen this in comments.
> >
> >   Simon
> >
> > Radim Kolarik wrote:
> >
> > > Hi Ant,
> > >
> > > I have specified absolute URI and it still doesn't work on Websphere:
> > >
> > > 
> > > http://www.osoa.org/xmlns/sca/1.0";
> > >   targetNamespace="http://company/examples/example-sc";
> > >   xmlns:ex="http://company/examples/example-sc";
> > > name="example-sc">
> > >
> > > 
> > >   
> > >   
> > >> > uri="http://localhost:9201/contextroot/ExampleComponent/ExampleService
> "/-->
> > >   
> > >   
> > > 
> > >
> > > 
> > >
> > > Do you have an idea what could be the problem?
> > >
> > > Thanks,
> > > Radim
> > >
> > >
> > > On 9/13/07, ant elder <[EMAIL PROTECTED]> wrote:
> > >
> > >>On 9/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> > >>
> > >>>
> > >>>ant elder wrote:
> > >>>
> > On 9/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> > 
> > 
> > >See inline.
> > >
> > >  Simon
> > >
> > >Radim Kolarik wrote:
> > >
> > >
> > >
> > >>Oh, sorry about the stack trace, it only occurs with older version
> of
> > >>Tuscany when TuscanyServlet is used instead of filters.
> > >>
> > >>I am now using Tuscany snapshot from the Maven repository dated
> 4th
> > >>September, with filters set up in web.xml, but still no luck on
> > >>Websphere. There is now no warning or exception in the log, but
> the
> > >>service is not being picked up. It is being picked up in Tomcat.
> > >>
> > >>Do you have any ideas?
> > >>
> > >>Thanks,
> > >>Radim
> > >>
> > >>On 9/13/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> > >>
> > >>
> > >>
> > >>>Hi Yang,
> > >>>
> > >>>thank you for your suggestions.
> > >>>
> > >>>I am sure I use the correct root context, because I can access a
> JSP
> > >>>within the application successfully. It seems to me that the axis
> > >>>service is not being recognized at
> > >>>http://localhost:9201/contextRoot/componentName/serviceName.
> > >>>
> > >
> > >I think this might be connected with the port number.  If your
> > >.composite file just uses the  element with dynamic
> WSDL
> > >generation and no "uri" attribute, then Tuscany will construct a
> default
> > >URI.  There's a hardcoded port number of 8085 in the
> > >>>
> > >>>Axis2ServiceProvider
> > >>>
> > >code, but I think in a webapp environment Tuscany would look for
> the
> > >webapp server's configured port or fall back to 8080 if it doesn't
> know
> > >what this is.  (I'm not 100% sure of the details of how this
> works.)
> > 
> > 
> > 
> > That Axis2ServiceProvider has port 8085 hard coded is a bug.
> > Axis2ServiceProvider should only be registering the servlet with an
> > >>>
> > >>>explicit
> > >>>
> > port if  specifies an explicit port. If 
> doesn't
> > specify the port then its down to the ServletHost impl to use the
> > >>>
> > >>>default
> > >>>
> > one, and thats what our WebAppServletHost will do. If we remove the
> > hardcoded port 8085 in Axis2ServiceProvider this all works fine. The
> > Tuscany-Geronimo integration also has this problem which is why I
> was
> > >>>
> > >>>trying
> > >>>
> > to remove the hard coded port :)
> > 
> > >>>
> > >>>A couple of questions:
> > >>>
> > >>>1. In a WebSphere environment, can the WebAppServletHost get hold of
> the
> > >>>port number configured by WebSphere (9021 in this case)?
> > >>
> > >>
> > >>Its in the ServletRequest when a request comes in, but its not so easy
> to
> > >>find before a request (eg during init).
> > >>
> > >>2. Do you think at the moment it would try to use port 8085 in this
> case
> > >>
> > >>>even if the WSDL and/or binding URI settings specify 9021?  My
> > >>>experience (though not in a WebSphere environment) is that the
> WSDL
> > >>>and/or binding uri setttings override the default of 8085 if they
> > >>>are specified.
> > >>
> > >>
> > >>Right, if you specify an absolute uri in the binding.ws uri then that
> it
> > >>should use that, its only using the hardcoded 8085 when it doesn't
> have an
> > >>absolut

Re: websphere web service deployment problem

2007-09-13 Thread Radim Kolarik

Hi Simon,

please ignore the --, it was just added to thread by accident. The
file I work with is a valid XML file.

The URI even gets picked up from the .composite file during
inicialization, I get the addServletMapping:
/contextroot/ExampleComponent/ExampleService in the log file.

But I do not see any initContextPath: in the log, maybe that could be
signaling the problem?

Thanks,
Radim

On 9/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> Radim,
> What actually happens when you put this URI into a browser?
>
> I'm slightly surprised by the --> at the end of the binding.ws
> element.  I've only seen this in comments.
>
>   Simon
>
> Radim Kolarik wrote:
>
> > Hi Ant,
> >
> > I have specified absolute URI and it still doesn't work on Websphere:
> >
> > 
> > http://www.osoa.org/xmlns/sca/1.0";
> >   targetNamespace="http://company/examples/example-sc";
> >   xmlns:ex="http://company/examples/example-sc";
> > name="example-sc">
> >
> > 
> >   
> >   
> >> uri="http://localhost:9201/contextroot/ExampleComponent/ExampleService"/-->
> >   
> >   
> > 
> >
> > 
> >
> > Do you have an idea what could be the problem?
> >
> > Thanks,
> > Radim
> >
> >
> > On 9/13/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> >>On 9/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> >>
> >>>
> >>>ant elder wrote:
> >>>
> On 9/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> 
> 
> >See inline.
> >
> >  Simon
> >
> >Radim Kolarik wrote:
> >
> >
> >
> >>Oh, sorry about the stack trace, it only occurs with older version of
> >>Tuscany when TuscanyServlet is used instead of filters.
> >>
> >>I am now using Tuscany snapshot from the Maven repository dated 4th
> >>September, with filters set up in web.xml, but still no luck on
> >>Websphere. There is now no warning or exception in the log, but the
> >>service is not being picked up. It is being picked up in Tomcat.
> >>
> >>Do you have any ideas?
> >>
> >>Thanks,
> >>Radim
> >>
> >>On 9/13/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>
> >>>Hi Yang,
> >>>
> >>>thank you for your suggestions.
> >>>
> >>>I am sure I use the correct root context, because I can access a JSP
> >>>within the application successfully. It seems to me that the axis
> >>>service is not being recognized at
> >>>http://localhost:9201/contextRoot/componentName/serviceName.
> >>>
> >
> >I think this might be connected with the port number.  If your
> >.composite file just uses the  element with dynamic WSDL
> >generation and no "uri" attribute, then Tuscany will construct a default
> >URI.  There's a hardcoded port number of 8085 in the
> >>>
> >>>Axis2ServiceProvider
> >>>
> >code, but I think in a webapp environment Tuscany would look for the
> >webapp server's configured port or fall back to 8080 if it doesn't know
> >what this is.  (I'm not 100% sure of the details of how this works.)
> 
> 
> 
> That Axis2ServiceProvider has port 8085 hard coded is a bug.
> Axis2ServiceProvider should only be registering the servlet with an
> >>>
> >>>explicit
> >>>
> port if  specifies an explicit port. If  doesn't
> specify the port then its down to the ServletHost impl to use the
> >>>
> >>>default
> >>>
> one, and thats what our WebAppServletHost will do. If we remove the
> hardcoded port 8085 in Axis2ServiceProvider this all works fine. The
> Tuscany-Geronimo integration also has this problem which is why I was
> >>>
> >>>trying
> >>>
> to remove the hard coded port :)
> 
> >>>
> >>>A couple of questions:
> >>>
> >>>1. In a WebSphere environment, can the WebAppServletHost get hold of the
> >>>port number configured by WebSphere (9021 in this case)?
> >>
> >>
> >>Its in the ServletRequest when a request comes in, but its not so easy to
> >>find before a request (eg during init).
> >>
> >>2. Do you think at the moment it would try to use port 8085 in this case
> >>
> >>>even if the WSDL and/or binding URI settings specify 9021?  My
> >>>experience (though not in a WebSphere environment) is that the WSDL
> >>>and/or binding uri setttings override the default of 8085 if they
> >>>are specified.
> >>
> >>
> >>Right, if you specify an absolute uri in the binding.ws uri then that it
> >>should use that, its only using the hardcoded 8085 when it doesn't have an
> >>absolute uri.
> >>
> >>   ...ant
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---

Re: websphere web service deployment problem

2007-09-13 Thread Radim Kolarik

Hi Ant,

see my answers inline.

Thanks,
Radim

On 9/13/07, ant elder <[EMAIL PROTECTED]> wrote:
> Hard to say, could you answer these questions:
>
> Do you see anything in the log or console saying "addServletMapping:
> /ExampleComponent/ExampleService" to show the web service
> is getting registered?

Yes I do. This gets logged fine.

>
> There should also be another message logged during start up saying
> "initContextPath:", what does that message say?

This message doesn't get logged.

> How is the name "contextroot" that appears in some url's defined, is that
> the webapp name or something else?

Yes, that is the web app name, root context of application which you
can specify when deploying WAR to Websphere.

> In an earlier email you said when you do a ?wsdl it doesn't return anything,
> so what happens exactly- an http 404 or something else?

Yes, it is HTTP 404 Not Found.

>...ant
>
>
> On 9/13/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> > Hi Ant,
> >
> > I have specified absolute URI and it still doesn't work on Websphere:
> >
> > 
> > http://www.osoa.org/xmlns/sca/1.0";
> >
> targetNamespace="http://company/examples/example-sc";
> > xmlns:ex=" http://company/examples/example-sc";
> > name="example-sc">
> >
> > 
> > 
> > < interface.java interface="com.company.ExampleService"/>
> >>
> uri="http://localhost:9201/contextroot/ExampleComponent/ExampleService
> "/-->
> > 
> >   
> > 
> >
> > 
> >
> > Do you have an idea what could be the problem?
> >
> > Thanks,
> > Radim
> >
> >
> > On 9/13/07, ant elder <[EMAIL PROTECTED]> wrote:
> > > On 9/13/07, Simon Nash <[EMAIL PROTECTED] > wrote:
> > > >
> > > >
> > > > ant elder wrote:
> > > > > On 9/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >>See inline.
> > > > >>
> > > > >>   Simon
> > > > >>
> > > > >>Radim Kolarik wrote:
> > > > >>
> > > > >>
> > > > >>>Oh, sorry about the stack trace, it only occurs with older version
> of
> > > > >>>Tuscany when TuscanyServlet is used instead of filters.
> > > > >>>
> > > > >>>I am now using Tuscany snapshot from the Maven repository dated 4th
> > > > >>>September, with filters set up in web.xml, but still no luck on
> > > > >>>Websphere. There is now no warning or exception in the log, but the
> > > > >>>service is not being picked up. It is being picked up in Tomcat.
> > > > >>>
> > > > >>>Do you have any ideas?
> > > > >>>
> > > > >>>Thanks,
> > > > >>>Radim
> > > > >>>
> > > > >>>On 9/13/07, Radim Kolarik < [EMAIL PROTECTED]> wrote:
> > > > >>>
> > > > >>>
> > > > Hi Yang,
> > > > 
> > > > thank you for your suggestions.
> > > > 
> > > > I am sure I use the correct root context, because I can access a
> JSP
> > > > within the application successfully. It seems to me that the axis
> > > > service is not being recognized at
> > > >
> http://localhost:9201/contextRoot/componentName/serviceName
> .
> > > > 
> > > > >>
> > > > >>I think this might be connected with the port number.  If your
> > > > >>.composite file just uses the < binding.ws/> element with dynamic
> WSDL
> > > > >>generation and no "uri" attribute, then Tuscany will construct a
> default
> > > > >>URI.  There's a hardcoded port number of 8085 in the
> > > > Axis2ServiceProvider
> > > > >>code, but I think in a webapp environment Tuscany would look for the
> > > > >>webapp server's configured port or fall back to 8080 if it doesn't
> know
> > > > >>what this is.  (I'm not 100% sure of the details of how this works.)
> > > > >
> > > > >
> > > > >
> > > > > That Axis2ServiceProvider has port 8085 hard coded is a bug.
> > > > > Axis2ServiceProvider should only be registering the servlet with an
> > > > explicit
> > > > > port if  specifies an explicit port. If < binding.ws>
> doesn't
> > > > > specify the port then its down to the ServletHost impl to use the
> > > > default
> > > > > one, and thats what our WebAppServletHost will do. If we remove the
> > > > > hardcoded port 8085 in Axis2ServiceProvider this all works fine. The
> > > > > Tuscany-Geronimo integration also has this problem which is why I
> was
> > > > trying
> > > > > to remove the hard coded port :)
> > > > >
> > > > A couple of questions:
> > > >
> > > > 1. In a WebSphere environment, can the WebAppServletHost get hold of
> the
> > > > port number configured by WebSphere (9021 in this case)?
> > >
> > >
> > > Its in the ServletRequest when a request comes in, but its not so easy
> to
> > > find before a request (eg during init).
> > >
> > > 2. Do you think at the moment it would try to use port 8085 in this case
> > > > even if the WSDL and/or binding URI settings specify 9021?  My
> > > > experience (though not in a WebSphere environment) is that the
> WSDL
> > > > and/or binding uri setttings override the default of 8085 if they
> > > > are specified.
> > >
> > >
> > > Right, if you specify an absolute uri in the binding.ws uri the

Re: websphere web service deployment problem

2007-09-13 Thread Radim Kolarik

Hi Simon and Ant,

We have tried to put a port to ws.binding to reference an existing
WSDL, which had the correct port in, but without success. Also, we did
another test and tried to specify the uri attribute to binding.ws, but
it didn't work either.

I will now try to reconfigure websphere to port 8080 and see if it works.

Ant are you saying that the Websphere problem would get resolved if
the hardcoded port 8085 is removed from Tuscany code?

Thanks,
Radim

On 9/13/07, ant elder <[EMAIL PROTECTED]> wrote:
> On 9/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> >
> > See inline.
> >
> >Simon
> >
> > Radim Kolarik wrote:
> >
> > > Oh, sorry about the stack trace, it only occurs with older version of
> > > Tuscany when TuscanyServlet is used instead of filters.
> > >
> > > I am now using Tuscany snapshot from the Maven repository dated 4th
> > > September, with filters set up in web.xml, but still no luck on
> > > Websphere. There is now no warning or exception in the log, but the
> > > service is not being picked up. It is being picked up in Tomcat.
> > >
> > > Do you have any ideas?
> > >
> > > Thanks,
> > > Radim
> > >
> > > On 9/13/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> > >
> > >>Hi Yang,
> > >>
> > >>thank you for your suggestions.
> > >>
> > >>I am sure I use the correct root context, because I can access a JSP
> > >>within the application successfully. It seems to me that the axis
> > >>service is not being recognized at
> > >>http://localhost:9201/contextRoot/componentName/serviceName.
> > >>
> > I think this might be connected with the port number.  If your
> > .composite file just uses the  element with dynamic WSDL
> > generation and no "uri" attribute, then Tuscany will construct a default
> > URI.  There's a hardcoded port number of 8085 in the Axis2ServiceProvider
> > code, but I think in a webapp environment Tuscany would look for the
> > webapp server's configured port or fall back to 8080 if it doesn't know
> > what this is.  (I'm not 100% sure of the details of how this works.)
>
>
> That Axis2ServiceProvider has port 8085 hard coded is a bug.
> Axis2ServiceProvider should only be registering the servlet with an explicit
> port if  specifies an explicit port. If  doesn't
> specify the port then its down to the ServletHost impl to use the default
> one, and thats what our WebAppServletHost will do. If we remove the
> hardcoded port 8085 in Axis2ServiceProvider this all works fine. The
> Tuscany-Geronimo integration also has this problem which is why I was trying
> to remove the hard coded port :)
>
>   ...ant
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: websphere web service deployment problem

2007-09-13 Thread Simon Nash


See inline.

  Simon

Radim Kolarik wrote:


Oh, sorry about the stack trace, it only occurs with older version of
Tuscany when TuscanyServlet is used instead of filters.

I am now using Tuscany snapshot from the Maven repository dated 4th
September, with filters set up in web.xml, but still no luck on
Websphere. There is now no warning or exception in the log, but the
service is not being picked up. It is being picked up in Tomcat.

Do you have any ideas?

Thanks,
Radim

On 9/13/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:


Hi Yang,

thank you for your suggestions.

I am sure I use the correct root context, because I can access a JSP
within the application successfully. It seems to me that the axis
service is not being recognized at
http://localhost:9201/contextRoot/componentName/serviceName.


I think this might be connected with the port number.  If your
.composite file just uses the  element with dynamic WSDL
generation and no "uri" attribute, then Tuscany will construct a default
URI.  There's a hardcoded port number of 8085 in the Axis2ServiceProvider
code, but I think in a webapp environment Tuscany would look for the
webapp server's configured port or fall back to 8080 if it doesn't know
what this is.  (I'm not 100% sure of the details of how this works.)

In the WebSphere environment you are using a port number of 9201 but
Tuscany doesn't know about this port number.  Maybe there's an API we
could use to get it from WebSphere, or some configuration that could be
set to override the default 8080.  There was discussion on the list
(see [1]) about adding the ability to set a system property for the
default port number.  This would require the WebSphere startup
configuration to include this system property.  This would be better
than having the port number in the .composite file, as it would allow
the same war to be deployed on different servers that use different
port numbers.

To confirm that this is the problem, can you try adding an explicit
"uri" attribute to the  element?  (If you are using explicit
WSDL and specifying a port in , then you would need do this
in your WSDL port definition instead.)  The value of the "uri" attribute
is the full URI for the service, so in your case it is:
 http://localhost:9201/contextRoot/componentName/serviceName";>

If this works, then we know the port number is the problem.  The longer
term solution will be to provide a suitable way of configuring the port
so it's not hard wired into the .composite file.

  Simon

[1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg22977.html


It is very strange, because if I deploy the same WAR to Tomcat, it works fine.

We have also tried attaching a static WSDL file, again, that gets
displayed fine in Tomcat, but on Websphere, we get:

[9/13/07 12:36:14:309 IST] 0035 WebAppE   [Servlet
Error]-[TuscanyServlet]: java.lang.StringIndexOutOfBoundsException
  at java.lang.String.substring(String.java:1081)
  at 
org.apache.tuscany.sca.binding.ws.axis2.TuscanyListingAgent.setContextRoot(TuscanyListingAgent.java:286)
  at 
org.apache.tuscany.sca.binding.ws.axis2.TuscanyListingAgent.processListService(TuscanyListingAgent.java:102)
  at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.doGet(Axis2ServiceServlet.java:260)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
  at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.service(Axis2ServiceServlet.java:235)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
  at 
org.apache.tuscany.sca.host.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:77)
  at 
org.apache.tuscany.sca.host.webapp.TuscanyServlet.service(TuscanyServlet.java:63)
  at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:966)
  at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
  at 
com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:463)
  at 
com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:92)
  at 
com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:744)
  at 
com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1425)
  at 
com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:92)
  at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)
  at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394)
  at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:274)
  at 
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
  at 
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
  at 
com.ibm.ws.tcp.channel.impl

Re: websphere web service deployment problem

2007-09-13 Thread Radim Kolarik

Oh, sorry about the stack trace, it only occurs with older version of
Tuscany when TuscanyServlet is used instead of filters.

I am now using Tuscany snapshot from the Maven repository dated 4th
September, with filters set up in web.xml, but still no luck on
Websphere. There is now no warning or exception in the log, but the
service is not being picked up. It is being picked up in Tomcat.

Do you have any ideas?

Thanks,
Radim

On 9/13/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> Hi Yang,
>
> thank you for your suggestions.
>
> I am sure I use the correct root context, because I can access a JSP
> within the application successfully. It seems to me that the axis
> service is not being recognized at
> http://localhost:9201/contextRoot/componentName/serviceName.
>
> It is very strange, because if I deploy the same WAR to Tomcat, it works fine.
>
> We have also tried attaching a static WSDL file, again, that gets
> displayed fine in Tomcat, but on Websphere, we get:
>
> [9/13/07 12:36:14:309 IST] 0035 WebAppE   [Servlet
> Error]-[TuscanyServlet]: java.lang.StringIndexOutOfBoundsException
>at java.lang.String.substring(String.java:1081)
>at 
> org.apache.tuscany.sca.binding.ws.axis2.TuscanyListingAgent.setContextRoot(TuscanyListingAgent.java:286)
>at 
> org.apache.tuscany.sca.binding.ws.axis2.TuscanyListingAgent.processListService(TuscanyListingAgent.java:102)
>at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.doGet(Axis2ServiceServlet.java:260)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
>at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.service(Axis2ServiceServlet.java:235)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
>at 
> org.apache.tuscany.sca.host.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:77)
>at 
> org.apache.tuscany.sca.host.webapp.TuscanyServlet.service(TuscanyServlet.java:63)
>at 
> com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:966)
>at 
> com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
>at 
> com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:463)
>at 
> com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:92)
>at 
> com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:744)
>at 
> com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1425)
>at 
> com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:92)
>at 
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)
>at 
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394)
>at 
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:274)
>at 
> com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
>at 
> com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
>at 
> com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:152)
>at 
> com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:213)
>at 
> com.ibm.io.async.AbstractAsyncFuture.fireCompletionActions(AbstractAsyncFuture.java:195)
>at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
>at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:193)
>at 
> com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:725)
>at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:847)
>at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1498)
>
> Does that help?
>
> Thanks,
> Radim
>
> On 9/12/07, Yang Lei <[EMAIL PROTECTED]> wrote:
> > I assume you did all the following correct:
> >
> >   - I assume the context root is correct for the war: you can use WAS
> >   console to check the value
> >   - I assume the port is correct. E.g. in my env, 9081 is the default
> >   port for my war. You can also use WAS console to check the setting on
> >   virtualHost
> >   - I assume the componentName/ServiceName is the one you registered to
> >   Axis 2 engine? Can you do the following to make sure Axis 2 recognize the
> >   service? http://localhost:9201/contextRoot/componentName/serviceName if
> >   you can then you can try
> >   http://localhost:9201/contextRoot/componentName/serviceName/?wsdl
> >
> > Good luck.
> >
> > Yang.
> >
> >
> > On 9/12/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi all,
> > >
> > > We having problems deploying our services to Websphere. We have
> > > resolved some WAS classloading issues as was recommended

Re: websphere web service deployment problem

2007-09-13 Thread Radim Kolarik

Hi Yang,

thank you for your suggestions.

I am sure I use the correct root context, because I can access a JSP
within the application successfully. It seems to me that the axis
service is not being recognized at
http://localhost:9201/contextRoot/componentName/serviceName.

It is very strange, because if I deploy the same WAR to Tomcat, it works fine.

We have also tried attaching a static WSDL file, again, that gets
displayed fine in Tomcat, but on Websphere, we get:

[9/13/07 12:36:14:309 IST] 0035 WebAppE   [Servlet
Error]-[TuscanyServlet]: java.lang.StringIndexOutOfBoundsException
at java.lang.String.substring(String.java:1081)
at 
org.apache.tuscany.sca.binding.ws.axis2.TuscanyListingAgent.setContextRoot(TuscanyListingAgent.java:286)
at 
org.apache.tuscany.sca.binding.ws.axis2.TuscanyListingAgent.processListService(TuscanyListingAgent.java:102)
at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.doGet(Axis2ServiceServlet.java:260)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.service(Axis2ServiceServlet.java:235)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at 
org.apache.tuscany.sca.host.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:77)
at 
org.apache.tuscany.sca.host.webapp.TuscanyServlet.service(TuscanyServlet.java:63)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:966)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
at 
com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:463)
at 
com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:92)
at 
com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:744)
at 
com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1425)
at 
com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:92)
at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)
at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394)
at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:274)
at 
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at 
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at 
com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:152)
at 
com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:213)
at 
com.ibm.io.async.AbstractAsyncFuture.fireCompletionActions(AbstractAsyncFuture.java:195)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:193)
at 
com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:725)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:847)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1498)

Does that help?

Thanks,
Radim

On 9/12/07, Yang Lei <[EMAIL PROTECTED]> wrote:
> I assume you did all the following correct:
>
>   - I assume the context root is correct for the war: you can use WAS
>   console to check the value
>   - I assume the port is correct. E.g. in my env, 9081 is the default
>   port for my war. You can also use WAS console to check the setting on
>   virtualHost
>   - I assume the componentName/ServiceName is the one you registered to
>   Axis 2 engine? Can you do the following to make sure Axis 2 recognize the
>   service? http://localhost:9201/contextRoot/componentName/serviceName if
>   you can then you can try
>   http://localhost:9201/contextRoot/componentName/serviceName/?wsdl
>
> Good luck.
>
> Yang.
>
>
> On 9/12/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> >
> > Hi all,
> >
> > We having problems deploying our services to Websphere. We have
> > resolved some WAS classloading issues as was recommended by ant elder on
> > the user group, it seems that the initialization is without a problem
> > now. But the URL we are trying to map, e.g.
> > http://localhost:9201/contextRoot/componentName/serviceName?wsdl is not
> > returning anything.
> >
> > Is there anybody in Tuscany team who has tried deployment to Websphere?
> > The same WAR file seems to be working fine on Tomcat, however, not in
> > WAS 6.1.
> >
> > Thanks,
> > Radim
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

---

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

Re: websphere web service deployment problem

30 matches

Site Navigation

Mail list logo

Footer information