Sto utilizzando tomcat con eclissi.Ordine di caricamento della classe Tomcat durante la pubblicazione di moduli senza pubblicazione
Secondo la documentazione di Tomcat:
dal punto di vista di un'applicazione web, di classe o di una risorsa di carico cerca nelle seguenti repository, in questo ordine:
- classi Bootstrap della vostra classe JVM sistema classi di caricamento (descritte sopra )
- /WEB-INF/classi della tua applicazione web
- /WEB-INF/lib/*.jar della tua applicazione web zione
- classi caricatore di classe comune (di cui sopra)
Così, quando si carica un classi, Tomcat cercherà WEB-INF/classes prima WEB-INF/lib. E possiamo sovrascrivere qualche classe nei file jar in WEB-INF/lib, tomcat prenderà quello sovrascritto.
Ma ora se ho modificato le opzioni del server tomcat selezionando "Pubblica moduli senza pubblicazione" , le classi sovrascritte non verranno più caricate.
C'è qualche soluzione per farlo funzionare di nuovo, ma voglio comunque che tomcat serva i moduli senza pubblicazione.
Modifiche:
Ho trovato qualcosa può essere utile, in questa cartella f: \ eclipse_projects \ .metadata.plugins \ org.eclipse.wst.server.core \ tmp0 \ conf c'è un server.xml contiene tali contenuti:
<Resources className="org.eclipse.jst.server.tomcat.loader.WtpDirContext"
extraResourcePaths=""
virtualClasspath="F:\eclipse_projects\ALS7C3\bin"/>
<Loader className="org.eclipse.jst.server.tomcat.loader.WtpWebappLoader"
useSystemClassLoaderAsParent="false"
virtualClasspath="F:\eclipse_projects\ALS7C3\bin"/>
sembra che durante l'esecuzione di Tomcat con l'opzione "Servire moduli senza editoriale" controllato, eclissi lo userà la propria loader.This loader è contenuto in un file jar che sarà copiato in f: \ eclipse_ projects \ .metadata.plugins \ org.eclipse.wst.server.core \ tmp0 \ lib ** all'avvio di tomcat in eclissi. Ecco parte del codice sorgente di ** org.eclipse.jst.server.tomcat.loader.WtpDirContext:
public Object lookup(String name) throws NamingException {
if (name.startsWith("/WEB-INF/") && name.endsWith(".tld")) {
String tldName = name.substring(name.lastIndexOf("/") + 1);
if (virtualMappings != null && virtualMappings.containsKey(tldName)) {
return new FileResource(virtualMappings.get(tldName));
}
} else if (tagfileMappings != null && name.startsWith("/META-INF/tags")
&& (name.endsWith(".tag") || name.endsWith(".tagx"))) {
// already loaded tag file
return new FileResource(tagfileMappings.get(name));
}
Object retSuper;
NamingException superEx;
try {
retSuper = super.lookup(name);
return retSuper;
} catch (NamingException ex) {
retSuper = null;
superEx = ex;
}
if (mappedResourcePaths != null) {
// Perform lookup using the extra resource paths
for (Map.Entry<String, List<String>> mapping : mappedResourcePaths.entrySet()) {
String path = mapping.getKey();
List<String> dirList = mapping.getValue();
if (name.equals(path)) {
for (String resourcesDir : dirList) {
File f = new File(resourcesDir);
if (f.exists() && f.canRead()) {
if (f.isFile()) {
return new FileResource(f);
}
else {
// TODO Handle directory
}
}
}
}
path += "/";
if (name.startsWith(path)) {
String res = name.substring(path.length());
for (String resourcesDir : dirList) {
File f = new File (resourcesDir + "/" + res);
if (f.exists() && f.canRead()) {
if (f.isFile()) {
return new FileResource(f);
}
else {
// TODO Handle directory
}
}
}
}
}
}
throw superEx;
}
sembra che se sarà prima maniglia libreria di tag JSP quindi chiamare super.lookup , se non riesci a trovare in super.lookup, tenterà di caricare la risorsa in virtualClasspath, "F: \ eclipse_projects \ ALS7C3 \ bin" nel mio esempio, è dove eclipse emette i file di classe quando serve i moduli senza pubblicazione.
Quindi, credo, posso ottenere ciò che voglio se posso sovrascrivere il metodo diricerca di org.eclipse.jst.server.tomcat.loader.WtpDirContext, tuttavia questo file jar è contenuto in org .eclipse.jst.server.tomcat.core.jar, entrambi sono firmati.
Non so come sovrascrivere un file jar di questo tipo.
Chiunque può aiutare?
Perché vuoi ignorare le tue lezioni? I programmi non dovrebbero dipendere dal comportamento del classloading. Le implementazioni differiscono. – Keerthivasan
@Keerthi Per comodità in fase di sviluppo, abbiamo alcuni file jar che non hanno codice sorgente o documentazione. Ad esempio, voglio cambiare il formato del registro per eliminare informazioni inutili durante lo sviluppo, ma il formato del registro è codificato in alcune classi in quei barattoli. – CaiNiaoCoder
È possibile controllare i livelli di registrazione in base al pacchetto. Come per mia conoscenza, il programma di caricamento classi non caricherà di nuovo una classe con lo stesso nome e struttura del pacchetto. cioè override. L'ordine in cui sono caricate le classi è importante. Per favore fatemi sapere se ho torto – Keerthivasan