upper case abbreviations converted to lower case - web-services

When we upgrade weblogic to 12c, used "jwsc" ant tool to generate JAX-WS type WSDL and XSD file, the class name which include upper case abbreviations as prefix was converted to lower case in xsd:complexType.
for example:
class name is: PINRequest.java
use "jwsc" to generate WSDL/XSD: it displays in XSD as complexType name="pinRequest"
Using clientgen to generate client jar, the class name changed to: PinRequest.class
Is there any way to prevent this kind of convert?

Related

Is there a way to create JAXB binding rules based on regex for all xsds? (as opposed to a rule per schema file)

I'm using xjc (jaxb2-maven-plugin) to generate my POJOs from several XSD files. Not surprisingly, there are class conflicts if I put all my generated files into one package. By default xjc will use the namespace as a package name.
Ex:
namespace: "https://analysiscenter.domain.com/schema/4.0/sandboxlist"
becomes package: https.analysiscenter_domain_com.schema._4_0.sandboxlist
I realize that I can use xjc:bindings to specify individually which namespace becomes which package, but that becomes quite tedious. Is there any way to specify rules or regexs for the bindings for all xsds?
Ex: namespace ./schema/(.)/(.*) becomes package: myDefaultPackage.$1.$2
Ex something like the following:
<jaxb:bindings schemaLocation="*.xsd" node="/xsd:schema[#value=.*/schema/(.*)/(.*)">
<jaxb:schemaBindings>
<jaxb:package name="com.domain.$1.$2"/>
</jaxb:schemaBindings>
</jaxb:bindings>
Is there any way to specify rules or regexs for the bindings for all xsds?
No, you can't use regexes or similar. But I think you should be able to write an own implementation of the com.sun.xml.bind.api.impl.NameConverter and register it in com.sun.tools.xjc.Options.setNameConverter(...) via XJC plugin.

i have headers separately, how to import it to informatica target

I have source and target in an informatica powercenter developer. I heed some other header name to be imported in the target file automatically without any manual entry. How can I import customized headers to informatica target.
What have you tried?
You can use a header command in the session configuration for the target, I haven't used it, and couldn't find any documentation on it (i.e. what is possible and how, whether parameters can be used or not, etc.). I did test using (on Windows) an ECHO command to output its text to the header row, but it didn't seem to recognize parameters.
Or you can try to include the header as the first data output row. That means your output will have to be all string types and length restrictions may compound the issue.
Or you can try using two mappings, one that truncates the files and writes the header and one which outputs the data specifying append in the session. You may need two target definitions pointing to the same files. I don't know if the second mapping would attempt to load the existing data (i.e. typecheck), in which case it might throw an error if it didn't match.
Other options may be possible, we don't do much with flat files.
The logic is,
In session command, there is an option called user defined headers. Type echo followed by column name separated by comma delimited
echo A, B, C

What is the meaning of the leading slash / in Tomcat's <url-pattern>?

I know I cannot use regular expressions for the <url-pattern> of a filter-mapping, but is it possible to use a directory pattern to specify any url containing the word myuniqws as in:
https://my.hostname.org/myuniqws/myport/soap?wsdl
I am thinking of perhaps this would be the correct syntax:
<url-pattern>/*myuniqws*</url-pattern>
but I have not been able to find documentation for the exact rule of Tomcat's <url-pattern> syntax.
Will the above regex work as I desire?
Update:
Thanks to the answer below, I discovered the following section in the Java Servlet Specification, which basically answers my questions.
12.2 Specification of Mappings
In the Web application deployment descriptor, the following syntax is used to define
mappings:
A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used for
path mapping.
A string beginning with a ‘*.’ prefix is used as an extension mapping.
The empty string ("") is a special URL pattern that exactly maps to the application's context root, i.e., requests of the form http://host:port/<contextroot>/. In this case the path info is ’/’ and the servlet path and context path is empty string (““).
A string containing only the ’/’ character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.
All other strings are used for exact matches only.
If the effective web.xml (after merging information from fragments and annotations) contains any url-patterns that are mapped to multiple servlets then the deployment must fail.
Presumably, you mean the <url-pattern> for filter mappings in web.xml. You might not know this, but web.xml is defined as part of the Java Servlet Specification. You can find full documentation for the 3.1 version (currently, the latest and greatest) here:
https://jcp.org/aboutJava/communityprocess/final/jsr340/index.html
If you read section 12.2 ("Specification of Mappings") you can see exactly what kinds of patterns are recognized, including the prefix-mapping you are requesting above.
EDIT 2014-11-04:
You should know that CATALINA_HOME/conf/web.xml (or CATALINA_BASE/conf/web.xml if you have one) is the default configuration for all web applications deployed on Tomcat and that your webapp's WEB-INF/web.xml is the configuration specific for your own web application. Both of these files should have the following xmlns statements and therefore indicate to you (by their URIs) that they are covered by the Java Servlet Specification (or at least Java EE, which includes the servlet spec):
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">

Use WSDL dynamically in Delphi

How can I use dynamic WSDL, it's operations and parameters, which is given in program config file?
For example, we have a config file:
[Section]
WSDL=http://example.com/SomePub/ws/SomeService?wsdl
Username=myuser
Password=mypass
OperationName=MyOperation
ParameterName=MyParameter
I.e. we have to use web-service, which is unknown, but given (by ini-file) only in run-time. So, we cannot use WSDL Import wizard in Delphi.
Can we write in Delphi such a program, which would load these settings from configuration, and then pass data to specified operation in specified parameter on web-service, which specified by given WSDL?
Using SOAPUI, import the service and perform a sample call. Copy the raw request and the raw response into notepad. Modify the real data with 'tags' and include each raw template as a value in your INI. When you need to make the call, open your INI, grab the raw response template and replace tags with real values. Manually send the SOAP request and parse the response in the same way using the raw template.
The Delphi WSDL importer and the Free Pascal Web Service Toolkit do not provide a way to build a SOAP request dynamically based on a WSDL.
The Web Service Toolkit (and the WSDL importer) are only source code generators, so the code first needs to be compiled - this requires to include a compiler with your application.

SOAP/REST Webservices XML case sensitivity

I just got a doubt whether the XMLs we are using for our SOAP/REST-based web services are case-sensitive or or not? How does it work exactly?
Tell me both for the default soap envelope as well as for payload XMLs.
SOAP is a specific instance of an XML language.
As such, it adheres to all the rules of XML.
One of these rules is that XML is case-sensitive.
Therefore SOAP is case sensitive as well.
Same is true for REST
XML is always case-sensitive; it's defined that way by the W3C (see the definition for “match” where it says that no case folding is performed). SOAP uses XML for both envelope and payload, so those are by definition case-sensitive.
(Note that this is different from HTML, which is case-insensitive for element and attribute names. That's because HTML is built on top of SGML, itself a much-more-complex predecessor to XML.)