Develop Reference

AWS ElasticBeanstalk Play Framework 2.8.8 deployment issue with CheckProcfileForJavaApplication

Trying to deploy a Play Framework based Application using an ELB container
Recently it seems that AWS made changes to the way ELB works as we've done this before without issue.
The error we currently get is:
2021/12/14 23:00:15.705423 [INFO] Executing instruction: CheckProcfileForJavaApplication
2021/12/14 23:00:15.705468 [ERROR] An error occurred during execution of command [app-deploy] - [CheckProcfileForJavaApplication]. Stop running the command. Error: there is no Procfile and no .jar file at root level of your source bundle
2021/12/14 23:00:15.705474 [INFO] Executing cleanup logic
2021/12/14 23:00:15.705598 [INFO] CommandService Response: {"status":"FAILURE","api_version":"1.0","results":[{"status":"FAILURE","msg":"Engine execution has encountered an error.","returncode":1,"events":[{"msg":"Instance deployment failed. For details, see 'eb-engine.log'.","timestamp":1639522815,"severity":"ERROR"}]}]}
Now of course I wouldn't be here if this was the actual problem
# cd /var/app/staging/server-xxxxxxxxxxx/
# ls -l
total 16
-rw-r--r-- 1 webapp webapp 135 Dec 14 20:39 Procfile
drwxr-xr-x 2 webapp webapp 82 Dec 14 22:21 bin
drwxr-xr-x 2 webapp webapp 113 Dec 14 22:21 conf
drwxr-xr-x 2 webapp webapp 8192 Dec 14 22:21 lib
drwxr-xr-x 3 webapp webapp 17 Dec 14 22:21 share
So Procfile exists
Hmmm is it valid however?
Let's check that out:
# cat Procfile
web: bin/server -v -J-Xms512M -J-Xmx2048m -J-server -Dhttp.port=5000 -Dhttps.port=8443 -Dconfig.resource=application.conf
Looks normal enough -- but does it actually work?
Short answer is yes -- if I copy and paste that command (minus the "web:" prefix of course) system comes up without any issues (ELB still fails to realize that though...)
I've tried a few variants of the command thinking that it might be related to yaml formatting of perhaps a tighter regex ^[A-Za-z0-9_-]+:\s*[^\s].*$ (source: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/platforms-linux-extend.html)
web: bin/server
web: ./bin/server
web: bin/server
web: ./bin/server
web:bin/server
web:./bin/server
No difference (both worked when manually started without or without the leading ./ btw)
Unsure how I move forward here?
How do we find what the real problem is so that we have fighting chance to fix it?
And yes -- the initial trace above is already the output of eb-engine.log
Using (in case this is relevant)
Coretto Java 11
Play 2.8.8
Scala 2.13.6
SBT 1.5.2
Will answer any relevant queries that help improve this question and any chance of resolving it. Most Google searches I've dug through are related to other environments and are simply a missing Procfile...

