I am working on creating a CAM (custom authentication module/provider) for Cognos 10.
Various encrypted information is passed into the provider from the query string. The Namespace's authentication process is then designed to talk to a web service in order to validate the encrypted information wasn't tampered with and to make sure the user's "session" in the authenticating application hasn't expired.
The authenticating application uses .NET and has the web service exposed for use with SOAP requests (1.1 and 1.2, I believe). I pointed wsimport at the wsdl and generated a set of classes that works when I build a standard Java console app and pass along debug values.
When I add this code into my Namespace class and attempt the request to the web service I am getting this error from Cognos:
com.sun.xml.internal.ws.spi.ProviderImpl (initialization failure)
I thought Cognos 10 was using JDK 1.6. I am developing my CAM code in 1.6 (64bit JDK). I should have 64bit Cognos running but I do not know if it is using a 32bit JDK. Could a possible disparity in 32bit vs. 64bit be causing the issue?
Any clue as to why the generated classes from wsimport (JAXWS) won't work in Cognos? Is there a way around this?
I'm going to mark this as answered but I'll put the caveat that I haven't tested this.
After dealing with trying to get 3rd party libraries to work with my CAP/CAM I figured that the reason JAXWS was not working correctly because Cognos didn't have that included in its Java distribution.
I got a similar error to the above when trying to use Microsoft's JDBC implementation to talk to a SQL server for namespace searches. This leads me to believe that the same situation exists with JAXWS.
I looked around for the jar file that should contain the classes that would need to be there. I didn't see any jar file that was named the same as what I have for 1.6. Unless it truly isn't supported in Cognos I think including the jar file for JAXWS in the WEB-INF/lib folder will allow webservice communications using JAXWS.
Related
We still have an implementation of this running on an old Tomcat java 1.5 box. Its used to sso for our own domain email via google
https://developers.google.com/google-apps/sso/saml_reference_implementation_web#file-and-directory-structure-for-saml-reference-code
I noticed there is a warning that this is old and no longer compatible. Is there an updated how to or sample that we can implement into an Ear file for websphere with java 1.6 ? I haven't been able to find anything yet. Thanks.
I have a jar file which houses client code to connect to our infrastructure webservices that was initially created using axis' wsdl2java. I converted the guts of the connectivity this week to use the extract from wsimport. When running on my local Windows XP tomcat using java6_18 I have no issues and all runs perfectly. I have now moved my code to our development AIX instance and have lost total web service communication while receiving the following error:
XML reader error: javax.xml.stream.XMLStreamException:
The root element is required in a well-formed document
On AIX we are running java6_64.
I am assuming it is the AIX java libs not being compatible with the Sun provided java runtime libs however I am at a total loss at the moment as to how to resolve.
Can anybody shed some light on why I am receiving this exception?
This could be a code page issue as it complains that there is no root-element, and if the < character is misinterpreted as something else you have no root element.
Check the system properties to see what encoding the program runs under. You may have an assumption somewhere that the encoding is ISO-Latin-1 as under Windows.
I don't like answering my own question but thought recording the answer could be beneficial to others...
After digging a bit, the resolution was simply the format of the wsdl url. With axis, I specified the wsdl URL as the path to the webservice. For JAX-WS, it requires path to the service+"?wsdl" (the actual wsdl to load at runtime).
The above error was generated since the "axis" path did not result in the wsdl to pull but rather a blank resultset. Once I added the "?wsdl" all works fine.
I am trying to create a simple SOAP webservice (calculator) to learn the basics of this technology. I am new to SOAP so I have already done some things but I am not sure what to do next.
I have chosen a top-down approach, which means creating a wdsl file first and then generating the code automatically.
I have created a wsdl file with the service description and used that to generate java files. I have it both in 1.1 and 2.0 format. To get 2.0 files I used the wsdl2java tool of axis2, for 1.1 I used java wsimport tool.
From the wsimport tool I got the following files:
package-info.java
ObjectFactory.java
CalculatorService.java (name of my service)
Calculator.java (name of my portType)
Input.java (name of a complex type)
The wsdl2java tool gave me the following files:
services.xml
CalculatorService.wsdl
Output.java (name of output element)
Input.java (name of input element)
cInput.jaba (name of input complex element)
ExtensionMapper.java
CalculatorServiceCallbackHandler.java
CalculatorServiceMessageReceiverInOut.java
CalculatorServiceSkeleton.java (includes implementation of interface)
CalculatorServiceSkeletonInterface.java
CalculatorServiceStub.java
In the wsdl2java files I guess I have everything I need excpept the server implementation. As for the wsimport ones they are missing an implementation and I am not sure where to add it. The server implementation is also missing.
At first I would like to run it as a local service (local server) to test that it is working and also write a client later.
I found an example of a server implementation here: In-process SOAP service server for Java.
It seems quite simple and if possible I would like to use this approach. But I am not sure if it would work with the files I have generated (wsdl2java or wsimport). I also have an Apache server installed if it would be of use. So I am looking for advice, which set of files to use to set up the server and what would be the easiest way to do it.
Also I am wondering if the namespaces used in the wsdl file affect the service availability? Becuase they have to be URI-s but I do not have one for my service at the moment. So for targetNamespace, xmlns:tns, endpoint address, etc I used random URL-s. Would it work if I am trying to run it locally or would it create issues?
Ok, I think I found the solution myself.
Used Tomcat server and eclipse axis2 plugins to get the server and client working.
This was a good tutorial in my opinion: http://eclipse.dzone.com/articles/web-services-development-with-
I developed an application that uses Apache XML security library for xml encryption and signing. It runs on SUN's JDK without any problems, however, IBM JDK gives me tons of problems.
It doesn't sign right (validation fails), pkcs11 provider fails to encrypt.
It seems that problem is because IBM provides their own security providers.
I tried to comment out those providers (namely fips), and I almost managed to get same behaviour as on sun's jdk, except pkcs11 provider, which alwasy fails.
Any suggestions?
Does this thread help - http://www.ibm.com/developerworks/forums/message.jspa?messageID=1315965?
I had trouble in the past with an SSL enabled web application in Apache Tomcat because Tomcat defaults to using algorithm=SunX509 when you define a secure Connector. When using the IBM JDK, you must override by explicitly using algorithm=Ibmx509.
I'm guessing there's a similar issue at the root of your problem.
I've created an app that interacts with a SOAP service using java WS. I generate classes and manage the WSDL using the built in netbeans functions.
Every time I run the application, it has to download the WSDL and parse it again. The WSDL is frozen at each version so I don't think this is necessary. I've tried to reference it as a local file, but then my app complains it can't find the file when it's installed on another machine.
Does anyone know how I can stop Java WS needing to re-parse the WSDL, or at least cache it locally?
I've figured it out...
This page has the info
Developing client application with locally packaged WSDL