geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <rwo...@gmail.com>
Subject Re: Implementing rfc66 in Geronimo
Date Mon, 18 Jan 2010 09:47:14 GMT
2010/1/18 David Jencks <david_jencks@yahoo.com>

>
> On Jan 18, 2010, at 12:33 AM, Rex Wang wrote:
>
>
>
> 2010/1/18 Jarek Gawor <jgawor@gmail.com>
>
>> On Thu, Jan 14, 2010 at 9:47 PM, Ivan <xhhsld@gmail.com> wrote:
>> > I am thinking that while implementing the WAB extender, how does it use
>> > current deployer ? There might be something need to consider :
>> > 1. Current Geronimo deployer is designed for two steps deployment, which
>> > means that it needs to install package to the OSGI environment twice,
>> how to
>> > handler it in the extender ?
>>
>> Right now I think the idea is to modify our deployment process to 1)
>> work directly with a Bundle object and 2) not to create any additional
>> or temporary bundles during deployment and just create a configuration
>> object that the extender can load/start/stop.
>>
>
> That makes me to think about if we can make our Geronimo plugins more
> extender-like. Such as Ivan said, currently we need deploy a car twice in
> order to firstly install all the depending bundles and generate the
> config.ser, then using the config to instantiate gbeans. This is very
> different to the RFC66 WABs.
> Before starting the WAB, extender even does not know the existence of it. A
> WAB is considered as a normal bundle with other bundles. So our extender
> need track the WAB starting and generate config.ser and instantiate gbeans
> all in one step. Hence, what is the standard way to install a war? I see two
> approaches as follows:
> 1. The current way of making the war a geronimo-lize war before start it.
> 2. Convert the war to WAB and deploy the WAB, after start it, extender will
> find it and generate geronimo information. That is what RFC66 spec required.
> I think we should choose the #2.
>
>
> I am not yet convinced that rfc 66 and #2 are good ways to deploy web apps.
>  We want to support them but that doesn't mean they are ideal.  The main
> problem I have with rec66 like methods is that you end up with extra data
> needed to start the geronimo plugin-ized WAB that isn't in the WAB.  So, you
> can't just copy the plugin into another server, you have to go through
> deployment via the rfc66 extender on every server.
>
Sorry, I am not very understand this. Do you indicate the server-farming
scenario, which firstly deploy an app and need to farm to other servers?

-Rex


