hammock-project / hammock Goto Github PK

Metrics is a popular tool for gather statistics for your running JVMs. The Metrics CDI project adds CDI support. Hammock should provide integration for the project.

Allow an app to automatically register configuration sources from Tamaya.

Library upgrades

https://www.versioneye.com/user/projects/583af3ebe7cea00045b893ad?child=summary

• Hibernate
• Jersey
• AssertJ
• Mockito
• Undertow
• Spark
• Tomcat

Make the REST URI configurable.

• RestEasy

• CXF

• Jersey

Add a module to enable Jersey integration as an alternative to other JAX-RS implementations.

Add new JPA Provider - OpenJPA

Reassert the copyright. Allow copyright claims to be retained by contributors for their contributions. Added a NOTICE file as well.

Need to load multiple property files by default. This includes the CLI, apache-deltaspike.properties and various locations of hammock.properties.

SSL tests are missing for Tomcat, Jetty.

Ensures consistent maven in use, no need to install extra components.

Parallel Universe' Capsule (http://www.capsule.io/) is an open-source packaging and deployment tool for JVM applications.

IMO Capsule packaging is better than common fat jar created by Maven Shade plugin. Capsule provides nested jar, there are no file name conflicts, no need to merge same files into single one.

Add an arquillian extension for simplified deployment.

Based on https://github.com/apache/activemq-artemis/blob/master/docs/user-manual/en/cdi-integration.md , add support for CDI and messaging platform Artemis.

Add EclipseLInk as a supported JPA Provider.

JNDI server is mandatory if we want to add feature like #24 and JTA support.

The 0.0.3 release accidentally brought in arquillian dependencies at compile scope, instead of test scope.

Hammock should be able to secure the rest services through TLS sockets.
The configuration should be done in a property file in apache deltaspike.
The certificates should be provided by the client and loaded through the available classpath.

For example, in order to open the https port, the following properties can be placed in a hammock.property file in classpath:

webserver.port=80
webserver.secured.port=443
webserver.keystore.path=/keystore.jks
webserver.keystore.type=JKS
webserver.keystore.password=mypassword
webserver.truststore.path=/truststorejks
webserver.truststore.type=JKS
webserver.truststore.password=mypassword

When #35 was brought in, it introduced an injection point for EntityManager.

This worked, however it meant that datasources and entity managers couldn't share names (the @Named annotation has this restriction). To deal with this, introduce a new @Database annotation that includes the name.

Various library upgrades that align to the 0.5.0 release.

Add the ability to run tests with a random port number for the webserver.

Add support for spark-java as a REST implementation.

It should be possible to load static resources. Currently, undertow can load from the file system in a direct URI. Figure out what would be needed to add resource loading as well from the classpath.

Great work! What do I have to do to so that undertow serves static files (css, images), too? I've tried to set a different ResourceManager on DeploymentInfo, but it doesn't work (I debugged it and ResourceManager#getResource method is never executed).

• Hystrix configuration

It seems that the ApplicationPath annotation value is ignored (from the rest Application class).

For example, the test ws.ament.hammock.rest.resteasy.ResteasyTest still passes, even if you change the class ws.ament.hammock.rest.resteasy.RestApp like this:
@ApplicationPath("/testme") @ApplicationScoped public class RestApp extends Application{ }

Expected result:
The path should be /testme/rest but instead is till /rest.

The beans.xml file is missing from the resteasy module.

For projects which will have only ws.ament.hammock:web-undertow and ws.ament.hammock:rest-resteasy the ws.ament.hammock.rest.resteasy.ResteasyServletContextAttributeProvider is not injected in weld. All requests will go though to the local files.

Add a beans.xml file in the ws.ament.hammock:rest-resteasy project.

If flyway is on the classpath, add a bean that can do flyway integration. Handle various extra options as well (properties being loaded) and what lifecycle methods should be invoked.

Spark Java 2.5.1 adds multiple application support. In fact, the way application was loaded in the past is broken in 2.5.1. So implement it as a multiple application tool.

In addition to weld, a number of other libraries are out of date: https://www.versioneye.com/user/projects/574cdc006497d90039ac460e

• Undertow 1.4.2
• Tomcat 8.5.5
• Rest Assured 3.0.1

Running the spark-java tests using the tomcat-test profile will fail. Likewise deploying an app based on it doesn't work.

Add a tomcat webserver.

This is not an issue but more like a hint. Weld Servlet might reuse an existing BeanManager. See also https://github.com/weld/core/blob/master/environments/servlet/tests/jetty/src/test/weld-se-coop/org/jboss/weld/environment/servlet/test/se/coop/BootstrapNotNeededTest.java. So that it's not necessary to implement custom listerners like ws.ament.hammock.web.spi.CDIListener but reuse the existing servlet container support.

For a better user experience with JPA and future database related feature, we should add a module allowing definition and thus automatic creation of a datasource.
Information would be read thru a CDI extension in a ProcessAnnotatedType observer.

To make this module useful we need a JNDI module (datasources are looked thru JNDI in JPA) and make sure that if we add eager instantiation of Persistence Units, it will be done after (probably in an AfterBeanDiscovery event)

Use an archetype to create a project from scratch. Could even be a project generator site.

Allow configuration to be passed in via the CLI.

Allow the RabbitMQ beans to leverage metrics integration if metrics-cdi is on the classpath.

This is similar to, possibly blocking, possibly duplicate to #35

The current strategy for JPA includes native Weld support via JpaInjectionServices, this works for @PersistenceContext etc, but not well for other use cases. I want to decouple the two. add weld support if needed, but also allow it to work without Weld.

Add JPA support, with a built in module that brings in Hibernate.

Pom versions should be parameterized wherever possible.

Add support for RabbitMQ's java client

The default JPA EntityManager is built using the following logic:

            PersistenceUnitInfo persistenceUnitInfo = builder
               .withClasses(jpaExtension.getEntityClasses())
               .withDataSource(dataSource)
               .loadAllProperties(createPrefix(DEFAULT_EMF),true)
               .build();
            PersistenceProvider provider = getPersistenceProvider();
            return provider.createContainerEntityManagerFactory(persistenceUnitInfo, emptyMap());

Where the datasource is loaded based on the PU's name. Other cases just use Persistence.createEntityManagerFactory(s, properties); to load the EMF. While can use the defined JPA standards for JDBC, using Hikari makes more sense by default. So this should be a supported case.

Upgrade to latest undertow.

Instead of having to call shrinkwrap directly, simplify Hammock setup by introducing a HammockArchive utility.

JAR at least that can be used with the microprofile defined feature set.

It would be great to have JPA support without needing persistence.xml.

OpenWebBeans is another CDI implementation. It would be great to use Hammock with it.

Provide an OOTB CORS filter that is rest service independent.
It should be configurable.

This is one idea, in the examples, but open to others
CORSFilter and associated configuration

If you run the jersey tests with jetty as a container, it fails on a 404. Resteasy works fine.