quarkusio / quarkus Goto Github PK
View Code? Open in Web Editor NEWQuarkus: Supersonic Subatomic Java.
Home Page: https://quarkus.io
License: Apache License 2.0
Quarkus: Supersonic Subatomic Java.
Home Page: https://quarkus.io
License: Apache License 2.0
Make it possible to use some methods at runtime, such as getBeans()
or getReference()
.
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
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%
Right now it expects java
to be in the system path.
there are two issues:
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.
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"; }
}
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.
[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)
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.
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.
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:
Optional
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.
[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]
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))
This includes injections, observers, lifecycle callbacks, interceptor methods.
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.
This will make it obvious which classes have been generated by which features.
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:
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?
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
Currently needs at least 3.2.5.
This example currently fails:
class IntegerProducerField {
@Produces
int foo = 10;
}
Thus it keeps showing up in my commits needing to be edited out.
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.
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?
Looks like a typo.
Can someone confirm?
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.
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
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.
Running in "JVM mode" the demo rest-http-crud
at
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?
Changes to META-INF/microprofile-config.properties
are not reflected in dev mode.
Note that depending on #200 the location may change.
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
gettid
so it can be correlated to PS/top (but print it in decimal for sanity's sake)When running mvn shamrock:run -Dfakereplace=true
, new defined beans are not injected (NullPointerException
in the application)
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;
If you have a simple project and follows:
Run -> Run Configurations...
Maven Build
and select new Configuration
Run dev mode
)${project_loc}
goals
field enter: compile shamrock:devRun
The application is served correctly.
But:
when accessing:
@Inject
Instance<X> x;
VerifyError :-)
So it's not possible to add method-level interceptor binding to a business method.
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:
target/classes
dir exist and ask the user to launch mvn compile
explicitly@stuartwdouglas WDYT?
It should be created in target
(or in a sub-directory of target
, but not the project root).
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
So that there's little probability of a clash with app classes.
The current state:
_Bean
_Observer
_ClientProxy
_Subclass
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
We will need this for MP TCK test suites.
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)
Reproducer:
mvn compile shamrock:dev
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.