[Java] eigen dir ipv ext/lib folder

[Lucky_me]

Hallo,

Ik ben bezig een java applicatie te bouwen die gebruik maakt van externe Jar files (uit de SDK van business objects van crystal reports 4 eclipse). Als ik al deze JAR's in een aparte map "lib" zet naast de geëxporteerde applicatie, en ik mijn manifest netjes aanpas, vind hij alle benodigde jars uit de aangemaakte "lib" folder, toch geeft hij even later alsnog een "NoClassDefFoundError" error.

Zodra ik alle JAR's verplaats naar de "ext" folder van mijn JRE (C:\Program Files\Java\jre1.6.0\lib\ext), werkt alles in 1x wel. Toch zou ik graag mijn "lib" folder willen gebruiken omzo de applicatie uiteindelijk makkelijk te distribueren als 1 map. En om te voorkomen dat als er een JRE update is dat hij daarna ineens de ext folder met mijn JAR's niet meer kan vinden.

Heeft iemand een suggestie?


Hieronder een overzicht van melding en manifest config:

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/collections/Predicate
at com.crystaldecisions.reports.common.engine.ConfigurationMana ger.<init>(Unknown Source)
at com.crystaldecisions.reports.common.engine.Engine.configure( Unknown Source)
at com.crystaldecisions.reports.common.engine.Engine.getConfigu rationManager(Unknown Source)
at com.crystaldecisions.reports.common.engine.a.a(Unknown Source)
at com.crystaldecisions.reports.common.engine.Engine.getKeycode Manager(Unknown Source)
at com.businessobjects.reports.sdk.a.a(Unknown Source)
at com.businessobjects.reports.sdk.a.<init>(Unknown Source)
at com.businessobjects.reports.sdk.a.if(Unknown Source)
at com.businessobjects.reports.sdk.JRCCommunicationAdapter.void (UnknownSource)
at com.businessobjects.reports.sdk.JRCCommunicationAdapter.conn ect(Unknown Source)
at com.crystaldecisions.proxy.remoteagent.y.a(Unknown Source)
at com.crystaldecisions.sdk.occa.report.application.ReportAppSe ssion.int(Unknown Source)
at com.crystaldecisions.sdk.occa.report.application.ReportAppSe ssion.initialize(Unknown Source) at com.crystaldecisions.sdk.occa.report.application.ClientDocum ent.for(Unknown Source)
at com.crystaldecisions.sdk.occa.report.application.ReportClien tDocument.for(Unknown Source)
at com.crystaldecisions.sdk.occa.report.application.ClientDocum ent.open(Unknown Source)
at com.crystaldecisions.reports.sdk.ReportClientDocument.open(U nknown Source)
at connection.ClsCrystalReports.exportXML(ClsCrystalReports.jav a:61)
at profiles.ClsAposys.verwerkEMDs(ClsMijnklasse.java:66)
at main.ClsFarmadex.start(ClsAndereklasse.java:14)
at main.ClsFarmadex.main(ClsAndereklasse.java:9)

Dit is mijn manifest

Class-Path: lib\axis-ant.jar lib\axis.jar lib\cecore.jar lib\celib.jar
lib\commons-collections-3.1.jar lib\commons-configuration-1.2.jar lib\
commons-discovery.jar lib\commons-lang-2.1.jar lib\commons-logging.jar
lib\Concurrent.jar lib\corbaidl.jar lib\CRDBJavaServerCommon.jar lib\
CRDBXMLExternal.jar lib\CRDBXMLServer.jar lib\CrystalCharting.jar lib\
CrystalCommon.jar lib\CrystalContentModels.jar lib\CrystalDatabaseConn
ectors.jar lib\CrystalExporters.jar lib\CrystalExportingBase.jar lib\Cr
ystalFormulas.jar lib\CrystalQueryEngine.jar lib\CrystalReportEngine.j
ar lib\CrystalReportingCommon.jar lib\ebus405.jar lib\icu4j.jar lib\ja
xrpc.jar lib\jrcadapter.jar lib\jrcerom.jar lib\keycodeDecoder.jar lib
\log4j.jar lib\MetafileRenderer.jar lib\pullparser.jar lib\rasapp.jar
lib\rascore.jar lib\ReportPrinter.jar lib\ReportViewer.jar lib\rpoifs.
jar lib\saaj.jar lib\serialization.jar lib\tet.txt lib\URIUtil.jar lib\
webreporting-jsf.jar lib\webreporting.jar lib\wsdl4j.jar lib\xbean.ja
r lib\xercesImpl.jar lib\xml-apis.jar
Main-Class: main.myMainClass

