Symfony Assetic bundle 2.3 doesn't work with Sass - symfony

I have 2 project on my server with the same configuration(Symfony, MopaBootstrapBundle with Sass).
One works perfect, but it use elder version of Assetic bundle(2.1).
And the second(with Assetic bundle v.2.3) breaks the server with this message in error.log:
[error] child died with signal 11
and css is not compiled.
I have compared two versions of the bundle and found that SassFilter class in the newer version use "goto" operator.
I tried to change it on "break 3" (this has the same logic in this particular method) and everithing works fine.
I searched throw the project and found 2 goto labels with the same name (one in the SassFilter and the other in the LessFilter), but I think that is not the problem because I don't use LessFilter and thanks to lazy loading it souldn't load.
So I googled the issue and didn't find any notices of this problem. May be I should check my server configuration (I have apache2) in order to work properly with "goto"?
Thanks in advance for any help.

Related

Symfony 5 doctrine_migrations error on script boot

As far as i can tell, i can't see any other questions that ask this, so here goes:
I've been running the latest Symfony, for a side project, and encountered this error as i was writing the app. Nothing i do now fixes it, not even re-installing symfony, and i have no idea what the problem even is. I am getting the error:
The parameter "doctrine_migrations.dir_name" has a dependency on a
non-existent parameter "kernel.root_dir". Did you mean one of these:
"kernel.project_dir", "kernel.cache_dir", "kernel.logs_dir"?
It seems that you are using the undefined kernel.root_dir variable in your config/packages/doctrine_migrations.yaml config file.
You should replace it by kernel.project_dir:
# config/packages/doctrine_migrations.yaml
doctrine_migrations:
dir_name: '%kernel.project_dir%/src/Migrations'
See: https://symfony.com/doc/master/bundles/DoctrineMigrationsBundle/index.html#configuration
Just to document the root cause.
Symfony 5 removed kernel.root_dir parameters. Doctrine Migrations Bundle uses it as default value for dir_name.
It's been discussed. See https://github.com/doctrine/DoctrineMigrationsBundle/issues/305 and https://github.com/doctrine/DoctrineMigrationsBundle/pull/295.
SOLUTION: right now (Symfony 5 and Migrations bundle 2.1.x), you should not delete doctrine_migrations.yaml. Leave it there with a dir_name that does not raise en error.
at this point i am assuming it is a symfony bug, so i will close this question. Thanks for everyone's help!
try
composer remove orm
composer require symfony/orm-pack

Configuration files are ignored after migrating to Servicemix 5

We use a .cfg file in ./etc directory to configure our bundle in ServiceMix. Everything worked fine in SMX 4.5.3, but when migrating to the 5th version the file is not picked up. When the bundle encounters a property the following exception is thrown:
java.lang.IllegalArgumentException: Property with key [xslt.dir] not found in properties from text: {{xslt.dir}}, StackTrace: org.apache.camel.RuntimeCamelException: java.lang.IllegalArgumentException: Property with key [xslt.dir] not found in properties from text: {{xslt.dir}}
However, if I put the properties in default-properties section in my blueprint configuration, it works.
Also, the console command config:list actually shows the properties for the bundle in spite of the exception:
Pid: misrouter
BundleLocation: mvn:ru.mig/mis-router/1.0-SNAPSHOT
Properties:
service.pid = misrouter
felix.fileinstall.filename = file:/home/petr/programs/5.0.0-apache-servicemix/etc/misrouter.cfg
xslt.dir = /home/petr/programs/5.0.0-apache-servicemix/xslt
So was something changed in SMX 5 configuration mechanism or is there a bug in it?
What version of the JDK/JRE are you using? When I was trying this out a few minutes ago to answer your question, I also had some problems using the 1.7.0_15 version I had installed and upgrading to the latest 1.7.0_51 fixed those for me.
Actually it's related to Camel vm component, a bug was created for SMX

"include_recipe" vs. Vagrantfile "chef.add_recipe". What's the difference?

Just ran nginx::source recipe on my vagrant box, and I have very unusual behaviour.
When I include a recipe from the Vagrantfile (as below), everything works like a charm,
chef.add_recipe("project::nginx")
chef.add_recipe("nginx::source")
(project::nginx recipe is very simple. Using it to override default attributes of the nginx cookbook)
but if I include a recipe at the very end of project::nginx (mentioned up), everything falls apart:
node.default['nginx']['server_names_hash_bucket_size'] = 128
include_recipe "nginx::source"
Until now I didn't know there's any difference in behaviour between those two invocations. Does anybody here knows what's the difference?
Gotya! Chef 11 feature. Issue with it exist in chef-solo solely :)
To make a quick resume, difference is:
chef.add_recipe() - loads entire cookbook context (all the files, e.g. recipes, definitions, attributes...)
include_recipe "" - files(attributes, definitions etc.) that are not in the expended run list are not loaded.
There are at least 4 ways to solve the issue(put files in the run list):
include_attribute - include desired attribute file explicitly.
metadata.rb->dependency - if your cookbook is using recipe from another cookbook, put that cookbook in metadata.rb's dependency section, and all it's files will be loaded.
chef.add_recipe() - Load recipe via Vagrantfile. (Mentioned here just for reference)
Berkshelf - you may use this cookbook manager to solve the issue as well. Here's the Stackoverflow thread about this exact problem and some Docs
For those who are interested in further reading, Chef 11 introduced dependency-based cookbook loading for non-recipe files. The new loading logic means that files belonging to cookbooks which exist in the cookbook_path but are not in the expanded run_list or dependencies of the cookbooks in the expanded run_list will no longer be loaded. REF: Opscode breaking changes documentation, and if you need a signature of the error I got, here's the exactly same one, even for the same cause.

