[jira] Updated: (AXIS2-2303) java2wsdl-maven-plugin throws ClassNotFoundException on execution of java2wsdl goal

[Shane Isbell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shane Isbell updated AXIS2-2303:


Attachment: patch-tests.zip

Tests for the patch.

> java2wsdl-maven-plugin throws ClassNotFoundException on execution of 
> java2wsdl goal
> ---
>
> Key: AXIS2-2303
> URL: https://issues.apache.org/jira/browse/AXIS2-2303
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: Tools
> Environment: Maven 2.0.5, Windows, JDK 1.5
>Reporter: Shane Isbell
>Priority: Minor
> Fix For: nightly
>
> Attachments: java2wsdl-plugin.patch, patch-tests.zip
>
>
> When invoking the java2wsdl maven plugin on a project, I receive a 
> java.lang.ClassNotFoundException. This is due to the maven plugin not adding 
> the pom dependencies to the option map ( which is fed into the class loader).
>   
> 
>   
> org.apache.axis2
> axis2-java2wsdl-maven-plugin
> 
>   
> 
>   java2wsdl
> 
>   
> 
> 
>   test.TestInterface
>   target/service.wsdl
> 
>   
> 
>   
> Stack Trace:
> [INFO] [axis2-java2wsdl:java2wsdl {execution: default}]
> java.lang.Exception: java.lang.ClassNotFoundException: test.TestInterface
> at 
> org.apache.ws.java2wsdl.Java2WSDLCodegenEngine.generate(Java2WSDLCode
> genEngine.java:58)
> at 
> org.apache.axis2.maven2.java2wsdl.Java2WSDLMojo.execute(Java2WSDLMojo
> .java:164)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:420)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:539)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:480)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:459)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:311)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:278)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: java.lang.ClassNotFoundException: test.TestInterface
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassL
> oader.java:195)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal
> m.java:255)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal
> m.java:274)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal
> m.java:274)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.
> java:214)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:242)
> at 
> org.apache.ws.java2wsdl.Java2WSDLUtils.namespaceFromClassName(Java2WS
> DLUtils.java:63)
> at 
> org.apache.ws.java2wsdl.Java2WSDLUtils.schemaNamespaceFromClassName(J
> ava2WSDLUtils.java:82)
> at 
> org.apache.ws.java2wsdl.Java2WSDLBuilder.getSchemaTargetNamespace(Jav
> a2WSDLBuilder.java:56)
> at 
> org.apache.ws.java2wsdl.Java2WSDLBuilder.generateWSDL(Java2WSDLBuilde
> r.java:152)
> at 
> org.apache.ws.jav

[jira] Updated: (AXIS2-2303) java2wsdl-maven-plugin throws ClassNotFoundException on execution of java2wsdl goal

[Shane Isbell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shane Isbell updated AXIS2-2303:


Attachment: java2wsdl-plugin.patch

Patch for this issue.

> java2wsdl-maven-plugin throws ClassNotFoundException on execution of 
> java2wsdl goal
> ---
>
> Key: AXIS2-2303
> URL: https://issues.apache.org/jira/browse/AXIS2-2303
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: Tools
> Environment: Maven 2.0.5, Windows, JDK 1.5
>Reporter: Shane Isbell
>Priority: Minor
> Fix For: nightly
>
> Attachments: java2wsdl-plugin.patch, patch-tests.zip
>
>
> When invoking the java2wsdl maven plugin on a project, I receive a 
> java.lang.ClassNotFoundException. This is due to the maven plugin not adding 
> the pom dependencies to the option map ( which is fed into the class loader).
>   
> 
>   
> org.apache.axis2
> axis2-java2wsdl-maven-plugin
> 
>   
> 
>   java2wsdl
> 
>   
> 
> 
>   test.TestInterface
>   target/service.wsdl
> 
>   
> 
>   
> Stack Trace:
> [INFO] [axis2-java2wsdl:java2wsdl {execution: default}]
> java.lang.Exception: java.lang.ClassNotFoundException: test.TestInterface
> at 
> org.apache.ws.java2wsdl.Java2WSDLCodegenEngine.generate(Java2WSDLCode
> genEngine.java:58)
> at 
> org.apache.axis2.maven2.java2wsdl.Java2WSDLMojo.execute(Java2WSDLMojo
> .java:164)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:420)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:539)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:480)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:459)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:311)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:278)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: java.lang.ClassNotFoundException: test.TestInterface
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassL
> oader.java:195)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal
> m.java:255)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal
> m.java:274)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal
> m.java:274)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.
> java:214)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:242)
> at 
> org.apache.ws.java2wsdl.Java2WSDLUtils.namespaceFromClassName(Java2WS
> DLUtils.java:63)
> at 
> org.apache.ws.java2wsdl.Java2WSDLUtils.schemaNamespaceFromClassName(J
> ava2WSDLUtils.java:82)
> at 
> org.apache.ws.java2wsdl.Java2WSDLBuilder.getSchemaTargetNamespace(Jav
> a2WSDLBuilder.java:56)
> at 
> org.apache.ws.java2wsdl.Java2WSDLBuilder.generateWSDL(Java2WSDLBuilde
> r.java:152)
> at 
> org.apach

[jira] Created: (AXIS2-2303) java2wsdl-maven-plugin throws ClassNotFoundException on execution of java2wsdl goal

[Shane Isbell (JIRA)]

java2wsdl-maven-plugin throws ClassNotFoundException on execution of java2wsdl 
goal
---

 Key: AXIS2-2303
 URL: https://issues.apache.org/jira/browse/AXIS2-2303
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: Tools
 Environment: Maven 2.0.5, Windows, JDK 1.5
Reporter: Shane Isbell
Priority: Minor
 Fix For: nightly


When invoking the java2wsdl maven plugin on a project, I receive a 
java.lang.ClassNotFoundException. This is due to the maven plugin not adding 
the pom dependencies to the option map ( which is fed into the class loader).

  

  
org.apache.axis2
axis2-java2wsdl-maven-plugin

  

  java2wsdl

  


  test.TestInterface
  target/service.wsdl

  

  

Stack Trace:

[INFO] [axis2-java2wsdl:java2wsdl {execution: default}]
java.lang.Exception: java.lang.ClassNotFoundException: test.TestInterface
at org.apache.ws.java2wsdl.Java2WSDLCodegenEngine.generate(Java2WSDLCode
genEngine.java:58)
at org.apache.axis2.maven2.java2wsdl.Java2WSDLMojo.execute(Java2WSDLMojo
.java:164)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:420)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:480)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:459)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:311)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:278)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.lang.ClassNotFoundException: test.TestInterface
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassL
oader.java:195)
at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal
m.java:255)
at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal
m.java:274)
at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal
m.java:274)
at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.
java:214)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at org.apache.ws.java2wsdl.Java2WSDLUtils.namespaceFromClassName(Java2WS
DLUtils.java:63)
at org.apache.ws.java2wsdl.Java2WSDLUtils.schemaNamespaceFromClassName(J
ava2WSDLUtils.java:82)
at org.apache.ws.java2wsdl.Java2WSDLBuilder.getSchemaTargetNamespace(Jav
a2WSDLBuilder.java:56)
at org.apache.ws.java2wsdl.Java2WSDLBuilder.generateWSDL(Java2WSDLBuilde
r.java:152)
at org.apache.ws.java2wsdl.Java2WSDLCodegenEngine.generate(Java2WSDLCode
genEngine.java:56)
... 19 more
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] java.lang.ClassNotFoundException: test.TestInterface


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTE

Axis2 LocalTransportReceiver

[Mark Badorrek]

I'm trying to call Axis2 using the LocalTransportReceiver and 
LocalTransportSender.
I already have the SOAP request in a string 'text'.
 
ByteArrayInputStream inboundMessage =  new 
ByteArrayInputStream(text.getBytes());
LocalTransportReceiver.CONFIG_CONTEXT = myAxisConfigContext;
LocalTransportSender sender = new LocalTransportSender();
LocalTransportReceiver receiver = new LocalTransportReceiver(sender);
receiver.processMessage(inboundMessage, new 
EndpointReference("axis2/services/myService/myOperation"));
 
All works well except that there is nowhere that I can set the outputstream on 
the sender.
Any ideas?
 
Chears,
 
Mark B
 

Michael Rheinheimer/Austin/IBM is out of the office.

[Michael Rheinheimer]

I will be out of the office starting  03/08/2007 and will not return until
03/19/2007.

If you need to reach me immediately, please try my personal cell phone at
512-797-6788.

