Consuming old axis generated WSDL - cxf

I am trying to generate the java stubs for the following WSDL http://telviva.com/local/telvivaapi.wsdl
If I try and use CXF I get the following error:
WSDLToJava Error: Rpc/encoded wsdls are not supported with CXF
Many forums online say I need to use axis to generate them, but using axis gives me the following error:
java.io.IOException: No 'message' attribute in for operation 'delete_access'
Can anyone suggest how I might consume this WSDL please?

Related

Sitecore Autofac - Void Autofac.RegistrationExtensions.RegisterModule

I would like to use Autofac in my Sitecore project with Solr,
I have set next code to global.asax
<%#Application Language='C#' Inherits="Sitecore.ContentSearch.SolrProvider.AutoFacIntegration.AutoFacApplication" %>
but i see an error
Method not found: 'Void Autofac.RegistrationExtensions.RegisterModule(Autofac.ContainerBuilder, Autofac.Core.IModule)'.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.MissingMethodException: Method not found: 'Void Autofac.RegistrationExtensions.RegisterModule(Autofac.ContainerBuilder, Autofac.Core.IModule)'
I have checked AutoFac version and it is correct 3.5.2 like in Sitecore.ContentSearch.SolrProvider.AutoFacIntegration
What should I do to set up it correct in term of Sitecore.
This issue happens because Sitecore's Solr support package relies on an old Autofac version (3.1.5 or earlier) where the method builder.RegisterModule() was still defined in Autofac.RegistrationExtensions. Newer Autofac versions have a similar method defined in the class Autofac.ModuleRegistrationExtensions.
Without Sitecore recompiling the Solr/Autofac integration dlls, unfortunately, there are only two ways around this:
Use another DI library;
Write your own Solr/Autofac integration.
This issue is still present in the Solr support package shipped with Sitecore 8.2.
I have registered this issue with Sitecore Support.
Edit: Sitecore replied that the support of Autofac 3.2 and later is on the wish list. To track the status of this request, you can use the reference number 94626.
Have you removed all the Lucene config files and added in all the solr config files in the App_Config/Include.
You will also need to drop in all the Solr Dlls as shown below.

Extract data from JSON in vanilla Java/Camel/Spring

I am trying to write a Camel route to get JMX data from an ActiveMQ server through the Jolokia REST API. I was able to successfully get the JSON object from the ActiveMQ server, but I am running into an issue where I cannot figure out how to parse the JSON object in my Camel route. Camel is integrated with Jackson, Gson, and XStream, but each of those appear to require an extra library that I do not have. Camel also has support for JSONPath, but it requires another library that I do not have. All of my research so far seems to point to using a new software library, so I am looking for someone who knows a solution to possibly save me some time from trying several more dead ends.
The big catch is that I am trying to parse JSON with something that comes with Java/Camel/Spring/ActiveMQ/apache-commons. I would prefer a solution that only uses Camel/Spring XML, but another solution using Java would work (maybe JXPath with Apache Commons?).
The reason I am trying to use libraries that I currently have is the long process that our company has for getting new software libraries approved. I can wait several months to get a library approved or I can write my own specialized parser, but I am hoping there is some other way for me to extract some of the information from the JSON object that I am getting from the Jolokia JMX REST API in ActiveMQ.
There is no JSOn library out of the box in Java itself. But there is a RFE to maybe add that in a future Java release, maybe Java 9.
So if you want to parse json, you need to use a 3rd party library. So you better get your company to approve a library.
camel-core 2.15.x has a json scheme parser we use to parse the component docs json schemas that is shipped now. But its not a general purpose json parser, but can parse simple schemas.
Its at org.apache.camel.util.JsonSchemaHelper

How WSDLToJava in cxf works?

