FW: [Eclipsedotnet-developers] AssemblyLoader mechanism improved

[<jpp...@gm...>]

Damn. I replied only to you, Kunle, instead of to the list :( .
Sorry for the duplicate mail :( . I'll check the mailing list options to =
see
if I can change the ReplyTo address.

Regards,
JS

> -----Original Message-----
> From: Jo=E3o Saraiva [mailto:jpp...@gm...]=20
> Sent: quinta-feira, 8 de Dezembro de 2005 19:35
> To: 'Kunle Odutola'
> Subject: RE: [Eclipsedotnet-developers] AssemblyLoader=20
> mechanism improved
>=20
> The only one I have in mind for the platform itself is the=20
> loading of plugins into their own AppDomains (instead of into=20
> a default AppDomain, which is what's going on now). I had=20
> thought of this some time ago, and I believe you also=20
> mentioned it in one of your mails.
>=20
> There's nothing wrong with loading the assemblies/plugins=20
> into the default app domain, but in doing so we cannot=20
> explicitly unload the plugin: we have to lose all references=20
> to all types of all the assemblies of that plugin and _hope_=20
> that the garbage collector does its job.
>=20
> Nevertheless, the code I committed served only the purposes I=20
> mentioned: give some more relevance to DelegatingLoader and=20
> remove some hacks I had (especially in PluginLoader) to make=20
> the mechanism work well.
>=20
> Anyway, this is just a note for the future. I haven't really=20
> written any code for this AppDomain end. It's just a "would=20
> be nice to have" thingie ;) . When I started making a UML=20
> model of the mechanism yesterday (in paper), I noticed that=20
> maybe using the AssemblyLoader class to encapsulate an=20
> AppDomain may not be a very bad idea. But I still have to=20
> read a lot about this; my major concerns are assemblies=20
> references (i.e., dll dependencies), performance impact, and=20
> what types _must_ inherit from System.MarshalByRefObject.
>=20
> Of course, any comments/suggestions/criticisms are greatly=20
> appreciated, as this is still a concept brewing in my mind,=20
> and I would like to have every information possible about=20
> (dis)advantages of using multiple AppDomains. Hence the=20
> research I still have to do ;) .
>=20
>=20
> Regards,
> JS
>=20
> P.S.: I just remembered there is something I still have to do=20
> in the code. Plugins need not declare their dependance on=20
> Core.Runtime and Core.Boot (as they are implicit imports:=20
> they are always activated and loaded in memory when other=20
> plugins are loaded). The code, in its present state, succeeds=20
> in finding classes in the plugin and its imports _except_ for=20
> the import of Core.Runtime/Core.Boot . In other words, if the=20
> developer, in a plugin, tries to use the AssemblyLoader=20
> mechanism to search for a class in Core.Runtime/Core.Boot,=20
> this search will fail.
> The resolution to this should be very small and=20
> straightforward (in the code, besides all imports, add an=20
> import of Core.Runtime; Core.Runtime already has an import of=20
> Core.Boot). Tomorrow morning, I'll do the correction and test it.
>=20
>=20
> ------------------------------------
> Jo=E3o Paulo Pedro Mendes de Sousa Saraiva Estudante=20
> jps...@ne... jpp...@ho...=20
> jpp...@gm... Rua Mateus Vicente, 9, 10=B0 Dto
> 1500-445 Lisboa
> tel: 217267899
> mobile: 965403291
> IM: jpp...@ho...
> http://mega.ist.utl.pt/~jmss/
> ------------------------------------
> =20
>=20
> > -----Original Message-----
> > From: ecl...@li...
> > [mailto:ecl...@li...]
> > On Behalf Of Kunle Odutola
> > Sent: quinta-feira, 8 de Dezembro de 2005 19:25
> > To: ecl...@li...
> > Subject: RE: [Eclipsedotnet-developers] AssemblyLoader mechanism=20
> > improved
> >=20
> > Jo=E3o,
> >=20
> > > This was also to start paving the way to using AppDomains in the=20
> > > platform, although I still have a lot to read regarding
> > this subject,
> > > as it can have great effects on the platform.
> >=20
> > What other uses for AppDomains are you suggesting/planning here?.
> >=20
> > Kunle
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log=20
> > files for problems?  Stop!  Download the new AJAX search=20
> engine that=20
> > makes searching your log files as easy as surfing the  web.=20
>  DOWNLOAD=20
> > SPLUNK!
> > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick
> > _______________________________________________
> > Eclipsedotnet-developers mailing list
> > Ecl...@li...
> >=20
> https://lists.sourceforge.net/lists/listinfo/eclipsedotnet-developers
> >=20
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.362 / Virus Database: 267.13.12/192 - Release
> > Date: 05-12-2005
> > =20
> >=20
>=20
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.362 / Virus Database: 267.13.12/192 - Release=20
> Date: 05-12-2005
> =20
>=20

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.12/192 - Release Date: =
05-12-2005
=20