Petals ESB Container

Le problème ne se produit que lorsque la webconsole essaie de contacter Petals.

Impossible à reproduire pour le moment, il nous faut plus d'informations sur le contexte dans lequel se produit cette exception

Nous avons réussi à reproduire le problème. Il semble venir du nombre de SU installées.

1. Lancer Petals 3.1 (conf par défaut)
2. Créer une base pour le SE-KPI
3. Prendre le fichier de conf petals-view.properties, et le renseigner pour qu'il pointe sur la base de PetalsView
4. Modifier le chemin du fichier de conf de petals-view dans le jbi.xml du SE-KPI
5. Modifier le jbi.xml du SE-XSLT pour qu'il pointe vers le fichier conf.xml (pas besoin de le modifier, il est déjà OK pour la base de transco)
6. Déployer la shared-library oracle
7. Installer tous les composants, en commencant par le SE-KPI
8. Déployer toutes les SU
9. Démarrer Tomcat, aller sur la page de la webconsole, et constater la présence d'une stacktrace.

I investigated the problem, it appears in the following method:

public Document getDescription(String serviceName, String endpointName)
throws EndpointRegistryServiceErrorException

This method is located in EndpointRegistryClient class of petals-jmx

The following line returned the stacktrace by performing the action with
service name = {http://wsdls.datastream.net/MP0302_GetAssetEquipment_001}AD009-GetAssetEquipmentService
endpoint name = edpt-8CCE22D14897EECDFF54534999866461=

document = (Document) this.performAction(GET_ENDPOINT_DESCRIPTION, objects, strings);

The document that attempts to be recovered corresponds to the following service unit : su-SOAP-AD009-GetAssetEquipmentService-provide-1.0.0-SNAPSHOT

I tested by removing the service assembly (sa-AD009-RecupVersionPointInterventionSigma-1.0.0-SNAPSHOT-07-27-2010-043849102) which contains this service unit and it works correctly.

La SA "sa-AD009-RecupVersionPointInterventionSigma-1.0.0-SNAPSHOT.zip" semble être à l'origine du problème

More precisely, the SU "su-SOAP-AD009-GetAssetEquipmentService-provide-1.0.0-SNAPSHOT.zip" (.original) is the one that causes this problem.

This SU has a WSDL with a lot of XSD imports and a **complex** directory structure. The WSDL is valid, but Petals can't handle it, since I can't retrieve the WSDL when I expose this SU to the outter world. So I think this is more of a PetalsESB / EasyWSDL problem than anything else. But is it possible to display a line corresponding to the faulty endpoint, with the error message we get when we call the getDescriptionMethod() ? (eg something like this : <error><description>Unable to get WSDL for this service</description><reason>WSDL description can not been retrieved from JBI endpoint</reason></error>)

NB :

• sa-SOAP-AD009-GetAssetEquipmentService-provide-1.0.0-SNAPSHOT.zip.original is the original SA containing the original problematic SU.
• sa-SOAP-AD009-GetAssetEquipmentService-provide-1.0.0-SNAPSHOT.zip.modded is a modded SA, with all the imports at the same level.
• sa-SOAP-AD009-consume-1.0.0-SNAPSHOT.zip is the consumer SU

EasyWSDL reads properly wsdl contained in su-SOAP-AD009-GetAssetEquipmentService-provide-1.0.0-SNAPSHOT.zip
I would say that the problem lies elsewhere between the jmx client and the mxbean...

To reproduce the bug easily :

• launch petals
• deploy bc-soap
• deploy sa-AD009-RecupVersionPointInterventionSigma-1.0.0-SNAPSHOT.zip
• open jconsole
• invoke EndpointRegistry.getDescription with service name and endpoint name corresponding to sa-AD009-RecupVersionPointInterventionSigma-1.0.0-SNAPSHOT.zip (taken from petals console)

all other attachments are useless

=> StackOverflow

Registry log confirm that the WSDL inserted in database is correct.
However it, once all imports resolved, it is huge (8MB).

Serialization occuring between MBean and jmx client causes a stack overflow because of this complexity, and mostly because a dom Document is used for serialization (which is a highly deep and nested structure).

A solution could probably be to serialize WSDL as a String, and parse it back on client side.

Fixed by letting getDescription return a raw String instead of a DOM document.
(See attached kernel patch).