We Keep Coding

Why is javax.json from Glassfish needed as a dependency when using Yasson with JSON-B?

In order to use Java API for JSON Binding (JSON-B), I have found it necessary to include the following three dependencies in my Maven POM:
<!-- https://mvnrepository.com/artifact/jakarta.json.bind/jakarta.json.bind-api -->
<dependency>
<groupId>jakarta.json.bind</groupId>
<artifactId>jakarta.json.bind-api</artifactId>
<version>1.0.1</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.eclipse/yasson -->
<dependency>
<groupId>org.eclipse</groupId>
<artifactId>yasson</artifactId>
<version>1.0.3</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.glassfish/javax.json -->
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.json</artifactId>
<version>1.1.4</version>
</dependency>
The first two make sense to me.
jakarta.json.bind-api is the JSON-B API defined by JSR 367.
yasson is the reference implementation of that API, Eclipse Yasson.
➥ But what exactly does the third dependency, javax.json from Glassfish, bring to the party? Why is it required for my app to work?
If omitted, when running Jsonb jsonb = JsonbBuilder.create();, I get this error:
javax.json.JsonException: Provider org.glassfish.json.JsonProviderImpl not found
I am confused because I thought Yasson is my JSON processing implementation.

Actually, your code should only depend on the api jakarta.json.bind-api, so you don't accidentally use implementation details from yasson, e.g. the internal org.eclipse.yasson.internal.ReflectionUtils. To do this, you should add <scope>runtime</scope> to your yasson dependency. Only to run it, you need an implementation, and you picked the reference implementation yasson.
But JSON-B is just a layer on top of JSON-P: it does the binding part, while it delegates all the raw JSON processing to JSON-P. You can mix and match any JSON-B implementation with any JSON-P implementation.
As yasson has to be able to work with any JSON-P implementation, it can't have a hard dependency on, e.g., Glassfish JSON-P; you have to specify it yourself (also with a runtime scope). The error message you see mentions Glassfish, as that's the fallback implementation JSON-P is looking for.

Swagger2 - No handler found for GET

I have developed one API in Spring boot. where I used Swagger2 for easiness & technical doc purposefully.
Now, I am running through an issue which is mainly cause on our whole API.
It's Frequently printing a logs. it's around in 1-min. 2-5 MB logs are created. which is absolutely not acceptable. Due to the below mentioned error.
I strongly believe, it's because of Swagger UI configuration. it's appearing.
org.springframework.web.servlet.NoHandlerFoundException: No handler found for GET /null/swagger-resources/configuration/security
org.springframework.web.servlet.NoHandlerFoundException: No handler found for GET /null/swagger-resources
org.springframework.web.servlet.NoHandlerFoundException: No handler found for GET /null/swagger-resources/configuration/ui
I have already configured to bypassed the following endpoints from my "Authentication/Authorization" validation checks.
1. /swagger-ui.html
2. /v2/api-docs
3. /swagger-resources/configuration/ui
4. /swagger-resources
5. /swagger-resources/configuration/security
Question is, why it's internally calls endpoints which are starting with /null prefix(see the above mentioned 3-erroneous statements which are printing in my logs)
Surplice! & Interesting! things for me is, it's happening(causing) in only one of my environment(DEV, TEST, PROD). Whereas in other environment, it works very well without throwing any such kind of errors.
NOTE - I have enabled swagger only in DEV & LOCAL env. only. May be due to this reason, it's not giving any error in TEST & PROD respectively. Again I am not sure what's wrong going on.
Even, In my Local also not giving any errors!
I am using following maven dependencies to enable swagger are,
<!-- https://mvnrepository.com/artifact/io.springfox/springfox-swagger2 -->
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-swagger2</artifactId>
<version>2.8.0</version>
</dependency>
<!-- https://mvnrepository.com/artifact/io.springfox/springfox-swagger-ui -->
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-swagger-ui</artifactId>
<version>2.8.0</version>
</dependency>
Any help would be appreciable!!

Upgrading to swagger 3 solved the problem for me. This link might be useful.

Dropwizard as a non blocking task execution component

I'm in the process of evaluating dropwizard for a mission critical component of our production system.
What I need to implement is a command line tool with RESTful support(there is little need to provide REST API, I need mostly to communicate with external API systems for B2B), logging dependency injection and some short of non blocking I/O operations for maximum performance.
My question is if someone has experience with the particular framwork being ready for a production system and some alternative solutions of a lightweight non blocking operations (Something like Celery on Python)
Finally, does Dropwizard supports java 1.8?
Many thanks for the help in advance

