I'm a beginner with Vertx and I'm using this link as the starter code.
However, there is no main file and I don't see how the MainVerticle is deployed. I would like to set some deployment options for the MainVerticle but since there is no main file; how would I do that?
I recommend this link for you to improve your vert.x knowledge from zero to hero.You will be able to make a crud application using this repository.
https://github.com/saranglohar/vertx-crud-operations-demo/tree/master/src/main/java/com/vertx/student/crud
The two common ways to do that :
build a fat jar using the maven shade plugin or exec plugin and the io.vertx.core.Launcher class as main class, according to this documentation. Then you will be able to run your fat jar with a java -jar command.
My favorite : use the vertx command line (like you would do with nodejs for example).
I'd prefer the second solution in order to avoid the duplication of the vert.x core library in your filesystem which can have a real cost when you have to run bunch of vert.x microservices.
Afterwards to go further you can encapsulate that with a resilient services orchestrator like systemd or even docker+kubernetes & co.
You can use main() very easily:
public class Application {
public static void main(String args[]) {
Vertx vertx = Vertx.vertx()
vertx.deployVerticle(new MainVerticle());
}
}
Related
I try to call scout service from Scout Form, so I create interface in shared folder
#TunnelToServer
public interface IPersonsFormService extends IService {
void test();
}
and in server I created implementation of this interface
public class PersonsFormService implements IPersonsFormService {
#Override
public void test() {
System.out.println("TEST");
}
}
but I get
o.e.scout.rt.platform.exception.ExceptionHandler - SecurityException:service registry does not contain a service of type com.sixt.leasing.contract.scout.shared.person.IPersonsFormService [majorPrincipal: 'marko']
java.lang.SecurityException: service registry does not contain a service of type com.sixt.leasing.contract.scout.shared.person.IPersonsFormService
It looks like interface is not registered, but in Neon I thought that service is registered with #TunnelToServer annotation.
Where else should I register service ?
This project is extension project of main project.
In Main project all services works,....
Solution: put scout.xml with default content in src/main/resources/META-INF folder of the server project.
Why did this happen? Since this is an extension we apparently forgot to copy this file and Scout Neon seems to ignore projects that don't contain this file.
Figured this out by putting a PlatformListener in that project and since that never triggered it was easier to track down the issue.
This annotation is requested for Remote-Service (see also the 3.5.1. #TunnelToServer section). The implementation class (or the interface) should have the #ApplicationScoped annotation.
For Local-Service, use either the #Bean or the #ApplicationScoped annotation to register the service.
If your annotations are correct, your Jandex index might be broken.
Start the application with -Djandex.rebuild=true to rebuild the application on startup.
This will recalculate each of your target/classes/META-INF/jandex.idx files.
Of course, you can also delete each file manually. Running mvn clean also clean those files.
I'm currently writing integration tests for a Java EE application and use openejb/openjpa.
But as I'm using CMP I have to use a javaagent to enhance my classes. In maven I can configure my surefire plugin to do this enhancement, or better set the agent as vm parameter to the test.
But as I'm currently developing I like to run my tests quite often in eclipse. But there I don't want to set the agent all the time via
java -javaagent:openejb-javaagent-4.6.0.jar _\[other params...](other-params....html)
Does someone have a useful solution for this problem?
For testing in Eclipse purposes, I always create a variable that can be used in the VM arguments section of your Run Configuration. This way all you need to specify is something like ${agent} (or whatever you call it) rather than the full javaagent string.
Mhh but not sure, looking at my properties, my classes should be enhanced at runtime:
#Before
public void startupContainer() throws NamingException {
Properties p = new Properties();
p.put("openjpa.jdbc.SynchronizeMappings", "buildSchema(ForeignKeys=true)");
p.put("openjpa.jdbc.DBDictionary", "hsql(SupportsSelectForUpdate=true)");
p.put("openejb.embedded.initialcontext.close", "destroy");
p.put("openjpa.RuntimeUnenhancedClasses", "supported");
p.put("openjpa.DynamicEnhancementAgent", "true");
p.put("javax.persistence.lock.timeout", "0");
p.put("openejb.log.factory", "slf4j");
ejbContainer = EJBContainer.createEJBContainer(p);
}
I have a Scalatra web service that runs with embedded Jetty. I'd now like to write integration tests that:
start the service (using the main method of the application)
run the tests (driving the HTTP interface)
stop the service.
This should all be triggered by an SBT command.
How should I go about this?
You could write such integration tests on top of BDD test frameworks like Specs. Unfiltered project has many such examples that should work for other web frameworks like Scalatra.
For example, take a look at ServerSpec:
"A Server" should {
"respond to requests" in {
http(host as_str) must_== "test"
}
....
}
It's starting up a test server specified in setup and hitting it using Dispatch in the specification. The key part is implemented in unfiltered.spec.jetty.Served trait, which does that you described: starting and stopping the service. There's also Specs2 version: unfiltered.specs2.jetty.Served.
Another trick you could use is sbt-revolver, which my favorite plugin while doing any web development, especially used in conjunction with JRebel. This plugin can load your web server in the background. I haven't tried test together, but it could work if you don't have to change the server-side during the test.
Scalatra offers a DSL to write tests. There is support for specs2 and scalatest.
By default an embedded Jetty will be used for testing. If you want to provide your own server, you can reuse the EmbeddedJettyContainer implementation and override start, stop and servletContextHandler.
start will be called before executing the tests, which allows to start your server if required. stop is called after the tests. servletContextHandler is required in order to add your servlets using addServlet(..).
This is from the spec2 integration:
trait BaseScalatraSpec extends SpecificationStructure with FragmentsBuilder with ScalatraTests {
override def map(fs: =>Fragments) = Step(start()) ^ super.map(fs) ^ Step(stop())
}
trait ScalatraTests extends EmbeddedJettyContainer with HttpComponentsClient { }
Alternatively you can provide your own Container implementation.
I'm thinking about how should be the process to deploy my already locally tested rest api to the cloud, lets say an infrastructure as a service (not a platform as a service such as Heroku) like amazon.
I have my local envorinment set up with sbt up and running but my question is How should I deploy this in a production environment?
Is it sane to define a process in which the devops pulls the most recent changes from the git repo and then simply executes sbt run?
I want to know how does the teams that uses scala+spray+sbt deploys their apis to a production environment.
The heart of our services is scala + akka + spray + mongo. So we are using GitHub for version control. After merging checked PRs to the master branch, Jenkins automaticaly tests'n'builds project. If all tests were successful then Jenking runs a couple of scripts:
Increment project version (currently written in shell, but will be changed to sbt)
Run assembly task with sbt-assembly
Run deploy script (written in Python with Fabric) wich deploys our jar to EC2
Basicaly on the thrid step you have a couple of choices:
Make a runnable jar using IO/Spray boot file:
object Boot extends App {
implicit val system = ActorSystem("ServiceName")
val log = system.log
val service = system.actorOf(Props[Service], name="serviceActor")
IO(Http) ! Http.Bind(service, interface = host, port = port)
}
Make a runnable jar as Akka's microkernel:
In this case you should extend Bootable trait and override startup and shutdown methods:
class Kernel extends Bootable {
// many lines of code
def startup() {
scheduler.start()
SomeActorSystem.startup()
}
def shutdown() {
scheduler.shutdown()
SomeActorSystem.shutdown()
system.shutdown()
}
}
Using a TypeSafe startscript:
Can't show an example, but it has a good intro on github =)
We are using all of this way in different cases.
You should build a jar with the plugin sbt-assembly
addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.9.0")
Then you can run the jar in production with java -jar
If you give version number to your project, this is a rather classic process.
Hope it helps.
Never went to PRO with spray-akka. Only pet projects. My suggestions here should be taken as inspiration. I know some of the options I present are costly in terms of maintenance or prone to errors.
Packaging
I only used maven-shade-plugin (no experience with sbt) but I guess there's a similar solution.
Packaging Issues
There's few issues with this approach though. Akka and many of the spray modules use the references.conf and application.conf convention. When assembly/shading all your dependencies the resources (since they are named the same) may overwrite and you'd be unable to start the application.
The quick and dirty solution I found was to copy/paste the application and ref.conf of the dependencies into one controlled by me.
I am new to JBoss ESB and I am trying to intercept and handle all messages that happen on my application server.
I found that pipeline interceptors are what I am looking for. However, I am unable to make them work. Could you direct me to any tutorial concerning this problematigue? I tried documentation for JBoss ESB but this section is very vague. Is there any working sample with pipeline interceptors? I have not found any...
Here is what I have tried:
import org.jboss.soa.esb.helpers.ConfigTree;
import org.jboss.soa.esb.listeners.message.PipelineInterceptor;
import org.jboss.soa.esb.message.Message;
public class Interceptor implements PipelineInterceptor {
#Override
public void processMessage(Message msg, ConfigTree arg1) {
System.out.println("Intercepted" + msg.getContext());
}
}
I programmed this very simple class and converted it into a .jar file and placed it in the root directory of my project. I also copied jbossesb-properties.xml next to it and uncommented the interceptors section. What else should I do? Where do I specify the path to my interceptor class?
Any help is appreciated...
Ok, after a day of trying everything possible, I think I have solved it. You have to place the .jar file with Interceptor somewhere in the path of ESB (the best way is probably to the folder with deployed ESB in AS) and specify path to it in jbossesb-properties.xml file...