Bela Ban wrote:
It would be nice if the scripts referenced via @BMScript(value="file" dir="dir") could also be searched on the classpath.
E.g. @BMScript(value="scripts/bela.btm") would also try to find scripts/bela.btm on the classpath, in addition to its usual resolution rules. Perhaps the above annotation could also be written as @BMScript(value="bela" dir="scripts")...
Hmm, what an interesting idea. I think it may be possible albeit not necessarily completely straightforward (see below). I assume you mean that you would like to look up the flle as a resource?
Bela Ban wrote:
If this is feasible, and can go into 2.0, I'm willing to implement it and issue a pull request...
Ok, let's deal with the priorities first -- you are now an officially signed up Byteman developer. Welcome to the team! (I have to earn something back for answering all these questions ;-)
Unfortunately, it cannot go into 2.0.0 because I have just posted 2.0.0 to the maven repo and was just getting ready to announce it. However, it could go into 2.0.1 (releases are cheap).
Bela Ban wrote:
Well, the place to look is in class org.jboss.byteman.contrib.bmunit.BMUnit. That is where all the real Byteman-specific action happens in the BMUnit package. The rest of the clasees (all 10, count them!) are either annonations or JUnit/TestNG integration.
The method you would need to modify is
BMUnit.loadScriptFile(Class<?> clazz, String testName, String dir)
which is called before a test is run to locate and upload a script file. It caches any resulting file so the corresponding unload method does not need to do any lookup. When this gets called:
clazz is the class holding the test method
testName is the value field of the BMScript annotation unless this field is "" or null in which case
for a class annoation testName is null
for a method annotation testName is the name of the method
dir is the directory field of the BMScript annotation unless this field is "" or null in which case dir is null
The rules for searching for a script file should be evident from the code -- they involve constructing a path based on dir (or "." if dir is null), possibly suffixed with the class package and using either testName or clazz.name-testName as the name of the file to look for. If testName is null then just class.name is used. Files are searched for using either a ".btm" or a ".txt" extension.
So, if you wanted to also use resource lookup then you could do this either before or after checking the file system by posting a resource lookup request to the current class loader (which in most cases ought to be the System classloader). I don't suppose it matters too much which way roudn you do this.
As for how you compute the resource file name, you could choose to use just testName/className or the dir and testName/className in combination, and you might possibly want to include the package component of the clazz to extend the dir. It's not clear to me that the same set of combinations is needed but I'll leave it to you to make a suggestion.
I think it would only be sensible to check for both ".btm" and ".txt" extensions. However one thing I did not think of with the exsting implementation is that an explcitily supplied annotation value might include irts own extension so perhaps testName ought to be checkdfor a '.xxx' ending and the other extensions only appended where this is missing. That could probably safely be retrofitted to the existing file lookup code as any working tests using the existign code will probably not include a '.xxx' suffix.
Anyway. if you want to do this raise a JIRA, write a proposal here or on the JIRA describing how you want to implement this and and then assign it to yourself and provide an implementation. I'll be happy to comment, review the code and pull the fix into 2.0.1
Ok, I created https://issues.jboss.org/browse/BYTEMAN-185. The pull request will follow shortly.
The way I implemented this is to take the existing logic, but place it all in one single method. It searches
- in the current working dir, for the name, then name.btm, then name.txt
- if not found it searches for name, name.btm and name.txt in the classpath as well
No need for this; as byteman will be part of JGroups 3.1, the release with my change should be released before 3.1, but that's not going to happen before March. Since I'm still experimenting with byteman, I might find other stuff to add/change...
Release 2.0.1 whenever you feel like it, but don't let this get influenced by my work.