We have this scalariform feature enabled in our project like this:
<check level="error" class="org.scalastyle.scalariform.NonASCIICharacterChecker" enabled="true"/>
However we want to whitelist some non ASCII characters (e.g. λ). Is this possible and if so how?
Related
I've recently made some databasae changes to custom objects, and I'm trying to generate a new enterprise.jar to reflect these changes. I'm following all documentation located here for the process. I'll also note, with the exception of some new dependencies, I've followed this process before with no errors to generate the enterprise.jar file. So this is a process that has worked for my sandbox in the past, but we haven't had any structural changes to the database in a solid 5 years.
Following along with the steps is simple enough. I generate the XML file from my Salesforce login in my developer sandbox utilizing Enterprise WSDL (we clearly have Enterprise level service, just so that's established). From there, I go to the Maven repository, get force-wsc-48.0.0.jar from there (as per the current API version of my sandbox), and then download a few dependencies like rhino, ST, and antlr-runtime. I get all files together in a temp folder in my C drive and try running command:
java -classpath C:\temp\force-wsc-48.0.0.jar;C:\temp\rhino1_7R4\js.jar;C:\temp\ST-4.3.1.jar;\jdk\jdk1.8.0_251\lib\tools.jar;C:\temp\antlr-runtime-3.5.jar com.sforce.ws.tools.wsdlc C:\temp\enterprise.wsdl C:\temp\enterprise.jar
Here's where the trouble begins. Once I run this, I hit the following error:
Exception in thread "main" com.sforce.ws.wsdl.WsdlParseException: Parse error: Found invalid XML. could not determine namespace bound to element prefix xsd (position: TEXT seen ...ration value="ACTIONCALL_DUPLICATE_INPUT_PARAM">\r\n<xsd:annotation>... #17360:17)
at com.sforce.ws.wsdl.WsdlParser.next(WsdlParser.java:94)
at com.sforce.ws.wsdl.Definitions.read(Definitions.java:111)
at com.sforce.ws.wsdl.WsdlFactory.createFromInputStream(WsdlFactory.java:69)
at com.sforce.ws.wsdl.WsdlFactory.create(WsdlFactory.java:49)
at com.sforce.ws.codegen.Generator.generate(Generator.java:94)
at com.sforce.ws.tools.wsdlc.run(wsdlc.java:115)
at com.sforce.ws.tools.wsdlc.run(wsdlc.java:149)
at com.sforce.ws.tools.wsdlc.main(wsdlc.java:71)
Caused by: com.sforce.ws.ConnectionException: Found invalid XML. could not determine namespace bound to element prefix xsd (position: TEXT seen ...ration value="ACTIONCALL_DUPLICATE_INPUT_PARAM">\r\n<xsd:annotation>... #17360:17)
at com.sforce.ws.parser.XmlInputStream.next(XmlInputStream.java:138)
at com.sforce.ws.wsdl.WsdlParser.next(WsdlParser.java:90)
... 7 more
Caused by: com.sforce.ws.parser.XmlPullParserException: could not determine namespace bound to element prefix xsd (position: TEXT seen ...ration value="ACTIONCALL_DUPLICATE_INPUT_PARAM">\r\n<xsd:annotation>... #17360:17)
at com.sforce.ws.parser.MXParser.parseStartTag(MXParser.java:1826)
at com.sforce.ws.parser.MXParser.nextImpl(MXParser.java:1144)
at com.sforce.ws.parser.MXParser.next(MXParser.java:1111)
at com.sforce.ws.parser.XmlInputStream.next(XmlInputStream.java:136)
... 8 more
A snipped of the XML at error line:
<!--
These are the extension code to provide additional error information
-->
<simpleType name="ExtendedErrorCode">
<restriction base="xsd:string">
<enumeration value="ACTIONCALL_DUPLICATE_INPUT_PARAM">
<xsd:annotation>
<xsd:documentation>
Errors with this extended error code have the following properties: severity, actionCallName, parameterName
</xsd:documentation>
</xsd:annotation>
</enumeration>
<enumeration value="ACTIONCALL_DUPLICATE_OUTPUT_PARAM">
<xsd:annotation>
<xsd:documentation>
Errors with this extended error code have the following properties: severity, actionCallName, parameterName
</xsd:documentation>
</xsd:annotation>
</enumeration>
Parent schema:
<schema elementFormDefault="qualified" targetNamespace="urn:fault.enterprise.soap.sforce.com">
<import namespace="urn:enterprise.soap.sforce.com"/>
I don't know if it's necessary, but I'll note that there's no <xsd:schema...> at all in the XML file. xsd is used before this, but only to define element string types; eg: <element name="sessionId" type="xsd:string" nillable="true"/>
If I remove xsd prefix from everything that causes the error, I'll instead get the same error, but for soap instead of xsd. XML snippet of first instance of that:
<!-- Soap Binding -->
<binding name="SoapBinding" type="tns:Soap">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="login">
<soap:operation soapAction=""/>
<input>
<soap:header use="literal" message="tns:Header" part="LoginScopeHeader"/>
<soap:body parts="parameters" use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
There's no parent schema here.
Again, there is no <soap:schema...> defined in the XML. And if I remove all of the instances of using the soap prefix, I'll land on the following issue.
Exception in thread "main" com.sforce.ws.wsdl.WsdlParseException: targetNamespace not specified in wsdl:definitions
at com.sforce.ws.wsdl.Definitions.read(Definitions.java:115)
at com.sforce.ws.wsdl.WsdlFactory.createFromInputStream(WsdlFactory.java:69)
at com.sforce.ws.wsdl.WsdlFactory.create(WsdlFactory.java:49)
at com.sforce.ws.codegen.Generator.generate(Generator.java:94)
at com.sforce.ws.tools.wsdlc.run(wsdlc.java:115)
at com.sforce.ws.tools.wsdlc.run(wsdlc.java:149)
at com.sforce.ws.tools.wsdlc.main(wsdlc.java:71)
Again, not sure if it matters, but there's no <wsdl:definitions...> in the XML file.
I don't know if this is an issue of Salesforce generating a bad XML file (the issue occurs even in sandboxes I haven't made any database changes for, including production where I have an old but working enterprise.jar), if I don't have the right force-wsc jar file, if I'm not running it through the right version of Java (1.8, if it wasn't clear, but I've tried earlier versions of java and I just get the minor.major 52 error, which means it should be 8, as far as I know).
Any help pinpointing what the issue here is would be greatly appreciated. I'm more than open to suggestions. And if it is just Salesforce giving me a bad XML file, I can open a ticket there. I just want to make sure I'm not doing something wrong before I open a ticket.
After spending more time on this, and after coordinating with a co-worker who works on a different Salesforce project, we've discovered the following
1 Salesforce was absolutely giving a bad WSDL file.
2 The generation of the bad WSDL file only occurred because I was using a Firefox web browser. Using Chrome instead to access the WSDL generation fixed the issue, of all things.
So for any poor soul that comes across this issue in the future, I hope using Chrome fixes it for you as well.
Hopefully I can keep this as clear and simple as possible. I'm trying to replace variables in my web.config based upon an environment. Currently I am able to replace other variables such as the one in my connection string and app settings by putting the variable in the format "#{variablename}#. This is not working for the variable in the endpoint address.
I was previously using replace tokens to accomplish this but it must now be built into azure because I don't have any extra task in the build or in the release task that's performing the replacement. Unless it's somewhere else that I'm not aware of. I have searched everything I could find and I am not seeing a reason why the value in this section isn't replace I thought it was replacing based off of name but I don't see why this value won't replace.
This replacement works with VariableName ConnectionString
<connectionStrings>
<add name="ConnectionString" connectionString="#{ConnectionString}#" providerName="System.Data.SqlClient"/>
</connectionStrings>
This doesn't work with VariableName ServiceSoapEndPoint
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="Service" />
</basicHttpBinding>
<customBinding>
<binding name="Service1">
<textMessageEncoding messageVersion="Soap1" />
<httpTransport />
</binding>
</customBinding>
</bindings>
<client>
<endpoint address="#{ServiceSoapEndPoint}#" binding="basicHttpBinding"
bindingConfigu`enter code here`ration="ServiceSoap" contract="Service.ServiceSoap"
name="ServiceSoapEndPoint" />
</client>
I wasn't able to find the exact solution I was looking for so I ended up doing a work around to accomplish this. I was basically trying to have environment variables so that when I would publish it would change the endpoint address based on the environment. Since I was able to get the value to change in the appsettings element I did a work around to instantiate the soap service using the value read from the appsettings value.
I am working on configuring NLog configuration which works perfectly for logging into text files. Now on the top of this I want to set a conditional target as Mail which should get fired only for a specific set of exceptions. For example - if there is a PaymentFailedException, CardExpiredException then the NLog should target Mail.
I have checked the NLog documentation but I could not find any way to set it for specific set of exceptions. However, NLog allows for setting target as Mail for exception levels.
You could configure use the <when> for this.
e.g.
<logger name="*" writeTo="myMailTarget">
<filters>
<when condition="not contains('${exception:format=type}', 'PaymentFailedException") action="Ignore" />
</filters>
</logger>
See filtering log messages and <when> docs
The server.log says "signature_status": "UNVERIFIED". Is this a certificate issue?
Also what are the best ways to read the pingfederate logs in windows machine.
That sounds like an issue with signature verification, which could be the cert itself but is more likely a configuration issue. More information is really needed to know which it is.
I assume the issue you are having with reading logs on windows machines is because the files are large or are moving quickly. If the files are too big you can modify the log4j2.xml config file at appdir/pingfed*/pingfed*/server/default/conf/log4j2.xml to reduce the log size to something easier to read in notepad. Here is an example rolling file appender that should leave you with easily maneageable files.
<RollingFile name="FILE" fileName="${sys:pf.log.dir}/server.log"
filePattern="${sys:pf.log.dir}/server.log.%i" ignoreExceptions="false">
<PatternLayout>
<!-- Uncomment this if you want to use UTF-8 encoding instead
of system's default encoding.
<charset>UTF-8</charset> -->
<pattern>%d %X{trackingid} %-5p [%c] %m%n</pattern>
</PatternLayout>
<Policies>
<SizeBasedTriggeringPolicy
size="20000 KB" />
</Policies>
<DefaultRolloverStrategy max="5" />
</RollingFile>
If you issue is that the files are moving too fast to read then you might consider using something like baretail or Get-Content in powershell now that it has a tail switch.
I modified my web.config to add a custom binding in order to increase the buffer and message size, and it seems like in creating the service element explicitly, it has somehow broken the reference to my behavior element.
When I try to run my web service from VS using the WCF Test Client, or I go to the service page, I get the error:
Metadata publishing for this service is currently disabled.
I've compared my web.config to a few different sources on this and everything seems to match. I've no idea what the issue is.
Here is the System.serviceModel element:
<system.serviceModel>
<services>
<service name="BIMIntegrationWS.BIMIntegrationService" behaviorConfiguration="metadataBehavior">
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
<endpoint address="http://localhost:1895/BIMIntegrationService.svc"
binding="customBinding" bindingConfiguration="customBinding0"
contract="BIMIntegrationWS.IBIMIntegrationService"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="metadataBehavior">
<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpGetEnabled="true"/>
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<customBinding>
<binding name="customBinding0">
<binaryMessageEncoding />
<httpTransport maxReceivedMessageSize="262064"
maxBufferSize="262064"
maxBufferPoolSize="262064" />
</binding>
</customBinding>
</bindings>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" aspNetCompatibilityEnabled="true"/>
It almost seems like either the web service page is not finding the element. I don't get an error complaining that the target behaviorConfiguration doesn't exist, or anything like that, just that Metadata publishing is not enabled.
Any help would be greatly appreciated.
Thanks.
I think i've "fixed" the issue. More coming later.
EDIT:
In order to "fix" my issue, I basically added a new WCF service to my application, and had it implement my previous interface, I then copied all the code from my original service and when I tweaked the .config file (to look pretty much like the one posted in the question), everything worked fine.
Ofcourse, I know, like we all know, that there is no magic here, that there must be some discrepancy. This is when I noticed/remembered, that after I had created my original service, called "BIMIntegrationService.svc", I had decided that this was too long of a name, so I renamed/refactored my class to "BIMIntegrationWS". Doing this, however, does not change the name of the service file (and therefore the name of the file in the http:// address).
Long story short, I made 2 changes to my .config and everything worked:
1) I changed:
<service name="BIMIntegrationWS.BIMIntegrationService" behaviorConfiguration="metadataBehavior">
to
<service name="BIMIntegrationWS.BIMIntegrationWS" behaviorConfiguration="metadataBehavior">
After running the service like this, I got an error (a helpful one this time) complaining that if multipleSiteBindings was enabled, the endpoint address had to be relative. So:
2) I set that to false (because I don't remember why it was in there in the first place) and everything worked fine.
I guess I should have taken a hint when it seemed like my web service was not using my "service" element at all. :\
EDIT 2:
Actually, you can see in my second comment, in the original question, that the auto-generated tag was pointing to: , as opposed to "BIMIntegrationService".
That should have given it away.
I doubt many other people will have this same issue, but just in case.
I've had the same trouble; I've gotten everything configured correctly (even copied the code from a previous service I have running) and yet no change on allowing the service to expose metadata. yet, if I make a spelling error, parse error, etc. to the app.config I'm given exceptions telling me to correct the problem (which tells me the service is reading the config, just disregarding it.
I was able to bypass it by generating the config settings in the host application:
System.ServiceModel.Description.ServiceMetadataBehavior smb = new System.ServiceModel.Description.ServiceMetadataBehavior();
smb.HttpGetEnabled = true;
ServiceBase host = new Servicebase(typeof(MyService), new Uri("http://localhost:1234/"));
host.Description.Behaviors.Add(smb);
host.Open();
...
host.Close();
Basically allow the code to override and push the config file changes i wanted applied. I know it's not ideal, but I was exposing the service through a windows service which made this do-able. if you do get your problem resolved, please pass along the solution though as I'd be curious to know why (at least in yours, if not both our cases) it's failing.