Extending ClassLoader(getResource) Functionality: Questions

[Robert Paris]

First Question:
Is there a difference between:
<class_name>.class.getResource()
and
this.getClass().getResource()
Is one done natively? How does the VM see these two - as equivalent?

Second Question:
I know that when getClass().getResource() is called, that it
delegates the check to the Class's ClassLoader. So really the call is to
the ClassLoader. So when you normally do a call for getResource() it just creates a path by changing the class's package dots into "/" and then passes this to the ClassLoader to look in the folder structure.
Here's what I want to do:
1. Have XML config files for Objects in a package
a. Have these XML files available either through Http, file, etc.
2. Be able to tie the domain address to the ProtectionDomain (I think this is what I mean) of a package
EXAMPLE
If I set "http://www.site.com/Person.cfg" as the config file for
the object of class: com.site.dept.Person, then when the Person
object calls:
this.getClass().getResource("/Person.cfg");
the resource should be found at http://www.site.com/Person.cfg
ONLY from a call of an object in that package. So basically, it
ties "http://www.site.com/Person.cfg" to the package
com.site.dept; As with normal lookups, if I'm calling it from
a class com.site.other.People.class.getResource( "Person.cfg")
then it will return null (even though Person.cfg is really
located in an http location.
As well, just as with any resource actually in the folder:
com/site/dept (inside the jar or whatever), it will be
a part of that ProtectionDomain and have the same security
settings as any file in that folder would have, even though
the ClassLoader fetches it from http.
I want this to be as clean and secure as possible. I also know that I
should delegate to the super class (URLClassLoader) as much as possible, but I don't know if I can do that here since I'm doing something completely different in terms of storing URLs and tying them together. So I'm at a loss as to what's the best way to tie the http addresses (or other protocol addresses) to the correct package spots. Just to give you all more info, when I create the classloader I can pass it the info of what address is supposed to go with what object. So maybe something like this:

   <ConfigResource>
      <Location>http://www.site.com/Person.cfg</Location>
      <Object>com.site.dept.Person</Object>
   </ConfigResource>

Thanks and please let me know if anything here needs more explaining!
-Robert
[ July 29, 2002: Message edited by: Robert Paris ]
[ July 29, 2002: Message edited by: Robert Paris ]

[Robert Paris]

Anyone?

[Frank Carver]

This all seems like a mighty complicated approach. I agree that using getResource is very handy for loadable configurations and so on. I can also see that publishing these configurations in a web server can be handy if you have multiple similar applications deployed and want to share configuration information. But I don't understand the reasoning behind this "tieing together" approach.
Can you explain a little about why you want to do all this stuff with classloaders and getResource tied to remote locations? Maybe we can get a handle on other, simpler, ways of achieving the same user benefits.

[Robert Paris]

Frank,
Thanks for the reply. I talked to someone else and they convinced me that using ClassLoader is not the best idea for doing this. So here's what I need to do now:
1. Configurator will hold these files (resources)
2. Classes can call config.getConfig() and (hopefully) my Configurator will pass back only the file that fits the caller
The way I want it to do this, is for my configurator to know what class called it. It will then pass back whatever config file is stored for that class.
Someone told me the way to do this is with printStackTrace() into a StringWriter or whatever. However, I don't know if this is standard across all VMs or not, or if there is a better way to do this.
The reason for this, is I do not want classes to be able to see resources (config files) that are for other classes - for security reasons. So I can't have something where the class calls getCOnfig(String className) because that gives them the ability to pass another class's name.
Any idea for the best way to do this?
Thanks again!

[Frank Carver]

I tend to feel that the "who called me" approach is not only tricky to implement but also severely limits the maintainability of the software. It would mean that you would never be able to refactor your software to put shared code for config access into a utility class, or rename one of your config users etc. Effectively it's a "come from" which is as bad as a "go to".
If your configurations need to be "secure", and only made available to certain callers, why not do it the way the real world does it - require some sort of ID or key to be passed in when accessing the configuration information.
public Object getConfig(String paramName, Object key)
or whatever.
How the calling class gets the secure key is up to you:- compiled in as a private final member, requested from a central repository at construct time etc.
I know I keep asking for more information, but can you describe a bit more about the "security" you require? What cases can you envisage where you would need to protect your configuraion information from access by other classes? It's not something I've ever needed to do myself and I'm intrigued.

[Robert Paris]

Well, let's see if I can explain this. I'll take each idea one at a time. (Oh, btw thank you sooo much for taking the time to help me here! It's a great help and I know you're probably pretty busy)
WHY SECURITY ON CONFIG FILES?
------------------------------
Normally, I agree. Config files - who cares? It's for your own app, there's no risk. However my app is for collaboration. You can plug in objects from different places (as long as they have the right interface) - e.g. two diff. companies that work with you, on the fly at runtime. (It's through RMI right now that it works with other objects) Given this, and the fact that almost all of these objects will be configurable, I'd prefer that they only have access to their own configurations.
WHY NOT USE ID THAT THEY GIVE YOU?
----------------------------------
You might be right on this, as I might need an ability to give two diff. instances of Company object diff. configurations. So they would need instance markers that my Manager object can use to make sure they get the right configs. However, again I do not want this to lie with the object itself. Simply because then it is up to the object writer to implement this correctly. Not even so much a security issue as much as there's a chance for error EVERY time someone makes an object for my app. So here's what I'm thinking:

Have config for my Manager that tells it all the instances it needs to create and what their ids are

Manager keeps a HashMap (or whatever) with a ref. to the object and its ID.

The config files locations are also under those IDs, so when a class calls:

config.getConfigOptions(Object ref)
it simply passes itself in, and the config looks it up in the Manager for the id and gets the right config file

Questions

Will this work with RMI?

Will this work even normally? Will putting a ref to the object into a HashMap and then passing that object as an argument to the method match up, but two different objects of the same class not match up?

Thanks again!

[Frank Carver]

More and more as you describe this it reminds me of Jini. Have you checked out the Jini infrastructure in the light of this project ? It could provide pre-thought-out solutions to a lot of your problems and potential problems.
Anyway. in random order:
Will putting a ref to the object into a HashMap and then passing that object as an argument to the method match up, but two different objects of the same class not match up?
Yes. HashMaps are keyed on the object's hashCode(), which (unless overridden) is unique for each object instance.
Will this work with RMI? I'm not sure. You might just end up back at the same problem again. I'd imagine that when RMI deserializes an object it places it at an effectively random memory location, so you can't rely on the default hashCode(). You'll need the client objects to implement a globally unique hashCode(), which is back to a "magic key" again.
e.g. two diff. companies that work with you, on the fly at runtime. ... Have config for my Manager that tells it all the instances it needs to create and what their ids are
This worries me a little. Who/what would be responsible for managing the configuration manager config? Requiring an unrelated (manual ?)process to complete before someone can connect their object to your system doesn't sound very "on the fly" to me.
How about you provide something like a simple but secure web interface which a client-class programmer can use to generate a unique id string? Then just require that all client classes pass that string into the getConfig() method. I can't imagine it would be any more difficult than coding the class to use the getConfig() method in the first place.
As far as I recall, the DCE distributed programming system (a precursor to CORBA) used this approach. I remember having to run a generator program and then type in 30 or 40 characters of gibberish before I could create a new client.

[Robert Paris]

Thanks I'm checking out Jini and it looks like it might help me. Do you know of any Jini tutorials? The examples that come with these things are never easy to figure out - it takes 2 hours just to figure out how to get a pre-written example to run! (Programmers should NOT be allowed to write tutorials)

[Frank Carver]

I can't point to any tutorials right now, but I have reviewed three Jini books here in the bunkhouse