Petals ESB Container

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

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.

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

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...

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

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

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.

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.

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

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