Skip to Content

SAP Cloud Platform, java and agents

Sep 18, 2017 at 07:17 PM


avatar image
Former Member

How do I deploy a java application on the SAP Cloud Platform that requires an agent to be attached via vm arguments at startup?

The neo tool seems to ignore non .war files, so cannot upload the agent files that I would reference from the vm-arguments setting.


What I would like is to have non-war files as source, that I can then reference from the vm-arguments, to set as agents for the JVM, something like:

vm-arguments=-javaagent:agent.jar -- or

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

avatar image
Former Member
Sep 20, 2017 at 06:18 AM


In general, deploying agents is not supported as improper configuration may lead to jvm fail to start.

In your example, while -javaagent option may seems straight forward to support, -agentpath require knowledge in cloud internals (specifying full path to the agent and also OS architecture, etc).

Another issue could be that if two or more agents are specified they may clash sooner or later and cause strange behavior of the application. Since these agents don't come with the platform and are not validated to work (together)

What is the agent that you would like to specify and which is the java runtime that you target (neo-java-web, neo-javaee6-wp, neo-javaee7-wp + version)?

Kind regards,


Show 2 Share
10 |10000 characters needed characters left characters exceeded
Former Member


I am trying to find a way to deploy with JRebel enabled on the neo platform - In this case, with the neo-java-web (Tomcat 8) target, if that makes any difference.

If using cloud foundry, then it works out of the box, as JRebel is part of the standard java build pack, but using the neo tool, that is not the case.

JRebel comes in two parts, a native component and a .jar file, where you add something like -agentpath:/path/to/ (for a 64-bit JVM on Linux) as a JVM argument, and the native agent would then initialize and find the jrebel.jar and use that for the java parts.



Hi Michael,

JRebel is targeted at the development phase of a product. So, this is more intended for developers, rather than production software. During the development cycle of a "Neo" application you may use it on a on-premise server (neo-java-web from SDK or a full-blown tomcat). Once you release a new product version, then the continuous integration software should take care of deploying it to Neo. The software running on Neo shouldn't be subject to updates/changes. It should be a stable version. Therefore, it doesn't make sense using JRebel in this context.

I am not saying that you couldn't have a sub-account in Neo for development purposes. You could, but I believe it is encouraged that you first develop your software locally and then deploy it into Neo environment. The same is encouraged for CF projects being developed by teams with CI software in place. For CF apps you can still use JRebel on-premise. Of course, there might be some situations where it is not possible to check your code on-premise, simply because it is not reflecting the cloud environment 100%. Still, there are techniques to mitigate the risk of having the software testing on cloud without issues.

When you deploy your software on a sub-account for dev purposes in Neo or a space in CF, your goal is just to validate the pieces that have been mature enough to make it to production. Deployment takes quite some time. So, for some teams it makes sense using JRebel in the cloud. I would love to see SAP investing on this approach for Neo - maybe a new neo runtime could have it enabled by default so development teams could use it for fast development and avoid having an on-premise system just for that.

As of now, this isn't available on the current Java runtimes that are out there. So I would stick with the option described above and use the on-premise system or move development altogether to CF.