I've deployed my app to Bluemix and want to change the default Java version from 8 to 7. Then I run the cf command "cf set-env myapp JBP_CONFIG_IBMJDK "version: 1.7+"", then run "cf restage myapp", but error occurred. Below is the log.
Anyone can give me some tips on how to customize Java version, instead of using the default one? Thanks so much!
Updated app with guid 978e8006-6211-47c7-aa67-2931be310519 ({"environment_json"=>"PRIVATE DATA HIDDEN"})
Got staging request for app with id 978e8006-6211-47c7-aa67-2931be310519
-----> Downloaded app package (12M)
-----> Downloaded app buildpack cache (4.0K)
-----> Liberty Buildpack Version: v2.3-20151208-1311
E, [2016-01-10T09:42:28.093168 #73] ERROR -- /var/vcap/data/dea_next/admin_buildpacks/24690e4f-31f1-4172-b295-80c16598b357_bb01df5b768b9bb0430b0a8427293feda0a920cc/lib/liberty_buildpack/buildpack.rb:50:in `rescue in drive_buildpack_with_logger': Compile failed with exception #<NoMethodError: undefined method `include?' for nil:NilClass>
undefined method `include?' for nil:NilClass
Staging failed: Buildpack compilation step failed
encountered error: App staging failed in the buildpack compile phase
Stopped app instance (index 0) with guid 978e8006-6211-47c7-aa67-2931be310519
The error is related with the buildpack not compiling successfully.
Check if you are using any feature related to jre 1.8 version.
All the options to configure the jre used in your liberty application are documented here:
https://www.ng.bluemix.net/docs/#starters/liberty/index.html#liberty
Related
I just installed camel-k 1.0.0 as described in the installation documentation and ran a simple groovy example.
I installed camel-k on a 1.17 virtual on-prem kubernetes test-cluster.
The error:
Error during unshare(CLONE_NEWUSER): Invalid argument
User namespaces are not enabled in /proc/sys/user/max_user_namespaces.
level=error msg="error parsing PID \"\": strconv.Atoi: parsing \"\": invalid syntax"
level=error msg="(unable to determine exit status)"
How I installed:
kamel install --registry sonatype.nexus3.reg. --registry-auth-username MyUsername --registry-auth-password MyPassword
Then I executed hello.groovy:
kamel run hello.groovy
A camel-k-kit pod is created then running after a couple of seconds into the above error.
What am I doing wrong?
I've created a new project from a start pack in IBM Cloud and I've created a toolchain for it. But when I commit new code to git, my build stage fails with this message
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireJavaVersion failed with message:
Detected JDK Version: 1.7.0 is not in the allowed range [1.8,).
How do I force IBM Cloud to use Java8?
I am little bit surprised because IBM Cloud liberty profile actually uses java8, according to this
https://console.bluemix.net/docs/runtimes/liberty/customizingJRE.html#customizing_jre
I'm a newbie in Grails Framework, I've downloaded Grails version 2.4.4 and set Path to it.
I create new application (like "hello world") but when run it with command (after cd application folder): grails run-app ,
cmd was stopped at this line : Configuring classpath.
Then I google, and try to use this way : setting "verbose" in BuildConfig.groovy file and it still like before with these errors :
| Error Resolve error obtaining dependencies: Failed to read artifact descriptor for org.slf4j:jcl-over-slf4j:jar:1.7.5
org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.slf4j:jcl-over-slf4j:jar:1.7.5
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:370)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:217)
at org.eclipse.aether.internal.impl.DefaultDependencyCollector.resolveCachedArtifactDescriptor(DefaultDependencyCollector.java:525)
at org.eclipse.aether.internal.impl.DefaultDependencyCollector.getArtifactDescriptorResult(DefaultDependencyCollector.java:509)
at org.eclipse.aether.internal.impl.DefaultDependencyCollector.processDependency(DefaultDependencyCollector.java:409)
at org.eclipse.aether.internal.impl.DefaultDependencyCollector.processDependency(DefaultDependencyCollector.java:363)
at org.eclipse.aether.internal.impl.DefaultDependencyCollector.process(DefaultDependencyCollector.java:351)
at org.eclipse.aether.internal.impl.DefaultDependencyCollector.doRecurse(DefaultDependencyCollector.java:494)
at org.eclipse.aether.internal.impl.DefaultDependencyCollector.processDependency(DefaultDependencyCollector.java:458)
at org.eclipse.aether.internal.impl.DefaultDependencyCollector.processDependency(DefaultDependencyCollector.java:363)
What can I do next?? and why it has these error, and what can I do for running this application.
P/s : Java version that I use is Java 1.6.0, OS: window 7.
Thank for any help.
This is a proxy issue, you can execute below commands:
grails add-proxy "client" "--host=yourHostName" "--port=8080" "--username=***" "--password='PASSWORD_GOES_HERE'"
grails set-proxy client
I believe the notation is incorrect for your dependency. You have:
org.slf4j:jcl-over-slf4j:jar:1.7.5
this includes a jar reference, which is unnecessary. Can you try:
org.slf4j:jcl-over-slf4j:1.7.5
Also, it looks like version 1.7.9 is available as of December 2014, if you want to use the latest.
when I run sample IBM Bluemix Liberty for Java application https://github.com/ibmjstart/bluemix-java-postgresql-uploader.git following error:
-----> Downloaded app package (1.9M)
-----> Downloaded app buildpack cache (4.0K)
OK
/var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:101:in build_pack': Unable to detect a supported application type (RuntimeError) from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:74:inblock in compile_with_timeout'
from /usr/lib/ruby/1.9.1/timeout.rb:68:in timeout' from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:73:incompile_with_timeout'
from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:54:in block in stage_application' from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:50:inchdir'
from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:50:in stage_application' from /var/vcap/packages/dea_next/buildpacks/bin/run:10:in'
FAILED
Server error, status code: 400, error code: 170001, message: Staging error: cannot get instances since staging failed
TIP: use 'cf logs jpu-henryhan --recent' for more information
The top error looks like you left off the -p <path_to_war> parameter when doing a push. If you just push a directory containing a WAR file, it will not be detected by the Java buildpack.
The tip provided in the output of your cf push request is relevant.
TIP: use 'cf logs jpu-henryhan --recent' for more information
Running that command will tail the log files produced during the staging process and let you see what error may have been raised. Often, it can be a missing dependency or a transient failure of some sort.
I just successfully deployed the sample using the "deploy to Bluemix" button and manually via the cf command line tool. Unless you changed the code, it is most likely that this error is a transient failure.
Run following command:
$ cf push jpu- -b https://github.com/cloudfoundry/java-buildpack --no-manifest --no-start -p PostgreSQLUpload.war
add the parameter to set the buildpack "-b https://github.com/cloudfoundry/java-buildpack"
I have a web application and using jenkins for build and deployment to glassfish 3+ server. But now I am facing a problem. The jenkins is building the application successfully but when it tries to deploy the application to the target server then it failed with following error
Deploying /var/lib/jenkins/workspace/Gordon Converter Dev/target/gordons-dev-deployment.war to container GlassFish 3.x Remote
ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to exception
org.codehaus.cargo.util.CargoException: Deployment has failed: Action failed Deploying application to target server failed; Error occurred during deployment: Exception while deploying the app [gordons-dev-deployment] : Could not load any resource bundle by com.sun.org.apache.xerces.internal.impl.msg.XMLSchemaMessages. Please see server.log for more details.
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.waitForProgressObject(AbstractJsr88Deployer.java:220)
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.deploy(AbstractJsr88Deployer.java:76)
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.redeploy(AbstractJsr88Deployer.java:142)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:64)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:90)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:77)
at hudson.FilePath.act(FilePath.java:920)
at hudson.FilePath.act(FilePath.java:893)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:77)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:47)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:756)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:720)
at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1040)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:669)
at hudson.model.Run.execute(Run.java:1735)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:529)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:234)
Finished: FAILURE
I just got this error too and I noticed that Java had auto updated itself to the latest version. So I was compiling the application with Java 1.7.0_131, but Glassfish3 was still running under Java 1.7.0_121. My solution was to restart Glassfish so that it was running under the new version of Java 1.7.0_131. I guess I could have also downgraded my Java back to 1.7.0_121 and compiled my application with that... Bottom line here is to make sure that you are compiling with the same version of Java that Glassfish is running.