We discussed this in our asarch meeting today.
No one wanted to risk increases to the asadmin startup time by using
OSGi. We're already trying to squeeze out fractions of a second from
the startup time.
Jerome pointed out that #4 isn't going to work because the command
implementations in the extension class loader won't have access to
the other asadmin classes in the application class loader. Thus,
we decided that we needed to pursue option #2.
Jerome thinks there may be some HK2 classes to help with constructing
the URLClassLoader we'll need to implement #2.
This approach will allow asadmin extension jar files to be installed
into lib/asadmin and discovered by HK2 in asadmin.
Let me know if anyone sees any issues with this.
Bill Shannon wrote on 09/17/09 14:10:
> I changed asadmin recently to use HK2 to allow the set of local commands
> to be extensible. That solved only part of the problem. Since asadmin
> doesn't use OSGi, there's no convenient, automatic way to install a new
> jar file that includes support for a new local command and have it be
> seen by asadmin. Essentially there needs to be a way to add a new jar
> file to asadmin's CLASSPATH.
>
> Here's the ways I've thought of to solve this problem:
>
> 1. Use OSGi. I think this is excessive but I list it for completeness.
>
> 2. Have the asadmin code explicitly create a ClassLoader to load classes
> from some specific directory where asadmin extension commands can be
> dropped.
>
> 3. Have the asadmin shell script add all jar files in a specific directory
> to the CLASSPATH before running the java command.
>
> 4. Have the asadmin shell script invoke the java command with the System
> property java.ext.dirs pointing to a specific directory where command
> extensions can be dropped.
>
> Preferences? Other alternatives?
>
> I'm assuming HK2 will work fine with any of the above.
>
> Right now I prefer #4, with a directory something like "lib/asadmin".