geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject [Fwd: Re: NPE exporting a plugin ... null returned from getPluginMetadata()]
Date Fri, 22 Feb 2008 04:27:41 GMT
forwarding messages to dev list for further discussion.

-------- Original Message --------
Subject: Re: NPE exporting a plugin ... null returned from 
Date: Thu, 21 Feb 2008 14:42:36 -0800 (PST)
From: David Jencks <>
To: Joe Bohn <>

This should be on the dev list :-)  Feel free to forward my contributions.

As I understand the issue we want all applications/modules to have some 
kind of geronimo-plugin.xml.  Lets look at where that could happen

-- deployers could construct them.  Right now I don't see quite how to 
do this in one place, but it might let us put more of the info into the 
plan or an auxilary plan.  I've wondered about combining the plan and 
geronimo-plugin.xml file.

-- config stores could insert them when you install a module.  I think 
this might be the best plan for now if all the info is available for 
constructing a default geronimo-plugin.xml

-- config stores or the GeronimoSourceRepository could provide a default 
if there's nothing there when you ask.  I'm not too thrilled with this, 
it makes me feel like the config store is lying.  The SourceRepository 
might be ok.

-- plugin installer could construct it if missing.  I think this is my 
second choice at the moment.

One thing I haven't figured out is if the console lets you just edit the 
plugin info or only includes the edited info in the export.  Do you know?

david jencks

----- Original Message ----
From: Joe Bohn <>
To: David Jencks <>
Sent: Thursday, February 21, 2008 1:40:19 PM
Subject: NPE exporting a plugin ... null returned from getPluginMetadata()

I'm looking into a problem where we get a NPE when attempting to export 
a configuration as a plugin (I'm driving it from the console Plugin 
portlet .. GERONIMO-3866 & GERONIMO-3867 - they are actually the same 
root problem).

This code in ExportConfigHandler.renderView() is the source of the problem:
     PluginType data = 
     PluginArtifactType instance = data.getPluginArtifact().get(0);

The last line is getting the NPE because the 
pluginInstaller.getPluginMetadata for the artifact is returning null. 
I've verified that the artifact itself appears valid after being created.

Digging a bit deeper I discovered that in 
GeronimoSourceRepository.extractPluginMetadata(File dir) we have the 
following check:

    if (!xml.isFile() || !xml.canRead() || xml.length() == 0) {
       return null;

So this is why we get null for the metadata and why we fail the export 
of a plugin.  It appears that the process of extractingPluginMetadata 
assumes it is working with a deployed plugin and judging from the code 
in the portlet I would assume this has not always been the case.

I found slightly different code in place back when the original function 
logic was included in PluginInstallerGBean.  When it was moved to 
GeronimoSourceRespository (in rev. 604483) the additional check for 
configId was lost.  The original code was this:

    if (!xml.isFile() || !xml.canRead() || xml.length() == 0) {
       if (moduleId != null) {
           return createDefaultMetadata(moduleId);
       } else {
           return null;

I think this additional check would allow the export plugin to function 
properly by creating some default metadata (I'm trying it out now).

Would it be a problem if I introduced that capability into the 
GeornimoSourceRepository.extractPluginMetadata(File dir)?   Of course I 
would have to pass along the configId to make it work.  I'm trying it 
out now but didn't want to do something that would cause you grief.


View raw message