Unencrypted Communications are disallowed - autonomy

I am trying to leverage the IDOL Web API (if that is its name) so that I can programmatically validate document creation/modification actions triggering an IDOL crawl of said document. We had a situation where a few documents were seemingly crawled by IDOL, but never made it to one of the 13 content engines. What I want to do is execute a script hourly to quickly validate that all documents created/modified in the preceding hour are in the IDOL index. This should be "easy" based upon some of the examples I have found.
Executing this http://[server]:9000/ACTION=licenseInfo and I get this response in the browser:
<?xml version="1.0" encoding="UTF-8" ?>
- <autnresponse xmlns:autn="http://schemas.autonomy.com/aci/">
<action>LICENSEINFO</action>
<response>ERROR</response>
- <responsedata>
- <error>
<errorid>IDOLPROXYLICENSEINFO-2147441838</errorid>
<rawerrorid>0x8000A352</rawerrorid>
<errorstring>Unencrypted communications are disallowed</errorstring>
<errorcode>ERRORENCRYPTIONFAILED</errorcode>
<errortime>08 Aug 12 10:23:02</errortime>
</error>
</responsedata>
</autnresponse>
Executing this http://[server]:9000/ACTION=query&text=toys and I get this:
<?xml version="1.0" encoding="UTF-8" ?>
- <autnresponse xmlns:autn="http://schemas.autonomy.com/aci/">
<action>QUERY</action>
<response>ERROR</response>
- <responsedata>
- <error>
<errorid>IDOLPROXYQUERY-2147441838</errorid>
<rawerrorid>0x8000A352</rawerrorid>
<errorstring>Unencrypted communications are disallowed</errorstring>
<errorcode>ERRORENCRYPTIONFAILED</errorcode>
<errortime>08 Aug 12 10:26:40</errortime>
</error>
</responsedata>
</autnresponse>
Is there something I am missing in my IIS setup?

I asked this question in another forum that seems to be more active for users of the Autonomy/Interwoven suite of products. Basically, the version of the IDOL indexer that comes built-in with the WorkSite Indexer does not allow Web API calls.

Related

WAZUH/OSSEC - overwriting rules doesn't seem to work

