The API tool is very good and useful for documentation, but is rarely accessed. Yet causes very slow start ups.

With ApiTool:

[2018-07-23 15:09:40,081]-[main] INFO c.z.s.App - [local@netty]: Server started in 34232ms

Without ApiTool:

[2018-07-23 15:10:09,926]-[main] INFO c.z.s.App - [local@netty]: Server started in 2860ms

We looked into running the maven apitool but we can't configure it, and also has some issues.

com.fasterxml.jackson.databind.JsonMappingException: Index: 0, Size: 0 (through reference chain: java.util.ArrayList[5]->org.jooby.apitool.RouteMethod["response"]->org.jooby.apitool.RouteResponse["type"])
	at com.fasterxml.jackson.databind.JsonMappingException.wrapWithPath(JsonMappingException.java:391)
	at com.fasterxml.jackson.databind.JsonMappingException.wrapWithPath(JsonMappingException.java:351)
	at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.wrapAndThrow(BeanDeserializerBase.java:1711)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:290)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:151)
	at com.fasterxml.jackson.databind.deser.impl.FieldProperty.deserializeAndSet(FieldProperty.java:136)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:288)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:151)
	at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:286)
	at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:245)
	at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:27)
	at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4013)
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2985)
	at org.jooby.internal.apitool.BytecodeRouteParser.read(BytecodeRouteParser.java:364)
	at org.jooby.internal.apitool.BytecodeRouteParser.lambdas(BytecodeRouteParser.java:595)
	at org.jooby.internal.apitool.BytecodeRouteParser.parse(BytecodeRouteParser.java:397)
	at org.jooby.apitool.ApiParser.parse(ApiParser.java:295)
	at org.jooby.apitool.ApiParser.parseFully(ApiParser.java:310)
	at org.jooby.internal.apitool.APIProvider.<init>(APIProvider.java:225)
	at org.jooby.internal.apitool.APIProvider$$FastClassByGuice$$9b325895.newInstance(<generated>)
	at com.google.inject.internal.DefaultConstructionProxyFactory$FastClassProxy.newInstance(DefaultConstructionProxyFactory.java:89)
	at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:114)
	at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:91)
	at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:306)
	at com.google.inject.internal.BoundProviderFactory.get(BoundProviderFactory.java:60)
	at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
	at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:148)
	at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:39)
	at com.google.inject.internal.InternalInjectorCreator.loadEagerSingletons(InternalInjectorCreator.java:211)
	at com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:182)
	at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:109)
	at com.google.inject.Guice.createInjector(Guice.java:87)
	at com.google.inject.Guice.createInjector(Guice.java:78)
	at org.jooby.Jooby.lambda$new$0(Jooby.java:885)
	at org.jooby.Jooby.bootstrap(Jooby.java:2996)
	at org.jooby.Jooby.start(Jooby.java:2197)
	at org.jooby.Jooby.start(Jooby.java:2178)
	at org.jooby.Jooby.run(Jooby.java:2107)
	at co.zeekit.server.App.main(App.java:296)
Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
	at java.util.ArrayList.rangeCheck(ArrayList.java:657)
	at java.util.ArrayList.get(ArrayList.java:433)
	at org.jooby.internal.apitool.TypeJsonDeserializer.deserialize(TypeJsonDeserializer.java:226)
	at org.jooby.internal.apitool.TypeJsonDeserializer.deserialize(TypeJsonDeserializer.java:217)
	at com.fasterxml.jackson.databind.deser.impl.FieldProperty.deserializeAndSet(FieldProperty.java:136)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:288)
	... 35 common frames omitted

Process finished with exit code 130 (interrupted by signal 2: SIGINT)

jooby 2

After a long consideration of existing implementation, ideas described in #926, evaluation of new frameworks (specially from Go but also http4k)... found some time to draw what and how Jooby 2 is going to look and work.

As always, your feedback is welcome.

design

• Single Context object replaces Request and Response
• Route Handler is now a function (returns a value)
• Filter is now a function and they are not tied to a route pattern. They are group and composed using as functions
• Route chain/pipeline replaced by functional filter
• Run code in the IO Thread
• Router algorithm now matches a single Handler. We can't add multiple handlers to same route
• No more greedy Ant path pattern: **
• There will be a clear difference between query, path and form parameters. Must get rid of the generic Request.param(String) method
• Root package will be io.jooby
• Remove DI/Guice from core

contracts

interface Context {
  //... merge of Request/Response objects from 1.x
}

interface Handler {
  Object apply(Context ctx);
}

