Topic
  • 4 replies
  • Latest Post - ‏2013-09-26T04:52:34Z by jgawor
pgr9
pgr9
5 Posts

Pinned topic Liberty 8.5.5, application component lifecycle operations

‏2013-09-23T14:57:02Z |

We are considering a migration of our server app from the Apache Geronimo container to WLP.  Our application includes several GBeans, which provide persistent state and lifecycle operations.  I am having trouble figuring out what the equivalent Liberty construct is, such that I can map the functionality of these GBeans into Liberty.

How is this sort of requirement addressed in WLP?  (I'd prefer to use a solution that does not require third party components.)

 

  • James Stansell
    James Stansell
    2 Posts

    Re: Liberty 8.5.5, application component lifecycle operations

    ‏2013-09-23T15:06:29Z  

    Hi,

    The first thing that comes to mind is the OSGi lifecycle. Does this post come close to what you are looking for?

    http://devangelist.blogspot.com/2011/04/osgi-bundle-lifecycles.html

    Regards,

    -james.

  • pgr9
    pgr9
    5 Posts

    Re: Liberty 8.5.5, application component lifecycle operations

    ‏2013-09-23T17:28:38Z  

    Hi,

    The first thing that comes to mind is the OSGi lifecycle. Does this post come close to what you are looking for?

    http://devangelist.blogspot.com/2011/04/osgi-bundle-lifecycles.html

    Regards,

    -james.

    Thanks!

    Maybe.  I get that WLP supports OSGi apps, and that OSGi apps have lifecycle operations.  This article seems to be oriented toward OSGi usage in Geronimo 3.  Maybe there would be an analogous means of installing this app into WLP.  Maybe this app would work in WLP unchanged, and I'll investigate that.

    So, I have decomposed my present app into a small set of EARs, which in turn contain WARs and EJBs, with JMS dependency markup.

    In Geronimo, there exists a file [/geronimo/var/config/config.xml], which allows you to declare applications (EAR, WAR) to be loaded at startup.  These applications in turn contain [/META-INF/application.xml] and [/META-INF/geronimo-application.xml], which declare embedded WARs, EJBs, etc. 

    It seems that the WLP equivalent of config.xml is server.xml.  Both allow the specification of apps to run at startup.  And the EARs and WARs are structured similarly in either container.  What is left (for me) is how to account for the geronimo-specific markup contained in [/META-INF/geronimo-application.xml].  It contains some declarative stuff and dependency specification that may not have an analogue in WLP.  What is left are gbean declarations like this:

        <dep:gbean name="Server" class="myapp.geronimo.Server"/>

    This entry maps to a class in my code jar that implements [org.apache.geronimo.gbean.GBeanLifecycle], has some state, and implements

        void doStart() throws java.lang.Exception;   
        void doStop() throws java.lang.Exception;   
        void doFail();
     

    I am (naturally) maintaining existing code, where the original authors aren't around to ask questions.  Conceptually, it seems useful to be able to specify a class such that start() is called when I start my server, and stop() is called when I stop my server.  I'd like to maintain the existing structure of the app as much as possible, as I don't have a deep understanding of how any changes would impact the functionality.

    So, on the surface, this "devangelist" blog entry seems heavy for my situation.  I don't have enough experience to say that an OSGi app couldn't be declared as easily as a gbean.  But I can say that to me, it is more complex conceptually.

     

  • James Stansell
    James Stansell
    2 Posts

    Re: Liberty 8.5.5, application component lifecycle operations

    ‏2013-09-23T23:41:14Z  
    • pgr9
    • ‏2013-09-23T17:28:38Z

    Thanks!

    Maybe.  I get that WLP supports OSGi apps, and that OSGi apps have lifecycle operations.  This article seems to be oriented toward OSGi usage in Geronimo 3.  Maybe there would be an analogous means of installing this app into WLP.  Maybe this app would work in WLP unchanged, and I'll investigate that.

    So, I have decomposed my present app into a small set of EARs, which in turn contain WARs and EJBs, with JMS dependency markup.

    In Geronimo, there exists a file [/geronimo/var/config/config.xml], which allows you to declare applications (EAR, WAR) to be loaded at startup.  These applications in turn contain [/META-INF/application.xml] and [/META-INF/geronimo-application.xml], which declare embedded WARs, EJBs, etc. 

    It seems that the WLP equivalent of config.xml is server.xml.  Both allow the specification of apps to run at startup.  And the EARs and WARs are structured similarly in either container.  What is left (for me) is how to account for the geronimo-specific markup contained in [/META-INF/geronimo-application.xml].  It contains some declarative stuff and dependency specification that may not have an analogue in WLP.  What is left are gbean declarations like this:

        <dep:gbean name="Server" class="myapp.geronimo.Server"/>

    This entry maps to a class in my code jar that implements [org.apache.geronimo.gbean.GBeanLifecycle], has some state, and implements

        void doStart() throws java.lang.Exception;   
        void doStop() throws java.lang.Exception;   
        void doFail();
     

    I am (naturally) maintaining existing code, where the original authors aren't around to ask questions.  Conceptually, it seems useful to be able to specify a class such that start() is called when I start my server, and stop() is called when I stop my server.  I'd like to maintain the existing structure of the app as much as possible, as I don't have a deep understanding of how any changes would impact the functionality.

    So, on the surface, this "devangelist" blog entry seems heavy for my situation.  I don't have enough experience to say that an OSGi app couldn't be declared as easily as a gbean.  But I can say that to me, it is more complex conceptually.

     

    I am familiar with supporting an application where the original authors have left! The requirements and design vanished with them, so making any major changes is a horrid idea.

    I got to wondering if you had tried the application migration tool, but I don't see Geronimo listed, either under the Apache project name or the Websphere CE name. The "competitive" migration only lists Tomcat from Apache.

    http://www.ibm.com/developerworks/websphere/downloads/migtoolkit/vtov.html

     

  • jgawor
    jgawor
    9 Posts

    Re: Liberty 8.5.5, application component lifecycle operations

    ‏2013-09-26T04:52:34Z  
    • pgr9
    • ‏2013-09-23T17:28:38Z

    Thanks!

    Maybe.  I get that WLP supports OSGi apps, and that OSGi apps have lifecycle operations.  This article seems to be oriented toward OSGi usage in Geronimo 3.  Maybe there would be an analogous means of installing this app into WLP.  Maybe this app would work in WLP unchanged, and I'll investigate that.

    So, I have decomposed my present app into a small set of EARs, which in turn contain WARs and EJBs, with JMS dependency markup.

    In Geronimo, there exists a file [/geronimo/var/config/config.xml], which allows you to declare applications (EAR, WAR) to be loaded at startup.  These applications in turn contain [/META-INF/application.xml] and [/META-INF/geronimo-application.xml], which declare embedded WARs, EJBs, etc. 

    It seems that the WLP equivalent of config.xml is server.xml.  Both allow the specification of apps to run at startup.  And the EARs and WARs are structured similarly in either container.  What is left (for me) is how to account for the geronimo-specific markup contained in [/META-INF/geronimo-application.xml].  It contains some declarative stuff and dependency specification that may not have an analogue in WLP.  What is left are gbean declarations like this:

        <dep:gbean name="Server" class="myapp.geronimo.Server"/>

    This entry maps to a class in my code jar that implements [org.apache.geronimo.gbean.GBeanLifecycle], has some state, and implements

        void doStart() throws java.lang.Exception;   
        void doStop() throws java.lang.Exception;   
        void doFail();
     

    I am (naturally) maintaining existing code, where the original authors aren't around to ask questions.  Conceptually, it seems useful to be able to specify a class such that start() is called when I start my server, and stop() is called when I stop my server.  I'd like to maintain the existing structure of the app as much as possible, as I don't have a deep understanding of how any changes would impact the functionality.

    So, on the surface, this "devangelist" blog entry seems heavy for my situation.  I don't have enough experience to say that an OSGi app couldn't be declared as easily as a gbean.  But I can say that to me, it is more complex conceptually.

     

    What sort of GBeans are they?  Are they custom GBeans that you developed? Or are they GBeans provided by the Geronimo environment? The answer could be different depending on the type of GBeans you are using.

    In general if you are using GBeans to perform some actions on application start/stop (e.g. execute some sql) you could potentially replace the logic with simple @PostCreate / @PreDestroy lifecycle methods on some servlet, or ejb, etc. If you are using GBeans to perform some actions on server start/stop then I think writting a Liberty extension might be a good approach.  You can then rely on OSGi lifecycle callbacks and events (as one method) to perform the actions. Plus you get a whole bunch of other benefits when using the extension approach (config injection, interaction with other Liberty services, etc.).