Re: SPI-fly and JSR-203

2016-09-30 15:02 GMT+02:00 David Bosschaert : > Modifying the JRE installation via the endorsed this might be the only way > to do this, but that really means that everyone using that JRE gets your > hack and doesn't really support any kind of deployment lifecycle at

RE: Blueprint issue with generics

Ah ok. If it’s a matter of toggling the mode, could be even more easy to have a flag in the config.properties. Something like “org.apache.aries.blueprint.allow-erasure-conversion”. I may give it a try to look at the code and maybe find a solution, but I doubt I would be able to push back the

Re: Blueprint issue with generics

I certainly would not oppose extending the ext namespace, or adding a new namespace for that. But I also don't plan to spend a day on that, as there is an easy workaround : this is already available by adding a few lines of xml, or even adding a new file, those can be easily done from the pom

RE: Blueprint issue with generics

Hi Guillaume, Do you think a fallback converter option (or via a fragment) might be added to Aries? JP De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com] Envoyé : mardi 27 septembre 2016 11:12 À : user@aries.apache.org Objet : RE: Blueprint issue with generics This

Re: SPI-fly and JSR-203

Hi Guillaume, I don't think you *can* hack the java.util.ServiceLoader. It's in java.* (not in javax.*) and those packages are designated for the JRE only. If you try to load them from another place you'll get a security exception of some sort. Cheers, David On 30 September 2016 at 07:27,

Re: SPI-fly and JSR-203

2016-09-29 23:36 GMT+02:00 David Bosschaert : > Yes, SPI-Fly only handles setting the ThreadContextClassLoader for the > duration of certain invocations. > > BTW Anyone know whether there exist such a hacked endorsed jar for the > file system provider? > I'm not aware