Closed robinroos closed 5 years ago
Have you tested your built jar in your application that is having issues? I'd like to avoid doing release after release just for logging information until your problem is determined.
No.
I am unable to deploy code into our Swarm except by building the product with artefacts from maven and jcenter.
I have, however, reviewed the output this logging generates in the Travis CI build. Extracts of those are appended as a comment to Issue #30.
I believe this diagnostic information will be instrumental in getting us up and running before the morning. I doubt I will find any actual logic issues in hazelcast-docker-swarm-discovery-spi, but any lessons learned about setup and configuration will be fed back to you as before.
If you already have access to your maven's build file, then you should be able to do something like this
<dependency>
<groupId>com.sample</groupId>
<artifactId>sample</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/src/main/resources/yourJar.jar</systemPath>
</dependency>
My organisation does not run its own maven repo and, although I own entirely the application and its stack, I have only limited visibility to Jenkins and no access other than log visibility in the deployed test environments.
It would be great if I was set up to run a local daily Coker swarm, but no one in my team can do so at this stage.
Also, since our use-case warranted functional commits in RC11 I expect you guys would be eager to see positive results from such usage.
I am as high up as it gets in our organization’s Java team; whilst I do look to further improve our processes there are significant limits to what I can achieve in the next six or so hours.
Add diagnostic logging within SwarmDiscoveryUtil.discoverContainersViaCriteria() as a means to resolving Issue #30 ("NPE at SwarmMemberAddressProvider line 237").