Spring Insight looks incredible. We're using the Spring stack but not running on tc server. Should it be possible for me to explicitly pass the right jvm parameters to add SI instrumentation on WebSphere 6.1 (jdk 1.5 based)?
Thanks,
Stu
Spring Insight looks incredible. We're using the Spring stack but not running on tc server. Should it be possible for me to explicitly pass the right jvm parameters to add SI instrumentation on WebSphere 6.1 (jdk 1.5 based)?
Thanks,
Stu
You won't be able to use it outside of tc Server for the time being. We rely on Tomcat's classloader for a few of our tricks.
Thanks for the quick response. It saved me from wasting time trying to get it to work.
Is that something you see SI moving towards at some point in the future, or is the vision that this would be a part of the value of using tc?
I wouldn't rule it out in the future, as we want people who are writing Spring applications to have this valuable tool irrespective of how it's deployed. However, at this time we are focusing our energy on the Tomcat container -- specifically tc Server. As you can imagine, it makes our death matrix much smaller which allows us to move much more quickly.
Are you not able to try your app out on tc Server? What ties you to websphere?
Makes sense, and you guys are certainly moving quickly.
The apps I'm interested in for this are EARs, fairly integration-heavy with plenty of JNDI stuff configured in WebSphere already. Ideally we'd be able to just run them on tc, but I suspect this would be quite a bit of work in reality.
We've generally been using Jamon with Spring-injected timing aspects for high level performance data. We're looking seriously at OSGi for future apps, and I suspect that approach will hit problems, as I think Jamon holds it's data within a single classloader. Works great in JEE, but what about when there are many bundles and each with it's own classloader? I need to dig to see if this is really a problem, but that's my hunch.
SI looks like it holds timing info in it's own WAR, and gathers data in the target by instrumenting bytecode within the same JVM. ...currently moot point since tc isn't OSGi based, but if it were, would this approach work to capture timings in OSGi apps?
Apologies if this is a dumb question. I'm still trying to sort out all of the implications of OSGi.
Hey Jon,
Just wondering if its a possibility to use Insight on plain vanilla Tomcat. Considering tc is using Tomcat and as you mentioned earlier you are using the Tomcat classloader is there a way to deploy Insight in standard Tomcat.
My app uses JDK 1.6 and Tomcat 6.x
Thanks
- Kam
Yes, it would be possible to run Insight with vanilla Tomcat, as tc Server is pretty much just that with some additional niceties. Does tc not fit your needs?
Tc fits my need as Dev but not for production/commercial use. Right now our production stack is all tomcat and/or approaching tomcat as part of our migration effort to make it consistent operational environment across the board.
And that is the reason for asking. Considering that you have said yes, what do I need to do to get Insight running on Tomcat 6.x.
There are a few things that the Insight tc Server template does that you'll need to replicate in Tomcat:
- context.xml -- You will need to use the same configuration as we use (namely changing the valve and adding the weaving classloader)
- setenv.sh -- To get weaving information from the items in tomcat's /lib directory, you'll need to use our standard classloader.
- lib/* -- We have a variety of libs that must be in the tomcat top-level classloader to properly process traces.
Obviously the plugin and configuration for insight exists in insight/*, so you'll need all that as well. Let me know how it works out for you.