I need to upgrade an existing rather large application from Symfony 2.0.15 to Symfony 2.4.x (replace with current version).
I'm not quite sure what would be the best strategy to do so. Migration critical features like forms or esi are used, of course :)
Upgrade "step by step" from one major version to another (2.1, 2.2, 2.3, 2.4)
Upgrade directly from 2.0.x to 2.4
Do you have any tips / experience to share ? Would appreciate it :)
Thanks,
Stephan
Each new version comes with an update UPGRADE-2.x.md file containing all intructions to convert your application from the immediately previous version.
I had to do that on my project as well, and I found the step-by-step method more natural and easier to manage. Fact is, there is no file such file as UPGRADE-2.0-to-2.4.md that would help you out for a direct conversion to 2.4.
I shall first recommend to make sure that none of your code uses obsolete functionnalities of Symfony 2.0 (not sure if there are deprecated parts in this version, though), because these can be removed in ulterior versions and will not be included in the UPGRADE file.
If you have done indeep modifications of the core Symfony code, you may find that some undocumented modifications are needed. For instance, there is a custom error handler in my project, extending the Symfony error handler. Well, although it was not documented in the UPGRADE file, the signature of ErrorHandler::handle() was modified and needed to be updated in my custom handler.
Similarly, I had to modify some namespaces because files had been moved in the framework code.
The conversion is still ongoing and I'm currently experiencing a weird error I'm trying to get rid of: The 'request' scope on services registered on custom events generates errors in the logs.
Related
I'm trying to upgrade a Symfony instance from 2.8 to 3.0, and, while I was checking the deprecations in profiler, I found:
The Twig\Template class implements Twig_TemplateInterface that is deprecated since 1.12 (to be removed in 3.0) (2 times)
The Twig\Lexer class implements Twig_LexerInterface that is deprecated since 1.12 (to be removed in 3.0)
The Twig\Compiler class implements Twig_CompilerInterface that is deprecated since 1.12 (to be removed in 3.0)
The Twig\Node\Node class implements Twig_NodeInterface that is deprecated since 1.12 (to be removed in 3.0)
The Twig\Parser class implements Twig_ParserInterface that is deprecated since 1.12 (to be removed in 3.0)
My Twig version is 1.42.4
Just to confirm: we agree this is deprecation messages from twig itself, telling it will remove those functions in its own 3.0 version ? I mean: it's not Symfony telling it will not support this anymore in its 3.0.0 ?
I also suppose upgrading Twig will not help on this. It is the the responsible for those calls I guess ;)
After confirming the above basics, how can I locate the bundle which uses those deprecated functions, because I suppose THIS is the package I need to upgrade first (I'm pretty sure the problem is not in my own code...) ?
The message does not give so many details, and... the stack is just unclear to me...
DebugClassLoader::loadClass()
spl_autoload_call()
class_exists() (called from Template.php at line 5)
require() (called from DebugClassLoader.php at line 169)
DebugClassLoader::loadClass()
spl_autoload_call()
ReflectionClass::__construct() (called from ClassCollectionLoader.php at line 307)
ClassCollectionLoader::getOrderedClasses() (called from ClassCollectionLoader.php at line 120)
ClassCollectionLoader::load() (called from Kernel.php at line 405)
Kernel::doLoadClassCache() (called from Kernel.php at line 124)
Kernel::boot() (called from Kernel.php at line 180)
Kernel::handle() (called from app_dev.php at line 28)
Maybe that can help to answer: I noticed the deprecation warnings appear ONLY when I load a page for the first time, or when I just deleted the cache... So, it's something generating the Symfony cache, which is calling deprecated features...
At last, but not least, I tried to upgrade Twig from 1.x to 2.x, knowing Symfony composer tells "twig/twig": "^1.0||^2.0". I first though it would go to 2.x, but it just upgraded it to the lmatest 1.x (1.42.4), my current version... Composer message was not clear about what was reponsible of the fact it did not go higher...
IF I understood well, those deprecation warnings are not about Symfony upgrade itself, so I 'could eventually go for it. I have something in my instance, that uses old Twig functions, so I would like to get rid of it...
BONUS question: sometimes, I wonder... it's so complicated to fight with all those version constraints... Wouldn't it be more simple just to use generic composer.json, provided with the symfony version we are trying to reach, instead of editing the one we get for years, in our old version ? At least, I guess all libraries would be updated at versions tested by developpers ?
Thanks for helping, and happy new year ;)
In short, sometimes deprecations are reported for vendor code that you can't really change. This is the case. It's useless for you.
It will go away eventually, once you upgrade to higher Symfony/Twig.
In a project built using Symfony 4, we use NelmioApiDocBundle version 3 plus Swagger annotations, which works fine.
In addition to browsing the API docs, I would like to create a static version of the documentation, to be generated in a build pipeline. (In your case, it’s Bitbucket Pipelines, but that shouldn’t make a difference.) NelmioApiDocBundle version 2 had a command for emitting documentation, but it seems version 3 no longer has. It’s easy to write a command which fetches ApiDocGenerator from the Symfony container and thus to obtain the information I want – but I can’t imagine I am the only one who wishes to do this.
Am I overlooking something? Does NelmioApiDocBundle really not have a built-in way of generating static, offline documentation?
I google a lot but not find any solution. Below is my problem :
I make a simple project where I use reference "IdentityServer4.Postgresql": "1.0.0"
where "using IdentityServer4.Services.InMemory" works perfectly.
But when I use "IdentityServer4.Postgresql": "2.0.0" then IdentityServer4.Services.InMemory always shows error.
That means version 2 of IdentityServer4.Postgresql not support IdentityServer4.Services.InMemory.
How can I use IdentityServer4.Services.InMemory for "IdentityServer4.Postgresql": "2.0.0"?
Thanks in advance.
IdentityServer4.Postgresql is not a part of the IdentityServer project, but sounds like a community contribution. You may have a better result by contacting the library creator.
Otherwise, you could try the official IdentityServer4.EntityFramework package that is maintained by the IdentityServer team in combination with an Entity Framework Core database provider for PostgreSQL.
The official quickstarts only show adding Entity Framework in the 8th quickstart. You'll have to do each one in succession up to the eighth one to fully understand / make sure to have the code you need.
After you have Entity Framework added to the configuration, you can support a Postgres database by just adding dependencies.
At the moment, the Hibernate Validator has released the latest version as 4.3.0.Final here. I have tried to upgrade it to my Glassfish 3.1.2 as the following step: -
1. Remove the GLASSFISH/glassfish/modules/bean-validator.jar
2. Copying the hibernate-validator-4.3.0.Final.jar to GLASSFISH/glassfish/modules
3. Restart the Glassfish
4. The Glassfish cannot start. It seems hang.
After searching via the Google, I've found that the file named "bean-validator.jar" was created by the Glassfish team as an OSGi version. Sadly, I cannot find how to create it. Could you please help to advise further? Thank you very much for your help in advance. I'm looking forward to hearing from you soon.
A (slightly outdated) description of how to build Glassfish's bean-validator.jar can be found here.
What's needed in general is an OSGi bundle which includes Hibernate Validator itself and the Bean Validation API. With this bundle you should be able to replace the original bean-validator.jar. Additionally you need the JBoss Logging bundle, which is used since release 4.3 by Hibernate Validator as logging API and already comes in form of an OSGi bundle.
If you're building a web application, you could also package HV 4.3 within your WAR and turn off class loader delegation by providing the file WEB-INF/glassfish-web.xml with the following contents:
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
<class-loader delegate="false" />
</glassfish-web-app>
That way the HV classes will be loaded from your application instead of from the module provided by Glassfish.
You might also be interested in the issue GLASSFISH-15648 which aims to provide a dedicated Glassfish update package for HV.
As my case was ear, rather than war, based on suggestion of Gunnar, I did a patched version of the module, that is deployable to Glassfish (My version is 3.1.1 OSE).
Someone might find it still useful, see my blog for my solution (including step-by-step approach): http://peter-butkovic.blogspot.de/2012/11/glassfish-311-oss-with-hibernate.html
I have a previous project running Ninject 2.0 runtime version 2.0 and now I am using Ninject in a new project and using the new Ninject, ninject web.mvc version 2.2 for runtime version 4.0.
Every single time I get the error no parameterless constructor
Invalid Operation exception
An error occurred when trying to create a controller of type HomeController'. Make sure that the controller has a parameterless public constructor.
What am I missing. All the bindings are registered.
Do I need to now define interfaces for Controllers as well such as HomeController as IHomeController as I have seen in some examples, Or do I get back to using the older version
There is one version that does not show activation exceptions properly but show this exception instead. Most likely the problem is a duplicated binding.
In addition to what Remo Gloor said, you might want to check that MVC is set up to use Ninject correctly. I was doing some things manually on an older version of the MVC plugin and ended up needing to just bite the bullet and make Global extend the NinjectHttpApplication class, which I had previously been avoiding.
The error you're getting is the error you would get if MVC tries using its built-in controller factory to produce controllers. So you may want to create a custom method binding on your controller class and put a breakpoint inside to make sure it's even being invoked.
You may also want to switch to version 2.3. You can pick up the latest builds of Ninject and all its extensions here.
I have seen this issue mentioned couple of times on forums where there is no direct answer, here is the solution to the above problem, i.e., working with latest ninject
Download the latest Ninject from github.
The ninject I got for MVC2 is named as Ninject.Web.Mvc2-2.2.0.0-release-net-4.0 (runtime version 4)
Now during adding reference add Ninject.Web.Mvc.dll(check the version is same as above by right click properties in VS)
Now Add Ninject.dll from the lib folder in same parent folder (check the version as above)
Now Add CommonServiceLocator.NinjectAdapter.dll from the extensions folder in lib parent folder (check the version as above.)
The missing link in all these have been the commonserviceLocator.dll and the correct version should match. This should be tried if you are sure your bindings are correct as mine were and check to see if your project work with older version.
Thanks to everyone, and good luck :)