I'm developing a message-driven module that does not offer any web services (although it might invoke some). The main loop is to listen for incoming messages.
The reason I'm thinking of re-using dropwizard is because, even though I'm not developing any web services, I'd like to reuse the rest of the functionality that comes packaged with dropwizard - database, migrations, configuration,.yml files, jersey client etc. Is that possible (without a hack)?
You should be able to use the components that interest you as Maven dependencies. Like this:
<dependency>
<groupId>io.dropwizard</groupId>
<artifactId>dropwizard-configuration</artifactId>
<version>0.9.1</version>
</dependency>
These individual modules don't depend on dropwizard-core so you won't be pulling in Jetty, etc.
Related
I want to use an on prem bitbucket server using the bitbucket rest api from an application to create, update, and manage projects, repositories, teams etc while taking the parameters from my UI. And create we hooks from my java application. Can anyone point me in the right direction and a few examples to use the api for these from my spring boot project? What are the prerequisites
PS: I looked at the api docs and tried from postman and i want to call the rest end point from my java application.
Edit:
So I am trying to use the JAVA api given
<dependency>
<groupId>com.atlassian.bitbucket.server</groupId>
<artifactId>bitbucket-rest</artifactId>
<version>4.0.0-eap1</version>
<scope>provided</scope>
</dependency>
I'm unable can someone point me to the right direction to initialize or configure the BitBucketClient in my Java code. I don't know how to start calling my local bitbucket server
Has anyone configured swagger with spring-data-rest. I know swagger has DocumentationConfig class which scans for all spring-mvc request mappings. But, how to use that for spring-data-rest as there are no explicit request mappings defined. Any help in this regard is greatly appreciated. Also, like to know, if there are any other documentation framework which supports Spring-Data-Rest.
In version greater than 2.6.0 of SpringFox, support for spring data rest was added (but it's still in incubation). In order to add support for Spring Data Rest, you need to include the dependency below:
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-data-rest</artifactId>
<version>2.6.1</version>
</dependency>
This has been lingering out there a while, but as others have mentioned, there are (still) no Swagger implementations that support Spring Data Rest. However, Spring Data Rest does follow the HAL specification, and the HAL Browser integrated really seamlessly with any SDR project. Coupled together with the newer versions of SDR that expose ALPS metadata, this should be very sufficient for your documentation goals.
Answer for your second question:
AsciiDoctor combined with Spring REST Docs/RestAssured can be neat way of documenting SDR endpoints. It does require a bit of manual effort though, as the only automated part will be the creation of snippets. These can then be loaded into your AsciiDoc files.
was wondering if I can use the Neo4j Java API for connecting to remote DBs or is REST the only way for me to access a remote DB ? Was looking to use something like
GraphDatabaseService graphDb = new GraphDatabaseFactory().newEmbeddedDatabase(NEO_4J_REMOTE_DB_ENDPOINT);
If I can use, what would my endpoint look like ? '/db/data ?
Or is it the case where I have to use REST ?
I have my server running in GAE and have a Neo4j instance in Heroku.
Thanks guys.
REST is the only communication protocol with the server version at the moment. There have been talks about a binary protocol but that does not exist atm.
However, there are several layers for different languages over this REST API. For Java, you can find it here :
https://github.com/neo4j/java-rest-binding
This allows you to use the same API as the embedded version, but in the background it is translated to REST. There are some limitations on the functionality, and it's not up to date with all the latest versions but never the less, it works pretty darn good and I always use it with Heroku.
EDIT: If you're using maven, add this repository http://m2.neo4j.org/index.html and then add these lines to your POM
<dependency>
<groupId>org.neo4j</groupId>
<artifactId>neo4j-rest-graphdb</artifactId>
<version>2.0.1</version>
</dependency>
I would like to share the data access portion of my grails app (Grails domain classes and services) with another grails app. One is a standard client facing web app, the other (not yet written) will be for periodic background tasks such as reminder emails and such using the Quartz plugin or similar, where the UI will just be for statistics/control for internal users.
I do not want this all bundled in one Grails application because I want to be able to scale them and run them on different machines. What is the proper way to do this? I have accomplished this in the past in more legacy Java web applications by bundling the shared data access classes into a .jar and including them where needed in multiple apps, but I'm not sure if this is the right approach for Grails.
I've considered a full blown service oriented architecture where a third grails application is responsible for all data access and the two described do all their data access through REST calls to this service app, but this is out of scope for the short term since the client facing webapp is already written.
Usually this is done via plugins. Create your domain classes, services, controllers and even default gsp's that you want to share among apps and create them as a plugin. That way you can install them in any Grails app that requires that behavior.
I've done this with some generic accounting type behavior that is fairly common among apps I write like receivables, payables, etc.
One great thing is that you can write the plugin and test separately with a test data source and then when you install it into a Grails app it will use the apps data source. And it will have default gsp's and controllers that give you a basic set of behavior that you can override in the actual app.
I'm thinking about possible alternatives for our EJB based service layer and wondered if it would make sense to use just the service and database layer of Grails together with the Remoting Plugin or is this using a sledgehammer to crack a nut?
Speaking of the Remoting Plugin: is there a standard way of generating a JAR file, that contains the necessary classes to make a remote call to a Grails service from a non-Spring Java application?
Interesting idea. I don't think it'd be overkill at all. The nice thing is that your service would be very portable across protocols and deployment options (e.g. put a controller layer on top and it's instantly embedded). This gives you the benefits of EJB's (persistence) + the ability to use Groovy and GORM.
FWIW, we're using Grails as our service tier; in come cases we use it embedded (as a plugin), in others we expose the services (via controllers) as JSON or SOAP; I see exposing as RMI as a variation of what we're doing (without the controller layer).