I have a Dropwizard(v 0.7.1) based Jersey REST service. Currently I use one application connector port (8810) and I have two resources (say "/path1","/path2").
I will be able to access these resources as http:\\localhost:8810\path1 and http:\\localhost:8810\path2 respectively. What am trying to achieve is have a separate port for each resource. (e.g http:\\localhost:8810\path1 and http:\\localhost:8820\path2). I tweaked the yaml file to have the below configuration and when I started the application both resources were available using both ports and am not sure how to configure these resources to use specific ports or is that even possible with Dropwizard?
server:
applicationConnectors:
-
type: http
port: 8810
-
type: http
port: 8820
Appreciate if someone can enlighten.
Thanks
your issue is that the DefaultServerFactory adds all applicationConntectors to the same Handler, see DefaultServerFactory#build:
#Override
public Server build(Environment environment) {
printBanner(environment.getName());
final ThreadPool threadPool = createThreadPool(environment.metrics());
final Server server = buildServer(environment.lifecycle(), threadPool);
LOGGER.info("Registering jersey handler with root path prefix: {}", applicationContextPath);
environment.getApplicationContext().setContextPath(applicationContextPath);
final Handler applicationHandler = createAppServlet(server,
environment.jersey(),
environment.getObjectMapper(),
environment.getValidator(),
environment.getApplicationContext(),
environment.getJerseyServletContainer(),
environment.metrics());
LOGGER.info("Registering admin handler with root path prefix: {}", adminContextPath);
environment.getAdminContext().setContextPath(adminContextPath);
final Handler adminHandler = createAdminServlet(server,
environment.getAdminContext(),
environment.metrics(),
environment.healthChecks());
final RoutingHandler routingHandler = buildRoutingHandler(environment.metrics(),
server,
applicationHandler,
adminHandler);
server.setHandler(addStatsHandler(addRequestLog(server, routingHandler, environment.getName())));
return server;
}
What you need to do is implement your own ServerFactory.
You can extend DefaultServerFactory and overwrite the build method to set up your connectors in the way you want them to be.
Presumably you'll want to add some more configuration that indicates what goes where, since in terms of your yaml it will not be possible to map a resource to a specific connector. How would dropwizard know about that.
For overwriting the behaviour for dropwizard (adding a new ServerFactory) you can see this post I wrote about adding logging: Dropwizard doesn't log custom loggers to file
It basically involves implementing the class and making it discoverable for dropwizard. After that all you need to do is to change the yaml file to point to the correct ServerFactory.
If you don't like that approach, you can overwrite the get/set method on the configuration to return your class. For this, your class MUST extend DefaultServerFactory, since otherwise the yaml mapping won't work anymore. You can overwrite the build method regardless though.
Update:
Looking at it in a bit more detail, you'll run into a second problem:
Your Environment only has one jersey environment that it can use.
You will need to configure a second jersey environment since currently by default each Handler will get the same Jersey config passed to it (the only one that exists). This is why it will be available for all of your http configurations. So in summary:
Create a new Environment that supports multiple jersey configurations
Create a server factory that knows what jersey config belongs to which Handler and instantiates the handlers in that form.
I believe those two steps would be required.
In terms of environment, you will have to create your own ServerCommand (that is the command that starts up dropwizard server).
Looking in EnvironmentCommand#run you can see where the Environment is created. This will be the only place you can overwrite the default Environment (as far as I know) which is what you need to do to support multiple jersey configs.
To be honest with you, looking at this, I do not believe that this is what the dropwizard guys had in mind.
Related
I have a Quarkus application which all packages an Angular SPA (bundled in the JAR). Quarkus provides the backend API routes for the frontend to consume. The Angular application build is copied to the META-INF/resources path in the target when the Quarkus application is built.
I am not using JAX-RS to register my routes. Instead I am directly registering them programmatically on the Vertx router inside the fun onRouterReady(#Observes router: Router) method.
I would like any route which is not recognised (either as a Vertx-registered route or as a static resource) to be re-directed to index.html so that my Angular application can load from all of its routes. Unfortunately I have not been able to find any way to do this.
I do not know how all the Quarkus routes function. I suspect that Quarkus itself is registering some routes using Servlets (or perhaps Vertx) because index.html is properly served on the root but my authentication root can prevent loading without authentication.
I have tried various things I have found through searches, such as:
router.route("/*").handler(StaticHandler.create())
router.route().handler({ context: RoutingContext ->
context.reroute("index.html)
})
where the idea is to create a static handler, followed by a catch-all which will re-write the request to index.html so that it is then caught by the static handler but this just results in an infinite loop (the static handler does not seem to be able to find index.html).
I have also tried adding a filter via JAX-RS (which I would like to avoid) but this does not work either.
There must be some way to set this up and I am sure that Quarkus code actually does somewhere, but I cannot find it. Any ideas much appreciated.
You need to observe Router somewhere in application scoped class and set 404 error handler to redirect to index.html
public void init(#Observes Router router) {
router.errorHandler(404, routingContext -> {
routingContext.response().setStatusCode(302).putHeader("Location", "/index.html").end();
});
}
P.S using routingContext.reroute("index.html"); will work as well, but it will keep path as it was(e.g you wrote /testabc, it will show your html file but path won't be /index.html). If you need exactly this then replace it with your option inside errorHandler
So, I will answer my own question here since I had particular requirements that were not met by the given answer.
Quarkus does indeed register its own handlers through a RestEasy standalone class (even though RestEasy is not included in my application). This includes the hot-reload routes (for dev mode), some security routes and static route handlers pointing to known static resources (presumably known at compile-time).
The static resources handler is given a low priority so is one of the last to be called. It seems to accept existing static resource paths and the route path (which it uses as /index.html).
The mistake I had made was not following the re-routing logic carefully enough. My code:
router.route("/*").handler(StaticHandler.create())
router.route().handler({ context: RoutingContext ->
context.reroute("index.html)
})
would intercept any paths which had not been matched to routes and re-route them (I am not looking to do a re-direct) to /index.html. However, re-routing starts the whole routing process over again, so I came back to my catch-all handler with the /index.html path and again tried to re-route it (because the static handler is only called much later).
The solution therefore is to ensure that I only re-route paths I have not already tried to re-route (and I can re-route to / instead of /index.html):
router.routeWithRegex("\\/.+").handler({ context: RoutingContext ->
context.reroute("/")
})
and the Quarkus-added static resource handler will take care of the rest.
Thanks for attention
i used spring integration in my project, i want to retrieve many input file from multiple ftp server with different address as bellow image:
how to create dynamically inbound-adapter in my project to polling and retrieve files from servers?
If you're allowed to use non-"General Availability" (GA) versions of 3rd party libraries (e.g. release candidates (RC) or milestones (M)) in your project, then you can utilize version 5.0.0.M2 of Spring Integration. It is the latest published version as of Mar 09 '17.
Starting from 5.0, Spring Integration includes Java DSL Runtime flow registration feature. It allows you to define integration flows (including inbound adapters) just like you do it in standard beans but it can be done at any runtime moment.
All you need to use it are these 3 steps:
Get IntegrationFlowContext bean from Spring context, e.g. by means of autowiring:
#Autowired
public MyClass(IntegrationFlowContext flowContext) {
this.flowContext = flowContext;
}
Build new flow with it, for example:
IntegrationFlowRegistration registration = flowContext
.registration(IntegrationFlows // this method accepts IntegrationFlow instance
.from(s -> s.ftp(ftpSessionFactory())
.localFilter(localFileFilter())
//other actions
.get()) // standard end of DSL flow building process
.autoStartup(true) // not required but can be useful
.register(); // this makes the flow exist in the context
When it's time to remove dynamically created flow, just refer to IntegrationFlowContext again with registration id you've got in the previous step:
// retrieve registration ID from the object created above
String dynamicFlowRegistrationId = registration.getId();
// the following will also gracefully stop all the processes within the flow
flowContext.remove(dynamicFlowRegistrationId);
There is also a DynamicTcpClient sample available on GitHub.
See the dynamic-ftp sample. While it only covers the outbound side, there are links in the README to discussions about what needs to be done on the inbound side (put each adapter in a child context that send messages to a channel in the main context).
Also see my answer to a similar question for multiple IMAP mail adapters using Java configuration and then a follow-up question.
You should be able to use the technique used there.
We use Java DSL to configure our routes. All configurations for routes are in a db table and can be configured via a GUI.
How is it possible to ensure that the camelContext starts up even if a route is misconfigured (e.g. .to(invalidurl or typo) in a route or simply a bug in a route)?
Is there a possibilty to validate the routes before starting or maybe better some parameters/options which can be set on the context itself?
You can configure the routes with .autoStartup(false), and then start the routes manually when CamelContext has been started up.
To validate its really depending on what kind of component it is. If its some database component you can write some code that does a SQL query to see if the is valid user login or something.
To validate that an endpoint uri is misconfigured, then that is harder as they have a ton of options. But this is getting improved from Camel 2.16 onwards where we have during build time some tooling that generates a json schema file with the options, then we could potentially leverage that during parsing the routes to check for invalid configuration before attempting to create the endpoints which could detect errors sooner, and even also with IDE plugins or other 3rd party tooling.
Can you just before adding every route to the context, add it to a separate "test" context individually, and see if it spins up or fails; then based on that add it to your real context?
In java EE, the way you get an EJB from a remote server is by looking it up in JNDI. The specification defines the JNDI name for a given bean type.
However, this seems to be only if you want to get a bean off your local computer. I want to get the bean off a remote server, like most users would. How do I specify the server URL? Do I pass a map to the InitialContext constructor?
Note: There is another question that is pretty much the same, but that has become out of date since the definition of portable JNDI names by the specification.
I want to get the bean off a remote server
Yes, you need specify the IP/port where the remote server (JNDI service) is running/listening.
How do I specify the server URL?
You have to set the propertie: java.naming.provider.url and make it available to the InitialConetxt.
This can be done in different ways:
to use a jndi.properties file
to use system properties
passing the value in a Hashtable when you create a new instance of
InitialContext object.
The concrete value of this and others necessary properties to instantiate the InitialConetct are vendor dependen.
An example for JBoss could be:
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=jnp://yourServer:1099
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
Keep in mind that there is no way that you can get the EJB's stub from a remote server if you don´t indicate the url.
By "Remote" I mean the client and the server are running in different JVM.
You do JNDI lookups of remote EJBs using exactly the same code as you would use when running server-side:
Context context = new InitialContext(); // No properties needed
MyEJB myEjbInstance = (MyEJB) context.lookup("ejb/MyEJB");
Or, of course, you can inject it:
#EJB
private MyEJB myEjbInstance;
To make the naming context work, you must run your application as a Java EE application client. An application client is exactly like a regular standalone Java program, with a standard main method; the only difference is that it needs to be run in a different manner. That manner is not specified in the Java EE Spec, so each application server has its own way of doing it.
GlassFish, for example, requires an application client to include some special jars in the classpath, and set a couple system properties. Specifically, you must include lib/gf-installer.jar and all the jars referenced by its manifest in your classpath, and you must set the org.omg.CORBA.ORBInitialHost and org.omg.CORBA.ORBInitialPort system properties.
I want to configure a self-written JCA 1.6 inbound resource adapter (RA). My big problem is that the RA needs to get access to some (dynamic) configuration data living in the application that uses the RA.
Now I know that this is against the original idea of the whole JCA idea but unfortunately I cannot change this design as quickly as I'd like/have to.
The data I need to get to the RA is
the port it's supposed to listen on,
the license used for the whole application (the feature the RA supplies requires extra licensing)
additional configuration data stored in a db
I've come up with four ideas:
Use the asadmin create-resource-adapter-config. Due to the fact that glassfish doesn't seem to restart apps depending on the RA, we need to restart the application after this. While this attempt is suitable for the port, it won't fit for the other data.
Use administered objects to give my application a means to pass data in to the RA. This idea is mentioned here. I guess this does it, but the spec states in chapter 13.4.2.3 that
Note, administered objects are not used for setting up asynchronous message
deliveries to message endpoints. The ActivationSpec JavaBean is used to hold all
the necessary activation information needed for asynchronous message delivery
setup.
But I cannot get any dynamic data to the ActivationSpec object (neither through a DeploymentDescriptor nor through annotations). Or did I miss something here? :-)
Use JDBC directly to access the data (also grabbed the idea from here). While this is presumably the best idea, it does not work for the mentioned licensing data as it is not stored in the db.
The last idea I had was to put a method in the MessageDrivenBean (through my interface) that is used to fetch data from within the RA. That method could be called from the RA and would supply the data. But: I just think that is quite abusive as it couples the RA to the app.
Dear community, what are your thoughts on this one? I'm afraid it's not so easy to find answers to these questions, so I'd be quite happy about opinions!
Thanks and cheers,
Julius
In the ra.xml there is the possibility to define config-properties. In Websphere these then show up as editable fields in a table of custom properties for the selected resource adapter. I'm working on a similar problem, I also need to pass hostname / port info to an RA. Unfortunately I haven't figured out how to read the contents of these fields from within the RA however.
The solution I finally came up with is to use the #ConfigProperty annotation. This means I use option one of my question above.
So my ResourceAdapter class looks like this:
public class Hl7ResourceAdapter implements ResourceAdapter {
#ConfigProperty
private Integer port = null;
// Rest from ResourceAdapter interface omitted here...
// Use port here to open socket...
}
The #ConfigProperty fields can now be set through either
a resource-adapter-config
the ra.xml deployment descriptor
Now in order to reconfigure these settings I use glassfish's REST interface to change these settings programmatically (one could also use the asadmin create-resource-adapter-config command). I circumvent the problem, that glassfish does not restart the application that uses the resource adapter by simply restarting it myself through REST. (To be precise: I disable the application and then reenable it to get around another bug in glassfish)
A few additional notes:
We deploy the resource adapter's .rar file into the .ear of the application using it.
We have a separate application outside glassfish (standalone) that calls the REST interface to do such things as restart the resource adapter application etc. It is obvious that an application cannot restart itself properly.
Hope this helps. kutuzof, will this get you any further?