Following error shown in the problem section for unknown property
There is no easy way to fix the warning in STS4
Even after adding the quickfix, the error is not seems to be going
Description Resource Path Location Type
'IntuitAccountingAPIHost' is an unknown property. application.properties /hk-qbo-connector/src/main/resources line 8 org.eclipse.lsp4e.diagnostic
'OAuth2AppClientId' is an unknown property. application.properties /hk-qbo-connector/src/main/resources line 2 org.eclipse.lsp4e.diagnostic
'OAuth2AppClientSecret' is an unknown property. application.properties /hk-qbo-connector/src/main/resources line 3 org.eclipse.lsp4e.diagnostic
'OAuth2AppRedirectUri' is an unknown property. application.properties /hk-qbo-connector/src/main/resources line 5 org.eclipse.lsp4e.diagnostic
You should probably consider raising your problem as a bug-report or feature request on our issue tracker. It doesn't read like a 'question' to me, and so it probably doesn't belong on SO as such.
Nevertheless let me try and answer as best as I can.
Even after adding the quickfix, the error is not seems to be going
It will, once you save the additional-spring-configuration-metadata.json file where the quickfix creates new metadata for you.
I agree it is a little unintuitve that the change is not saved automatically, but I'm afraid we (STS vscode extension) don't have control over this. The changes are being applied by the Vscode language server client, and it's the client's decision to apply the changes only to 'dirty' editor buffers rather than apply them directly to the files on disk.
As to your general statement that 'In STS 4.0 ignoring unknown property support is missing'... I think you are referring to the fact that in STS3 it used to be possible to ignore problems of a given type altogether and this is no longer possible in STS4. This is true. If you like to get this kind of user-configurability back again, please consider raising a feature request on our issue tracker. SO, really isn't the place to ask for this sort of thing.
In STS 4.11, you will find this option in Window -> Preferences -> Language Servers -> Spring Language Servers -> Spring Boot Language Servers -> Yaml Editor or Properties Editor.
Related
I was looking for a configuration parser for go and https://github.com/spf13/viper seems to come highly recommended.
I am very surprised to find that configuration files are not validated by default.
Viper parses files and extracts requested values from them but I cannot find a way to detect bad configuration.
For instance I if create a (Java style) .properties file containing just "???" and nothing else. This is accepted without any error.
I can understand the philosophy that you should ignore irrelevant configuration items but I desire more rigor. I would also like to reject anything that does not match the X=Y format in a properties file.
To me this is a fatal flaw that suggests I should use a different package (or roll my own as usual).
Have I missed something? Does viper in fact support detecting and rejecting bad configuration keys?
I think the answer is no. viper does not validate java .properties files.
I posted a bug report (or feature request depending on your point of view) as https://github.com/spf13/viper/issues/790
You can try https://github.com/num30/config library which is based on Viper. It has built-in validation.
I've tried to compile .NET project and this CA appears, however I can't find any information about it on MSDN, do you know how to fix it?
The documentation can be found here:
https://msdn.microsoft.com/en-us/library/dn621098.aspx
Rule Description
To use security critical types, the code that references the type must be either security critical or security safe critical. This is true even if the reference is indirect. For example, when you reference a transparent field that has a critical type, your code must be either security critical or security safe. Therefore, having a security transparent or security safe critical field is misleading because transparent code will still be unable to access the field.
How to Fix Violations
To fix a violation of this rule, mark the field with the SecurityCriticalAttribute attribute, or make the type that is referenced by the field with security transparent or safe critical.
In the Error List you can click the underlines CA2151 link or right click the line and select Show Error Help. Both actions will launch the MSDN overview of code analysis violations. From here you can find a link to the description of CA2151 and how to fix it.
I am making a new biztalk solution, where i am using existing maps, schemas and orchestrations. And the orchestrations is giving me lots of problems.
I get this erorr message when I try to build my orchestration:
a 'module' must have a non-null XmlNamespace under BPEL4WS compliance
I can't find any solution to it anywhere, so I hope somebody can help me here.
What does that error mean and how do I solve it??
It turned out that if I clicked on the Project name, there is a BPEL Compliance that was set to True. Should have been set to false.
This doesn't look familiar at all.
Right click on the project and hit properties. Check to see if your assembly namespace and name are set in the 'Application' tab.
Open the orchestration and click on the background between the port surfaces. Check the namespace in the properties window.
If that doesn't work perhaps you can temporarily remove items from the orchestration to see if you can isolate which shape is causing the error.
I have had very strange issues where the orchestration namespace was incorrect.
Some projects require the BPEL Compliance setting to be true. For those projects you may have two cases:
If you do not wish to export the orchestration as a module; make sure the Module Exportable setting is false.
If you wish to export the orchestration as a module; make sure the Module Exportable setting is true together with a Module XML Target Namespace setting that has a valid value instead of being empty (or null)
Magento seems to be using "Happy go Lucky" error handling, where all errors in xml files will just cause the xml config file to be ignored. And missing/wrong tags will just be ignored too, sometimes causing Magento to skip parts of the xml file.
But is there any way(A log file or something) which shows exactly what part of the config files Magento skips, and which tags are unknown/wrong. Using Magento 1.6 if that matters.
From what I have seen in Magento, it will throw out the entire XML file if there is invalid XML in it - broken/mismatched tags, erroneous characters, etc. I think it would be somewhat impossible for a xml parser to do any sort of a decent job parsing this out - that's the goal of XML. If my configuration isn't loading, the first think I like to do is go and perform a wellformedness validation on the code, which will show me if I have a problem there.
If there is references to invalid classes, usually it will break. Layout XML is different - it will ignore the block and continue on, which can be a real pain to troubleshoot.
So, to answer your question - no, there isn't a native way to do this. The best way, IMO, is to go and validate it at a third party.
There is logging in Magento, to enable it:
Go into your Admin Panel, then System > Configuration > Advanced > Developer
Under Log Settings ensure Enabled = Yes
This will create two separate logs in magento root/var/log (in my case /var/www/html/var/log)
Exception.log will hold any errors created using Mage::LogException($e)
System.log will hold any logging created using Mage::Log('message')
You can also create your own log files...if you so wish by
Mage::Log('message', null, 'my.log');
This will create a my.log file in the var/log directory.
FYI - I believe the reason Magento handles configuration files in this manner is to protect the rest of the system from an issue with a single extension.
I have a Managed Object Context to which I add two different SQLite stores. I use Configurations in the Mananged Object Model to assign certain entities to one store and other entities to the other. The Configurations are called "UserDB" and "MainDB".
Everything works okay until I try to use automatic migration. After creating a new Managed Object Model version, and adding a new attribute to one of the entities in the UserDB Configuration, I get an exception when adding the old version store (for the UserDB related store) to the store coordinator: 'Model does not contain configuration 'UserDB'.' I can find no hits for this error on Google. Anyone out there using multiple stores with Configurations? Anyone have an idea what I might be doing wrong?
The stack looks like this:
objc_exception_throw
-[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:]
-[NSStoreMigrationPolicy sourceModelForStoreAtURL:metadata:error:]
-[NSStoreMigrationPolicy(InternalMethods) _gatherDataAndPerformMigration:]
-[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:]
-[MyAppDelegate persistentStoreCoordinator]
This looks like a bug with migration+configurations. I was able to work around the problem by going through the same motions and passing nil for configuration when calling addPersistentStoreWithType. The migration happens, and then I can make a new persistent store coordinator and add the stores again with the proper Configuration string arguments.
This is the second configuration related bug I've run into. Not a well tested feature apparently.
I had the same problem. The fact pattern was identical and the error message the same. It turned out, however, to be the result of my own mistake.
Let's say the old model was Blah.xcdatamodel and the new Blah 2.xcdatamodel. I had started making changes to Blah before realising my mistake and creating Blah 2. I then used my version control system (Git) to revert to the old Blah and then recreated Blah 2. Everything looked right. But I must have done something wrong in the reversion process, because when I thought to double check that Blah.xcdatamodel in my current project folder was really the same as Blah.xcdatamodel in the project folder I used to build the previous version of the app (fortunately I always keep a zipped archive of the project folder for each released version as I don't fully trust version control systems), I found that they were in fact different, albeit that they looked identical in XCode. The file size was different, for instance.
I substituted the old Blah into my current project folder, and lo and behold it all went perfectly, without any need for the workaround described by Ken.
I am not saying that Ken had necessarily made a similar mistake, but if you do encounter this message it is at least worth confirming that the model you are migrating from is REALLY the model that was used to create the data in question.