Abbiamo un dipendente il cui cognome è Null. La nostra applicazione di ricerca dei dipendenti viene interrotta quando quel cognome viene utilizzato come termine di ricerca (che sembra essere abbastanza spesso ora). L'errore ricevuto (grazie Fiddler!) È:

<soapenv:Fault>
   <faultcode>soapenv:Server.userException</faultcode>
   <faultstring>coldfusion.xml.rpc.CFCInvocationException: [coldfusion.runtime.MissingArgumentException : The SEARCHSTRING parameter to the getFacultyNames function is required but was not passed in.]</faultstring>

Carino, eh?

Il tipo di parametro è string.

Sto usando:

• WSDL ( SOAP )
• Flex 3.5
• ActionScript 3
• ColdFusion 8

Si noti che l'errore non si verifica quando si chiama webservice come oggetto da una pagina ColdFusion.

Rintracciarlo

All'inizio ho pensato che si trattasse di un errore di coercizione in cui nullveniva costretto a superare "null"un test "null" == null. Non è. Ero vicino, ma molto, molto sbagliato. Mi dispiace per quello!

Da allora ho lavorato molto su wonderfl.net e ho rintracciato il codice mx.rpc.xml.*. Alla riga 1795 di XMLEncoder(nella fonte 3.5), in setValue, tutta la codifica XMLE si riduce a

currentChild.appendChild(xmlSpecialCharsFilter(Object(value)));

che è essenzialmente lo stesso di:

currentChild.appendChild("null");

Questo codice, secondo il mio violino originale, restituisce un elemento XML vuoto. Ma perché?

Causa

Secondo il commentatore Justin Mclean sulla segnalazione di bug FLEX-33664 , il colpevole è il seguente (vedi gli ultimi due test nel mio violino che lo verificano):

var thisIsNotNull:XML = <root>null</root>;
if(thisIsNotNull == null){
    // always branches here, as (thisIsNotNull == null) strangely returns true
    // despite the fact that thisIsNotNull is a valid instance of type XML
}

Quando currentChild.appendChildviene passata la stringa "null", la converte prima in un elemento XML radice con testo null, quindi verifica tale elemento rispetto al valore letterale null. Questo è un test di uguaglianza debole, quindi o l'XML contenente null viene forzato sul tipo null, oppure il tipo null viene forzato su un elemento xml radice contenente la stringa "null" e il test passa dove probabilmente dovrebbe fallire. Una soluzione potrebbe essere quella di utilizzare sempre rigorosi test di uguaglianza quando si controlla XML (o qualcosa del genere) per "nullità".

Soluzione

I valori CDATA sono il modo più appropriato per mutare un intero valore di testo che altrimenti causerebbe problemi di codifica / decodifica. La codifica esadecimale, ad esempio, è pensata per singoli personaggi. I valori CDATA sono preferiti quando stai sfuggendo all'intero testo di un elemento. La ragione principale di ciò è che mantiene la leggibilità umana.

Nella nota xkcd , il sito Web Bobby Tables offre buoni consigli per evitare l'interpretazione impropria dei dati dell'utente (in questo caso, la stringa "Null") nelle query SQL in varie lingue, incluso ColdFusion .

Non è chiaro dalla domanda che questa è la fonte del problema, e data la soluzione annotata in un commento alla prima risposta (incorporando i parametri in una struttura) sembra probabile che fosse qualcos'altro.

Il problema potrebbe essere nell'encoder SOAP di Flex. Prova ad estendere il codificatore SOAP nell'applicazione Flex e esegui il debug del programma per vedere come viene gestito il valore null.

La mia ipotesi è che è passato come NaN (Not a Number). Questo a volte farà confondere il processo di smascheramento del messaggio SOAP (in particolare nel server JBoss 5 ...). Ricordo di aver esteso il codificatore SOAP e di aver eseguito un controllo esplicito su come viene gestito NaN.

@ doc_180 aveva il concetto giusto, tranne per il fatto che era focalizzato sui numeri, mentre il poster originale aveva problemi con le stringhe.

La soluzione è cambiare il mx.rpc.xml.XMLEncoderfile. Questa è la linea 121:

    if (content != null)
        result += content;

