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.<http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2>
>