{"action":"closed","issue":{"url":"https://api.github.com/repos/jmockit/jmockit1/issues/286","repository_url":"https://api.github.com/repos/jmockit/jmockit1","labels_url":"https://api.github.com/repos/jmockit/jmockit1/issues/286/labels{/name}","comments_url":"https://api.github.com/repos/jmockit/jmockit1/issues/286/comments","events_url":"https://api.github.com/repos/jmockit/jmockit1/issues/286/events","html_url":"https://github.com/jmockit/jmockit1/issues/286","id":158677229,"number":286,"title":"JMockit Initialization on WildFly","user":{"login":"Vampire","id":325196,"avatar_url":"https://avatars.githubusercontent.com/u/325196?v=3","gravatar_id":"","url":"https://api.github.com/users/Vampire","html_url":"https://github.com/Vampire","followers_url":"https://api.github.com/users/Vampire/followers","following_url":"https://api.github.com/users/Vampire/following{/other_user}","gists_url":"https://api.github.com/users/Vampire/gists{/gist_id}","starred_url":"https://api.github.com/users/Vampire/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Vampire/subscriptions","organizations_url":"https://api.github.com/users/Vampire/orgs","repos_url":"https://api.github.com/users/Vampire/repos","events_url":"https://api.github.com/users/Vampire/events{/privacy}","received_events_url":"https://api.github.com/users/Vampire/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/jmockit/jmockit1/labels/other","name":"other","color":"000000"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2016-06-06T13:26:37Z","updated_at":"2016-06-09T14:49:45Z","closed_at":"2016-06-09T14:49:44Z","body":"It would be great if JMockit would be better usable in Arquillian Integration Test - resp. Application Server - scenarios.\r\n\r\nWe are about to implement integration tests with Arquillian against a running WildFly application server.\r\nTo use JMockit in this situation, the only option is to start the WildFly server with the `-javaagent` option.\r\n\r\nThere were some problems with the other methods.\r\n\r\n1. JMockit does not correclty find its JAR file, as it is not available on disk, but only in a virtual file system (`vfs:`) of WildFly, so what JMockit gives to `loadAgent` the path `D:/Programme/wildfly-8.1.0.Final/content/mod-cm-integTest-2016R2.ear/lib/jmockit-1.24.jar` which does not exist of course and leads to the error `Error opening zip file or JAR manifest missing: D:/Programme/wildfly-8.1.0.Final/content/mod-cm-integTest-2016R2.ear/lib/jmockit-1.24.jar`.  \r\nIt could even be that there is not even a real file system present which is prefectly fine according to the Java EE specification.\r\n\r\n It would be nice if JMockit would check for the presence of the `jmockit.jar` path it determined.  \r\n If the check is positive, the current method can go on, if not, maybe the needed `jmockit.jar` can be created on-disk (if a disk is present) and then this generated file being used as argument for the `loadAgent` method.\r\n\r\n2. Some automatic initialization in this context would be nice, as you cannot really influence the order on the classpath and thus cannot make sure that JMockit is in the classpath before JUnit. But using `JMockit` as runner is also not an option, as the runner has to be `Arquillian`, so some other means of initialisation like some \"on deploy hook\" would be nice.\r\n\r\n3. JMockit is tried to be initialized mutiple times if you do undeploy / deploy cycles which is the case with Arquillian as for every test class the EAR is newly deployed and after the test undeployed. This leads to multiple problems.\r\n\r\n The first problem is, that the JVM can load a native library only from one class loader at a time. This means, if you run the second deployment without restarting the WildFly, you get `java.lang.UnsatisfiedLinkError: Native Library C:\\Program Files\\Java\\jdk1.8.0_77\\jre\\bin\\attach.dll already loaded in another classloader`, as it is already loaded in the classloader of the former deployment. Actually I guess the mocking would still work if the former call did succeed and thus did initialize JMockit, but I don't know, as it doesn't work at all.\r\n\r\n Maybe it would be an idea to not use static fields to determine whether JMockit is initialized already, but some means that is controlled by the JMockit Java Agent, like rewriting a hard-coded `final` `boolean` that is `false` at compile time to `true` at runtime and then check this boolean or something like that, then the determination whether JMockit is already initialized should probably work better even in this case of multiple class loaders.\r\n\r\n Actually this would also eliminate the native library on multiple class loaders problem in most cases, as long as not something else did use the attach api already in this VM, but I guess this is not too likely to happen and at least it would improve the situation much."}}
{"actor":{"display_login":"rliesenfeld"}}