Re: Classloading and ArgoUML

Hi Anders,
I would rather keep the classloading mechanism simple. I believe that 
even application like argo, that has a separate classloader for every 
jar file, also has a classloader that can see classes in all jar-files.
With MDR, you should be able to get it to work the following way:
1) load your metamodel into the MDR and generate JMI interfaces for it 
(e.g. in MDR Explorer)
2) compile and package the JMI interfaces into a jar file and put it on 
the classpath of argo
3) in your code, implement the ClassLoaderProvider interface so that it 
returns the classloader that can see all the jar-files from the 
getClassLoader() method and that it always returns null from the 
defineClass method

This should definitely work. In addition, if you want to provide 
implementation classes for some of the JMI interfaces, you can either 
put them into the same jar as the JMI interfaces, or you can create a 
separate jar that depends on the one with the interfaces.

The way MDR works is that it creates its own class-loader, that 
delegates to the classloader returned from getClassLoader method when 
looking for classes. The implementations of JMI interfaces that MDR 
generates during the runtime MDR first tries to define using the 
defineClass method of the ClassLoaderProvider interface - if it returns 
null, MDR defines these classes in its own classloader.
Regards,
Martin

Anders W. Tell wrote:
> Hi Martin,
> 
> I tried to dynamically load generated JMI files but  I cannot get the 
> correct classloader from ArgoUML and since MDR requires me to make my 
> own classloader.  I could not get the MDR generated bytecode to mix with 
> Argo loaded JMI partly because Argo create its own Jar-loader /per JAR 
> wich is not kept after loading, so I cannot get a reference to it.
> 
> Generally I would prefer that MDR allows a classloader per extent, this 
> way you can load/unload metamodels and generated API and other files. 
> This is needed in scenarions when you work with Ant buildscripts and 
> dynamic languages.
> Maybe a classloading algorithm like this would be better than today
> 1 find registered classloader for extent
> 2. if not found the look for classloader in MDRepository
> 3. if not found then use static classloader.
> 
> /anders
> 
> Martin Matula wrote:
> 
>> Hi Anders,
>> can you send more details about the ClassCastException? There are some 
>> other possible (and more elementary) problems besides the one Roy 
>> pointed you to. Maybe you are using both versions of UML (1.3 and 1.4) 
>> loaded in the repository at the same time (then the interfaces for 1.3 
>> clash with interfaces for 1.4), or you have some UML interfaces on 
>> your classpath but they are incorrect, or something, so MDR generates 
>> its own which are then incompatible with those on your classpath, etc.
>> So more info would help...
>> Martin
>>
>> Anders W. Tell wrote:
>>
>>> Hi,
>>>
>>> Im having some trouble using ArgoUML and MDR together, for some 
>>> reason I get a classcast exception when refering to generated Java 
>>> API/JMI files. It seems that MDR and ArgoUML is using different 
>>> classloaders or Im I wrong ?
>>>
>>> Im sure that ArgoUML got its own classloader but how is this loader 
>>> related to the automatically generated internal implementation of the 
>>> metamodel used internally in MDR ?
>>>
>>>
>>> Has anyone had a similar problem and solved it ?
>>>
>>> /anders
>>>
>>>
>>>
>>
>>
>>
>>
> 
> 
>