I have worked out the following work-around to be able to use a standard (well slightly modified) Play Framework dist directly in an AWS ELB Java container
We start with the typical sbt dist process to create a zip "distribution" file
That file won't work in the format it is currently in (I've been researching and I will be asking specific questions to see if making it work directly might be possible) however it only takes a few small tweaks to get it to work
First Step: Modify Procfile (a file that you manually create and place in the project's dist directory) as follows:
web: chmod 700 bin/server; bin/server -v -J-Xms512M -J-Xmx2048m -J-server -Dpidfile.path=/dev/null -Dhttp.port=5000 -Dconfig.resource=application.conf
Note the chmod 700 bin/server; that was the final secret sauce required to make this work! I was kinda shocked that it did work actually. I did not think that would get past the regex they use to parse the Procfile
As a zip file is permissions agnostic, once I finally got the elb install process to get past that first "missing jar" hurdle I noticed the permissions on bin/server were simply rw. The ec2 instance's /var/log/eb-engine.log did not quite spell that out too clearly, however I confirmed that whenever I manually modified those permissions (on the ec2 instance) and then ran the bin/server command (to verify it) the Play server would start right away (however the elb container still failed to see it as a legitimate process and continued to report it as Status of no data, nor did it allow the load balancer to send it traffic so this "fix" was a real shot in the dark!)
Second step: Unzip that zip file and cd into the directory it created/assigned
cd server-vxxxxxxxxxxxxxx
touch placeholder.jar
The second dab of secret sauce is that the placeholder.jar file is simply a means to satisfy the CheckProcfileForJavaApplication which simply looks for the existence of any file named *.jar in the root of the bundled directory. If that file does not exist then the elb install script stops dead in it's tracks.
Note: You could simply place this empty placeholder.jar file in the Play dist folder if you prefer
Third Step: Create a new zip file elb.zip
zip --exclude share/doc/api/\* -r elb.zip .
Now take elb.zip and upload it to an AWS ELB container and low and behold it (finally) springs to life!

Azure DevOps JavaToolInstaller - Can't get jdkDestinationDirectory Right

My first version (in azure-pipelines.yml) targeted the tempDirectory/bin folder:
- task: JavaToolInstaller#0
inputs:
versionSpec: '11'
jdkArchitectureOption: 'x64'
jdkSourceOption: LocalDirectory
jdkFile: "JDK Bin.zip"
jdkDestinationDirectory: "$(agent.tempDirectory)/bin"
cleanDestinationDirectory: true
and I was rewarded with
Retrieving the JDK from local path.
Creating destination folder: I:\Agent-Win-A\_work\_temp\jdk
Extracting file: I:\Agent-Win-A\_work\1637\s\JDK Bin.zip
[command]I:\Agent-Win-A\_work\_tasks\JavaToolInstaller_c0e0b74f-0931-47c7-ac27-7c5a19456a36\0.151.2\FileExtractor\7zip\7z.exe x -oI:\Agent-Win-A\_work\_temp\jdk "I:\Agent-Win-A\_work\1637\s\JDK Bin.zip"
7-Zip [64] 16.00 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-10
Scanning the drive for archives:
1 file, 8875164 bytes (8668 KiB)
Extracting archive: I:\Agent-Win-A\_work\1637\s\JDK Bin.zip
--
Path = I:\Agent-Win-A\_work\1637\s\JDK Bin.zip
Type = zip
Physical Size = 8875164
Everything is Ok
Folders: 1
Files: 121
Size: 21509208
Compressed: 8875164
(node:12092) Warning: Use Cipheriv for counter mode of aes-256-ctr
JAVA_HOME is being set to: I:\Agent-Win-A\_work\_temp\jdk\bin
JAVA_HOME_11_x64 is being set to: I:\Agent-Win-A\_work\_temp\jdk\bin
##[error]Directory does not exist: I:\Agent-Win-A\_work\_temp\jdk\bin\bin
##[error]Directory does not exist: I:\Agent-Win-A\_work\_temp\jdk\bin\bin
I have no idea where it gets that it should be looking for \bin\bin - it looks to me like everything is working as expected
My .zip file has this structure:
bin/
- server/
- somefile.dll
- *lots of dlls*
Anyone know where I'm screwing up?

##[error]Directory does not exist: I:\Agent-Win-A_work_temp\jdk\bin\bin
The root cause of this issue could be that the JavaToolInstaller task hasn't created the correct destination folder.
Based on my test, I could run the task successfully with the same Yaml definition.
I notice that the task will create a destination folder: xxxx\Agent2\_work\_temp\bin\JAVA_HOME_11_x64_JDK Bin_zip
But in your case, it creates the wrong path: xxx\_work\_temp\jdk
According to your log, your are using the JavaToolInstaller task version : 0.151.2. This could be an old task version. I am using the version 0.177.0
You could try to navigate to I:\Agent-Win-A\_work\_tasks and find the folder JavaToolInstallerxxxx. Then you could delete it and re-run the pipeline.
The pipeline will download the latest version of the JavaToolInstaller task automatically.

Cloud Foundry java buildpack - java: command not found

New to cloud foundry, using the java buildpack to push a zip distribution of a java app. It detects the start script correctly, but when the start script gets to the point where it needs to start up the jvm, I get this error:
bash: java: command not found
Apparently 'java' is not on the shell's path during execution of the script, and I'm not finding a JAVA_HOME definition anywhere.
What is the path to use for starting java apps?
Where is it documented?
FALSE ALARM
Many thanks to #DanielMikusa for pointing out that JAVA_HOME is indeed set, even in the pretty old version of the buildpack that was in use. Nothing to see here.
EDIT #1
I've been able to find out that when the start script launches there is a jre located in $PWD/.buildpack-java/oracle_jre. But, this can't be what I'm expected to use to specify for the path of JAVA_HOME, can it? It seems like this location is entirely dependent on the java buildpack's current implementation. It seems like either the jre's bin folder should be in the start script's process' path or that there should be an environment variable or other configuration established prior to running the launch script so I can use that value for finding the java executable.
EDIT #2
Below is the output during the cf push operation:
PS E:\dev\hoobajoob\myproject\build\distributions> cf push -p .\my-service-1.0.0.zip my-service
Using manifest file E:\dev\hoobajoob\myproject\build\distributions\manifest.yml
Creating app my-service in org DEV / space dev as chefhoobajoob#github.com...
OK
Creating route my-service.cflab.dctmlabs.com...
OK
Binding my-service.cflab.dctmlabs.com to my-service...
OK
Uploading my-service...
Uploading app files from: C:\Users\hoobajoob\AppData\Local\Temp\unzipped-app384867239
Uploading 9.7M, 9390 files
Done uploading
OK
Starting app my-service in org DEV / space dev as chefhoobajoob#github.com...
Downloading oracle_buildpack_151...
Downloading binary_buildpack...
Downloading go_buildpack...
Downloading python_buildpack...
Downloading java-buildpack-offline-v3-19-2...
Downloaded java-buildpack-offline-v3-19-2
Downloading java-buildpack-offline-4-7...
...<more downloads>
Creating container
Successfully created container
Downloading app package...
Downloaded app package (53.1M)
Staging...
-----> Java Buildpack Version: v3.5.1 (offline) | https://github.com/cloudfoundry/java-buildpack.git#3abc3db
-----> Downloading Oracle JRE 1.8.0_112 from http://127.0.0.1/oracle-jre/trusty/x86_64/jre-8u112-linux-x64.tar.gz (found
in cache)
Expanding Oracle JRE to .java-buildpack/oracle_jre (2.3s)
-----> Downloading Open JDK Like Memory Calculator 2.0.1_RELEASE from https://download.run.pivotal.io/memory-calculator/
trusty/x86_64/memory-calculator-2.0.1_RELEASE.tar.gz (found in cache)
Memory Settings: -Xms2304M -XX:MetaspaceSize=314572K -Xss1M -Xmx2304M -XX:MaxMetaspaceSize=314572K
-----> Downloading Spring Auto Reconfiguration 1.10.0_RELEASE from https://download.run.pivotal.io/auto-reconfiguration/
auto-reconfiguration-1.10.0_RELEASE.jar (found in cache)
Exit status 0
Staging complete
Uploading droplet, build artifacts cache...
Uploading droplet...
Uploading build artifacts cache...
Uploaded build artifacts cache (108B)
Uploaded droplet (120.5M)
Uploading complete
Destroying container
Successfully destroyed container
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
1 of 1 instances running
App started
OK
App my-service was started using this command `CALCULATED_MEMORY=$($PWD/.java-buildpack/oracle_jre/bin/java-buildpack-memory-calculator-2.0.1_RELEASE -memorySizes=metaspace:64m.. -memoryWeights=heap:75,metaspace:10,native:10,stack:5 -memoryInitials=heap:100%,metaspace:100% -totMemory=$MEMORY_LIMIT) && JAVA_HOME=$PWD/.java-buildpack/oracle_jre JAVA_OPTS="-Djava.io.tmpdir=$TMPDIR -XX:OnOutOfMemoryError=$PWD/.java-buildpack/oracle_jre/bin/killjava.sh $CALCULATED_MEMORY" exec $PWD/my-service-1.0.0/bin/launch`

