Don,
I have been doing more experimenting with this today, trying to determine
whether one of my components is the problem. At this point, I believe that
they are not. I reverted to a default openmap.properties file, and added a
single button component to it. The only function this button has is to
call PropertyHandler.createOpenMapProperties(..). When I try to load
OpenMap with the new file that is generated, the entire tool panel is
missing. Like before, opening the file in a text editor shows the file in
hex mode.
Although I haven't been able to drill too deeply, the issue resides
somewhere in the depths of printComponentProperties call. If I comment
this call out, the file opens as expected. Of course, I don't have the
component properties in the file, so this doesn't resolve the issue.
Thanks again,
Greg Jewell
On Mon, Jul 9, 2012 at 9:59 AM, Greg Jewell <greg17_at_jewell.net> wrote:
> Don,
>
> I'm sorry for the delayed response, but I was out of the office on Friday.
>
> I discovered that the reason that the prefix was null for the projection
> loaders was due to a mistake on my part. I modified the
> "openmap.components" line in the properties file, and the "projFactory"
> component was accidentally removed. Putting that back in prevented the
> NPEs from occurring.
>
> However, I am encountering another issue now. Although the properties
> file is apparently successfully created, reloading the map with the new
> properties file causes all of the buttons along the top to disappear (pan,
> zoom, etc.) As I mentioned above, I did modify the openmap.components
> line, but my new components don't have any state, and just return an empty
> properties object on the getProperties() call.
>
> I noticed that if I open the custom properties file with a text editor, it
> is opened in hex mode. Additionally, a lot of the properties have keys,
> but no values -- they'll look like "key=" or "key= " Could the blank values
> be causing these issues? What is the difference between
> "openmap.components" and "main.components"? I see a lot of overlap in the
> values of these properties, but they aren't identical.
>
>
> Thanks again,
> Greg
>
>
>
> On Fri, Jul 6, 2012 at 1:03 PM, Don Dietrick <dfdietrick_at_gmail.com> wrote:
>
>> Hi Greg,
>>
>> On Jul 5, 2012, at 3:50 PM, Greg Jewell wrote:
>>
>> > Hello,
>> >
>> > I have encountered another issues with porting an application to use
>> OpenMap 5. A button on the application UI causes
>> PropertyHandler.createOpenMapProperties(..) to be called. From here, the
>> ProjectionFactory.getProperties(..) method is called is eventually called.
>> The ProjectionFactory tries to iterate over all of its projection loader
>> classes, and to obtain the property prefix for each of them. However, the
>> prefix is always null, and is causing a NullPointerException to be thrown
>> at line 168.
>>
>> Why is the prefix null? I don't see how the read from properties will
>> work if the prefix for each ProjectionLoader is null.
>>
>> The null pointer exception is a bug, and I think if the prefix is null
>> the code should probably try to generate a unique prefix to use in the
>> properties.
>>
>>
>> >
>> > In OpenMap 4.6.5, the ProjectionFactory class simply returns the
>> Properties object passed into the method, or an empty Properties if the
>> original was null. I created a class that derived from ProjectionFactory
>> with this older implementation of getProperties(..) and placed this new
>> class in the openmap.properties file, but the original class still loaded.
>> >
>> > How can I get my custom ProjectionFactory class to load? Is this the
>> best solution?
>>
>> The ProjectionFactory moved in OM5 from being a singleton class to being
>> a SoloMapComponent, which means only one can be in a MapHandler at a time -
>> so different MapBeans can have different projections available to them.
>>
>> The OM5 ProjectionFactory will still generate a new Properties object if
>> a null one is passed in, that's handled in the OMComponent superclass.
>>
>> I think the problem could be better handled if the ProjectionLoaders had
>> property prefixes on them - if they are being created via a properties
>> file, they should have them. If they are being created that way and don't
>> have prefixes, that's a bug I haven't seen.
>>
>> - Don
>
>
>
--
[To unsubscribe to this list send an email to "majdart_at_bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Mon Jul 09 2012 - 16:27:10 EDT