I am trying to migrate from axis to cxf. Here's the problem i am facing: some packages has incorrect names being generated by cxf. Specifically there is a difference for a types, that located in xsd files, imported to main wsdl through <s:import> element: looks like cxf prefers xsd's file namespaces while axis not. This is gonna take much more time to migrate if i should change package names for all xsd types. Is it possible to ignore xsd namespaces?
CXF's wsdl2java has a -pnamespace=package flag that can be used to map namespaces to non-default packages.
Related
I`m using Apache Tika 1.4 to extract content from my documents. But it also comes with org.bouncycastle.* classes, and I use another version of bouncycastle which is conflicting with the Tika packages.
If the Tika was using the bouncycastle (bcprov) jar, I could exclude that using exclusion tag from Maven, but the TikaApp has copied the org.bouncycastle classes into it, so, I cannot exclude them.
There`s some way to remove this package without recompiling or branching Apache Tika and set to use another JAR to this specified package or something like that?
Thanks
Your problem is that you're using completely the wrong packaging of Tika!
The tika-app jar is a standalone, runnable jar, containing all of the Tika code + all dependencies required to let it run. It's intended to be used from the command line, standalone, to allow non-Java users to call Tika, and to allow for easy testing.
If you're writing your own Java application, which it sounds like you are, you will want to depend on the tika-core artifact as a minimum. That contains all the interfaces, the mime detection, service loaders etc. You'll then almost certainly also want to depend on tika-parsers , which provides all the code to do the actual parsing of the file formats, along with pulling in their required dependencies. This gives you the full control you seem to want.
Finally, there's also an OSGi bundle available, for those who prefer the control and classloading that OSGi offers, that's in the tika-bundle artifact. There's also a CXF powered JAX-RS version, which offers Tika's services over a RESTful interface, that comes in the tika-server artifact.
I'm trying to configure locate the DTDs for Saxon extensions and java types (IntelliJ editor configuration).
The namespaces:
http://saxon.sf.net
http://saxon.sf.net/java-type
...have no DTDs available in the classpath. I've looked in the jars and everywhere and can't find an explanation or references to such DTDs on the web. I'm able to use extensions and java types, such as saxon:evaluate, successfully.
I'm using Saxon 9B.
There are no elements or attributes in these namespaces, only functions and types. DTDs define elements and attributes. So there would be nothing for a DTD to say.
What problem are you actually trying to solve: what would you want to do with this DTD if it existed?
I have found that there is a multitude of XSD files on the web that claim their targetNamespace is "http://schemas.xmlsoap.org/wsdl/". Naturally, there is one at "http://schemas.xmlsoap.org/wsdl/", but there is another one at "http://www.w3.org/TR/wsdl#A4.1". And e.g. Oracle has at least 10 versions of wsdl.xsd in its SOA Suite 11g, all somehow derived from the xmlsoap.org or w3.org version.
The problem is, all these various WSDL 1.1 definitions are mutually different!! For instance the schema at "http://schemas.xmlsoap.org/wsdl/" allows the "name" attribute on and for operations in the sections, while the schema at "http://www.w3.org/TR/wsdl#A4.1" doesn't allow that.
So, which XSD schema for WSDL 1.1 is the right one?
I have WSDL files and would like to compare and match WSDL elements in these files syntactically. Do you have any suggestions for Java libraries that can be used finding syntactical similarities between two terms in Web (for me, wsdl elements)?
Thanks.
There's also WSDL Analyzer which builds upon the most recent version of the Membrane SOA Model. It's a web application which not only allows you to validate and check your
WSDL against best practices but also lets you compare different versions of your WSDL.
Disclaimer: I'm one of it's developers.
Well, you can use SOAPUI to load the wsdl definitions and compare them.
Including link with some documentation relating to your question. Hope is of some help.
http://www.soapui.org/SOAP-and-WSDL/working-with-wsdls.html
edit:
Also, check out http://www.membrane-soa.org, which as some libraries for comparing wsdl files.
Some specific examples are here: http://www.membrane-soa.org/compare-wsdl-java-api.htm
I've been using spring.net with xml configuration for some times, and I just saw that spring team released CodeConfig a month ago.
What I like about the xml config is that if I have a problem on the live server I can easily change the xml configuration to enable some specific debugging settings, or disable a specific component simply changing the xml configuration.
What is the advantage of using a code configuration instead of an xml configuration other than compile time check?
With code config, possible benefits you could get are:
Better refactoring support; e.g. renaming an injected property
More compact configuration, compared to xml
Developers can use code, in which they are often more at home than in xml
Benefit of the last point is also that developers new to the framework will have a significantly less steep learning curve than with the xml config.
From the docs:
While there are several positive
aspects to expressing configuration
metadata in XML files, there are also
many problems with this approach
including the verbosity of XML and its
heavy dependence on string-literals
which are both prone to typing errors
and unusually resistant to most modern
refactoring tools in use today. The
CodeConfig approach removes these
problems by providing a type safe,
code-based, approach to dependency
injection. It keeps the configuration
metadatda external to your class so
your class can be a POCO, free of any
DI related annotations.
Just to highlight one thing, you can mix and match configuration styles. From within a CodeConfig class you can refere to XML config files using the [ImportResource] attribute (see here), and in the XML you can use the namespace (see here).
Cheers,
Mark