dev@glassfish.java.net

Re: WebSniffer and OSGi

From: Sahoo <Sahoo_at_Sun.COM>
Date: Fri, 25 Apr 2008 10:47:47 +0530

Jerome Dochez wrote:
>
> On Apr 24, 2008, at 8:27 PM, Sahoo wrote:
>
>> Roberto Chinnici wrote:
>>> While implementing the Phobos container for V3, I saw this comment
>>> in the code for the WebSniffer (in the
>>> org.glassfish.web:gf-web-connector module):
>>>
>>> // Commented out by Sahoo, as in OSGi environment, we can't support
>>> // Module.addImport. So, temporarily we add webtier to the dependency
>>> // list of gf-web-sniffer.
>>> // public Module[] setup(String containerHome, Logger logger)
>>> throws IOException {
>>> // Module[] modules = new Module[1];
>>> // modules[0] =
>>> modulesRegistry.makeModuleFor("org.glassfish.web:webtier", null);
>>> // if (modules[0]==null) {
>>> // throw new IOException("Webtier module not found, web
>>> container is not installed or found");
>>> // }
>>> // return modules;
>>> // }
>>>
>>> This means that the sniffer module depends on the main web tier
>>> module, which defeats the purpose of sniffers. Also, this is an
>>> obstacle to providing a small distribution, because inclusion of the
>>> sniffer will trigger inclusion of the whole web container.
>>>
>>> I understand that this is a temporary measure, but going forward
>>> what's going to be the mechanism to enable sniffers to dynamically
>>> load the container they sniff for? Will the HK2 module registry APIs
>>> call into the OSGi layer to install and start the dependent bundle?
>>> Or is there going to be a new API?
>>>
>> The issue is not about downloading bundles or installing them. The
>> real problem is addImport() tries to *add* a new dependency for a
>> bundle after it is installed (e.g. in the above case, it was adding a
>> dependency on gf-web-container after gf-web-connector was installed),
>> which is not allowed in OSGi. I am still not convinced as to why we
>> need that.
>
> The code commented had nothing to do with adding a dependency after a
> module is installed.
>
> The code above is just about giving the main module id to the V3 so it
> can be used to set the context class loader when doing request
> dispatching.
>
Well, it was earlier resulting in a call to addImport. When I had put
that comment in WebSniffer, the code in ApplicationLifecycle was calling
module.addImport() as shown below:
        // I do the container setup first so the code has a chance to set up
        // repositories which would allow access to the connector module.
        try {

            modules = sniffer.setup(containerHome, logger);
            if (modules!=null) {
                for (Module module : modules) {
                    snifferModule.addImport(module);
                }
            }

I looked at the recent code, and we don't call addImport() any more. I
am sure it was changed when you & I discussed about removal of calls to
addImport(). So, the comment is no more valid. I will file a bug to
change the comment and fix it after tp2.

Thanks,
Sahoo