how to ant build liferay-yuicompressor.jar?

I am using liferay 5.2 sp 2 on weblogic 10.
I need liferay-yuicompressor.jar file in the lib folder of domain.
I am tryign to create .jar file as per described on this link:
http://issues.liferay.com/browse/LPS-3169
When i ant build-yui i am facing below exception.
get-swing-ex:
[mkdir] Created dir: D:\Liferay Material\GOSI\liferay-portal-src-5.2.2\liferay-portal-src-5.2.2\portal-impl\20130301133406114\rhino1_6R7\toolsrc\com\liferay\mozilla\javasc
ript\tools\debugger\downloaded
[get] Getting: http://java.sun.com/products/jfc/tsc/articles/treetable2/downloads/src.zip
[get] To: D:\Liferay Material\GOSI\liferay-portal-src-5.2.2\liferay-portal-src-5.2.2\portal-impl\20130301133406114\rhino1_6R7\toolsrc\com\liferay\mozilla\javascript\tool
s\debugger\downloaded\swingExSrc.zip
[get] http://java.sun.com/products/jfc/tsc/articles/treetable2/downloads/src.zip permanently moved to http://www.oracle.com/technetwork/java/index.html
[unzip] Expanding: D:\Liferay Material\GOSI\liferay-portal-src-5.2.2\liferay-portal-src-5.2.2\portal-impl\20130301133406114\rhino1_6R7\toolsrc\com\liferay\mozilla\javascri
pt\tools\debugger\downloaded\swingExSrc.zip into D:\Liferay Material\GOSI\liferay-portal-src-5.2.2\liferay-portal-src-5.2.2\portal-impl\20130301133406114\rhino1_6R7\toolsrc\co
m\liferay\mozilla\javascript\tools\debugger\downloaded
BUILD FAILED
As per my understanding it is trying to get the .zip file from http://java.sun.com/products/jfc/tsc/articles/treetable2/downloads/src.zip
but it is no longer available and moved to http://www.oracle.com/technetwork/java/index.html
I need your help in getting liferay-yuicompressor.jar file.
Please help me out...
Nakul, I was responding your other post facing exception while deploying liferay on weblogic. Sorry I misunderstood your last comment on that post, as I used LifeRay 6.x, not 5.x.
How about we disable the minification for the runtime so that you do not need to use the liferay-yuicompressor.jar.
You can add the below to portal-ext.properties
javascript.fast.load=false
theme.css.fast.load=false
If you still prefer to do minification for performance reason, you can do it during the build time as described here: http://yui.github.com/yuicompressor/. Between runtime and build time minification, I always prefer build time.
try to comment
<ant antfile="toolsrc/build.xml" target="compile"/>
into the root build.xml
more than that if you will have similiar problems with xbean.jar just set
without-xmlimpl: no
into build.properties file

Compile error in empty cocos2d 2.0 (iPhone)

When I try to compile new cocos2d+box2d project in xcode4.
I got error message like:
/Users/bla-bla/Cocos2d testing/Cocos2d testing/libs/cocos2d/CCDirector.h:32:9: fatal error: 'kazmath/mat4.h' file not found [2]
/Users/bla-bla/Cocos2d testing/Cocos2d testing/libs/cocos2d/CCNode.h:37:9: fatal error: 'kazmath/kazmath.h' file not found [2]
File I checked, what is wrong?
This is caused by having a space in the path name to your project. To work around this, you'll need to add the following under your project's configuration... in Build Settings, in the group of Search Paths, set the Header Search Paths to the following value:
"${SRCROOT}/Cocos2d testing/libs/kazmath/include"
Be sure to include the double-quotes.
did you check in Finder to see if there is a real folder named kazmath in the same path as where CCNode is ? if not, there is probably a flaw in the templates install script for that version of coco. But dont rely on the 'tree view' of the Xcode project navigator to really know whether a file is present or not. If the path is wrong in the include, suggest you report it to the coco team. You could temporarily fix the import statements to get going, but that would be throw-away code :) when coco issues another release candidate, presumably fixed.
Ensure you are editing the right header search paths for the right target. 1 hour of my life wasted editing the main project or the app rather than the test!

Resources