Lightweight open-source framework for developing microservices using standard Java EE technologies and migrating Java EE to cloud-native architecture.
Home Page: https://ee.kumuluz.com
License: MIT License
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
KumuluzEE is using the HikariCP for its implementation of the Datasource configuration pool, but it is currently lacking any advanced configuration options that HikariCP provides (except for the max pool size).
I propose all the available HikariCP configuration options are added to the KumuluzEE configuration options.
Problem:
Infrequently (not always) the boot loader fails to initialize application properly.
This seems to be dependant on the load order of .jars included in the uber jar.
I have managed to reproduce this with the JAX-RS sample where approx 1/20 times the uberjar fails to run.
With my own project it fails a lot more frequently.
Environment:
Tested with:
How to reproduce:
Attachments:
For these the system variable com.kumuluz.ee.loader.debug was set to true.
Hi,
I am getting following error when using version 2.5.1
Failed to collect dependencies at com.kumuluz.ee:kumuluzee-microProfile-1.2:jar:2.5.1 -> com.kumuluz.ee.config:kumuluzee-config-mp:jar:1.1.0: Failed to read artifact descriptor for com.kumuluz.ee.config:kumuluzee-config-mp:jar:1.1.0: Could not find artifact com.kumuluz.ee:kumuluzee-bom:pom:2.5.0-SNAPSHOT -> [Help 1]
Have issues when running kumuluzee -based application.
Same symptoms as in "Running uberjar fails infrequently #87" in closed issues.
Using JPA, REST and OpenAPI.
Maven 3.5.2
Java openjdk version "11-ea" 2018-09-25 (but same behaviour even with Java10 and 8)
Happens in Windows 10 and in Docker with Alpine Linux
Using Kumuluzee 2.5.3.
One thing that I can say about my project is that it has a large number of entitiy classes.
Succeeded to recreate same thing with kumuluz-samples/kumuluz-rest (when i added OpenAPI or Swagger)
kumuluzee-failures.txt
CTRL-C to terminate between runs
It should be possible to specify the path to config.properties file, perhaps via -D parameter at runtime.
Please make the Servlet and JSF components work with src/main/webapp as that would allow writing an application that's really compatible with any appservers and with Kumuluz. Additionally some IDEs handle src/main/webapp specially i.e. when using features like "Generate web.xml" or "Enable JSF" (adding some lines to web.xml). It's very confusing if that does not work or one ends up with two faces.xml files.
When developing I'd rather prefer using an appserver with hot-deployment of changed classes but when deploying the final app into production, I would like to use KumuluzEE to create a uber-jar.
Currently for JSP support the jetty library is used. However it would be better if we used only the reference implementation and add it to the underlaying server like all the other components.
Hi, great framework, specially to Microservices architecture... Nevertheless i would like packaging a JSF based application... any sample on this ?
Would be great to be able to run KumuluzEE as an "uber-jar".
Problem:
If the generated uber jar is inside a directory called 'lib' JAX-RS endpoints do not work properly.
Environment:
Tried and reproduced in:
Background
I found this out after trying to push my application to Cloud Foundry, for which I had to use a DistZip deployment archive.
(see https://github.com/cloudfoundry/java-buildpack/blob/master/docs/container-dist_zip.md)
In the DistZip archive, .jar files for the application reside in 'lib'.
How to reproduce:
You may need to replace ${project.build.finalName} with generated project name, in my case jax-rs-2.5.0-SNAPSHOT.
Run:
git clone https://github.com/kumuluz/kumuluzee-samples
cd kumuluzee-samples/jax-rs
mvn clean package
mkdir target/lib
cp target/${project.build.finalName}.jar target/lib
java -jar target/lib/${project.build.finalName}.jar
Then go to url: http://localhost:8080/v1/customers
Browser will return an error:
HTTP ERROR 404
Problem accessing /v1/customers. Reason:
Not Found
Hi. Every time I try to start an uber jar with JAX-RS it fails.
Exception
org.eclipse.jetty.server.AbstractConnector -- Started ServerConnector@41641c84{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
Exception in thread "main" java.lang.NoClassDefFoundError: org/glassfish/jersey/internal/ServiceFinder
at org.glassfish.jersey.servlet.internal.ServletContainerProviderFactory.getAllServletContainerProviders(ServletContainerProviderFactory.java:66)
at org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer.onStartup(JerseyServletContainerInitializer.java:134)
at org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup(ContainerInitializer.java:140)
at org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(ServletContainerInitializersStarter.java:63)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:329)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1515)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1477)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:785)
at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:261)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:133)
at org.eclipse.jetty.server.Server.start(Server.java:418)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:107)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.Server.doStart(Server.java:385)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at com.kumuluz.ee.jetty.JettyServletServer.startServer(JettyServletServer.java:80)
at com.kumuluz.ee.EeApplication.initialize(EeApplication.java:360)
at com.kumuluz.ee.EeApplication.(EeApplication.java:73)
at com.kumuluz.ee.EeApplication.main(EeApplication.java:85)
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 com.kumuluz.ee.loader.EeClassLoader.invokeMain(EeClassLoader.java:455)
at com.kumuluz.ee.loader.EeBootLoader.launch(EeBootLoader.java:54)
at com.kumuluz.ee.loader.EeBootLoader.main(EeBootLoader.java:41)
Caused by: java.lang.ClassNotFoundException: Failure to load: org.glassfish.jersey.internal.ServiceFinder
at com.kumuluz.ee.loader.EeClassLoader.loadClass(EeClassLoader.java:509)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
This is my Pom:
4.0.0
<groupId>com.ibm.jsf</groupId>
<artifactId>jsf</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>
<name>JSF</name>
<description>JSF Test </description>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<kumuluz.version>2.5.2</kumuluz.version>
<kumuluzee-config.version>1.1.0</kumuluzee-config.version>
<kumuluzee-logs.version>1.3.0</kumuluzee-logs.version>
<kumuluzee-discovery.version>1.1.0</kumuluzee-discovery.version>
<kumuluzee-rest.version>1.2.0</kumuluzee-rest.version>
<kumuluzee-cors.version>1.0.2</kumuluzee-cors.version>
<kumuluzee-health.version>1.0.0</kumuluzee-health.version>
<kumuluzee-fault-tolerance.version>1.0.0</kumuluzee-fault-tolerance.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-bom</artifactId>
<version>${kumuluz.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-core</artifactId>
</dependency>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-servlet-jetty</artifactId>
</dependency>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-jsp-jetty</artifactId>
</dependency>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-el-uel</artifactId>
</dependency>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-jsf-mojarra</artifactId>
</dependency>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-cdi-weld</artifactId>
</dependency>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-jax-rs-jersey</artifactId>
</dependency>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-json-p-jsonp</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-maven-plugin</artifactId>
<version>${kumuluz.version}</version>
<executions>
<execution>
<id>package</id>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Problem:
Application does not run
Environment:
How to reproduce:
Attachments:
20180108_beansxml_error_log.txt
beans.xml.txt
Is it possible to include several sub-classes of javax.ws.rs.core.Application (each with their own ApplicationPath and resource classes) in the same Kumuluzee uber jar?
If so, what are the necessary steps to make that work.
/Lars
Is a class level javax.annotations.security.DenyAll supposed to deny access to endpoints contained within? i.e. :
@path("my-app")
@Denyall
class app {
@GET
@Path("get-data")
public Response getData() {
//...
}
}
If so I can't seem to get it to work using kumuluzee-bom and microprofile-1.2.
Thanks, Anthony.
Currently when you declare a CDI bean with the @ConfigBundle annotation to auto-populate its fields with proper values from the apps config, it is only possible to populate primitive types (String, Integer, ...). Like so:
@ConfigBundle("app")
@ApplicationScoped
public class AppConfig {
private String externalUrl;
private String externalApiKey;
// Getters and setters
}This works great, however with bigger apps the config tends to get very large, so you would rather not have all the values on the same config level and class. Currently the way to solve this is to create multiple CDI @ConfigBundle classes with a different (nested) prefix for each nested level of configuration values. Another way is to manually query every key using the ConfigurationUtil. It also gets very tricky and repetitive if you have a List in your configuration, since you need to query each value one by one.
This needs to be streamlined. I propose we add support for nested custom classes and lists (of primitives and custom classes) when configuring and populating the CDI @ConfigBundle class. This way if such a class has properties that are not primitives KumuluzEE MUST recursively populate then as well along side the already available primitive properties. The same goes for properties that are lists. KumuluzEE MUST also find out about possible cycles in the configuration class tree and warn the developer about them.
In essence, from the developers perspective the following should work automagically:
public class ExternalConfig {
private String url;
private String apiKey;
// Getters and setters
}@ConfigBundle("app")
@ApplicationScoped
public class AppConfig {
private String name;
private ExternalConfig external;
// Getters and setters
}@ApplicationScoped
public class AppServiceImpl {
@Inject
private AppConfig appConfig;
public void verifyService() {
// Prints the value of the nested config param
System.out.println(appConfig.getExternal().getUrl());
}
}The first alpha version of KumuluzEE.
I've got the follow error when i've tried to run the ubber jar with
<kumuluzee.version>3.0.0</kumuluzee.version>
jdk1.8.0_161.jdk
2018-11-03 19:40:57 INFO Bootstrap:49 - WELD-ENV-000020: Using jandex for bean discovery
2018-11-03 19:40:57.098 WARNING -- org.eclipse.jetty.webapp.WebAppContext -- Failed startup of context o.e.j.w.WebAppContext@163e4e87{/api/agenda,jar:file:/Users/lacerdaph/workspace/lider/agenda-api/target/agenda-api-0.0.1-SNAPSHOT.jar!/webapp,UNAVAILABLE}
javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found
at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:176)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92)
at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136)
at org.jboss.weld.xml.BeansXmlStreamParser.parse(BeansXmlStreamParser.java:133)
at org.jboss.weld.bootstrap.WeldBootstrap.parse(WeldBootstrap.java:136)
at org.jboss.weld.environment.deployment.discovery.AbstractBeanArchiveScanner.parseBeansXml(AbstractBeanArchiveScanner.java:46)
at org.jboss.weld.environment.deployment.discovery.DefaultBeanArchiveScanner.scan(DefaultBeanArchiveScanner.java:76)
at org.jboss.weld.environment.servlet.deployment.WebAppBeanArchiveScanner.scan(WebAppBeanArchiveScanner.java:73)
at org.jboss.weld.environment.deployment.discovery.AbstractDiscoveryStrategy.performDiscovery(AbstractDiscoveryStrategy.java:93)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.createDeployment(WeldServletLifecycle.java:302)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize(WeldServletLifecycle.java:156)
at org.jboss.weld.environment.servlet.EnhancedListener.onStartup(EnhancedListener.java:62)
at org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup(ContainerInitializer.java:140)
at org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(ServletContainerInitializersStarter.java:64)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:355)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1497)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1459)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:848)
at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:287)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:138)
at org.eclipse.jetty.server.Server.start(Server.java:419)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:108)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.Server.doStart(Server.java:386)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at com.kumuluz.ee.jetty.JettyServletServer.startServer(JettyServletServer.java:81)
at com.kumuluz.ee.EeApplication.initialize(EeApplication.java:368)
at com.kumuluz.ee.EeApplication.(EeApplication.java:73)
at com.kumuluz.ee.EeApplication.main(EeApplication.java:85)
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 com.kumuluz.ee.loader.EeClassLoader.invokeMain(EeClassLoader.java:434)
at com.kumuluz.ee.loader.EeBootLoader.launch(EeBootLoader.java:54)
at com.kumuluz.ee.loader.EeBootLoader.main(EeBootLoader.java:41)
The workaround was to add the follow dependecy
stax stax 1.2.0The alpha that was released for testing was proven stable. Rerelease it as stable to mark it available to use.
I'm doing integration testing and I needed to programatically start and stop the EeApplication. I'm trying to create something like Dropwizard's DropwizardTestSupport class. In a nutshell, I'm doing something like this:
class SomeIntegrationTest {
private EeApplication app;
@Before
public void startServer() {
config = createCustomEeConfig();
app = new EeApplication(config);
}
@After
public void stopServer() {
app.getServer().stopServer();
}
@Test
public void test() {
// hit the API, etc.
}
}The stopServer() method always throws an IllegalStateException. Examining JettyServletServer, the cause becomes apparent. The code guarding against multiple attempts to stop the server is the same as the one used for startServer():
@Override
public void stopServer() {
// ...
if (server.isStarted() || server.isStarting())
throw new IllegalStateException("Jetty is not running stopped");
// ...
}By symmetry, it should really be:
@Override
public void stopServer() {
// ...
if (server.isStopped() || server.isStopping())
throw new IllegalStateException("Jetty is already stopped");
// ...
}I created PR #111 to fix the issue.
The KumuluzEE Logs framework enable the simple use off pluggable implementations through the frameworks native extension mechanism. Additionally it comes with a set of useful logging common methods that are implemented along side the normal logging extensions and makes it implementation agnostic.
Right now the interfaces to support the Kumuluz Logs framework are located inside KumuluzEE itself. The reason for that is that we will shortly begin migrating all of KumuluzEE's internal logging to it. However by default if you don't include any extensions there are no implementations available at runtime, which means that it won't work.
We need to implement and include a default implementation for the KumuluzEE Logs framework for the JVM built in JUL as it requires no additional dependencies and is available everywhere. A default implementation will enable KumuluzEE Logs to work out of the box with no extra dependencies and almost no overhead and will enable us to start migrating the rest of the framework and its extensions to it.
It would be very helpful for the Getting Started guide to have the following Windows syntax for running jar files specified alongside the Linux/UNIX syntax:
java -classpath "target\classes;target\dependency*" com.kumuluz.ee.EeApplication
I just verified that the command works.
such as zookeeper and queue?
Which Java EE components are included is controlled purely from the projects dependencies. That means that there can be multiple implementations and/or version of the same component loaded at the same time. The framework needs to check for this and issue appropriate warnings and/or errors.
When using the @ConfigBundle annotation to automatically populate bean properties from the config, if using the root prefix (i.e. not suppling a prefix) it's not picking them up. For instance:
@ConfigBundle
@ApplicationScoped
public class ServiceProperties {
private String authUrl;
public String getAuthUrl() {
return authUrl;
}
public void setAuthUrl(String authUrl) {
this.authUrl = authUrl;
}
}and the config.yml file:
auth-url: http://localhost:9080/authThe properties are not available in the bean as would be expected.
The config framework has the ability to retrieve values as a String, Integer, Double, Float and Boolean, but not Long. We need to add support for the latter as well. Also make sure to update the ConfigurationValueTypeenum and thegetType` function of the util.
Optional<Long> value = ConfigurationUtil.getInstance().getLong("key");Web fragments are currently not loaded as they are not in the scan path of jetty. The dependency jars are listed in the java.class.path variable, they should be included in the scan path.
Right now, KumuluzEE just works with EclipseLink, but it could be nice if it can works with other ORM like BatooJPA or another ORM (yes HIbernate may be).
Or, it is some way to do that?
Thanks in advance.
I need to run a thread as part of my application and this thread needs to be able to fire CDI events. What are my options when using Kumuluzee?
/Lars
Hello.
I started to use KumuluzEE and I need to use couple of ContainerRequestFilters in my jax-rs application.
Those filters which are in project are loaded and invoked. I have one jar archive for authorization which contains another ContainerRequestFilter which is not loaded at all.
I tried to create web.xml with jersey.config.server.provider.packages but without any success.
How to load this ContainerRequestFilter from different archive please?
Thakns
Currently the bean-validation-hibernate-validator doesn't provide a way to automatically validate JAX-RS resources. This could be solved by adding the following dependency to this component:
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>2.25.1</version>
<exclusions>
<exclusion>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
</exclusion>
</exclusions>
</dependency>Or maybe it would be better to create a new component altogether, e.g. bean-validation-jersey-validator?
Similar to Wildlfy-Swarm ...
public static void main(String[] args) throws Exception {
int port = 9090;
Container container = new Container("MyFavouriteContainerName", port);
container
.dataSource("MyDS", (ds) -> {
ds.driverName("h2");
ds.connectionUrl("jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE");
ds.userName("sa");
ds.password("sa");
})
.deploy("name of Resource", MyResource.class, options)
;
container.start();
Hi everyone,
I facing the following error when running the project with version 2.5.2 and it doesn't happen with version 2.4.1 , all help appreciated :
myproject/target/myproject.jar!/webapp,UNAVAILABLE}
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:219)
at java.util.zip.ZipFile.(ZipFile.java:149)
at java.util.jar.JarFile.(JarFile.java:166)
at java.util.jar.JarFile.(JarFile.java:103)
at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:93)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:84)
at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89)
at org.eclipse.jetty.webapp.MetaInfConfiguration.getTlds(MetaInfConfiguration.java:438)
at org.eclipse.jetty.webapp.MetaInfConfiguration.scanForTlds(MetaInfConfiguration.java:355)
at org.eclipse.jetty.webapp.MetaInfConfiguration.scanJars(MetaInfConfiguration.java:173)
at org.eclipse.jetty.webapp.MetaInfConfiguration.preConfigure(MetaInfConfiguration.java:102)
at org.eclipse.jetty.webapp.WebAppContext.preConfigure(WebAppContext.java:506)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:544)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:133)
at org.eclipse.jetty.server.Server.start(Server.java:418)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:107)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.Server.doStart(Server.java:385)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at com.kumuluz.ee.jetty.JettyServletServer.startServer(JettyServletServer.java:80)
at com.kumuluz.ee.EeApplication.initialize(EeApplication.java:360)
at com.kumuluz.ee.EeApplication.(EeApplication.java:73)
at com.kumuluz.ee.EeApplication.main(EeApplication.java:85)
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 com.kumuluz.ee.loader.EeClassLoader.invokeMain(EeClassLoader.java:455)
at com.kumuluz.ee.loader.EeBootLoader.launch(EeBootLoader.java:54)
at com.kumuluz.ee.loader.EeBootLoader.main(EeBootLoader.java:41)
2018-01-16 02:51:10.340 INFO -- org.eclipse.jetty.server.AbstractConnector -- Started ServerConnector@17579e0f{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
2018-01-16 02:51:10.341 INFO -- org.eclipse.jetty.server.Server -- Started @1608ms
2018-01-16 02:51:10.341 INFO -- com.kumuluz.ee.EeApplication -- KumuluzEE started successfully
hell i know that jndi support is usually very container specific.
but in case of jetty this could be done easiely.
Some Java EE components need others in order to function (ex. JSF needs EL, ...). The framework should include a mechanism for the components so that they can specify what they need. Then on startup it needs to verify that all the dependencies and requirements are met.
Guys,
i didn't find on the documentation how to configure the embedded jetty to run over HTTPS.
Is this a feature that is not possible yet using KumuluzEE?
For instance, to enable CORS, i had to add jetty-servlets dependency and enable it on web.xml configuration file.
https://www.eclipse.org/jetty/documentation/9.4.x/cross-origin-filter.html
Hi,
first of all i want to say that KumuluzEE is great piece of work.
But i think the refactoring of webapp to src/main/resources is a little bit unfortunate due to various reasons:
Therefore i developed KumuluzEE maven plugin which i would like to share. Any interests?
Kind regards
Alex
It looks like classes annotated with @webservice are not managed by cdi container and therefore injections are not supported.
Hello everyone,
i'm having this error when running a sample project with the jsf project sample contents :
`org.eclipse.jetty.webapp.WebAppContext -- Failed startup of context o.e.j.w.WebAppContext@38bc8ab5{/,jar:file:/Users/......./devstudio/test/target/test.jar!/webapp,UNAVAILABLE}
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:225)
at java.util.zip.ZipFile.(ZipFile.java:155)
at java.util.jar.JarFile.(JarFile.java:166)
at java.util.jar.JarFile.(JarFile.java:103)
at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:93)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:84)
at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89)
at org.eclipse.jetty.webapp.MetaInfConfiguration.getTlds(MetaInfConfiguration.java:438)
at org.eclipse.jetty.webapp.MetaInfConfiguration.scanForTlds(MetaInfConfiguration.java:355)
at org.eclipse.jetty.webapp.MetaInfConfiguration.scanJars(MetaInfConfiguration.java:173)
at org.eclipse.jetty.webapp.MetaInfConfiguration.preConfigure(MetaInfConfiguration.java:102)
at org.eclipse.jetty.webapp.WebAppContext.preConfigure(WebAppContext.java:506)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:544)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:138)
at org.eclipse.jetty.server.Server.start(Server.java:419)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:108)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.Server.doStart(Server.java:386)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at com.kumuluz.ee.jetty.JettyServletServer.startServer(JettyServletServer.java:81)
at com.kumuluz.ee.EeApplication.initialize(EeApplication.java:368)
at com.kumuluz.ee.EeApplication.(EeApplication.java:73)
at com.kumuluz.ee.EeApplication.main(EeApplication.java:85)
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 com.kumuluz.ee.loader.EeClassLoader.invokeMain(EeClassLoader.java:434)
at com.kumuluz.ee.loader.EeBootLoader.launch(EeBootLoader.java:54)
at com.kumuluz.ee.loader.EeBootLoader.main(EeBootLoader.java:41)
2018-10-29 21:04:40.504 INFO -- org.eclipse.jetty.server.AbstractConnector -- Started ServerConnector@14729f0c{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
2018-10-29 21:04:40.505 INFO -- org.eclipse.jetty.server.Server -- Started @1628ms
2018-10-29 21:04:40.505 INFO -- com.kumuluz.ee.EeApplication -- KumuluzEE started successfully`
I'm using a standard maven webapplication archetype project.
the project :
test.zip
Thank you in advance.
In addition to the other built in config sources, I propose we also add support for the Java SystemProperties config source, which would fetch the config values from the standard (-D) Java config properties passed to the app.
The naming convention would follow the standard .properties naming we already have in place. The source's priority would be above the file source but below the extentions and environemnt sources.
For example to set the KumuluzEE http port:
$ java -cp "target/classes:target/dependency/*" -Dkumuluzee.server.http.port=9000 com.kumuluz.ee.EeApplicationHello,
I find kumuluz very promising but it is a very bad sign that there are no tests written for the framework.
Is there any plan to at least add examples of how to do integration testing with components enabled on-demand? Or any plans to write an arquillian adapter?
First, thanks for your work, Kumuluzee works great and is very promising!
I don't find a proper way to activate or deactivate extensions once there are in dependencies.
For example, I want to use consul as configuration provider in production environment but I would prefer to use a basic configuration file in dev environment.
For now (and for test purpose), I'm hacking a bit via reflection the ConfigurationImpl in the ConfigurationUtil instance by removing the ConsulConfigurationSource from sources.
The same type of problem occurs for other extension like discovery. In production environment, I want to use consul but in dev environment, I would prefer to directly use entry points configured in configuration file.
For now, I added a custom annotation with a custom producer. In dev environment, this producer procuces a WebTarget to entry points configured in the configuration file but in production environment, the "real" DiscoverServiceProducer is used to return a WebTarget .
A more elegant way seems to write my own EeApplication class which takes care of activation/deactivation via properties:
kumuluzee:
extensions:
config.enabled: false
discovery.enabled: false
fault.tolerance.enabled: false
but I'm afraid of side effects for some extensions.
Is there a better way to achieve this kind of activation/deactivation on extensions?
I have a multimodule maven project organized such that one module is the JAX-RS application and another module is the KumuluzEE app itself. The latter depends on the former. I have pushed a very small repo to demonstrate the issue at https://github.com/andref/kumuluzee-uberjar-bug.
The app runs fine from any IDE or from the command line:
java -cp $(ls application/target/classes/lib/*.jar | paste -s -d":" -) \
com.kumuluz.ee.EeApplicationDuring the start-up process, it notes:
INFO -- KumuluzEE running in an exploded class and dependency runtime.
The app responds as expected:
$ curl -X HEAD -I http://localhost:8080/v1/hello
HTTP/1.1 200 OK
Date: Sat, 01 Sep 2018 17:21:08 GMT
X-Powered-By: KumuluzEE/2.5.3
Content-Type: application/json
Content-Length: 11
Server: Jetty(9.4.8.v20171121)Now, if I run the uberjar generated by the kumuluzee-maven-plugin, things go wrong. The app notes:
INFO -- KumuluzEE running inside a JAR runtime.
And although it appears to be running, it does not respond:
$ curl -X HEAD -I http://localhost:8080/v1/hello
HTTP/1.1 404 Not Found
Date: Sat, 01 Sep 2018 17:21:56 GMT
X-Powered-By: KumuluzEE/2.5.3
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 324
Server: Jetty(9.4.8.v20171121)As there's nothing really weird about packaging the JAX-RS resources and application in a jar (since the equivalent war webapp would run just fine), I believe this must be a bug in either the maven plugin or the class loading mechanism used by the uberjar.
Mojarra is the reference implementation for JSF and as such it should be used according to the frameworks philosophy.
Config values retrieved from the configuration framework are always literal primitives (Strings, Integers, ...) retrieved from one of the config sources. They cannot be combined or put together in any way other then manually in the code by a developer. I propose we add basic string interpolation to the config values to enable construction of config parameters in runtime. This enables us to reduce config value repeatedness (as we can reference other config values) as well as construct values with multiple other values.
To start with KumuluzEE MUST detect interpolated string values designated with the syntax of ${PROPERTY} and replace them with their actual values, which are fetched from the config property represented by PROPERTY in the proposed syntax. There can be multiple such values but for now cannot be nested. In the future certian functions or more complex construction of strings should be possible.
Example:
app:
name: "Sample app"
version: "1.0.0."
external-name: "${app.name}"The property app.external-name should contain the value Sample app. Interpolation SHOULD work on every source as well as cross source.
Hi everyone,
I'm facing the following error on my test project trying to use CDI beans with Kumuluzee :
...2018-03-08 10:31:54.693 INFO -- org.eclipse.jetty.server.Server -- Started @2852ms 2018-03-08 10:31:54.693 INFO -- com.kumuluz.ee.EeApplication -- KumuluzEE started successfully SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. 2018-03-08 10:32:00.185 WARNING -- com.sun.faces.lifecycle.ProcessValidationsPhase -- /input.xhtml @14,62 value="#{customerBean.id}": Target Unreachable, id javax.el.PropertyNotFoundException: /input.xhtml @14,62 value="#{customerBean.id}": Target Unreachable, identifier 'customerBean' resolved to null at com.sun.faces.facelets.el.TagValueExpression.getType(TagValueExpression.java:100) at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getConvertedValue(HtmlBasicInputRenderer.java:95) at javax.faces.component.UIInput.getConvertedValue(UIInput.java:1046) at javax.faces.component.UIInput.validate(UIInput.java:976) at javax.faces.component.UIInput.executeValidate(UIInput.java:1249) at javax.faces.component.UIInput.processValidators(UIInput.java:712) at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261) at javax.faces.component.UIForm.processValidators(UIForm.java:253) at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261) at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261) at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:1195) at com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:76) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:860) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650) at org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:181) at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1629) at com.kumuluz.ee.common.filters.PoweredByFilter.doFilter(PoweredByFilter.java:43) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.Server.handle(Server.java:530) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626) at java.lang.Thread.run(Unknown Source) Caused by: javax.el.PropertyNotFoundException: Target Unreachable, identifier 'customerBean' resolved to null at com.sun.el.parser.AstValue.getTarget(AstValue.java:174) at com.sun.el.parser.AstValue.getType(AstValue.java:86) at com.sun.el.ValueExpressionImpl.getType(ValueExpressionImpl.java:201) at org.jboss.weld.el.WeldValueExpression.getType(WeldValueExpression.java:93) at com.sun.faces.facelets.el.TagValueExpression.getType(TagValueExpression.java:98) ... 49 more
My POM has the following settings:
`...
4.0.0
mz.co.tester
nimbus
0.0.1-SNAPSHOT
war
nimbus
a test project
<url>http://testproject.org</url>
<licenses>
<license>
<name>Apache License, Version 2.0</name>
<distribution>repo</distribution>
<url>http://www.apache.org/licenses/LICENSE-2.0.html</url>
</license>
</licenses>
<properties>
<!-- Explicitly declaring the source encoding eliminates the following
message: -->
<!-- [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
resources, i.e. build is platform dependent! -->
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<kumuluzee.version>2.5.2</kumuluzee.version>
<failOnMissingWebXml>false</failOnMissingWebXml>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-bom</artifactId>
<version>${kumuluzee.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<!-- kumuluzee -->
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-core</artifactId>
</dependency>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-servlet-jetty</artifactId>
</dependency>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-jsp-jetty</artifactId>
</dependency>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-jsf-mojarra</artifactId>
</dependency>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-el-uel</artifactId>
</dependency>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-jax-rs-jersey</artifactId>
</dependency>
<dependency>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-cdi-weld</artifactId>
</dependency>
</dependencies>
<build>
<finalName>nimbus</finalName>
<plugins>
<!-- <plugin> -->
<!-- <groupId>com.kumuluz.ee</groupId> -->
<!-- <artifactId>kumuluzee-maven-plugin</artifactId> -->
<!-- <version>${kumuluzee.version}</version> -->
<!-- <executions> -->
<!-- <execution> -->
<!-- <id>package</id> -->
<!-- <goals> -->
<!-- <goal>repackage</goal> -->
<!-- </goals> -->
<!-- </execution> -->
<!-- </executions> -->
<!-- </plugin> -->
<plugin>
<groupId>com.kumuluz.ee</groupId>
<artifactId>kumuluzee-maven-plugin</artifactId>
<version>${kumuluzee.version}</version>
<executions>
<execution>
<id>package</id>
<goals>
<goal>copy-dependencies</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
The CustomerBean
`.. import java.io.Serializable;
import java.util.List;
import javax.enterprise.context.SessionScoped;
import javax.inject.Named;
@nAmed
@SessionScoped
public class CustomerBean implements Serializable {
/**
*
*/
private static final long serialVersionUID = -7279629389399167678L;
/**
* @return the id
*/
public String getId() {
return id;
}
/**
* @param id the id to set
*/
public void setId(String id) {
this.id = id;
}
/**
* @return the firstName
*/
public String getFirstName() {
return firstName;
}
/**
* @param firstName the firstName to set
*/
public void setFirstName(String firstName) {
this.firstName = firstName;
}
/**
* @return the lastName
*/
public String getLastName() {
return lastName;
}
/**
* @param lastName the lastName to set
*/
public void setLastName(String lastName) {
this.lastName = lastName;
}
private String id;
private String firstName;
private String lastName;
public CustomerBean() {
}
public CustomerBean(String id, String firstName, String lastName) {
this.id = id;
this.firstName = firstName;
this.lastName = lastName;
}
// TODO: implement getters and setters
public void addCustomer() {
Customer customer = new Customer();
customer.setId(this.getId());
customer.setFirstName(this.getFirstName());
customer.setLastName(this.getLastName());
Database.addCustomer(customer);
this.setId(null);
this.setFirstName(null);
this.setLastName(null);
}
public List<Customer> getCustomers()
{
return Database.getCustomers();
}
@Override
public String toString() {
return "Customer {\n" +
" id='" + id + "',\n" +
" firstName='" + firstName + "',\n" +
" lastName='" + lastName + "'\n" +
"}";
}
}
`
But when I change the @nAmed by @ManagedBean it works. Since I would like to stick with CDI only this I would like to solve this issue. I've been facing this issues for some days now , any help or hint to solve it will deeply appreciated.
Thanks in advance.
Hello people,
I'm trying to make a simple app work with microprofile, however every time I start the project with beans.xml it launches an exeptcion according to the log.
The strange thing is I tested the example from the repository and it is working.
my project only works when I remove beans.xml
Java version : (build 25.151-b12)
OS Ubuntu 16.04
Eclipse Oxygen
Maven : 3.5.0
2017-11-29 19:03:42.097 INFO -- org.eclipse.jetty.webapp.StandardDescriptorProcessor -- NO JSP Support for /, did not find org.eclipse.jetty.jsp.JettyJspServlet
2017-11-29 19:03:42.225 INFO -- org.jboss.weld.environment.servlet.EnhancedListener -- WELD-ENV-001008: Initialize Weld using ServletContainerInitializer
2017-11-29 19:03:42.253 INFO -- org.jboss.weld.bootstrap.WeldStartup -- WELD-000900: 2.4.4 (Final)
2017-11-29 19:03:42.305 INFO -- org.jboss.weld.environment.deployment.discovery.DiscoveryStrategyFactory -- WELD-ENV-000020: Using jandex for bean discovery
2017-11-29 19:03:42.438 WARN -- org.jboss.weld.environment.deployment.discovery.DefaultBeanArchiveScanner -- WELD-ENV-000002: Could not read resource with name: jar:file:/home/daniel/git/SouJava/soujava{RIO}/soujava-rio-labs/microprofile/kumuluzee/target/kumuluzEE-sample-0.0.1-SNAPSHOT.jar!/META-INF/beans.xml
java.net.URISyntaxException: Illegal character in opaque part at index 41: jar:file:/home/daniel/git/SouJava/soujava{RIO}/soujava-rio-labs/microprofile/kumuluzee/target/kumuluzEE-sample-0.0.1-SNAPSHOT.jar!/META-INF/beans.xml
at java.net.URI$Parser.fail(URI.java:2848)
at java.net.URI$Parser.checkChars(URI.java:3021)
at java.net.URI$Parser.parse(URI.java:3058)
at java.net.URI.<init>(URI.java:588)
at java.net.URL.toURI(URL.java:946)
at org.jboss.weld.environment.deployment.discovery.DefaultBeanArchiveScanner.getBeanArchiveReference(DefaultBeanArchiveScanner.java:96)
at org.jboss.weld.environment.deployment.discovery.DefaultBeanArchiveScanner.scan(DefaultBeanArchiveScanner.java:79)
at org.jboss.weld.environment.servlet.deployment.WebAppBeanArchiveScanner.scan(WebAppBeanArchiveScanner.java:73)
at org.jboss.weld.environment.deployment.discovery.AbstractDiscoveryStrategy.performDiscovery(AbstractDiscoveryStrategy.java:86)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.createDeployment(WeldServletLifecycle.java:312)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize(WeldServletLifecycle.java:163)
at org.jboss.weld.environment.servlet.EnhancedListener.onStartup(EnhancedListener.java:62)
at org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup(ContainerInitializer.java:140)
at org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(ServletContainerInitializersStarter.java:63)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:329)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1501)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1463)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:785)
at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:261)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
at org.eclipse.jetty.server.Server.start(Server.java:452)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:105)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.Server.doStart(Server.java:419)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at com.kumuluz.ee.jetty.JettyServletServer.startServer(JettyServletServer.java:80)
at com.kumuluz.ee.EeApplication.initialize(EeApplication.java:343)
at com.kumuluz.ee.EeApplication.<init>(EeApplication.java:70)
at com.kumuluz.ee.EeApplication.main(EeApplication.java:82)
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 com.kumuluz.ee.loader.EeClassLoader.invokeMain(EeClassLoader.java:444)
at com.kumuluz.ee.loader.EeBootLoader.launch(EeBootLoader.java:54)
at com.kumuluz.ee.loader.EeBootLoader.main(EeBootLoader.java:41)
2017-11-29 19:03:42.441 WARNING -- org.eclipse.jetty.annotations.ServletContainerInitializersStarter --
java.lang.NullPointerException
at org.jboss.weld.environment.deployment.discovery.DefaultBeanArchiveScanner.getBeanArchiveReference(DefaultBeanArchiveScanner.java:110)
at org.jboss.weld.environment.deployment.discovery.DefaultBeanArchiveScanner.scan(DefaultBeanArchiveScanner.java:79)
at org.jboss.weld.environment.servlet.deployment.WebAppBeanArchiveScanner.scan(WebAppBeanArchiveScanner.java:73)
at org.jboss.weld.environment.deployment.discovery.AbstractDiscoveryStrategy.performDiscovery(AbstractDiscoveryStrategy.java:86)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.createDeployment(WeldServletLifecycle.java:312)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize(WeldServletLifecycle.java:163)
at org.jboss.weld.environment.servlet.EnhancedListener.onStartup(EnhancedListener.java:62)
at org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup(ContainerInitializer.java:140)
at org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(ServletContainerInitializersStarter.java:63)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:329)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1501)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1463)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:785)
at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:261)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
at org.eclipse.jetty.server.Server.start(Server.java:452)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:105)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.Server.doStart(Server.java:419)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at com.kumuluz.ee.jetty.JettyServletServer.startServer(JettyServletServer.java:80)
at com.kumuluz.ee.EeApplication.initialize(EeApplication.java:343)
at com.kumuluz.ee.EeApplication.<init>(EeApplication.java:70)
at com.kumuluz.ee.EeApplication.main(EeApplication.java:82)
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 com.kumuluz.ee.loader.EeClassLoader.invokeMain(EeClassLoader.java:444)
at com.kumuluz.ee.loader.EeBootLoader.launch(EeBootLoader.java:54)
at com.kumuluz.ee.loader.EeBootLoader.main(EeBootLoader.java:41)
2017-11-29 19:03:42.442 WARNING -- org.eclipse.jetty.webapp.WebAppContext -- Failed startup of context o.e.j.w.WebAppContext@17695df3{/,jar:file:/home/daniel/git/SouJava/soujava%7bRIO%7d/soujava-rio-labs/microprofile/kumuluzee/target/kumuluzEE-sample-0.0.1-SNAPSHOT.jar!/webapp,UNAVAILABLE}
java.lang.RuntimeException: java.lang.NullPointerException
at org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(ServletContainerInitializersStarter.java:68)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:329)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1501)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1463)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:785)
at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:261)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
at org.eclipse.jetty.server.Server.start(Server.java:452)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:105)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.Server.doStart(Server.java:419)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at com.kumuluz.ee.jetty.JettyServletServer.startServer(JettyServletServer.java:80)
at com.kumuluz.ee.EeApplication.initialize(EeApplication.java:343)
at com.kumuluz.ee.EeApplication.<init>(EeApplication.java:70)
at com.kumuluz.ee.EeApplication.main(EeApplication.java:82)
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 com.kumuluz.ee.loader.EeClassLoader.invokeMain(EeClassLoader.java:444)
at com.kumuluz.ee.loader.EeBootLoader.launch(EeBootLoader.java:54)
at com.kumuluz.ee.loader.EeBootLoader.main(EeBootLoader.java:41)
Caused by: java.lang.NullPointerException
at org.jboss.weld.environment.deployment.discovery.DefaultBeanArchiveScanner.getBeanArchiveReference(DefaultBeanArchiveScanner.java:110)
at org.jboss.weld.environment.deployment.discovery.DefaultBeanArchiveScanner.scan(DefaultBeanArchiveScanner.java:79)
at org.jboss.weld.environment.servlet.deployment.WebAppBeanArchiveScanner.scan(WebAppBeanArchiveScanner.java:73)
at org.jboss.weld.environment.deployment.discovery.AbstractDiscoveryStrategy.performDiscovery(AbstractDiscoveryStrategy.java:86)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.createDeployment(WeldServletLifecycle.java:312)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize(WeldServletLifecycle.java:163)
at org.jboss.weld.environment.servlet.EnhancedListener.onStartup(EnhancedListener.java:62)
at org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup(ContainerInitializer.java:140)
at org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(ServletContainerInitializersStarter.java:63)
... 25 more
2017-11-29 19:03:42.476 INFO -- org.eclipse.jetty.server.AbstractConnector -- Started ServerConnector@397fbdb{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
2017-11-29 19:03:42.476 INFO -- org.eclipse.jetty.server.Server -- Started @1836ms
2017-11-29 19:03:42.476 INFO -- com.kumuluz.ee.EeApplication -- KumuluzEE started successfully
Hi,
When we returning JsonObject from JAX-RS , we get following json message in kumuluz. Where if I run same code in other micro profile like wildfly-swarm or payara, I got different json output. So my question is how can I got same response with kumuluz using JsonObject ???
@GET
public Response ping() {
JsonObject jsonObject = Json.createObjectBuilder()
.add("message", "Hello Java Microprofile.")
.build();
return Response.ok(jsonObject).build();
}Kumuluz output
{
"message": {
"valueType": "STRING",
"string": "Hello Java Microprofile.",
"chars": "Hello Java Microprofile."
}
}wildfly-swarm
{
"message": "Hello Java Microprofile."
}
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.