[jira] [Created] (RAMPART-388) NPE in RampartUtil#setKeyIdentifierType (line #1389) wss (web service security options assertion) is null.

2012-09-18 Thread Stefan Vladov (JIRA) 
Stefan Vladov created RAMPART-388:
-

 Summary: NPE in RampartUtil#setKeyIdentifierType (line #1389) wss 
(web service security options assertion) is null.
 Key: RAMPART-388
 URL: https://issues.apache.org/jira/browse/RAMPART-388
 Project: Rampart
  Issue Type: Bug
  Components: rampart-core
Affects Versions: 1.6.2
Reporter: Stefan Vladov
Priority: Minor


When a security policy requires a token reference (instead of including the 
token directly) but there is no Wss10 or Wss11 assertion in the policy, Rampart 
throws a NPE in RampartUtil#setKeyIdentifierType (line #1389).
Neither of the assertions is obligatory and all the configuration settings in 
those assertions are optional. Wss4j will by default use Issuer+Serial 
reference identifier. As a workaround One could add an empty Wss10 or Wss11 
assertion in the policy but this is an inconvenience and is absolutely 
unnecessary.

A simple null check will solve the problem.

Thanks,
Stefan

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

[jira] [Updated] (RAMPART-388) NPE in RampartUtil#setKeyIdentifierType (line #1389) wss (web service security options assertion) is null.

2012-09-18 Thread Stefan Vladov (JIRA) 

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

Stefan Vladov updated RAMPART-388:
--

Description: 
When a security policy requires a token reference (instead of including the 
token directly) but there is no Wss10 or Wss11 assertion in the policy, Rampart 
throws a NPE in RampartUtil#setKeyIdentifierType (line #1389).
Neither of the assertions is obligatory and all the configuration settings in 
those assertions are optional. Wss4j will by default usees Issuer+Serial 
reference identifier. As a workaround one could add an empty Wss10 or Wss11 
assertion in the policy but this is an inconvenience and is absolutely 
unnecessary.

A simple null check will solve the problem.

Thanks,
Stefan

  was:
When a security policy requires a token reference (instead of including the 
token directly) but there is no Wss10 or Wss11 assertion in the policy, Rampart 
throws a NPE in RampartUtil#setKeyIdentifierType (line #1389).
Neither of the assertions is obligatory and all the configuration settings in 
those assertions are optional. Wss4j will by default use Issuer+Serial 
reference identifier. As a workaround One could add an empty Wss10 or Wss11 
assertion in the policy but this is an inconvenience and is absolutely 
unnecessary.

A simple null check will solve the problem.

Thanks,
Stefan


> NPE in RampartUtil#setKeyIdentifierType (line #1389) wss (web service 
> security options assertion) is null.
> --
>
> Key: RAMPART-388
> URL: https://issues.apache.org/jira/browse/RAMPART-388
> Project: Rampart
>  Issue Type: Bug
>  Components: rampart-core
>Affects Versions: 1.6.2
>Reporter: Stefan Vladov
>Priority: Minor
>
> When a security policy requires a token reference (instead of including the 
> token directly) but there is no Wss10 or Wss11 assertion in the policy, 
> Rampart throws a NPE in RampartUtil#setKeyIdentifierType (line #1389).
> Neither of the assertions is obligatory and all the configuration settings in 
> those assertions are optional. Wss4j will by default usees Issuer+Serial 
> reference identifier. As a workaround one could add an empty Wss10 or Wss11 
> assertion in the policy but this is an inconvenience and is absolutely 
> unnecessary.
> A simple null check will solve the problem.
> Thanks,
> Stefan

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

[jira] [Created] (RAMPART-389) RampartException: "Unexpected signature" thrown on client side when the service policy requires SignatureConfirmation and it is the only signed element.

2012-09-18 Thread Stefan Vladov (JIRA) 
Stefan Vladov created RAMPART-389:
-

 Summary: RampartException: "Unexpected signature" thrown on client 
side when the service policy requires SignatureConfirmation and it is the only 
signed element.
 Key: RAMPART-389
 URL: https://issues.apache.org/jira/browse/RAMPART-389
 Project: Rampart
  Issue Type: Bug
  Components: rampart-core
Affects Versions: 1.6.2
Reporter: Stefan Vladov


When validating signed parts the PolicyBasedResultsValidator does not handle 
SignatureConfirmation when receiving the service response. According to the 
security policy specification the wsse11:SignatureConfirmation element should 
be covered by the message signature, but rampart validator fails with 
"Unexpected signature" in case the SignatureConfirmation is the only signed 
thing in the response message, because it is not added to the list of expected 
signed parts/elements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

[jira] [Updated] (RAMPART-389) RampartException: "Unexpected signature" thrown on client side when the service policy requires SignatureConfirmation and it is the only signed element.

2012-09-18 Thread Stefan Vladov (JIRA) 

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

Stefan Vladov updated RAMPART-389:
--

Attachment: SignatureConfirmationPolicy.xml

Attaching the policy used to simulate the issue

> RampartException: "Unexpected signature" thrown on client side when the 
> service policy requires SignatureConfirmation and it is the only signed 
> element.
> 
>
> Key: RAMPART-389
> URL: https://issues.apache.org/jira/browse/RAMPART-389
> Project: Rampart
>  Issue Type: Bug
>  Components: rampart-core
>Affects Versions: 1.6.2
>Reporter: Stefan Vladov
> Attachments: SignatureConfirmationPolicy.xml
>
>
> When validating signed parts the PolicyBasedResultsValidator does not handle 
> SignatureConfirmation when receiving the service response. According to the 
> security policy specification the wsse11:SignatureConfirmation element should 
> be covered by the message signature, but rampart validator fails with 
> "Unexpected signature" in case the SignatureConfirmation is the only signed 
> thing in the response message, because it is not added to the list of 
> expected signed parts/elements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

[jira] [Updated] (RAMPART-389) RampartException: "Unexpected signature" thrown on client side when the service policy requires SignatureConfirmation and it is the only signed element.

2012-09-18 Thread Stefan Vladov (JIRA) 

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

Stefan Vladov updated RAMPART-389:
--

Attachment: SignatureConfirmationPatch.txt

Attached a simple patch with suggested solution.

> RampartException: "Unexpected signature" thrown on client side when the 
> service policy requires SignatureConfirmation and it is the only signed 
> element.
> 
>
> Key: RAMPART-389
> URL: https://issues.apache.org/jira/browse/RAMPART-389
> Project: Rampart
>  Issue Type: Bug
>  Components: rampart-core
>Affects Versions: 1.6.2
>Reporter: Stefan Vladov
> Attachments: SignatureConfirmationPatch.txt, 
> SignatureConfirmationPolicy.xml
>
>
> When validating signed parts the PolicyBasedResultsValidator does not handle 
> SignatureConfirmation when receiving the service response. According to the 
> security policy specification the wsse11:SignatureConfirmation element should 
> be covered by the message signature, but rampart validator fails with 
> "Unexpected signature" in case the SignatureConfirmation is the only signed 
> thing in the response message, because it is not added to the list of 
> expected signed parts/elements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

[jira] [Commented] (AXIS-2875) Axis not buildable with Java 1.6

2012-09-18 Thread Andreas Veithen (JIRA) 

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

Andreas Veithen commented on AXIS-2875:
---

There is one remaining issue with Java 1.6. 
ComplexEchoServiceTestCase#test2ComplexEchoServiceEcho21 fails with the 
following error:

org.xml.sax.SAXException: No deserializer for 
{http://www.w3.org/2001/XMLSchema}anyType
at 
org.apache.axis.encoding.ser.BeanDeserializer.onStartChild(BeanDeserializer.java:320)
at 
org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1052)
at 
org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:158)
at 
org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:1141)
at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:236)
at org.apache.axis.message.RPCElement.getParams(RPCElement.java:384)
at org.apache.axis.client.Call.invoke(Call.java:2467)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at 
test.wsdl.echo.ComplexEchoServiceSoapBindingStub.echo2(ComplexEchoServiceSoapBindingStub.java:255)
at 
test.wsdl.echo.ComplexEchoServiceTestCase.test2ComplexEchoServiceEcho21(ComplexEchoServiceTestCase.java:105)

