Re: [mat-dev] DTFJ code submitted - need to test

[Andrew Johnson <andrew_johnson@xxxxxxxxxx>]

> Hi there,
> 
> I have submitted the DTFJ adapter to our repository and changed the 
> build accordingly. The first version (not yet publicly linked) can 
> be found here [1].
> 
> @Andrew: Can you take a look at this version? It works for me, if I 
> additionally install the "Diagnostics Tooling for Java" feature only.
> 
> 
> I'd also like to address the issue raised in the forum over the 
> weekend [2] - the one about parsing DTFJ dumps from the command 
> line. If I understand it correctly, the reason is that only the 
> bundle activator registers the parser. And the reason for the bundle
> activator is the extension point that was not able to handle 
> multiple parser definitions in one plug-in [3]. Right?
> 
> Is see three options
> (a) fix the extension point (now it is easier to do, because the 
> dtfj adapter lives in the same repository)
> (b) add code to the parse application which forces the start-up of 
> the dtfj adapter
> (c) add the required fragments to the ParseHeapDump script.
> 
> Any take on this?
> 
> 
> Andreas.
> 
> 
> [1] http://www.eclipse.org/downloads/download.php?file=/technology/
> 
mat/latest/rcp/MemoryAnalyzer-Incubation-0.8.0.20090522-win32.win32.x86.zip
> [2] http://www.eclipse.org/newsportal/article.php?
> id=299&group=eclipse.technology.memory-analyzer#299
> [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=261195
> 
Code in [1] works for me too.

>And the reason for the bundle
> activator is the extension point that was not able to handle 
> multiple parser definitions in one plug-in [3]. Right?
No, this is not the reason.
The reason is that DTFJ is an interface with different implementations and 
the DTFJ parser shouldn't have to know about all the implementations. I 
got the DTFJ API plugin to define an extension point.
Each DTFJ implementation then declares an extension giving its factory 
class and which file types it can read.

The DTFJ adapter then in turn needs to declare to MAT which file types it 
supports. It reads all the DTFJ extensions and dynamically builds the MAT 
parser and file type extensions. The dynamic building is a bit ugly as it 
uses the IExtensionRegistry.addContribution and 
ExtensionRegistry.getUserToken calls. The file type is also a bit tricky. 
MAT expects the parsers to declare Eclipse file types extending 
org.eclipse.mat.JavaHeapDump. DTFJ can't really have special knowledge of 
this type, so the file types are more generic. In DTFJ though I've used 
the convention that all DTFJ types have a base content type which is an 
alias for 'com.ibm.dtfj.base'. If this 'com.ibm.dtfj.base' is not defined 
then the DTFJ file types can extend well known Eclipse types such as 
org.eclipse.core.runtime.xml or org.eclipse.core.runtime.text. The adapter 
declares the com.ibm.dtfj.base type to be an subtype of 
org.eclipse.mat.JavaHeapDump so then automatically all DTFJ types which 
are subtypes of com.ibm.dtfj.base are subtypes of 
org.eclipse.mat.JavaHeapDump and are visible to MAT.

This all needs to be done before MAT asks which parsers are available. I 
use the bundle start call to declare the parser and file types. I then use 
the org.eclipse.ui.startup extension to start my adapter early. This isn't 
perfect as it doesn't work in command line mode without modifying 
config.ini or provide a -Dosgi.bundles property and also will start the 
DTFJ parser bundle if MAT is installed into Eclipse workbench even if the 
rest of MAT is not started.

MAT could have its own parser startup extension point.

Perhaps some Eclipse plug-in experts can help me on this one.

Andrew Johnson






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU