On Jan 18, 2010, at 12:33 AM, Rex Wang wrote:
2010/1/18 Jarek Gawor <[email protected]>
On Thu, Jan 14, 2010 at 9:47 PM, Ivan <[email protected]> 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 <[email protected]>
>>
>> Rex Wang wrote:
>>>
>>>
>>> 2010/1/14 Jarek Gawor <[email protected] <mailto:[email protected]>>
>>>
>>> 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
