Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ontopia on GAE - URLStreamHandler is a restricted class #118

Closed
GoogleCodeExporter opened this issue Mar 16, 2015 · 7 comments
Closed

Ontopia on GAE - URLStreamHandler is a restricted class #118

GoogleCodeExporter opened this issue Mar 16, 2015 · 7 comments

Comments

@GoogleCodeExporter
Copy link

I'm testing out a simple Ontopia webapp, https://ontopia.googlecode.com/
svn/trunk/sandbox/ontopia-stormberg-demowebapp, on Google App engine.
The app uses a standard in-memory topic map, but tries to read the topic 
map from file submitted with the source code. 
I am informed that the reading of the resource file is in conflict with 
the GAE way of doing things.
This can be worked around by not having the file with the source code. But 
the problem with the file loader should be looked into.

Original issue reported on code.google.com by stig....@gmail.com on 18 Aug 2009 at 10:58

@GoogleCodeExporter
Copy link
Author

Stack trace

Original comment by stig....@gmail.com on 18 Aug 2009 at 10:59

Attachments:

@GoogleCodeExporter
Copy link
Author

This is the relevant part of the stack trace:

[ontopia-stormberg/1.335703334203193331].<stdout>: ERROR [Runtime Network 
Thread] 
(TopicMapSourceManager.java:157) - Could not refresh topic map source 
net.ontopia.topicmaps.xml.XTMPathTopicMapSource@c707c1. Ignoring.
java.lang.NoClassDefFoundError: java.net.URLStreamHandler is a restricted 
class. 
Please see the Google App Engine developer's guide for more details.
    at 
com.google.apphosting.runtime.security.shared.stub.java.net.URLStreamHandler.<cl
init>
(URLStreamHandler.java)
    at net.ontopia.infoset.impl.basic.URILocator.<clinit>(URILocator.java:28)
    at net.ontopia.topicmaps.entry.AbstractURLTopicMapReference.<init>
(AbstractURLTopicMapReference.java:47)
    at net.ontopia.topicmaps.entry.AbstractOntopolyURLReference.<init>
(AbstractOntopolyURLReference.java:41)
    at net.ontopia.topicmaps.xml.XTMTopicMapReference.<init>
(XTMTopicMapReference.java:35)
    at net.ontopia.topicmaps.xml.XTMPathTopicMapSource.createReference
(XTMPathTopicMapSource.java:54)
    at net.ontopia.topicmaps.entry.AbstractPathTopicMapSource.createReference
(AbstractPathTopicMapSource.java:246)
    at 
net.ontopia.topicmaps.entry.AbstractPathTopicMapSource.refreshFromFilesystem
(AbstractPathTopicMapSource.java:225)
    at net.ontopia.topicmaps.entry.AbstractPathTopicMapSource.refresh
(AbstractPathTopicMapSource.java:200)
    at net.ontopia.topicmaps.entry.TopicMapSourceManager.refresh
(TopicMapSourceManager.java:146)
    at net.ontopia.topicmaps.entry.TopicMapSourceManager.getReferenceByKey
(TopicMapSourceManager.java:80)
    at net.ontopia.topicmaps.entry.TopicMaps.createStore(TopicMaps.java:44)
    at net.ontopia.topicmaps.entry.TopicMaps.createStore(TopicMaps.java:34)
    at net.ontopia.topicmaps.nav2.impl.basic.NavigatorApplication.getTopicMapById
(NavigatorApplication.java:192)
    at net.ontopia.topicmaps.nav2.impl.basic.NavigatorApplication.getTopicMapById
(NavigatorApplication.java:181)
    at net.ontopia.topicmaps.nav2.taglibs.logic.ContextTag.doStartTag
(ContextTag.java:147)
    at org.apache.jsp.klesplaggListe_jsp._jspService(klesplaggListe_jsp.java:78

This is actually in the static initialization of the URILocator class, where we 
register a completely different class as the URL handler for the data: URLs. 
There 
is already a catch clause there to ensure that SecurityExceptions just cause 
silent 
failure to install, and we could do the same with 
java.lang.NoClassDefFoundError.

I can't think of any arguments against it, really, except that the alternative 
would 
be to move the installation of the handler to the data URL handler class. Not 
sure 
why we have this at all, to be honest.

Original comment by lar...@gmail.com on 18 Aug 2009 at 11:07

  • Added labels: Component-Engine

@GoogleCodeExporter
Copy link
Author

Fixed in revision 419, I think. Please verify that the fix works and set the 
issue 
to Verified.

Original comment by lar...@gmail.com on 18 Aug 2009 at 11:30

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

[deleted comment]

1 similar comment
@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

Revision 419 works successfully. Now need a place to store snapshot build. 
Propose 
to use svn/maven-snapshot-repository

Original comment by stig....@gmail.com on 18 Aug 2009 at 5:13

@GoogleCodeExporter
Copy link
Author

Original comment by lar...@gmail.com on 1 Sep 2009 at 11:57

  • Added labels: Release5.0.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant