WebSphere Application Server & Liberty

 View Only
Expand all | Collapse all

Liberty Features: Bundle-ActivationPolicy: lazy and Subsystem-Content

  • 1.  Liberty Features: Bundle-ActivationPolicy: lazy and Subsystem-Content

    IBM Champion
    Posted 12 days ago
    Hi everyone!
    When writing a feature, I found out that one of my features may NOT have

    <Bundle-ActivationPolicy>lazy</Bundle-ActivationPolicy>

    ... to work properly, while another feature, which is to start between datasources and the application actually needs this to work properly.
    This is the documentation I used:  Liberty feature manifest files - IBM Documentation

    There does not seem to be much of a documentation about the bundle manifest files, however.

    ---

    The second question is about Subsystem-Content.
    When I write some other features into Subsystem-Content and then uninstall that feature again, the features mentioned in subsystem-content are also uninstalled. This is my SUBSYSTEM.MF file snippet:

    Subsystem-Content: my.company.feature;version="[${parsedVersion.osgiVersion},${parsedVersion.osgiVersion}]";start-order:="1";start-phase=CONTAINER_LATE,
    com.ibm.websphere.appserver.servlet-3.1; ibm.tolerates:="3.0, 4.0"; type="osgi.subsystem.feature",
    com.ibm.websphere.appserver.jsp-2.3; type="osgi.subsystem.feature",
    com.ibm.websphere.appserver.jndi-1.0; type="osgi.subsystem.feature",
    com.ibm.wsspi.appserver.webBundle-1.0; type="osgi.subsystem.feature",
    com.ibm.websphere.appserver.spi.kernel.service;version="[1.3,2.0)"
    Now, when I uninstall that feature, the kernel service gets uninstalled. Along with it: all the binaries belonging to it, e.g. featureManager, productInfo scripts etc.
    What did I do wrong here?

    ------------------------------
    ------------------------------
    Benjamin Marwell
    System Engineer // IBM Champion // Apache Shiro PMC
    Finanz Informatik
    ------------------------------
    ------------------------------


  • 2.  RE: Liberty Features: Bundle-ActivationPolicy: lazy and Subsystem-Content

    Posted 3 days ago
    Edited by THOMAS JOHNSON 3 days ago

    Hey Benjamin,

    These are great questions, thank you! I wouldn't call myself a bnd tools, or OSGi expert, but I've worked with both these pieces in my years of Liberty development so I thought I'd try lending a hand to get to the bottom of this.

    To your first question, the lazy activation of a bundle. In the bnd tools world, using the lazy bundle activation policy means that a bundle isn't started until after the first request to load a class. According to the bnd tools documentation, the request can come from either normal class loading or from a bundle's loadClass method. You can view that documentation here: Bnd Tools Activation Policy Documentation

    Without knowing more about what's in those two features, I'm going to make some assumptions. I'd bet that the behavior your seeing, where one feature needs eager initialization (the default) while another needs lazy initialization, probably has to do with what the features are providing (i.e. it's bundles startup can't be deferred because another feature depends on what it's providing).

    In regards the Subsystem-Content header, lets use the jsp-2.3 feature as an example.  If your feature is starting,  and has marked the jsp-2.3 feature as Subsystem-Content, the framework will check to see if jsp-2.3 is already loaded by another feature or defined by you via server.xml configuration. If not already loaded, then the framework will start jsp-2.3 for your feature. The same is true for when the feature is stopped, meaning if you don't have jsp-2.3 defined in your server.xml and no other feature needs jsp-2.3, then the framework will stop it along with your feature and any other Subsystem-Content features that are no longer needed.

    If you want a feature to keep running even after the feature that uses it has stopped, all you need to do is add it the list of features in the server.xml. If jsp-2.3 was the feature you wanted to remain up after you stop your feature, then it'd look something like this: 

    <server>
       <featureManager>
           <feature>yourFeature-1.0</feature>
           <feature>jsp-2.3</feature>
       <featureManager>
    <server>

    The caveat here is that only features denoted as public can be defined in the server.xml. See the visibility section of the Liberty feature manifest files link you pointed to for more info on that.  Hopefully that helps clarify, if not let me know and I'll get you some real help!

    Thanks again for reaching out!



    ------------------------------
    THOMAS JOHNSON
    ------------------------------