This seems to be related by a difference in behavior when selecting the XML 
type for test.wsdl.echo.NamedValue[], as can be seen in the following debug 
logs.

Java 1.5:

15:48:36,735 [305967@qtp-25358555-3] DEBUG 
org.apache.axis.encoding.SerializationContext - Start serializing element; 
elemQName={http://types.echo.services}value; 
xmlType={http://www.w3.org/2001/XMLSchema}anyType; javaClass=class 
java.lang.Object; sendNull=null; sendType=null; 
value=[Ltest.wsdl.echo.NamedValue;@299629
15:48:36,735 [305967@qtp-25358555-3] DEBUG 
org.apache.axis.encoding.SerializationContext - Getting serializer for 
javaType=class [Ltest.wsdl.echo.NamedValue; and xmlType=null
15:48:36,735 [305967@qtp-25358555-3] DEBUG 
org.apache.axis.encoding.SerializationContext - Serializer is 
org.apache.axis.encoding.ser.ArraySerializer@b2175
15:48:36,735 [305967@qtp-25358555-3] DEBUG 
org.apache.axis.encoding.SerializationContext - Actual XML type is 
{http://types.echo.services}ArrayOfNamedValue
15:48:36,735 [305967@qtp-25358555-3] DEBUG 
org.apache.axis.encoding.SerializationContext - Start element 
{http://types.echo.services}value
15:48:36,735 [305967@qtp-25358555-3] DEBUG 
org.apache.axis.encoding.SerializationContext - Adding xsi:type attribute for 
type {http://types.echo.services}ArrayOfNamedValue

Java 1.6:

16:48:38,309 [371070192@qtp-15735326-3] DEBUG 
org.apache.axis.encoding.SerializationContext - Start serializing element; 
elemQName={http://types.echo.services}value; 
xmlType={http://www.w3.org/2001/XMLSchema}anyType; javaClass=class 
java.lang.Object; sendNull=null; sendType=null; 
value=[Ltest.wsdl.echo.NamedValue;@5afaa824
16:48:38,309 [371070192@qtp-15735326-3] DEBUG 
org.apache.axis.encoding.SerializationContext - Getting serializer for 
javaType=class [Ltest.wsdl.echo.NamedValue; and xmlType=null
16:48:38,309 [371070192@qtp-15735326-3] DEBUG 
org.apache.axis.encoding.SerializationContext - Serializer is 
org.apache.axis.encoding.ser.ArraySerializer@15b57dcb
16:48:38,309 [371070192@qtp-15735326-3] DEBUG 
org.apache.axis.encoding.SerializationContext - Actual XML type is 
{http://types.echo.services}>MyElement2Response
16:48:38,309 [371070192@qtp-15735326-3] DEBUG 
org.apache.axis.encoding.SerializationContext - Start element 
{http://types.echo.services}value


> Axis not buildable with Java 1.6
> 
>
> Key: AXIS-2875
> URL: https://issues.apache.org/jira/browse/AXIS-2875
> Project: Axis
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Andreas Veithen
>Assignee: Andreas Veithen
>Priority: Minor
> Fix For: 1.4.1
>
>
> Axis currently can't be built with Java 1.6. The reason is that Axis 
> implements an older version of the SAAJ specs, but Java 1.6 contains the 
> latest SAAJ version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

[jira] [Commented] (AXIS-2875) Axis not buildable with Java 1.6

2012-09-18 Thread Andreas Veithen (JIRA) 

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

Andreas Veithen commented on AXIS-2875:
---

Looks like this has to do with the fact that the order in which type mappings 
are defined in the generated WSDD file (see 
integration/target/work/test/wsdl/echo/deploy.wsdd) is different. That in turn 
appears to be connected to the order in which the methods of the service are 
processed:

Java 1.5:

  

Java 1.6:

  

> Axis not buildable with Java 1.6
> 
>
> Key: AXIS-2875
> URL: https://issues.apache.org/jira/browse/AXIS-2875
> Project: Axis
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Andreas Veithen
>Assignee: Andreas Veithen
>Priority: Minor
> Fix For: 1.4.1
>
>
> Axis currently can't be built with Java 1.6. The reason is that Axis 
> implements an older version of the SAAJ specs, but Java 1.6 contains the 
> latest SAAJ version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

Build failed in Jenkins: axis-trunk #136

2012-09-18 Thread Apache Jenkins Server 
See 

Changes:

[veithen] Improved debug logging.

--
[...truncated 681 lines...]
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running test.message.TestSOAPFault
Fault: java.lang.Exception: File already exists
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running test.message.TestMessageElement
http://xml.apache.org/axis/wsdd/"; 
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"; 
xmlns:ns1="urn:EchoAttachmentsService" 
xmlns:ns2="http://xml.apache.org/axis/wsdd/";>
  




  

 http://schemas.xmlsoap.org/soap/encoding/"; 
languageSpecificType="java:javax.activation.DataHandler" 
qname="ns1:DataHandler" 
serializer="org.apache.axis.encoding.ser.JAFDataHandlerSerializerFactory"/>
  



  
some text nodes insides
  

Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.07 sec
Running test.message.TestSOAPHeader
Element:http://www.jcommerce.net/soap/ns/SOAPHelloWorld";>
Tony
  
HEADER ELEMENT NAME:shw:Hello http://www.jcommerce.net/soap/ns/SOAPHelloWorld
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running test.components.TestUUID
1:  e678ca00-01aa-11e2-8eed-e94bb5960067
2:  e678f110-01aa-11e2-8eed-e94bb5960067
3:  e678f110-01aa-11e2-8eee-e94bb5960067
4:  e678f110-01aa-11e2-8eef-e94bb5960067
5:  e678f110-01aa-11e2-8ef0-e94bb5960067
6:  e678f110-01aa-11e2-8ef1-e94bb5960067
7:  e678f110-01aa-11e2-8ef2-e94bb5960067
8:  e678f110-01aa-11e2-8ef3-e94bb5960067
9:  e678f110-01aa-11e2-8ef4-e94bb5960067
10:  e678f110-01aa-11e2-8ef5-e94bb5960067
UUIDGen took 2 milliseconds
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.038 sec
Running test.utils.TestQName
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running test.utils.TestStringUtils
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running test.utils.TestMessages
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.348 sec
Running test.utils.cache.TestJavaMethod
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running test.utils.cache.TestJavaClass
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running test.utils.TestJavaUtils
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.017 sec
Running test.utils.TestNSStack
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.316 sec
Running test.utils.TestSrcContent
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.162 sec <<< 
FAILURE!
Running test.utils.TestXMLUtils
Tests run: 17, Failures: 0, Errors: 8, Skipped: 0, Time elapsed: 0.039 sec <<< 
FAILURE!
Running test.utils.bytecode.TestParamReader
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0 sec <<< 
FAILURE!
Running test.utils.bytecode.TestChainedParamReader
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.002 sec <<< 
FAILURE!
Running test.utils.bytecode.TestParamNameExtractor
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.001 sec <<< 
FAILURE!
Running test.properties.TestScopedProperties
org.apache.maven.surefire.util.SurefireReflectionException: 
java.lang.reflect.InvocationTargetException; nested exception is 
java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.NoClassDefFoundError: 
org/apache/axis/configuration/BasicServerConfig
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2395)
at java.lang.Class.getMethod0(Class.java:2642)
at java.lang.Class.getMethod(Class.java:1579)
at 
org.apache.maven.surefire.common.junit3.JUnit3Reflector.createInstanceFromSuiteMethod(JUnit3Reflector.java:152)
at 
org.apache.maven.surefire.common.junit3.JUnit3Reflector.constructTestObject(JUnit3Reflector.java:121)
at 
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:71)
at 
org.apache.maven.surefire.junit.JUnit3Provider.executeTes

[jira] [Commented] (AXIS2-5421) Axis2 Can't find ServletConfigParameter

2012-09-18 Thread Sunil Polineni (JIRA) 

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

Sunil Polineni commented on AXIS2-5421:
---

Any comments on above exception.

> Axis2 Can't find ServletConfigParameter
> ---
>
> Key: AXIS2-5421
> URL: https://issues.apache.org/jira/browse/AXIS2-5421
> Project: Axis2
>  Issue Type: Bug
>  Components: Addressing, deployment, wsdl
>Affects Versions: 1.4
> Environment: Weblogic 12.1 , spring
>Reporter: Moe Jalali
>  Labels: WSDeployment
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> I am migrating a web service to WebLogic 12.1 from WebSphere. I am getting 
> the error: 
> Axis2 Can't find ServletConfigParameter 
> which causes
> DeploymentException: The following error occurred during schema generation: 
> null
> I am using 1xis2 1.4 and spring. I have implemented the recommendations on 
> the site
> http://axis.apache.org/axis2/java/core/docs/spring.html
> to resolve weblogic and axis2 jar conflicts. Addressing and Rampart modules 
> engage okay. Error happens when making this call from the client
>   
> ConfigurationContextFactory.createConfigurationContextFromFileSystem("c:EdlService.ear/EdlService/WEB-INF","c:/EdlService.ear/EdlService/WEB-INF/conf/axis2.xml");
> 2012-09-13 12:58:46,112 ERROR org.apache.axis2.deployment.ServiceDeployer - 
> The EdlService service, which is not valid, caused The following error 
> occurred during schema generation: null
> org.apache.axis2.deployment.DeploymentException: The following error occurred 
> during schema generation: null
> at 
> org.apache.axis2.deployment.ServiceGroupBuilder.populateServiceGroup(ServiceGroupBuilder.java:106)
> at 
> org.apache.axis2.deployment.repository.util.ArchiveReader.buildServiceGroup(ArchiveReader.java:110)
> at 
> org.apache.axis2.deployment.repository.util.ArchiveReader.processServiceGroup(ArchiveReader.java:179)
> at 
> org.apache.axis2.deployment.ServiceDeployer.deploy(ServiceDeployer.java:81)
> at 
> org.apache.axis2.deployment.repository.util.DeploymentFileData.deploy(DeploymentFileData.java:136)
> at 
> org.apache.axis2.deployment.DeploymentEngine.doDeploy(DeploymentEngine.java:597)
> at 
> org.apache.axis2.deployment.repository.util.WSInfoList.update(WSInfoList.java:144)
> at 
> org.apache.axis2.deployment.RepositoryListener.update(RepositoryListener.java:330)
> at 
> org.apache.axis2.deployment.RepositoryListener.checkServices(RepositoryListener.java:227)
> at 
> org.apache.axis2.deployment.DeploymentEngine.loadServices(DeploymentEngine.java:131)
> at 
> org.apache.axis2.deployment.FileSystemConfigurator.loadServices(FileSystemConfigurator.java:147)
> at 
> org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:82)
> at 
> org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContextFromFileSystem(ConfigurationContextFactory.java:184)
> at 
> cbp.pspo.tm.edl.ws.externalWSClientStub.CbsaEdlService.createServiceStub(CbsaEdlService.java:109)
> at 
> cbp.pspo.tm.edl.ws.externalWSClientStub.CbsaEdlService.init(CbsaEdlService.java:96)
> CAUSED BY:
> Caused by: org.apache.axis2.AxisFault: Axis2 Can't find ServletConfigParameter
> at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
> at 
> org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier.getServiceObject(SpringServletContextObjectSupplier.java:86)
> ... 127 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

Jenkins build is back to normal : axis-trunk » Axis :: Core #137

2012-09-18 Thread Apache Jenkins Server 
See 


-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

Jenkins build is back to normal : axis-trunk #137

2012-09-18 Thread Apache Jenkins Server 
See 


-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

Build failed in Jenkins: axis-trunk #138

2012-09-18 Thread Apache Jenkins Server 
See 

Changes:

[veithen] Improved debug logging.

--
[...truncated 710 lines...]
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running test.message.TestSOAPFault
Fault: java.lang.Exception: File already exists
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running test.message.TestMessageElement
http://xml.apache.org/axis/wsdd/"; 
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"; 
xmlns:ns1="urn:EchoAttachmentsService" 
xmlns:ns2="http://xml.apache.org/axis/wsdd/";>
  




  

 http://schemas.xmlsoap.org/soap/encoding/"; 
languageSpecificType="java:javax.activation.DataHandler" 
qname="ns1:DataHandler" 
serializer="org.apache.axis.encoding.ser.JAFDataHandlerSerializerFactory"/>
  



  
some text nodes insides
  

Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.069 sec
Running test.message.TestSOAPHeader
Element:http://www.jcommerce.net/soap/ns/SOAPHelloWorld";>
Tony
  
HEADER ELEMENT NAME:shw:Hello http://www.jcommerce.net/soap/ns/SOAPHelloWorld
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running test.components.TestUUID
1:  a4b3f600-01b2-11e2-a6c2-837bd29d31ed
2:  a4b3f600-01b2-11e2-a6c3-837bd29d31ed
3:  a4b3f600-01b2-11e2-a6c4-837bd29d31ed
4:  a4b3f600-01b2-11e2-a6c5-837bd29d31ed
5:  a4b3f600-01b2-11e2-a6c6-837bd29d31ed
6:  a4b3f600-01b2-11e2-a6c7-837bd29d31ed
7:  a4b3f600-01b2-11e2-a6c8-837bd29d31ed
8:  a4b3f600-01b2-11e2-a6c9-837bd29d31ed
9:  a4b3f600-01b2-11e2-a6ca-837bd29d31ed
10:  a4b3f600-01b2-11e2-a6cb-837bd29d31ed
UUIDGen took 1 milliseconds
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec
Running test.utils.TestQName
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running test.utils.TestStringUtils
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running test.utils.TestMessages
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.288 sec
Running test.utils.cache.TestJavaMethod
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running test.utils.cache.TestJavaClass
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running test.utils.TestJavaUtils
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
Running test.utils.TestNSStack
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.305 sec
Running test.utils.TestSrcContent
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.342 sec <<< 
FAILURE!
Running test.utils.TestXMLUtils
Tests run: 17, Failures: 0, Errors: 8, Skipped: 0, Time elapsed: 0.038 sec <<< 
FAILURE!
Running test.utils.bytecode.TestParamReader
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.001 sec <<< 
FAILURE!
Running test.utils.bytecode.TestChainedParamReader
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.001 sec <<< 
FAILURE!
Running test.utils.bytecode.TestParamNameExtractor
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0 sec <<< 
FAILURE!
Running test.properties.TestScopedProperties
org.apache.maven.surefire.util.SurefireReflectionException: 
java.lang.reflect.InvocationTargetException; nested exception is 
java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.NoClassDefFoundError: 
org/apache/axis/configuration/BasicServerConfig
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2395)
at java.lang.Class.getMethod0(Class.java:2642)
at java.lang.Class.getMethod(Class.java:1579)
at 
org.apache.maven.surefire.common.junit3.JUnit3Reflector.createInstanceFromSuiteMethod(JUnit3Reflector.java:152)
at 
org.apache.maven.surefire.common.junit3.JUnit3Reflector.constructTestObject(JUnit3Reflector.java:121)
at 
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:71)
at 
org.apache.maven.surefire.junit.JUnit3Provider.executeTe

Jenkins build is back to normal : axis-trunk » Axis :: Core #139

2012-09-18 Thread Apache Jenkins Server 
See 


-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

Jenkins build is back to normal : axis-trunk #139

2012-09-18 Thread Apache Jenkins Server 
See 


-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

[jira] [Created] (AXIS-2876) Order of type mappings in generated WSDD depends on Java version

2012-09-18 Thread Andreas Veithen (JIRA) 
Andreas Veithen created AXIS-2876:
-

 Summary: Order of type mappings in generated WSDD depends on Java 
version
 Key: AXIS-2876
 URL: https://issues.apache.org/jira/browse/AXIS-2876
 Project: Axis
  Issue Type: Bug
  Components: WSDL processing
Affects Versions: 1.4
Reporter: Andreas Veithen
Priority: Minor
 Fix For: 1.4.1


The order of the type mappings in the WSDD generated by wsdl2java depends on 
the Java version and is not the same with Java 1.5 and 1.6. In principle this 
should not be a problem, but in some cases, a change in the order of type 
mappings triggers other issues. The consequence is that builds are not 
reproducible across different Java versions.

The issue can be demonstrated with the 
ComplexEchoServiceTestCase#test2ComplexEchoServiceEcho21 test case. The WSDD 
file for that test case has two type mappings for the 
test.wsdl.echo.NamedValue[] Java type:

  http://types.echo.services";
qname="ns:>MyElement2Response"
type="java:test.wsdl.echo.NamedValue[]"
innerType="cmp-ns:NamedValue" xmlns:cmp-ns="http://types.echo.services";
encodingStyle=""
  />

  http://types.echo.services";
qname="ns:ArrayOfNamedValue"
type="java:test.wsdl.echo.NamedValue[]"
innerType="cmp-ns:NamedValue" xmlns:cmp-ns="http://types.echo.services";
encodingStyle=""
  />

The test case attempts to serialize an instance of test.wsdl.echo.NamedValue[] 
as the value of an element with type xsd:anyType. In that case, Axis needs to 
identify the XML type in order to generate the xsi:type attribute. The code in 
TypeMappingImpl determines that XML type by looking at the last registered type 
mapping with the given Java type, and therefore the order of type mappings is 
relevant. With Java 1.5, the mapping with ns:ArrayOfNamedValue is registered 
last and the test case succeeds. With Java 1.6, the mapping with 
ns:>MyElement2Response is registered last. The test case fails because an 
anonymous type can't be used with xsi:type.

Obviously the real problem in this example is that Axis attempts to use an 
anonymous type where this is not possible. Nevertheless, this kind of issue 
should not be triggered by a change of the Java version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

[jira] [Updated] (AXIS-2876) Order of type mappings in generated WSDD depends on Java version

2012-09-18 Thread Andreas Veithen (JIRA) 

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

Andreas Veithen updated AXIS-2876:
--

Attachment: AXIS-2876.patch

Attached patch with the necessary changes to make WSDD files independent of the 
Java version. Note that before applying that change, we need to complete the 
migration of test cases to the Maven build.

> Order of type mappings in generated WSDD depends on Java version
> 
>
> Key: AXIS-2876
> URL: https://issues.apache.org/jira/browse/AXIS-2876
> Project: Axis
>  Issue Type: Bug
>  Components: WSDL processing
>Affects Versions: 1.4
>Reporter: Andreas Veithen
>Priority: Minor
> Fix For: 1.4.1
>
> Attachments: AXIS-2876.patch
>
>
> The order of the type mappings in the WSDD generated by wsdl2java depends on 
> the Java version and is not the same with Java 1.5 and 1.6. In principle this 
> should not be a problem, but in some cases, a change in the order of type 
> mappings triggers other issues. The consequence is that builds are not 
> reproducible across different Java versions.
> The issue can be demonstrated with the 
> ComplexEchoServiceTestCase#test2ComplexEchoServiceEcho21 test case. The WSDD 
> file for that test case has two type mappings for the 
> test.wsdl.echo.NamedValue[] Java type:
>xmlns:ns="http://types.echo.services";
> qname="ns:>MyElement2Response"
> type="java:test.wsdl.echo.NamedValue[]"
> innerType="cmp-ns:NamedValue" 
> xmlns:cmp-ns="http://types.echo.services";
> encodingStyle=""
>   />
>xmlns:ns="http://types.echo.services";
> qname="ns:ArrayOfNamedValue"
> type="java:test.wsdl.echo.NamedValue[]"
> innerType="cmp-ns:NamedValue" 
> xmlns:cmp-ns="http://types.echo.services";
> encodingStyle=""
>   />
> The test case attempts to serialize an instance of 
> test.wsdl.echo.NamedValue[] as the value of an element with type xsd:anyType. 
> In that case, Axis needs to identify the XML type in order to generate the 
> xsi:type attribute. The code in TypeMappingImpl determines that XML type by 
> looking at the last registered type mapping with the given Java type, and 
> therefore the order of type mappings is relevant. With Java 1.5, the mapping 
> with ns:ArrayOfNamedValue is registered last and the test case succeeds. With 
> Java 1.6, the mapping with ns:>MyElement2Response is registered last. The 
> test case fails because an anonymous type can't be used with xsi:type.
> Obviously the real problem in this example is that Axis attempts to use an 
> anonymous type where this is not possible. Nevertheless, this kind of issue 
> should not be triggered by a change of the Java version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org