Hi Andrew, On Tue, Sep 16, 2014 at 3:07 AM, Andrew Stone <[email protected]> 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]. > 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.