(Ho esaminato l'SDK di Flex 4.5.1; i numeri di riga potrebbero differire in altre versioni.)

Fondamentalmente, la validazione fallisce perché 'content is null' e quindi il tuo argomento non viene aggiunto al pacchetto SOAP in uscita; causando così l'errore del parametro mancante.

Devi estendere questa classe per rimuovere la validazione. Quindi c'è una grande palla di neve lungo la catena, modificando SOAPEncoder per usare il tuo XMLEncoder modificato, quindi modificando Operazione per usare il tuo SOAPEncoder modificato, e quindi moidfing WebService per usare la tua classe operativa alternativa.

Ci ho passato alcune ore, ma devo andare avanti. Probabilmente ci vorranno un giorno o due.

Potresti essere in grado di correggere la linea XMLEncoder ed eseguire alcune patch scimmia per utilizzare la tua classe.

Aggiungerò anche che se si passa all'uso di RemoteObject / AMF con ColdFusion, il null viene passato senza problemi.

16/11/2013 aggiornamento :

Ho un'aggiunta più recente al mio ultimo commento su RemoteObject / AMF. Se si utilizza ColdFusion 10; quindi le proprietà con un valore null su un oggetto vengono rimosse dall'oggetto lato server. Quindi, devi controllare l'esistenza delle proprietà prima di accedervi o otterrai un errore di runtime.

Controlla in questo modo:

<cfif (structKeyExists(arguments.myObject,'propertyName')>
 <!--- no property code --->
<cfelse>
 <!--- handle property  normally --->
</cfif>

Questo è un cambiamento nel comportamento rispetto a ColdFusion 9; dove le proprietà null si trasformerebbero in stringhe vuote.

Modifica il 06/12/2013

Dato che c'era una domanda su come vengono trattati i null, ecco una rapida applicazione di esempio per dimostrare come una stringa "null" si collegherà alla parola riservata null.

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
               xmlns:s="library://ns.adobe.com/flex/spark"
               xmlns:mx="library://ns.adobe.com/flex/mx" minWidth="955" minHeight="600" initialize="application1_initializeHandler(event)">
    <fx:Script>
        <![CDATA[
            import mx.events.FlexEvent;

            protected function application1_initializeHandler(event:FlexEvent):void
            {
                var s :String = "null";
                if(s != null){
                    trace('null string is not equal to null reserved word using the != condition');
                } else {
                    trace('null string is equal to null reserved word using the != condition');
                }

                if(s == null){
                    trace('null string is equal to null reserved word using the == condition');
                } else {
                    trace('null string is not equal to null reserved word using the == condition');
                }

                if(s === null){
                    trace('null string is equal to null reserved word using the === condition');
                } else {
                    trace('null string is not equal to null reserved word using the === condition');
                }
            }
        ]]>
    </fx:Script>
    <fx:Declarations>
        <!-- Place non-visual elements (e.g., services, value objects) here -->
    </fx:Declarations>
</s:Application>

L'output della traccia è:

la stringa null non è uguale alla parola riservata null usando la condizione! =

la stringa null non è uguale alla parola riservata null utilizzando la condizione ==

la stringa null non è uguale alla parola riservata null utilizzando la condizione ===

Traduci tutti i caratteri nei loro equivalenti esadecimali. In questo caso, Nullverrebbe convertito in&#4E;K&#6C;&#6C;

La stringa di un nullvalore in ActionScript darà la stringa "NULL". Il mio sospetto è che qualcuno ha deciso che è, quindi, una buona idea per decodificare la stringa "NULL"come null, causando la rottura che vedete qui - probabilmente perché dato che anche in nulloggetti e ottenere le stringhe nel database, quando non volevano quello (quindi assicurati di controllare anche quel tipo di bug).

Come hack, potresti considerare di avere una gestione speciale sul lato client, convertendo la stringa 'Null' in qualcosa che non si verificherà mai, ad esempio XXNULLXX e riconvertendo il server.

Non è carino, ma può risolvere il problema per un caso del genere.

Bene, immagino che l'implementazione di Flex dell'encoder SOAP sembra serializzare i valori null in modo errato. Serializzarli come String Null non sembra essere una buona soluzione. La versione formalmente corretta sembra passare un valore null come:

<childtag2 xsi:nil="true" />

Quindi il valore di "Null" non sarebbe altro che una stringa valida, che è esattamente quello che stai cercando.

Immagino che risolvere questo problema in Apache Flex non dovrebbe essere così difficile. Consiglierei di aprire un problema con Jira o di contattare i ragazzi della mailing list di apache-flex. Tuttavia, ciò risolverebbe solo il lato client. Non posso dire se ColdFusion sarà in grado di lavorare con valori null codificati in questo modo.

Vedi anche il post sul blog di Radu Cotescu Come inviare valori Null nelle richieste soapUI .

È un kludge, ma supponendo che ci sia una lunghezza minima per SEARCHSTRING, ad esempio 2 caratteri, substringil SEARCHSTRINGparametro al secondo carattere e passarlo invece come due parametri: SEARCHSTRING1 ("Nu")eSEARCHSTRING2 ("ll"). Concatenate li ricongiungono insieme quando si esegue la query nel database.