I'm new to Dropwizard. In the newest documentation, it refers to "Service" as the main entry point of any application. But in the example code, it actually uses "Application". I'm assuming that "Application" is a new name for "Service", since I can't find "Service" in the new source code.
I also noticed that the namespace has changed from "com.yammer" to "com.codehaus" to "io.dropwizard". I'm assuming it reflects the evolution of the project itself. Just out of curiosity, can anyone add some context to how this came about?
Both the naming changes you cited are actually changes for the upcoming Version 0.7. The documentation isn't up-to-date yet (and is actually the main thing holding back the 0.7 release according to the mailing list).
The current release notes can be found in the master branch.
Upgraded to Java 7.
Moved to the io.dropwizard group ID and namespace.
Extracted out a number of reusable libraries: dropwizard-configuration,
dropwizard-jackson, dropwizard-jersey, dropwizard-jetty, dropwizard-lifecycle,
dropwizard-logging, dropwizard-servlets, dropwizard-util, dropwizard-validation.
Extracted out various elements of Environment to separate classes: JerseyEnvironment,
LifecycleEnvironment, etc.
Extracted out dropwizard-views-freemarker and dropwizard-views-mustache.
dropwizard-views just provides infrastructure now.
Renamed Service to Application.
Added dropwizard-forms, which provides support for multipart MIME entities.
Added dropwizard-spdy.
Added AppenderFactory, allowing for arbitrary logging appenders for application and request
logs.
Added ConnectorFactory, allowing for arbitrary Jetty connectors.
Added ServerFactory, with multi- and single-connector implementations.
Added ReporterFactory, for metrics reporters, with Graphite and Ganglia implementations.
Added ConfigurationSourceProvider to allow loading configuration files from sources other than
the filesystem.
Added setuid support. Configure the user/group to run as and soft/hard open file limits in the
ServerFactory. To bind to privileged ports (e.g. 80), enable startAsRoot and set user
and group, then start your application as the root user.
Added builders for managed executors.
Added a default check command, which loads and validates the service configuration.
Added support for the Jetty HTTP client to dropwizard-client.
Added Jackson Afterburner support.
Added support for deflate-encoded requests and responses.
Added support for HTTP Sessions. Add the annotated parameter to your resource method:
#Session HttpSession session to have the session context injected.
Added support for a "flash" message to be propagated across requests. Add the annotated parameter
to your resource method: #Session Flash message to have any existing flash message injected.
Added support for deserializing Java enums with fuzzy matching rules (i.e., whitespace
stripping, -/_ equivalence, case insensitivity, etc.).
Added HibernateBundle#configure(Configuration) for customization of Hibernate configuration.
Added support for Joda Time DateTime arguments and results when using JDBI.
Added configuration option to include Exception stack-traces when logging to syslog. Stack traces
are now excluded by default.
Added the application name and PID (if detectable) to the beginning of syslog messages, as is the
convention.
Added --migrations-file command-line option to migrate command to supply the migrations
file explicitly.
Validation errors are now returned as application/json responses.
Simplified AsyncRequestLog; now standardized on Jetty 9 NCSA format.
Renamed DatabaseConfiguration to DataSourceFactory, and ConfigurationStrategy to
DatabaseConfiguration.
Changed logging to be asynchronous. Messages are now buffered and batched in-memory before being
delivered to the configured appender(s).
Changed handling of runtime configuration errors. Will no longer display an Exception stack-trace
and will present a more useful description of the problem, including suggestions when appropriate.
Changed error handling to depend more heavily on Jersey exception mapping.
Changed dropwizard-db to use tomcat-jdbc instead of tomcat-dbcp.
Changed default formatting when logging nested Exceptions to display the root-cause first.
Replaced ResourceTest with ResourceTestRule, a JUnit TestRule.
Dropped Scala support.
Dropped ManagedSessionFactory.
Dropped ObjectMapperFactory; use ObjectMapper instead.
Dropped Validator; use javax.validation.Validator instead.
Fixed a shutdown bug in dropwizard-migrations.
Fixed formatting of "Caused by" lines not being prefixed when logging nested Exceptions.
Fixed not all available Jersey endpoints were being logged at startup.
Upgraded to argparse4j 0.4.1.
Upgraded to Guava 15.
Upgraded to Hibernate Validator 5.0.1.
Upgraded to Jackson 2.2.3.
Upgraded to JDBI 2.50.
Upgraded to Jetty 9.0.5.
Upgraded to Liquibase 3.0.4.
Upgraded to Logback 1.0.13.
Upgraded to Metrics 3.0.1.
Upgraded to Mustache 0.8.13.
Upgraded to SLF4J 1.7.5.
Related
I am running into the follow error while upgrading my versions of Jetty for a Dropwizard project:
java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.eclipse.jetty.util.ssl.SslContextFactory. (Use org.eclipse.jetty.util.ssl.SslContextFactory$Server or org.eclipse.jetty.util.ssl.SslContextFactory$Client instead)
The tricky part is that I do not directly set up my SslContextFactory in code. Instead, Dropwizard sets it up behind the scenes at application startup, where it quickly runs into this issue and fails.
I see from the Dropwizard documentation that certain environment variables can be set on the Jetty server that it spins up, but I do not see documentation on how to modify specific classes.
If I add a jetty.xml file within $JETTY_HOME$/etc/config, will Dropwizard know how to pick this up?
I just need to understand how Dropwizard picks up settings on Jetty so I can use SslContextFactory.Server and resolve this error at startup.
Your version of Dropwizard is too old.
Dropwizard properly uses the SslContextFactory.Server where appropriate.
I try to increase ejb transaction timeout in WildFly.
There are 3 options to do it:
via standalone-full.xml file, affects all components globally
via #org.jboss.ejb3.annotation.TransactionTimeout wildfly specific annotation. Requires code changes.
via jboss-ejb3.xml file.
The last option does not work with Wilfly 10. The example could be taken from Specification of Transaction Timeout in the Deployment Descriptor
The problem is that the documentation belongs to version 9. Beginning from WF 10, I do not see this timeout-specific section in Wilfly 10 jboss-ejb3.xml Reference
Also existing examples refers to transaction xsd schema, but it does not exist anymore, see jboss xsd existing schemas.
In the github repo it could be found: github transaction xsd schema
Does this ability to control transaction with the option #3 still exists? Or what do I miss with it?
I have a SpringBoot 2 app that uses using Spring Data Couchbase.
I have this message on the logs every minute
2019-11-12 13:48:48,924 WARN : gid: trace= span= [cb-orphan-1] c.c.c.c.t.DefaultOrphanResponseReporter Orphan responses observed: [{"top":[{"r":"10.120.93.220:8092","s":"view","c":"5BE128F6F96A4D28/FFFFFFFFDA2C8C52","l":"10.125.216.233:49893"}],"service":"view","count":1}]
That is from the new Response Time Observability feature underlying the Java SDK.
It would seem to indicate that you have view requests which are timing out, but eventually received later, but I have no views defined in Couchbase DB
I would like to know if it is possible to disable OrphanResponseLogReporter via YML file config in a SpringBoot app. , setting the logIntervalNanos to 0
No, unfortunately, you cannot do it. Only a subset of Couchbase's configuration properties is supported in the application.yml, namely the ones present in the CouchbaseProperties.java class.
You could although use an environment variable: com.couchbase.orphanResponseReportingEnabled=false. It is independent of Spring, it's read directly by Couchbase SDK.
Edit:
As a workaround, you can set logging level in the application.yml:
logging.level.com.couchbase.client.core.tracing.DefaultOrphanResponseReporter: ERROR
While it's well known that Websphere's JAX-WS implementation is based on Axis2, I have had trouble finding information how to set "scope" for the service.
In axis 2 scope can be defined using services.xml. Is this file also available in Websphere?
http://axis.apache.org/axis2/java/core/docs/axis2config.html
scope: (Optional Attribute) The time period during which runtime information of the deployed services will be available. Scope is of several types- "application", "soapsession", "transportsession", "request". The default value (if you don't enter any value) will be "request"
It seems it is possible to do what you want in WebSphere (not using services.xml):
Configuring the scope of a Web service port using wsadmin scripting
Did not try it myself, also, could not find such settings in the admin console or deployment descriptor of some kind but that might be possible as well.
Enviroment: JSF 2.0, RichFaces 3.3.3, Facelets 1.1.15B1, Spring Framework 3.x, WebFlow 2.1, MyBatis 3.0.1, Oracle 10/11 g backend, SLF4j into Log4j. Well thats probably TMI since my issue is only a logging problem but better to be too thorough than not.
Anyways... I just setup SLF4j & log4j so now all of the internal facelets log msgs are being dumped into log4j & I can actually see them. In addition I setup Tomcat to also dump to log4j instead of it's custom version of JULI. Upon doing this everything appeared to be working great.... until i shut down the app.
Midway through the shutdown process my app started barfing up errors left 'n right because (which makes sense) Tomcat is trying to grab a logger instance AFTER spring has already cleaned up the logger bean.
Anyone familiar with this? I imagine it must be a common problem for anyone who has Tomcat using the non-standard logging mechanism. What is the best way around this?
I thought maybe if I just raised the log level then Tomcat wouldn't even try to log msgs because of the level req.s but the problem occurs when tomcat is trying to retrieve a logger instance so that didn't work.
I would move the Logger higher in the food chain.
I personally never configured log4j with spring relying on its own configuration mechanism (and hunting for where the heck it finds the properties file it is using in the process).
If you can you can opt to completely remove log4j from your war and rely on the log4j in the common tomcat library classpath. Then of course you are at the mercy of the tomcat configuration and you cannot access the log from inside your app, but it is always there during the complete lifecycle of your app.