'org.apache.cxf.tools.wsdlto.WSDLToJava' converts wsdl to java classes.
Is it using JAXB internally?How come this command is able to generate classes like how 'xjc' creates?Can somebody explain me how it works?
CXF uses xjc internally for code generation.
Refer to following for more information (from CXF official page)
In CXF versions prior to 2.3.0, the xjc plugins were shaded directly into the big cxf bundle jar. In 2.3.0, they were removed from the jar and are placed individually into the lib directory of the distribution. The xjc plugins are only code generation utilities and not used at all at runtime which is why they were pulled out.
The Apache CXF XJC-Utils subproject provides a bunch of utilities for working with JAXB to generate better or more usable code.
Currently, it consists of the following modules:
cxf-xjc-plugin Provides a maven wrapper around the JAXB XJC utility
cxf-xjc-dv Initialize fields mapped from elements/attributes with their default values
cxf-xjc-ts Implements the toString() method
cxf-xjc-boolean Generate getters named getXXX() for Booleans instead of isXXX()
cxf-xjc-wsdlextension Adds extensions methods to allow generated beans to be used as WSDL4J extensors
cxf-xjc-bug671 Provides a workaround for https://jaxb.dev.java.net/issues/show_bug.cgi?id=671
- Not needed for JAXB >=2.1.12
WSDL2Java is a command line tool that generates Java classes from an existing WSDL document. Generated classes represent client stubs, server skeletons and data types that will helps you to write client side and server Java programs for Web services defined in the WSDL document.
DEFAULT_FRONTEND_NAME = "jaxws";
DEFAULT_DATABINDING_NAME = "jaxb";
For details,
http://cxf.apache.org/docs/wsdl-to-java.html http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cxf/cxf-bundle/2.0.6/org/apache/cxf/tools/wsdlto/WSDLToJava.java

Using Solr to read OpenGrok's database and failing with "no segments* file found"

I need a simple way to read OpenGrok's DB from a php script to do some weird searches (as doing that in Java in OpenGrok itself isn't in my abilities). So I decided to use Solr as a way to query the Lucene DB directly from another language (probably PHP or C).
The problem is that when I point Solr to /var/opengrok/data, it bombs out with:
java.lang.RuntimeException: org.apache.lucene.index.IndexNotFoundException: no segments* file found in org.apache.lucene.store.MMapDirectory#/var/opengrok/data/index lockFactory=org.apache.lucene.store.NativeFSLockFactory#3a329572: files: [] at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1103)
(etc, etc, the backtrace is about three screens long)
I tried to point it somewhere inside data with no luck. The structure looks like this:
/var/opengrok/data/index/$projname/segment*
/var/opengrok/data/spelling...
and seems like whatever Solr is using is expecting the segment files directly in the index directory.
I checked to see if there's any version discrepancy, but OpenGrok 0.11 is using Lucene 3.0.2 and I've set Solr to LUCENE_30 as the database version.
Any pointers will be greatly appreciated, google didn't seem to be able to help with this.
opengroks web interface can consume any well formed search query (through url) and reply with xhtml results which are easily parse-able, so you're probably making it too complex to hack inside the lucene rather than using UI provided ...

ClassCastException+spring

Hi following error I have got please let me know solution
java.lang.ClassCastException: org.apache.catalina.util.DefaultAnnotationProcessor cannot be cast to org.apache.AnnotationProcessor –
Im using tomcat 6.0
This is a known issue. This is the reason:
This was due to efforts from MYFACES-1246, proposal of annotation
processing here in list (adding method), but this of course breaks
compatibility of the same named interfaces.
If you have older code using org.apache.AnnotationProcessor you can make
it work on Tomcat.
Solution is:
Add <Loader delegate="true"/> into context.xml file (to Context element) in tomcat/conf directory.
This makes classloading in Tomcat sticking to J2EE spec.
(I couldn't make it work with suggested approach for only 1 webapp)
This is the reference: http://mail-archives.apache.org/mod_mbox/myfaces-dev/200703.mbox/%3C45F6D22B.1020803#ataco.cz%3E

Resources