[The - DDD]

Maak van die backslashes is slashes in je Class-Path entry.

[Lucky_me]

Dat maakt helaas niet uit. Aangezien hij (zoals ik in mijn bericht heb vermeld) een aantal andere libraries dmv deze manifest wel vind. Dus de slashes zijn wel ok.

[Janoz]

Zet ze toch maar even adnersom. Daarnaast:

Continuation
Manifest files have about strangest continuation convention ever invented. No line may be longer than 72 bytes (not characters), in its UTF8-encoded form. If a value would make the initial line longer than this, it should be continued on extra lines (each starting with a single SPACE). Don't split a name over two lines. e.g.

Main-Class: com.mindprod.MyProgram
Class-Path: activation.jar axis.jar
commons-discovery.jar
commons-logging.jar
jaxrpc.jar
log4j-1.2.8.jar
mail.jar saaj.jar junit.jar

I suggest putting long names on a line by themselves, with a single space on the start of the line, and using short names to stay away from the 72 limit. Be very careful with spaces. Don't add extra ones or remove any. jar.exe is highly senstive to having its spaces and blank lines just right. It does not give helpful error messages.

Ik zie in je copy paste actie sowieso enkele namen die afgebroken zijn en ik heb verder niet eens gekoken of regels breder dan 72 tekens zijn.

[The - DDD]

Dat zou het best is kunnen zijn.

Ik kijk even in een door Maven 2 gegenereerde manifest:

code:

Class-Path: relaxngDatatype-1.0.4.jar XX-XXXXX-ejb-1.0.0-ibm.jar xsdli
 b-1.0.4.jar jaxb-api-1.0.4.jar jaxb-impl-1.0.4.jar jaxb-libs-1.0.4.ja
 r XXXXXXXXX.jar log4j-1.2.9.jar XXXXXXXXXXXXX-1.0.0-SNAPSHOT.jar XXXX
 XXXXXX-1.0.0-ibm.jar namespace-1.0.4.jar spring-2.0.1.jar jaxb-xjc-1.
 0.4.jar XXXXXXXXXXX-1.0.0-SNAPSHOT.jar XXXXXXXXXXXXXXX.jar XXXXXXXXXX
 XXXXXX.jar

Zat me al af te vragen waarom Maven 2 die manifests zo genereerd.

Afbreken is zo tez ien geen probleem midden in paden.

[ Voor 4% gewijzigd door The - DDD op 01-05-2007 11:24 ]

[Lucky_me]

Bedankt voor de tips, maar helaas heeft dat geen succes, dit is mijn nieuwe manifest, en hij vindt zeker weten de laatste jar "lib/sunjce_provider.jar" (Het programma start al wel, waarvoor de laatste library iig zeker weten nodig is)

Ik vrees dat het het iets Crystal Reports specifiek is. Heb ook al in de jars zelf zitten zoeken naar externe verwijzingen maar vind er niets speciaals.

code:

