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 <[EMAIL PROTECTED]>
To: Joe Bohn <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
To: David Jencks <[EMAIL PROTECTED]>
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
