[osmosis-dev] API 0.6 and unique keys

[Brett Henderson]

marcus.wolschon at googlemail.com wrote:
> On Tue, 3 Feb 2009 10:48:26 +1100, Brett Henderson <brett at bretth.com>
> wrote:
>   
>> On Tue, Feb 3, 2009 at 1:38 AM, <marcus.wolschon at googlemail.com> wrote:
>>
>>     
>>> On Mon, 2 Feb 2009 15:21:53 +0100, Jochen Topf <jochen at remote.org>
>>>       
> wrote:
>   
>>>> I am not sure any more that this JPF magic is the right way to go. At
>>>> least not in this current form. We would at least need some kind of
>>>> versioning mechanism so that I can get a proper message: "Found plugin
>>>> xyz which conflicts bla bla" instead of just giving a null pointer
>>>> exception. I rarely use Osmosis from the command line, normally I have
>>>> scripts calling it, so I don't mind having some extra command line
>>>> options.
>>>>         
>>> Actually your NullPointerException is still an mystery.
>>> It should never happen even if there where broken plugins and things.
>>> There is a version-mechanism that can be used to specify that
>>> a plugin requires a specific version of osmosis.
>>>       
>> We'll need to make this more robust.  It would be good enough to isolate
>> the
>> problem to a single plugin so the user knows where the problem lies.
>> Hopefully this isn't impossible with JPF.
>>     
>
> That's the problem.
> What what I have reat and seen in the stack-trace:
> a) no plugin was present. It was giving an empty array of plugin-locations
> to the registerPlugins()-method.
>    My on-line-patch should avoid calling the jpf-code at all in this case
> to
>    avoid the issue altogether.
> b) the NullPointerException is inside jpf.jar and lookin at the source-code
> in that line
>    there can be no NullPointerException without already having encountered
> one.
> c) Up to now it can only be reproduced on Jochen's 64bit-machine and the
> same
>    code works fine everywhere else.
> So, how can we debug something we cannot reproduce?
>   
I hope I didn't come across critical, it wasn't my intent.  This one is 
almost impossible to diagnose without being able to reproduce it so 
you've done all you can.  In fact I wasn't suggesting there was a bug in 
the JPF support either, just that the current error (or lack thereof) 
makes it hard to diagnose.

What I'm wondering is whether it is possible to register each plugin 
individually and log a fine/finer message stating the plugin file name 
before we do it.  It would mean that if an error does occur we can at 
least identify exactly which plugin caused the failure.  Currently the 
code contains this statement in the registerJpfPlugins method which is 
the one that failed:
pluginManager.publishPlugins(locations.toArray(new 
PluginLocation[locations.size()]));

That statement is publishing all located plugins in a single call to JPF 
which means that in cases like these it can be difficult to pinpoint the 
problem.

Is it possible to publish each plugin individually?  Perhaps that makes 
no sense ... I really need to get familiar with JPF :-)

Brett