Embedding Telnet -- Crash -- Groovy in a WAR with minimal impact.

[brian...@gmail.com]

Hello all,

I have a situation where I have a 'high performance' WAR deployed via Amazon's Elastic Beanstalk. The War is a Pixel gathering and recording system for a very large online advertiser.

Because of the substantial work already done, and the apps simplicity I do not want to 'springify' the app. I just want to the ability to telnet into the 'app'  and test out groovy as a method for me to diagnose issues at runtime and possibly other things as soon as I get familiar with exactly what a groovy interface can let me do. I used to do this manually using a reverse proxy model and predefined methods but I was only able to do things I had thought about before at compile time. I think telnet -- Crash -- Groovy could replace this and allow me much more flexibility with less code.

I have been able to get the WAR to open a port and allow me to telnet into it simply by adding

  <listener>
    <listener-class>org.crsh.plugin.WebPluginLifeCycle</listener-class>
  </listener>

along with my other listeners and adding the config and adding the crash/commands/ to by WEB-INF.

There was a bit of trouble at first finding the rite dependancies to get this far but that was relatively easy.

My problem is I can telnet (locally only which is great) in and I am not seeing any errors even at finest grain logging in tomcat7 but the only command available to me when using telnet is bye which is not helpful.

I was wondering if anyone had experience with this and could give me some helpful advice. I will be more than happy to build a tutorial for the site if I can get through this and it shows it's worth. I would even fork and build a special case branch for this situation if necessary.

Anyway, Thanks in advance for any help and I hope this makes sense.

Cheers,
 - Brian

[Julien Viet]

Hi Brian,

It looks like you build your war yourself.

The WebPluginLifeCycle integration will get the commands in "/WEB-INF/crash/commands" of the web application, but it looks like you did something like that since you mention it.

There is a web distribution you can download that has all base crash commands unpacked in this location that you may want to look at: https://code.google.com/p/crsh/downloads/detail?name=crash-1.2.0-war.tar.gz&can=2&q=#makechanges . Can you try this war file in Tomcat and in your context and tell us if CRaSH is able to see the commands. To print all the available commands you can type "help".

Concerning what you can do and can't, the answer lies in which object commands can access. The WebPluginLifeCycle will expose all the servlet context attributes of the web application easily. So if you store your application objects there, you can use them out of the box with the implicit context object attributes: so "context.attributes['foo']" provides the servlet context "foo" object. You also have access to the classes visible in the war files and so all the static fields which can be helpful if you use static registries or singletons.

cheers

Julien

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes CRaSH User Group.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

[Brian Lima]

Absolutely perfect! What a great chunk of code!

I do build my war using Maven and I had copied the WEB-INF/crash/commands directory.

I installed the was you provided and after seeing it work I started looking at the differences between my war and the posted one and noticed that I did not have 

# VFS configuration

crash.vfs.refresh_period=1

in my crash.properties file.

I have not had a chance to look into the code that uses that yet but that was all I had to change and after a few hours of playing with the shell it looks like this is exactly what I was looking for. Without any modifications I am already able to access everything I want to now. Most of my code is Singleton and static producer consumer type stuff so this just seems to play well with that architecture out of the box.

Now on to learn more groovy.

Cheers  Julien,

 I hope to come back soon with some contributions.

 - Brian

--
Vous recevez ce message car vous êtes abonné à un sujet dans le groupe Google Groupes "CRaSH User Group".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/crash-users/hrEnnE4J-f0/unsubscribe?hl=fr.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse crash-users...@googlegroups.com.