Initially used PHP 7.1.1 and Phalcon 3.4 to support API end. Once upgraded the PHP 7.2.24 and Phalcon 4.0.0 we faced the Phalcon response issue when calling the API. We mainly used Phalcon-rest to support API.
Below attached the file structure, source code and issue what I faced. Please share your inputs to resolve the issue.
Fatal error: Declaration of
PhalconRest\Http\Response::setJsonContent($content, $jsonOptions = 0,
$depth = 512) must be compatible with
Phalcon\Http\Response::setJsonContent($content, int $jsonOptions =
NULL, int $depth = NULL): Phalcon\Http\ResponseInterface in
C:\dev\servicechum_api\vendor\redound\phalcon-rest\src\PhalconRest\Http\Response.php on line 68
The upstream package you use (redound/phalcon-rest) is incompatible with modern PHP versions. The error message is self explanatory: the implementation of the Response::setJsonContent method must match the parent, while it does not.
Judging by the code, lack of tests, invalid library constraints (vide "php": ">=5.4") in the composer.json either downgrade your PHP or stop using this software, but prefer latter.
Related
Just upgraded to Laravel 8 / Laravel Passport 10.1 and Locbucci JWT 4.1. I'm getting this error:
Target [Lcobucci\JWT\Parser] is not instantiable while building [Laravel\Passport\Http\Controllers\AccessTokenController]
This error makes sense since Parser is an interface, if I remove it from the AccessTokenController everything works as expected. As far as I can tell these packages should work together. Am I missing something here?
This is an error caused by the version of Laravel/passport, to solve this problem you must update to a new version of the package
execute this command, good luck
composer update laravel/passport
I'm on OS X 10.11.1 running the latest version of X Code. I installed Lua 5.3 today from source with no problem. Seems to work correctly. No errors installing luarocks and then using it to install moonscript. However, both moon and moonc give the following error when invoked from the command line:
$ moon
/usr/local/bin/lua: /usr/local/share/lua/5.3/alt_getopt.lua:24: attempt to call a nil value (global 'module')
stack traceback:
/usr/local/share/lua/5.3/alt_getopt.lua:24: in main chunk
[C]: in function 'require'
/usr/local/lib/luarocks/rocks/moonscript/0.4.0-1/bin/moon:2: in main chunk
[C]: in ?
Looking at alt_getopt.lua shows that it is indeed using the now-defunct 'module' keyword. The GitHub project for this module appears to be dead with no action in the past 3 years.
How should I proceed to get Moonscript working on my system?
Yes, as you noted, module has been deprecated for quite a while and was only working with earlier versions because of compatibility switches.
You can comment out the line 24 in alt-getopt and add the following line to the end of the alt-getopt.lua file: return {get_opts = get_opts, get_ordered_opts = get_ordered_opts}.
This should make this module Lua 5.2/5.3 compatible (I haven't checked if there are any other compatibility issues with using Lua 5.3 though).
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.
Trying to achieve this proposal to make a div size based on its background image I'm using Less 2.5.1 compiled by Web Essentials 2013 for Update 4 version 2.5.4 and some functions do not resolve:
My Less File:
.myClass{
height:image-height("myUrl.png"); //<-- Do not resolve
width:percentage(1/2); //<--Resolves
}
Resolved Css File:
.myClass{
height:image-height("myUrl.png"); //Not good
width:50%; //Good
}
I'm having this problem with image-height, image-width and image-size. Not with the rest of Misc Functions
There's no problem resolving the image by the compiler, because it's working fine when I used it like:
background-image:url("myUrl.png");
In the documentation there's a note for these methods saying:
Note: this function needs to be implemented by each environment. It is
currently only available in the node environment.
In the WebEssentials documentation it says:
Web Essentials uses the node-less compiler and it always uses the
latest version
And
NodeJS compilation - Web Essentials uses NodeJS to run the compiler.
It's the fastest and most accurate compiler for LESS available.
I'm missing something that I don't know. What does that note mean? What
should I do?
I've create a jsfiddle to share with you my goal.
Validation framework which has been rolled up as part of the JEE6 spec (WL12). Both the WL10 and WL12 versions of our application were deployed with the following open source libraries:
JSR-303 / validation-api.jar (version 1.0)
Hibernate Validator (version 4.2.0)
However, the libraries are also bundled with WL 12 (modules directory). Note that the Hibernate Validator version is slightly different.
modules.javax.validation_1.0.0.jar
hibernate.validator_4.1.0.jar
With our WL12 run we are getting below exception:
javax.validation.ValidationException: Unable to get available provider
Attempted Solutions
Our next attempt was to use the WebLogic FilteringClassLoader to prefer the libraries from our application (APP-INF/lib directory) by specifying them in the weblogic-application.xml file (i.e. choose our versions over WebLogic’s). We were already doing this for several other open source libraries in WL10:
<prefer-application-packages>
<package-name>com.google.common.*</package-name>
<package-name>org.apache.commons.lang.*</package-name>
<package-name>org.apache.commons.logging.*</package-name>
<package-name>org.apache.commons.beanutils.*</package-name>
<package-name>org.apache.commons.collections.*</package-name>
<package-name>antlr.*</package-name>
<package-name>javax.validation.*</package-name>
<package-name>org.hibernate.validator.*</package-name>
</prefer-application-packages>
After making that change, our application experienced the following run-time error trying to process any request that makes use of the validation framework:
javax.validation.ValidationException: Unable to get available provider resolvers.
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:259)
at web20.hibernate.validation.ValidatorFactoryConfigurator.getValidatorFactory(ValidatorFactoryConfigurator.java:39)
at web20.hibernate.validation.ValidationHandlerImpl.handleHibernateValidations(ValidationHandlerImpl.java:180)
at web20.hibernate.validation.ValidationHandlerImpl.performValidation(ValidationHandlerImpl.java:255)
at web20.hibernate.validation.ValidationHandlerImpl.validateAndFormatMessages(ValidationHandlerImpl.java:302)
at web20.hibernate.validation.ValidationHandlerImpl.validateUsingHibernateGroups(ValidationHandlerImpl.java:113)
at service.serviceapp.performValidations(serviceapp.java:392)
at service.serviceapp.performValidations(serviceapp.java:379)
at service.TransactionalServiceImpl.search(TransactionalServiceImpl.java:300)
Given that Bean Validation is part of the EE standard, I assume there is some code Bean Validation integration code which causes the problem. I see two potential solutions:
Patch the WL instance and upgrade to the Validator version you want to use
Try writing your own ValidationProvider. Internally it could just delegate to the Hibernate Validator classes. If you then add a validation.xml to your application, specifying your custom provider, WL should bootstrap this one. TBH, I don't know whether this will work. There are many unknowns and I don't know enough about the integration of WL and Bean Validation.
Personally, I think I would just try to upgrade the Validator version used in WL.