Re: funky classpath issues? -- solved

Thanks for the update, Jeff. Good explanation. I'll update the OpenMap
FAQ to have an entry on this topic.

- Don

On Tuesday, August 14, 2001, at 03:17 PM, Jeff Mathis wrote:

> I found the issue.
>
> All has to do with ClassLoader heirarchy.
>
> LayerHandler, LocationLayer and PropertyHandler all perform dynamic
> loading of classes
> using Class.forName(someClassString). If a class is placed in the
> jre/lib/ext directory, and it performs
> dynamic loading, it can only look for classes in that ext directory. The
> users CLASSPATH variable is ignored.
> This is a security issue, and in retrospect, I agree with the behavior.
>
> The fix is to copy/extend ComponentFactory, LayerHandler, LocationLayer
> and PropertyHandler
> so that all calls to Class.forName occur within my classes, and not
> OpenMap's classes. Then modify the
> properties file to point to the new classes. Now, I can
> put openmap.jar in the ext directory, have my classpath point to my
> classes, and all works fine.
>
> I don't know if anyone would put openmap.jar in their ext directory in
> the first place. We have a somewhat unconventional user here, but I'd
> call this a feature of OpenMap to make known. Don't put openmap.jar in
> the ext directory unless your code can go there too.
>
> Donald Dietrick wrote:
>>
>> Hi Jeff,
>>
>> On Monday, August 13, 2001, at 07:06 PM, Jeff Mathis wrote:
>>
>>> Don -
>>>
>>> thanks for your response.
>>>
>>> In reading suns documentation, it may be a security policy issue.
>>> Nothing to do with OpenMap at all
>>>
>>> So, to be explicit, I place openmap.jar inside JAVA_HOME/jre/lib/ext.
>>> my class files reside elsewhere, say in /home/myfiles. The
>>> /home/myfiles
>>> directory has a com/mycompany/main.java class. main.java fires up my
>>> version of OpenMap, using some of my classes in the com/mycompany
>>> directory and its subdirectories. I am using the MapHandler and the
>>> properties file.
>>>
>>> I then issue the commands:
>>>
>>> CLASSPATH="/home/myfiles";export CLASSPATH
>>> $JAVA_HOME/bin/java -cp $CLASSPATH com.mycompany.main -p
>>> file:/home/myfiles/myprops.properties
>>>
>>> I use the ArgParser, and it verifies that it can successfully find the
>>> properties file, and LayerUtils.getResourceOrFileOrURL returns a valid
>>> URL which I feed to the PropertyHandler.
>>>
>>> In this scenario, OpenMap classes are created, but classes in my
>>> CLASSPATH cannot be found (a ClassNotFoundException is thrown), and
>>> the
>>> application does not initialize (even though com.mycompany.main CAN be
>>> found!)
>>
>> That's something I would not have expected.
>>
>>> Now, I remove openmap.jar from $JAVA_HOME/jre/lib/ext. I issue the
>>> following:
>>>
>>> CLASSPATH="/home/myfiles:/home/openmap/openmap.jar";export CLASSPATH
>>> $JAVA_HOME/bin/java -cp $CLASSPATH com.mycompany.main -p
>>> file:/home/myfiles/myprops.properties
>>>
>>> All works as expected.
>>>
>>>
>>> This behavior is new to me since I've never put stuff in
>>> $JAVA_HOME/jre/lib/ext. However, one of our users does.
>>
>> I've never messed around with that directory, either. It just feels
>> like asking for trouble, but then again, I don't know what the intent
>> of
>> the directory is. It also seems like it shouldn't be messing up your
>> classpath settings.
>>
>>> So, the question is: is something in OpenMap resetting the classpath
>>> at
>>> runtime to ignore the command line flag (yea right!), or, do we need
>>> to
>>> define a security policy if we insist on putting things in both
>>> jre/lib/ext and our own directories?
>>
>> OpenMap doesn't do anything with classpath settings. :) I don't know
>> if a security policy would help, either. It would be nice if you were
>> getting something more explicit for error messages to let you know
>> what's really going on with the classpath. Maybe you can play around
>> with the ClassLoader a bit to see what it thinks is going on.
>>
>> Good Luck,
>>
>> Don
>>
>>> (actually, I'd vote to not put anything in $JAVA_HOME/jre/lib/ext, but
>>> you know how pesky users can be!)
>>>
>>> Jeff
>>>
>>>
>>>
>>> Donald Dietrick wrote:
>>>>
>>>> Hi Jeff,
>>>>
>>>> I may be reading this wrong, but it looks like the jre is acting the
>>>> way
>>>> I would expect it to. I would assume that anything in the
>>>> JAVA_HOME/jre/lib/ext would be prepended to the CLASSPATH, and any
>>>> classes found in those directories/jar files would be used before
>>>> anything else in the CLASSPATH.
>>>>
>>>> - Don
>>>>
>>>> On Monday, August 13, 2001, at 04:35 PM, Jeff Mathis wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> We've noticed something very interesting.
>>>>>
>>>>> If we put the openmap.jar file into a directory other than
>>>>> JAVA_HOME/jre/lib/ext, the openmap package seems to pay attention to
>>>>> the
>>>>> CLASSPATH environment variable specified on the jvm command line.
>>>>>
>>>>> However, if openmap.jar gets put into JAVA_HOME/jre/lib/ext, it
>>>>> ignores
>>>>> any classpath specified in the users environment or on the jvm
>>>>> command
>>>>> line, and therefore any classes I have written cannot be found by
>>>>> the
>>>>> MapHandler. Compilation happens under either scenario.
>>>>>
>>>>> Have you seen this before?
>>>>>
>>>>> thanks
>>>>>
>>>>> jeff
>>>>>
>>>>> --
>>>>> Jeffrey Mathis, PhD FAX: 505-988-2229
>>>>> Senior Scientist email: jeff.mathis@biosgroup.com
>>>>> Bios Group, Inc. phone 505-992-6737
>>>>> 317 Paseo de Peralta http://www.biosgroup.com
>>>>> Santa Fe, NM 87501
>>>>>
>>>>> --
>>>>> [To unsubscribe to this list send an email to "majdart@bbn.com"
>>>>> with the following text in the BODY of the message "unsubscribe
>>>>> openmap-users"]
>>>>>
>>>>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Donald F. Dietrick, dietrick@bbn.com
BBN Technologies, 10 Moulton Street, Cambridge, MA 02138
617.873.3031 FAX 2794
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>
>>> --
>>> Jeffrey Mathis, PhD FAX: 505-988-2229
>>> Senior Scientist email: jeff.mathis@biosgroup.com
>>> Bios Group, Inc. phone 505-992-6737
>>> 317 Paseo de Peralta http://www.biosgroup.com
>>> Santa Fe, NM 87501
>>>
>
> --
> Jeffrey Mathis, PhD FAX: 505-988-2229
> Senior Scientist email: jeff.mathis@biosgroup.com
> Bios Group, Inc. phone 505-992-6737
> 317 Paseo de Peralta http://www.biosgroup.com
> Santa Fe, NM 87501
>

--
[To unsubscribe to this list send an email to "majdart@bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]