Skip to main content

Overriding a GF module jar in V 3.1.2

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
1 reply [Last post]
Comerford, Sean...
Offline
Joined: 2010-11-05

We have a library we received from a vendor that requires a fairly old version woodstox.

It won't work with the JAR we get in $GF_HOME/modules and we've had no luck forcing our GF instance to use the old version.

It 2.1 classpath-prefix would usually do the trick for us but it seems the behavior of that property has changed.

What is the recommended way to force a single GF to downgrade to an older version of a core module?

So far the only we've gotten this to work is by deleting the woodstox jar from the GF modules directory but that's not an acceptable solution :-)

---
Sean Comerford
ESPN.com Architecture & Platforms

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mgainty
Offline
Joined: 2004-05-21

SeanHere is the pom.xml to build your ear which is located in gf-3.2 distro <?xml version="1.0"?>

4.0.0
org.glassfish.metro
wstx-project
2.2.0-1
--> org.glassfish.metro wstx-services 2.2.0-1

ear
WS-TX Protocol Web Services

javax.xml
webservices-api-osgi
${project.version}

com.sun.xml.ws
webservices-osgi
${project.version}

org.codehaus.woodstox
wstx-asl
3.2.1

basically this pom.xml says in order to build this ear you will need to include all version-specific dependent jars ...each of which is included in tag The pure Glassfish way is to Deploy the dependent application.
2. Web and App Classloaders are different and do not cross boundaries Add the dependent application’s client JAR file to the
calling application.

For a calling EJB component, add the client JAR file at the same level as the
EJB component. Then add a Class-Path entry to the MANIFEST.MF
file of the calling EJB component. The Class-Path entry has this
syntax Class-Path: EJBClient.jar wstx-asl.jar ...
Each filepath is relative to the directory or JAR file containing
the MANIFEST.MF file. For details, see the Java EE
specification.

For a calling web
component, add the client JAR file under the WEB-INF/lib
directory.

3. App and Web both share the same jars: If you need to package the client JAR with both the EJB and
web components, set
delegate="true" in the class-loader
element of the glassfish-web.xml file.

MG>
This changes the Web class loader so that it follows the standard class
loader delegation model and delegates to its parent *app* CL before attempting to load a
class itself from Web CL
i would be cautious of this as your app jars are going to 'cross boundaries' to import into webspaceMG>
i'll pick up this thread on on maven users listhttp://maven.apache.org/mail-lists.html
Martin
______________________________________________
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: Sean.Comerford@espn.com
To: users@glassfish.java.net
Date: Tue, 12 Mar 2013 15:12:40 -0400
Subject: Overriding a GF module jar in V 3.1.2

We have a library we received from a vendor that requires a fairly old version woodstox.
It won't work with the JAR we get in $GF_HOME/modules and we've had no luck forcing our GF instance to use the old version.
It 2.1 classpath-prefix would usually do the trick for us but it seems the behavior of that property has changed.
What is the recommended way to force a single GF to downgrade to an older version of a core module?
So far the only we've gotten this to work is by deleting the woodstox jar from the GF modules directory but that's not an acceptable solution :-)
---Sean ComerfordESPN.com Architecture & Platforms