Oct 19th, 2011, 02:07 PM
The only way the classpath is altered is that the agent code is added to it (above the user code). The user code that gets loaded is all re-written though, to be amenable to reloading later, but without seeing the exceptions and perhaps the code that leads to them, I can't fix anything for you.
Editing the launch configuration for a server should be done through the server configuration UI panel. My point was that if you start manually editing the launch configuration created to represent the server settings, you may find some of it gets rewritten - as you can see the javaagent bit is rewritten, and I believe the insight setting is modified too. So you are kind of on your own if doing that and it may get annoying with things changing underneath you. If you don't mind risking it, that's fine. But if you want to start changing it manually, it is probably better to take a copy of the launch configuration and use that to start the server. Options on the springloaded agent are configurable in the dialog box on the server settings page but they won't let you change the agent jar itself. If there is a setting for the server that really should be user configuration then we would expose it through the UI, and I'd recommend raising a jira for that on the STS issuetracker.
With regard to the agent options, they are still evolving really, hence there is no solid documentation on them. Tweaking them is unlikely to fix something like the problem you describe with the exceptions occurring. I guess the two options you may want to play with are inclusions and exclusions, which take an AspectJ style type pattern list that determines what code will be made reloadable (default is to make code reloadable if it comes in from an on disk .class file - so things in jar files will not be made reloadable). Format is like "inclusions=com.foo..*" "exclusions=com.foo.ThisType,com.bar.ThatType" . Perhaps if you tell me what you want to tweak with the options, I can tell you about how you might do that. It currently doesn't do any jar scanning (regardless of what options you specify) so it won't reload from a jar if you drop a new version of a jar on an old one, it just monitors .class files on disk. Once the options have settled down and I know what really needs to be user configurable, there will be documentation, but the original design goal is that it behaves in most situations with no options set.
But to provide a bit more info. Grails 2.0 uses the agent and you may see in its options it specifies 'profile=grails' for the agent. A profile is a shorthand for configuring a bunch of other options. In this case the grails profile is doing things like turning on caching (which can make secondary startups faster) and defining a cache location. These options could be set manually via "caching=true;cacheDir=/tmp/foobar". But as I say, once the options settle down they will be documented.
Oct 20th, 2011, 07:35 AM
ok, where is the file that I need to modify to add my own javaagent?
I grep'd and didnt find anything in the workspace or deployment dirs...
Oct 20th, 2011, 04:32 PM
There isn't a file on disk to edit, I would start the server once then open the list of launch configurations, copy the one that was just created for that start of the server, rename it and tailor it to use whatever agent you wish. That should be enough.
May 2nd, 2012, 01:07 PM
This issue is not solved.
I cannot save the VM argument for the Java agent, set to the Spring instrument.
Whenever I save the launch configuration, it resets when I start the server in run or debug mode.
What am I doing wrong?
VMware vFabric tc Server Developer Edition (Runtime) v2.6
SpringSource Tool Suite Version: 2.9.1.RELEASE, Build Id: 201203221000
Jun 25th, 2012, 10:38 AM
This thread is actually about the springloaded javaagent, not the spring instrument one. There is some special handling here and there for the springloaded one, not sure about the spring instrument jar. If you copy your launch configuration do you still find in the copy that it gets reset on save? Have you raised a jira? https://issuetracker.springsource.com/browse/STS - it is possible the logic that runs when manipulating launch configurations needs some improvement to cope with this (it needs to understand you are trying to override the default).
Tags for this Thread