Hey Matin,
Thanks for the help.
Some additional info from my side – this is part of an Xgames stats ingest process. So there's no webapp or dependent app in play, just an EJB jar inside of an EAR.
We have a timer bean that needs to call a remote http service endpoint to fetch some data – the client the vendor gave us depends on that old version of woodstox. The maven dependency we have for the client does in fact pull in the correct version to our ear's APP-INF/lib folder but that always gets overridden by the corresponding GF module.
If I'm following the email below, it sounds like we just need to add a classpath entry to the manifest of our EJB jar to explicitly point to our apps required (old) version of woodstox.
Does that right? And is there an EJB jar / EAR level equivalent of delegate="true"?
---
Sean Comerford
ESPN.com Architecture & Platforms
From: Martin Gainty <mgainty_at_hotmail.com<mailto:mgainty_at_hotmail.com>>
Reply-To: "users_at_glassfish.java.net<mailto:users_at_glassfish.java.net>" <users_at_glassfish.java.net<mailto:users_at_glassfish.java.net>>
Date: Tue, 12 Mar 2013 20:03:56 -0400
To: "users_at_glassfish.java.net<mailto:users_at_glassfish.java.net>" <users_at_glassfish.java.net<mailto:users_at_glassfish.java.net>>
Subject: RE: Overriding a GF module jar in V 3.1.2
Sean
Here is the pom.xml to build your ear which is located in gf-3.2 distro
<?xml version="1.0"?>
<!--
DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
Copyright (c) 1997-2011 Oracle and/or its affiliates. All rights reserved.
The contents of this file are subject to the terms of either the GNU
General Public License Version 2 only ("GPL") or the Common Development
and Distribution License("CDDL") (collectively, the "License"). You
may not use this file except in compliance with the License. You can
obtain a copy of the License at
https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
or packager/legal/LICENSE.txt. See the License for the specific
language governing permissions and limitations under the License.
When distributing the software, include this License Header Notice in each
file and include the License file at packager/legal/LICENSE.txt.
GPL Classpath Exception:
Oracle designates this particular file as subject to the "Classpath"
exception as provided by Oracle in the GPL Version 2 section of the License
file that accompanied this code.
Modifications:
If applicable, add the following below the License Header, with the fields
enclosed by brackets [] replaced by your own identifying information:
"Portions Copyright [year] [name of copyright owner]"
Contributor(s):
If you wish your version of this file to be governed by only the CDDL or
only the GPL Version 2, indicate your decision by adding "[Contributor]
elects to include this software in this distribution under the [CDDL or GPL
Version 2] license." If you don't indicate a single choice of license, a
recipient has the option to distribute your version of this file under
either the CDDL, the GPL Version 2 or to extend the choice of license to
its licensees as provided above. However, if you add GPL Version 2 code
and therefore, elected the GPL Version 2 license, then the option applies
only if the new code is made subject to such option by the copyright
holder.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<!--
<parent>
<groupId>org.glassfish.metro</groupId>
<artifactId>wstx-project</artifactId>
<version>2.2.0-1</version>
</parent>
-->
<groupId>org.glassfish.metro</groupId>
<artifactId>wstx-services</artifactId>
<version>2.2.0-1</version>
<packaging>ear</packaging>
<name>WS-TX Protocol Web Services</name>
<dependencies>
<dependency>
<groupId>javax.xml</groupId>
<artifactId>webservices-api-osgi</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>webservices-osgi</artifactId>
<version>${project.version}</version>
</dependency>
<!-- assuming you're connected to internet you can include your version-specific woodstox here -->
<dependency>
<groupId>org.codehaus.woodstox</groupId>
<artifactId>wstx-asl</artifactId>
<version>3.2.1</version>
</dependency>
<!-- end mods woodstox -->
</dependencies>
</project>
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 <dependency> tag
The pure Glassfish way is to
1. 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.
2.
* 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 webspace
MG>
i'll pick up this thread on on maven users list
http://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_at_espn.com<mailto:Sean.Comerford_at_espn.com>
To: users_at_glassfish.java.net<mailto:users_at_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 Comerford
ESPN.com Architecture & Platforms