Alternative de Soleil SAAJ SAVON de mise en œuvre

Je suis à la recherche d'alternative au SAVON (javax.xml.soap) la mise en œuvre, autre que Soleil SAAJ. La raison pour cela est parce que je tiens à déployer JAX-WS WebService sur IBM JDK 5 pilotée par Tomcat, mais il est connu que le Soleil SAAJ mise en œuvre dépend de réaffectées Xerces classes (voir Ref Impl ne fonctionne pas avec JDK IBM et SAAJ cas de test ne plus travailler avec IBM SDK) et la seule façon de s'en sortir est d'utiliser un profil Maven pour tirer com.sun.xml.parsers:jaxp-ri comme:

<profiles>
    <profile>
        <id>pre-jdk5-profile</id>

        <activation>
            <jdk>(,1.4]</jdk>
        </activation>

        <dependencies>
            <dependency>
                <groupId>com.sun.xml.parsers</groupId>
                <artifactId>jaxp-ri</artifactId>
                <scope>runtime</scope>
            </dependency>
        </dependencies>
    </profile>
</profiles>

Je voudrais supprimer ce profil et il suffit de remplacer le SAVON mise en œuvre par une autre qui fonctionne partout.

Je suppose que le vendeur de SAVON implémentations peuvent venir avec Apache Axis /Apache CXF (qui est basé sur IBM SOAP4J) ou JBoss as – veuillez fournir des informations en fonction de mes préférences:

  • Mise en œuvre devrait être facile à séparer du reste du personnel (de préférence une lumière pondérée en pot).
  • Mise en œuvre devrait soutenir SAVON messages avec des pièces jointes.
  • Mise en œuvre devrait être Java5 bytecode compatible.
  • Si la mise en œuvre est disponible dans Maven Central, c'est un plus.

Références:

OriginalL'auteur dma_k | 2012-02-12

  1. 7

    Après avoir navigué autour de moi, je viens le potentiel de la solution du problème. J'ai exploré ce sont les descendants de javax.xml.soap.MessageFactory à l'aide de grepcode.com.

    En dehors de la norme com.sun.xml.messaging.saaj.soap.MessageFactoryImpl, j'ai trouvé (comme le suppose):

    • org.apache.axis2.saaj.MessageFactoryImpl dans org.apache.axis2:axis2-saaj:1.6.1. Ce POT correctement annonce les usines via META-INF\services\javax.xml.soap.MessageFactory et META-INF\services\javax.xml.soap.MetaFactory donc aucun autre réglage n'est nécessaire. Cette version (d'après Maven Central) a été publié en 2011, quelques dépendances, recommandé.
    • org.jboss.ws.core.soap.MessageFactoryImpl dans org.jboss.ws.native:jbossws-native-core:3.2.1.Beta2 de JBoss 3.x. L'air d'être assez vieux et peut-être JBoss n'est pas de soutenir son développement plus comme je l'ai été en mesure de trouver ce pot à l'extérieur de maven central (ici). Beaucoup de dépendances, de 1,8 M de taille, n'est pas recommandée.
    • org.apache.openejb.server.webservices.saaj.MessageFactoryImpl dans org.apache.openejb:openejb-webservices:4.0.0-bêta-2 et org.apache.geronimo.webservices.saaj.GeronimoMessageFactory dans org.apache.geronimo.modules:geronimo-webservices:3.0-M1. En réalité, l'une de ces usines est un wrapper/runtime_locator pour Axis2 ou le Soleil implémentations (voir SaajFactoryFinder et SAAJFactoryFinder). De ne pas être considéré.

    Ligne de fond: La seule solution acceptable est Axis2 mise en œuvre.

    Qui pourrait fonctionner. Si vous n'avez pas de succès avec Axis2 vous pourriez regarder dans l'aide de Spring WS qui devrait fonctionner sur du JDK 1.4.
    (malheureusement) à Partir de spring-ws-parent-2.0.4.La LIBÉRATION.pom: <dependency><groupId>com.sun.xml.messaging.saaj</groupId><artifactId>saaj-impl</artifactId><version>1.3.2</version></dependency> qui est un signal que peut-être le Printemps-WS utilise le Soleil SAAJ et ils en quelque sorte résoudre le même problème.
    Ouais, mon mauvais, uggh.

    OriginalL'auteur dma_k

  2. 0

    Bien que je ne sais pas la réponse à votre question, j'ai une solution comment vous pouvez le faire Sun SAAJ (et JAX-WS RI) de travail en vertu de JRE 1.5. La raison pourquoi il y a des problèmes avec l'exécution de JAX-WS RI sous Java 5 est en effet l'ancienne JAXP (Java 1.5 est livré avec JAXP 1.3, tandis que JAX-WS RI nécessite JAXP 1.4), ET parce que JAX-WS RI est codé en dur pour utiliser le Soleil JAXP RI (com.soleil.org.apache...). Depuis JAXP 1.3 est une partie de la JRE, vous ne pouvez pas il suffit de le remplacer (vous pouvez remplacer la mise en œuvre, mais pas de l'API).
    La solution est la activesoap de xerces port, qui est un coupe-bas JAXP version 1.4 qui utilise le Soleil JAXP RI paquet de nommage (com.soleil.org.apache.).
    Vous pouvez le trouver dans le repo Maven:

    <dependency>
    <groupId>activesoap</groupId>
    <artifactId>jaxb-xercesImpl</artifactId>
    <version>1.5</version>
