Dynamic load of helper classes

[vojedav]

Hi all,

  if I create some classes and put them in a jar file. Is it possible to make Byteman aware of them at runtime? How?

In my scenario, if I put the library (.jar) in the $JBOSS_HOME/common/lib (or other folder in the CLASSPATH) the rules can use my helper classes but, if I change that clases, I don't want to restart the server in order to make them "available". How to tell Byteman to use my "updated" jar ?

Thanks in advance,

  Victor

[vojedav]

The command

./bmsubmit.sh -s /home/vojeda/tools/jboss/server/sifHelper.jar -l thread.btm  (the same if I change -s to -b)

gives me the following error

java.lang.Exception: The remote byteman agent reported an error:

EXCEPTION Unable to add jar file -l

java.util.zip.ZipException: error in opening zip file

java.util.zip.ZipException: error in opening zip file

at java.util.zip.ZipFile.open(Native Method)

at java.util.zip.ZipFile.<init>(ZipFile.java:127)

at java.util.jar.JarFile.<init>(JarFile.java:135)

at java.util.jar.JarFile.<init>(JarFile.java:99)

at org.jboss.byteman.agent.TransformListener.loadJars(TransformListener.java:269)

at org.jboss.byteman.agent.TransformListener.handleConnection(TransformListener.java:211)

at org.jboss.byteman.agent.TransformListener.run(TransformListener.java:146)

[vojedav]

Of course, for this testing, I put the file sifHelper.jar in the /home/vojeda/tools/jboss/server directory

[vojedav]

Solved!!! I made a typo in the path.

[adinn]

Hi Victor,

Glad to see you managed to work out how to load your helper classes using bmsubmit -s.

This is useful when you load Byteman after starting your proram. But it will not allow you to redefine and reload your code. That's just the way Java works. Once you have loaded a class via the system classpath you cannot unload it. If you are only injecting rules into code which is in your deployed ear then you  could put the helpr jar in the ear and deploy/undeploy/redeploy it using the ear to manage the deployment. But thta may not be what you want.

[vojedav]

Hi Andrew,

the scenario I was thinking of is the following:

imagine you have an application deployed in, for instance, an JBoss AS. After some time, the user complains that some process is too slow. What means slow in that context? You cannot reproduce the situation at lab because the enviroment, the data and so on are different. Then you have to take some measures and probe some "variants" in production. But you have several modules and a lot of methods. Well. May be you need some helper classes to help you to do the work WITHOUT changing the application already in production. And that classes can be very different each other. Then, may be, I need many times to load and unload their libraries.

I know that I cannot unload my code once loaded but ...what about a custom classloader just to load and unload the helper classes? Is that idea ...feasible? What is your opinion?

Kind regards,

  Victor

[adinn]

Hi Victor,

Victor M. Ojeda V. wrote:

the scenario I was thinking of is the following:

imagine you have an application deployed in, for instance, an JBoss AS. After some time, the user complains that some process is too slow. What means slow in that context? You cannot reproduce the situation at lab because the enviroment, the data and so on are different. Then you have to take some measures and probe some "variants" in production. But you have several modules and a lot of methods. Well. May be you need some helper classes to help you to do the work WITHOUT changing the application already in production. And that classes can be very different each other. Then, may be, I need many times to load and unload their libraries.

I know that I cannot unload my code once loaded but ...what about a custom classloader just to load and unload the helper classes? Is that idea ...feasible? What is your opinion?

That's a very good question. I have been thinking about exactly this for some time now as this problem also crops up when you are runnign Byteman inside a JVM using a module loader. I think it might be possible to play tricks with a custom classloader to resolve this problem. But I am still some way from implementing any ideas at the moment. In fact I am really busy on other projects just now (and will be for much of the nxt 6 months) so even putting what I have been thinking about down on paper will take some time. I will raise a JIRA as a place-holder for this idea.

My only advice is that as a workaround you load different versions of the helper under different names e.g. repackage the code as org.my.helper.FooHelper1, org.my.helper2.FooHelper2 etc and update your rules according. I know thta is less than perfect but it may extend the shelf life of your rules before you have to restart your app.