Manifest-Version: 1.0
Main-Class: main.xxxxxx
Class-Path: lib/axis-ant.jar lib/axis.jar lib/cecore.jar 
 lib/celib.jar
 lib/commons-collections-3.1.jar lib/commons-configuration-1.2.jar
 lib/commons-discovery.jar lib/commons-lang-2.1.jar
 lib/commons-logging.jar lib/Concurrent.jar lib/corbaidl.jar
 lib/CRDBJavaServerCommon.jar lib/CRDBXMLExternal.jar
 lib/CRDBXMLServer.jar lib/CrystalCharting.jar lib/CrystalCommon.jar
 lib/CrystalContentModels.jar lib/CrystalDatabaseConnectors.jar
 lib/CrystalExporters.jar lib/CrystalExportingBase.jar
 lib/CrystalFormulas.jar lib/CrystalQueryEngine.jar
 lib/CrystalReportEngine.jar lib/CrystalReportingCommon.jar
 lib/ebus405.jar lib/icu4j.jar lib/jaxrpc.jar lib/jrcadapter.jar
 lib/jrcerom.jar lib/keycodeDecoder.jar lib/log4j.jar
 lib/MetafileRenderer.jar lib/pullparser.jar lib/rasapp.jar
 lib/rascore.jar lib/ReportPrinter.jar lib/ReportViewer.jar 
 lib/rpoifs.jar
 lib/saaj.jar lib/serialization.jar lib/tet.txt lib/URIUtil.jar
 lib/webreporting-jsf.jar lib/webreporting.jar lib/wsdl4j.jar 
 lib/xbean.jar lib/xercesImpl.jar lib/xml-apis.jar lib/mail.jar 
 lib/sunjce_provider.jar

Er is ook een lege regel 23 die ook nodig schijnt te zijn voor het functioneren van de manifest

[ Voor 3% gewijzigd door Lucky_me op 01-05-2007 17:48 ]

[bloody]

The - DDD schreef op dinsdag 01 mei 2007 @ 11:22:
...

Zat me al af te vragen waarom Maven 2 die manifests zo genereerd.

Afbreken is zo tez ien geen probleem midden in paden.

Klopt, dat is de manifest standaard; schrijft voor dat er fixed-length regels moeten zijn

En dat van Maven2: mvn2 gooit ook alle transitieve dependencies in je jar, so be warned...
Vooral als je onder jboss 4 werkt, heb je 987 stacktraces (op DEBUG level dat wel) dat jboss een jarretje niet kan vinden dat wel in het manifest gespecificeerd staat. Logisch want je wil niet alle transitieve dependences meeslepen een release area.

[Lucky_me]

Weet iemand misschien dan het verschil tussen de 2 mappen

lib/ext map in java_home
de classpath van de app

behalve dat de lib/ext folder eerder wordt doorzocht als de classpath? Want hiertussen zit blijkbaar het dilemma. Blijf het dan overigens nog steeds vreemd vinden dat eclipse wel runt met eigen classpath en de jar afzonderlijk niet...

[Lucky_me]

Ik heb een oplossing gevonden, misschien niet de meest mooie, maar het werkt in ieder geval

Wanneer ik als extra parameter meegeef:

code:

java -jar mijnjar.jar -Djava.ext.dirs=lib

dan doet hij het goed. Ondanks dat de class-path setting in de manifest dezelfde jars aanwijst.

[Janoz]

Ik blijf het heel vreemd vinden. Is het misschien een case verhaal? Dat de jar bestandsnamen in je lib qua case niet overeenkomen met die in je manifest?

[Lucky_me]

Nee ik heb net dus mijn manifest gewoon verwijderd, het enige dat ik als extra parameter opgeef is die java.ext.dirs door middel van die te setten vind hij alle benodigde jars in de juiste directory. De code kan op geen enkele andere manier aan de jars komen als via die variabele.

Overigens had ik mijn manifest class-path entries gewoon copy paste van de dosbox gedaan dus hoofdletters heeft ie gewoon meegepakt. Hoe de jars intern in elkaar steken heb ik geen idee van, heb de SDK ook niet zelf gebouwd... maar dat zou opzich toch ook niet hoeven maken lijkt me.

blijkbaar is de extension folder van java iets meer waard als een class-path entrie.. Dat bleek eigenlijk al toen ik mijn libs in %java_home%/ext/lib zette ipv eigen class-path dir.

[ Voor 14% gewijzigd door Lucky_me op 02-05-2007 14:59 ]