Asked  1 Year ago    Answers:  5   Viewed   10 times

I am trying to create a simple bundle inheritance as instructed in here and ran into a problem with routes. I'm using annotations for routing. When I register my child bundle in AppKernel.php all my parent bundles routes are lost.

For what I understand from the documentation Symfony2 should look all files, including routes, first from the child bundle and then from the parent bundle. Now that is not happening, only child bundles controllers seems to be loaded.

In my child bundles Bundle file I have implemented getParent function as instructed, and in my routing.yml I have:

resource: "@Parent/Controller/"
type:     annotation
prefix:   /admin/

which worked fine before the inheritance.

I have tested that the system works fine if in include all controller files separetely in routing.yml but that seems very cumbersome way to make the inheritance to work as I only want to override few parts of the parent bundle ( not all controllers ).

Profiler is showing both of my bundles as active.



I found the right solution for this issue. Today I was also trying to override a parent bundle configured with annotations routing and also found that parent routes were ignored if the anotation routing imported the whole bundle ("@SomeBundle/Controller").

After a little debugging I found that the explanation for this is that if you use "@" as prefix for the controller this will pass to the kernel resolver which will return ONLY the child resource if the parent resource has been overridden. So the solution is to provide the full path of the bundle, considering that the kernel will try to match the resource from app/Resources so you will have to add a relative directory (../../) before the actual path:

# app/config/routing.yml:
    resource: "../../src/Application/ParentBundle/Controller"
    type: annotation

# ChildBundle implements getParent() method to inherit from ParentBundle
    resource: "@ChildBundle/Controller"
    type: annotation

This will work as expected: all parent routes will be imported and will be overridden by all routes specified in the child bundle.

Thursday, April 1, 2021

The parent entity needs to give visibility of it's properties to it's children.

Change your $id property visibility to "protected".

Saturday, May 29, 2021

Bundle-ClassPath is intended for including dependencies in our bundle, so that our bundle can be deployed standalone.

Let's take an example. Suppose the code in my bundle uses a library, e.g. Google Guava. I have two choices for packaging my bundle:

  1. Simply create my bundle with only my own code inside it. The bundle will now have the Import-Package statements that declare a dependency on Guava, and anybody who wants to deploy my bundle into his application will also have to deploy Guava.

  2. Alternatively I can include a copy of Guava inside my bundle and reference it from my Bundle-ClassPath. Whoever deploys my bundle can deploy just my bundle, and doesn't need to worry about where to get Guava from. In fact, the existence of Guava inside my bundle is an implementation detail, and the deployer doesn't even need to know that I am using it.

The choice between these two options is a trade-off. Option 2 has the advantage that my bundle is easier to deploy because it is standalone -- everything it needs is right there inside it. On the other hand my bundle is much bigger than it needs to be, which could become a problem if lots of other bundles also embed their own copy of Guava.

A more severe problem with option 2 is that all of the dependencies of the library now become my dependencies as well. Actually Guava is a rare example of a Java library with no dependencies of its own... but many other Java libraries drag in a huge tree of transitive dependencies. If you use this approach with, say, Hibernate then your own bundle will also have that large dependency set. This gets very ugly, very quickly.

So, you should be cautious not to overuse Bundle-ClassPath/Embed-Dependency. You should only consider using it if the dependency is (a) small, and with no transitive dependencies, and (b) your bundle uses the library as an internal implementation detail, i.e. it is not part of your public API.


I forgot to answer your second question about the exports. The answer is NO, the exports of any "bundles" you put on your Bundle-ClassPath will NOT become exports of your own bundle. In fact the JARs we put on Bundle-ClassPath are not treated as bundles at all, they are just JARs.

You can choose to export packages that come from within the JARs on your Bundle-ClassPath but you have to do this in the MANIFEST.MF of your own bundle.

Sunday, August 1, 2021
Do Tog

Are you using Symfony2? If you are and can use annotations for your routing instead of yml or xml then it's possible to have multiple routes defined along these lines:

* @Route("/");
* @Route("/home");

Then you don't need to duplicate the action method.

Monday, August 9, 2021
 * @Route("/secured/{anything}", name="_secured", defaults={"anything" = null}, requirements={"anything"=".+"})

public function securedAction($anything){
    //return secured JS frontend 

name - just name of the route.

defaults - here you can set default value of the parameter, if you not provide parameter in the url: /secured/

requirements - requirements for parameter(s), in this case anything can contain forward slash: , but you must handle it in your controller action yourself:

for example if you provide url: /secured/anything/another_thing/one_more_thing

you can get all parameters by explode('/', $anything);

and the results will be:

array:3 [
  0 => "anything"
  1 => "another_thing"
  2 => "one_more_thing" ]

Just everything after /secured/ will be one parameter $anything.

Friday, October 22, 2021
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :