quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.

Quarkus - Supersonic Subatomic Java

Quarkus is a Cloud Native, (Linux) Container First framework for writing Java applications.

• Container First: Minimal footprint Java applications optimal for running in containers.
• Cloud Native: Embraces 12 factor architecture in environments like Kubernetes.
• Unify imperative and reactive: Brings under one programming model non-blocking and imperative styles of development.
• Standards-based: Based on the standards and frameworks you love and use (RESTEasy and JAX-RS, Hibernate ORM and JPA, Netty, Eclipse Vert.x, Eclipse MicroProfile, Apache Camel...).
• Microservice First: Brings lightning fast startup time and code turnaround to Java apps.
• Developer Joy: Development centric experience without compromise to bring your amazing apps to life in no time.

All under ONE framework.

Getting Started

• Documentation
• Wiki

Migration Guides

We collect all the migration notes in our migration guides.

Release Planning

Interested in when the next release is coming? Check our release planning document for details.

How to build Quarkus

The build instructions are available in the contribution guide.

quarkus's Issues

shamrock:dev cannot be run in Eclipse

If you have a simple project and follows:

1. Run -> Run Configurations...
2. Right-Click on Maven Build and select new Configuration
3. Give a name to the new configuration (such as Run dev mode)
4. Set the base directory to ${project_loc}
5. In the goals field enter: compile shamrock:dev
6. Click on Run

The application is served correctly.
But:

1. The hot-redeploy does not work (classpath issue)
2. The red button does not stop the process

GraalVM rc7 removed method LocalizationSupport#addToCache

We'll need to figure out a better alternative for Shamrock.

In the meantime when testing things with Graal "master" I've used this additional commit to restore compatibility:

https://github.com/protean-project/graal/commit/581706eb9aaf417646eba6188dbf2eae92d308f0

org.jboss.builder.BasicTests hangs intermittently

graph-output.dot generated at the project root

It should be created in target (or in a sub-directory of target, but not the project root).

Build warnings out of hibernate-protean

[WARNING] 
[WARNING] Some problems were encountered while building the effective model for org.hibernate.protean:hibernate-orm-protean:jar:1.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-source-plugin is missing. @ org.hibernate.protean:hibernate-orm-protean-parent:1.0.0-SNAPSHOT, /home/david/src/java/shamrock/ext/hibernate-protean/pom.xml, line 112, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for org.hibernate.protean:hibernate-orm-protean-example:jar:1.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-source-plugin is missing. @ org.hibernate.protean:hibernate-orm-protean-parent:1.0.0-SNAPSHOT, /home/david/src/java/shamrock/ext/hibernate-protean/pom.xml, line 112, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for org.hibernate.protean:hibernate-orm-protean-parent:pom:1.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-source-plugin is missing. @ line 112, column 21
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING] 

@ConfigProperty should be able to inject primitive fields

When using something like:

    @Inject
    @ConfigProperty(name = "smtp.port", defaultValue = "25")
    public int port;

Caused by: javax.enterprise.inject.UnsatisfiedResolutionException: InjectionPointInfo [requiredType=int, requiredQualifiers=[@ConfigProperty(defaultValue = "25",name = "smtp.port")]] on CLASS bean [types=[org.jboss.shamrock.email.ReactiveEmailService, org.jboss.shamrock.email.impl.ReactiveEmailServiceProvider, java.lang.Object], qualifiers=[@Default, @Any], target=Optional[org.jboss.shamrock.email.impl.ReactiveEmailServiceProvider]]
	at org.jboss.protean.arc.processor.Beans.resolveInjectionPoint(Beans.java:254)
	at org.jboss.protean.arc.processor.BeanInfo.init(BeanInfo.java:312)
	at org.jboss.protean.arc.processor.BeanDeployment.init(BeanDeployment.java:206)
	at org.jboss.protean.arc.processor.BeanProcessor.process(BeanProcessor.java:148)
	at org.jboss.shamrock.arc.deployment.ArcAnnotationProcessor.build(ArcAnnotationProcessor.java:224)
	at org.jboss.shamrock.arc.deployment.ArcAnnotationProcessorBuildStep2.execute(Unknown Source)
	at org.jboss.builder.BuildContext.run(BuildContext.java:401)
	at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1934)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1463)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1354)
	at java.lang.Thread.run(Thread.java:748)
	at org.jboss.threads.JBossThread.run(JBossThread.java:479)

The workaround is to use an Integer:

    @Inject
    @ConfigProperty(name = "smtp.port", defaultValue = "25")
    public Integer port;

Performance regression on RESTEasy 4.0.0.Beta6 upgrade

After upgrading to RESTEasy.4.0.0.Beta6, services using shamrock-rest-client see an increase in heap allocation and cpu pinned at 100% running continuous Full GC's. Application throughput dropped to ~50%

Deleted servlet are still served with shamrock:dev

Reproducer:

1. Create a project
2. Run mvn compile shamrock:dev
3. Create a servlet
4. Check it's served
5. Delete the servlet
6. Servlet is still served, while it should not.

AnnotationsTransformer not used to collect method-level interceptor binding

So it's not possible to add method-level interceptor binding to a business method.

Make the scehduler works in native mode

Right now, I've a build issue:

[INFO]
[INFO] --- shamrock-maven-plugin:1.0.0.Alpha1-SNAPSHOT:native-image (default) @ scheduling-periodic-tasks ---
[INFO] Running Shamrock native-image plugin on Java HotSpot(TM) 64-Bit Server VM
[/Users/clement/Development/graalvm/Contents/Home//bin/native-image, -J-Djava.util.logging.manager=org.jboss.logmanager.LogManager, -J-Dcom.sun.xml.internal.bind.v2.bytecode.ClassTailor.noOptimize=true, -H:InitialCollectionPolicy=com.oracle.svm.core.genscavenge.CollectionPolicy$BySpaceAndTime, -jar, scheduling-periodic-tasks-1.0-SNAPSHOT-runner.jar, -J-Djava.util.concurrent.ForkJoinPool.common.parallelism=1, -H:+PrintAnalysisCallTree, -H:EnableURLProtocols=http, -H:-JNI, --no-server, -H:-UseServiceLoaderFeature, -H:+StackTrace]
[scheduling-periodic-tasks-1.0-SNAPSHOT-runner:48911]    classlist:   3,873.82 ms
[scheduling-periodic-tasks-1.0-SNAPSHOT-runner:48911]        (cap):   1,159.05 ms
[scheduling-periodic-tasks-1.0-SNAPSHOT-runner:48911]        setup:   2,548.52 ms
15:12:26,275 INFO  [o.j.p.arc] ArC DI container initialized [beans=16, observers=1]
15:12:26,359 INFO  [o.j.r.r.i18n] RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.acme.scheduling.ShamrockApplication
15:12:28,228 INFO  [o.xnio] XNIO version 3.6.5.Final
15:12:28,422 INFO  [o.x.nio] XNIO NIO Implementation Version 3.6.5.Final
15:12:30,034 INFO  [o.j.threads] JBoss Threads version 3.0.0.Alpha4
[scheduling-periodic-tasks-1.0-SNAPSHOT-runner:48911]     analysis:  19,894.11 ms
Printing call tree to /Users/clement/Projects/protean/quickstarts/scheduling-periodic-tasks/target/reports/call_tree_scheduling-periodic-tasks-1.0-SNAPSHOT-runner_20181207_151247.txt
Printing list of used classes to /Users/clement/Projects/protean/quickstarts/scheduling-periodic-tasks/target/reports/used_classes_scheduling-periodic-tasks-1.0-SNAPSHOT-runner_20181207_151249.txt
Printing list of used packages to /Users/clement/Projects/protean/quickstarts/scheduling-periodic-tasks/target/reports/used_packages_scheduling-periodic-tasks-1.0-SNAPSHOT-runner_20181207_151249.txt
error: Bytecode parsing error: java.lang.NoClassDefFoundError: javax/transaction/UserTransaction
Detailed message:
Error: Bytecode parsing error: java.lang.NoClassDefFoundError: javax/transaction/UserTransaction
Trace:
        at parsing org.quartz.impl.StdSchedulerFactory.instantiate(StdSchedulerFactory.java:1222)
Call path from entry point to org.quartz.impl.StdSchedulerFactory.instantiate():
        at org.quartz.impl.StdSchedulerFactory.instantiate(StdSchedulerFactory.java:598)
        at org.quartz.impl.StdSchedulerFactory.getScheduler(StdSchedulerFactory.java:1559)
        at org.jboss.shamrock.scheduler.runtime.QuartzScheduler.start(QuartzScheduler.java:142)
        at org.jboss.shamrock.scheduler.runtime.QuartzScheduler_Observer1.notify(Unknown Source)
        at org.jboss.protean.arc.EventImpl$Notifier.notify(EventImpl.java:222)
        at org.jboss.protean.arc.EventImpl.fire(EventImpl.java:85)
        at org.jboss.shamrock.arc.runtime.LifecycleEventRunner.fireShutdownEvent(LifecycleEventRunner.java:45)
        at org.jboss.shamrock.arc.runtime.ArcDeploymentTemplate$5.run(ArcDeploymentTemplate.java:140)
        at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
        at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
        at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:479)
        at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:199)
        at com.oracle.svm.core.code.CEntryPointCallStubs.com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_002epthreadStartRoutine_0028com_002eoracle_002esvm_002ecore_002ethread_002eJavaThreads_0024ThreadStartData_0029(generated:0)
--------------------------------------------------------------------------------------------
-- WARNING: The above stack trace is not a real stack trace, it is a theoretical call tree---
-- If an interface has multiple implementations SVM will just display one potential call  ---
-- path to the interface. This is often meaningless, and what you actually need to know is---
-- the path to the constructor of the object that implements this interface.              ---
-- Shamrock has attempted to generate a more meaningful call flow analysis below          ---
---------------------------------------------------------------------------------------------

Possible path to org.quartz.impl.StdSchedulerFactory.instantiate():o    org.quartz.impl.StdSchedulerFactory.instantiate():o
        org.quartz.impl.StdSchedulerFactory.getScheduler():o
        org.jboss.shamrock.scheduler.runtime.QuartzScheduler.start(org.jboss.shamrock.runtime.StartupEvent):v
This is an implementation of org.jboss.shamrock.scheduler.runtime.QuartzScheduler printing path to constructors of org.jboss.shamrock.scheduler.runtime.QuartzScheduler

Possible path to org.jboss.shamrock.scheduler.runtime.QuartzScheduler.<init>():v        org.jboss.shamrock.scheduler.runtime.QuartzScheduler.<init>():v
        org.jboss.shamrock.scheduler.runtime.QuartzScheduler_ClientProxy.<init>(org.jboss.shamrock.scheduler.runtime.QuartzScheduler_Bean):v
        org.jboss.shamrock.scheduler.runtime.QuartzScheduler_Bean$$function$$17.get():j
This is an implementation of java.util.function.Supplier printing path to constructors of org.jboss.shamrock.scheduler.runtime.QuartzScheduler_Bean$$function$$17

Possible path to org.jboss.shamrock.scheduler.runtime.QuartzScheduler.<init>():v        org.jboss.shamrock.scheduler.runtime.QuartzScheduler.<init>():v
        org.jboss.shamrock.scheduler.runtime.QuartzScheduler_Bean.create(javax.enterprise.context.spi.CreationalContext):o
        org.jboss.shamrock.scheduler.runtime.QuartzScheduler_Bean.create(javax.enterprise.context.spi.CreationalContext):o
        org.jboss.shamrock.scheduler.runtime.QuartzScheduler_Bean.create(javax.enterprise.context.spi.CreationalContext):j
This is an implementation of javax.enterprise.context.spi.Contextual printing path to constructors of org.jboss.shamrock.scheduler.runtime.QuartzScheduler_Bean


Original exception that caused the problem: java.lang.NoClassDefFoundError: javax/transaction/UserTransaction
        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
        at java.lang.Class.getDeclaredMethods(Class.java:1975)
        at jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.toJava(HotSpotResolvedJavaMethodImpl.java:611)
        at jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.getAnnotation(HotSpotResolvedJavaMethodImpl.java:537)
        at com.oracle.svm.hosted.cenum.CEnumCallWrapperSubstitutionProcessor.lookup(CEnumCallWrapperSubstitutionProcessor.java:51)
        at com.oracle.graal.pointsto.infrastructure.SubstitutionProcessor$ChainedSubstitutionProcessor.lookup(SubstitutionProcessor.java:128)
        at com.oracle.graal.pointsto.infrastructure.SubstitutionProcessor$ChainedSubstitutionProcessor.lookup(SubstitutionProcessor.java:128)
        at com.oracle.graal.pointsto.infrastructure.SubstitutionProcessor$ChainedSubstitutionProcessor.lookup(SubstitutionProcessor.java:128)
        at com.oracle.graal.pointsto.infrastructure.SubstitutionProcessor$ChainedSubstitutionProcessor.lookup(SubstitutionProcessor.java:128)
        at com.oracle.graal.pointsto.infrastructure.SubstitutionProcessor$ChainedSubstitutionProcessor.lookup(SubstitutionProcessor.java:128)
        at com.oracle.graal.pointsto.meta.AnalysisUniverse.lookupAllowUnresolved(AnalysisUniverse.java:380)
        at com.oracle.graal.pointsto.infrastructure.WrappedConstantPool.lookupMethod(WrappedConstantPool.java:104)
        at org.graalvm.compiler.java.BytecodeParser.lookupMethod(BytecodeParser.java:3928)
        at org.graalvm.compiler.java.BytecodeParser.genInvokeStatic(BytecodeParser.java:1422)
        at com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.genInvokeStatic(SharedGraphBuilderPhase.java:168)
        at org.graalvm.compiler.java.BytecodeParser.processBytecode(BytecodeParser.java:4868)
        at org.graalvm.compiler.java.BytecodeParser.iterateBytecodesForBlock(BytecodeParser.java:3141)
        at org.graalvm.compiler.java.BytecodeParser.processBlock(BytecodeParser.java:2950)
        at org.graalvm.compiler.java.BytecodeParser.build(BytecodeParser.java:888)
        at org.graalvm.compiler.java.BytecodeParser.buildRootMethod(BytecodeParser.java:782)
        at org.graalvm.compiler.java.GraphBuilderPhase$Instance.run(GraphBuilderPhase.java:95)
        at org.graalvm.compiler.phases.Phase.run(Phase.java:49)
        at org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:197)
        at org.graalvm.compiler.phases.Phase.apply(Phase.java:42)
        at org.graalvm.compiler.phases.Phase.apply(Phase.java:38)
        at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder.parse(MethodTypeFlowBuilder.java:204)
        at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder.apply(MethodTypeFlowBuilder.java:323)
        at com.oracle.graal.pointsto.flow.MethodTypeFlow.doParse(MethodTypeFlow.java:310)
        at com.oracle.graal.pointsto.flow.MethodTypeFlow.ensureParsed(MethodTypeFlow.java:300)
        at com.oracle.graal.pointsto.flow.MethodTypeFlow.addContext(MethodTypeFlow.java:107)
        at com.oracle.graal.pointsto.flow.SpecialInvokeTypeFlow.onObservedUpdate(InvokeTypeFlow.java:421)
        at com.oracle.graal.pointsto.flow.TypeFlow.notifyObservers(TypeFlow.java:347)
        at com.oracle.graal.pointsto.flow.TypeFlow.update(TypeFlow.java:389)
        at com.oracle.graal.pointsto.BigBang$2.run(BigBang.java:508)
        at com.oracle.graal.pointsto.util.CompletionExecutor.lambda$execute$0(CompletionExecutor.java:174)
        at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
        at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
        at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
        at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
        at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
Caused by: java.lang.ClassNotFoundException: javax.transaction.UserTransaction
        at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        ... 41 more

Arc - add basic BeanManager support

Make it possible to use some methods at runtime, such as getBeans() or getReference().

Improve how the "java" executable is found

Right now it expects java to be in the system path.
there are two issues:

1. windows users (java.exe)
2. it may not be the case on all systems

Something like:

private File findJava() {
        String javaHome = System.getProperty("java.home");
        File found;
        if (javaHome == null) {
            found = findExecutableInSystemPath("java");
        } else {
            File bin = new File(javaHome, "bin");
            found = find("java", bin);
        }

        if (found == null || ! found.isFile()) {
            throw new IllegalStateException("Unable to find the java executable in JAVA_HOME or in the system path");
        }
        return found;
    }

public static File findExecutableInSystemPath(String executable) {
        String systemPath = System.getenv("PATH");

        // Fast failure if we don't have the PATH defined.
        if (systemPath == null) {
            return null;
        }

        String[] pathDirs = systemPath.split(File.pathSeparator);

        for (String pathDir : pathDirs) {
            File dir = new File(pathDir);
            if (dir.isDirectory()) {
                File file = findExecutableInDirectory(executable, dir);
                if (file != null) {
                    return file;
                }
            }
        }
        // :-(
        return null;
    }

public static File find(String executable, File... dirs) {
        // First try using the hints.
        if (dirs != null) {
            for (File hint : dirs) {
                File file = findExecutableInDirectory(executable, hint);
                if (file != null) {
                    return file;
                }
            }
        }

        // Not found, try to use the system path.
        return findExecutableInSystemPath(executable);
    }

private static File findExecutableInDirectory(String executable, File directory) {
        if (directory == null || !directory.isDirectory()) {
            // if the directory is null or not a directory => returning null.
            return null;
        }
        for (String extension : EXECUTABLE_EXTENSIONS) {
            File file = new File(directory, executable + extension);
            if (file.isFile() && file.canExecute()) {
                return file;
            }
        }
        // Not found.
        return null;
    }

would be more robust. I will work on a PR.

Improve SIGQUIT handler

• Include 'nid' field:
  • On Mac it should be the value of pthread_t (currently what's stuffed in the 'tid' field)
  • On Linux it's the result of gettid so it can be correlated to PS/top (but print it in decimal for sanity's sake)
• Fix 'tid' field:
  • On OpenJDK it's meant to be the pointer to the thread internal structure; should be able to derive that from the IsolateThread
• Add in monitors and stuff
  • Figure out which frames grab monitors or locks from the class/method name
  • Snoop the object right off of the call stack using JavaStackWalker and print some interesting info about it

Arc - implement CDI inheritance rules properly

See also http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#inheritance.

Let's move to Graal 1.0.0.RC10

Given the difficulties with NPE in report output, we should probably just move to RC10.

This would probably depend on having the RC10 artifacts published.

Excessive logging in shamrock-example-permissive

When building shamrock-example-permissive, we end up with a lot of logging:

[WARNING] Duplicate entry META-INF/INDEX.LIST entry from io.undertow:undertow-core:jar:2.0.16.Final:provided will be ignored
[WARNING] Duplicate entry META-INF/INDEX.LIST entry from org.jboss.spec.javax.servlet:jboss-servlet-api_4.0_spec:jar:1.0.0.Final:provided will be ignored
[WARNING] Duplicate entry META-INF/INDEX.LIST entry from org.jboss.shamrock:shamrock-core-runtime:jar:1.0.0.Alpha1-SNAPSHOT:provided will be ignored
[WARNING] Duplicate entry META-INF/LICENSE.txt entry from org.jboss.logging:jboss-logging-embedded:jar:1.0.0.Alpha1-SNAPSHOT:provided will be ignored
[WARNING] Duplicate entry META-INF/INDEX.LIST entry from org.jboss.logging:jboss-logging-embedded:jar:1.0.0.Alpha1-SNAPSHOT:provided will be ignored
[WARNING] Duplicate entry META-INF/INDEX.LIST entry from org.jboss.threads:jboss-threads:jar:3.0.0.Alpha4:provided will be ignored
[WARNING] Duplicate entry META-INF/LICENSE.txt entry from org.jboss.threads:jboss-threads:jar:3.0.0.Alpha4:provided will be ignored
[WARNING] Duplicate entry META-INF/INDEX.LIST entry from org.jboss.slf4j:slf4j-jboss-logging:jar:1.1.0.Final:provided will be ignored
[WARNING] Duplicate entry dependencies.runtime entry from org.jboss.shamrock:shamrock-undertow-runtime:jar:1.0.0.Alpha1-SNAPSHOT:provided will be ignored
[WARNING] Duplicate entry META-INF/INDEX.LIST entry from org.jboss.shamrock:shamrock-undertow-runtime:jar:1.0.0.Alpha1-SNAPSHOT:provided will be ignored
[WARNING] Duplicate entry META-INF/INDEX.LIST entry from org.jboss.xnio:xnio-nio:jar:3.6.5.Final:provided will be ignored
[WARNING] Duplicate entry META-INF/INDEX.LIST entry from org.jboss.xnio:xnio-api:jar:3.6.5.Final:provided will be ignored
[WARNING] Duplicate entry dependencies.runtime entry from org.jboss.shamrock:shamrock-jaxrs-runtime:jar:1.0.0.Alpha1-SNAPSHOT:provided will be ignored
[WARNING] Duplicate entry META-INF/INDEX.LIST entry from org.jboss.shamrock:shamrock-jaxrs-runtime:jar:1.0.0.Alpha1-SNAPSHOT:provided will be ignored
[WARNING] Duplicate entry META-INF/INDEX.LIST entry from org.jboss.resteasy:resteasy-core:jar:4.0.0.Beta6:provided will be ignored
[WARNING] Duplicate entry META-INF/INDEX.LIST entry from org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.1_spec:jar:1.0.0.Final:provided will be ignored
[WARNING] Duplicate entry META-INF/LICENSE entry from org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.1_spec:jar:1.0.0.Final:provided will be ignored
[WARNING] Duplicate entry META-INF/INDEX.LIST entry from org.jboss.resteasy:resteasy-core-spi:jar:4.0.0.Beta6:provided will be ignored
[WARNING] Duplicate entry META-INF/LICENSE entry from org.apache.httpcomponents:httpclient:jar:4.5.4:provided will be ignored
[WARNING] Duplicate entry META-INF/DEPENDENCIES entry from org.apache.httpcomponents:httpcore:jar:4.4.7:provided will be ignored
[WARNING] Duplicate entry META-INF/NOTICE entry from org.apache.httpcomponents:httpcore:jar:4.4.7:provided will be ignored

And so on...

Is it something expected? Can we avoid it?

Adding beans to application is not supported in "redeploy" mode

When running mvn shamrock:run -Dfakereplace=true, new defined beans are not injected (NullPointerException in the application)

JAXRS - Registering all the built-in providers makes native image significantly larger

By default, when using JAXRS, all the built-in providers are included. This includes for instance DocumentProvider which brings with him Xalan and Xerces.

Taking a simple JAXRS example and looking for is implemented by org.jboss.resteasy.plugins.providers.DocumentProvider.readFrom in the call tree log will guide you to the issue.

In a typical application, you will probably use JSON but XML is definitely not the default choice nowadays.

I made a test with the bean-validation-strict example which only uses text/plain and modified the JAXRS deployment component with this quick and dirty patch:

diff --git a/jaxrs/deployment/src/main/java/org/jboss/shamrock/jaxrs/JaxrsScanningProcessor.java b/jaxrs/deployment/src/main/java/org/jboss/shamrock/jaxrs/JaxrsScanningProcessor.java
index 2a412919..65fc3f8f 100755
--- a/jaxrs/deployment/src/main/java/org/jboss/shamrock/jaxrs/JaxrsScanningProcessor.java
+++ b/jaxrs/deployment/src/main/java/org/jboss/shamrock/jaxrs/JaxrsScanningProcessor.java
@@ -92,14 +92,12 @@ public class JaxrsScanningProcessor {
 
     @BuildStep
     ServletInitParamBuildItem registerProviders(List<JaxrsProviderBuildItem> providers) {
-        StringBuilder sb = new StringBuilder();
-        for (int i = 0; i < providers.size(); ++i) {
-            if (i != 0) {
-                sb.append(",");
-            }
-            sb.append(providers.get(i).getName());
-        }
-        return new ServletInitParamBuildItem("resteasy.providers", sb.toString());
+        return new ServletInitParamBuildItem("resteasy.providers", "org.jboss.resteasy.plugins.providers.DefaultTextPlain, org.jboss.resteasy.plugins.providers.StringTextStar");
+    }
+
+    @BuildStep
+    ServletInitParamBuildItem disableBuiltinProviders() {
+        return new ServletInitParamBuildItem("resteasy.use.builtin.providers", "false");
     }
 
     @BuildStep

Native image size goes from 27 MB to 21 MB and the native image generation is significantly faster.

Obviously, this is far too simplistic but I'm wondering if we could enable the providers depending on the @Produces annotation used + return type of the methods.

bytecode recorded classes should have more meaningful names

This will make it obvious which classes have been generated by which features.

High thread contention in org.jboss.protean.arc.RequestContext

org.jboss.protean.arc.RequestContext.activate()[1] and org.jboss.protean.arc.RequestContext.deactivate()[2] both use coarse grained locking via method synchronization.

These methods are on a hot code path, and cause a lot of thread contention under load. For a 1min 39s sample, I have observed a total of 1hr 7min 54s of thread time blocked waiting for the sync lock.

I am not sure of the intention of the synchronization as the currentContext is accessed in methods other than activate() and deactivate(), so is not not consistently protected. The property is also a threadLocal, so each thread should have it's own copy of the object.

I am not sure that the synchronization is necessary, but if it is required, we need to implement a more lightweight, finer grained, locking implementation.

[1] https://github.com/protean-project/shamrock/blob/master/ext/arc/runtime/src/main/java/org/jboss/protean/arc/RequestContext.java#L95
[2] https://github.com/protean-project/shamrock/blob/master/ext/arc/runtime/src/main/java/org/jboss/protean/arc/RequestContext.java#L109

Arc does not support injecting into non private field

when accessing:

@Inject
Instance<X> x;

VerifyError :-)

Pick up a CDI producer even if the declaring class is not annotate with a bean defining annotation

Currently, we follow the rules of "annotation" bean discovery mode and thus for example this producer is not registered:

class Foo {
  @Produces
  String produceString() { return "foo"; }
}

Update README to specific mvn version

Currently needs at least 3.2.5.

shamrock:run fails if the project does not depends on logging

If the project does not depend on:

<dependency>
     <groupId>org.jboss.shamrock</groupId>
     <artifactId>shamrock-logging-deployment</artifactId>
     <scope>provided</scope>
     <version>${shamrock.version}</version>
</dependency>

mvn compile shamrock:run fails with:

Nov 23, 2018 10:39:54 AM org.jboss.shamrock.maven.runner.RunMojoMain doStart
ERROR: Failed to start shamrock
java.lang.NoClassDefFoundError: org/wildfly/common/flags/Flags
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at org.jboss.builder.BuildStepBuilder.produces(BuildStepBuilder.java:164)
        at org.jboss.shamrock.jaxrs.JaxrsScanningProcessorBuildProvider.installInto(Unknown Source)
        at org.jboss.builder.BuildChainBuilder.loadProviders(BuildChainBuilder.java:136)
        at org.jboss.shamrock.deployment.ShamrockAugumentor.run(ShamrockAugumentor.java:63)
        at org.jboss.shamrock.runner.RuntimeRunner.run(RuntimeRunner.java:75)
        at org.jboss.shamrock.maven.runner.RunMojoMain.doStart(RunMojoMain.java:88)
        at org.jboss.shamrock.maven.runner.RunMojoMain.main(RunMojoMain.java:58)
Caused by: java.lang.ClassNotFoundException: org.wildfly.common.flags.Flags
        at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        ... 19 more

Make it possible to get interceptor bindings from Arc InvocationContext

See also https://github.com/weld/api/blob/master/weld/src/main/java/org/jboss/weld/interceptor/WeldInvocationContext.java

Create Arquillian adapter

We will need this for MP TCK test suites.

Add support on @Valid on method parameter

configuration not reloaded with shamrock:dev

Changes to META-INF/microprofile-config.properties are not reflected in dev mode.