</dependency>

    N'avez pas l'esprit de l'étrange paquet de nommage, il suffit de l'essayer.

    C'est souvent tout ce qui est nécessaire pour exécuter le Soleil JAX-WS RI (et SAAJ dans le cadre de celui-ci) sous Java 5.

    N'oubliez pas de ne PAS inclure l'API JAXP Pots. Ils seront en conflit avec Java 5 de l'API JAXP.

    rustyx, je vous remercie pour vos efforts, mais votre réponse va dans la mauvaise direction. Le profil que j'ai mentionné est exactement ce que vous suggérez: si le tire Soleil Xerces la mise en œuvre et résout ainsi le problème sous 1,5
    1) pourquoi ne pas toujours comprendre les jaxp pot? 2) êtes-vous sûr que vous pouvez changer simplement SAAJ sans passer par un autre JAX-WS pile??
    1) le fait d'Avoir plusieurs Xerces dans votre classpath n'est pas bon et peut conduire à des problèmes qui sont difficiles à repérer, car à certains moment je ne sais pas ce que Xerces sont utilisés. 2) je ne sais pas. Si cela n'est pas possible, j'espère que la communauté va dire. D'autre part, je ne vois pas de problème dans javax.xml.soap avoir un autre implémentations. Pourquoi cela devrait me forcer à passer à un autre de la pile?

    OriginalL'auteur rustyx

  3. 0

    Difficile. Peut-être regarder l'un de l'Apache CXF versions. http://cxf.apache.org/

    Vous pouvez essayer en le feuilletant le chargeur de classe, de grouper les pots que vous avez besoin avec votre application web et de les charger dans un PARENT_LAST modèle. C'est probablement votre meilleur pari.

    Une troisième option dans Tomcat pourrait être Approuvé les Normes de Remplacer le Mécanisme de prise en charge par Java et Tomcat. -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS

    Voir ici, je pense qu'il applique pour les anciennes versions de Tomcat: http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html#XML_Parsers_and_Java.

    Je sais que SAAJ mise en œuvre devrait être CXF, mais comment l'utiliser? Ce que les bocaux à utiliser? (eh bien, il n'est pas nécessaire de les mettre en endorsed comme je l'ai utiliser IBM JDK, qui n'est pas emballé avec SAAJ).
    Il a été quelques années mais j'ai dû faire quelque chose de similaire sur Websphere. renversé le chargeur de classe parent dernier et devait inclure quelques-uns des principaux pots en conflit avec mon web service. Je ne me souviens pas exactement des pots, j'ai eu à inclure. J'ai commencé avec le jaxp d'exécution et a dû courir en arrière dans un processus d'élimination.
    Je pense, j'ai trouvé l'approbation de ma théorie 🙂 Vérifier ma réponse.

    OriginalL'auteur TechTrip