Thread Weaver mavenized, plus a few questions
Scott
working on. Alasdair, if you're interested, I could send you the
maven project as tar-gzipped file, for you to unpack and examine, and
I can give you a brief overview of Maven and its preferred structure
for code, resources, etc.; if you agree, I'd like to upload it to
Maven central, so it can be available for other developers in their
maven projects.
I do have a question about Codepoints: I read through the user docs,
and worked through some of the examples, and it all seems clear.
However, I couldn't get it to work in one of my tests on a private
static void method. Can Thread Weaver set code points or break points
inside methods that are private, and static, and return nothing?
I also made a minor change in my local install of Thread Weaver, to
exclude slf4j/logback classes from being instrumented (otherwise I get
linkage errors with conflicting SAXParser classes). I saw from a
comment in your instrumentation class, Alasdair, that you may make the
list of classes to exclude to a configurable parameter. That sounds
like a good idea to me: but would it make sense to make the list a
whitelist, rather than a blacklist? Most likely, people only want to
instrument the classes in their local packages, not every dependency
they load, too. Would instrumenting only local packages lead to
dependency issues?
This is a great package, and I'm looking forward to exercising it more
vigorously.
thanks,
-- Scott
Alasdair Mackintosh
> I mavenized Thread Weaver, so I could include it on a project I'm
> working on. Alasdair, if you're interested, I could send you the
> maven project as tar-gzipped file, for you to unpack and examine, and
> I can give you a brief overview of Maven and its preferred structure
> for code, resources, etc.; if you agree, I'd like to upload it to
> Maven central, so it can be available for other developers in their
> maven projects.
Sure. I'm glad you're finding it useful.
> I do have a question about Codepoints: I read through the user docs,
> and worked through some of the examples, and it all seems clear.
> However, I couldn't get it to work in one of my tests on a private
> static void method. Can Thread Weaver set code points or break points
> inside methods that are private, and static, and return nothing?
You can use ClassInstrumentation.atMethodStart() or
ClassInstrumentation.atMethodEnd(), and pass in the appropriate Method
object (which you find via reflection). Would this work? If not, can
you send me an example of what you are trying to do?
> I also made a minor change in my local install of Thread Weaver, to
> exclude slf4j/logback classes from being instrumented (otherwise I get
> linkage errors with conflicting SAXParser classes). I saw from a
> comment in your instrumentation class, Alasdair, that you may make the
> list of classes to exclude to a configurable parameter. That sounds
> like a good idea to me: but would it make sense to make the list a
> whitelist, rather than a blacklist? Most likely, people only want to
> instrument the classes in their local packages, not every dependency
> they load, too. Would instrumenting only local packages lead to
> dependency issues?
Hmm. One potential worry about the whitelist approach is that people
might think that they are instrumenting more classes than they really
are. (I.e. they assume that TW is stepping through an instrumented
class, when in fact it isn't.) Also, it's one extra thing to add to
your test setup. But, yes, I can also see the advantages. It probably
makes sense to add both approaches.
> This is a great package, and I'm looking forward to exercising it more
> vigorously.
Cool. Please let me know what issues you find. I have a couple of
potential enhancements as well, and I'd like to roll them out into a
new release some time.