Note that depending on #200 the location may change.

reported time by shamrock:run in redeploy mode is wrong

It increases after every request:

INFO: Shamrock started in 1168.991ms
...
INFO: Shamrock started in 13272.696ms
...
INFO: Shamrock started in 19981.831ms
...
INFO: Shamrock started in 33562.543ms
...
INFO: Shamrock started in 179589.761ms
...

I suspect the "begin" time is not refreshed.

Shutdown hook changes have broken JVM shutdown

Looks like JVM shutdown is broken

22:25 $ jstack 91451
2018-12-06 22:25:52
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode):

"Attach Listener" #24 daemon prio=9 os_prio=31 tid=0x00007fee73865800 nid=0x5d03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"SIGINT handler" #23 daemon prio=9 os_prio=31 tid=0x00007fee7451f000 nid=0xa203 waiting for monitor entry [0x000070000c471000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at java.lang.Shutdown.exit(Shutdown.java:212)
	- waiting to lock <0x00000006c0451210> (a java.lang.Class for java.lang.Shutdown)
	at java.lang.Terminator$1.handle(Terminator.java:52)
	at sun.misc.Signal$1.run(Signal.java:212)
	at java.lang.Thread.run(Thread.java:748)

"SIGINT handler" #22 daemon prio=9 os_prio=31 tid=0x00007fee758a0800 nid=0x5c03 waiting for monitor entry [0x000070000c36e000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at java.lang.Shutdown.exit(Shutdown.java:212)
	- waiting to lock <0x00000006c0451210> (a java.lang.Class for java.lang.Shutdown)
	at java.lang.Terminator$1.handle(Terminator.java:52)
	at sun.misc.Signal$1.run(Signal.java:212)
	at java.lang.Thread.run(Thread.java:748)

"SIGINT handler" #21 daemon prio=9 os_prio=31 tid=0x00007fee7489e800 nid=0x5a03 waiting for monitor entry [0x000070000c26b000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at java.lang.Shutdown.exit(Shutdown.java:212)
	- waiting to lock <0x00000006c0451210> (a java.lang.Class for java.lang.Shutdown)
	at java.lang.Terminator$1.handle(Terminator.java:52)
	at sun.misc.Signal$1.run(Signal.java:212)
	at java.lang.Thread.run(Thread.java:748)

"SIGINT handler" #20 daemon prio=9 os_prio=31 tid=0x00007fee73867800 nid=0x5807 waiting for monitor entry [0x000070000c065000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at java.lang.Shutdown.exit(Shutdown.java:212)
	- waiting to lock <0x00000006c0451210> (a java.lang.Class for java.lang.Shutdown)
	at java.lang.Terminator$1.handle(Terminator.java:52)
	at sun.misc.Signal$1.run(Signal.java:212)
	at java.lang.Thread.run(Thread.java:748)

"SIGINT handler" #19 daemon prio=9 os_prio=31 tid=0x00007fee762b4000 nid=0x5507 waiting for monitor entry [0x000070000bf62000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at java.lang.Shutdown.exit(Shutdown.java:212)
	- waiting to lock <0x00000006c0451210> (a java.lang.Class for java.lang.Shutdown)
	at java.lang.Terminator$1.handle(Terminator.java:52)
	at sun.misc.Signal$1.run(Signal.java:212)
	at java.lang.Thread.run(Thread.java:748)

"SIGINT handler" #18 daemon prio=9 os_prio=31 tid=0x00007fee762be000 nid=0x5707 waiting for monitor entry [0x000070000bd5c000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at java.lang.Shutdown.exit(Shutdown.java:212)
	- waiting to lock <0x00000006c0451210> (a java.lang.Class for java.lang.Shutdown)
	at java.lang.Terminator$1.handle(Terminator.java:52)
	at sun.misc.Signal$1.run(Signal.java:212)
	at java.lang.Thread.run(Thread.java:748)

"SIGINT handler" #17 daemon prio=9 os_prio=31 tid=0x00007fee762bd000 nid=0x5607 waiting for monitor entry [0x000070000bc59000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at java.lang.Shutdown.exit(Shutdown.java:212)
	- waiting to lock <0x00000006c0451210> (a java.lang.Class for java.lang.Shutdown)
	at java.lang.Terminator$1.handle(Terminator.java:52)
	at sun.misc.Signal$1.run(Signal.java:212)
	at java.lang.Thread.run(Thread.java:748)

"DestroyJavaVM" #16 prio=5 os_prio=31 tid=0x00007fee7451e000 nid=0x1703 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Shutdown thread" #13 prio=5 os_prio=31 tid=0x00007fee758a1800 nid=0xa403 waiting on condition [0x000070000c168000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006c003e390> (a java.lang.Thread)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at org.jboss.shamrock.runtime.graal.ShutdownHookThread.run(ShutdownHookThread.java:39)

"SIGINT handler" #15 daemon prio=9 os_prio=31 tid=0x00007fee762ab800 nid=0x1007 in Object.wait() [0x000070000be5f000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x0000000772b56af0> (a org.jboss.shamrock.runtime.graal.ShutdownHookThread)
	at java.lang.Thread.join(Thread.java:1252)
	- locked <0x0000000772b56af0> (a org.jboss.shamrock.runtime.graal.ShutdownHookThread)
	at java.lang.Thread.join(Thread.java:1326)
	at java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:106)
	at java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:46)
	at java.lang.Shutdown.runHooks(Shutdown.java:123)
	at java.lang.Shutdown.sequence(Shutdown.java:167)
	at java.lang.Shutdown.exit(Shutdown.java:212)
	- locked <0x00000006c0451210> (a java.lang.Class for java.lang.Shutdown)
	at java.lang.Terminator$1.handle(Terminator.java:52)
	at sun.misc.Signal$1.run(Signal.java:212)
	at java.lang.Thread.run(Thread.java:748)

"Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007fee6f84b800 nid=0x3c03 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007fee70803000 nid=0x4103 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007fee70817000 nid=0x3b03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007fee7205b000 nid=0x4303 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007fee71026800 nid=0x4503 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007fee71036800 nid=0x3803 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007fee71013800 nid=0x3203 in Object.wait() [0x000070000b441000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000006c0005cd0> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
	- locked <0x00000006c0005cd0> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007fee6f83b000 nid=0x4c03 in Object.wait() [0x000070000b33e000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000006c0013f60> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(Object.java:502)
	at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
	- locked <0x00000006c0013f60> (a java.lang.ref.Reference$Lock)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=31 tid=0x00007fee6f808000 nid=0x3103 runnable

"GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007fee72004000 nid=0x1e07 runnable

"GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007fee72005000 nid=0x2a03 runnable

"GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007fee7100e000 nid=0x2c03 runnable

"GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007fee7100e800 nid=0x5303 runnable

"GC task thread#4 (ParallelGC)" os_prio=31 tid=0x00007fee72005800 nid=0x5203 runnable

"GC task thread#5 (ParallelGC)" os_prio=31 tid=0x00007fee72006000 nid=0x5003 runnable

"GC task thread#6 (ParallelGC)" os_prio=31 tid=0x00007fee72006800 nid=0x4f03 runnable

"GC task thread#7 (ParallelGC)" os_prio=31 tid=0x00007fee72007800 nid=0x3003 runnable

"VM Periodic Task Thread" os_prio=31 tid=0x00007fee6f84c000 nid=0x3e03 waiting on condition

JNI global references: 517

Support primitives in CDI producers

This example currently fails:

class IntegerProducerField {
        @Produces
        int foo = 10;
}

Unable to shutdown after bootstrap errors

Running in "JVM mode" the demo rest-http-crud at

• https://github.com/protean-project/rest-http-crud/tree/master/shamrock

This demo requires PostgreSQL to run. If you start it w/o the RDBMS being up, then the demo boots by printing appropriate exceptions about not being able to connect to the database - but then doesn't respond to CTRL+C signals (nor kill -3), requiring a kill -9 to stop the demo.

If instead the RDBMS is available, then CTRL+C works as expected so I assume this relates with order of setup.

Let's make sure the signal handlers are registered consistently as very first thing?

Bean Validation - Method validation for CDI and JAX-RS

Right now, we support injecting a Validator but we don't support automatic method validation via CDI - it will especially be useful for JAX-RS.

It's solved in HV via a CDI extension but Arc does not support extensions.

We need to discuss it with @mkouba .

Creating an issue so that we don't forget about it.

Default to turning off Isolates in Native Image

In evaluating rest-http project RSS usage for Native Image it was determined that Isolates caused an additional 16MB of RSS to be used.

For rest-http it was disabled in the plugin: https://github.com/protean-project/rest-http/blob/master/shamrock/pom.xml#L105

It would probably be a good idea to default to disabling Isolates until such time as they might be needed/used.

ShamrockAugumentor should be ShamrockAugmentor?

Looks like a typo.

Can someone confirm?

Producer method with erased generic return type causes NPE

A producer method with

    @Produces
    @Claim("")
    @Named("RawClaimTypeProducer#getOptionalValue")
    public Optional getOptionalValue(InjectionPoint ip) {
        log.debugf("getOptionalValue(%s)", ip);
        String name = getName(ip);
        ClaimValue<Optional<Object>> cv = MPJWTProducer.generalClaimValueProducer(name);
        Optional<Object> value = cv.getValue();
        return value;
    }

causes the following NPE with ARC:

	Suppressed: java.lang.NullPointerException
		at org.jboss.protean.arc.processor.Types.getTypeHandle(Types.java:39)
		at org.jboss.protean.arc.processor.Types.getTypeHandle(Types.java:64)
		at org.jboss.protean.arc.processor.BeanGenerator.initConstructor(BeanGenerator.java:535)
		at org.jboss.protean.arc.processor.BeanGenerator.createConstructor(BeanGenerator.java:439)
		at org.jboss.protean.arc.processor.BeanGenerator.generateProducerMethodBean(BeanGenerator.java:312)
		at org.jboss.protean.arc.processor.BeanGenerator.generate(BeanGenerator.java:102)
		at org.jboss.protean.arc.processor.BeanProcessor.process(BeanProcessor.java:162)
		at org.jboss.shamrock.arc.deployment.ArcAnnotationProcessor.build(ArcAnnotationProcessor.java:208)
		at org.jboss.shamrock.arc.deployment.ArcAnnotationProcessorBuildStep0.execute(Unknown Source)
		at org.jboss.builder.BuildContext.run(BuildContext.java:403)
		at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
		at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1934)
		at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1463)
		at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1354)
		at java.lang.Thread.run(Thread.java:748)
		at org.jboss.threads.JBossThread.run(JBossThread.java:479)

There are two places I can see this can be handled. I'll create a pull request for the more general location, and @mkouba can decide if that is the best way to do so.

AbstractMethodError when running an application

When running the quickstart, it's failing with:

