Binari Tridion CWA 2011 Restituisce 404 Fino all'aggiornamento

Question

Il mio client ha un problema dopo l'aggiornamento da CWA 1.5 a CWA 2011 in esecuzione su WebSphere. Il problema è che qualsiasi risorsa binaria richiesta restituisce un 404. Quando la richiesta viene nuovamente inviata (ad esempio, la pagina viene aggiornata/ricaricata), viene caricata.

Non ho accesso al loro ambiente e devo ottenere tutti i file di configurazione tramite terze parti. Mi stavo chiedendo se qualcuno ha qualche idea fuori di testa su cosa potrebbe causare questi 404 su binari?

Answer 1

Per WebSphere 7, il servlet predefinito è conosciuta come la FileServlet, e quindi la seguente dovrebbe funzionare:

<servlet> 
<servlet-name>FileServlet</servlet-name> 
<servlet-class> 
com.ibm.ws.webcontainer.servlet.SimpleFileServlet 
</servlet-class> 
</servlet> 


<servlet-mapping> 
    <servlet-name>FileServlet</servlet-name> 
    <url-pattern>*.css</url-pattern> 
</servlet-mapping> 
<servlet-mapping> 
    <servlet-name>FileServlet</servlet-name> 
    <url-pattern>*.jpg</url-pattern> 
</servlet-mapping> 
<servlet-mapping> 
    <servlet-name>FileServlet</servlet-name> 
    <url-pattern>*.js</url-pattern> 
</servlet-mapping> 
<servlet-mapping> 
    <servlet-name>FileServlet</servlet-name> 
    <url-pattern>*.gif</url-pattern> 
</servlet-mapping> 

Answer 2

È passato molto tempo da quando ho utilizzato CWA, ma IIRC serializza i file binari su disco su richiesta e li memorizza nella cache per richieste future. Sembra che il processo richieda troppo tempo, quindi ottieni una 404 come prima richiesta per un binario. Ne ho già sentito parlare su WebSphere, sei sicuro che non stia accadendo anche con il vecchio CWA?

Se il problema persiste, suggerisco di contattare l'assistenza clienti SDL.

Answer 3

A partire da Websphere 6.1, IBM ha modificato il comportamento dei filtri e questi non verranno eseguiti se l'URL che stai chiamando non esiste realmente sul server.

Ciò significa che una richiesta per /somefile.png che si trova ancora nel DB risulterà in un 404 (tecnicamente corretto) ma non completamente ciò che si aspetta con un'applicazione Web abilitata CWA.

La soluzione è quella di rendere il filtro invocare su una richiesta senza una mappatura servlet e si dovrebbe essere in grado di effettuare le seguenti operazioni in WebSphere Admin Console:

1. Fare clic su Server -> Tipi di server -> Websphere Application Server -> -> impostazioni Web Container -> Contenitore Web
2. Sotto ulteriori impostazioni cliccare su proprietà personalizzate
3. Nella pagina delle proprietà personalizzate, fare clic su Nuovo e quindi immettere "com.ibm.ws.webcontainer.invokefilterscompatibility", come il nome della proprietà e "true" come valore
4. Salvare l'aggiornamento e riavviare il server

Answer 4

Nel file di cd_cwa_conf.xml, è anche possibile aggiungere il seguente parametro:

<configuration> 
... 
    <!-- Number of seconds to wait for the default Servlet to pick up changes on the file-system --> 
    <file-synchronization delay="..." /> 
... 
</configuration> 

Come ha detto Chris, la prima volta che viene richiesto un binario quindi il file viene serializzato e memorizzato nella cache sul disco. Se il processo è troppo lungo, il server dell'app restituirà un 404.

Con questo parametro, il sistema attende alcuni secondi (ovvero il valore specificato) prima di accedere al file.

Abbiamo avuto lo stesso problema con un server Tomcat e questo ha corretto il pb.

Answer 5

Penso che ci sia un po 'di confusione su quale sia esattamente la domanda. Quindi Nick sta spiegando che una prima richiesta su un binario risulta in un 404. Qualsiasi richiesta successiva serve il binario come previsto. Pertanto, la risposta che Elena ha dato non è davvero la soluzione a questo problema, anche se lei ha ragione dicendo che quell'impostazione particolare ha il che deve essere fatto in WebSphere.

La risposta per il rilascio 'ottenere un 404 alla prima richiesta solo' sta avendo una mappatura esplicita nel file web.xml su ogni modello di URL tipo binario per il servlet predefinito.Questo è descritto in http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_CWA_10/task_C1FECE85AD5E4F0BB3957C4516D7E2AC, proiettile # 6:

<servlet-mapping> 
    <servlet-name>default</servlet-name> 
    <url-pattern>*.jpg</url-pattern> 
</servlet-mapping> 

documentazione afferma questo risolve JBoss, Tomcat, ma ho anche visto corregge WebLogic. Spero che aggiusti anche WebSphere. Fatecelo sapere.

Answer 6

Fare attenzione se si utilizza Tomcat 7 (e probabilmente ultime versioni di Tomcat 6). Esiste una limitazione nel modo in cui i file web.xml vengono uniti.

Non so esattamente perché, ma NON è possibile definire più mapping al servlet predefinito. È possibile avere una sola voce di mappatura per questo servlet.

Forse in relazione con questo: https://issues.apache.org/bugzilla/show_bug.cgi?id=50026

Tra l'altro, è possibile ignorare questo limite ridefinendo anche la mappatura predefinita.

Es: quanto segue non funziona con Tomcat 7.0.33. Tutte le risorse sono nell'errore 404.

<servlet-mapping> 
    <servlet-name>default</servlet-name> 
    <url-pattern>/worldwide/binaries/*</url-pattern> 
</servlet-mapping> 
<servlet-mapping> 
    <servlet-name>default</servlet-name> 
    <url-pattern>/france/binaries/*</url-pattern> 
</servlet-mapping> 

Le seguenti opere perfettamente

<servlet-mapping> 
    <servlet-name>default</servlet-name> 
    <url-pattern>/worldwide/binaries/*</url-pattern> 
    <url-pattern>/france/binaries/*</url-pattern> 
    <url-pattern>/</url-pattern> 
</servlet-mapping> 

speranza che aiuta.