dropwizard-sundial lets you schedule jobs in dropwizard. The github README has more sample but here's a quick sneak peak:
#CronTrigger(cron = "0/5 * * * * ?")
public class SampleJob extends org.knowm.sundial.Job {
#Override
public void doRun() throws JobInterruptException {
// Do something interesting...
}
}
What it does is at the time of initializing your dropwizard application, sundial will drop in and start its scheduler. Then you can configure tasks via package in yaml, tasks, xml. Also the admin task it registed could be used to manage jobs (create/trigger/etc).
One thing to notice is that dropwizard-sundial package itself includes a set of dropwizard-core and dropwizard-util. Very likely you'll find it conflicts with the version which would cause NoClassDefException or NoMethodFoundException. My solution is to exclude from dropwizard-sundial and use your own one.
<dependency>
<groupId>org.knowm</groupId>
<artifactId>dropwizard-sundial</artifactId>
<version>1.0.0.0</version>
<exclusions>
<exclusion>
<groupId>io.dropwizard</groupId>
<artifactId>dropwizard-core</artifactId>
</exclusion>
<exclusion>
<groupId>io.dropwizard</groupId>
<artifactId>dropwizard-util</artifactId>
</exclusion>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-server</artifactId>
</exclusion>
</exclusions>
</dependency>

Does anyone know a Jersey client proxy implementation like Apache CXF offers for REST

the Apache CXF project offers a proxy based client implementation for REST services. This looks like:
Resource resource = JAXRSClientFactory.create( baseAddress, Resource.class )
Does anyone know a similar implementation for Jersey?
I spotted an approach using #HyperMediaController annotations, but I want to stick to JSR-311 default annotations like #Path and #Get ...
Has anyone an idea?

A proxy implementation exists, but unfortunately it's not even mentioned in Jersey Client API documentation (neither in Jersey User Guide) as of version 2.22.1.
What I found was JavaDoc for WebResourceFactory, even better is the package JavaDoc. Here's a snippet from the JavaDoc on the usage of the WebResourceFactory:
Client client = ClientBuilder.newClient();
WebTarget target = client.target("http://localhost:8080/");
MyResourceIfc resource = WebResourceFactory.newResource(MyResourceIfc.class, target);
In Maven you then need:
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-proxy-client</artifactId>
<version>2.22.1</version>
</dependency>
in addition to
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>2.22.1</version>
</dependency>

I found WebResourceFactory miss generic types supports and it's source code was really hard to understand. So we created https://github.com/adaptris/jaxrs-client-proxy and we are currently devloping it.
To use it you need to build a resource:
ResourceBuilder builder = new ResourceBuilder();
resource = builder.
url("https://host/api").
build(Resource.class);
client = resource.get();
Then you can call client - which is proxy of your jax-rs annotation described interface (Resource.class). You should close a resource after stoping using it as it is recommended by jax-rs client api.
resource.close()
More details on github projet page.

I created an own implementation. See utils-apl-derived wiki page therefore.

Is there a lightweight standalone SOAP server? Or how would you implement one?

The challenge here is that I need to implement a highly concurrent and dynamic system that is based on SOAP communication - in Java. It can be viewed as a multi-agent system where an agent is a software process (like a daemon) that responds to SOAP requests. At runtime my system may comprise more than a thousand of such agents - each of which bound to its own dedicated port, offering the exact same service/interface. Thus, implementing it as a Tomcat servlet or similar is a way to heavy.
For my first try I built a simple HTTP-Server and tried to implement SOAP message handling on top. But I didn't want to re-invent the wheel, especially since that Simple Object Access Protocol is actually not that simple. Unfortunately, most solutions for Java are based on Jax-WS and require a tomcat or other server environment to run (as far as I understood).
Then I had a look at the axis library (awesome). It even comes with a SimpleAxisServer module which does exactly what I want. It runs as a very light-weight standalone SOAP server, and deploying a SOAP service is done very easily. But... here comes the problem:
The SimpleAxisServer is meant for development and debugging purposes only and it is highly discouraged to use it otherwise. Of course, me ignoring those hints started prototyping the system using that module, and ran right into trouble after a few days...
My actual question now is:
Isn't there a ready-made solution for this problem?
Which libraries/classes should I have a look at?

I personally would use Apache CXF. The standalone mode is based on Jetty which is light enough according to my book and Jetty itself is stable and performs well.
import java.util.logging.LogManager;
import javax.xml.ws.Endpoint;
public class MySoapServer {
public static void main(String[] args) {
String serviceAddress = "http://localhost:9099/mysoap";
MyService implementor = new MyServiceImpl();
Endpoint ep = Endpoint.publish(serviceAddress, implementor);
}
}
If you are using Maven (which you really should), add the following to pom.xml:
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>2.4.2</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http</artifactId>
<version>2.4.2</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http-jetty</artifactId>
<version>2.4.2</version>
</dependency>
The service itself will be built with standard JAX-WS annotations.
First create the interface.
import javax.jws.WebService;
#WebService
public interface MyService {
public String hello();
}
And then the implementing class.
import javax.jws.WebService;
#WebService(serviceName="HelloWorld")
public class MyServiceImpl implements MyService {
public String hello() {
return "Hello World!";
}
}
Or you may also use WSDL-first approach if you want to.