Tomcat lib-configuration (axis2, hibernate, logging)

[Mario___]

Hallo zusammen,

kurz mal zur web-applikation: Die Anmeldung geht über einen eigenen Realm, welcher mittels hibernate aus einer Userdatenbank die notwendigen Daten liest (myrealm.jar), die notwendigen jar files habe ich alle in die server/lib des tomcat gegeben, sieht jetzt so aus:

hineinkopiert:
myrealm.jar
asm-3.1.jar
cglib-nodep-2.1_3.jar
commons-collections-2.1.1.jar
commons-logging-1.0.4.jar
dom4j-1.6.1.jar
ejb3-persistence.jar
hibernate-annotations.jar
hibernate-commons-annotations.jar
hibernate3.jar
jta.jar
junit-4.5.jar
log4j-1.2.15.jar
mysql-connector-java-5.1.5-bin.jar
own-services-api.jar

waren schon drin:
annotations-api.jar
catalina-ant.jar
catalina-ha.jar
catalina-tribes.jar
catalina.jar
el-api.jar
jasper-el.jar
jasper-jdt.jar
jasper.jar
jsp-api.jar
servlet-api.jar
tomcat-coyote.jar
tomcat-dbcp.jar
tomcat-i18n-es.jar
tomcat-i18n-fr.jar
tomcat-i18n-ja.jar

Die Webapplikation selber muss auf eine andere Datenbank (auch mit hibernate), damit sieht die WEB-INF/lib so aus:

antlr-2.7.2.jar
asm-3.1.jar
asm-commons-3.1.jar
c3p0-0.9.1.2.jar
catalina.jar
cglib-nodep-2.1_3.jar
commons-beanutils-1.6.jar
commons-chain-1.1.jar
commons-collections-2.1.1.jar
commons-csv-20070724.jar
commons-digester.jar
commons-fileupload-1.2.1.jar
commons-io-1.4.jar
commons-lang-2.4.jar
commons-logging-1.0.4.jar
commons-logging-api-1.1.jar
commons-validator-1.3.1.jar
dom4j-1.6.1.jar
ejb3-persistence.jar
FontBox-0.1.0-dev.jar
freemarker-2.3.8.jar
hibernate-annotations.jar
hibernate-commons-annotations.jar
hibernate3.jar
iText-2.1.3.jar
iText-rtf-2.1.3.jar
jta.jar
log4j-1.2.15.jar
mail.jar
ognl-2.6.11.jar
original-xwork-2.1.2-SNAPSHOT.jar
oro-2.0.8.jar
PDFBox-0.7.3.jar
myrelease-management.jar
myservices-api.jar
myservices-impl.jar
myservices.jar
myPropertyReader.jar
struts-core-1.3.5.jar
struts2-config-browser-plugin-2.1.3-SNAPSHOT.jar
struts2-convention-plugin-2.1.3-SNAPSHOT.jar
struts2-core-2.1.3-SNAPSHOT.jar
struts2-pell-multipart-plugin-2.1.3-SNAPSHOT.jar

Das ganze hat gut funktioniert. Nun musste ich ein WebService (mit axis2) einbinden, welches jetzt services der Webapplikation benutzt, also nur code generieren und ein paar zeilen selber schreiben. + folgende jars im WEB-INF/lib

axiom-api-1.2.7.jar
axiom-impl-1.2.7.jar
axis2-adb-1.4.1.jar
axis2-jaxws-1.4.1.jar
axis2-kernel-1.4.1.jar
backport-util-concurrent-3.1.jar
commons-httpclient-3.1.jar
neethi-2.0.4.jar
woden-api-1.0M8.jar
wsdl4j-1.6.2.jar
XmlSchema-1.4.2.jar

Wenn jetzt aber das WebService aufgerufen wird gibt es folgende Exception:

SCHWERWIEGEND: Servlet.service() for servlet AxisServlet threw exception
org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:385)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at org.apache.axis2.context.MessageContext.<clinit>(MessageContext.java:105)
at org.apache.axis2.context.ConfigurationContext.createMessageContext(ConfigurationContext.java:486)
at org.apache.axis2.transport.http.AxisServlet.createMessageContext(AxisServlet.java:626)
at org.apache.axis2.transport.http.AxisServlet.createMessageContext(AxisServlet.java:704)
at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:121)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Unknown Source)


Ich weiß das es wegen der commons-logging-1.0.4.jar im (WEB-INF/lib) und commons-logging-1.0.4.jar (im server/lib) ist, aber diese werden dort gebraucht. Entferne ich die commons-logging-1.0.4.jar im server/lib muss ich den rest auch entfernen bis zu den hibernate Klassen und damit kommt myreal.jar auch in die WEB-INF/lib, aber da findet tomcat es beim starten nicht. Umgekehrt wenn ich es im WEB-INF/lib entferne (+ hibernate-jars), wird hibernate-jars im server geladen und findeten die mapping-Klassen nicht mehr (die in der Webapplikation).