interface Filter {
  Handler apply(Handler next);

  default Filter then(Filter next) {
    return h -> apply(next.apply(h));
  }

  default Handler then(Handler next) {
    return ctx -> apply(next).apply(ctx);
  }
}

interface Router {

  Handler match(String method, String path);

  //.. usual router methods
}

examples

HelloWorld

{
  get("/", ctx -> "Hello world!");
}

Nothing new, except we replaced the (Request, Response) signature by (Context)

Filter

{
  /** Timing filter: */
  filter(next -> {
    return ctx -> {
      long start = System.currentTimeMillis();
      Object response = next.apply(ctx);
      long end = System.currentTimeMillis();
      System.out.println("Took: " + (end - start));
      return response;
    };
  });

  get("/", ctx -> "Hello world!");
}

Here the timing filter applies to all the route defined bellow it.

Filters are not tied to a path pattern anymore, the Route.Chain was replaced by a function composition.

Scoped Filter

{
  group(() -> {
    /** JWT auth filter: */
    filter(new JWTToken());

    get("/api/pets", ctx -> ...);
  });
}

Here the JWT filter applies to all the route defined below which are wrapped by group operator.

unit tests

As expected unit test will be easily to write due we use a functional approach:

@Test
public void easyTest() {
   Context ctx = mock();
   Router router = ...;
   Handler handler = router.match("/");
   Object response = handler.apply(ctx);
   assertEquals("Hello world!", response);
}

path pattern

We are going to remove the greedy Ant path pattern, so patterns like:

• '/foo/**'
• '/foo/**/bar'

won't work any more

The new router algorithm will be a port of go-chi

thread model

We are going to keep the worker thread as default execution mode, also going to allow to execute a route in the IO thread:

{
    mode(Mode.IO); // Default is WORKER

    worker(ForkJoinPool.commonPool()); // Set a default worker or Fallback to `server` worker executor

    get("/", ctx -> "from IO thread");

    dispatch(() -> {
      get("/default-worker", ctx -> "from worker thread"); // Run with default worker executor
    });

    dispatch(executor, () -> {
      get("/executor", ctx -> "from custom executor thread"); // Run with a custom executor
    });
}

Filters are going run properly (not like in 1.x where they are ignored #996)

Just a quick preview of what is coming in 2.x

As always, your feedback is welcome.

How can I resolve this?

✦ ➜ ./gradlew joobyRun
> Task :kaptGenerateStubsKotlin UP-TO-DATE
> Task :kaptKotlin UP-TO-DATE
> Task :compileKotlin UP-TO-DATE
> Task :compileJava NO-SOURCE
> Task :processResources NO-SOURCE
> Task :classes UP-TO-DATE
> Task :joobyRun FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':joobyRun'.
> /Users/max/Library/Caches/JNA/temp/jna7013481395428920527.tmp: dlopen(/Users/max/Library/Caches/JNA/temp/jna7013481395428920527.tmp, 1): no suitable image found.  Did find:
  	/Users/max/Library/Caches/JNA/temp/jna7013481395428920527.tmp: no matching architecture in universal wrapper
  	/Users/max/Library/Caches/JNA/temp/jna7013481395428920527.tmp: no matching architecture in universal wrapper

With gradle the LiveReload throws the following exception:

C:\dev\sandbox\joobytest\my-app>gradlew joobyRun
:compileJava UP-TO-DATE
:processResources NO-SOURCE
:classes UP-TO-DATE
:joobyRun
>>> jooby:run[info|Daemon worker Thread 2]: Hotswap available on: [C:\dev\sandbox\joobytest\my-app]
>>> jooby:run[info|Daemon worker Thread 2]:   includes: [**/*.class;**/*.conf;**/*.properties;**/*.html]
>>> jooby:run[info|Daemon worker Thread 2]:   excludes: []
[2017-08-02 14:18:29,019]-[HotSwap] INFO  com.mycompany.App - Stopped
[2017-08-02 14:18:29,024]-[HotSwap] ERROR com.mycompany.App - An error occurred while starting the application:
com.google.inject.CreationException: Unable to create injector, see the following errors:

1) No implementation for java.util.Set<org.jooby.filewatcher.FileEventOptions> was bound.
  while locating java.util.Set<org.jooby.filewatcher.FileEventOptions>
    for the 4th parameter of org.jooby.filewatcher.FileMonitor.<init>(FileMonitor.java:252)
  at org.jooby.filewatcher.FileWatcher.configure(FileWatcher.java:540)

