Implementing rfc66 in Geronimo

[Jarek Gawor <jg...@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.
  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.
    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.

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

Re: Implementing rfc66 in Geronimo

[Ivan <xh...@gmail.com>]

2010/1/18 David Jencks <da...@yahoo.com>

>
> On Jan 17, 2010, at 9:01 PM, Ivan wrote:
>
>
>
> 2010/1/18 Jarek Gawor <jg...@gmail.com>
>
>> On Thu, Jan 14, 2010 at 9:47 PM, Ivan <xh...@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.
>>
>>     For WAB, it might be OK, but for common Java EE applications, it is
> difficult.
>     Since only one time installation, the extender would need handle
> something itself, such as loading dependency artifacts.
>
>
> I know of 3 approaches to loading dependency artifacts:
> 1. our geronimo-plugin.xml dependency list which explicitly specifies
> maven-url dependencies for some bundles (our plugins).  This is normally
> derived from maven dependency info while building the plugin
> 2. karaf feature.xml dependencies.  I haven't looked at this very hard but
> think it's pretty much equivalent to (1).
> 3. aries application bundle + OBR.  I don't understand any details about
> this but think that it basically involves the bundles specifying
> import-packages and using the OBR to resolve these into dependency bundles
> which are then installed.  The part that seems missing to me in this
> approach is how to populate the OBR.
>
> I am hoping that we can come up with a unified solution that basically
> involves using the maven-like dependency information such as in our
> geronimo-plugin.xml or karaf feature.xml aggregated together to populate one
> or possibly more than one OBR.  I think Jarek suggested this idea.
>
>
>
>
>> > 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.
>
>
>    The reason that I asked this is based on the one time installation, as
> those configurations ( config.ser/geronimo-plugin.xml) are not ready. So the
> WAB starting codes might be different between the deployment phase and
> restart phase.
>
>
> I'm not sure I understand... are you saying that we would only generate the
> config.ser file if it was not present, otherwise we would skip this
> deployment step?
>

   No, I did not mean this. While deploying the WAB to Geronimo, the
extender is triggered by the installation event, which means that the bundle
is in the process of installing to the OSGI container. So at this time slot,
writing config.ser/geronimo-plugin.xml to the bundle package did not affect
the installed bundle itself, in other words, the bundle should be in the
"read-only" status (Am I making any mistake here ?). Then, our existing
start logic would not find the new added configuration files.


>
thanks!
> david jencks
>
>
>>
>
>> > 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 <ri...@gmail.com>
>> >>
>> >> Rex Wang wrote:
>> >>>
>> >>>
>> >>> 2010/1/14 Jarek Gawor <jgawor@gmail.com <ma...@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
>> >
>>
>
>
>
> --
> Ivan
>
>
>


-- 
Ivan

Re: Implementing rfc66 in Geronimo

[David Jencks <da...@yahoo.com>]

On Jan 17, 2010, at 9:01 PM, Ivan wrote:

>
>
> 2010/1/18 Jarek Gawor <jg...@gmail.com>
> On Thu, Jan 14, 2010 at 9:47 PM, Ivan <xh...@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.
>
>     For WAB, it might be OK, but for common Java EE applications, it  
> is difficult.
>     Since only one time installation, the extender would need handle  
> something itself, such as loading dependency artifacts.

I know of 3 approaches to loading dependency artifacts:
1. our geronimo-plugin.xml dependency list which explicitly specifies  
maven-url dependencies for some bundles (our plugins).  This is  
normally derived from maven dependency info while building the plugin
2. karaf feature.xml dependencies.  I haven't looked at this very hard  
but think it's pretty much equivalent to (1).
3. aries application bundle + OBR.  I don't understand any details  
about this but think that it basically involves the bundles specifying  
import-packages and using the OBR to resolve these into dependency  
bundles which are then installed.  The part that seems missing to me  
in this approach is how to populate the OBR.

I am hoping that we can come up with a unified solution that basically  
involves using the maven-like dependency information such as in our  
geronimo-plugin.xml or karaf feature.xml aggregated together to  
populate one or possibly more than one OBR.  I think Jarek suggested  
this idea.


>
> > 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.
>
>    The reason that I asked this is based on the one time  
> installation, as those configurations ( config.ser/geronimo- 
> plugin.xml) are not ready. So the WAB starting codes might be  
> different between the deployment phase and restart phase.

I'm not sure I understand... are you saying that we would only  
generate the config.ser file if it was not present, otherwise we would  
skip this deployment step?

thanks!
david jencks

>
>
> > 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 <ri...@gmail.com>
> >>
> >> Rex Wang wrote:
> >>>
> >>>
> >>> 2010/1/14 Jarek Gawor <jgawor@gmail.com <ma...@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
> >
>
>
>
> -- 
> Ivan

Re: Implementing rfc66 in Geronimo

[Ivan <xh...@gmail.com>]

2010/1/18 Jarek Gawor <jg...@gmail.com>

> On Thu, Jan 14, 2010 at 9:47 PM, Ivan <xh...@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.
>
>     For WAB, it might be OK, but for common Java EE applications, it is
difficult.
    Since only one time installation, the extender would need handle
something itself, such as loading dependency artifacts.


> > 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.


   The reason that I asked this is based on the one time installation, as
those configurations ( config.ser/geronimo-plugin.xml) are not ready. So the
WAB starting codes might be different between the deployment phase and
restart phase.

>
>

> > 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 <ri...@gmail.com>
> >>
> >> Rex Wang wrote:
> >>>
> >>>
> >>> 2010/1/14 Jarek Gawor <jgawor@gmail.com <ma...@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
> >
>



-- 
Ivan

Re: Implementing rfc66 in Geronimo

[Rex Wang <rw...@gmail.com>]

2010/1/18 David Jencks <da...@yahoo.com>

>
> On Jan 18, 2010, at 12:33 AM, Rex Wang wrote:
>
>
>
> 2010/1/18 Jarek Gawor <jg...@gmail.com>
>
>> On Thu, Jan 14, 2010 at 9:47 PM, Ivan <xh...@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 <ri...@gmail.com>
>> >>
>> >> Rex Wang wrote:
>> >>>
>> >>>
>> >>> 2010/1/14 Jarek Gawor <jgawor@gmail.com <ma...@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

Re: Implementing rfc66 in Geronimo

[David Jencks <da...@yahoo.com>]

On Jan 18, 2010, at 12:33 AM, Rex Wang wrote:

>
>
> 2010/1/18 Jarek Gawor <jg...@gmail.com>
> On Thu, Jan 14, 2010 at 9:47 PM, Ivan <xh...@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.  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 <ri...@gmail.com>
> >>
> >> Rex Wang wrote:
> >>>
> >>>
> >>> 2010/1/14 Jarek Gawor <jgawor@gmail.com <ma...@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

Re: Implementing rfc66 in Geronimo

[Rex Wang <rw...@gmail.com>]

2010/1/18 Jarek Gawor <jg...@gmail.com>

> On Thu, Jan 14, 2010 at 9:47 PM, Ivan <xh...@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.

-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 <ri...@gmail.com>
> >>
> >> Rex Wang wrote:
> >>>
> >>>
> >>> 2010/1/14 Jarek Gawor <jgawor@gmail.com <ma...@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

Re: Implementing rfc66 in Geronimo

[Jarek Gawor <jg...@gmail.com>]

On Thu, Jan 14, 2010 at 9:47 PM, Ivan <xh...@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.

> 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 <ri...@gmail.com>
>>
>> Rex Wang wrote:
>>>
>>>
>>> 2010/1/14 Jarek Gawor <jgawor@gmail.com <ma...@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
>

Re: Implementing rfc66 in Geronimo

[Ivan <xh...@gmail.com>]

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 ?
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 ?
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.

2010/1/14 Rick McGuire <ri...@gmail.com>

> Rex Wang wrote:
>
>>
>>
>> 2010/1/14 Jarek Gawor <jgawor@gmail.com <ma...@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

Re: Implementing rfc66 in Geronimo

[Rick McGuire <ri...@gmail.com>]

Rex Wang wrote:
>
>
> 2010/1/14 Jarek Gawor <jgawor@gmail.com <ma...@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>

Re: Implementing rfc66 in Geronimo

[Rex Wang <rw...@gmail.com>]

2010/1/14 Jarek Gawor <jg...@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?

 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