You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Melanie Reiplinger <me...@dfki.de> on 2012/07/04 16:00:39 UTC
Re: ontonet problems
Hello all.
I'm still on the ontonet endpoint, now trying to implement access to the
session and the library manager. I'm somehow confused about the
documentation. On
http://incubator.apache.org/stanbol/docs/trunk/ontologymanager/
<http://incubator.apache.org/stanbol/docs/trunk/ontologymanager/ontonet/>,
there are two branches:
ontologymanager/{registry|ontonet}/
and
ontonet.
Both do not state examples for creating or deleting sessions. On the
RESTful docu, there is an example for a POST request that should create
a session. But that command does not work for me. Even the curl command
throws me a 'Method not allowed' when I do something like:
curl -i -X POST
"<server>/ontonet/session?scope=<scope>&session=<id>&location=<url>"
HTTP/1.1 405 Method Not Allowed
Allow: GET,OPTIONS,HEAD
Content-Type: text/html; charset=iso-8859-1
Cache-Control: must-revalidate,no-cache,no-store
Content-Length: 1398
Server: Jetty(6.1.x)
Was I again following the wrong documentation here?
Thanks,
melanie
Am 22.06.2012 12:17, schrieb Melanie Reiplinger:
> yes, sorry for this. I just saw it when going through your mail (see
> my reply to your earlier mail)
> ( sorry but I did not have time to do so earlier this week).
>
> Am 22.06.2012 11:46, schrieb Alessandro Adamou:
>> On 6/22/12 11:38 AM, Melanie Reiplinger wrote:
>>> sorry, just one more thing i noticed:
>>>
>>> [...]
>>> (note the ontology at 'localhost:8080')
>>>
>>> so there seem to be some hardcoded paths to the localhost in this
>>> interface.
>>
>> This is due to the need to configure the namespace in the Felix
>> configurations for the Ontology Network Manager and the OntoNet
>> session manager. As I wrote earlier:
>>
>>> Also, don't forget that before starting to load ontologies, you
>>> should configure the namespace of the Ontology Network Manager and
>>> the Session Manager in the Felix console, so that they point to the
>>> resolvable URLs. This is necessary for the Java API to produce
>>> correct import statements. I'm trying to figure out a way not to
>>> need that anymore, but it must work even if the RESTful API is not
>>> used (so you cannot register the UriInfo as a namespace).
>>
>> Sorry for having to go through this for the time being, but I have a
>> work plan for it. I don't think I can eliminate the need for
>> configuring the namespace completely, but at least I can reduce its
>> effect on the RESTful services.
>>
>> Best,
>> Alessandro
>>
>>
>>> Am 22.06.2012 11:27, schrieb Melanie Reiplinger:
>>>> Hi Alberto.
>>>>
>>>> Thank you so much for your support :-) and sorry for the late
>>>> reply. Here are the results of what I tried this morning, when
>>>> using your commands:
>>>>
>>>> The commands all work, so first I thought I was having gremlins the
>>>> other day when producing the errors. But the behaviour of the
>>>> endpoint is not always the same, even if I execute the same
>>>> sequence of commands.
>>>>
>>>> When first creating the scope just as you describe, my error
>>>> logfile increased a few hundred megabyte, and for a short time
>>>> loading of the webpage /ontonet/ontology was delayed again. The
>>>> rest of the commands worked perfectly. I then deleted all scopes
>>>> and all ontologies, restarted Stanbol and tried again (while
>>>> tracking the size of the logfile).
>>>>
>>>> This time, the logfile stayed unchanged throughout creation of the
>>>> scope and loading of the ontology. Then, when requesting the scope,
>>>> the log file suddenly grew to 12M (writing ~ 13K times the "Too
>>>> many open files" exception).
>>>> From that point on, everything stayed unchanged through requests or
>>>> loading of the page.
>>>>
>>>> Then I tried to load another ontology
>>>> (curl -X POST -F
>>>> "url=http://ontologydesignpatterns.org/ont/iks/kres/onm.owl"
>>>> <myserver>/ontonet/ontology/myScope)
>>>> I get the error message
>>>> HTTP ERROR 400
>>>> Problem accessing /ontonet/ontology/myScope. Reason: Bad Request
>>>> and the logfile grows to 152M (including now more than 180K times
>>>> the "Too many open files" exception).
>>>>
>>>> When trying this a second or a third time, the error message stays
>>>> unchanged, but the log file does not grow any further.
>>>> Also when trying to load an ontology via the RESTful interface, I'm
>>>> not having any success today for the onm.owl ontology, it gives me
>>>> the exception I appended below (it says that the new ontology
>>>> cannot be loaded because the already loaded ontology cannot be
>>>> loaded and because of too many open files).
>>>>
>>>> The logfile is now 251M in size, with even more "Too many open
>>>> files" issues, it has grown while I was writing this eMail so it
>>>> seems there are *WARN* logs written with some delay in time (?).
>>>>
>>>> But anyway I'm glad already that you showed me how to correctly
>>>> load an ontology into a scope. Thanks :-). Now I can go on trying.
>>>>
>>>> Best Melanie
>>>>
>>>> error message when trying to load the second ontology:
>>>> (don't mind the messed-up server time)
>>>>
>>>> 22.06.2012 12:08:27.596 *ERROR* [24890767@qtp-14471083-13]
>>>> org.apache.stanbol.ontologymanager.web.resources.ScopeResource
>>>> Failed to load ontology from
>>>> http://ontologydesignpatterns.org/ont/iks/kres/onm.owl
>>>> org.semanticweb.owlapi.model.UnloadableImportException: Could not
>>>> load imported ontology:
>>>> <http://ontologydesignpatterns.org/ont/iks/kres/omv.owl> Cause: Too
>>>> many open files
>>>> at
>>>> uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.makeLoadImportRequest(OWLOntologyManagerImpl.java:1119)
>>>> at
>>>> org.coode.owlapi.rdfxml.parser.TPImportsHandler.handleTriple(TPImportsHandler.java:88)
>>>> at
>>>> org.coode.owlapi.rdfxml.parser.OWLRDFConsumer.handleStreaming(OWLRDFConsumer.java:1626)
>>>> at
>>>> org.coode.owlapi.rdfxml.parser.OWLRDFConsumer.statementWithResourceValue(OWLRDFConsumer.java:1581)
>>>> at
>>>> org.semanticweb.owlapi.rdf.syntax.RDFParser.statementWithResourceValue(RDFParser.java:576)
>>>> at
>>>> org.semanticweb.owlapi.rdf.syntax.RDFParser$EmptyPropertyElement.startElement(RDFParser.java:1047)
>>>> at
>>>> org.semanticweb.owlapi.rdf.syntax.RDFParser$PropertyElementList.startElement(RDFParser.java:924)
>>>> at
>>>> org.semanticweb.owlapi.rdf.syntax.RDFParser.startElement(RDFParser.java:281)
>>>> at
>>>> org.coode.owlapi.rdfxml.parser.RDFXMLParser$1.startElement(RDFXMLParser.java:92)
>>>> at
>>>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:504)
>>>> at
>>>> com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182)
>>>> at
>>>> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.emptyElement(XMLDTDValidator.java:791)
>>>> at
>>>> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:353)
>>>> at
>>>> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2732)
>>>> at
>>>> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:625)
>>>> at
>>>> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116)
>>>> at
>>>> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488)
>>>> at
>>>> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:812)
>>>> at
>>>> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:741)
>>>> at
>>>> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
>>>> at
>>>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208)
>>>> at
>>>> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525)
>>>> at javax.xml.parsers.SAXParser.parse(SAXParser.java:392)
>>>> at
>>>> org.semanticweb.owlapi.rdf.syntax.RDFParser.parse(RDFParser.java:173)
>>>> at
>>>> org.coode.owlapi.rdfxml.parser.RDFXMLParser.parse(RDFXMLParser.java:120)
>>>>
>>>> at
>>>> uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:204)
>>>> at
>>>> uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:726)
>>>> at
>>>> uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:667)
>>>> at
>>>> uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:641)
>>>> at
>>>> org.apache.stanbol.ontologymanager.ontonet.api.io.RootOntologyIRISource.<init>(RootOntologyIRISource.java:45)
>>>> at
>>>> org.apache.stanbol.ontologymanager.ontonet.api.io.RootOntologyIRISource.<init>(RootOntologyIRISource.java:40)
>>>> at
>>>> org.apache.stanbol.ontologymanager.ontonet.api.io.RootOntologyIRISource.<init>(RootOntologyIRISource.java:36)
>>>> at
>>>> org.apache.stanbol.ontologymanager.web.resources.ScopeResource.postOntology(ScopeResource.java:552)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>> at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> at java.lang.reflect.Method.invoke(Method.java:616)
>>>> at
>>>> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>>>> at
>>>> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
>>>> at
>>>> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>>>> at
>>>> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
>>>> at
>>>> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
>>>> at
>>>> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>>>> at
>>>> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>>>> at
>>>> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1483)
>>>> at
>>>> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1414)
>>>> at
>>>> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1363)
>>>> at
>>>> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1353)
>>>> at
>>>> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:414)
>>>> at
>>>> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
>>>> at
>>>> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:708)
>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>>>> at
>>>> org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
>>>> at
>>>> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
>>>> at
>>>> org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
>>>> at
>>>> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
>>>> at
>>>> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
>>>> at
>>>> org.apache.stanbol.commons.httpqueryheaders.impl.QueryHeadersFilter.doFilter(QueryHeadersFilter.java:75)
>>>> at
>>>> org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:88)
>>>> at
>>>> org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:76)
>>>> at
>>>> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:47)
>>>> at
>>>> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
>>>> at
>>>> org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:78)
>>>> at
>>>> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:47)
>>>> at
>>>> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
>>>> at
>>>> org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
>>>> at
>>>> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
>>>> at
>>>> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>>>> at
>>>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
>>>> at
>>>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
>>>>
>>>> at
>>>> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>>>>
>>>> at
>>>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
>>>>
>>>> at
>>>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>>>>
>>>> at org.mortbay.jetty.Server.handle(Server.java:326)
>>>> at
>>>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>>>>
>>>> at
>>>> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943)
>>>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
>>>> at
>>>> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
>>>> at
>>>> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>>>> at
>>>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
>>>> at
>>>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
>>>> Caused by:
>>>> org.semanticweb.owlapi.io.OWLOntologyCreationIOException: Too many
>>>> open files
>>>> at
>>>> uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:212)
>>>> at
>>>> uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:726)
>>>> at
>>>> uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:667)
>>>> at
>>>> uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadImports(OWLOntologyManagerImpl.java:1084)
>>>> at
>>>> uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.makeLoadImportRequest(OWLOntologyManagerImpl.java:1112)
>>>> ... 81 more
>>>> Caused by: java.net.SocketException: Too many open files
>>>> at
>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>>> at
>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>>>> at
>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
>>>> at
>>>> sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1458)
>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>> at
>>>> sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1452)
>>>> at
>>>> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1106)
>>>> at
>>>> org.semanticweb.owlapi.io.AbstractOWLParser.getInputStreamFromContentEncoding(AbstractOWLParser.java:161)
>>>> at
>>>> org.semanticweb.owlapi.io.AbstractOWLParser.getInputStream(AbstractOWLParser.java:126)
>>>> at
>>>> org.semanticweb.owlapi.io.AbstractOWLParser.getInputSource(AbstractOWLParser.java:200)
>>>> at
>>>> org.coode.owlapi.rdfxml.parser.RDFXMLParser.parse(RDFXMLParser.java:119)
>>>>
>>>> at
>>>> uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:204)
>>>> ... 85 more
>>>> Caused by: java.net.SocketException: Too many open files
>>>> at java.net.Socket.createImpl(Socket.java:414)
>>>> at java.net.Socket.connect(Socket.java:544)
>>>> at sun.net.NetworkClient.doConnect(NetworkClient.java:173)
>>>> at sun.net.www.http.HttpClient.openServer(HttpClient.java:409)
>>>> at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
>>>> at sun.net.www.http.HttpClient.<init>(HttpClient.java:240)
>>>> at sun.net.www.http.HttpClient.New(HttpClient.java:321)
>>>> at sun.net.www.http.HttpClient.New(HttpClient.java:338)
>>>> at
>>>> sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935)
>>>> at
>>>> sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876)
>>>> at
>>>> sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801)
>>>> at
>>>> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139)
>>>> at
>>>> sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:2214)
>>>> at
>>>> java.net.URLConnection.getContentEncoding(URLConnection.java:513)
>>>> at
>>>> org.semanticweb.owlapi.io.AbstractOWLParser.getInputStream(AbstractOWLParser.java:125)
>>>> ... 88 more
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Am 19.06.2012 09:49, schrieb Alberto Musetti:
>>>>> Hi Melanie,
>>>>> i have tried this sequence of commands:
>>>>>
>>>>> # myScope is<scopeID>
>>>>> # create a new scope
>>>>> 1. curl -i -X PUT
>>>>> http://localhost:8080/ontonet/ontology/myScope?location=http://ontologydesignpatterns.org/ont/iks/kres/
>>>>>
>>>>> # get a scope
>>>>> 2. curl -H "Accept:application/rdf+xml"
>>>>> http://localhost:8080/ontonet/ontology/myScope
>>>>>
>>>>> # load an ontology in myScope
>>>>> 3. curl -X POST -F
>>>>> "url=http://ontologydesignpatterns.org/ont/iks/kres/omv.owl"
>>>>> http://localhost:8080/ontonet/ontology/myScope
>>>>>
>>>>> # get stored ontology
>>>>> 4. curl -H "Accept:application/rdf+xml"
>>>>> http://localhost:8080/ontonet/ontology/myScope/http://kres.iks-project.eu/ontologies/omv.owl
>>>>>
>>>>> This sequence of actions works, but i don't know because if i use
>>>>> 'location' parameter instead 'url' it doesn't works any more. I
>>>>> check it and i let you know.
>>>>>
>>>>> Best
>>>>> Alberto
>>>>>
>>>>>
>>>>> Il giorno 17/giu/2012, alle ore 16:28, Melanie Reiplinger ha scritto:
>>>>>
>>>>>> Hi Alberto,
>>>>>>
>>>>>> thanks for your fast reply.
>>>>>>
>>>>>> Am 15.06.2012 12:21, schrieb musetti@cs.unibo.it:
>>>>>>> Hi Melanie,
>>>>>>> thanks for reporting this issue!
>>>>>>>
>>>>>>> I have a question, what it means:'I noticed that loading of
>>>>>>> ontologies did
>>>>>>> not really work'?
>>>>>>> Can you post the sequence of actions (even as curl commands)
>>>>>>> that you used
>>>>>>> in order I can replicate the issue? Right now I tryed to store
>>>>>>> and get an
>>>>>>> ontology to and from my Stanbol installation and everything worked
>>>>>>> properly.
>>>>>> I used
>>>>>> curl -i -X PUT
>>>>>> "http://<myserver>/ontonet/ontology/<scopeID>?location=http://ontologydesignpatterns.org/ont/iks/kres/"
>>>>>> to create a scope and load an ontology library.
>>>>>> Then, to load a specific ontology into this scope, I said:
>>>>>> curl -i -X POST -data
>>>>>> "http://ontologydesignpatterns.org/ont/iks/kres/omv.owl"
>>>>>> http://<myserver>/ontonet/ontology/<scopeID>
>>>>>> That gave me some Unsupported Media Type Error.
>>>>>>
>>>>>>> I try to open [http://lnv-89012.dfki.uni-sb.de:9001/ontonet] but
>>>>>>> there
>>>>>>> isn't response from the server. It is correct that uri?
>>>>>> The server can only be accessed from within our network, because
>>>>>> it is still kind of a development or test version. Sorry that the
>>>>>> link got into that email in the first place, I wanted to post
>>>>>> only 'http://<myserver>/ontonet#', with the placeholder instead
>>>>>> of the URL.
>>>>>>
>>>>>> Best, Melanie
>>>>>>
>>>>>>> Bests,
>>>>>>> Alberto Musetti
>>>>>>>
>>>>>>>
>>>>>>>> correction: The same exception message is also written to the
>>>>>>>> log file
>>>>>>>> when requesting other webpages of the Stanbol REST API like
>>>>>>>> e.g. the
>>>>>>>> contenthub, just only a very few times so that the page is
>>>>>>>> loaded with
>>>>>>>> no perceivable delay.
>>>>>>>>
>>>>>>>> This means that while trying out the curl commands on the
>>>>>>>> ontonet's REST
>>>>>>>> API on Tuesday, I must have blown my stanbol installation.
>>>>>>>> Has anyone ever (successfully) worked with the instructions
>>>>>>>> from that
>>>>>>>> page?
>>>>>>>>
>>>>>>>> Sebastian recommended to simply re-install, and maybe that will
>>>>>>>> solve
>>>>>>>> the problem; but if I again use the same commands I might
>>>>>>>> destroy the
>>>>>>>> stanbol over again. So do you have a reference for the ontonet
>>>>>>>> endpoint
>>>>>>>> apart from the README file and the http://<myserver>/ontonet#
>>>>>>>> <http://lnv-89012.dfki.uni-sb.de:9001/ontonet#> ? (e.g. for
>>>>>>>> creating
>>>>>>>> scopes, loading ontologies and the like)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 15.06.2012 10:50, schrieb Melanie Reiplinger:
>>>>>>>>> I forgot to mention: loading of the page does not fail,
>>>>>>>>> however. After
>>>>>>>>> several minutes, and after writing 2-3G of exception messages
>>>>>>>>> into the
>>>>>>>>> logfile, the page appears in the browser.
>>>>>>>>>
>>>>>>>>> Am 15.06.2012 10:42, schrieb Melanie Reiplinger:
>>>>>>>>>> Hi Stanbolers, Hi Rupert.
>>>>>>>>>>
>>>>>>>>>> I started working on the ontonet endpoint (in order to
>>>>>>>>>> implement the
>>>>>>>>>> Javascript interface) this week. First, I noticed that
>>>>>>>>>> loading of
>>>>>>>>>> ontologies did not really work. Second, the stanbol server got
>>>>>>>>>> terribly slow as soon as I had started posting requests to the
>>>>>>>>>> ontonet/ontology. (curl commands took several minutes,
>>>>>>>>>> loading a page
>>>>>>>>>> into the browser up 5-10 minutes). Meanwhile, loading the other
>>>>>>>>>> endpoints was unproblematic as usual. Then my network group
>>>>>>>>>> notified
>>>>>>>>>> me that the disk space used by stanbol exploded during that
>>>>>>>>>> time.
>>>>>>>>>>
>>>>>>>>>> I checked and found that the stanbol/logs/ folder gains
>>>>>>>>>> several G in
>>>>>>>>>> size while requesting e.g.
>>>>>>>>>> http://<myserver>/ontonet/ontology/
>>>>>>>>>> <http://lnv-89012.dfki.uni-sb.de:9001/ontonet/ontology/>
>>>>>>>>>> (i.e., while trying to load the page into the browser)
>>>>>>>>>>
>>>>>>>>>> In the file error.log, there is the same exception written
>>>>>>>>>> over and
>>>>>>>>>> over again:
>>>>>>>>>>
>>>>>>>>>> 15.06.2012 10:16:08.238 *WARN* [28346522@qtp-25994851-1 -
>>>>>>>>>> Acceptor0
>>>>>>>>>> SelectChannelConnector@0.0.0.0:9001] org.apache.felix.http.jetty
>>>>>>>>>> EXCEPTION (java.io.IOException: Too many open files)
>>>>>>>>>> java.io.IOException: Too many open files
>>>>>>>>>> at sun.nio.ch.ServerSocketChannelImpl.accept0(Native
>>>>>>>>>> Method)
>>>>>>>>>> at
>>>>>>>>>> sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:163)
>>>>>>>>>>
>>>>>>>>>> at
>>>>>>>>>> org.mortbay.jetty.nio.SelectChannelConnector$1.acceptChannel(SelectChannelConnector.java:75)
>>>>>>>>>>
>>>>>>>>>> at
>>>>>>>>>> org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:664)
>>>>>>>>>>
>>>>>>>>>> at
>>>>>>>>>> org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:191)
>>>>>>>>>>
>>>>>>>>>> at
>>>>>>>>>> org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
>>>>>>>>>>
>>>>>>>>>> at
>>>>>>>>>> org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:708)
>>>>>>>>>>
>>>>>>>>>> at
>>>>>>>>>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Do you know this problem?
>>>>>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
Re: ontonet problems
Posted by Fabian Christ <ch...@gmail.com>.
2012/7/4 Alessandro Adamou <ad...@cs.unibo.it>:
> On 7/4/12 4:00 PM, Melanie Reiplinger wrote:
>>
>> Hello all.
>>
>> I'm still on the ontonet endpoint, now trying to implement access to the
>> session and the library manager. I'm somehow confused about the
>> documentation. On
>> http://incubator.apache.org/stanbol/docs/trunk/ontologymanager/
>> <http://incubator.apache.org/stanbol/docs/trunk/ontologymanager/ontonet/>,
>> there are two branches:
>> ontologymanager/{registry|ontonet}/
>> and
>> ontonet.
>
>
> I do know why this is happening, but it must be due to the way Markdown
> processes the documentation sources. I removed the trunk/ontonet path long
> ago, but somehow it still makes its way into the staging build...
>
> The correct paths are ontologymanager/{registry|ontonet}/
I will have a look. I think there is a way to trigger a new checkout
of the sources when the website is built. Otherwise content seems to
be never deleted.
- Fabian
Re: ontonet problems
Posted by Melanie Reiplinger <me...@dfki.de>.
Am 06.07.2012 12:53, schrieb Alessandro Adamou:
> On 7/6/12 12:05 PM, Melanie Reiplinger wrote:
>> [...]
>>
>> But when I do
>>
>> curl -i -X DELETE
>> http://<stanbol>/ontonet/session/<mySession>/<someScope>
>> HTTP/1.1 500 Internal Server Error
>> Content-Length: 0
>> Server: Jetty(6.1.x)
>>
>> the scope (which i appended to the session before) is not removed.
>>
>> Is that a desired restriction, so that I cannot undock a scope from a
>> session unless I delete the session completely?
>
> No, more simply scope detachment is not implemented in the RESTful API
> yet, only in the Java API.
>
> It's just a matter of choosing what the method should look like.
>
> Resources such as
> http://<stanbol>/ontonet/session/<mySession>/<someScope> are not
> created at all afaik. It throws that error because it cannot find an
> ontology named <someScope> (I'll make it return 404 instead)
>
> What would you like the session-scope relation to look like in the
> RESTful API? Would you like it to be something like
>
> DELETE http://<stanbol>/ontonet/session/<mySession>/<someScope>
> (thereby creating the resources too)
>
> or
>
> DELETE http://<stanbol>/ontonet/session/<mySession>?scopeid=<someScope>
>
>> Also, when clicking in the Browser view on the link of the loaded
>> scope, I'm redirected to
>> http://<stanbol>/ontonet/ontology/<someScope>
>> <http://lnv-89012.dfki.uni-sb.de:9001/ontonet/ontology/pizzaScope>.
>
> That's normal, scopes are managed as they are. But like I said, if you
> want I can make it create resources like
> http://<stanbol>/ontonet/session/<mySession>/<someScope>
The second alternative (?scopeid=<someScope>) seems to be more intuitive
then, since the scope is already there and it exists on the
ontonet/ontology/. Moreover, having additional resources for a scope on
the ontonet/session/ seems unnecessary since there's a link to the scope.
>
> Alessandro
>
>
>> Am 06.07.2012 11:37, schrieb Melanie Reiplinger:
>>> Sorry, I meant I was on revision 1356930 for the complete stanbol. I
>>> alway updated and rebuilt the whole thing. But Most probably it's
>>> much faster if I just rebuild the respective endpoint.
>>>
>>> Am 06.07.2012 10:50, schrieb Alessandro Adamou:
>>>> On 7/6/12 10:36 AM, Melanie Reiplinger wrote:
>>>>> Thanks for your efforts in helping me :-)
>>>>
>>>> well I'm the guy behind that code, so I'm listening for reports and
>>>> wishes over there.
>>>>
>>>>> I can create session now and add scopes to them, but the version
>>>>> where the session ID should be created automatically does not work
>>>>> for me (see below).
>>>>>
>>>>>> To create a session:
>>>>>> - If you want to decide which ID to give it, just do a PUT
>>>>>> [stanbol-host]/ontonet/session/[ID]
>>>>>> - If you want Stanbol to decide the ID, do a POST
>>>>>> [stanbol-host]/ontonet/session
>>>>>
>>>>> The first works fine, but for the second option, I get:
>>>>>
>>>>> curl -i -X POST http://<stanbol>/ontonet/session
>>>>> HTTP/1.1 405 Method Not Allowed
>>>>> Allow: GET,OPTIONS,HEAD
>>>>> Content-Type: text/html; charset=iso-8859-1
>>>>> Cache-Control: must-revalidate,no-cache,no-store
>>>>> Content-Length: 1398
>>>>> Server: Jetty(6.1.x)
>>>>>
>>>>> (I'm presently at revision 1356930)
>>>>
>>>> could you please update and rebuild ontologymanager? I'm on 1357301
>>>> here
>>>>
>>>>> Furthermore, at this endpoint as well as for the ontonet/ontology,
>>>>> PUT and DELETE are not allowed for CORS yet, so the Http requests
>>>>> will fail.
>>>>>
>>>>> When doing a preflight request for PUT to
>>>>>
>>>>> http://<stanbol>/ontonet/session/pizzaSession
>>>>>
>>>>> I get in the response
>>>>>
>>>>> Access-Control-Allow-Methods:
>>>>> GET, POST, OPTIONS
>>>>
>>>> I'm afraid I'm going to need help from other Stanbolers, as like I
>>>> said I don't really dig CORS very much :(
>>>>
>>>> In the revision I mentioned, I had this preflight method in the
>>>> Session resource:
>>>>
>>>> @OPTIONS
>>>> public Response handleCorsPreflight(@Context HttpHeaders
>>>> headers) {
>>>> ResponseBuilder rb = Response.ok();
>>>> enableCORS(servletContext, rb, headers, GET, POST, PUT,
>>>> DELETE, OPTIONS);
>>>> return rb.build();
>>>> }
>>>>
>>>> I thought that manually adding supported methods in the OPTIONS
>>>> request was enough.
>>>>
>>>> Maybe I should do that in the addCORSOrigin() call for the PUT and
>>>> DELETE methods as well?
>>>>
>>>> Regards,
>>>> alessandro
>>>>
>>>
>>
>>
>
>
Re: ontonet problems
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
On 7/6/12 12:05 PM, Melanie Reiplinger wrote:
> [...]
>
> But when I do
>
> curl -i -X DELETE http://<stanbol>/ontonet/session/<mySession>/<someScope>
> HTTP/1.1 500 Internal Server Error
> Content-Length: 0
> Server: Jetty(6.1.x)
>
> the scope (which i appended to the session before) is not removed.
>
> Is that a desired restriction, so that I cannot undock a scope from a
> session unless I delete the session completely?
No, more simply scope detachment is not implemented in the RESTful API
yet, only in the Java API.
It's just a matter of choosing what the method should look like.
Resources such as
http://<stanbol>/ontonet/session/<mySession>/<someScope> are not created
at all afaik. It throws that error because it cannot find an ontology
named <someScope> (I'll make it return 404 instead)
What would you like the session-scope relation to look like in the
RESTful API? Would you like it to be something like
DELETE http://<stanbol>/ontonet/session/<mySession>/<someScope> (thereby
creating the resources too)
or
DELETE http://<stanbol>/ontonet/session/<mySession>?scopeid=<someScope>
> Also, when clicking in the Browser view on the link of the loaded
> scope, I'm redirected to
> http://<stanbol>/ontonet/ontology/<someScope>
> <http://lnv-89012.dfki.uni-sb.de:9001/ontonet/ontology/pizzaScope>.
That's normal, scopes are managed as they are. But like I said, if you
want I can make it create resources like
http://<stanbol>/ontonet/session/<mySession>/<someScope>
Alessandro
> Am 06.07.2012 11:37, schrieb Melanie Reiplinger:
>> Sorry, I meant I was on revision 1356930 for the complete stanbol. I
>> alway updated and rebuilt the whole thing. But Most probably it's
>> much faster if I just rebuild the respective endpoint.
>>
>> Am 06.07.2012 10:50, schrieb Alessandro Adamou:
>>> On 7/6/12 10:36 AM, Melanie Reiplinger wrote:
>>>> Thanks for your efforts in helping me :-)
>>>
>>> well I'm the guy behind that code, so I'm listening for reports and
>>> wishes over there.
>>>
>>>> I can create session now and add scopes to them, but the version
>>>> where the session ID should be created automatically does not work
>>>> for me (see below).
>>>>
>>>>> To create a session:
>>>>> - If you want to decide which ID to give it, just do a PUT
>>>>> [stanbol-host]/ontonet/session/[ID]
>>>>> - If you want Stanbol to decide the ID, do a POST
>>>>> [stanbol-host]/ontonet/session
>>>>
>>>> The first works fine, but for the second option, I get:
>>>>
>>>> curl -i -X POST http://<stanbol>/ontonet/session
>>>> HTTP/1.1 405 Method Not Allowed
>>>> Allow: GET,OPTIONS,HEAD
>>>> Content-Type: text/html; charset=iso-8859-1
>>>> Cache-Control: must-revalidate,no-cache,no-store
>>>> Content-Length: 1398
>>>> Server: Jetty(6.1.x)
>>>>
>>>> (I'm presently at revision 1356930)
>>>
>>> could you please update and rebuild ontologymanager? I'm on 1357301
>>> here
>>>
>>>> Furthermore, at this endpoint as well as for the ontonet/ontology,
>>>> PUT and DELETE are not allowed for CORS yet, so the Http requests
>>>> will fail.
>>>>
>>>> When doing a preflight request for PUT to
>>>>
>>>> http://<stanbol>/ontonet/session/pizzaSession
>>>>
>>>> I get in the response
>>>>
>>>> Access-Control-Allow-Methods:
>>>> GET, POST, OPTIONS
>>>
>>> I'm afraid I'm going to need help from other Stanbolers, as like I
>>> said I don't really dig CORS very much :(
>>>
>>> In the revision I mentioned, I had this preflight method in the
>>> Session resource:
>>>
>>> @OPTIONS
>>> public Response handleCorsPreflight(@Context HttpHeaders headers) {
>>> ResponseBuilder rb = Response.ok();
>>> enableCORS(servletContext, rb, headers, GET, POST, PUT,
>>> DELETE, OPTIONS);
>>> return rb.build();
>>> }
>>>
>>> I thought that manually adding supported methods in the OPTIONS
>>> request was enough.
>>>
>>> Maybe I should do that in the addCORSOrigin() call for the PUT and
>>> DELETE methods as well?
>>>
>>> Regards,
>>> alessandro
>>>
>>
>
>
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"I will give you everything, just don't demand anything."
(Ettore Petrolini, 1917)
Not sent from my iSnobTechDevice
Re: ontonet problems
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Alessandro.
When I do
curl -i -X DELETE
http://<stanbol>/ontonet/session/<mysession>/<someOntology>
HTTP/1.1 200 OK
Content-Length: 0
Server: Jetty(6.1.x)
everything is fine and the ontology is removed from my session.
But when I do
curl -i -X DELETE http://<stanbol>/ontonet/session/<mySession>/<someScope>
HTTP/1.1 500 Internal Server Error
Content-Length: 0
Server: Jetty(6.1.x)
the scope (which i appended to the session before) is not removed.
Also, when clicking in the Browser view on the link of the loaded scope,
I'm redirected to
http://<stanbol>/ontonet/ontology/<someScope>
<http://lnv-89012.dfki.uni-sb.de:9001/ontonet/ontology/pizzaScope>.
Is that a desired restriction, so that I cannot undock a scope from a
session unless I delete the session completely?
Am 06.07.2012 11:37, schrieb Melanie Reiplinger:
> Sorry, I meant I was on revision 1356930 for the complete stanbol. I
> alway updated and rebuilt the whole thing. But Most probably it's much
> faster if I just rebuild the respective endpoint.
>
> Am 06.07.2012 10:50, schrieb Alessandro Adamou:
>> On 7/6/12 10:36 AM, Melanie Reiplinger wrote:
>>> Thanks for your efforts in helping me :-)
>>
>> well I'm the guy behind that code, so I'm listening for reports and
>> wishes over there.
>>
>>> I can create session now and add scopes to them, but the version
>>> where the session ID should be created automatically does not work
>>> for me (see below).
>>>
>>>> To create a session:
>>>> - If you want to decide which ID to give it, just do a PUT
>>>> [stanbol-host]/ontonet/session/[ID]
>>>> - If you want Stanbol to decide the ID, do a POST
>>>> [stanbol-host]/ontonet/session
>>>
>>> The first works fine, but for the second option, I get:
>>>
>>> curl -i -X POST http://<stanbol>/ontonet/session
>>> HTTP/1.1 405 Method Not Allowed
>>> Allow: GET,OPTIONS,HEAD
>>> Content-Type: text/html; charset=iso-8859-1
>>> Cache-Control: must-revalidate,no-cache,no-store
>>> Content-Length: 1398
>>> Server: Jetty(6.1.x)
>>>
>>> (I'm presently at revision 1356930)
>>
>> could you please update and rebuild ontologymanager? I'm on 1357301 here
>>
>>> Furthermore, at this endpoint as well as for the ontonet/ontology,
>>> PUT and DELETE are not allowed for CORS yet, so the Http requests
>>> will fail.
>>>
>>> When doing a preflight request for PUT to
>>>
>>> http://<stanbol>/ontonet/session/pizzaSession
>>>
>>> I get in the response
>>>
>>> Access-Control-Allow-Methods:
>>> GET, POST, OPTIONS
>>
>> I'm afraid I'm going to need help from other Stanbolers, as like I
>> said I don't really dig CORS very much :(
>>
>> In the revision I mentioned, I had this preflight method in the
>> Session resource:
>>
>> @OPTIONS
>> public Response handleCorsPreflight(@Context HttpHeaders headers) {
>> ResponseBuilder rb = Response.ok();
>> enableCORS(servletContext, rb, headers, GET, POST, PUT,
>> DELETE, OPTIONS);
>> return rb.build();
>> }
>>
>> I thought that manually adding supported methods in the OPTIONS
>> request was enough.
>>
>> Maybe I should do that in the addCORSOrigin() call for the PUT and
>> DELETE methods as well?
>>
>> Regards,
>> alessandro
>>
>
Re: ontonet problems
Posted by Melanie Reiplinger <me...@dfki.de>.
Sorry, I meant I was on revision 1356930 for the complete stanbol. I
alway updated and rebuilt the whole thing. But Most probably it's much
faster if I just rebuild the respective endpoint.
Am 06.07.2012 10:50, schrieb Alessandro Adamou:
> On 7/6/12 10:36 AM, Melanie Reiplinger wrote:
>> Thanks for your efforts in helping me :-)
>
> well I'm the guy behind that code, so I'm listening for reports and
> wishes over there.
>
>> I can create session now and add scopes to them, but the version
>> where the session ID should be created automatically does not work
>> for me (see below).
>>
>>> To create a session:
>>> - If you want to decide which ID to give it, just do a PUT
>>> [stanbol-host]/ontonet/session/[ID]
>>> - If you want Stanbol to decide the ID, do a POST
>>> [stanbol-host]/ontonet/session
>>
>> The first works fine, but for the second option, I get:
>>
>> curl -i -X POST http://<stanbol>/ontonet/session
>> HTTP/1.1 405 Method Not Allowed
>> Allow: GET,OPTIONS,HEAD
>> Content-Type: text/html; charset=iso-8859-1
>> Cache-Control: must-revalidate,no-cache,no-store
>> Content-Length: 1398
>> Server: Jetty(6.1.x)
>>
>> (I'm presently at revision 1356930)
>
> could you please update and rebuild ontologymanager? I'm on 1357301 here
>
>> Furthermore, at this endpoint as well as for the ontonet/ontology,
>> PUT and DELETE are not allowed for CORS yet, so the Http requests
>> will fail.
>>
>> When doing a preflight request for PUT to
>>
>> http://<stanbol>/ontonet/session/pizzaSession
>>
>> I get in the response
>>
>> Access-Control-Allow-Methods:
>> GET, POST, OPTIONS
>
> I'm afraid I'm going to need help from other Stanbolers, as like I
> said I don't really dig CORS very much :(
>
> In the revision I mentioned, I had this preflight method in the
> Session resource:
>
> @OPTIONS
> public Response handleCorsPreflight(@Context HttpHeaders headers) {
> ResponseBuilder rb = Response.ok();
> enableCORS(servletContext, rb, headers, GET, POST, PUT,
> DELETE, OPTIONS);
> return rb.build();
> }
>
> I thought that manually adding supported methods in the OPTIONS
> request was enough.
>
> Maybe I should do that in the addCORSOrigin() call for the PUT and
> DELETE methods as well?
>
> Regards,
> alessandro
>
Re: ontonet problems
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Sorry that was a wrong question. I don't see any varargs in the method
addCORSOrigin()
But then why is not working for Melanie? It seems like everything's in
the right places re CORS...
On 7/6/12 3:57 PM, Alessandro Adamou wrote:
> Yes I am calling addCORSOrigin() already, but should I also
> explicitly add the supported methods? Right now I am simply passing
> over the request headers in the PUT and DELETE methods, like this
>
> addCORSOrigin(servletContext, rb, headers);
>
> Should I instead do
>
> // for the DELETE method
> addCORSOrigin(servletContext, rb, headers, HttpMethod.DELETE);
>
> and
>
> // for the PUT method
> addCORSOrigin(servletContext, rb, headers, HttpMethod.PUT);
>
> best,
> Alessandro
>
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"I will give you everything, just don't demand anything."
(Ettore Petrolini, 1917)
Not sent from my iSnobTechDevice
Re: ontonet problems
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Thanks a lot Rupert,
On 7/6/12 2:53 PM, Rupert Westenthaler wrote:
>> @OPTIONS
>> public Response handleCorsPreflight(@Context HttpHeaders headers) {
>> ResponseBuilder rb = Response.ok();
>> enableCORS(servletContext, rb, headers, GET, POST, PUT, DELETE,
>> OPTIONS);
>> return rb.build();
>> }
> That's exactly what you need to do. Just make sure that the "@OPTIONS"
> also matches all sub-resources that need to support PUT and DELETE.
Yes I've done that too. it's in a recent revision.
> You do need to call addCORSOrigin() otherwise users would get an error in the
> actual request - because you are telling the browser that it MUST NOT share the
> retrieved data with the webpage originating from a different domain.
Yes I am calling addCORSOrigin() already, but should I also explicitly
add the supported methods? Right now I am simply passing over the
request headers in the PUT and DELETE methods, like this
addCORSOrigin(servletContext, rb, headers);
Should I instead do
// for the DELETE method
addCORSOrigin(servletContext, rb, headers, HttpMethod.DELETE);
and
// for the PUT method
addCORSOrigin(servletContext, rb, headers, HttpMethod.PUT);
best,
Alessandro
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"I will give you everything, just don't demand anything."
(Ettore Petrolini, 1917)
Not sent from my iSnobTechDevice
Re: ontonet problems
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi
sorry a bit late but ...
On Fri, Jul 6, 2012 at 10:50 AM, Alessandro Adamou <ad...@cs.unibo.it> wrote:
> I'm afraid I'm going to need help from other Stanbolers, as like I said I
> don't really dig CORS very much :(
>
> In the revision I mentioned, I had this preflight method in the Session
> resource:
>
> @OPTIONS
> public Response handleCorsPreflight(@Context HttpHeaders headers) {
> ResponseBuilder rb = Response.ok();
> enableCORS(servletContext, rb, headers, GET, POST, PUT, DELETE,
> OPTIONS);
> return rb.build();
> }
>
> I thought that manually adding supported methods in the OPTIONS request was
> enough.
That's exactly what you need to do. Just make sure that the "@OPTIONS"
also matches all sub-resources that need to support PUT and DELETE.
An annotation like in the above example would AFAIK only be applied to
the path of the resource and not to sub-resources.
>
> Maybe I should do that in the addCORSOrigin() call for the PUT and DELETE
> methods as well?
>
You do need to call addCORSOrigin() otherwise users would get an error in the
actual request - because you are telling the browser that it MUST NOT share the
retrieved data with the webpage originating from a different domain.
Hope this helps
best
Rupert
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: ontonet problems
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
On 7/6/12 10:36 AM, Melanie Reiplinger wrote:
> Thanks for your efforts in helping me :-)
well I'm the guy behind that code, so I'm listening for reports and
wishes over there.
> I can create session now and add scopes to them, but the version where
> the session ID should be created automatically does not work for me
> (see below).
>
>> To create a session:
>> - If you want to decide which ID to give it, just do a PUT
>> [stanbol-host]/ontonet/session/[ID]
>> - If you want Stanbol to decide the ID, do a POST
>> [stanbol-host]/ontonet/session
>
> The first works fine, but for the second option, I get:
>
> curl -i -X POST http://<stanbol>/ontonet/session
> HTTP/1.1 405 Method Not Allowed
> Allow: GET,OPTIONS,HEAD
> Content-Type: text/html; charset=iso-8859-1
> Cache-Control: must-revalidate,no-cache,no-store
> Content-Length: 1398
> Server: Jetty(6.1.x)
>
> (I'm presently at revision 1356930)
could you please update and rebuild ontologymanager? I'm on 1357301 here
> Furthermore, at this endpoint as well as for the ontonet/ontology, PUT
> and DELETE are not allowed for CORS yet, so the Http requests will fail.
>
> When doing a preflight request for PUT to
>
> http://<stanbol>/ontonet/session/pizzaSession
>
> I get in the response
>
> Access-Control-Allow-Methods:
> GET, POST, OPTIONS
I'm afraid I'm going to need help from other Stanbolers, as like I said
I don't really dig CORS very much :(
In the revision I mentioned, I had this preflight method in the Session
resource:
@OPTIONS
public Response handleCorsPreflight(@Context HttpHeaders headers) {
ResponseBuilder rb = Response.ok();
enableCORS(servletContext, rb, headers, GET, POST, PUT, DELETE,
OPTIONS);
return rb.build();
}
I thought that manually adding supported methods in the OPTIONS request
was enough.
Maybe I should do that in the addCORSOrigin() call for the PUT and
DELETE methods as well?
Regards,
alessandro
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"I will give you everything, just don't demand anything."
(Ettore Petrolini, 1917)
Not sent from my iSnobTechDevice
Re: ontonet problems
Posted by Melanie Reiplinger <me...@dfki.de>.
Hi Alessandro!
Thanks for your efforts in helping me :-)
I can create session now and add scopes to them, but the version where
the session ID should be created automatically does not work for me (see
below).
Am 04.07.2012 17:42, schrieb Alessandro Adamou:
> On 7/4/12 4:00 PM, Melanie Reiplinger wrote:
>> Hello all.
>>
>> I'm still on the ontonet endpoint, now trying to implement access to
>> the session and the library manager. I'm somehow confused about the
>> documentation. On
>> http://incubator.apache.org/stanbol/docs/trunk/ontologymanager/
>> <http://incubator.apache.org/stanbol/docs/trunk/ontologymanager/ontonet/>,
>> there are two branches:
>> ontologymanager/{registry|ontonet}/
>> and
>> ontonet.
>
> I do know why this is happening, but it must be due to the way
> Markdown processes the documentation sources. I removed the
> trunk/ontonet path long ago, but somehow it still makes its way into
> the staging build...
>
> The correct paths are ontologymanager/{registry|ontonet}/
>
>> Both do not state examples for creating or deleting sessions. On the
>> RESTful docu, there is an example for a POST request that should
>> create a session. But that command does not work for me. Even the
>> curl command throws me a 'Method not allowed' when I do something like:
>>
>> curl -i -X POST
>> "<server>/ontonet/session?scope=<scope>&session=<id>&location=<url>"
>> HTTP/1.1 405 Method Not Allowed
>> Allow: GET,OPTIONS,HEAD
>> Content-Type: text/html; charset=iso-8859-1
>> Cache-Control: must-revalidate,no-cache,no-store
>> Content-Length: 1398
>> Server: Jetty(6.1.x)
>>
>> Was I again following the wrong documentation here?
>
> No, this time the documentation is outdated, sorry for that.
>
> This is because the session APIs were reworked and simplified in the
> past months
>
> To create a session:
> - If you want to decide which ID to give it, just do a PUT
> [stanbol-host]/ontonet/session/[ID]
> - If you want Stanbol to decide the ID, do a POST
> [stanbol-host]/ontonet/session
The first works fine, but for the second option, I get:
curl -i -X POST http://<stanbol>/ontonet/session
HTTP/1.1 405 Method Not Allowed
Allow: GET,OPTIONS,HEAD
Content-Type: text/html; charset=iso-8859-1
Cache-Control: must-revalidate,no-cache,no-store
Content-Length: 1398
Server: Jetty(6.1.x)
(I'm presently at revision 1356930)
Furthermore, at this endpoint as well as for the ontonet/ontology, PUT
and DELETE are not allowed for CORS yet, so the Http requests will fail.
When doing a preflight request for PUT to
http://<stanbol>/ontonet/session/pizzaSession
I get in the response
Access-Control-Allow-Methods:
GET, POST, OPTIONS
>
> The latter I just reimplemented in revision 1357301 right after your
> message, so if you svn update now, POST should be there again. It will
> return 201 CREATED with the new session URL in the Location, or 503
> FORBIDDEN if you've reached the active session quota. Right now the ID
> is simply the creation timestamp.
>
> Other than that, adding ontologies now works almost the same as in
> scopes. Just do the appropriate POST with form-multipart or
> form-urlencoded as for scopes. There are only these differences:
>
> - there's no ontology addition in the PUT method at session creation
> time. This is because, unlike scopes, sessions do not have a
> privileged space for core ontologies.
> - you can also append one entire scope (or more) to a session, so they
> will be part of the overall ontology network (and the OWL artifact
> that corresponds to the session will have owl:imports declarations on
> the scopes), e.g.
>
> % curl -X POST -F scope=social
> [stanbol-host]/ontonet/session/melanie666
>
> Hope this brings you a little further
>
> Alessandro
>
Re: ontonet problems
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
On 7/4/12 4:00 PM, Melanie Reiplinger wrote:
> Hello all.
>
> I'm still on the ontonet endpoint, now trying to implement access to
> the session and the library manager. I'm somehow confused about the
> documentation. On
> http://incubator.apache.org/stanbol/docs/trunk/ontologymanager/
> <http://incubator.apache.org/stanbol/docs/trunk/ontologymanager/ontonet/>,
> there are two branches:
> ontologymanager/{registry|ontonet}/
> and
> ontonet.
I do know why this is happening, but it must be due to the way Markdown
processes the documentation sources. I removed the trunk/ontonet path
long ago, but somehow it still makes its way into the staging build...
The correct paths are ontologymanager/{registry|ontonet}/
> Both do not state examples for creating or deleting sessions. On the
> RESTful docu, there is an example for a POST request that should
> create a session. But that command does not work for me. Even the curl
> command throws me a 'Method not allowed' when I do something like:
>
> curl -i -X POST
> "<server>/ontonet/session?scope=<scope>&session=<id>&location=<url>"
> HTTP/1.1 405 Method Not Allowed
> Allow: GET,OPTIONS,HEAD
> Content-Type: text/html; charset=iso-8859-1
> Cache-Control: must-revalidate,no-cache,no-store
> Content-Length: 1398
> Server: Jetty(6.1.x)
>
> Was I again following the wrong documentation here?
No, this time the documentation is outdated, sorry for that.
This is because the session APIs were reworked and simplified in the
past months
To create a session:
- If you want to decide which ID to give it, just do a PUT
[stanbol-host]/ontonet/session/[ID]
- If you want Stanbol to decide the ID, do a POST
[stanbol-host]/ontonet/session
The latter I just reimplemented in revision 1357301 right after your
message, so if you svn update now, POST should be there again. It will
return 201 CREATED with the new session URL in the Location, or 503
FORBIDDEN if you've reached the active session quota. Right now the ID
is simply the creation timestamp.
Other than that, adding ontologies now works almost the same as in
scopes. Just do the appropriate POST with form-multipart or
form-urlencoded as for scopes. There are only these differences:
- there's no ontology addition in the PUT method at session creation
time. This is because, unlike scopes, sessions do not have a privileged
space for core ontologies.
- you can also append one entire scope (or more) to a session, so they
will be part of the overall ontology network (and the OWL artifact that
corresponds to the session will have owl:imports declarations on the
scopes), e.g.
% curl -X POST -F scope=social [stanbol-host]/ontonet/session/melanie666
Hope this brings you a little further
Alessandro
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"I will give you everything, just don't demand anything."
(Ettore Petrolini, 1917)
Not sent from my iSnobTechDevice