geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: [Fwd: Re: NPE exporting a plugin ... null returned from getPluginMetadata()]
Date Fri, 22 Feb 2008 20:17:53 GMT

Hold off on the patch for now.  I was cleaning things up a bit right 
before I created the patch and now when I try to build assemblies it is 
spewing NPEs like they are going out of style.  Let me figure out what 
is going on.


Joe Bohn wrote:
> Joe Bohn wrote:
>> Joe Bohn wrote:
>>> forwarding messages to dev list for further discussion.
>>> -------- Original Message --------
>>> Subject: Re: NPE exporting a plugin ... null returned from 
>>> getPluginMetadata()
>>> 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.
>> I agree this would perhaps be the best.  Combining the plan and 
>> geronimo-plugin.xml is an interesting idea.  I think that makes a lot 
>> of sense if we can provide or construct reasonable defaults so that 
>> the geronimo-plugin info need only be specified if the user really has 
>> intentions of exporting a plugin.  Would this then result in the 
>> configuration being considered as if it was an installed plugin and 
>> available for other functions such as inclusion when exporting a server?
>>> -- 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.
>> I think this would be ok in the short term.  It seems that this is the 
>> function that was in place earlier.  The nice thing about it is that 
>> it is only created when necessary (and then only for transient 
>> purposes since it isn't persisted).  AFAIK this is only used when 
>> exporting plugins at the moment.
> David,  I added a patch onto 
> that puts the 
> generation of the geronimo-plugin.xml into GeronimoSourceRepository. 
> It's not perfect and there are still other issues with export but I 
> think this gets us past the referenced problem for now.  Could you 
> please take a look?  This is patch for trunk but it is more important to 
> get a fix back into the 2.1 branch.
> Thanks, Joe
>>> -- 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?
>> Some of the information can be edited but not all.  For example, the 
>> Unique ID cannot be edited but some other fields (such as the human 
>> readable name) can be.
>>> thanks
>>> 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 = 
>>> ManagementHelper.getManagementHelper(request).getPluginInstaller().getPluginMetadata(

>>>                 Artifact.create(configId));
>>>     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.
>>> Thanks,
>>> Joe

View raw message