> This pretty much negates most of the good points about geronimo plugins.
>  We might decide this is the direction we want to go in, but we should talk
> about it in detail.
>
> thanks
> david jencks
>
>
>
> -Rex
>
>
>>
>> > 2. Where and when we store the configuration datas ? Not sure in the
>> spec,
>> > there is any description about the contain's behavior, or it would
>> analysis
>> > the WAB each time while starting it ?
>>
>> We could store that information in the bundle private storage area. If
>> the information is already there and the bundle hasn't been updated we
>> could reuse the information and skip the deployment.
>>
>> > 3 . About the double start, while restarting Geronimo, it should be
>> possible
>> > to use location or artifact, but since WAB could be installed by any
>> other
>> > applications, so location/artifact might not enough.
>>
>> I'm not worried about this now but potentially yes. Maybe this won't
>> even be an issue.
>>
>> Jarek
>>
>> >
>> > 2010/1/14 Rick McGuire <rickmcg@gmail.com>
>> >>
>> >> Rex Wang wrote:
>> >>>
>> >>>
>> >>> 2010/1/14 Jarek Gawor <jgawor@gmail.com <mailto:jgawor@gmail.com>>
>> >>>
>> >>>    Hey all,
>> >>>
>> >>>    I've been looking into implementing rfc66 support in Geronimo a
>> little
>> >>>    bit more. Here are some things that we need to do and my
>> >>>    thoughts/impressions about them:
>> >>>
>> >>>    1. WAR to WAB converter. Installs webbundle: url handler that
>> converts
>> >>>    standard WAR files into Web Application Bundles (WAB). The
>> converter
>> >>>    code was contributed by IBM to Apache Aries but so far it has not
>> been
>> >>>    moved to trunk yet. This code will probably need some updates but
I
>> >>>    think we could just mostly use it as it is in Geronimo.
>> >>>
>> >>>    2. WAB extender. Watches for WABs to be started in the framework
>> and
>> >>>    performs the necessary steps to deploy the applications.
>> >>>     a. In Geronimo we will need a custom extender that effectively
>> >>>    invokes Tomcat/JettyWebModuleBuilders to deploy the application.
>> There
>> >>>    might be an extender implementation donated to Aries at some point
>> but
>> >>>    I don't think we will be able to use since it most likely will use
>> the
>> >>>    Tomcat or Jetty API directly to deploy the application. In Geronimo
>> we
>> >>>    build the GBeans which then use Tomcat/Jetty API to set everything
>> up.
>> >>>     b. The biggest issue that I see with Geronimo WAB extender is
>> >>>    updating the WebModuleBuilders (or actually the whole deployment
>> >>>    process) to work with Bundle objects. Right now the deployment
>> process
>> >>>    for the most part assumes it is working with JarFiles.
>> >>>
>> >>> So, what is the standard method to install/deploy a WAB into Geronimo
>> >>> 3.0? From the osgi perspective, that should be the same with
>> installing a
>> >>> normal bundle to framework, and then the extender will track this and
>> help
>> >>> deploy it to geronimo by instantiating some gbeans. Should we support
>> the
>> >>> geronimo deployment process such as deploy a WAB with a external plan?
>> >>
>> >> One key point with WABs is to remember that a WAB is an OSGi
>> programming
>> >> construct and even though it is running under Geronimo, it should
>> function
>> >> under OSGi rules.  One key point here is any application may install
>> and
>> >> start a WAB bundle using a BundleContext without ever knowing anything
>> about
>> >> the hosting Geronimo server.  That's the key purpose of the
>> extender...it
>> >> processes any bundle that has the manifest entries that identify this
>> as a
>> >> WAB and take the steps necessary to deploy this.  The bundle in
>> question
>> >> might not have gone through the Geronimo deployment process first.
>> >>>
>> >>>     c. Rick has some initial extender code in the sandbox that we
>> should
>> >>>    be able to reuse (or at least parts of it) in Geronimo.
>> >>>     d. Things to keep in mind:
>> >>>       1. The specification talks about support for lazy bundles. More
>> >>>    specifically, that a request on static resource of a lazy activated
>> >>>    bundle should not cause the bundle to become fully activated.  This
>> >>>    might be tricky to implement in Geronimo and would require changes
>> to
>> >>>    existing code. However, support for lazy bundles seems to be
>> optional
>> >>>    in the specification.
>> >>>       2. The specification says that “it should be possible for a
Web
>> >>>    application bundle to remain installed when its Web Container is
>> >>>    dynamically replaced”. Which I think it means what happens if
>> somebody
>> >>>    deploys WAB, then stops Tomcat container and starts Jetty container
>> >>>    all at runtime. Does the application continue to work? Should
>> Geronimo
>> >>>    support this case? It is an optional feature.
>> >>>
>> >>> Does that indicate each WAB will contain several plans for different
>> >>> containers? That might require a way to distinguish the plans.
>> >>>
>> >>>       3. The extender might need to track somehow which WABs were
>> >>>    already deployed to prevent double start problems. Once some WAB
is
>> >>>    deployed and the Geronimo server is restarted, Geronimo will
>> attempt
>> >>>    to start the generated configuration/plugin for the WAB. Starting
>> of
>> >>>    the plugin will also start the actual WAB and then the extender
>> will
>> >>>    see the starting bundle and attempt to deploy the WAB again.
>> >>>
>> >>> Yes, I think the other RFC66 implementation also need to take care of
>> it.
>> >>>
>> >>> Thanks
>> >>> -Rex
>> >>>
>> >>>
>> >>>    3. Annotation and resource discovery.
>> >>>     a. The specification does not describe an exact way of discovering
>> >>>    annotations or resources in a WAB. For example, if WAB imports some
>> >>>    package from another bundle, are all classes in that package
>> scanned
>> >>>    for annotations? What about resources in META-INF directory? Are
>> the
>> >>>    bundles wired to the WAB checked for META-INF resources?  These are
>> >>>    some unanswered questions that we need to keep track of.
>> >>>     b. In certain cases (e.g. servlets 3.0, EJBs, etc.) we will need
>> to
>> >>>    discover all accessible classes in bundle class space that have a
>> >>>    given annotation. For that we will need annotation discovery code
>> that
>> >>>    might need to know how to scan bundles based on Bundle-Classpath
>> and
>> >>>    possibly on Import-Packages, DynamicImport-Package, Require-Bundle,
>> >>>    etc. depending on what the specification will say. The annotation
>> >>>    scanning code might get even more difficult if it needs to support
>> >>>    lazy bundles.
>> >>>     c. Tag library scanning might require similar code as used in
>> >>>    annotation discovery since the tld files can be included in any
>> >>>    directory in a JAR under the META-INF directory. This also depends
>> on
>> >>>    what the final specification will say.
>> >>>
>> >>>    4. JSP Runtime Compilation. Not sure yet what that will require
>> >>>    (if anything).
>> >>>
>> >>>    5. JNDI (RFC 142) integration. Get services from service registry
>> >>>    using JNDI lookup using osgi:service/<interface> name (and
>> therefore
>> >>>    OSGi services could be injected via standard @Resource annotation).
>> >>>    Support for RFC 142 is recommended but not required by RFC 66. This
>> is
>> >>>    an optional item but useful to have. There is RFC 142
>> implementation
>> >>>    in Apache Aries that seems pretty complete so it just needs to be
>> >>>    integrated in Geronimo.
>> >>>
>> >>>    I think updating the WebModuleBuilders (2.b) will take the most
>> time
>> >>>    and effort. The annotation and resource discovery (3.b and 3.c)
>> >>>    shouldn't be a lot of work but it's still not very well defined in
>> the
>> >>>    specification and that is something we need to keep track of. The
>> good
>> >>>    news is that we can work on all (except maybe the JSP compilation)
>> of
>> >>>    these items at the same time without stepping on each other's feet.
>> >>>    Also, if the specification decides to require support for lazy
>> bundles
>> >>>    that will cause some fairly major changes in Geronimo. For now, I
>> >>>    think we should assume that lazy bundles are optional and assume
>> >>>    fairly simple rules for annotation and resource discovery code
>> (i.e.
>> >>>    scan jars files or directories specified on the Bundle-ClassPath
>> >>>    only).
>> >>>
>> >>>    Comments?
>> >>>
>> >>>    Jarek
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Lei Wang (Rex)
>> >>> rwonly AT apache.org <http://apache.org>
>> >>
>> >
>> >
>> >
>> > --
>> > Ivan
>> >
>>
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>
>
>


-- 
Lei Wang (Rex)
rwonly AT apache.org

Mime
View raw message