I am trying to deploy a guest executable but that executable is in a subfolder of my code directory like this below is xml snippet from my ServiceManifest.xml
<EntryPoint>
<ExeHost>
<Program>Anaconda\python.exe</Program>
<Arguments>InitialFiltering\back_testing_agent_python_consumer.py</Arguments>
<WorkingFolder>CodeBase</WorkingFolder>
<!-- Uncomment to log console output (both stdout and stderr) to one of the
service's working directories. -->
<!-- <ConsoleRedirection FileRetentionCount="5" FileMaxSizeInKb="2048"/> -->
</ExeHost>
</EntryPoint>
but whenever i try to deploy it upon my local cluster it throws
Microsoft.VisualStudio.Azure.Fabric.ApplicationProject.ProjectSystem.PackageException
. however if the exe is directly under the code folder like this
<Program>python.exe</Program>
then it works fine
Related
I have a standard Sprinb Boot project.
And in the folder: src/main/resources/tmp/my_file.json, i have a json that I read in my Java code.
File file = new File("src/main/resources/tmp/my_file.json");
When running it locally it goes perfectly
With Jib I create a docker image:
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>2.5.2</version>
<configuration>
<from>
<image>adoptopenjdk:11-jre-hotspot</image>
</from>
<to>
<image>xxx/my_project:${version}</image>
</to>
<container>
<creationTime>USE_CURRENT_TIMESTAMP</creationTime>
</container>
</configuration>
</plugin>
When I run the container, it gives me an error that it cannot find the file:
java.io.FileNotFoundException: src/main/resources/tmp/my_file.json (No such file or directory)
The "src/main/resources" folder is the standard location for static resources.
Should I add any extra configuration to Jib to make the file available?
You don't want your application to open a file based on the source project structure. At runtime (whether packaged as a JAR file or a container image), you won't have the src/ directory, and new File("src/...") will always fail. For example, even outside the Docker context, suppose you packaged your app as a runnable jar. Then running your app with java -jar <your-runnable.jar> will fail from the same error.
What Java folks usually do is to search files on a classpath, and this is pretty much the standard way to what you're trying to achieve. You can find many useful materials when you google "java get resources", but here are some references:
https://www.baeldung.com/java-classpath-resource-cannot-be-opened
https://docs.oracle.com/javase/8/docs/technotes/guides/lang/resources.html
https://mkyong.com/java/java-read-a-file-from-resources-folder/
As of now, Jib 2.7.0 is the latest.
The problem is not with Jib but with your code.
Put "src/main/resources/" on the class path -- this is a standard way. And modify your code as below:
File file = new File("tmp/my_file.json");
When Jib creates an image, it copies all the resources from "src/main/resources/" to a directory ("/app/resources") on the image and puts that directory on the class path while launching your application.
I have been searching around for this specific problem of mine. We have a folder that is on a shared folder on another server "\\server1\shares\web\images" and I want to link this folder into my web application in Jboss 7.2.2. I'm migrating from Jboss 4.2.2 to Jboss 7.2.2.
Here is my server.xml file from Jboss 4.2.2. You'll notice that the <Context> tag handles this link for me.
<Server>
<Service name="jboss.web">
<!-- ... -->
<Engine name="jboss.web" defaultHost="localhost">
<!-- ... -->
<Host name="myApp" autoDeploy="false" deployOnStartup="false"
deployXML="false" configClass="org.jboss.web.tomcat.security.config.JBossContextConfig">
<!-- ... -->
<Context path="/images" appBase="" docBase="\\server1\shares\web\images"
debug="99" reloadable="true" />
<!-- ... -->
</Host>
</Engine>
</Service>
My research has lead me to use modules, but I cannot figure out how to use the modules properly for this problem. Most examples shows how to provide some link to a folder on the same machine as the Jboss server is on.
So, am I suppose to use modules or is there another way of doing this?
I have developed an application via Java Web Start more or less according to this: How do I fix "missing Codebase, Permissions, and Application-Name manifest attribute" in my JNLP app? I have packed the jar with manifest.txt, etc..but in this way I have resolved missing attributes problem, and now I have other problem this message is always showed!! I checked "No show again" and each time I press button to execute and always is showed!! I
Adicionally this is my manifest file:
Manifest-Version: 1.0
Class-Path: .
Main-Class: com.zkteco.biometric.AccesoBiometrioAS2
Permissions: all-permissions
Codebase: http://192.168.111.25:8180/pos-web/
Application-Name: Biometrico
And my Jnlp File this:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://192.168.111.25:8180/pos-web/">
<information> <title>CajaPos</title> <vendor>xxx</vendor>
</information>
<security><all-permissions/>
</security>
<resources>
<j2se version="1.2+"/>
<jar href="xx.jar"
main="true" />
</resources
<application-desc main-class="ec.com.xx.pos" type="JavaFX">
<argument>XY</argument>
</application-desc>
</jnlp>
In this page after check the dialog is not showed again and works fine.
https://docs.oracle.com/javase/tutorial/deployment/webstart/deploying.html
Where XY change for each request because I generate jnlp-xml in a dynamically way with a servlet.
This is due to your Java settings. It is a security prompt. There’s nothing you can change in your application to prevent this dialog, it is up to the end-user to change their security settings to show/hide these dialog windows.
Edit: I also recommend migrating your app to a different delivery platform because Java Web Start is being violently turned off by Oracle.
I am trying to deploy Apache Archiva on my Server, but it just fails all the time.
specs:
os: ubuntu 10.04
tomcat: Apache Tomcat/6.0.24
jvm: 1.6.0_27-b27
$CATALINA_HOME : /usr/share/tomcat6
$CATALINA_BASE : /var/lib/tomcat6
$CATALINA_OPTS : "-Dappserver.home=$CATALINA_HOME -Dappserver.base=$CATALINA_BASE"
path to lib : $CATALINA_BASE/common/lib
#java -version
java version "1.6.0_27"
OpenJDK Runtime Environment (IcedTea6 1.12.3) (6b27-1.12.3-0ubuntu1~10.04.1)
OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)
Tomcat itself is up and running. I followed the instructions on this page, copied all the necessary jars to the lib (location specified above), created the archiva.xml in /var/lib/tomcat6/conf/Catalina/localhost/ with that content:
<Context path="/archiva" docBase="/var/lib/tomcat6/archiva/apache-archiva-1.4-M4.war">
<Resource name="jdbc/users"
auth="Container"
type="javax.sql.DataSource"
username="philipp"
password="xxx"
driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
url="jdbc:derby:////localhost:1527/archivausers;create=true" />
<Resource name="jdbc/archiva"
auth="Container"
type="javax.sql.DataSource"
username="philipp"
password="xxx"
driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
url="jdbc:derby://localhost:1527/archivadata;create=true" />
<Resource name="mail/Session"
auth="Container"
type="javax.mail.Session"
mail.smtp.host="localhost"/>
</Context>
After a click on »start« in the tomcat manager: FAIL - Application at context path /archiva could not be started
the last lines on the catalina.out are:
SCHWERWIEGEND: A web application created a ThreadLocal with key of type[java.lang.ThreadLocal] (value [java.lang.ThreadLocal#69bf9]) and a value of type [org.apache.logging.log4j.core.impl.Log4jLogEvent] (value [Logger=org.springframework.web.context.ContextLoader Level=ERROR Message=Context initialization failed]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
11.06.2013 16:29:30 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SCHWERWIEGEND: A web application created a ThreadLocal with key of type [null] (value [org.apache.logging.log4j.spi.DefaultThreadContextMap$1#1ea380c]) and a value of type [null] (value [null]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
I tried more or less everything what came to my mind, but always FAIL!
Any Idea?
Since I could manage to get it running I think it could be useful for somebody else to share the steps I have taken. These descriptions assume that one has already has read the official installation Instructions of archiva and should be a kind of additional explanation due to the fact that the official documentation could be a bit more verbose.
First I downloaded the »war« and stored it in /var/lib/tomcat6/archiva, this defines the starting point.
1. Database:
In the official instruction one is asked to download derby.jar and derbytools.jar to save them in $CATALINA_HOME/lib (in my case that points to /usr/share/tomcat6/lib) to make the files available for all web application running on this tomcat. On my research I came over the apache derby project where I also found this command:
sudo apt-get install sun-javadb-core sun-javadb-client
which just installs the derby db (in my case I had to add »multiverse« in /etc/apt/sources.list at the of one source). After that I run:
sudo ln -s /usr/share/javadb/lib/*.jar -t /usr/share/tomcat6/lib
what linked all needed derby-jars to the tomcat lib (probably some are not needed there). After that I created the directory db in /var/lib/tomcat6/archiva and changed its owner and group to tomcat6, but it is up to you where you want to store the database files, but it is important not to create the two subdirectories for the two needed databases, namly: users and archiva, inside that directory.
2. Mail
There I followed the Instructions and copied mail.jar and activation.jar to tomcats library.
3. archiva home directory
One of the Errors that prevented archiva from running was that it tried to create a home Directory in /usr/share/tomcat6/.m2, but that resulted in an permission conflict, so I created that directory and changed group and owner to tomcat6.
Last but not least I cared about the archiva.xml, located in in /var/lib/conf/Catalina/localhost. Since the paths that should be replaced were not marked in »bold« it is kind of easy to oversee them, so I try to do that here, using ${path} to point that out:
<Context path="/archiva"
docBase="${path to the archiva war archive here}">
<Resource name="jdbc/users"
auth="Container"
type="javax.sql.DataSource"
username="sa"
password=""
driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
url="jdbc:derby:${path to the db folder}/users;create=true" />
<Resource name="jdbc/archiva"
auth="Container"
type="javax.sql.DataSource"
username="sa"
password=""
driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
url="jdbc:derby:${path to db folder}/archiva;create=true" />
<Resource name="mail/Session"
auth="Container"
type="javax.mail.Session"
mail.smtp.host="localhost"/>
</Context>
That should be everything and I hope that I did not forgot anything to mention. Searching the catalina.out for error logs is a kind of senseless since the messages in there do not describe explicit problems, therefor I want to suggest to read localhost.${date}.log in the same directory, therein I could find debug information which was much more useful.
p.s.: After the Installation of Archiva did the very same Steps for Apache Continuum, just replacing folder- and filenames, what resulted in a running Installation, too.
Happy Install, cheers!
I downloaded wicket examples 1.6.0 and built successfully in netbeans7.2. but got errors when I tried to deploy on tomcat 7:
Cannot deploy the module. The context.xml file seems to be broken. Check whether it is well-formed and valid.
The module has not been deployed.
See the server log for details.
at
org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:210)
at
org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy(ExecutionChecker.java:178)
at
org.netbeans.modules.maven.j2ee.ExecutionChecker.executionResult(ExecutionChecker.java:130)
at
org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:212)
at
org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
heres the contents in context.xml:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<!-- <Loader className="org.atmosphere.util.AtmosphereClassloader"/> -->
<Loader delegate="true"/>
</Context>
I prefer to run wicket in eclipse as it negates the requirement to mess around with an external tomcat instance.
If you are comfortable with eclipse and maven i would download wicket 1.6 example archetype via maven, import into eclipse and then in the test directory you can run the run.java class to get an internal jetty server host wicket for you.
this should get you started quickly without having to wrestle with tomcat configurations too.
Not really an answer but an alternative route to the same end point
Add parameter path to context tag, same path that app will be served:
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/application-path-name/">
<!-- <Loader className="org.atmosphere.util.AtmosphereClassloader"/> -->
<Loader delegate="true"/>
</Context>
Answer obtained from this question.