Hey Andy, thanks for the quick response. Aha, I forgot it is a regular Jetty servlet container and your proposal of an ActiinProcessor that refuses HTTP sounds as a possible solution.
"Concrete description of the pub/sub": we are currently using Apache ActiveMQ with TCP and WebSocket connectors on (indeed) different ports, which works okay for now. However, in my opinion, it would be way more elegant if we could expose this functionality as a Fuseki service like /ds/subscribe. I think this will be quite a challenge, since I am not sure if for example client-side JMS ConnectionFactories accept paths for broker services. "What parts of the Fuseki infrastructure would you want to access and reuse?" Not sure, the main reason we want this is because it has a tighter integration with Fuseki and this would be more elegant and consistent for the outside world: for request/response you go to the /ds/query endpoint and for subscribe/publish you go to the /ds/subscribe endpoint. We can then also use the Assemblers to define such subscribe services for a particular dataset and maybe use Fuseki's GUI that shows the services as well. Curious about your thought about the above. Regards, Barry Op 12 dec. 2019 18:02 schreef Andy Seaborne <[email protected]>: Hi Barry, The FusekiServer.Builder (main) or web/xml (Fuseki full) can includes arbitrary servlets and servlet filters so anything can be added but the naming requirement may currently get in the way. Routing is by the dataset part fo the URL path. If you want "/ds/myPubSub" and also /ds/sparql" then currently "myPubSub" will need to be an ActionProcessor (and will get the logging and counters added.) Could you give a concrete description of the pub/sub? Which protocol(s) does it want to use if not HTTP? Plain TCP on differnt ports? I don't think it is fundamental - changing it so failing to find a registered ActionProcessor could make the dispatcher drop through to normal servlet dispatch in Jetty (and 404 that way). Or a ActionProcessor that refuses HTTP requests with 404 and does it's own TCP thing. What parts of the Fuseki infrastructure would you want to access and reuse? Andy On 12/12/2019 08:41, Nouwt, B. (Barry) wrote: > Hi all, > > we are using Apache Jena Fuseki 3.13 and would like to add a custom > publish/subscribe service (next to the default SPARQL service). We are > wondering whether this is possible within the provided framework of > Operations/Processors/Actions, etc, since the Fuseki classes in the > org.apache.jena.fuseki.servlets package like HttpAction and ServletBase seem > to only support HTTP based services. > > Thanks in advance! > > Regards, Barry This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
