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.
Related
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
I would like to have a C++ client application that maintains a cache of objects that come from a Java server. The objects need to be compatible. I understand that Gemfire maintains them in a serializable format. This means the Java class needs to be equivalent to the C++ class.
Is there a common practice for defining the class structure in common place in a language-independent specifcation and generating the equivalent Java and C++ classes that are serializable to PDX or any other form that Gemfire uses?
Regards,
Yash
Before PDX I used to create a language-neutral representation of my domain and simultaneously generate Java, C++ and .Net classes using DataSerializable. However, PDX makes this unnecessary for the most part. I enclose the sample config below.
If you encounter types that you are using that Java does not support, you still do not have to resort to generating serializers but you can focus in on serializing that one type (see page 564 of http://gemfire.docs.pivotal.io/pdf/pivotal-gemfire-ug.pdf
Consider generating your own serializers when you have an insane need for speed since the auto-serializer can produce a drag. This is usually not needed but if you do, here are the instructions: http://data-docs-samples.cfapps.io/docs-gemfire/latest/javadocs/japi/com/gemstone/gemfire/DataSerializer.html
Here is the configuration for using the pdx auto serializer:
<!-- Cache configuration configuring auto serialization behavior -->
<cache>
<pdx>
<pdx-serializer>
<class-name>com.gemstone.gemfire.pdx.ReflectionBasedAutoSerializer
</class-name>
<parameter name="classes">
<string>com.company.domain.DomainObject</string>
</parameter>
</pdx-serializer>
</pdx>
...
</cache>
If I answered your question, please give check "Answered". Thanks.
I am trying to create bindings using the kml schema http://schemas.opengis.net/kml/2.2.0/ogckml22.xsd and the gx extension schema https://developers.google.com/kml/schema/kml22gx.xsd
I have no trouble generating and using the bindings generated from the ogckml22 schema. I am unclear as to how to incorporate the extension schema into these bindings.
You don't incorporate the schema into those bindings. You generate a new bindings module for the extending schema (which has its own namespace), and make sure it references the existing bindings. Something like this[*]:
pyxbgen \
--archive-path='&pyxb/bundles/opengis//' \
--schema-location=http://code.google.com/apis/kml/schema/kml22gx.xsd \
--module=kml22gx
The bindings for kml22gx will be subclasses of the pyxb.bundles.opengis.ogckml22 bindings that are being extended.
Look at the file pyxb/bundles/opengis/scripts/genbind which is what generates the bindings in PyXB itself. Several of the namespaces extend other OpenGIS namespaces for which bindings were generated in an earlier invocation of pyxbgen.
([*] When you do this, you may get an AssertionError. Comment out the assertion; it seems to be too restrictive.)
I have been playing around the last couple of days with different solutions for mapping DTO's to entities for a VS2013, EF6, WCF Service App project.
It is a fairly large project that is currently undergoing a major refactoring to bring the legacy code under test (as well as port the ORM from OpenAccess to EF6).
To be honest I had never used AutoMapper before but what I saw I really liked so I set out to test it out in a demo app and to be honest I am a bit ashamed that I have been unable to achieve a working solution after hours of tinkering and Googling. Here is a breakdown of the project:
WCF Service Application template based project (.svc file w/code behind).
Using Unity 3.x for my IoC container and thus creating my own ServiceHostFactory inheriting from UnityServiceHostFactory.
Using current AutoMapper nuget package.
DTO's and DAL are in two separate libraries as expected, both of which are referenced by the service app project.
My goal is simple (I think): Wire up and create all of my maps in my composition root and inject the necessary objects (using my DI container) into the class that has domain knowledge of the DTO's and a reference to my DAL library. Anyone that needs a transformation would therefore only need to reference the transformation library.
The problem: Well, there are a couple of them...
1) I cannot find a working example of AutoMapper in Unity anywhere. The code snippet that is referenced many times across the web for registering AutoMapper in Unity (see below) references a Configuration class that doesn't seem to exist anymore and I cannot find any documentation on its deprecation:
container.RegisterType<AutoMapper.Configuration, AutoMapper.Configuration>(new PerThreadLifetimeManager(), new InjectionConstructor(typeof(ITypeMapFactory),
AutoMapper.Mappers.MapperRegistry.AllMappers())).RegisterType<ITypeMapFactory,
TypeMapFactoy>().RegisterType<IConfiguration, AutoMapper.Configuration>().RegisterType<IConfigurationProvider,
AutoMapper.Configuration>().RegisterType<IMappingEngine, MappingEngine>();
2) Where to create the maps themselves... I would assuming that I could perform this operation right in my ServiceHostFactory but is that the correct place? There is a Bootstrapper project out there but I have not gone down that road (yet) and would like to avoid it if possible.
3) Other than the obviously necessary reference to AutoMapper in the DTO lib, what would I be injecting into the instantition, the configuration object (assuming IConfiguration or IConfigurationProvider) and which class I am injecting into the constructor of the WCF service to gain access to the necessary object.
I know #3 is a little vague but since I cannot get AutoMapper bound in my Unity container, I cannot test/trial/error to figure out the other issues.
Any pointers would be greatly appreciated.
UPDATE
So I now have a working solution that is testing correctly but would still like to get confirmation that I am following any established best practices.
First off, the Unity container registration for AutoMapper (as of 11/13/2013) v3.x looks like this:
container
.RegisterType<ConfigurationStore, ConfigurationStore>
(
new ContainerControlledLifetimeManager()
, new InjectionConstructor(typeof(ITypeMapFactory)
, MapperRegistry.AllMappers())
)
.RegisterType<IConfigurationProvider, ConfigurationStore>()
.RegisterType<IConfiguration, ConfigurationStore>()
.RegisterType<IMappingEngine, MappingEngine>()
.RegisterType<ITypeMapFactory, TypeMapFactory>();
Right after all of my container registrations, I created and am calling a RegisterMaps() method inside of ConfigureContainer(). I created a test mapping that does both an auto mapping for like named properties as well as a custom mapping. I did this in my demo app for two reasons primarily:
I don't yet know AutoMapper in a WCF app hosted in IIS and injected with Unity well enough to fully understand its behavior. I do not seem to have to inject any kind of configuration object into my library that does the transformations and I am still reading through the source to understand its implementation.
As I understand it, there is a caching mechanism at play here and that if a mapping is not found in cache that it will create it on the fly. While this is great in theory, the only way I could then test my mappings that were occurring in my composition root was to do some sort of custom mapping and then call Mapper.Map in the library that performs mapping and returns the DTO.
All of that blathering aside, here is what I was able to accomplish.
WCF Service App (composition root) injects all of the necessary objects including my DtoConversionMapper instance.
The project is made up of the WCF Service App (comp root), DtoLib, DalLib, ContractsLib (interfaces).
In my ServiceFactoryHost I am able to create mappings, including custom mappings (i.e. map unlike named properties between my DTO and EF 6 entity).
The DtoConversionMapper class lives in the DtoLib library and looks like this: IExampleDto GetExampleDto(ExampleEntity entity);
Any library with a reference to the DtoLib can convert back and forth, including the Service App where the vast majority of these calls will take place.
Any guiding advice would be greatly appreciated but I do have a working demo now that I can test things out with while I work through this large refactoring.
Final Update
I changed the demo project just a little by adding another library (MappingLib) and moved all of my DTO conversions and mappings to it in a static method. While I still call the static method in my composition root after the Unity container is initialized, this gives me the added flexibility of being able to call that same map creation method in my NUnit unit test libraries, effectively eliminating any duplication of code surrounding auto mapper and makes it very testable.
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