geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: [Fwd: Re: NPE exporting a plugin ... null returned from getPluginMetadata()]
Date Wed, 27 Feb 2008 22:46:08 GMT
comments in-line

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 <david_jencks@yahoo.com>
> To: Joe Bohn <joe.bohn@earthlink.net>
> 
> 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.

I wasn't able to get this working from within the 
GeronimoSourceRepository since I didn't have the necessary objects 
available at all times.  For example, loading configurations worked at 
runtime when exporting a plugin but the same logic was driven during the 
build and that results in different NPEs during the build that I 
referenced in another post on this thread.

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

I implemented a version of this in trunk (rev. 631760) and branches/2.1 
(rev. 631762).

I'm still not sure this is exporting the plugin appropriately.  If I'm 
attempting to export a simple war file it prompts me to save a file 
which is also a war as a result of the export when I was expecting a CAR 
file.  I have to play around with this some more to better understand 
how it is supposed to work.

> 
> 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?
> 
> thanks
> david jencks
> 
> ----- Original Message ----
> From: Joe Bohn <joe.bohn@earthlink.net>
> To: David Jencks <david_jencks@yahoo.com>
> 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
> 
> 


Mime
View raw message