This question already has answers here:
How do I return the response from an asynchronous call?
(41 answers)
Closed 4 years ago.
I try to create jar with mvn install , but Spring boot maven plugin skips some classes from the jar. In particular those which can are not part of my groupId if it is related. How to include all the classes?
There is no way to actually wait for the result of an async execution in JavaScript. JavaScript, whether server-side or browser-based, uses a single event loop/queue. Async operations just involve multiple events posted on the queue. You can use async/await (in modern JS) to write your code as if it were blocking but that's just syntactic sugar.
Related
This question already has an answer here:
How can I integrate socket.io on Karate
(1 answer)
Closed 1 year ago.
We are using ReadyAPI for API testing, Mocking and JMeter for performance testing and looking into the possibility to migrate everything to Karate framework. Would be handy to have all in one open source framework. But the main question is: can Karate framework handle JMS calls? Because 80% of our service testing is via JMS (with Hermes in ReadyAPI). I know SOAP and REST are supported but can't find anything about JMS.
Yes, you have to write a Java adapter (one-time work).
Please look at these 2 references:
https://twitter.com/getkarate/status/1128170638223364097
A great example that shows off Karate's
Java / JS interop - and built-in async support
first we call custom code to listen to an ApacheActiveMQ queue
an HTTP POST is made
we wait for the JMS message
and assert that the message is as expected
https://github.com/intuit/karate/tree/master/karate-netty#consumer-provider-example
https://twitter.com/getkarate/status/1417023536082812935
How Java interop and mocks can come together for advanced async / messaging flows such as JMS or apachekafka
link to full example: https://github.com/intuit/karate/tree/develop/karate-demo/src/test/java/mock/async
This question already has an answer here:
How to get transactions to a #PostConstruct CDI bean method
(1 answer)
Closed 5 years ago.
I have a Java EE 7 project with a web frontend and I'd like to present some lazily-initialized initial choice to the user which he_she can then complement. The #PostConstruct method of the EJB seemed like a good place, but it doesn't guarantee that a transaction is present.
I'm looking for the most elegant solution, eventually a place which has been foreseen for this task.
The #PostConstruct method of an #ApplicationScoped managed bean in the web frontend would be an option, but I'd still have to make a bogus call to get it initialized - it's way, but maybe not the most elegant one.
Specify the javax.persistence.sql-load-script-source property in your persistence.xml file.
It points at a SQL script that will preload your database. This can be a resource embedded in your application or an external file URL.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Our group used to build web applications using jersey. Usually we would have two modules, dao and api. Dao consists of entity classes and dao interfaces/implementation classes, while Api module has all the rest api classes. Recently, we have been transitioning from Jersey to Spring MVC and Spring Boot. Since we are using Spring Data and JPA, there seems to have no need of having a dao package for all the interfaces and implementations. Instead, JPA repositories take care of all the data access. Services are built over the repository layer. It feels more natural to have the JPA repository stuff in the same module as services, controller, etc.
What is the best practice of organizing a restful web api project? Should I set up the project as a two module application just like what we did before, that is having all the entities in one module (model or dao) and the rest goes to another module called api? If this is the way to go, should I keep persistence.xml which contains all the ORM mapping for entities within the entity module or the api module?
This is mostly my opinion of 1 vs 2 modules, but I don't think there is one single answer. It probably depends on how large the web app is. Is it a single API in the same codebase/build that's basic CRUD or do you have many separate, but smaller APIs creating more of a micro-service environment. We had a few larger monolithic apps where we did separate out the Dao stuff into separate modules. We also separated 3rd party dependencies such as Google or Stripe into a module even separate from Dao stuff. Makes it easier to create a separate jar if there was a need.
Regardless, what's more important is you can ensure you have one way dependency. Meaning the API is dependent on the DAO but not the opposite. Curious what others think
I'd like to know how to do general initialization tasks in Vaadin 7.6. Application that take place at deployment time, before incoming HTTP requests. Found some threads that suppose using AbstractApplicationServlet. But seems removed in Vaadin 7.
Because I'm quite new to Vaadin I feel a little lost here. What is the way to go?
Using Jetty 9.
That's not a task for Vaadin since Vaadin only gets active when the first request is handled by the Vaadin servlet.
You can implement a standard javax.servlet.ServletContextListener, which is intended for this purpose, and register that in your web.xml. In the listener's contextInitialized() method, you can perform your initialization tasks.
The Vert.x documentation says that Scala (and Clojure) will be supported 'soon'.
What's actually missing for using it with Scala as is??
So, as of 2013/11/04:
Scala support has everything up to Vert.x 2.0.2-final plus DNS support. So you need 2.1M1 of Vert.x core and the 0.2.0 release of Scala.
We need to add UDP support, EventBus timeouts (mostly done, but there seems to be a bug in the vert.x core project: https://bugs.eclipse.org/bugs/show_bug.cgi?id=420850 ), provide asynchronous registerHandler methods (as these changed to async style) and provide a solution for the unregisterHandler problem we were facing (probably use the asynchronous registerHandler to provide a RegisteredHandler object that has an unregisterHandler() method).
and a followup
Update: EventBus timeouts are done, waiting for review in pull request https://github.com/vert-x/mod-lang-scala/pull/77
I forgot to mention that HTTP Compression was also missing. Just added another PR to review here: https://github.com/vert-x/mod-lang-scala/pull/78
Also added docs for both of them.
To recap what's still missing:
UDP support + test + docs
asynchronous registerHandler methods + test + docs
unregisterHandler issue + tests + docs (I guess this should be done with the asynchronous registerHandler providing a AsyncResult[RegisteredHandler] => Unit callback)
Also announced today:
I'm really proud to announce the release of Vert.x Scala 0.2.0 which includes full Vert.x 2.0 API support as well as new DNS API support coming up in Vert.x 2.1. This means that mod-lang-scala 0.2.0 now requires Vert.x 2.1.
The amazing API work has been driven by the tireless Joern Bernhardt and his colleague Sascha Schmidt. Between them two they've added all the missing APIs and reworked the testsuite to add Scala specific testtools. This was a big tasks and both Joern and Sascha deserve full credit for pulling this off. Kudos to both for this fantastic work!! :). On top of this, we've also added the capability to deploy Scala scripts into Vert.x, bringing the Vert.x Scala examples in line with other languages.
For next release, 0.3.0, we'll be focusing on polishing some these APIs, adding new APIs that Vert.x 2.1 brings, documentation and more examples :)
While we complete the documentation, the best place to get started with the Scala language module is to look at the README file in the Vert.x mod-lang-scala repository.