INFO] --- shamrock-maven-plugin:1.0.0.Alpha1-SNAPSHOT:dev (default-cli) @ my-shamrock-project ---
2018-11-30 15:10:46,478 hoth shamrock2583966883683498412-runner.jar[49865] INFO  [o.j.s.u.r.UndertowDeploymentTemplate] (main) Starting Undertow on port 8080
2018-11-30 15:10:46,554 hoth shamrock2583966883683498412-runner.jar[49865] INFO  [o.xnio] (main) XNIO version 3.3.8.Final
2018-11-30 15:10:46,575 hoth shamrock2583966883683498412-runner.jar[49865] INFO  [o.x.nio] (main) XNIO NIO Implementation Version 3.6.5.Final
Exception in thread "main" java.lang.AbstractMethodError: org.xnio.Xnio.createWorker(Ljava/lang/ThreadGroup;Lorg/xnio/OptionMap;Ljava/lang/Runnable;)Lorg/xnio/XnioWorker;
	at org.xnio.Xnio.createWorker(Xnio.java:498)
	at org.xnio.Xnio.createWorker(Xnio.java:485)
	at io.undertow.Undertow.start(Undertow.java:122)
	at org.jboss.shamrock.undertow.runtime.UndertowDeploymentTemplate.startUndertowEagerly(UndertowDeploymentTemplate.java:230)
	at org.jboss.shamrock.dev.RuntimeCompilationSetup.setup(RuntimeCompilationSetup.java:53)
	at org.jboss.shamrock.dev.DevModeMain.main(DevModeMain.java:79)

NPE in shamrock:dev

[INFO] --- shamrock-maven-plugin:1.0.0.Alpha1-SNAPSHOT:dev (default-cli) @ input-validation ---
Using servlet resources /Users/clement/Projects/protean/quickstarts/input-validation/src/main/resources/META-INF/resources
Exception in thread "main" java.lang.NullPointerException
	at sun.nio.fs.UnixPath.normalizeAndCheck(UnixPath.java:77)
	at sun.nio.fs.UnixPath.<init>(UnixPath.java:71)
	at sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:281)
	at java.nio.file.Paths.get(Paths.java:84)
	at org.jboss.shamrock.dev.RuntimeCompilationSetup.setup(RuntimeCompilationSetup.java:55)
	at org.jboss.shamrock.dev.DevModeMain.main(DevModeMain.java:80)

Drop the private member infos to debug level for a class that is not an application class

This includes injections, observers, lifecycle callbacks, interceptor methods.

Application Config should not inject `null`

The microprofile spec does not allow injecting null, while shamrock does inject null:

@Inject
@ConfigProperty(name="not-in-config")
String boom

If the value is optional, 2 approaches:

• use Optional
• use what is described in eclipse/microprofile-config#365. (a specific default value)

Just having shamrock-agroal-deployment as dependency shouldn't require it to be configured

In the process of adding new extensions to an existing demo, my first step was to add shamrock-agroal-deployment and then verify the build was still fine.

Tests actually fails with:

Caused by: java.lang.RuntimeException: org.jboss.shamrock.deployment.configuration.ConfigurationError: Required configuration property 'shamrock.datasource.driver' was not defined.
	at org.jboss.shamrock.runner.RuntimeRunner.run(RuntimeRunner.java:128)

I haven't configured it yet, but I'm also not really using Agroal yet so I hope we can improve on this.

Enabling injection even when no beans.xml ?

Just some thought.

I had a project that does not contain any bean definition. It only has a Jax-RS resource. This resource declares 2 injected fields. Unfortunately, the injection does not work. If I declare a bean, the injection works.

Of course, it works if I add a beans.xml file. So, I was wondering if we can't detect this case and enable the injection if it's required, or warn the user.

Provide a "create"/"setup" goal to the Maven plugin

build-create.log (from CreateProjectMojoIT) is not gitignored and not in **/target/

Thus it keeps showing up in my commits needing to be edited out.

Native image build occasionally fails with NPE

Occasionally when compiling an application to a native-image, the native-image generator fails with a NPE.

org.jboss.shamrock.jaxrs.runtime.graal.LocatableAnnotationSubstitutions$Selector.getAsBoolean() and org.jboss.shamrock.jaxrs.runtime.graal.InternalLocatableAnnotationSubstitutions$Selector.getAsBoolean() do not handle NoClassDefFoundError in exception logic. If the CL throws a NoClassDefFoundError, this error propagates through the call stack back to com.oracle.svm.hosted.NativeImageGenerator.run(), which causes the native image build to fail and a NPE to be thrown

`application.properties` or `protean.properties` support and location

Instead of (or in addition to) META-INF/microprofile-config.properties it would be nice to support one of the 2 names (issue title).

Also, it is possible to configure the file location? META-INF means "from inside the package", so the configuration cannot be located directly on the file system. This can be an issue if we want to mount it using a config map. Should a specific location (such as $PWD/conf/application.properties) be checked by default?

(don't do $PWD/application.properties as a config map cannot be mounted in an existing directory (or erase the content))

Arc - support initializer injection on superclasses

Should the dev mojo enforce that target/classes exists

Right now, if the java classes are not compiled, the dev mode compile them. But it does not copy the resources.

So, we can either:

• enforce the target/classes dir exist and ask the user to launch mvn compile explicitly
• copy the resources in the dev mode.

@stuartwdouglas WDYT?

Allow application bytecode transformation over plain byte arrays

We need Hibernate ORM to apply its own bytecode transformation logic on the user's JPA model.

The API we have in ORM is this one:

• https://github.com/hibernate/hibernate-orm/blob/159bc99a36d86988b61b88ba91eec82cac044e1c/hibernate-core/src/main/java/org/hibernate/bytecode/enhance/spi/Enhancer.java#L16-L29

while Shamrock expects a Function<String, Function<ClassVisitor, ClassVisitor>> function; I don't see an easy way to adapt to this.

Would be nice to also expose the option to register a processor which works on plain byte[] rather than ASM class visitors?

Names of classes generated by Arc should have more complex suffix

So that there's little probability of a clash with app classes.

The current state:

• beans - _Bean
• observers - _Observer
• client proxies - _ClientProxy
• intercepted subclasses -_Subclass