In a solution in Lansa Integrator, I have an XML Binding where the XML format is still in flux. Most of it is fixed by now but minor changes are still expected.
With the SOAP Agent I could replace the WSDL - by creating a new solution with the same name as the old solution but referencing the new WSDL - and keep the bindings that already were set.
I have not found a way to accomplish this with XML Binding. I have tried the same as with the SOAP Agent - a new XML Binding with the same name - and I have tried editing the project manually in the XML Editor.
Is there a way for me to do this, so I do not have to recreate my bindings every time the XML format is changed?
Very simple, apparently: Within the same project group + group + solution group you create a new solution with the same name as the existing solution and of the same type (SOAP agent). Then you browse to (or add the URL to) the new WSDL.
Lansa Integrator then asks if you wish to overwrite the existing to which you agree.
Lansa Integrator will keep those parts that relates to the parts of the WSDL that hasn't changed, effectively making it an update.
Related
(Sample) Problem:
When a yaml source contains conflicting definitions, e.g. myClass and MyClass both generating into a java class MyClass with one overwriting the other, no warning or error occurs.
Other similar cases can occur the same way (e.g. via implicitly generated classes from complex entries of type: array).
Framing
has to work without modifying the source file
there is exactly one source file, for whatever that's worth
has to work as a Maven plugin
tested with swagger-codegen-maven-plugin 2.4.0 and 2.4.22
am familiar with JAXB2 and both of its common Maven plugins:
jaxb2-maven-plugin
maven-jaxb2-plugin
am not familiar with swagger-codegen-maven-plugin
did not find solutions (or even corresponding problem reports) using Google searches
swagger codegen strict
swagger-codegen-maven-plugin strict
swagger codegen name collision
swagger-codegen-maven-plugin name collision
swagger codegen resolve name collision
swagger-codegen-maven-plugin resolve name collision
found this closed issue describing a similar issue (silently generates corrupt code), which appears to be mostly unrelated and is alledgedly long fixed
Question
What is the proper solution that produces
an eagerly failing generation process
amended via externally configured customBindings
without touching the yaml source file
?
Solution ideas:
Use JAXB2 instead
JAXB2
fails generation where a generated file already exists
allows a separate customBindings.xjs file to modify generation of
classes
can be adapted to work with YAML using
JacksonJaxbYAMLProvider
However it seems that the common Maven plugins jaxb2-maven-plugin and maven-jaxb2-plugin do not support YAMl definition files (out of the box?). [1]
Use Mustache files to resolve the name collision
The Mustache language seems to provide the necessary facilities to implement rules similar to JAXBs xjb.
However
binding a Mustache template to a class has to be done by name (<class name>.mustache), aka. name collision in particular cannot be resolved from an external file [2]
this does not help with the silence of errors in generated code - one cannot fix the error, while unaware of it
1 - Searches for this topic have yielded one result that it does not work out-of-the-box (duh) and no results whether it can be made to work using the extensions interface both plugins support.
2 - I could not find the relevant part directly within Swagger codegen documentation, but here is a relevant part of the implemented-by-Swagger OpenAPI generator documentation.
I have an EJB that plays the role of my web service class too. I use Oracle Weblogic 12.1.2 as JavaEE container.
Here is the code of that class:
#Stateless
#WebService(serviceName="MyService")
#Policy(uri = "Wssp1.2-2007-Https-UsernameToken-Plain.xml", attachToWsdl=true)
#XmlAccessorType(XmlAccessType.FIELD)
public class MyWebServiceBean{
// some web methods ...
}
The attached policy and its corresponding wsse tags is properly can be seen in generated WSDL file. However, there is a IncludeTimestamp tag in the generated file that forces clients to send Timestamp in their request. As in my environment clients may have different times, I perefer not to force them to send the time! Then I simply omit the IncludeTimestamp Tag from the server wsdl and everything goes well after that! But I do not want to handle it by hand. Is there any setting in weblogic 12.1.2 to configure existence of mentioned tag?
After a lot reading and searching for this matter i found that we should create Custom Policy. Firstly we should find the xml file of the desired policy. Flow this post to do so. Then we should edit it and copy the edited version in our classpath and for #Policy annotation we should use new address of our xml file! That's it.
I am doing a windows service, using app.config, where there is a section to retrieve common configuration in another file. Using
AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", "filepath\\file");
works for me, but using
string appconfig = ConfigurationManager.AppSettings["CommonAppSetting"];
AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", appconfig);
does not. It gets from the app.config of the windows service instead of the common configuration.
Anything I did wrong, or is there other better ways of doing it?
You need to reset some variables (ClientConfigPaths) in the ConfigurationManager in order for it to refresh its values. These can be seen in the following accepted answer (complete with code for doing this legwork).
Change default app.config at runtime
I have some code (Forms/Frames) in the repository, is there anyway to disable the 'use' option. I only want objects in the repository to be 'inherited' or copied.
And is there a way to set the default to be 'inherited'
Have looked at the XML in the RADStudioRepository.xml and there is no obvious fields to add/edit.
Thanks
There has indeed never been a way to specify in the object repository for a form or frame to be "inherit only".
Not in the current RADStudioRepository.xml way of specifying what is in the object repository, nor in the old way (I forgot the config name back in the Delphi 2..7 days).
What you can do is suggest this as a new feature for a future Delphi version at http://qc.embarcadero.com
I think it is an interesting feature request, and would upvote such a request. So let us know if you create such a request.
I'm having some trouble merging the localization satellite assemblies into the plugin DLL for CRM2011.
Either that, or I don't know how to use the merged resources afterwards.
I create a few plugins and create a basic resource file (default - English) and one for a specific culture (at the time of writing it's for Polish localizations, but later I'll need to add French as well).
I make sure not to sign the assembly itself, as ILMerge will sign the finished assembly itself.
This is the command I use to merge the extra satellite assembly:
ilmerge /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319 /log:log.txt /keyfile:KeyFile.snk /out:Plugins.dll DynamicsCRM2011.Plugins.dll pl-PL\DynamicsCRM2011.Plugins.resources.dll
As you can see, the plugins are in .NET 4.0 and I've got the required .config file for ILMerge to use the required assemblies for merging.
The generated file appears fine, I can register it with CRM plugin-registrator, add new steps and so forth.
However, it will always use the default language. I've tried changing the System.Threading.Thread.CurrentThread.UICulture, but this didn't help. When I created a ResourceManager class and used GetString("ErrorMessage", new System.Globalization.CultureInfo("pl-PL")), I got an Exception that the specified ResourceManager doesn't know what to do with the specified culture.
I know of this question here. However, the posted solution seems to be an old one. The generated resource .cs files do not use a ComponentResourceManager. Also, parts of the code posted there have been marked as deprecated.
I'm not really sure what I'm am to do now, or how to further debug this, as I have very little experience when it comes to working with assemblies themselves. Please, help me get those satellite assemblies under control.
Update:
I've been working with sandbox plugins for a while now, and thus I no longer have access to things such as CurrentCulture (or at least I cannot change such things). I've tried tackling this problem once more: I've created a simple plugin which is fired when a new Account is saved. Nothing fancy. Here's the actual plugin code:
ResourceManager rm = new ResourceManager(typeof(Properties.Resources));
var s = rm.GetString("ErrorAlreadyPosted", new System.Globalization.CultureInfo("pl-PL"));
throw new InvalidPluginExecutionException(s);
The code no longer throws an exception about not being able to find the specified culture... also the code obviously throws an exception at the end, but the important thing is WHAT the exception message is. I'd expect it to be in Polish.
Alas, it is not. The string returned by GetString is still in English.
The command I used for ILmerge is the same as before, but with the /lib parameter specified so that I don't have to copy all the CRM SDK dlls...
Apparently it is not possible to read resources from with the context of a Plugin.
Read up on MSDN: http://msdn.microsoft.com/en-us/library/hh670609.aspx#BKMK_UseXMLWebResourcesAsLanguageResources
Quote: When a plug-in requires localized text, you can use an XML web resource to store the localized strings so the plug-in can access them when needed. The structure of the XML is your option, but you may want to follow the structure used by ASP.NET Resource (.resx) files to create separate XML web resources for each language. For example, the following is an XML web resource named localizedString.en_US that follows the pattern used by .resx files.
This is all I know so far - have yet to build my own solution for localization of a crm plugin.
If you use a reflector tool to look at the generated assembly, do you see your resource(s) embedded correctly? You may be experiencing the bug as outlined in the link you posted.
Try setting Thread.CurrentThread.CurrentUICulture and\or Thread.CurrentThread.CurrentCulture.
Also try hooking into the AppDomain.CurrentDomain.AssemblyLoad and\or AppDomain.CurrentDomain.AssemblyResolve to debug which assemblies are being attempted to load and from where. You might need to customize their behavior so that instead of loading an external assembly to load an internal resource instead.
You can try embedding project references as resources instead of using ilmerge as well.
See this: http://bartlomiej.net/dotnet/embeded-assembies-into-an-executable/
The way we eventually handled this is by adding the localization XML files (generated by Visual Studio) as CRM resources, and created a bit of custom code which seeks the appropriate resource and then seeks the localization text inside.
It's, obviously, not as simple as just using the generated C# localization class, and requires some prep work. However, with that prep-work in place and with using nameof it's now almost as simple as the aforementioned resource classes.