1 error
        at com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:470)
        at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
        at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
        at com.google.inject.Guice.createInjector(Guice.java:99)
        at com.google.inject.Guice.createInjector(Guice.java:84)
        at org.jooby.Jooby.lambda$new$0(Jooby.java:884)
        at org.jooby.Jooby.bootstrap(Jooby.java:2948)
        at org.jooby.Jooby.start(Jooby.java:2161)
        at org.jooby.Jooby.start(Jooby.java:2142)
        at org.jooby.Jooby.run(Jooby.java:2072)
        at com.mycompany.App.main(App.java:20)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jooby.run.Main.lambda$startApp$1(Main.java:427)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
>>> jooby:run[error|HotSwap]: com.mycompany.App.start() resulted in error
java.lang.NullPointerException
        at org.jooby.run.Main.lambda$startApp$1(Main.java:432)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

Example Project: https://github.com/JStumpp/jooby-gradle-livereload

We use another maven annotation processor to create immutable data classes (https://immutables.github.io/). When we define these immutable classes inside the same maven module as Jooby, it appears that the MVC processor doesn't generated an import for the jooby generated module class. At runtime, this gives us a NoClassDefFoundError.

Interestingly, if our generated data classes are in a different module, Jooby is properly able to create import statements.

For example public SourceConnectionTestResult testSource(SourceConnectionTestRequest testRequest) a resource defined like this (both the argument and return are immutables generated classes) ends up generating a module

that looks like

var2 = app.post("/source/test", (ctx) -> {
      SourceResource var2 = (SourceResource)provider.get();
      return var2.testSource((SourceConnectionTestRequest)ctx.body(SourceConnectionTestRequest.class));
    });
    var2.setReturnType(SourceConnectionTestResult.class);

While this code is correct, the class doesn't have any import statements for SourceConnectionTestResult or SourceConnectionTestRequest.

I played around with different package configurations, and that doesn't seem to change the error.

My naive guess here is that there's a race/ordering issue with both of these annotation processors running in the same maven module.

hello, I have set according to the documentation

<plugin>
			<artifactId>maven-compiler-plugin</artifactId>
			<version>3.8.1</version>
			<configuration>
				<forceJavacCompilerUse>true</forceJavacCompilerUse>
				<!-- 
				<compilerArgs>
					<arg>-parameters</arg>
				</compilerArgs> 
				-->
				<annotationProcessorPaths>
					<path>
					    <groupId>org.projectlombok</groupId>
					    <artifactId>lombok</artifactId>
					    <version>1.18.12</version>
					</path>
					<path>
						<groupId>io.jooby</groupId>
						<artifactId>jooby-apt</artifactId>
						<version>2.8.1</version>
					</path>
				</annotationProcessorPaths>
			</configuration>
		</plugin>
		<plugin>
			<groupId>io.jooby</groupId>
			<artifactId>jooby-maven-plugin</artifactId>
			<version>2.8.1</version>
			<configuration>
				<mainClass>${application.class}</mainClass>
				<restartExtensions>conf,properties,class</restartExtensions>
				<compileExtensions>java,kt</compileExtensions>
				<port>8080</port>
			</configuration>
		</plugin>

But after I modified the code Console output error

io.jooby.Usage: Router not found: cn.ef.modules.sys.action.DownloadAct. Make sure Jooby annotation processor is configured properly. For more details, please visit: https://jooby.io/usage#annotation-processing-tool-router-not-found at io.jooby.Usage.apt (Usage.java:62) at io.jooby.Usage.mvcRouterNotFound (Usage.java:41) at io.jooby.Jooby.lambda$null$3 (Jooby.java:323) at java.util.Optional.orElseThrow (Optional.java:290) at io.jooby.Jooby.lambda$mvc$4 (Jooby.java:323) at java.util.Optional.orElseGet (Optional.java:267) at io.jooby.Jooby.mvc (Jooby.java:320) at io.jooby.Jooby.mvc (Jooby.java:310)

Hello, check this out:

I get this exception when I try to use the RAML module with MVC routes:

java.lang.ClassCastException: sun.reflect.generics.reflectiveObjects.WildcardTypeImpl cannot be cast to java.lang.Class

This is how I'm using:

new Raml().install(this);

I've also tried like this:

new Raml().filter(routeSpec -> routeSpec.pattern().startsWith("/user")).install(this);

To no avail.

Do you know what I might be doing wrong?

Thanks

No sure if I'm simply not finding it in the docs, but async request processing would be great. If Jooby had support for async and modules for ebean and akka I know a lot of folks that would be happy dropping the playframework.

It may actually be compatible/possible in the V1.2x codebase, but seeing as V2 is being designed here is what I'd love to see in Jooby:

Demo of decomposition of Jooby application that includes 'domains' and 'directories'

That demo's repo showing tracing output from the running of that representative Jooby application

What the demo is showcasing is the nesting of directories and a Jooby app serving two domains (through a single 80/443 port):

1. dir(..) and Dir is similar to the existing path, but implicitly directories are bounded by '/' chars in URLs.

2. domain(..) and Domain are not currently modeled in Jooby.

Another difference is that the instead of Runnable (as in path(str, Runnable)), there is JoobyComponent (would implement most of the methods of DSL Jooby today).

We just released pac4j v1.8 and as Jooby uses it for authentication, it should be upgraded.

pac4j v1.8 is a major version as it is now a full security engine and not only an authentication one for Facebook, Twitter...: it now supports REST/web services as well as authorizations. Which allows implementations (like jooby-pac4j) to become full security libraries. Configuration can now be handled at the pac4j level (-> https://github.com/pac4j/pac4j/tree/master/pac4j-core/src/main/java/org/pac4j/core/config) as well as profile storage (-> https://github.com/pac4j/pac4j/blob/master/pac4j-core/src/main/java/org/pac4j/core/profile/ProfileManager.java).

The idea with pac4j v1.8 is not only to have implementations which are close, but to provide guidelines on how to implement pac4j and have the same algorithm implemented for all frameworks/tools, making evolutions and adoption easier.

If you read: https://github.com/pac4j/pac4j,

There are now two kinds of clients (= authentication mechanims):

• indirect / stateful clients are for UI when the user authenticates once at an external provider (like Facebook, a CAS server...) or via a local form (or basic auth popup)
• direct / stateless clients are for web services when credentials (like basic auth, tokens...) are passed for each HTTP request.

To define your security configuration, gather all your authentication mechanisms = clients via the Clients class (to share the same callback url). Also define your authorizers to check authorizations and aggregate both (clients and authorizers) on the Config. Notice you may also use the ConfigSingleton object to keep one instance of your configuration and share it among the different components (if you don't have any dependency injection capability). You can also use the ConfigFactory to build you configuration if no other mean is available.

To secure your Java web application, the reference implementation is to create two "filters": one to protect urls, the other one to receive callbacks for stateful authentication processes (indirect clients):

1. For your protection "filter", it must be based on two String parameters: clientName (list of clients used for authentication) and authorizerName (list of authorizers to check authorizations) and use the following logic: loop on direct clients for authentication then check the user profile and authorizations
2. For your callback "filter", get the credentials and the user profile on the callback url.

We moved things really far as you can see that both implementations between J2E and Play for example are very very close: https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L91 vs https://github.com/pac4j/play-pac4j/blob/master/play-pac4j-java/src/main/java/org/pac4j/play/java/RequiresAuthenticationAction.java#L95.

Even the README are organized the same way with the same texts for common parts. The associated demos have been upgraded and that should be done for: https://github.com/pac4j/jooby-pac4j-demo as well. The README of the demo can be copy/pasted from the one for J2E and updated. There is even a specific logo for the jooby-pac4j implementation: https://pac4j.github.io/pac4j/img/logo-jooby.png which should appear at the top of the README demo and of the implementation documentation: http://jooby.org/doc/pac4j/

If you have any question or need any help, don't hesitate.

Again me bringing a OpenAPI issue (I have to apologize for it!)...

It seems that when I have this: mvc(UserSettingsController())

openAPI correctly parses and displays the results.

However if I have this:

routes {
        decorator(RequireRole(StaffRole, CustomerRole))
        mvc(UserSettingsController())
    }

than openAPI will not show anything. The perpetrator here is the routes{} scoping. I need it since different routes have different decorators, but I also realized that removing it does give me my docs back.

Maybe someone can help

• Rename Context.attribute(String) => Context.getAttribute(String)
• Rename Context.attribute(String, Object) => Context.setAttribute(String, Object)
• Merge Context.multipart into Context.form. So, Context.multipart related methods will be removed and replaced with Context.form methods.

Bumps flyway-core from 9.10.2 to 9.11.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps swagger.version from 2.2.7 to 2.2.8. Updates swagger-annotations from 2.2.7 to 2.2.8

Updates swagger-models from 2.2.7 to 2.2.8

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps fluent-hc from 4.5.13 to 4.5.14.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps rest-assured from 5.2.0 to 5.3.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps compile-testing from 0.19 to 0.21.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.