Hello Romain, I already explained why I do not want to give file or jar:file URL, even if I have it. Maven resolver is giving me File, I create a VestigeJar from it https://gaellalire.fr/gitlab/vestige/vestige.spi.resolver/blob/master/src/main/java/fr/gaellalire/vestige/spi/resolver/VestigeJar.java I also create a mvn: URL accessible through getCodeBase however it is only for policy permission you should not use openStream on it (although I had to make it possible to get BouncyCastle working).
I think that SecureClassLoader is not secure enough because it only checks classes not resources. In a world using XML to create, configure and link instances (Spring), it is terrible to let resources unchecked. That's also why VestigeClassLoader#getResource is returning vrt: URL and not jar:file: URL. The easiest way to implements War Maven artifacts deployment is to use directly Maven resolver API and give file or jar:file URL to Tomcat. I could have done that, but guess what, I'm willing to give TomEE EAR Maven artifacts deployment after Tomcat. In the TomEE my company uses there is a horrible CLASSPATH because they wanted to avoid RMI call between EAR. That is where Vestige is useful, it allows to choose which jar(s) should be shared without any global impact. You have 3 scopes and 2 modes in Vestige. Mode CLASSPATH is creating one classloader with all jars inside, not easy to share. Mode FIXED_DEPENDENCIES is creating one classloader per jar, but implies some good practice (use of context classloader for example). After setting FIXED_DEPENDENCIES you have to use the PLATFORM scope to get it shared, this scope implies some other good practice (static field immutable for example). About memory issue, I don't get your point. I will not keep all jars content in memory I will use shared locks (fcntl) to keep the content of RandomAccessFile the way it was when I checked it. VestigeJar#open will create an InputStream reading from this locked RandomAccessFile. Regards, Gaël Lalire Le 17 mars 2019 à 10:17, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > Hi Gaël, > > In Tomee we plugged before to enrich the classloader and then tomcat -and > other libs - works normally using jar urls. > > Cant you use a listener to do that and convert m2 urls to plain jar files - > at the end it is local files i guess otherwise you generally consume too > much memory to be prod friendly? > > > Le dim. 17 mars 2019 à 09:46, Gaël Lalire <gael.lal...@gaellalire.fr> a > écrit : > >> Hello Tomcat developers, >> >> I made a software to enable update of Java applications named Vestige. >> To achieve that, Vestige use Maven, downloading Maven artifacts and >> creating classloaders linked with jar inside m2 repository. >> >> I made it to update my IBM notes connector (POP access provider). >> >> The fact it is downloading Maven artifacts makes the assembly >> (jar-with-dependencies of maven-assembly-plugin) of the connector not >> mandatory. >> >> In a business project I saw that war artifacts were filling the >> repository, so they had to regularly remove older version from it. >> I thought it would be great if we could remove the WEB-INF/lib from the >> published war and still be able to deploy it with Tomcat. >> >> I did that, the WebResource API helps me a lot. >> However I had to disable JarScanner API (tld & fragments) because it's >> using JarURLConnection and my API is not providing jar:file: nor file: URL. >> My API won't provide them because I want to be able to check a pgp >> signature before any use of an artifact in m2 repository. >> If I check the signature and send a jar:file: or file: URL it won't be >> secure because there is no way to prevent the modification of the file >> after the check. >> To be secure I will probably lock the file for reading, then check the >> signature, and give locked InputStream. >> >> I would like you to change the JarScanner API/Impl so it won't rely on >> JarURLConnection anymore (maybe WebResource ?). >> Also I have to replace some Tomcat classes ( >> https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige/commit/67dea6054c9da30047ebba3e9a376fa44b544f13) >> that is not future proof. >> Could you provide some extension(s) so I could do the same thing without >> replacing any Tomcat class ? >> >> Hoping that you get interested enough to help me improve the Maven >> artifact deployment support, I send you my best regards. >> >> PS: >> You can test the vwar, an xml which describes the war to deploy >> (essentially repository URL, groupId, artifactId, version), deployment by : >> - download (https://gaellalire.fr/vestige/) & install & run Vestige >> - go to http://localhost:8480/ >> - click on install >> - write "tomcat" in repository application name >> - write "8.0.32" in repository application version >> - write "tc" in local application name >> - click install button >> - click play button >> - go to http://localhost:8080/mywar/hello (servlet test) and >> http://localhost:8080/mywar/hi.jsp?max=5 (jsp test) >> >> The vwar will be at $VESTIGE_BASE/app/tc/webapps/mywar.vwar >> Where $VESTIGE_BASE is : >> - $HOME/Vestige on Mac OS X >> - $HOME/vestige on Linux >> - %userprofile%\Vestige on Windows >> - the place you unzip the file if you chose to install the standalone >> version (a ZIP file) >> >> You can also see it at >> https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige/blob/master/installer/src/main/resources/mywar.vwar >> >> tomcat_vestige sources at >> https://gaellalire.fr/gitlab/vestige_app/tomcat_vestige >> tomcat_vestige descriptor at >> https://gaellalire.fr/vestige/repository/tomcat/tomcat-8.0.32.xml >> mywar sources at https://gaellalire.fr/gitlab/vestige_app/mywar (its pom >> https://gaellalire.fr/gitlab/vestige_app/mywar/blob/master/pom.xml >> excludes lib folder) >> >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