Writing up the comments above in case someone else comes across this question.
We reviewed the full output of staging and the start up command generated by the Java buildpack.
We could see from the start command generated by the Java buildpack that it is the start commands responsibility to set JAVA_HOME.
If you rely on the Java buildpack to create the start command for your dist-zip style applications, it will "do the right thing" and add the JAVA_HOME environment variable with the correct path to the start command.
If you need to create a custom start command, it is your responsibility to set JAVA_HOME correctly.
If you cf ssh into an application started by the Java buildpack, it is your responsibility to set JAVA_HOME.

JacORB 3.2 NameService (ns) seems not to read "orb.properties" file

I've got a problem with JacORB 3.2 as it seems that it doesn't read the orb.properties file, and especially the ORBInitRef.NameService property.
As stated in the documentation on chapter 3.1, JacORB automatically searches for the orb.properties file in three locations: the "java.home"/lib directory, the "user.home" directory and inside the classpath.
This is the evidence that I'm not totally drunk:
Java command:
System.out.println(System.getProperty("java.home"));
System.out.println(System.getProperty("user.home"));
Output:
/usr/lib/jvm/jdk1.7.0/jre
/home/emanuele
Bash command:
ls /usr/lib/jvm/jdk1.7.0/jre/lib | grep orb.properties ; ls /home/emanuele | grep orb.properties
Output:
jacorb.properties
orb.properties
jacorb.properties
orb.properties
These four .properties file are exactly the same. Please have a look at the URI of the file that contains the reference (IOR) of the NameService:
ORBInitRef.NameService=file:/tmp/CORBA/NS_Ref
The problem is that, when I try to launch the NameService without any parameter (ns) I got these error messages:
giu 05, 2013 9:56:51 PM org.jacorb.naming.NameServer main
SEVERE: unexpected exception
java.io.FileNotFoundException: c:/NS_Ref (No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:212)
at java.io.FileOutputStream.<init>(FileOutputStream.java:104)
at org.jacorb.naming.NameServer.main(NameServer.java:320)
java.lang.RuntimeException: c:/NS_Ref (No such file or directory)
at org.jacorb.naming.NameServer.main(NameServer.java:335)
Of course, if I explicitely pass the URI through console, everything goes fine
ns -Djacorb.naming.ior_filename=/tmp/CORBA/NS_Ref
The very strange thing is that, after the NameService is running, EVERY OTHER OBJECT can correctly and automatically resolve the initial reference of the NameService.
NamingContextExt nc = NamingContextExtHelper.narrow(orb.resolve_initial_references("NameService"));
The previous Java code returns a valid object. That does not make any sense for me.
And why does the NameService try to write its IOR inside a random file like C:\NS_Ref while I'm on Linux?
Any idea?

