Request method 'GET' not supported in Graphdb 8.8.1 - graphdb

I just upgraded from graphdb 8.4.1 to graphdb 8.8.1 - which worked quite well. However I could not access the triple store via sparql and GET anymore and get a lot of
[WARN ] 2019-03-19 21:08:20,090 [http-nio-7200-exec-8 | o.s.w.s.PageNotFound] Request method 'GET' not supported
How can I switch that on?
Thanks in advance!

The only think I can think of, since I cannot reproduce your issue is that you maybe overwrote some of the files in the directory. I created a repository in 8.4.1 and copied the data folder to 8.8.1 and it works fine. The big difference between 8.4 and 8.8 is the removal of the System repository, but all of your existing repositories will work when migrating.

Related

Is the ddd() helper not working in Laravel 9?

I upgraded to Laravel 9 the other day, and now the ddd() helper is failing with the error Call to undefined function ddd(). I found this post on the Laracasts forum, but at time of writing there is only a single reply that states that the facade/ignition was replaced with spatie/laravel-ignition. I did not see anything in the documentation for the new package that mentions anything changing with ddd(), is there an additional configuration or something that is needed to re-enable ddd()?
Take a look at this https://github.com/facade/ignition/pull/201#event-2712168617
jasonvarga deleted the ddd branch 2 years ago
And you are right about not seeing any documentation about it in changelogs as well.
I heard this ddd() helper for the first time from you, so thax for that.
Please do check out the documentation of both of the packages.
Here facade / ignition and spatie / laravel-ignition
Both packages saying the same thing that
spatie/laravel-ignition works for Laravel 8 and 9 applications running
on PHP 8.0 and above. Looking for Ignition for Laravel 5.x, 6.x or 7.x
or old PHP versions? facade/ignition is still compatible.
In spatie/laravel-ignition version 1.2.0, ddd() was added back in! If you are not able to use ddd(), first check your composer.json file to make sure that your spatie/laravel-ignition version is 1.2.0 or above.
"require-dev": {
"spatie/laravel-ignition": "^1.2.3"
}

Quickbooks & Rails 5, can't create an invoice

Things were working fine until I started the upgrade from Rails 4.2 to 5.0
Using qbo_api gem (1.8.1) which also now needs the simple_oauth (0.3.1) as well as the oauth (0.5.4) gem. (The faraday gem (0.14.0) is loaded as another dependency.)
I can successfully do get requests for invoice, customer, etc., so the keys and initialization of the qbo_api object are all working for qbo_api.get() but when I try to create an invoice with qbo_api.create(:invoice, payload: ...), I get the error:
Operation Could not find resource for relative : /v3/company/123145710499109/invoice of full path: https://sandbox.qbo.intuit.com/qbo50/v3/company/123145710499109/invoice is not supported.
The same qbo_api object is working for get, I see nothing obviously wrong with the URL, and it is unreleated to the JSON payload. I'm not sure where to look to debug this problem.
BTW, clicking on the URL above seems to go to QB just fine, returning a validation error as you would expect.
This turns out to be a problem in the 1.8.0 and 1.8.1 versions of the qbo_api gem. Minimul has released version 1.8.2 which fixes this problem.
Kudos to Minimul for a quick response to this.
check your realmId. Most probably realmId is not match to your connected intuit app. This is why its tells that Operation Could not find resource for relative.

Wso2 identity server load balanced setup refresh token issue

Refer the raised jira issue in below link .
https://wso2.org/jira/browse/IDENTITY-4633
Any solutions for solving this issue..,
We tried to temperorly solve this issue by editing sqlscripts.java file by downloading it from github, compiled it and tried to pack in same jar file (using winzip, as jar files are zip finally).
As part of the change we had removed TOKEN_SCOPE column from relevant sql query, but still error in log describes 'invalid column TOKEN_SCOPE'
Kindly suggest to make any further changes or share me the jar file.
I am using wso2 identity server v5.1.0
Thanks.
This issue seems to be already reported in https://wso2.org/jira/browse/IDENTITY-4532
This issue is already fixed in 5.2.0 which will be released soon. You can try the 5.2.0 beta from https://github.com/wso2/product-is/releases/tag/v5.2.0-beta
You can find the fix from the PR in the jira I have pointed.

Icinga2 object ApiUser is unknown

I need help understanding an error why I'm seeing an error.
The feature api is already enabled with the correct ApiListener object, and Api logs are being updated in /var/lib/icinga2/api/log/current .
But I'm getting this error when I restart icinga2:
Error: Error while evaluating expression: The type 'ApiUser' is unknown: in /etc/icinga2/conf.d/api-users.conf: 1:0-1:20
I'm running version r2.3.10-1 of Icinga2 on Ubuntu.
Can someone explain what the problem is?
You are probably mixing the current snapshot packages with the released stable versions. The 'ApiUser' object is part of the upcoming Icinga 2 v2.4 release and only available in git master (and therefore snapshot packages as well as docs). The stable 2.3.x tree does not have that kind of configuration object type and therefore bails out with an error.
Remove that file or its content, you don't need it for 2.3.x.

typo3 update 4.7 -> 6.2 - broken backend

I've performed an update from typo3 4.7.20 to 6.2.15. The process worked fine and there were no critical errors while running the install tool.
The frontend looks fine but the backend is broken:
I've removed all uncompatible extensions before I run the update. I've also checked all settings in the installationtool und deleted the temp/cache folder first.
I've got the feeling that the error is caused by the TemplaVoila! extension, I'm using v. 1.9.8. Firebug does not shows any error.
Does anyone had a similar problem and have already solved it?
Thank you very much!
I have come across this one multiple times. More often it is because there is a broken TBE_STYLES. I suggest you look around for $TBE_STYLES in your typo3conf folder and disable it for the time being. Most likely it will be in the extTables.php or some other file which is included dynamically.
seems BE is working, but you css does not got loaded.
check your 'web inspecter' to see if you get errors on loading CSS.
clear your cache (remove everything in typo3temp) and try again