I'm trying to overwrite a rule as per documentation, like this
https://documentation.wazuh.com/3.12/learning-wazuh/replace-stock-rule.html
So I've copied one rule to local_rules.xml, created my own group (prior to that also tried to put it within the rule's original group tag), but it seems to be completely ignoring it:
This is what I've put in local_rules.xml:
<group name="istvan">
<rule frequency="8" id="31533" level="9" overwrite="yes" timeframe="20">
<if_matched_sid>31530</if_matched_sid>
<same_source_ip/>
<description>High amount of POST requests in a small period of time (likely bot).</description>
<group>pci_dss_6.5,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SA.11,nist_800_53_SI.4,</group>
</rule>
</group>
I've only changed the level to 9 and added the overwrite="yes" tag. The idea is that it doesn't send me this alerts (as my treshold is set to level 10+), save, restart, but it's completely ignoring it, and I'm stil getting those alerts with level 10 tag.
Frankly, I'm starting to be clueless why is it happening.
Any ideas?
Thanks.
A good way to test the expected behaviour would be using /var/ossec/bin/ossec-logtest as mentioned in that doc.
To elaborate i will take the example of that doc :
I will overwrite the rule 5716 : https://github.com/wazuh/wazuh-ruleset/blob/317052199f751e5ea936730710b71b27fdfe2914/rules/0095-sshd_rules.xml#L121, as below :
[root#localhost vagrant]# egrep -iE "ssh" /var/ossec/etc/rules/local_rules.xml -B 4 -A 3
<rule id="5716" overwrite="yes" level="9">
<if_sid>5700</if_sid>
<match>^Failed|^error: PAM: Authentication</match>
<description>sshd: authentication failed.</description>
<group>authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,</group>
</rule>
The logs can be tested without having to restart the Wazuh manager, Opening /var/ossec/bin/ossec-logtest then pasting my log :
2020/05/26 09:03:00 ossec-testrule: INFO: Started (pid: 9849).
ossec-testrule: Type one log per line.
Oct 23 17:27:17 agent sshd[8221]: Failed password for root from ::1 port 60164 ssh2
**Phase 1: Completed pre-decoding.
full event: 'Oct 23 17:27:17 agent sshd[8221]: Failed password for root from ::1 port 60164 ssh2'
timestamp: 'Oct 23 17:27:17'
hostname: 'agent'
program_name: 'sshd'
log: 'Failed password for root from ::1 port 60164 ssh2'
**Phase 2: Completed decoding.
decoder: 'sshd'
dstuser: 'root'
srcip: '::1'
srcport: '60164'
**Phase 3: Completed filtering (rules).
Rule id: '5716'
Level: '9'
Description: 'sshd: authentication failed.'
As expected the level has been overwriting which was initially 5. Although in your case, you will have to paste the log 8 times in timeframe lower than 20 s to be able to trigger that rule.
If you can share the logs triggering that alert, i can test with it.
On the other hand, you can create a sibling rule to simply ignore your rule 31533, something similar to below :
<rule id="100010" level="2">
<if_sid>31533</if_sid>
<description>Ignore rule 31533</description>
</rule>
Make sure to restart the Wazuh manager afterward to apply the change.
You can find more information about customizing rules/decoders here : https://wazuh.com/blog/creating-decoders-and-rules-from-scratch/
Hope this helps,
After finally talking to the developers, it turns out that it was indeed ignoring local_rules.xml. I had a strage exclusion of one rule (probably a problematic syntax, although it did't report an error)
"rule_exclude": [
"31151"
When I removed it, it started working as described in the user's guide.

Spring Boot Multipart File Upload Size Inconsistency

I have an endpoint that uploads an image file to the server, then to S3.
When I run on localhost, the MultipartFile byte size is correct, and the upload is successful.
However, the moment I deploy it to my EC2 instance the uploaded file size is incorrect.
Controller Code
#PostMapping("/{id}/photos")
fun addPhotos(#PathVariable("id") id: Long,
#RequestParam("file") file: MultipartFile,
jwt: AuthenticationJsonWebToken) = ApiResponse.success(propertyBLL.addPhotos(id, file, jwt))
Within the PropertyBLL.addPhotos method, printing file.size results in the wrong size.
Actual file size is 649305 bytes, however when uploaded to my prod server it reads as 1189763 bytes.
My production server is an AWS EC2 instance, behind Https.
The Spring application yml files are the same. The only configurations I overrode were the file max size properties.
I'm using PostMan to Post the request. I'm passing the body as form-data, key named "file".
Again, it works perfectly when running locally.
I did another test where I wrote the uploaded file to the server so I could compare.
Uploaded file's first n bytes in Hex editor:
EFBFBD50 4E470D0A 1A0A0000 000D4948 44520000 03000000 02400802 000000EF BFBDCC96 01000000 0467414D 410000EF BFBDEFBF BD0BEFBF BD610500 00002063 48524D00 007A2600
Original file's first n bytes:
89504E47 0D0A1A0A 0000000D 49484452 00000300 00000240 08020000 00B5CC96 01000000 0467414D 410000B1 8F0BFC61 05000000 20634852 4D00007A 26000080 840000FA 00000080
They both appear to have the text "PNG" in them and also have the ending EXtdate:modify/create markers.
Per Request, the core contents of addPhoto:
val metadata = ObjectMetadata()
metadata.contentLength = file.size
metadata.contentType = "image/png"
LOGGER.info("Uploading image of size {} bytes, name: {}", file.size, file.originalFilename)
val request = PutObjectRequest(awsProperties.cdnS3Bucket, imageName, file.inputStream, metadata)
awsSdk.putObject(request)
This works when I run web server locally. imageName is just a custom built name. There is other code involving hibernate models, but is not relevant.
Update
This appears to be Https/api proxy related. When I hit the EC2 node's http url, it works fine. However, when I go through the api proxy (https://api.thedomain.com), which proxies to the EC2 node, it fails. I will continue down this path.
After more debugging I discovered that when I POST to the EC2 instance directly everything works as expected. Our primary and public api url makes proxies requests through Amazon's API Gateway service. This service for some reason converts the data to Base64 instead of just passing through raw binary data.
I have found documentation to update the API Gateway to passthrough binary data: here.
I am using the Content-Type value of multipart/form-data. Do not forget to also add it in your API Settings where you enable binary support.
I did not have to edit the headers options, additionally I used the default "Method Request Passthrough" template.
And finally, don't forget to deploy your api changes...
It's now working as expected.
Sorry, but many of the comments make no sense. file.size will return the size of the uploaded file in bytes, NOT the size of the request (which, yes, due to different filters could potentially be enhanced with additional information and increase in size). Spring can't just magically double the size of a PNG file (in your case adding almost another ~600kb of information on top of whatever you've sent). While I'd like to trust that you know what you're doing and the numbers you are giving us are indeed correct, to me, all evidence points to human error... please, double-, triple-, quadruple- check that you're indeed uploading the same file in all scenarios.
How did you get to 649305 bytes in the first place? Who gave you that number? Was it your code or did you actually look at the file on disk and see how big it was? The only way compression discussions make any sense in this context is if 649305 bytes is the already compressed size of the file when running locally (it's actual size on disk being 1189763 bytes) and indeed, compression not being turned on when deployed to AWS for some reason and you receive the full uncompressed file (we don't even know how you are deploying it... is it really the same as locally? Are you running a standalone .jar in both cases? Are you deploying a .war to AWS perhaps instead? Are you really running the app in the same container and container version in both cases or are you perhaps running Tomcat locally and Jetty on AWS? etc. etc. etc.). Are you sure your Postman request is not messed up and you're not sending something else by accident (or more than you think)?
EDIT:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.sandbox</groupId>
<artifactId>spring-boot-file-upload</artifactId>
<version>1.0-SNAPSHOT</version>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.6.RELEASE</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
package com.sandbox;
import static org.springframework.http.ResponseEntity.ok;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.multipart.MultipartFile;
#SpringBootApplication
public class Application {
public static void main(final String[] arguments) {
SpringApplication.run(Application.class,
arguments);
}
#RestController
class ImageRestController {
#PostMapping(path = "/images")
ResponseEntity<String> upload(#RequestParam(name = "file") final MultipartFile image) {
return ok("{\"response\": \"Uploaded image having a size of '" + image.getSize() + "' byte(s).\"}");
}
}
}
The example is in Java because it was just faster to put together (the environment is a simple Java environment having the standalone .jar deployed - no extra configs or anything, except for the server port being on 5000). Either way, you can try it out yourself by sending POST requests to http://test123456.us-east-1.elasticbeanstalk.com/images
This is my Postman request and the response using the image you've provided:
Everything seems to be looking fine on my AWS EB instance and all the numbers add up as expected. If you are saying your setup is as simple as it sounds then I'm unfortunately just as puzzled as you are. I can only assume that there's more to what you have shared so far (however, I doubt the issue is related to Spring Boot... then it is more likely that it has to do with your AWS configs/setup).
CloudFormation Template snippet for achieving Kenny Cason's solution:
MyApi:
Type: AWS::Serverless::Api
Properties:
BinaryMediaTypes:
- "multipart/form-data"

Why is this web service's XML response causing an error in the SSIS web service task?

I'm using SSIS 2012 to create a package which will retrieve data from a web service and load a database. I've already successfully created a number of web service tasks in this package calling a number of other methods on this web service, but something is going wrong with one of them.
The GetDeviceInfo method accepts the following parameters:
certificate - Received after calling the WS login method
accountId - Account which the device exists in
cmuId - The serial number of a specific device
When calling the method using an arbitrary cmuId which I know does not exist (1234567 in this example), the XML response, which says that no records were found, is correctly returned as follows:
<?xml version="1.0" encoding="utf-16"?>
<ResponseModel xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<message xsi:nil="true" xmlns="http://schemas.datacontract.org/2004/07/CellocatorPlusModels" />
<state xmlns="http://schemas.datacontract.org/2004/07/CellocatorPlusModels">valueNotFound</state>
<timestamp xmlns="http://schemas.datacontract.org/2004/07/CellocatorPlusModels">6.36186059963802E+17</timestamp>
</ResponseModel>
As soon as a valid value for cmuId is entered, however, SSIS throws an error:
SSIS package "<redacted>\getData.dtsx" starting.
Error: 0xC002F304 at Web Service Task, Web Service Task: An error occurred with the following error message: "Microsoft.SqlServer.Dts.Tasks.WebServiceTask.WebserviceTaskException: Could not execute the Web method. The error is: There was an error generating the XML document..
at Microsoft.SqlServer.Dts.Tasks.WebServiceTask.WebMethodInvokerProxy.InvokeMethod(DTSWebMethodInfo methodInfo, String serviceName, Object connection)
at Microsoft.SqlServer.Dts.Tasks.WebServiceTask.WebServiceTaskUtil.Invoke(DTSWebMethodInfo methodInfo, String serviceName, Object connection, VariableDispenser taskVariableDispenser)
at Microsoft.SqlServer.Dts.Tasks.WebServiceTask.WebServiceTask.executeThread()".
Task failed: Web Service Task
SSIS package "<redacted>\getData.dtsx" finished: Success.
The web service task fails and the response is not written to the output file.
Calling the web service from a browser, using the same parameters, returns the following, which is exactly what I'm expecting:
<ResponseModel xmlns="http://schemas.datacontract.org/2004/07/CellocatorPlusModels" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<message i:type="ExtendedUnitInfoModel">
<Account><..></Account>
<AccountId i:nil="true"/>
<AssemblyDate>05/13/2015</AssemblyDate>
<CMUID>1169817</CMUID>
<CurrentFWVersion>331</CurrentFWVersion>
<FWStatus>On Wait</FWStatus>
<FirstFWVersion i:nil="true"/>
<FirstPLVersion i:nil="true"/>
<FirstStatusDate>05/13/2015</FirstStatusDate>
<GroupID>22493</GroupID>
<GroupName>CR300B</GroupName>
<Modem>CR300B GE864</Modem>
<PLName i:nil="true"/>
<ProgStatus>Normal Operation</ProgStatus>
<Prov></Prov>
<ProviderId>5186</ProviderId>
<PurchaseOrder>SO28906.4</PurchaseOrder>
<SIMNumber/>
<SerialId/>
<ShipmentDate>06/07/2015</ShipmentDate>
<ShipmentTrackingNumber>8577</ShipmentTrackingNumber>
<TesterName>Arcam3</TesterName>
<TestingDate>05/14/2015</TestingDate>
<WarrantyExpDate>06/08/2016</WarrantyExpDate>
</message>
<state>success</state>
<timestamp>6.3618603925336154E+17</timestamp>
</ResponseModel>
I've tried creating a standalone package containing only this web service task for troubleshooting, with the same results.
Since I can call other methods on this WS perfectly OK, the task runs properly when I specify a non-existent device and I can correctly write to the output file under these circumstances I can only conclude that something is malformed in this response or I'm missing something very silly.
Any ideas? Thanks in advance.
Coming back to this question after several years, I have concluded that this issue was due to some idiosyncrasy in SSIS processing complex XML using the web service task component.
The solution that ultimately worked for me was implementing the operation in an execute code component using C#. Here's the basic template (only parsing a single field for demonstration).
public void PreExecute()
{
// Load the XML response into an XDocument object
XDocument doc = XDocument.Parse(Dts.Variables["User::XmlResponse"].Value.ToString());
// Select the message element
XElement messageElement = doc.Root.Element("message");
// Select the CMUID element
XElement cmuidElement = messageElement.Element("CMUID");
// Extract the value of the CMUID element
string cmuid = cmuidElement.Value;
// Store the CMUID value in a variable
Dts.Variables["User::CmuId"].Value = cmuid;
}
Perhaps this will help someone else struggling with a similar issue.

number-of-matches-within-limits requesting CardDav server

I recently tried to read alot of VCards from iCloud CardDav server. However I realized there is a limit on the 5000th vCard I request.
Here is my REPORT request:
<?xml version="1.0" encoding="utf-8" ?>
<C:addressbook-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav">
<C:filter>
<C:prop-filter name="X-ADDRESSBOOKSERVER-KIND" test="anyof">
<C:is-not-defined />
<C:text-match collation="i;unicode-casemap" match-type="equals" negate-condition="yes">group</C:text-match>
</C:prop-filter>
</C:filter>
</C:addressbook-query>
And here is the end of the server answer:
<response>
<href>/872816606/carddavhome/card/</href>
<status>HTTP/1.1 507 OK</status>
<error><number-of-matches-within-limits/></error>
</response>
Is there a way to query the next page?
Thanks in advance.
CardDAV all by itself does not offer a paging mechanism. WebDAV Sync (https://www.rfc-editor.org/rfc/rfc6578) on the other hand does provide paging, although not all server implementations do support paging.
Now, if understand your query, you are pretty much asking for all contacts in the collection, except for groups. Unless you have a very large number of groups, you probably want to filter them on the client side, in which case you can use a regular PROPFIND (or WebDAV Sync REPORT), followed by series of CarDAV multiget REPORTs, which is what most clients do.

JAXWS - problems generating correct structure of SOAP message

We have an application which needs to consume an external web service. To do this we have generated the set of Java artifacts from the WSDL via Maven using the wsdl2java goal provided by the cxf-codegen-plugin plugin.
We have written an integration test as part of our test suite which calls the real web service and everything works fine.
The code to integrate with the actual web service is then packaged into a set of JARs and used inside the front end application which needs to use the web service.
We are having an issue when the FE application uses the integration code. Exactly the same code is being executed by the FE application as is being used in our working integration test but the SOAP message which is ultimately generated is different between the two and the message generated by the actual application is incorrect.
The working SOAP request produced by our integration tests is:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns12:ProcessUIRequest xmlns:ns10="http://zzz/yyyentityview/validation/"
xmlns:ns11="http://zzz/yyyview/search/list/"
xmlns:ns12="http://zzz/yyywebservice/v5/types/"
xmlns:ns2="http://zzz/yyyentityview/app/"
xmlns:ns3="http://zzz/yyyentityview/client/"
xmlns:ns4="http://zzz/yyyview/search/postcode/"
xmlns:ns5="http://zzz/yyyview/app/"
xmlns:ns6="http://zzz/yyyview/search/app/"
xmlns:ns7="http://zzz/yyyview/search/bank/"
xmlns:ns8="http://zzz/yyyview/uw/"
xmlns:ns9="http://zzz/yyybase/">
<ns12:ProcessUIRequest CallType="Submit" DisplayError="false"
IsAnonymous="false" IsCompactRequest="false" IsError="false">
<ns9:ModelData>
<ns9:TransactionData ApplicationReference="20000003CR3.00000003"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns5:QuoteLoadTxnDataVO" />
</ns9:ModelData>
<ns9:Activity ActionCode="QuoteLoad" ActionMode="Default"
ActivityCode="QuoteApplicationFull" ActivityMode="Default"
ActivityReference="" ActivityStatus="Inital"
ActivityTransaction="StartNewActivityAndLogOffUser"
CanProceedWithValidationsOutstanding="true">
<ns9:BusinessKeys>
<item>
<key>
<string>ADVREF</string>
</key>
<value>
<BusinessKeyVO KeyName="ADVREF" KeyValue="AVAGT01">
<BusinessKey KeyName="ADVREF" KeyType="Unknown"
KeyValue="AVAGT01" />
</BusinessKeyVO>
</value>
</item>
</ns9:BusinessKeys>
</ns9:Activity>
</ns12:ProcessUIRequest>
</ns12:ProcessUIRequest>
</S:Body>
</S:Envelope>
The POJO which is marshalled into that SOAP request is:
<tcp.ssgbase.BaseVO>
<modelData>
<transactionData class="tcp.ssgview.app.QuoteLoadTxnDataVO">
<applicationReference>20000003CR3.00000003</applicationReference>
</transactionData>
</modelData>
<activity>
<businessKeys>
<item>
<tcp.serializable__dictionary.BusinessKeyItem>
<key>
<string>ADVREF</string>
</key>
<value>
<businessKeyVO>
<businessKey>
<keyName>ADVREF</keyName>
<keyValue>AVAGT01</keyValue>
<keyType>Unknown</keyType>
</businessKey>
<keyName>ADVREF</keyName>
<keyValue>AVAGT01</keyValue>
</businessKeyVO>
</value>
</tcp.serializable__dictionary.BusinessKeyItem>
</item>
</businessKeys>
<actionMode>DEFAULT</actionMode>
<activityMode>DEFAULT</activityMode>
<activityTransaction>START_NEW_ACTIVITY_AND_LOG_OFF_USER</activityTransaction>
<actionCode>QuoteLoad</actionCode>
<activityReference></activityReference>
<activityStatus>INITAL</activityStatus>
<activityCode>QuoteApplicationFull</activityCode>
<canProceedWithValidationsOutstanding>true</canProceedWithValidationsOutstanding>
</activity>
<displayError>false</displayError>
<isAnonymous>false</isAnonymous>
<isError>false</isError>
<isCompactRequest>false</isCompactRequest>
<callType>SUBMIT</callType>
</tcp.ssgbase.BaseVO>
The SOAP request generated by the actual FE application is:
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Body>
<ns2:ProcessUIRequest xmlns:ns2="http://zzz/yyywebservice/v5/types/">
<processUIRequest>
<activity>
<actionCode>QuoteLoad</actionCode>
<actionMode>DEFAULT</actionMode>
<activityCode>QuoteApplicationFull</activityCode>
<activityMode>DEFAULT</activityMode>
<activityReference />
<activityStatus>INITAL</activityStatus>
<activityTransaction>
START_NEW_ACTIVITY_AND_LOG_OFF_USER</activityTransaction>
<businessKeys />
<canProceedWithValidationsOutstanding>
true</canProceedWithValidationsOutstanding>
</activity>
<callType>SUBMIT</callType>
<displayError>false</displayError>
<isAnonymous>false</isAnonymous>
<isCompactRequest>false</isCompactRequest>
<isError>false</isError>
<modelData>
<transactionData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns2:quoteLoadTxnDataVO">
<applicationReference>
20000003ESF.00000018</applicationReference>
</transactionData>
</modelData>
</processUIRequest>
</ns2:ProcessUIRequest>
</soapenv:Body>
</soapenv:Envelope>
The POJO which is marshalled into that SOAP request is:
<tcp.ssgbase.BaseVO>
<modelData>
<transactionData class="tcp.ssgview.app.QuoteLoadTxnDataVO">
<applicationReference>20000003ESF.00000018</applicationReference>
</transactionData>
</modelData>
<activity>
<businessKeys>
<item>
<tcp.serializable__dictionary.BusinessKeyItem>
<key>
<string>ADVREF</string>
</key>
<value>
<businessKeyVO>
<businessKey>
<keyName>ADVREF</keyName>
<keyValue>AVAGT01</keyValue>
<keyType>Unknown</keyType>
</businessKey>
<keyName>ADVREF</keyName>
<keyValue>AVAGT01</keyValue>
</businessKeyVO>
</value>
</tcp.serializable__dictionary.BusinessKeyItem>
</item>
</businessKeys>
<actionMode>DEFAULT</actionMode>
<activityMode>DEFAULT</activityMode>
<activityTransaction>START_NEW_ACTIVITY_AND_LOG_OFF_USER</activityTransaction>
<actionCode>QuoteLoad</actionCode>
<activityReference></activityReference>
<activityStatus>INITAL</activityStatus>
<activityCode>QuoteApplicationFull</activityCode>
<canProceedWithValidationsOutstanding>true</canProceedWithValidationsOutstanding>
</activity>
<displayError>false</displayError>
<isAnonymous>false</isAnonymous>
<isError>false</isError>
<isCompactRequest>false</isCompactRequest>
<callType>SUBMIT</callType>
</tcp.ssgbase.BaseVO>
You can see that the structure of the two requests are different even though the code being executed in our integration JARs is exactly the same and the structure of the POJOs used to create the SOAP message is the same (barring one value). From the request, it looks to be like the request generated in the FE application is not picking up the correct WSDL and associated XSDs.
Our code to generate the correct service endpoint interface implementation is:
private <T> T createServiceObject(final Class<T> p_seiClass) throws ApplicationException {
try {
final Service serviceFactory = Service.create(new URL(wsdlLocation), new QName(targetNamespace, serviceName));
final SoapHandlerResolver handlerResolver = new SoapHandlerResolver();
handlerResolver.addHandler(new SoapMessageLoggingHandler());
serviceFactory.setHandlerResolver(handlerResolver);
final T service = serviceFactory.getPort(p_seiClass);
((BindingProvider) service).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
"endpoint");
return service;
} catch (MalformedURLException e) {
throw new ApplicationException(ApplicationErrorCode.COMM_ERR_UNEXPECTED_ERROR, e);
}
}
After doing some debugging, I have noticed that the instance of the serviceFactory is different in the integration test and when we are running within the FE application.
In the integration test, the instance of the class (taken from the Eclipse debugger where we run the integration test using jUnit) is: 'JAX-WS RI 2.1.6 in JDK 6: Stub for ' and it appears to be of type 'SEIStub'.
When running within the FE application, the instance of the class is org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler. The FE application is hosted and executed on WebSphere Application Server.
So, my question is what could be happening when running in the actual FE application to cause the incorrect WSDL and XSD definitions to be picked up when marshalling the POJO into the SOAP request? I have spent a long time trying to debug this but to no avail.
The two soap request are different because, as you already said, the two serviceFactory is different and using different specifications 1.1 and 1.2.
My suggestion is that you configure your maven project to import the right jars on your test enviroment or update the jar on the container (the jar that create the serviceFactory). As I'm not familiarized with cxf-codegen-plugin I can't suggest more than that.
This suggestion was originally posted as a comment. The OP ask to put it as an answer.
I had this experienced when I was trying to write a client application and deploy it in Web Logic Server. You need to use exact version of java which is used by the server while creating the classes.
Soap request is created internally by JVM. If JVM is different while creating the classes and testing them and while consuming it on real time, SOAP will or may be different.