Announcement Announcement Module
No announcement yet.
java agent based reloading Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • java agent based reloading

    Can anyone provide more information about the new feature on the server tab called "java agent based reloading". I gave it a short try and it reloaded properly my classes. But I'm wondering if this is a tc server feature and which functionality is provided with it.

    Is there any documentation about it?


  • #2
    Hi Claude,

    The Java agent based reloading isn't only usable under tc Server, it is a general approach, but we've spent most of our time testing under tc Server. *Currently* we package it as part of the SpringSource Tool Suite, but that may change over time.

    I don't think I've written down the feature list (or limitation list) anywhere actually, so let me give you some idea here. (I did talk about it at SpringOne and JavaOne last year). Regular 'hot code replace' allows you to change the bodies of methods/constructors. With the agent you can do:
    - add/delete methods themselves
    - add/delete fields
    - add/delete constructors
    - change annotations on those things
    - change annotations on the type declarations

    The main limitation right now is that it doesn't allow you to alter the hierarchy of a type, you can't change the set of interfaces you implement or your superclass.

    Hope thats useful,

    Andy Clement


    • #3
      Hi Andy

      Thanks for your answer! Therefore this feature is really new isn't it?

      Okay, I've found the vm arguments in the tc Server run configuration:
      -javaagent:"C:\springsource\sts-2.5.2.RELEASE\plugins\\lib\springloaded-0.5.1.jar" -noverify
      I would appreciate if you could answer the following questions:
      • Will this feature be turned into a commercial tool or is it intended to stay free to use?
      • Is there a plan for further development?
      • Will there be framework support such as done by JRebel?



      • #4
        Hi Claude,

        > Will this feature be turned into a commercial tool or is it intended to stay free to use?

        Likely to remain free (although I'm not sure I'm qualified to answer this definitively!), not sure if STS will always be the ship vehicle though. Our current focus around the STS/tcServer dev experience means it is a nice way to ship it right now whilst we work out the kinks.

        > Is there a plan for further development?

        Yep, it is actively under development, it is now working for groovy code and the next release will be doing more with grails reloading.

        > Will there be framework support such as done by JRebel?

        Yep, if we want to support the kinds of apps users deploy on tc Server we need support for informing the frameworks about changes (e.g. spring/hibernate).



        • #5
          Thank you Andy for the quick response.
          Looking forward to see this tool evolve.



          • #6
            doesnt work for me.
            How to change to another classloader?


            • #7

              What do you mean by 'change to another classloader'? If you are having an issue with the java agent based reloading, please raise an issue on the STS issuetracker: and I'll take a look, please try to include context of what you are doing and the kind of program you are running that isn't reloading correctly.



              • #8
                javaagent sts bug

                I can't add my own javagent such as:
                -javaagent:${development.lib.dir}/class-reload-agent.jar=classes=${virtual.classpath};${frontend.classes.d ir},loglevel=INFO

                it wont take in sts.

                I would use your
                javaagent:"C:\dev\software\springsource\sts-2.6.1.SR1\plugins\ eloading_2.8.0.201110171000-RELEASE\lib\springloaded-1.0.1.jar"

                if it worked for me.

                Perhaps some documentation for the options/parms would be a good start...


                • #9

                  The aim is that you don't need to use any options by default (for springloaded), and it usually will do the right thing - if it doesn't it is likely a bug. All options would be for advanced configuration only, and that is why there is no doc on them right now.

                  To put your own agent there I'd recommend copying the launch configuration rather than trying to edit the one created for tc server by default, as that launch configuration is subject to rewriting when the server starts up as STS modifies it to contain the most up to date and correct information (this may override anything you are manually tweaking).

                  > I would use your
                  > javaagent:"C:\dev\software\springsource\sts-2.6.1.SR1\plugins\ eloading_2.8.0.201110171000-RELEASE\lib\springloaded-1.0.1.jar"
                  > if it worked for me.

                  What didn't work? If you raise a bug I can take a look at whatever it is.



                  • #10
                    my app just wont start using the springloaded<ver>.jar..
                    seems to alter the classpath or something. I get a bunch of exceptions when I shouldn't.
                    If I un-check the option, all is fine...

                    If I cant update the server settings in sts, then what's the point of using the embedded server? BTW, if I alter any other setting, or add other entries, they stick. Just the javaagent doesnt seem to work.

                    As per the options for the javaagent - where is the documentation? I have seen people use the options in unrelated posts (not this site)
                    Thanks for the info though. Quite insightful.


                    • #11
                      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 "*" "," . 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.



                      • #12
                        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...


                        • #13
                          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.



                          • #14
                            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



                            • #15

                              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? - 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).