users@glassfish.java.net

RE: FileNotFoundException for lib dependency...

From: Martin Gainty <mgainty_at_hotmail.com>
Date: Mon, 3 May 2010 15:24:03 -0400

hopefully when you will be implement this solution into production the build engineer will convert whatever you have to
1)ant build.xml
2)maven pom.xml

the double lib is weird i would first look at .classpath file for any possible <in>correct located library entries e.g.
<classpathentry kind="lib" path="$AXIS2_HOME/lib/xmlsec-1.4.1.jar"/>

Stijn?
Martin Gainty
______________________________________________
Note de déni et de confidentialité
 Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.




From: smsiebe_at_gmail.com
Date: Mon, 3 May 2010 15:02:02 -0400
To: users_at_glassfish.dev.java.net
Subject: Re: FileNotFoundException for lib dependency...

Thanks Stijn and Martin,

Not having the ability to efficiently nest jars is a bit limiting, but certainly something I can get around through the build/deployment process. This leaves two questions:

1) Why doesn't Netbeans inform me of this during a build? I assume you don't want to error a build, in the event you're using an alternate ClassLoader (as you indicated)...but a warning such as "One of your dependencies has a non-satisfied dependency in the project, you doof" would be nice.



2) Why does GlassFish want the libs of these dependencies in <APP_ROOT>/lib/lib rather than <APP_ROOT>/lib? When I add those dependencies to the .ear directly (I tried this during my testing), it puts them in <APP_ROOT>/lib, so I still get the error. Flattening these libs causes code redundancy unless I do some build magic with the build/continuous integration. If that's the answer, that's fine...but I would think it would be something many people need/want to do and therefore a lot easier to accomplish. Anybody's experience in achieving a "clean"/complex build like this, I would be interested in learning your approach.




Martin, your explanation certainly helps me understand both what I am seeing as well as what Stijn explained - thank you.

I can't package everything in a war, in this instance, because I need MDB's as well. I took them out of the sample for simplification.




Thanks,

Steve

On Mon, May 3, 2010 at 2:47 PM, Martin Gainty <mgainty_at_hotmail.com> wrote:








the <WebArchive/ApplicationArchive> classloader sees only the jars/classes at that level e.g. the uber-Application Classloader sees all jars/ears/rars at $GF_HOME e.g.
$GF_HOME\imq\lib
$GF_HOME\lib\install\applications




any package with a war extension would automatically implement the WebApplication ClassLoader e.g.
$GF_HOME\imq\lib\*.war

tlds are (supposed to be) located at META-INF folder of the WebAppName e.g.


$GF_HOME\lib\install\applications\WebAppName\WebAppName_war\WEB-INF\lib\web-ui\META-INF


does this answer your question?
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.



Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.







From: smsiebe_at_gmail.com
Date: Mon, 3 May 2010 13:35:30 -0400
To: users_at_glassfish.dev.java.net



Subject: FileNotFoundException for lib dependency...

Hello all,

I have a similar problem I have read about on this mailing list, however, I have upgraded to the latest GlassFish (which resolved the first issue) and a new (but seemingly related) issue has come up. When I attempt to deploy my .ear, which contains .jar libraries with their own dependencies, I get two FileNotFoundExceptions (attached: fileNotFoundExceptions.txt). Each of the Exceptions are a result of "nested" dependencies, and not from the first-level. By this I mean:







centralizedLogger.ear
|__ centralizedLogger.jar (my EJB)
| |__ configuration.jar (deploys fine - this was fixed recently)
| | |__ get_dev-common (exception)
| | |__ javax.persistence.jar (exception - needed because I have Entity classes in configuration.jar)






| |__ logger.jar
| | |_ javax.persistence.jar (exception - again, have Entity classes in logger.jar)
| |__ persistence.xml (for both the configuration.jar and logger.jar Entities)
|__ centralizedLogger.war (nothing significant)







The persistence.xml is working - I can see the Entities being "transformed" and my tables being created from the DDL annotations (as I requested in the persistence.xml file). My SLSB's deploy and my application-scoped Singleton SLSB starts up. Then, I get the lib file dependency problem looking for the libraries in C:/glassfishv3/glassfish/domains/domain1/applications/centralizedLogger/lib/lib/get_dev-common.jar (forgive me, I am forced to work on a Windows box at work).







The javax.persistence.jar file I am referencing is referenced from each project from the C:/glassfishv3/glassfish/modules/ directory. Shouldn't the class loader already see this and not need it again?

The deployment is "successful", as they were just warnings, and GlassFish sets up the standard file system structure under my domain. The application seems to work fully, as well (LogEvents are being persisted, all SLSB's deploy and are operational...). If I manually place the jars in the "expected" place (lib/lib), restart the server, no more complaints.







Obviously, I can just add the libraries to passify the validating checking...but seems like there is something wrong (especially since everything is working dispite the warnings during "TLD scanning".






Thanks,

Steve
                                               
Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. See how.




                                               
_________________________________________________________________
The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5