Login
Username:

Password:

Remember me



Lost Password?

Register now!
Main Menu
H3D.org Feeds
H3D.org Forum Index
   Programming Issues
     Strange behavior from ResourceResolver and URNs in H3D 2.2b
Register To Post

Flat Previous Topic | Next Topic
Poster Thread
karlsvec
Posted on: 2012/5/19 2:08
Quite a regular
Joined: 2008/7/1
From:
Posts: 41
Strange behavior from ResourceResolver and URNs in H3D 2.2b
Hello,

I'm using H3D 2.2 beta and trying to programmatically set up some custom URNs for my application, but I'm getting some very weird behavior from ResourceResolver. Here's some sort-of pseudocode that illustrates the problem:

ResourceResolver::setURNResolver( new URNResolver );

ResourceResolver::getURNResolver()->addURNResolveRule"my_namespace",
                                                       
"my_prefix",
                                                       
"/path/to/x3d/files" );

// test the URN resolver
std::cout << "resolved URN: " << ResourceResolver::getURNResolver()->resolveURN"urn:my_namespace:my_prefix/test.x3d" );
std::cout << std::endl;

// test ResourceResolver::resolveURLAsFile()
std::cout << "resolved URL: " << ResourceResolver::resolveURLAsFile"urn:my_namespace:my_prefix/test.x3d" );
std::cout << std::endl;


I get the following output:

resolved URN: /path/to/x3d/files/test.x3d
resolved URL
:


I expect ResourceResolver::resolveUrlAsFile() to have the same output as URNResolver::resolveURN(), but it doesn't. After running this code in a debugger, I see that inside the call to resolveUrlAsFile(), the call to urn_resolver().get() always returns zero, even though clearly the AutoRef<> object *does* contain a valid pointer.

string ResourceResolver::resolveURLAs( const string &urn,
                                       
bool *is_tmp_file,
                                       
bool folder ) {
  if( 
urn == "" ) return "";
  
string filename urn;
  if( 
urn_resolver().get() ) { // <--- this always returns zero, even if a URNResolver is set
    
filename urn_resolver()->resolveURNurn );
  }
  
  
// first try as relative path


Of course, this has me very confused. Am I somehow misusing ResourceResolver and/or URNResolver?

My toolchain is MinGW GCC 4.6.2 on Windows 7. I understand that MinGW is not an officially supported compiler (and that is why I haven't reported this on the bug tracker), but I haven't had any problems with a MinGW-built libH3DAPI.dll up to this point. Is it possible I've run into a compiler bug? Presumably, wouldn't people using GCC 4.6.2 on other platforms have the same problem (assuming they're trying to use URNs)?

I did mention that I'm using the 2.2 beta branch of H3D, but the ResourceResolver code seems unchanged from the 2.1 branch, so I assume I'd have the same problem there.

Any thoughts on this issue are greatly appreciated. I'm more than willing to try out any patches folks might come up with.

Thanks,

- Karl
Flat Previous Topic | Next Topic

Subject Poster Date
 » Strange behavior from ResourceResolver and URNs in H3D 2.2b karlsvec 2012/5/19 2:08
     Re: Strange behavior from ResourceResolver and URNs in H3D 2.2b Markus 2012/5/21 9:41
       Re: Strange behavior from ResourceResolver and URNs in H3D 2.2b karlsvec 2012/5/21 21:41
         Re: Strange behavior from ResourceResolver and URNs in H3D 2.2b Markus 2012/5/22 9:12
           Re: Strange behavior from ResourceResolver and URNs in H3D 2.2b karlsvec 2012/5/22 20:48
             Re: Strange behavior from ResourceResolver and URNs in H3D 2.2b karlu 2012/5/29 9:13
               Re: Strange behavior from ResourceResolver and URNs in H3D 2.2b karlsvec 2012/5/29 23:05
                 Re: Strange behavior from ResourceResolver and URNs in H3D 2.2b karlu 2012/5/30 10:31
                   Re: Strange behavior from ResourceResolver and URNs in H3D 2.2b karlsvec 2012/6/7 22:08
                     Re: Strange behavior from ResourceResolver and URNs in H3D 2.2b Markus 2012/6/29 10:14
                       Re: Strange behavior from ResourceResolver and URNs in H3D 2.2b Markus 2012/7/3 8:37

Register To Post
 



(C) 2012 SenseGraphics AB    ---    Powered by XOOPS