Thanks again for the reply Michael - really appreciate it. Thinking more of it last night, it's in our best interest to have the HTTP server capabilities provided for more than just visualization (stats, node count, cluster status etc..) for long term support and troubleshooting both with our internal teams, customers and neo4j.
In that case it's a bit too bad about not moving to latest Jersey. I guess for now I'll try to isolate our other module and perhaps try to work up the chain to see if we can make a request to neo through our contract. Thanks again! On Tuesday, September 16, 2014 6:28:28 AM UTC-4, Michael Hunger wrote: > > Hi Andrew, > > On Tue, Sep 16, 2014 at 3:07 AM, Andrew Stone <[email protected] > <javascript:>> wrote: > >> Thanks again for the reply. >> >> Unfortunately that single page is a bit too simplistic. >> > Sure it was just an example to show that it's not hard to pull data out of > neo to visualize it. > > >> We have a relatively complex object model (10 different node types, 20 >> different relationship types) which will probably contain easily up to 100k >> nodes. Being able to target a single entity ID and view the connected >> relationships and their type (ex different icons) is hugely beneficial - >> this is where the /webadmin/ interface really shines. We actually prefer >> /webadmin/ over /browser/ since we mostly target single IDs and verify >> their relationships without having to worry about cypher. >> > > The code is there in the OSS github repository, it uses coffeescript + > arbor.js and should be not too hard to pull out into a separate standalone > app. You might even be able to patch neo4j-server to configure the webadmin > with a different URL. > > >> >> I do like your idea of exposing our own endpoint though to bypass the >> jersey problem. >> > > It sounds very much as if a custom visualization is something you want to > have for your application anyway. > >> >> Would it be overly difficult for us to strip out the neo4j /webadmin/ and >> point it to our new endpoint(s) ? Is Jersey2.x in the pipeline? >> > > I don't think that jersey 2 is in the pipeline for the next release(s). > >> >> I'm mostly concerned with spending too much effort / complexity on trying >> to solve this if Jersey2.x will be used in the very near future. >> > > I think looking into a dedicated custom visualization that has also a much > more efficient way of talking to the server than the old rest-API that > webadmin uses. > > Afaik alchemy.js that I used for cy2neo also supports node-icons and > custom captions. > > Cheers, Michael > >> >> >> >> On Monday, September 15, 2014 6:30:46 PM UTC-4, Michael Hunger wrote: >>> >>> You can just expose a simple cypher endpoint from your application, that >>> you then connect to from a single page javascript app like this: >>> jexp.github.io/cy2neo >>> >>> An example for that endpoint would either be CypherService (where you >>> only have to adapt the jersey changes) or the transactional cypher endpoint >>> (which is probably overkill for your debugging). >>> >>> HTH Michael >>> >>> On Mon, Sep 15, 2014 at 11:38 PM, Andrew Stone <[email protected]> >>> wrote: >>> >>>> Hi Michael, >>>> >>>> Thanks for the reply. I should have included that information... >>>> >>>> We have maven dependencies on neo4j-enterprise, neo4j-ha, neo4j-cypher >>>> and neo4j-server. >>>> >>>> We also have an additional dependency to deploy the static-web files of >>>> neo4j-server. >>>> >>>> Our goal is to have neo4j running 100% embedded (accessed with Java >>>> API) within our WAR, but we also desperately need the webadmin tool for >>>> debugging. >>>> >>>> When we try to pull in Jersey 2.x, it conflicts with the Jersey >>>> dependencies (jersey-core specifically) referenced from neo4j-server. Once >>>> I exclude Jersey dependencies from neo4j-server the webadmin tool breaks >>>> (the embedded DB works fine). >>>> >>>> Perhaps is there a way for us to have the webadmin tool without pulling >>>> in neo4j-server and/or Jersey? >>>> >>>> Much appreciated, >>>> Thanks >>>> >>>> On Monday, September 15, 2014 12:24:00 PM UTC-4, Andrew Stone wrote: >>>>> >>>>> Hello, >>>>> >>>>> We are running neo4j embedded within our application and have the need >>>>> to include a module which depends on Jersey 2.9 / JAX-RS2.0 >>>>> >>>>> Neo4j-server is running Jersey 1.9. >>>>> >>>>> As you may know. v1 and v2 of JAX-RS API have fundamental differences >>>>> that do not allow them to execute within the same classpath. So we are >>>>> stuck and need to either downgrade the other module (we own it) or try to >>>>> isolate it within its own classpath - either adds additional overhead for >>>>> development. >>>>> >>>>> *Does Neo4j have any intent to upgrade their Jersey version? Has >>>>> anyone else run into this problem? What was your solution?* >>>>> >>>>> >>>>> Thanks >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Neo4j" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Neo4j" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
