When multiple services are running in Docker, then host/port could vary with each run. Changing application.yaml will require the archive to be bundled again. It would be useful to provide host/port that can be either picked up programmatically or passed from pom.xml.

I started the Snoop service in a Docker container (which is running in Vagrant because I'am working on a Windows machine) with the following command:

docker run -it -d -p 8081:8080 ivargrimstad/snoop-service

It starts successfully and is then accessible via the browser on: http://localhost:8081/snoop-service.

Next, I created a new project (source attached) and trying to start it in a Glassfish 4.1.1 instance. This fails, the output from IntelliJ:

C:\Tools\glassfish-4.1.1\glassfish\bin\asadmin.bat start-domain domain1
[2015-10-29 11:11:34,733] Artifact untitled5:war: Server is not connected. Deploy is not available.
Detected server admin port: 4848
Detected server http port: 8080
Attempting to start domain1.... Please look at the server log for more details.....
Connected to server
[2015-10-29 11:11:43,213] Artifact untitled5:war: Artifact is being deployed, please wait...
[2015-10-29 11:12:12,272] Artifact untitled5:war: Error during artifact deployment. See server log for details.
[2015-10-29 11:12:12,273] Artifact untitled5:war: java.io.IOException: com.sun.enterprise.admin.remote.RemoteFailureException: Error occurred during deployment: Exception while loading the app : javax.ejb.CreateException: Initialization failed for Singleton SnoopRegistrationClient. Please see server.log for more details.

Glassfish server log: https://www.dropbox.com/s/vokck0xl3sri3cl/server.log?dl=0 Source code: https://www.dropbox.com/s/j99azkh724ef9u9/source.zip?dl=0

The SnoopProducer reads the config .yaml file from classpath by using this.getClass().getClassloader() which IMHO is not appropriate within JEE. This should be done by using the current threads classloader. This way you don't make any assumptions whether the classloader which loaded the SnoopProducer is still available for loading the config.

Please see: http://jeecookbook.blogspot.de/2013/07/java-why-you-should-not-use.html

Snoop Docker container shows the following message:

14:49:16,825 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017534: Registered web context: /snoop-service
14:49:16,932 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "snoop-service-1.0.0-SNAPSHOT.war" (runtime-name : "snoop-service-1.0.0-SNAPSHOT.war")
14:49:16,968 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
14:49:16,970 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
14:49:16,970 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.2.0.Final "Tweek" started in 9054ms - Started 327 of 380 services (92 services are lazy, passive or on-demand)

This shows that the image is still based on WildFly 8.2.0.Final.

Please move this to WildFly 9.0.0.Final.

It would be really neat if:

• SnoopEE service endpoints broadcast themselves via multicast to the current subnet
• SnoopEE in the consuming application listened for these heartbeats
• The CDI SnoopEE proxy in the consuming application chose a service endpoint based on the current heartbeat activity
• If a heartbeat dies, the CDI SnoopEE proxy would stop sending traffic there
• If a heartbeat is added, the CDI SnoopEE proxy starts sending traffic there

Cheers,

Let multiple instances of the SnoopEE service share service registers and keep track of each other Return list of available SnoopEE services to client services on heartbeat SnoopServiceClient should loop through SnoopEE services in list until one responds

Names to consider renaming (may be more):

@Snoop SnoopProducer SnoopDiscoveryClient SnoopApplicationClient

Also consider introducing interfaces where approprieate