Verzwickte situation! Ich hoffe jemand weiß wie ich da rauskomme.

lg Mario

 

[maki]

commons-logging-1.0.4.jar
commons-logging-api-1.1.jar

???

Die API sollte übrigens reichen, auf jedenfall sollte niemals die commons-logging Implementierung verwendet werden, da diese eine Fehlkonstruktion ist.

 

[Mario___]

danke für die schnelle antwort, jetzt verwende ich nur die API im WEB-INF/lib und server/lib und es funktioniert!

wusste nicht das die commons-logging eine Fehlkonstruktion ist, werde es mir jetzt aber merken!

VIELEN DANK

 

[Mario___]

Ok die freude war von kurzer Dauer! Anscheinend hat der rebuild vorhin im eclipse nicht richtig funktioniert, aber dafür hat dann das Webservice funktioniert, jetzt nach einem clean hab ich folgende Exception:

Caused by: org.hibernate.HibernateException: Could not parse configuration: hibernate.cfg.xml
at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:1500)
at org.hibernate.cfg.AnnotationConfiguration.doConfigure(AnnotationConfiguration.java:990)
at org.hibernate.cfg.AnnotationConfiguration.doConfigure(AnnotationConfiguration.java:69)
at org.hibernate.cfg.Configuration.configure(Configuration.java:1434)
at org.hibernate.cfg.AnnotationConfiguration.configure(AnnotationConfiguration.java:972)
at com.priorit.metis.utils.HibernateUtil.createSessionFactory(HibernateUtil.java:45)
... 31 more
Caused by: org.dom4j.DocumentException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory Nested exception: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
at org.dom4j.io.SAXReader.read(SAXReader.java:484)
at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:1490)
... 36 more


Die Situtation ist die gleiche wie vorhin, nur das common-logging-1.0.4.jar komplett weg ist und dafür im server lib die common-logging-api-1.1.jar drin

 

[Gast]

Genauer gesagt, das login durch den Realm hat funktioniert, dann sollte die Connection auf die Applikationsdatenbank hergestellt werden und dann geschieht das oben beschriebene

 

[byte]

commons-logging-1.0.4.jar
commons-logging-api-1.1.jar

???

Die API sollte übrigens reichen, auf jedenfall sollte niemals die commons-logging Implementierung verwendet werden, da diese eine Fehlkonstruktion ist.

Kannst Du das bitte mal genauer ausführen?

 

[maki]

Kannst Du das bitte mal genauer ausführen?

Die commons-logging hat leider einen viel besseren Ruf (durch das commons-* im Namen) als sie verdient.

Als zwischenschicht/API kann man sie zwar gefahrlos verwenden, aber sobald man die commons-logging Implementerung zum Loggen selbst verwendet (also nicht nur um die eigentliche Implementierung wie zB. log4j zu nutzen), fangen die Probleme an, sie haben den sog. "Classloader Hack" um automatich herauszufinden wie geloggt werden soll falls es nicht explizit konfiguriert ist.

http://www.google.co.uk/search?num=...ns+logging+classloader+hack&btnG=Search&meta=

Dieses verhalten führt auf bestimmten Umgebungen (OSGi, manche EJB App Server) zu Memory Leaks und anderen "lustigen" Problemen.

imho finger weg davon wenn möglich, log4j ist doch mehr als ausreichend, und wenn man unabhängig sein will, gibt es ja noch slf4j.

 

[byte]

Achso ok. Danke für die Info. Wir benutzen die Commons Logging API + log4j, daher bin ich hellhörig geworden.

 

[Mario___]

Hat jemand eine Lösungsvorschlag für mich?

 

[Mario___]

Das Problem liegt ja darin dass der Realm auch hibernate verwendet und somit das common-logging in konflikt kommt.

Im Realm verwende ich hibernate nur um die Connection zur Datenbank zu managen. In der context.xml bzw. server.xml von Tomcat darf ich keine einträge machen, deshalb kann ich auch nicht die <Resource name=..../> verwenden.

Hat jemand eine alternative zu hibernate um die Datenbankverbindung zu managen?

 

[Mario__]

Habe jetzt statt hibernate, smartpool als connection pool verwendet, somit kann ich das common-logging aus dem server lib entfernen und das problem besteht nicht mehr

 

[maki]

Jaja, die "gute" alte commons-logging Sch.....

Glückwunsch an dich Mario.