Bug in ResourceLocationJme

Hi, recently a change had been made to this inner class:



[java]

protected class ResourceLocationJme implements ResourceLocation {



public InputStream getResourceAsStream(String path) {

AssetKey<Object> key = new AssetKey<Object>(path);

AssetInfo info = assetManager.locateAsset(key);

if (info != null){

return info.openStream();

}else{

throw new AssetNotFoundException(path);

}

}



public URL getResource(String path) {

throw new UnsupportedOperationException();

}

}

[/java]



This class is insie NiftyJmeDisplay.

The previous version did not throw AssetNotFoundException().

And I’m 100% sure it shouldn’t.



When nifty looks up resources it iterates through all registered classes that implement ‘ResourceLocation’.

When this class throw the exception the rest of them do not even have a chance to look for the asset.



I had a searching class that worked quite well.

ResourceLocationJme didn’t find my resource but my class did.



I’d be greateful for fixing this bug :slight_smile:

It should return null right?

I almost changed that but really you should only access data that is inside the AssetManager root, why do you need nifty to load data from elsewhere? Especially images should only be loaded from a location that is accessible to the AssetManager, you should add the folder or whatever to the AssetManager root via FileLocator, ZipLocator or w/e. This is because only objects with valid asset names can be managed by the AssetManager, they are managed by that absolute pathname. If you register different locations, there might be two different images registered with the same name (e.g. hull.jpg from one location and hull.jpg from another location) and the system cannot tell one from the other.

I think there are several reasons why this should not throw an exception.



1.

I thought that locators are always queried in the same order.

If yes - then always the same locator should locate hull.jpg so there won’t be a problem with multiple resources.

But I’m not 100% sure about that so correct me if I’m wrong.



2.

Here we encounter a situation of NOT finding an asset. So we’re not really loading hull.jpg - some other locator should locate it.



3.

I - for example - am working with OSGI framework.

I have several bundles and each of them will carry its own resources. That is a general idea for my game to be.

So naturally I will not be able to use jme locators because they will only locate assets in jme bundle.

That is why I will need separate locators/loaders registered.



4.

You really should not give to much restrictions to developers and allowing them to use only one types of classes to do certain things.

I belive that framework that is used to develop games should be as much flexible as you can make it.

So restricting locators to only one class or (as in another topic :P) making AppSettings ‘final’ really binds the hands of others who could use

all available java features for writing their apps.



5.

The resource that was not find was my own nifty-style.xml.

It was referenced from the gui.xml file and loaded by nifty automatically.

I registered my locator to nifty but the exception interrupted the search.



6.

If you really want resources not to be doubled maybe we should consider something like DataRepository from blender importer.

It’s use causes that no asset is loaded twice.

Locators for nifty in general, yes, also the AssetManager locators, yes. Since the asset manager takes the role of locators in jME3 it replaces this function in Nifty for jME3, hence the exception. Nifty for jME3 is only displaying images that are used in the OpenGL context, hence it is only allowed to load them in a controlled manner.

The whole idea about the AssetManager is that there is only one file system - the AssetManagers file system - and that all resources are loaded via that manager, especially those that are displayed in the OpenGL context. I work with the same restrictions as you with the OSGi restricted class loader environment and the fact that I can use the AssetManagers filesystem independently actually helped me to manage some of these problems. So while I agree that maybe some xml file locators should not fail the image locating should fail when the images don’t come from assetManager. Its not about restricting people, its about how this is meant to work.

Bottom line: Add the locator to the assetManager, not to nifty.