How can I use wsimport (or any other tool that provides similar funcionality for that matter) to generate the required files to talk to a JAX-WS webservice, but not only have it add JAXB annotation to the request/response classes, but also add Jackson annotations?
In the big picture, I do not want to duplicate, I want to reuse the generated classes for a REST service. If the above is not possible, is there any other way that saves me from duplicating everything?
As mentioned in a comment, Jackson has a JAXB Annotations module, that can use JAXB annotated classes beside / instead of standard Jackson annotated ones...
See: https://github.com/FasterXML/jackson-module-jaxb-annotations
Related
I'm trying to use JavaFX in my android device, with the help of javafxports.
I used the XStream to parse some XML file in my program.
When i compile them, the javafxports outputs the following warnings:
Note: there were 9 classes trying to access annotations using reflection.
You should consider keeping the annotation attributes
(using '-keepattributes *Annotation*').
(http://proguard.sourceforge.net/manual/troubleshooting.html#attributes)
Note: there were 32 classes trying to access generic signatures using reflection.
You should consider keeping the signature attributes
(using '-keepattributes Signature').
(http://proguard.sourceforge.net/manual/troubleshooting.html#attributes)
Note: there were 56 unresolved dynamic references to classes or interfaces.
You should check if you need to specify additional program jars.
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclass)
Note: there were 3 class casts of dynamically created class instances.
You might consider explicitly keeping the mentioned classes and/or
their implementations (using '-keep').
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclasscast)
Note: there were 39 accesses to class members by means of introspection.
You should consider explicitly keeping the mentioned class members
(using '-keep' or '-keepclassmembers').
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclassmember)
Note: you're ignoring all warnings!
The output .apk can be installed and run until it calls the xstream classes to read annotations in my classes. The reason is actually described in the warnings.
So my question is, how can i disable the proguard when generating .apk, or send it a custom proguard.pro configuration.
And my build.gradle is almost the same as that in the helloworld example.
Thanks.
Apache Camel comes with some relatively nice Groovy extensions so that you, for instance, can use closures with the Java DSL for defining routes.
Most, if not all, of the additional methods providing these extensions seem to be located in the class CamelGroovyMethods with static methods like
public static ProcessorDefinition<?> process(ProcessorDefinition<?> self,
Closure<?> processorLogic){/* implementation */}
How is the actual extension of the Camel java classes realised? Is CamelGroovyMethods used as a category somewhere, and if so, where is use(CamelGroovyMethods) called?
Just a guess, but as they are called extension methods they have probably been defined as such. Look in the jar, you should find a file called org.codehaus.groovy.runtime.ExtensionModule in META-INF/services. Have a look at Creating an extension module. I've used this technique myself and it works great except if you want to provide custom constructors, that requires an alternate mechanism.
...
Yep, found it ExtensionModule file in GitHub. They even provided the dsld file to assist with code completion in Eclipse.
I am currently experiencing a problem in my RCP application and wanted to ask, if someone stumbled over the same problem and can give me some valuable hints:
My RCP application allows plugins to provide implementations of a specific abstract class of my model (singleton) to extend my model during runtime via the update manager. I instantiate these classes via
extensionPointImplementation.createExecutableExtension(..)
after parsing the Eclipse registry. I can serialize the created instances using the default Java serialization API.
Now to the problem: The plugin trying to deserialize the objects cannot find the class implementations of the model extensions due to the fact, that there is no plugin dependency between the plugins. Nevertheless, it is not possible for me to create such a dependency which would make the idea of extending the model during runtime obsolete.
Is it possible to solve this problem by using the default Java serialization API or do I have to implement my own serialization (which parses the Eclipse registry and creates the instances via the line shown above if all necessary plugins are available, otherwise throw an exception) which might be based on the default Java serialization API (if possible I do not want to create the serialization completely by myself)?
Thanks.
You need to define a so called buddy policy.
In the bundle trying to instantiate the class add
Eclipse-BuddyPolicy: registered
to the manifest.mf.
In the bundle providing the class add
Eclipse-RegisterBuddy: <symbolic name of the bundle instantiating the class>
to the manifest.mf.
I am using axis2 wsdl2java script to generate client side stubs with the data binding classes being generated separately using the -u option. The generated data binding classes are using the ADB data binder and all the classes are inheriting from the ADBBean. I want the classes to implement the Serializable interface. Is there a way to do this. I have been researching this for a while and haven't been able to find a concrete solution. I need the data binders to be generated separately instead of being inner classes.
We have two assemblies, DataContracts and Core. We are currently using svcutil to generate our DataContracts, while referencing Core. We've got a couple of extension methods on different enum types that would be useful on the client side.
Is there any way to get svcutil to include these extension methods into our generated proxies file?
Any methods that you want exposed you need to have as part of the operational contract. I don't know of any other way to expose the metadata in the WSDL without learning more about how the WSDLImporter works. Irregardless - Metadata is only contracts - you can't share operations/behaviors in your metadata. The only way to share method behaviors (your extensions) is to include them in the shared contract/core assembly or expose them as operation contracts.
The classes generated by svcutil are partial. Therefore the functionality of those classes can be split in multiple files. One file is the one generated by the svcutil with the functionality exposed by the service. Other files could contain the functionality you want to append, which is not part of the data contract.
More info on partial classes Partial Classes and Methods (C# Programming Guide) on MSDN