Contenitore portlet come pluto o jetspeed sul motore di app di google?

Question

Sto provando a creare qualcosa "server portlet" -ish sul motore dell'app google. (come open source)

mi piacerebbe utilizzare gli standard JSR168/286, ma penso che le restrizioni della motore app renderà in qualche luogo fra difficile e impossibile.

Qualcuno ha provato a eseguire jetspeed o un'applicazione che utilizza internamente il pluto nel motore dell'app google?

Sulla base della mia attuale conoscenza della portlet e il motore di applicazione Google Sono anticipando questi problemi:

un file WAR con portlet è dal punto di vista distribuzione più o meno una completa webapp (sì, lo so che in realtà non funziona senza un server del portale ). Il file war può contenere il proprio web.xml, ecc. Questo rende piuttosto difficile la distribuzione sul motore dell'app, perché le app sono non visibili l'una all'altra, quindi tutti gli archivi contenenti portlet devono essere inclusi nel file di guerra del distribuito "portal server basato su motore di app".

I "portlet" sono (almeno in Liferay) ha iniziato servlet come permanente processi, in base alle loro portlet.xmls e web.xmls che si trova nello stesso posto per ogni archivio portlet che viene caricato. Penso che questo potrebbe essere problematico nel motore di app , perché tutto è in una grande "web app", quindi potrebbe essere complicato a accedere a portlet.xmls da ciascun archivio.

Ciò impedisce una compatibilità del 100% a mio parere.

C'è qualcuno che ha esperienza con la combinazione di portlet e il motore di app ?

Pensi che sia possibile modificare jetspeed, pluto o qualsiasi altro contenitore di portlet per essere in grado di eseguire sul motore dell'app?

Answer 1

L'ho esaminato brevemente: il problema più grande è che le specifiche del portlet si basano ma superano alcuni bit chiave delle specifiche del servlet, in particolare richiedono in genere il supporto per le chiamate cross-context.

Mentre è possibile progettare una singola web-app che contiene più portlet e il contenitore servlet (spesso fatto per i portlet di amministrazione, o nel caso di Liferay molto del loro stack) non è facile.

In realtà, se si cerca di fare cose di tipo portale su AppEngine, guarderei molto più da vicino l'hosting di widget OpenSocial (se proprio si vogliono standard), magari in esecuzione in Shindig o ospitato esternamente. Ciò può anche ottenere la compatibilità con JSR-168, in quanto vi sono numerosi (non eccezionali) portlet di bridge per ospitare i widget e non è un adattatore duro da scrivere.