I thing you mixed up some different things in your question.
The location of the NS's IOR
The ability to read and use this IOR by other programs
First. Starting the NamingService is not affected by option ORBInitRef.NameService or any related commandline option. If you want the NamingService to drop it's IOR in a file, use
# The file where the name server drops its IOR
jacorb.naming.ior_filename=file:///tmp/CORBA/NS_Ref
as you already did. If this behaves different when using this as cmdline option, see 2.
Second. JacORB its config files are not OS specific - there is a mix of both Linux and Windows style. Don't rely on that.
Your call to ns will call the jaco script in JacORBs bin directory. Activate the verbosity stuff at the end of the file, then start ns again and see which jre and jacorb.home are really used. Look for configs. Remove ALL other configs you do not need.
Retry.

This
ns -Djacorb.naming.ior_filename=/tmp/CORBA/NS_Ref
looks fine, but shouldn't that
ORBInitRef.NameService=file:/tmp/CORBA/NS_Ref
read file:///tmp/CORBA/NS_Ref?
And this
c:/NS_Ref
is strange on Linux; that looks very windowzy to me; are you sure you've not mixed Win and Linux config files?

How do you make installer when the project is using many other dependencies in Java?

My main application is written in Java, which has Main.jar. I am preparing final package for deploy.
But it has other dependencies such as third party libraries need to be first available /pre-installed in Windows operating system, once that is installed my application can run, else it will show error and will not work. So i am struggling, end user has to do:
1) Thirdparty.library.msi (install manually) which is a GUI installer itself already
2) Then setup my Main.jar
3) Once it started it looks first for the third party libraries, if does not exist, software fails.
For such case, Is there any proper way to make one installer which can do the job as step 1 and then step 2, but both look like 1 installation?
Follow up: i also want my third party is not visible to the end user for presentation purpose. So i saw there is a tool exists called msi
1) Installer prepare for BATCH
Windows ® Installer. V 3.01.4000.1823
msiexec /Option <Required Parameter> [Optional Parameter]
Install Options
</package | /i> <Product.msi>
Installs or configures a product
/a <Product.msi>
Administrative install - Installs a product on the network
/j<u|m> <Product.msi> [/t <Transform List>] [/g <Language ID>]
Advertises a product - m to all users, u to current user
</uninstall | /x> <Product.msi | ProductCode>
Uninstalls the product
Display Options
/quiet
Quiet mode, no user interaction
/passive
Unattended mode - progress bar only
/q[n|b|r|f]
Sets user interface level
n - No UI
b - Basic UI
r - Reduced UI
f - Full UI (default)
/help
Help information
Restart Options
/norestart
Do not restart after the installation is complete
/promptrestart
Prompts the user for restart if necessary
/forcerestart
Always restart the computer after installation
Logging Options
/l[i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] <LogFile>
i - Status messages
w - Nonfatal warnings
e - All error messages
a - Start up of actions
r - Action-specific records
u - User requests
c - Initial UI parameters
m - Out-of-memory or fatal exit information
o - Out-of-disk-space messages
p - Terminal properties
v - Verbose output
x - Extra debugging information
+ - Append to existing log file
! - Flush each line to the log
* - Log all information, except for v and x options
/log <LogFile>
Equivalent of /l* <LogFile>
Update Options
/update <Update1.msp>[;Update2.msp]
Applies update(s)
/uninstall <PatchCodeGuid>[;Update2.msp] /package <Product.msi | ProductCode>
Remove update(s) for a product
Repair Options
/f[p|e|c|m|s|o|d|a|u|v] <Product.msi | ProductCode>
Repairs a product
p - only if file is missing
o - if file is missing or an older version is installed (default)
e - if file is missing or an equal or older version is installed
d - if file is missing or a different version is installed
c - if file is missing or checksum does not match the calculated value
a - forces all files to be reinstalled
u - all required user-specific registry entries (default)
m - all required computer-specific registry entries (default)
s - all existing shortcuts (default)
v - runs from source and recaches local package
Setting Public Properties
[PROPERTY=PropertyValue]
OR
2) Practical/samples
# Install Silently [works]:
C:\windows\system32\msiexec.exe /I "C:\Documents and Settings\sun\My Documents\Downloads\10.70.msi" /QN
C:\windows\system32\msiexec.exe /I "C:\Documents and Settings\sun\My Documents\Downloads\10.71.msi" /QN
# For future reference [not tested]
start /wait msiexec /i O12Conv.msi /qb
start /wait msiexec /p O12Convsp1-en-us.msp /qb
start /wait msiexec /i mpsetupedp.msi
# other samples [not tested]
msiexec /package Application.msi /quiet
msiexec /uninstall Application.msi /quiet
msiexec /update msipatch.msp /quiet
msiexec /uninstall msipatch.msp /package Application.msi / quiet

All UI based installation tools have ability to run external programs and to run in batch mode that is controlled by command line arguments.
So, if your thirdparty.msi is what you have and have to use I's suggest you to find the ability to run it in a batch mode. Then create your own installation procedure that will invoke this 3rd party MSI.
There are various tools that for creating UI based installations programs (InstallShieled, InstallAnywhere etc).

How about creating a DOS batch script(.bat) and call the msi installer and JAR in that particular order from there?.

there is a way to check if the dependent app is installed [like an env variable being set]. If not then the packaging script can install it. I have done this in Install Shield; not sure about other tools.