DiSL issueshttps://gitlab.ow2.org/disl/disl/-/issues2018-11-08T10:38:02Zhttps://gitlab.ow2.org/disl/disl/-/issues/7ASM ClassLoader2018-11-08T10:38:02ZVít KabeleASM ClassLoaderInstead of loading classes via ByteArrayClassLoader, try to implement the ASM `ClassNodeClassLoader` that will probably mean to use `ClassWriter` class visitor from ASM and then load as byte array.Instead of loading classes via ByteArrayClassLoader, try to implement the ASM `ClassNodeClassLoader` that will probably mean to use `ClassWriter` class visitor from ASM and then load as byte array.DiSL Sessions supportVít KabeleVít Kabelehttps://gitlab.ow2.org/disl/disl/-/issues/6Context Type discovery2018-11-11T18:53:46ZVít KabeleContext Type discoveryWhile trying to determine context type of snippet argument, the interfaces of class are determined using reflection in DiSL server VM.
This cannot succeed for obvious reason, since the classes are not loaded into the VM but received from...While trying to determine context type of snippet argument, the interfaces of class are determined using reflection in DiSL server VM.
This cannot succeed for obvious reason, since the classes are not loaded into the VM but received from client VM.
This currently causes the `gettarget` test to fail.DiSL Sessions supportVít KabeleVít Kabelehttps://gitlab.ow2.org/disl/disl/-/issues/4Update tests to reflect session support2018-11-06T21:50:50ZVít KabeleUpdate tests to reflect session supportThe test fixture contains several tests running client and server simultaneously, those need to be updated to reflect changes in execution of instrumentation server and client respectively.
This encompasses removing instrumentation jar ...The test fixture contains several tests running client and server simultaneously, those need to be updated to reflect changes in execution of instrumentation server and client respectively.
This encompasses removing instrumentation jar from server classpath and adding as parameter to client agent.DiSL Sessions supportVít KabeleVít Kabelehttps://gitlab.ow2.org/disl/disl/-/issues/3Instrumentation delivery2018-10-26T21:22:33ZVít KabeleInstrumentation deliveryModify `dislagent` and `dislserver` so that the instrumentation will be sent from client to the server without need to have instrumentation in server classpath.Modify `dislagent` and `dislserver` so that the instrumentation will be sent from client to the server without need to have instrumentation in server classpath.DiSL Sessions supportVít KabeleVít Kabelehttps://gitlab.ow2.org/disl/disl/-/issues/1Protocol update2018-11-16T17:15:44ZVít KabeleProtocol updateUpdate communication protocol to allow sessions on instrumentation server.Update communication protocol to allow sessions on instrumentation server.DiSL Sessions supportVít KabeleVít Kabelehttps://gitlab.ow2.org/disl/disl/-/issues/11Explicit disl-bypass.jar load2019-04-24T14:44:09ZVít KabeleExplicit disl-bypass.jar loadWhen executing the analysis I sometimes forget to place the `disl-bypass.jar` into the observed program classpath, or the jar file is not present at its expected location
due to the build errors for example. In such cases the observed ma...When executing the analysis I sometimes forget to place the `disl-bypass.jar` into the observed program classpath, or the jar file is not present at its expected location
due to the build errors for example. In such cases the observed machine dies with a core dump by the NoClassDefFound exception that forces the user to read the JVM internal error messages to realise that he misused the api.
Since it's relatively frequented message I was wondering if it wouldn't be better to pass the path to the disl-bypass.jar as another parameter to the agent and then add
the path as the bootstrap classloader segment using the [AddToBootstrapClassloaderSearch](https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#AddToBootstrapClassLoaderSearch) JVMTI method after we explicitly check whether the specified file exists.
It's not really must-have feature, but it would increase the user experience a bit.https://gitlab.ow2.org/disl/disl/-/issues/10Local socket transport2019-03-08T11:22:35ZVít KabeleLocal socket transportAdd support for locally created sockets (i.e. in domain *AF_UNIX*). This sockets are not addressed by a ip address, but its address is a file name.
Communication over the local socket makes a sense, when the analysis and the observed VM...Add support for locally created sockets (i.e. in domain *AF_UNIX*). This sockets are not addressed by a ip address, but its address is a file name.
Communication over the local socket makes a sense, when the analysis and the observed VM runs on the same physical machine, and allocating a port
is unnecessary.https://gitlab.ow2.org/disl/disl/-/issues/9Wiki/Web update2019-02-28T14:04:28ZVít KabeleWiki/Web updateI noticed, that there is a wiki page at [https://disl.ow2.org](https://disl.ow2.org).
As this page seems to be a bit discontinued I suppose to make a wiki as
[Gitlab Pages](https://docs.gitlab.com/ee/user/project/pages/),
if **OW** inst...I noticed, that there is a wiki page at [https://disl.ow2.org](https://disl.ow2.org).
As this page seems to be a bit discontinued I suppose to make a wiki as
[Gitlab Pages](https://docs.gitlab.com/ee/user/project/pages/),
if **OW** installation supports this feature. Since we have CI available, this shouldn't
bring much hassle and keeping the website managed from within a repository will bring us
a convenient way how to keep the documentation up-to-date with actual state of production
branch.
Even JavaDoc documentation can be simply included in generated website.https://gitlab.ow2.org/disl/disl/-/issues/8GIT workflow2018-11-27T14:06:35ZVít KabeleGIT workflowSince the disl is a project with relatively huge codebase, I think it would be nice to use some kind of well defined git workflow.
I’d suggest to use the **git flow** workflow, as described at [nvie.com](https://nvie.com/posts/a-success...Since the disl is a project with relatively huge codebase, I think it would be nice to use some kind of well defined git workflow.
I’d suggest to use the **git flow** workflow, as described at [nvie.com](https://nvie.com/posts/a-successful-git-branching-model/)https://gitlab.ow2.org/disl/disl/-/issues/5Directory structure update2018-11-16T17:15:44ZVít KabeleDirectory structure updateIn order to reduce the number of different packages in project, we decided to refactor the repository directory structure accordingly.
Supposed solution was to move files from `src-disl/ch/usi/dag/disl/<packagename>` into `src-<packagena...In order to reduce the number of different packages in project, we decided to refactor the repository directory structure accordingly.
Supposed solution was to move files from `src-disl/ch/usi/dag/disl/<packagename>` into `src-<packagename>/ch/usi/dag/disl` so that only one package will be created, while keeping the advantage of logically separated code files.
Since I suppose that similar refactoring is desirable for `shvm` sources, I propose the final directory structure to be one level deeper, starting with a package name.
I.e.
```
/disl
|- disl/
| |- src-disl/
| | |- ch/
| | | |- usi/
| |- src-exception/
| |- src-classparser/
|
|- shvm/
| |- src-shvm/
```
Please approve.
@pallashttps://gitlab.ow2.org/disl/disl/-/issues/2Protobuf ant task2018-11-07T16:00:13ZVít KabeleProtobuf ant taskSince the protobuf needs to be compiled with some special plugins in some special versions, I suggest not to version the generated protobuf codefiles, but regenerate them as an ant task.
This is not so straightforward as editing the `bu...Since the protobuf needs to be compiled with some special plugins in some special versions, I suggest not to version the generated protobuf codefiles, but regenerate them as an ant task.
This is not so straightforward as editing the `build.xml` file since the `protoc-c` compiler is distributed as `c` source and needs to be compiled on each architecture separately.