You may also contact Carlton Mason or Ann Robinson, who both know my
backups for all related projects.

Thanks.
Mike

[jira] Commented: (AXIS2-1220) AxisServlet.initContextRoot assumes 1 level deep context

[Jeff Peterson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479449
 ] 

Jeff Peterson commented on AXIS2-1220:
--

I found a work-around for the problem:
 * Manually set contextRoot in axis2.xml
 * Set the "axis2.find.context" init-param to "false"  for AxisServlet in 
web.xml

The initContextRoot() is definitely problematic and should be fixed.  In lieu 
of that, the above works.

> AxisServlet.initContextRoot assumes 1 level deep context
> 
>
> Key: AXIS2-1220
> URL: https://issues.apache.org/jira/browse/AXIS2-1220
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 1.1
> Environment: all
>Reporter: Bob Stevenson
> Assigned To: Eran Chinthaka
>
> initContextRoot only grabs the first part of the context.  My context is 
> /shop/wsengine , but this routine sets the contextRoot to only /shop.
> Then getEPRsForService() seems to rely on this for building the endpoints, 
> which are incorrect.
> if (contextRoot == null) {
> String [] parts = JavaUtils.split(req.getContextPath(), '/');
> if (parts != null) {
> for (int i = 0; i < parts.length; i++) {
> if (parts[i].length() > 0) {
> contextRoot = parts[i]; 
> break;
> }
> }
> }
> if (contextRoot == null || req.getContextPath().equals("/")) {
> contextRoot = "/";
> }
> log.warn("contextRoot2: " + req.getContextPath());
> //configContext.setContextRoot(contextRoot);
> configContext.setContextRoot(req.getContextPath());
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Reopened: (AXIS2-1220) AxisServlet.initContextRoot assumes 1 level deep context

[Davanum Srinivas (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davanum Srinivas reopened AXIS2-1220:
-


Reopened as per last comment.

> AxisServlet.initContextRoot assumes 1 level deep context
> 
>
> Key: AXIS2-1220
> URL: https://issues.apache.org/jira/browse/AXIS2-1220
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 1.1
> Environment: all
>Reporter: Bob Stevenson
> Assigned To: Eran Chinthaka
>
> initContextRoot only grabs the first part of the context.  My context is 
> /shop/wsengine , but this routine sets the contextRoot to only /shop.
> Then getEPRsForService() seems to rely on this for building the endpoints, 
> which are incorrect.
> if (contextRoot == null) {
> String [] parts = JavaUtils.split(req.getContextPath(), '/');
> if (parts != null) {
> for (int i = 0; i < parts.length; i++) {
> if (parts[i].length() > 0) {
> contextRoot = parts[i]; 
> break;
> }
> }
> }
> if (contextRoot == null || req.getContextPath().equals("/")) {
> contextRoot = "/";
> }
> log.warn("contextRoot2: " + req.getContextPath());
> //configContext.setContextRoot(contextRoot);
> configContext.setContextRoot(req.getContextPath());
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (AXIS2-1220) AxisServlet.initContextRoot assumes 1 level deep context

[Jeff Peterson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479428
 ] 

Jeff Peterson commented on AXIS2-1220:
--

I think this issue needs to be reopened.  With the default configuration for 
Axis2 1.1.1 the problem still happens.

The culprit appears to be AxisServlet.initContextRoot().   By default it 
ignores the axis2.xml configuration options and attempts to find the context on 
its own.

> AxisServlet.initContextRoot assumes 1 level deep context
> 
>
> Key: AXIS2-1220
> URL: https://issues.apache.org/jira/browse/AXIS2-1220
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 1.1
> Environment: all
>Reporter: Bob Stevenson
> Assigned To: Eran Chinthaka
>
> initContextRoot only grabs the first part of the context.  My context is 
> /shop/wsengine , but this routine sets the contextRoot to only /shop.
> Then getEPRsForService() seems to rely on this for building the endpoints, 
> which are incorrect.
> if (contextRoot == null) {
> String [] parts = JavaUtils.split(req.getContextPath(), '/');
> if (parts != null) {
> for (int i = 0; i < parts.length; i++) {
> if (parts[i].length() > 0) {
> contextRoot = parts[i]; 
> break;
> }
> }
> }
> if (contextRoot == null || req.getContextPath().equals("/")) {
> contextRoot = "/";
> }
> log.warn("contextRoot2: " + req.getContextPath());
> //configContext.setContextRoot(contextRoot);
> configContext.setContextRoot(req.getContextPath());
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Problem with the namespace prefix in Axis

[Anne Thomas Manes]

Prefixes are significant when the XML message or a portion thereof is
being signed.

Anup -- you have to make sure you process the signature before Axis
begins to process it. Are you using WSS4J to process the signature?

If the application needs to maintain the contents of the original SOAP
message in its pure form, then you must use the Messaging API and
process the raw XML.

Anne

On 3/8/07, Tom Jordahl <[EMAIL PROTECTED]> wrote:





No, namespace prefixes are not significant in SOAP messages.  They are just
a shorthand.

Axis doesn't preserve them in any way (nor do most other toolkits that I am
aware of).




--

Tom Jordahl

Adobe ColdFusion Team

 


From: anup bansal [mailto:[EMAIL PROTECTED]
 Sent: Saturday, March 03, 2007 3:39 AM
 To: axis-dev@ws.apache.org
 Subject: Re: Problem with the namespace prefix in Axis





Hi All,





Has anyone never faced this problem before?


I debugged the Axis 1.4 code and found that during serialization of the
input


received, (Client respone handler), the URIs are mapped to default namespace
prefix values and the original prefixes received with the mesages are
ignored.


Is there a way to get around this and make Axis use the same prefixes as
recevied? Can I set some prameter in my client-config.wsdd to disable this?


I have already tried the
"enableNamespacePrefixOptimization" property but it too
does not work?





Please help me.. Its really very urgent.





Thanks & regards,


Anup

 Anne Thomas Manes <[EMAIL PROTECTED]> wrote:


As long as the prefix maps to the correct namespace URI, the messages
 are semantically identical. Your handler should be to handle any
 prefix string.

 Anne

 On 2/27/07, anup bansal wrote:
 > Hi All,
 >
 > I am using Axis 1.4 for accessing a third party weservice. I am able to
 > connect to the service and receive the response.
 >
 > The prefixes in the response I receive is not the same as the the one
sent
 > by the service. The difference lies in the name space prefix values.
 > As a result the response header is not being validated.
 >
 > Axis is replacing the namespace prefixes with its own prefix values.
 > For e.g. the prefix value sent for the SOAP Body is soap12, where as Axis
 > converts it into soapenv.
 >
 > Is this a bug in Axis or is there a way to get around this problem? Can
you
 > please help?
 >
 > Regards,
 > Anup
 >
 > 
 > Here's a new way to find what you're looking for - Yahoo! Answers
 >
 >

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




 


Here's a new way to find what you're looking for - Yahoo! Answers


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

Re: [axis2] Re: svn commit: r516065 - /webservices/rampart/trunk/java/modules/rampart-integration/src/test/resources/security/complete.service.xml

[Brian De Pradine]

Hi Ruchith,

I modified the code recently to only send the message id and the relates 
to headers in an async response. It is meant to be a small performance 
tweak.

Cheers

Brian DePradine
Web Services Development
IBM Hursley
External  +44 (0) 1962 816319 Internal 246319

If you can't find the time to do it right the first time, where will you 
find the time to do it again?


"Ruchith Fernando" <[EMAIL PROTECTED]> wrote on 08/03/2007 
16:05:52:

> resend with the axis2 prefix :-)
> 
> On 3/8/07, Ruchith Fernando <[EMAIL PROTECTED]> wrote:
> > Hi devs,
> >
> > We had a build break in Rampart due to the "MessageId" addressing
> > header being absent in the response message. Is this behavior correct?
> >
> > Thanks,
> > Ruchith
> >
> > On 3/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > Author: ruchithf
> > > Date: Thu Mar  8 07:00:53 2007
> > > New Revision: 516065
> > >
> > > URL: http://svn.apache.org/viewvc?view=rev&rev=516065
> > > Log:
> > > Fixed the build break, there's no wsa:MessageId header in the 
> response to sign
> > >
> > > Modified:
> > > webservices/rampart/trunk/java/modules/rampart-
> integration/src/test/resources/security/complete.service.xml
> > >
> > > Modified: webservices/rampart/trunk/java/modules/rampart-
> integration/src/test/resources/security/complete.service.xml
> > > URL: http://svn.apache.
> org/viewvc/webservices/rampart/trunk/java/modules/rampart-
> integration/src/test/resources/security/complete.service.xml?
> view=diff&rev=516065&r1=516064&r2=516065
> > > 
> 
==
> > > --- webservices/rampart/trunk/java/modules/rampart-
> integration/src/test/resources/security/complete.service.xml (original)
> > > +++ webservices/rampart/trunk/java/modules/rampart-
> integration/src/test/resources/security/complete.service.xml Thu Mar
> 8 07:00:53 2007
> > > @@ -22,7 +22,7 @@
> > > SKIKeyIdentifier
> > > 
> SKIKeyIdentifier
> > >  alice
> > > -{Element}{http://www.w3.
> org/2005/08/addressing}To;{Element}{http://www.w3.
> org/2005/08/addressing}ReplyTo;{Element}{http://www.w3.
> org/2005/08/addressing}MessageID;{Element}{http://docs.oasis-open.
> org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}
> Timestamp
> > > +{Element}{http://www.w3.
> org/2005/08/addressing}To;{Element}{http://www.w3.
> org/2005/08/addressing}ReplyTo;{Element}{http://docs.oasis-open.
> org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}
> Timestamp
> > >
> > >  //xenc:EncryptedData/xenc:
> CipherData/xenc:CipherValue
> > >
> > >
> > >
> > >
> >
> >
> > --
> > www.ruchith.org
> > www.wso2.org
> >
> 
> 
> -- 
> www.ruchith.org
> www.wso2.org
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[jira] Updated: (AXIS2-2302) java.lang.RuntimeException: Can not serialize OM Element Envelope

[Federica Ciotti (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Federica Ciotti updated AXIS2-2302:
---

Attachment: PublishClient.java

> java.lang.RuntimeException: Can not serialize OM Element Envelope
> -
>
> Key: AXIS2-2302
> URL: https://issues.apache.org/jira/browse/AXIS2-2302
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: databinding
>Affects Versions: 1.1.1
> Environment: Linux Fedora fc5, tomcat 6.0.7, java1.5.0_11, Axis2 1.1.1
>Reporter: Federica Ciotti
> Attachments: PublishClient.java
>
>
> Generated stub class from wsdl with xmlbeans, I'm able to call the 
> get_authToken method and
> I get "Can not serialize OM Element Envelope" exception when the object 
> returned by the save_business calling is a not empty object.
> I tried to run this method on the server side, calling the skeleton method 
> directly and everything is fine...
>  [java] Mar 8, 2007 6:10:17 PM 
> org.apache.axis2.deployment.DeploymentEngine doDeploy
>  [java] INFO: Deploying module : addressing-1.1.1
>  [java] Publish client - Client class generated with xmlbeans
>  [java] authToken:E3B38370-CD97-11DB-BC6F-D4E858BD4935
>  [java] 2.0
>  [java] jUDDI.org
>  [java] Mar 8, 2007 6:10:18 PM 
> org.apache.axis2.deployment.DeploymentEngine doDeploy
>  [java] INFO: Deploying module : addressing-1.1.1
>  [java] org.apache.axis2.AxisFault: java.lang.RuntimeException: Can not 
> serialize OM Element Envelope
>  [java] at 
> org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:271)
>  [java] at 
> org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:202)
>  [java] at 
> uddi_org.publication_v2.PublishSoapServiceStub.save_business(PublishSoapServiceStub.java:1836)
>  [java] at 
> uddi_org.uddi_client.PublishClient.saveBusiness(PublishClient.java:130)
>  [java] at 
> uddi_org.uddi_client.PublishClient.main(PublishClient.java:44)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (AXIS2-2302) java.lang.RuntimeException: Can not serialize OM Element Envelope

[Federica Ciotti (JIRA)]

java.lang.RuntimeException: Can not serialize OM Element Envelope
-

 Key: AXIS2-2302
 URL: https://issues.apache.org/jira/browse/AXIS2-2302
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: databinding
Affects Versions: 1.1.1
 Environment: Linux Fedora fc5, tomcat 6.0.7, java1.5.0_11, Axis2 1.1.1
Reporter: Federica Ciotti


Generated stub class from wsdl with xmlbeans, I'm able to call the 
get_authToken method and
I get "Can not serialize OM Element Envelope" exception when the object 
returned by the save_business calling is a not empty object.

I tried to run this method on the server side, calling the skeleton method 
directly and everything is fine...

 [java] Mar 8, 2007 6:10:17 PM org.apache.axis2.deployment.DeploymentEngine 
doDeploy
 [java] INFO: Deploying module : addressing-1.1.1
 [java] Publish client - Client class generated with xmlbeans
 [java] authToken:E3B38370-CD97-11DB-BC6F-D4E858BD4935
 [java] 2.0
 [java] jUDDI.org
 [java] Mar 8, 2007 6:10:18 PM org.apache.axis2.deployment.DeploymentEngine 
doDeploy
 [java] INFO: Deploying module : addressing-1.1.1
 [java] org.apache.axis2.AxisFault: java.lang.RuntimeException: Can not 
serialize OM Element Envelope
 [java] at 
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:271)
 [java] at 
org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:202)
 [java] at 
uddi_org.publication_v2.PublishSoapServiceStub.save_business(PublishSoapServiceStub.java:1836)
 [java] at 
uddi_org.uddi_client.PublishClient.saveBusiness(PublishClient.java:130)
 [java] at 
uddi_org.uddi_client.PublishClient.main(PublishClient.java:44)



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (AXIS-2635) File download fails without crimson

[Tom Jordahl (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479356
 ] 

Tom Jordahl commented on AXIS-2635:
---

Axis has always used Xerces, never crimson, so I am not sure why you would see 
something not working with Xerces.


> File download fails without crimson
> ---
>
> Key: AXIS-2635
> URL: https://issues.apache.org/jira/browse/AXIS-2635
> Project: Axis
>  Issue Type: Bug
>  Components: SAAJ
>Affects Versions: 1.4
>Reporter: Manuel Ernstberger
>
> If I download several files using soap with attachments and I have the 
> crimson.jar in the class path all files arrive correctly at the web service 
> client. But if I remove crimson.jar, some of the files don't arrive at the 
> client.
> As Crimson is an older xml parser I would prefer using a newer one like 
> Xerces. Do you have any idea why SAAJ doesn't work properly with other 
> parsers that Crimson?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

RE: Problem with the namespace prefix in Axis

[Tom Jordahl]

No, namespace prefixes are not significant in SOAP messages.  They are
just a shorthand.

Axis doesn't preserve them in any way (nor do most other toolkits that I
am aware of).

 

--

Tom Jordahl

Adobe ColdFusion Team



From: anup bansal [mailto:[EMAIL PROTECTED] 
Sent: Saturday, March 03, 2007 3:39 AM
To: axis-dev@ws.apache.org
Subject: Re: Problem with the namespace prefix in Axis

 

Hi All,

 

Has anyone never faced this problem before? 

I debugged the Axis 1.4 code and found that during serialization of the
input 

received, (Client respone handler), the URIs are mapped to default
namespace prefix values and the original prefixes received with the
mesages are ignored. 

Is there a way to get around this and make Axis use the same prefixes as
recevied? Can I set some prameter in my client-config.wsdd to disable
this?

I have already tried the "enableNamespacePrefixOptimization" property
but it too does not work?

 

Please help me.. Its really very urgent.

 

Thanks & regards,

Anup

Anne Thomas Manes <[EMAIL PROTECTED]> wrote:

As long as the prefix maps to the correct namespace URI, the
messages
are semantically identical. Your handler should be to handle any
prefix string.

Anne

On 2/27/07, anup bansal wrote:
> Hi All,
>
> I am using Axis 1.4 for accessing a third party weservice. I
am able to
> connect to the service and receive the response.
>
> The prefixes in the response I receive is not the same as the
the one sent
> by the service. The difference lies in the name space prefix
values.
> As a result the response header is not being validated.
>
> Axis is replacing the namespace prefixes with its own prefix
values.
> For e.g. the prefix value sent for the SOAP Body is soap12,
where as Axis
> converts it into soapenv.
>
> Is this a bug in Axis or is there a way to get around this
problem? Can you
> please help?
>
> Regards,
> Anup
>
> 
> Here's a new way to find what you're looking for - Yahoo!
Answers
>
>


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

 

  



Here's a new way to find what you're looking for - Yahoo! Answers
  

[axis2] Re: svn commit: r516065 - /webservices/rampart/trunk/java/modules/rampart-integration/src/test/resources/security/complete.service.xml

[Ruchith Fernando]

resend with the axis2 prefix :-)

On 3/8/07, Ruchith Fernando <[EMAIL PROTECTED]> wrote:

Hi devs,

We had a build break in Rampart due to the "MessageId" addressing
header being absent in the response message. Is this behavior correct?

Thanks,
Ruchith

On 3/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: ruchithf
> Date: Thu Mar  8 07:00:53 2007
> New Revision: 516065
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=516065
> Log:
> Fixed the build break, there's no wsa:MessageId header in the response to sign
>
> Modified:
> 
webservices/rampart/trunk/java/modules/rampart-integration/src/test/resources/security/complete.service.xml
>
> Modified: 
webservices/rampart/trunk/java/modules/rampart-integration/src/test/resources/security/complete.service.xml
> URL: 
http://svn.apache.org/viewvc/webservices/rampart/trunk/java/modules/rampart-integration/src/test/resources/security/complete.service.xml?view=diff&rev=516065&r1=516064&r2=516065
> ==
> --- 
webservices/rampart/trunk/java/modules/rampart-integration/src/test/resources/security/complete.service.xml
 (original)
> +++ 
webservices/rampart/trunk/java/modules/rampart-integration/src/test/resources/security/complete.service.xml
 Thu Mar  8 07:00:53 2007
> @@ -22,7 +22,7 @@
>  SKIKeyIdentifier
>  SKIKeyIdentifier
>  alice
> -
{Element}{http://www.w3.org/2005/08/addressing}To;{Element}{http://www.w3.org/2005/08/addressing}ReplyTo;{Element}{http://www.w3.org/2005/08/addressing}MessageID;{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp
> +
{Element}{http://www.w3.org/2005/08/addressing}To;{Element}{http://www.w3.org/2005/08/addressing}ReplyTo;{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp
>
>  
//xenc:EncryptedData/xenc:CipherData/xenc:CipherValue
>
>
>
>


--
www.ruchith.org
www.wso2.org




--
www.ruchith.org
www.wso2.org

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

Re: svn commit: r516065 - /webservices/rampart/trunk/java/modules/rampart-integration/src/test/resources/security/complete.service.xml

[Ruchith Fernando]

Hi devs,

We had a build break in Rampart due to the "MessageId" addressing
header being absent in the response message. Is this behavior correct?

Thanks,
Ruchith

On 3/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Author: ruchithf
Date: Thu Mar  8 07:00:53 2007
New Revision: 516065

URL: http://svn.apache.org/viewvc?view=rev&rev=516065
Log:
Fixed the build break, there's no wsa:MessageId header in the response to sign

Modified:

webservices/rampart/trunk/java/modules/rampart-integration/src/test/resources/security/complete.service.xml

Modified: 
webservices/rampart/trunk/java/modules/rampart-integration/src/test/resources/security/complete.service.xml
URL: 
http://svn.apache.org/viewvc/webservices/rampart/trunk/java/modules/rampart-integration/src/test/resources/security/complete.service.xml?view=diff&rev=516065&r1=516064&r2=516065
==
--- 
webservices/rampart/trunk/java/modules/rampart-integration/src/test/resources/security/complete.service.xml
 (original)
+++ 
webservices/rampart/trunk/java/modules/rampart-integration/src/test/resources/security/complete.service.xml
 Thu Mar  8 07:00:53 2007
@@ -22,7 +22,7 @@
 SKIKeyIdentifier
 SKIKeyIdentifier
 alice
-
{Element}{http://www.w3.org/2005/08/addressing}To;{Element}{http://www.w3.org/2005/08/addressing}ReplyTo;{Element}{http://www.w3.org/2005/08/addressing}MessageID;{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp
+
{Element}{http://www.w3.org/2005/08/addressing}To;{Element}{http://www.w3.org/2005/08/addressing}ReplyTo;{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp

 
//xenc:EncryptedData/xenc:CipherData/xenc:CipherValue
   






--
www.ruchith.org
www.wso2.org

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

Re: [Axis2] Move nustUnderstand check into a handler

[Glen Daniels]

Paul Fremantle wrote:

Cool! I'd love to implement this in Synapse too. Basically have a way
of defining the roles a Synapse node implements.


Yup - you'll just configure that in Synapse and then pass it down to Axis.

--G



Paul Fremantle wrote:
> David, Sanjiva
>
> Shouldn't we be using the SOAP role model to handle this kind of
> situation. It seems to me that what you are describing is a case where
> the Axis2 engine is not the ultimateReceiver (see 2.7 Relaying SOAP
> Messages http://www.w3.org/TR/soap12-part1/#relaysoapmsg).
>
> The right way to handle this is to identify what role the SOAP node
> that is Axis2 is playing and do mustUnderstand checking based on that
> model.

Incidentally, per the other thread [1] I'm going to be improving this
functionality very soon to add the capability for the engine (or
individual services / modules) to determine which roles are in play, and
only do the MU check on those roles.

We should also make sure to only PROCESS the headers targeted at those
roles, which will be a little more coordination work between Axis, OM,
and the Module writers.

--Glen

[1]
http://www.nabble.com/AxisEngine.checkMustUnderstand-enforcing-actor-roles--t3350540.html 



-
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: [Axis2] Move nustUnderstand check into a handler

[Paul Fremantle]

Cool! I'd love to implement this in Synapse too. Basically have a way
of defining the roles a Synapse node implements.

Paul

On 3/8/07, Glen Daniels <[EMAIL PROTECTED]> wrote:

Paul Fremantle wrote:
> David, Sanjiva
>
> Shouldn't we be using the SOAP role model to handle this kind of
> situation. It seems to me that what you are describing is a case where
> the Axis2 engine is not the ultimateReceiver (see 2.7 Relaying SOAP
> Messages http://www.w3.org/TR/soap12-part1/#relaysoapmsg).
>
> The right way to handle this is to identify what role the SOAP node
> that is Axis2 is playing and do mustUnderstand checking based on that
> model.

Incidentally, per the other thread [1] I'm going to be improving this
functionality very soon to add the capability for the engine (or
individual services / modules) to determine which roles are in play, and
only do the MU check on those roles.

We should also make sure to only PROCESS the headers targeted at those
roles, which will be a little more coordination work between Axis, OM,
and the Module writers.

--Glen

[1]
http://www.nabble.com/AxisEngine.checkMustUnderstand-enforcing-actor-roles--t3350540.html

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





--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

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

Re: wsdl4j license inconsistency

[Jeremy Hughes]

On 08/03/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote:

Jukka,

There may be a way out...check the JIRA :)


Maybe it hasn't been clear (sorry) ... the code in the JIRA is a
snapshot of WSDL4J 1.4. Axis2 uses WSDL4J 1.6.2 which isn't
contributed. So, the revisions to WSDL4J since 1.4 haven't been
contributed.

The way forward on this IMO, is for Axis2 to move to use Woden and not
WSDL4J. Woden doesn't yet support WSDL 1.1, but it does have an
intention to (although it doesn't have the intention of being a JSR
110 implementation).

Regards,
Jeremy

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

Re: [Axis2] Move nustUnderstand check into a handler

[Glen Daniels]

Paul Fremantle wrote:

David, Sanjiva

Shouldn't we be using the SOAP role model to handle this kind of
situation. It seems to me that what you are describing is a case where
the Axis2 engine is not the ultimateReceiver (see 2.7 Relaying SOAP
Messages http://www.w3.org/TR/soap12-part1/#relaysoapmsg).

The right way to handle this is to identify what role the SOAP node
that is Axis2 is playing and do mustUnderstand checking based on that
model.


Incidentally, per the other thread [1] I'm going to be improving this 
functionality very soon to add the capability for the engine (or 
individual services / modules) to determine which roles are in play, and 
only do the MU check on those roles.


We should also make sure to only PROCESS the headers targeted at those 
roles, which will be a little more coordination work between Axis, OM, 
and the Module writers.


--Glen

[1] 
http://www.nabble.com/AxisEngine.checkMustUnderstand-enforcing-actor-roles--t3350540.html


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

[jira] Commented: (AXIS2-2301) wsa 04 version problem - AxisFault Required MessageID in header in Response

[Gee Chia (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479327
 ] 

Gee Chia commented on AXIS2-2301:
-

Hi Brian:

Basically, I have a simple web service, ServiceB with "start" operation.  I 
sent the "start" request  using wsa 04, and include here is the TCPMon output 
of the request and response. See MessageID was not in the response header, and 
this caused the AxisFault I described. 
Please note: To get the Response as included below, I had commented the 
MessageID check in AdressingSubmissionInHandler::checkForMandatoryHeaders.

Let me know if you need additional information.

Request:
http://schemas.xmlsoap.org/ws/2004/08/addressing"; 
xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";>http://localhost:8090/wsmex/services/ServiceBhttp://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymousurn:uuid:D8E5E04CC4F721903D1173365825365http://services.example.org/mex/interop/startRequesthttp://services.example.org/mex/interop";>3


Response:

http://schemas.xmlsoap.org/ws/2004/08/addressing"; 
xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymoushttp://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymoushttp://services.example.org/mex/interop/startResponseurn:uuid:D8E5E04CC4F721903D1173365825365http://localhost:8090/wsmex/services/ServiceA



> wsa 04 version problem - AxisFault Required MessageID in header in Response
> ---
>
> Key: AXIS2-2301
> URL: https://issues.apache.org/jira/browse/AXIS2-2301
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: Addressing
>Affects Versions: 1.1.1
>Reporter: Gee Chia
> Assigned To: Brian DePradine
>
> A Web service request worked in wsa 1.0 but failed in wsa 04 with
> AxisFault: A required message information header, To, MessageID, or Action, 
> is not present. Basically, message ID was not set in MessageContext for a 
> Response was the cause of the AxisFault.
> The exception was thrown from the checkForMandatoryHeaders method in the 
> org.apache.axis2.handlers.addressing.AddressingSubmissionInHandler.
> As I understood from the code 
> inspection,AbstractInOutSyncMessageReceiver::receive() method invokes
> MessageContext outMsgContext = 
> MessageContextBuilder.createOutMessageContext(msgContext);
> The messageID is conditionally set in the outMsgContext. 
> Then later on, it failed with messageID not set fault. 
> The same transaction/request worked in wsa 1.0. It worked because 
> AddressingFinalInHandler::checkForMandatoryHeaders only checks for Action 
> only. 
> My code worked in Axis2 1.1,  but failed in nightly build. I checked Axis2 
> 1.1.1,  I saw AddressingSubmissionInHandler change was introduced in 1.1.1. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [Axis2] Move nustUnderstand check into a handler

[Paul Fremantle]

Doh! Yep thats what I meant.

Paul

On 3/8/07, Glen Daniels <[EMAIL PROTECTED]> wrote:

Paul Fremantle wrote:
> * it must fault if there are mustUnderstand headers targeted at its roles

MU headers that it doesn't actually understand, you mean. :)

--G

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





--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

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

Re: [Axis2] Move nustUnderstand check into a handler

[Glen Daniels]

Paul Fremantle wrote:

* it must fault if there are mustUnderstand headers targeted at its roles


MU headers that it doesn't actually understand, you mean. :)

--G

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

Re: [Axis2] Move nustUnderstand check into a handler

[Paul Fremantle]

Jeremy

I think maybe you've misread the spec.

Basically the relay attribute is a red-herring in this case, because I
for one have never seen a relay header. The model is actually
reasonably simple (excluding the relay attribute for the minute):
* headers that are not explicitly marked with a role default to be
targeted at the ultimateReceiver
* nodes should understand which roles they are playing. Any node must
always play the role of next.
* any node may process and remove any headers targeted at its roles
* it must fault if there are mustUnderstand headers targeted at its roles

Actual relaying is a further complexity but I think that is
irrelevant. The behaviour required in the previous note-chain is
exactly that provided by defining roles as I've described and as the
SOAP spec describes.

Paul

Suppose Axis2 is acting as a

On 3/8/07, Jeremy Hughes <[EMAIL PROTECTED]> wrote:

Hi guys ...

On 21/02/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> David, Sanjiva
>
> Shouldn't we be using the SOAP role model to handle this kind of
> situation. It seems to me that what you are describing is a case where
> the Axis2 engine is not the ultimateReceiver (see 2.7 Relaying SOAP
> Messages http://www.w3.org/TR/soap12-part1/#relaysoapmsg).
>
> The right way to handle this is to identify what role the SOAP node
> that is Axis2 is playing and do mustUnderstand checking based on that
> model.
>

AFAICS, headers which are mustUnderstand="true" can't be relayed (see 2.7.1):

The relay attribute information item has no effect on the SOAP
processing model when the header block also carries a mustUnderstand
attribute information item with a value of "true".

(btw: I'm working with David on this) I think embedding Axis2 into a
larger system such that the whole of the larger system acts as a
single SOAP node would be a useful use case - if for example code
running outside of Axis2 would like to 'understand' headers. By
separating these out into two nodes, it looks like those headers that
are mustUnderstand true / role next can't get relayed to the second
node.

This is all kinda moot anyway and Sanjiva's suggestion seems to be the
best (only?) way of achieving this ... because ... for the piece of
the larger system, that Axis2 might be a part of, to do *all* of the
mustUnderstand either the Axis2 processed headers must have already
been removed (AIUI typically they're not) or the metadata about
flagging a header as processed needs to be flowed outside of Axis2
into the 'larger system'.

So inserting a handler to flag headers as processed and then doing the
real processing in the larger system seems to be the only option. Any
other ideas?

Thanks,
Jeremy

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





--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

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

[jira] Commented: (AXIS2-2301) wsa 04 version problem - AxisFault Required MessageID in header in Response

[Brian DePradine (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479320
 ] 

Brian DePradine commented on AXIS2-2301:


Hi Gee,

Can you please provide some more details on the scenario that you are trying to 
run. Including the TCPMon output of the request and response messages would 
also be a great help.

> wsa 04 version problem - AxisFault Required MessageID in header in Response
> ---
>
> Key: AXIS2-2301
> URL: https://issues.apache.org/jira/browse/AXIS2-2301
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: Addressing
>Affects Versions: 1.1.1
>Reporter: Gee Chia
> Assigned To: Brian DePradine
>
> A Web service request worked in wsa 1.0 but failed in wsa 04 with
> AxisFault: A required message information header, To, MessageID, or Action, 
> is not present. Basically, message ID was not set in MessageContext for a 
> Response was the cause of the AxisFault.
> The exception was thrown from the checkForMandatoryHeaders method in the 
> org.apache.axis2.handlers.addressing.AddressingSubmissionInHandler.
> As I understood from the code 
> inspection,AbstractInOutSyncMessageReceiver::receive() method invokes
> MessageContext outMsgContext = 
> MessageContextBuilder.createOutMessageContext(msgContext);
> The messageID is conditionally set in the outMsgContext. 
> Then later on, it failed with messageID not set fault. 
> The same transaction/request worked in wsa 1.0. It worked because 
> AddressingFinalInHandler::checkForMandatoryHeaders only checks for Action 
> only. 
> My code worked in Axis2 1.1,  but failed in nightly build. I checked Axis2 
> 1.1.1,  I saw AddressingSubmissionInHandler change was introduced in 1.1.1. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Assigned: (AXIS2-2301) wsa 04 version problem - AxisFault Required MessageID in header in Response

[Brian DePradine (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian DePradine reassigned AXIS2-2301:
--

Assignee: Brian DePradine

> wsa 04 version problem - AxisFault Required MessageID in header in Response
> ---
>
> Key: AXIS2-2301
> URL: https://issues.apache.org/jira/browse/AXIS2-2301
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: Addressing
>Affects Versions: 1.1.1
>Reporter: Gee Chia
> Assigned To: Brian DePradine
>
> A Web service request worked in wsa 1.0 but failed in wsa 04 with
> AxisFault: A required message information header, To, MessageID, or Action, 
> is not present. Basically, message ID was not set in MessageContext for a 
> Response was the cause of the AxisFault.
> The exception was thrown from the checkForMandatoryHeaders method in the 
> org.apache.axis2.handlers.addressing.AddressingSubmissionInHandler.
> As I understood from the code 
> inspection,AbstractInOutSyncMessageReceiver::receive() method invokes
> MessageContext outMsgContext = 
> MessageContextBuilder.createOutMessageContext(msgContext);
> The messageID is conditionally set in the outMsgContext. 
> Then later on, it failed with messageID not set fault. 
> The same transaction/request worked in wsa 1.0. It worked because 
> AddressingFinalInHandler::checkForMandatoryHeaders only checks for Action 
> only. 
> My code worked in Axis2 1.1,  but failed in nightly build. I checked Axis2 
> 1.1.1,  I saw AddressingSubmissionInHandler change was introduced in 1.1.1. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [Axis2] Move nustUnderstand check into a handler

[Jeremy Hughes]

Hi guys ...

On 21/02/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:

David, Sanjiva

Shouldn't we be using the SOAP role model to handle this kind of
situation. It seems to me that what you are describing is a case where
the Axis2 engine is not the ultimateReceiver (see 2.7 Relaying SOAP
Messages http://www.w3.org/TR/soap12-part1/#relaysoapmsg).

The right way to handle this is to identify what role the SOAP node
that is Axis2 is playing and do mustUnderstand checking based on that
model.



AFAICS, headers which are mustUnderstand="true" can't be relayed (see 2.7.1):

The relay attribute information item has no effect on the SOAP
processing model when the header block also carries a mustUnderstand
attribute information item with a value of "true".

(btw: I'm working with David on this) I think embedding Axis2 into a
larger system such that the whole of the larger system acts as a
single SOAP node would be a useful use case - if for example code
running outside of Axis2 would like to 'understand' headers. By
separating these out into two nodes, it looks like those headers that
are mustUnderstand true / role next can't get relayed to the second
node.

This is all kinda moot anyway and Sanjiva's suggestion seems to be the
best (only?) way of achieving this ... because ... for the piece of
the larger system, that Axis2 might be a part of, to do *all* of the
mustUnderstand either the Axis2 processed headers must have already
been removed (AIUI typically they're not) or the metadata about
flagging a header as processed needs to be flowed outside of Axis2
into the 'larger system'.

So inserting a handler to flag headers as processed and then doing the
real processing in the larger system seems to be the only option. Any
other ideas?

Thanks,
Jeremy

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

Re: Article on using Axis2 and Spring

[Thilina Gunarathne]

+1..  Please go ahead...

~Thilina

On 3/8/07, robert lazarski <[EMAIL PROTECTED]> wrote:

Well written article, uses all the axis2 code already in place. If no
one objects I'd like to include the link in the site 'articles'
section.

Robert

On 3/8/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> In case you didn't see this.
>
> http://www.devx.com/Java/Article/33839
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> [EMAIL PROTECTED]
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> -
> 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]





--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/

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

Re: Article on using Axis2 and Spring

[robert lazarski]

Well written article, uses all the axis2 code already in place. If no
one objects I'd like to include the link in the site 'articles'
section.

Robert

On 3/8/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:

In case you didn't see this.

http://www.devx.com/Java/Article/33839

--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

-
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: wsdl4j license inconsistency

[Davanum Srinivas]

Jukka,

There may be a way out...check the JIRA :)

-- dims

On 3/8/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:

Hi,

On 3/8/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> AFAIK WSDL4J is pretty embedded into Axis2, because Axis2 uses it to
> dynamically create WSDL for POJO endpoints.

OK, thanks.

> It would be some significant effort to move to a non-CPL WSDL4J. I've
> never heard of anyone complaining about CPL before. Is it a real
> objection to CPL or simply "its not ASL".

I really don't know what's behind there. The customer in question is a
major software company so I believe they know what they're doing. It
might be a political issue.

BR,

Jukka Zitting

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





--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers

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

[jira] Created: (AXIS2-2301) wsa 04 version problem - AxisFault Required MessageID in header in Response

[Gee Chia (JIRA)]

wsa 04 version problem - AxisFault Required MessageID in header in Response
---

 Key: AXIS2-2301
 URL: https://issues.apache.org/jira/browse/AXIS2-2301
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: Addressing
Affects Versions: 1.1.1
Reporter: Gee Chia


A Web service request worked in wsa 1.0 but failed in wsa 04 with
AxisFault: A required message information header, To, MessageID, or Action, is 
not present. Basically, message ID was not set in MessageContext for a Response 
was the cause of the AxisFault.

The exception was thrown from the checkForMandatoryHeaders method in the 
org.apache.axis2.handlers.addressing.AddressingSubmissionInHandler.

As I understood from the code 
inspection,AbstractInOutSyncMessageReceiver::receive() method invokes
MessageContext outMsgContext = 
MessageContextBuilder.createOutMessageContext(msgContext);
The messageID is conditionally set in the outMsgContext. 

Then later on, it failed with messageID not set fault. 

The same transaction/request worked in wsa 1.0. It worked because 
AddressingFinalInHandler::checkForMandatoryHeaders only checks for Action only. 


My code worked in Axis2 1.1,  but failed in nightly build. I checked Axis2 
1.1.1,  I saw AddressingSubmissionInHandler change was introduced in 1.1.1. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [axis2] Re: svn commit: r516022 - /webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java

[Glen Daniels]

Thanks David.  I'll look through the archives - but I'd definitely like 
to see this fixed unless there's a really compelling reason not to do 
so.  I'll write again after a quick read. :)


If we want to have an interface that adds a generic OMElement to 
SOAPHeader, that's fine... but it's a convenience method which wraps the 
OMElement in a SOAPHeaderBlock.  From the model/API perspective, the 
only thing that should live in SOAPHeader are SOAPHeaderBlocks.


--Glen

David Illsley wrote:

Hi Glen,
I think this has been discussed before... the problem is that any
handler may add an OMElement as a child of the SOAPHeader per the
OMElement interface.

If this is to be fixed it's in Axiom, and I think there was some
justification for not changing this when it was brought up before...
but I can't remember what it was.

David

On 08/03/07, Glen Daniels <[EMAIL PROTECTED]> wrote:

Hi Asankha:

I assume this has already been reported as an Axis2 problem?  IMHO we
should just fix this on the A2 side and not write this kind of
bug-compatible code for Synapse.

--Glen

[EMAIL PROTECTED] wrote:
> Author: asankha
> Date: Thu Mar  8 04:30:44 2007
> New Revision: 516022
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=516022
> Log:
> Axis2 has a strange behaviour where some of the headers returned 
from getEnvelope().getHeader().examineAllHeaderBlocks() returns raw 
OMElements and not only SOAPHeaderBlock's - make our code resilient

>
> Modified:
> 
webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java 


>
> Modified: 
webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java 

> URL: 
http://svn.apache.org/viewvc/webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java?view=diff&rev=516022&r1=516021&r2=516022 

> 
== 

> --- 
webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java 
(original)
> +++ 
webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java 
Thu Mar  8 04:30:44 2007

> @@ -24,6 +24,7 @@
>  import org.apache.axiom.om.xpath.AXIOMXPath;
>  import org.apache.axiom.om.impl.llom.OMTextImpl;
>  import org.apache.axiom.om.impl.llom.OMElementImpl;
> +import org.apache.axiom.om.OMElement;
>  import org.apache.axis2.AxisFault;
>  import org.apache.axis2.addressing.EndpointReference;
>  import org.apache.axis2.addressing.RelatesTo;
> @@ -444,8 +445,14 @@
>  if (iter.hasNext()) {
>  sb.append(separator + "Headers : ");
>  while (iter.hasNext()) {
> -SOAPHeaderBlock header = (SOAPHeaderBlock) 
iter.next();
> -sb.append(separator + header.getLocalName() + " : " 
+ header.getText());

> +Object o = iter.next();
> +if (o instanceof SOAPHeaderBlock) {
> +SOAPHeaderBlock header = (SOAPHeaderBlock) o;
> +sb.append(separator + header.getLocalName() + " 
: " + header.getText());

> +} else if (o instanceof OMElement) {
> +OMElement headerElem = (OMElement) o;
> +sb.append(separator + headerElem.getLocalName() 
+ " : " + headerElem.getText());

> +}
>  }
>  }
>
>
>
>
> -
> 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: [axis2] Re: svn commit: r516022 - /webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java

[David Illsley]

Hi Glen,
I think this has been discussed before... the problem is that any
handler may add an OMElement as a child of the SOAPHeader per the
OMElement interface.

If this is to be fixed it's in Axiom, and I think there was some
justification for not changing this when it was brought up before...
but I can't remember what it was.

David

On 08/03/07, Glen Daniels <[EMAIL PROTECTED]> wrote:

Hi Asankha:

I assume this has already been reported as an Axis2 problem?  IMHO we
should just fix this on the A2 side and not write this kind of
bug-compatible code for Synapse.

--Glen

[EMAIL PROTECTED] wrote:
> Author: asankha
> Date: Thu Mar  8 04:30:44 2007
> New Revision: 516022
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=516022
> Log:
> Axis2 has a strange behaviour where some of the headers returned from 
getEnvelope().getHeader().examineAllHeaderBlocks() returns raw OMElements and not 
only SOAPHeaderBlock's - make our code resilient
>
> Modified:
> 
webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java
>
> Modified: 
webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java
> URL: 
http://svn.apache.org/viewvc/webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java?view=diff&rev=516022&r1=516021&r2=516022
> ==
> --- 
webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java
 (original)
> +++ 
webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java
 Thu Mar  8 04:30:44 2007
> @@ -24,6 +24,7 @@
>  import org.apache.axiom.om.xpath.AXIOMXPath;
>  import org.apache.axiom.om.impl.llom.OMTextImpl;
>  import org.apache.axiom.om.impl.llom.OMElementImpl;
> +import org.apache.axiom.om.OMElement;
>  import org.apache.axis2.AxisFault;
>  import org.apache.axis2.addressing.EndpointReference;
>  import org.apache.axis2.addressing.RelatesTo;
> @@ -444,8 +445,14 @@
>  if (iter.hasNext()) {
>  sb.append(separator + "Headers : ");
>  while (iter.hasNext()) {
> -SOAPHeaderBlock header = (SOAPHeaderBlock) iter.next();
> -sb.append(separator + header.getLocalName() + " : " + 
header.getText());
> +Object o = iter.next();
> +if (o instanceof SOAPHeaderBlock) {
> +SOAPHeaderBlock header = (SOAPHeaderBlock) o;
> +sb.append(separator + header.getLocalName() + " : " + 
header.getText());
> +} else if (o instanceof OMElement) {
> +OMElement headerElem = (OMElement) o;
> +sb.append(separator + headerElem.getLocalName() + " : " 
+ headerElem.getText());
> +}
>  }
>  }
>
>
>
>
> -
> 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]





--
David Illsley - IBM Web Services Development

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

[axis2] Re: svn commit: r516022 - /webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java

[Glen Daniels]

Hi Asankha:

I assume this has already been reported as an Axis2 problem?  IMHO we 
should just fix this on the A2 side and not write this kind of 
bug-compatible code for Synapse.


--Glen

[EMAIL PROTECTED] wrote:

Author: asankha
Date: Thu Mar  8 04:30:44 2007
New Revision: 516022

URL: http://svn.apache.org/viewvc?view=rev&rev=516022
Log:
Axis2 has a strange behaviour where some of the headers returned from 
getEnvelope().getHeader().examineAllHeaderBlocks() returns raw OMElements and 
not only SOAPHeaderBlock's - make our code resilient

Modified:

webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java

Modified: 
webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java
URL: 
http://svn.apache.org/viewvc/webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java?view=diff&rev=516022&r1=516021&r2=516022
==
--- 
webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java
 (original)
+++ 
webservices/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/core/axis2/Axis2MessageContext.java
 Thu Mar  8 04:30:44 2007
@@ -24,6 +24,7 @@
 import org.apache.axiom.om.xpath.AXIOMXPath;
 import org.apache.axiom.om.impl.llom.OMTextImpl;
 import org.apache.axiom.om.impl.llom.OMElementImpl;
+import org.apache.axiom.om.OMElement;
 import org.apache.axis2.AxisFault;
 import org.apache.axis2.addressing.EndpointReference;
 import org.apache.axis2.addressing.RelatesTo;
@@ -444,8 +445,14 @@
 if (iter.hasNext()) {
 sb.append(separator + "Headers : ");
 while (iter.hasNext()) {
-SOAPHeaderBlock header = (SOAPHeaderBlock) iter.next();
-sb.append(separator + header.getLocalName() + " : " + 
header.getText());
+Object o = iter.next();
+if (o instanceof SOAPHeaderBlock) {
+SOAPHeaderBlock header = (SOAPHeaderBlock) o;
+sb.append(separator + header.getLocalName() + " : " + 
header.getText());
+} else if (o instanceof OMElement) {
+OMElement headerElem = (OMElement) o;
+sb.append(separator + headerElem.getLocalName() + " : " + 
headerElem.getText());
+}
 }
 }
 




-
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: wsdl4j license inconsistency

[Jukka Zitting]

Hi,

On 3/8/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:

AFAIK WSDL4J is pretty embedded into Axis2, because Axis2 uses it to
dynamically create WSDL for POJO endpoints.


OK, thanks.


It would be some significant effort to move to a non-CPL WSDL4J. I've
never heard of anyone complaining about CPL before. Is it a real
objection to CPL or simply "its not ASL".


I really don't know what's behind there. The customer in question is a
major software company so I believe they know what they're doing. It
might be a political issue.

BR,

Jukka Zitting

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

Re: wsdl4j license inconsistency

[Paul Fremantle]

AFAIK WSDL4J is pretty embedded into Axis2, because Axis2 uses it to
dynamically create WSDL for POJO endpoints.

It would be some significant effort to move to a non-CPL WSDL4J. I've
never heard of anyone complaining about CPL before. Is it a real
objection to CPL or simply "its not ASL".

Paul

On 3/8/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:

Hi,

On 3/8/07, Jeremy Hughes <[EMAIL PROTECTED]> wrote:
> On 07/03/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> > Yep I guess. If CPL is really an issue for some people maybe we should
> > prompt IBM to donate as promised and Woden to build a version of
> > WSDL4J too.
>
> Although this is draft [1], it indicates CPL is ok to ship in binary
> form (with conditions)
>
> [1] http://people.apache.org/~cliffs/3party.html

Yes, I also think it should be fine, and having a CPL dependency in
axis2 and woden is certainly no problem in general.

For some reason (don't ask me) the legal department of my customer has
banned the use of CPL dependencies. I'd however want to use axis2 and
I'm trying to figure out how to best resolve this problem. How
critical the wsdl4j dependency is for axis2, i.e. what features would
I miss if I just removed the library? My use case is accessing an
existing SOAP endpoint.

BR,

Jukka Zitting

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





--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

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

Re: wsdl4j license inconsistency

[Jukka Zitting]

Hi,

On 3/8/07, Jeremy Hughes <[EMAIL PROTECTED]> wrote:

On 07/03/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> Yep I guess. If CPL is really an issue for some people maybe we should
> prompt IBM to donate as promised and Woden to build a version of
> WSDL4J too.

Although this is draft [1], it indicates CPL is ok to ship in binary
form (with conditions)

[1] http://people.apache.org/~cliffs/3party.html


Yes, I also think it should be fine, and having a CPL dependency in
axis2 and woden is certainly no problem in general.

For some reason (don't ask me) the legal department of my customer has
banned the use of CPL dependencies. I'd however want to use axis2 and
I'm trying to figure out how to best resolve this problem. How
critical the wsdl4j dependency is for axis2, i.e. what features would
I miss if I just removed the library? My use case is accessing an
existing SOAP endpoint.

BR,

Jukka Zitting

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

Re: wsdl4j license inconsistency

[Jeremy Hughes]

On 07/03/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:

Yep I guess. If CPL is really an issue for some people maybe we should
prompt IBM to donate as promised and Woden to build a version of
WSDL4J too.


Although this is draft [1], it indicates CPL is ok to ship in binary
form (with conditions)

[1] http://people.apache.org/~cliffs/3party.html

Jeremy

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

[jira] Commented: (AXIS2-2000) java.lang.RuntimeException: Unexpected subelement antal

[Ole Dalgaard (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479283
 ] 

Ole Dalgaard commented on AXIS2-2000:
-

OK,  interesting...
I wanted to test the testBad with the latest snapshot from 
http://people.apache.org/dist/axis2/nightly/axis2-SNAPSHOT.zip
It seems to be missing a lot of jar files, so I tried to copy the ones from 
axis2-1.1.1. It gives errors like this:

java.lang.NoSuchMethodError: 
org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder: method 
(Ljavax/xml/stream/XMLStreamReader;)V not found
at 
org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:43)
at 
org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:118)
at 
org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:77)
at 
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:357)
at 
org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:295)
at 
dk.test.axis2.MyTestWSServiceStub.getOtherFoo(MyTestWSServiceStub.java:533)
at dk.test.axis2.MyTestWSTest.testBad2(MyTestWSTest.java:94)

I guess it is caused by using wrong versions of the non axis2*.jar files. Where 
can I find the correct versions of these files? 



> java.lang.RuntimeException: Unexpected subelement antal
> ---
>
> Key: AXIS2-2000
> URL: https://issues.apache.org/jira/browse/AXIS2-2000
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: adb
>Affects Versions: 1.1.1
> Environment: jdk 1.4.2 and Windows XP
>Reporter: Ole Dalgaard
> Assigned To: Amila Chinthaka Suriarachchi
> Attachments: MyTestWS.wsdl, myTestWS.zip
>
>
> Using arrays in inherited types gives this error:
> java.lang.RuntimeException: java.lang.RuntimeException: Unexpected subelement 
> antal
>   at 
> dk.test.axis2.MyTestWSServiceStub.fromOM(MyTestWSServiceStub.java:6360)
>   at 
> dk.test.axis2.MyTestWSServiceStub.getOtherFoo(MyTestWSServiceStub.java:182)
>   at dk.test.axis2.MyTestWSTest.testBad2(MyTestWSTest.java:94)
> Caused by: java.lang.RuntimeException: Unexpected subelement antal
>   at 
> dk.test.axis2.MyTestWSServiceStub$Bar$Factory.parse(MyTestWSServiceStub.java:1189)
>   at 
> dk.test.axis2.MyTestWSServiceStub$OtherFoo$Factory.parse(MyTestWSServiceStub.java:3681)
>   at 
> dk.test.axis2.MyTestWSServiceStub$GetOtherFooResponse$Factory.parse(MyTestWSServiceStub.java:3200)
>   at 
> dk.test.axis2.MyTestWSServiceStub.fromOM(MyTestWSServiceStub.java:6312)
>   ... 21 more
> Preparing some test data for the issue, I guess I found another bug:
> java.lang.RuntimeException: java.lang.RuntimeException: Unsupported type null 
> FooBar
>   at 
> dk.test.axis2.MyTestWSServiceStub.fromOM(MyTestWSServiceStub.java:6360)
>   at 
> dk.test.axis2.MyTestWSServiceStub.getOtherBar(MyTestWSServiceStub.java:388)
>   at dk.test.axis2.MyTestWSTest.testBad(MyTestWSTest.java:78)
> Caused by: java.lang.RuntimeException: Unsupported type null FooBar
>   at 
> dk.test.axis2.MyTestWSServiceStub$ExtensionMapper.getTypeObject(MyTestWSServiceStub.java:4144)
>   at 
> dk.test.axis2.MyTestWSServiceStub$Bar$Factory.parse(MyTestWSServiceStub.java:1091)
>   at 
> dk.test.axis2.MyTestWSServiceStub$OtherBar$Factory.parse(MyTestWSServiceStub.java:4724)
>   at 
> dk.test.axis2.MyTestWSServiceStub$GetOtherBarResponse$Factory.parse(MyTestWSServiceStub.java:5465)
>   at 
> dk.test.axis2.MyTestWSServiceStub.fromOM(MyTestWSServiceStub.java:6340)
>   ... 21 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Article on using Axis2 and Spring

[Paul Fremantle]

In case you didn't see this.

http://www.devx.com/Java/Article/33839

--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

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

[jira] Resolved: (AXIS2-2300) Reviewed files in xdocs : spring, tcp-transport, toc, and transport-howto

[Chatra Nakkawita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chatra Nakkawita resolved AXIS2-2300.
-

Resolution: Fixed

reviewed and committed. Thanks,

Chatra

> Reviewed files in xdocs : spring, tcp-transport, toc, and transport-howto
> -
>
> Key: AXIS2-2300
> URL: https://issues.apache.org/jira/browse/AXIS2-2300
> Project: Axis 2.0 (Axis2)
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 1.1.1
> Environment: Windows XP
>Reporter: Marietta Lovendhal
> Fix For: 1.2, nightly
>
> Attachments: patchxdocs.patch
>
>
> Reviewed and made minor changes to the following files in xdocs: spring, 
> tcp-transport, toc, and transport-howto

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (AXIS2-1970) Enabling the cache gets stuck in a loop and creates a file that won't stop growing

[Thilina Gunarathne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thilina Gunarathne resolved AXIS2-1970.
---

Resolution: Fixed

Fixed not to fail even if the boundary is missing..

> Enabling the cache gets stuck in a loop and creates a file that won't stop 
> growing
> --
>
> Key: AXIS2-1970
> URL: https://issues.apache.org/jira/browse/AXIS2-1970
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>Affects Versions: 1.1.1
> Environment: Windows
>Reporter: Andrew York
> Assigned To: Thilina Gunarathne
>Priority: Blocker
>
> I marked this as a blocker because cache can't be enabled on the client side.
> The following program will create a file that does not stop growing until I 
> terminate the process:
> /*
>  * Copyright 2004,2005 The Apache Software Foundation.
>  *
>  * Licensed under the Apache License, Version 2.0 (the "License");
>  * you may not use this file except in compliance with the License.
>  * You may obtain a copy of the License at
>  *
>  *  http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  */
> import javax.activation.DataHandler;
> import javax.activation.FileDataSource;
> import org.apache.axiom.om.OMAbstractFactory;
> import org.apache.axiom.om.OMElement;
> import org.apache.axiom.om.OMFactory;
> import org.apache.axiom.om.OMNamespace;
> import org.apache.axiom.om.OMText;
> import org.apache.axis2.Constants;
> import org.apache.axis2.addressing.EndpointReference;
> import org.apache.axis2.client.Options;
> import org.apache.axis2.client.ServiceClient;
> import org.apache.axis2.context.ConfigurationContext;
> import org.apache.axis2.context.ConfigurationContextFactory;
> public class Client {
> public static void main(String[] args) throws Exception {
> 
>   String endPoint = 
> "http://localhost:9080/axis2/services/UserGuideSampleService";;
>   
> ConfigurationContext ctx = 
> ConfigurationContextFactory.createConfigurationContextFromFileSystem(".", 
> "client.axis2.xml");
> 
> ServiceClient client = new ServiceClient(ctx, null);
> Options options = new Options();
> options.setAction("urn:echo");
> options.setTo(new EndpointReference(endPoint));
> 
> options.setProperty(Constants.Configuration.CACHE_ATTACHMENTS,Constants.VALUE_TRUE);
> options.setProperty(Constants.Configuration.ATTACHMENT_TEMP_DIR, 
> "temp");
> options.setProperty(Constants.Configuration.FILE_SIZE_THRESHOLD, 
> "4000");
> client.setOptions(options);
> 
> OMElement response = client.sendReceive(getPayload("Hello world"));
> 
> System.out.println(response);
> 
> }
> 
> private static OMElement getPayload(String value) {
> OMFactory factory = OMAbstractFactory.getOMFactory();
> OMNamespace ns = 
> factory.createOMNamespace("http://ws.apache.org/axis2/xsd","ns1";);
> OMElement elem = factory.createOMElement("echo", ns);
> OMElement childElem = factory.createOMElement("param0", null);
> childElem.setText(value);
> elem.addChild(childElem);
> //User can set optimized to false by using the following
> //textData.doOptimize(false);
> return elem;
> }
> 
> }
> The file that is created contains the response plus a whole lot of 0xFFs.  A 
> hex dump of the file follow.  The beginning of the file is what is expected.  
> The rest isn't.
> http://ws.apache.org/axis2/xsd";>Hello 
> world
> 3C 3F 78 6D 6C 20 76 65 72 73 69 6F 6E 3D 27 31 2E 30 27 20 65 6E 63 6F 64 69 
> 6E 67 3D 27 55 54 46 2D 38 27 3F 3E 3C 73 6F 61 70 65 6E 76 3A 45 6E 76 65 6C 
> 6F 70 65 20 78 6D 6C 6E 73 3A 73 6F 61 70 65 6E 76 3D 22 68 74 74 70 3A 2F 2F 
> 73 63 68 65 6D 61 73 2E 78 6D 6C 73 6F 61 70 2E 6F 72 67 2F 73 6F 61 70 2F 65 
> 6E 76 65 6C 6F 70 65 2F 22 3E 3C 73 6F 61 70 65 6E 76 3A 48 65 61 64 65 72 20 
> 2F 3E 3C 73 6F 61 70 65 6E 76 3A 42 6F 64 79 3E 3C 6E 73 3A 65 63 68 6F 52 65 
> 73 70 6F 6E 73 65 20 78 6D 6C 6E 73 3A 6E 73 3D 22 68 74 74 70 3A 2F 2F 77 73 
> 2E 61 70 61 63 68 65 2E 6F 72 67 2F 61 78 69 73 32 2F 78 73 64 22 3E 3C 6E 73 
> 3A 72 65 74 75 72 6E 3E 48 65 6C 6C 6F 20 77 6F 72 6C 64 3C 2F 6E 73 3A 72 65 
> 74 75 72 6E 3E 3C 2F 6E 73 3A 65 63 68 6F 52 65 73 70 6F 6E 73 65 3E 3C 2F 73 
> 6F 61 70 65 6E 76 3A 42 6F 64 79 3E 3C 2F 73 6F 61 70 65 6E 76 3A 45 6E 76 65 
> 6C 6F 70 65 3E FF FF FF FF FF FF