Buscador no busca documentos con tilde

[Sergio Romero Zayas, modificado hace 10 años.]

Pues vuelta a la carga...

Después de solucionar el problema con los contenidos con tilde, y su búsqueda sin tilde, haciendo uso de un Analyzer especifico creado en un ext-->Añadir analyzer español para Liferay 6.1.x - Como hacerlo fácil

Me he percatado, que el problema persiste en parte. Cuando lo que buscamos es un documento de "Documentos y Multimedia" (pdf, doc, etc) no me esta usando mi spanishAnalizyer ¿porque? Pues supongo que Liferay tratará los documentos de diferente forma, al Indexar, supongo que indexa bien porque el problema que tenía con los contenidos ya no lo tengo, pero con los documentos es como si no hubiera hecho nada.

Así que vuelvo a estar perdido, por ello pido algo de ayuda forera... Necesito saber si se habéis enfrentado a este problema, o si existe algún analizador o se os ocurre alguna propuesta. gracias de antemano.

[Iñaki Sainz, modificado hace 10 años.]

Hola Sergio,

creo que el problema puede venir por la declaración que has hecho del Analyzer. Según lo que indicas, sólo lo aplicas a los campos *_es_ES.

<entry key=".*_es_ES" value-ref="com.spanish.analyzer.SpanishAnalyzer" />

Pero si te fijas, en el indexador de documentos DLIndexer.java verás que el nombre del campo que utiliza para indexar no concatena el idioma, por que obviamente lo desconoce, por lo que tu nuevo analizador no se aplica. La key del campo de indexación es simplemente content.

document.addFile(Field.CONTENT, is, dlFileEntry.getTitle());

Es decir, que según tu declaración, no le estás aplicando el nuevo analizador que has desarrollado al campo content. Si es así, el problema te ocurriría igual en otros tipos de contenidos no dependientes del idioma, como los blogs o la wiki.

[Sergio Romero Zayas, modificado hace 10 años.]

Gracias por la respuesta Iñaki, esto mismo es lo que comentaba en mi comentario anterior, que me daba la sensación de o que no se indexaba o que para los documentos obvia el analyzer que cree. Efectivamente es así. Pero entonces la pregunta vuelve a ser la misma... ¿qué solución se le puede dar? Por donde sigo?

He probado forzar a que el Analyzer sea siempre SpanishAnalyzer, pero parece que le da igual. Por otro lado, he intentado que el key sea key=".*" y tampoco me ha servido para nada.

Creo que los documentos no pasan por Analyzer alguno, sino no tiene sentido, que funcione en contenidos y no en documentos. Y la pregunta sigue siendo, sino se usa para documentos el analyzer, que se usa para realizar la búsqueda? como actúa Liferay en este tipo de búsquedas?

EDITO

Tras ver las clases DLIndexer y JournalIndexer, observo perfectamente esa apreciación que citas, pero entonces la solución que sería ¿hacer un ext de DLIndexer para obligarle a usar idioma?

[Iñaki Sainz, modificado hace 10 años.]

Sergio,

has probado simplemente a poner la key de content y reindexar ?

<entry key="content" value-ref="com.spanish.analyzer.SpanishAnalyzer" />

Si obvias el tema de los documentos, te debería pasar también con la wiki. Haz la prueba y dime si ocurre igual.

[Sergio Romero Zayas, modificado hace 10 años.]

Iñaki Sainz:

Sergio,

has probado simplemente a poner la key de content y reindexar ?

<entry key="content" value-ref="com.spanish.analyzer.SpanishAnalyzer" />

Si obvias el tema de los documentos, te debería pasar también con la wiki. Haz la prueba y dime si ocurre igual.

Si he probado y no funciona.

Si modifico la clase DLIndexer me funciona... pero me parece poco elegante, además de que pienso que si pasa con esto, puede pasar con otros ClasesIndexer... WikiIndexer, BlogIndexer...

Aún así me sigue resultado tremendamente llamativo, el hecho de que tenga que llegar a tan bajo nivel para solventar una cosa tan simple como buscar una palabra sin tilde y que me aparezcan en los resultados aquellas que son iguales, pero con tilde,... en fin... a pulir el workaround

[Daniel Sanz, modificado hace 10 años.]

Como dice Iñaki, son 2 las cosas de las que hay que estar seguro
1. Que el PerFieldAnalyzerWrapper devuelva el SpanishAnalyzer para todos aquellos campos que se deseen usar para buscar en Español
2. Reindexar antes de buscar nada.

Esto es muy sencillo de averiguar:
* Inicia sesión de depuración
* Pon un punto de ruptura nada mas entrar en LuceneHelperImpl.addTerm()
* Realiza una búsqueda en la DL y observa qué campos se crean y qué analizadores se usan ¿Se utiliza el analizador necesario en cada uno de ellos? De no ser así es necesario modificar la configuración

Recuerda que no todos los campos de un documento lucene están localizados. El portal tiene una lógica de indexación específica para cada tipo de entidad. Si quieres ver como funciona, puedes depurar el método DLIndexer.doGetDocument(). Los elementos no localizables se indexan con un único campo, así que ten en cuenta que el analyzer que uses para ese campo condicionará la forma de buscar cosas en él para todos los idiomas.

[Sergio Romero Zayas, modificado hace 10 años.]

Daniel Sanz:

....

Ya hice todo lo que comentas Daniel, la solución es modificar DLIndexer cosa que no veo elegante, pero llevo ya 2 días con esto más los que perdí la semana pasada con la extensión del analyzer, (bueno hasta que llegue a su solución), ya que hacer la extensión en sí no me llevo más de 15 o 20 minutos.

[Daniel Sanz, modificado hace 10 años.]

Quizá podríamos ayudarte mejor si nos indicas todas las pruebas y configuraciones que has hecho.

Ayudaría mucho saber el requisito concreto (v.g que encuentre en el contenido del documento), los datos de que dispones (v.g. "el contenido se está indexando porque lo visualizo con luke") y los resultados que obtienes (v.g. "el portal genera esta query pero debería generar esta otra")

Sin esa información solo podemos orientarte de forma general.

[Sergio Romero Zayas, modificado hace 10 años.]

Agradezco el apoyo Daniel, pero aún sin haber detallado la línea de log ni las 20.000 pruebas realizadas el problema es muy muy simple. La casuística es bien sencilla.

Subo a la Document Library un fichero y le pongo en Título "camión" y en la descripción "camión".
Después me voy re-indexo.
Me voy al front, busco "camion" y no aparecen resultados. Busco "camión" y sí aparecen.

La casuística es simple. Ya lo arreglé para contenidos añadiendo un analyzer propio que añadiera un ASCIIFoldingFilter al tokenStream y re-definiendo en un ext el search-spring.xml.

El problema que detecté con este workaround que tuve que realizar previamente, es que los documentos no usaban o no pasaban por este analyzer que yo mismo añadí. Tras varias pruebas y gracias a la pista que dejó Iñaki (gracias) me di cuenta tras comparar JournalIndexer con DLIndexer que el problema se fundaba en que DLIndexer no usa el idioma, por lo que NO usará jamás el Analyzer que yo cree.

Lo más fácil y lo que se piensa primero es añadir un entry nuevo al search-spring.xml con la key "content" y asociarlo al analyzer propio, pero tampoco funcionó. Solo conseguí que me funcionará añadiendo el idioma en la clase DLIndexer, teniendo de nuevo que extender una clase de Liferay.

Con toda esta experiencia "religiosa" me quedo en que Liferay 6.1.x da más potencia si, mucha más con la gestión particularizada definida en search-spring.xml, pero creo que se habría beneficiado también una subida de versión de Lucene, en la que se incluyen idiomas como el Castellano, y viniendo "out-of-the-box" este tipo de cuestiones implementadas.

Me parece cuanto menos llamativo que en 2013 se tengan que estar acometiendo las mismas pericias en cuestión de idioma que hacia en 2006-2007 con el viejo OpenCMS, o en 2008 con Liferay 5.x.

[Sergio Romero Zayas, modificado hace 10 años.]

Otro tortazo...

Ayer probé (si lo reconozco) recompilando portal-impl mi solución y funcionó. Hoy estoy tratando de hacerlo bonito con un plugin EXT para extender el DLIndexer a mi MyIndexer, extendiendo de este y sobreescribiendo tan solo lo que necesito. Creo que dentro de lo que cabe es una solución más que elegante, dadas las circunstancias no hay otra salida, y esta se puede considerar incluso como buena praxis.

El caso es que me he topado con la siguiente incidencia :

LPS-35565

En el fichero liferay-portlet-ext.xml he colocado solo el portlet de documentos de liferay, id = 20, porque es donde se define el DLIndexer, donde sustituyo DLIndexer por MyIndexer. Pues bien al desplegar obtengo el erro de la incidencia sin resolver LPS-35565.

El contenido de mi liferay-portlet-ext.xml es:

<liferay-portlet-app>
	<portlet>
		<portlet-name>20</portlet-name>
		<icon>/html/icons/document_library.png</icon>
		<struts-path>document_library</struts-path>
		<configuration-action-class>com.liferay.portlet.documentlibrary.action.ConfigurationActionImpl</configuration-action-class>
		<indexer-class>com.spanish.indexing.MyDLIndexer</indexer-class>
		<open-search-class>com.liferay.portlet.documentlibrary.util.DLOpenSearchImpl</open-search-class>
		<portlet-url-class>com.liferay.portal.struts.StrutsActionPortletURL</portlet-url-class>
		<portlet-data-handler-class>com.liferay.portlet.documentlibrary.lar.DLPortletDataHandlerImpl</portlet-data-handler-class>
		<social-activity-interpreter-class>com.liferay.portlet.documentlibrary.social.DLActivityInterpreter</social-activity-interpreter-class>
		<webdav-storage-token>document_library</webdav-storage-token>
		<webdav-storage-class>com.liferay.portlet.documentlibrary.webdav.DLWebDAVStorageImpl</webdav-storage-class>
		<control-panel-entry-category>content</control-panel-entry-category>
		<control-panel-entry-weight>12.0</control-panel-entry-weight>
		<asset-renderer-factory>com.liferay.portlet.documentlibrary.asset.DLFileEntryAssetRendererFactory</asset-renderer-factory>
		<atom-collection-adapter>com.liferay.portlet.documentlibrary.atom.FileEntryAtomCollectionAdapter</atom-collection-adapter>
		<atom-collection-adapter>com.liferay.portlet.documentlibrary.atom.FolderAtomCollectionAdapter</atom-collection-adapter>
		<custom-attributes-display>com.liferay.portlet.documentlibrary.DLFileEntryCustomAttributesDisplay</custom-attributes-display>
		<custom-attributes-display>com.liferay.portlet.documentlibrary.DLFolderCustomAttributesDisplay</custom-attributes-display>
		<workflow-handler>com.liferay.portlet.documentlibrary.workflow.DLFileEntryWorkflowHandler</workflow-handler>
		<preferences-owned-by-group>true</preferences-owned-by-group>
		<use-default-template>false</use-default-template>
		<scopeable>true</scopeable>
		<private-request-attributes>false</private-request-attributes>
		<private-session-attributes>false</private-session-attributes>
		<render-weight>50</render-weight>
		<header-portlet-css>/html/portlet/document_library/css/main.css</header-portlet-css>
		<header-portlet-css>/html/portlet/dynamic_data_mapping/css/main.css</header-portlet-css>
		<footer-portal-javascript>/html/js/liferay/service.js</footer-portal-javascript>
		<footer-portlet-javascript>/html/portlet/dynamic_data_lists/js/main.js</footer-portlet-javascript>
		<footer-portlet-javascript>/html/portlet/dynamic_data_mapping/js/main.js</footer-portlet-javascript>
		<footer-portlet-javascript>/html/portlet/document_library/js/main.js</footer-portlet-javascript>
		<css-class-wrapper>portlet-document-library</css-class-wrapper>
		<add-default-resource>true</add-default-resource>
	</portlet>
</liferay-portlet-app>

El error de LOG:

09:48:53,680 ERROR [pool-2-thread-1][MainServlet:259] com.liferay.portal.kernel.atom.AtomException: Duplicate collection name files
com.liferay.portal.kernel.atom.AtomException: Duplicate collection name files
        at com.liferay.portal.atom.AtomCollectionAdapterRegistryImpl.register(AtomCollectionAdapterRegistryImpl.java:48)
        at com.liferay.portal.kernel.atom.AtomCollectionAdapterRegistryUtil.register(AtomCollectionAdapterRegistryUtil.java:49)
        at com.liferay.portlet.PortletBagFactory.newAtomCollectionAdapterInstances(PortletBagFactory.java:611)
        at com.liferay.portlet.PortletBagFactory.create(PortletBagFactory.java:205)
        at com.liferay.portal.servlet.MainServlet.initPortlets(MainServlet.java:920)
        at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:256)
        at javax.servlet.GenericServlet.init(GenericServlet.java:160)
        at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1266)
        at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1185)
        at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1080)
        at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5015)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5302)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:895)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:871)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
        at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:649)
        at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1585)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)

Normal que tenga pesadillas por la noche, todas empiezan por #LPS- jejejjeje. Dejando el humor de lado, agradecer a todos los que hacéis que de gusto trabajar con Liferay.

Supongo que a más de uno le habrá pasado esto, algún workaround para salir del paso sin tener que recompilar portal-impl??

[Jose Jiménez, modificado hace 10 años.]

Buenos días Sergio,

Aporto mi granito de arena, lo más directo en este caso sería comparar JournalArticleIndexer con DLIndexer y entender por qué en uno funciona el SpanishAnalyzer y en otro no, lo más directo es ver cómo los indexer crean el documento de lucene, y como puedes observar (adjunto links a implementación actual, para más detalles consulta la rama correspondiente a tu versión) para los contenido web si se almacena en lucene un campo por cada idioma mientras que para documentos no:

JournalArticleIndexer

DLFileEntryIndexer (lo que venía siendo el DLFileIndexer)

Así sumándome a soluciones anteriores que se proponian en este hilo, bastaría con añadir la regla adecuada para que el analyzer aplique al campo deseado, por tanto si buscas por título de fichero en DLFileIndexer se observa que dicho campo se almacena como document.addText(Field.TITLE, dlFileEntry.getTitle()) , es decir, la entry a añadir sería "title" (a verificar en tu versión actual)

Como complemento a este hilo y respecto a tus apreciaciones acerca de la evolución del producto, tu propuesta como mejora/nueva funcionalidad será bienvenida, puedes crearla en https://www.liferay.com/community/ideas y con un poco de suerte podrías disfrutar de ella en nuevas versiones, este es el lado positivo de los LPS-feature-request

Añadir que este tipo de mejoras pueden ser incluso contribuidas por lo que si te peleas mucho por algo que estaría muy bien que Liferay lo trajera y mantuviera de serie podrías aportarlo directamente. You are welcome!

Espero que esto ayude un poco y además encuentres interesante el canal de ideas si lo desconocías, esta mañana mismo han resuelto una de mis propuestas también relativa con multi-idioma LPS-33385

Un saludo,
Jose

[Sergio Romero Zayas, modificado hace 10 años.]

Gracias Jose,

Sinceramente agradezco tu respuesta, agradezco que intentes aportar tu grano de arena, pero es que estas diciendo exactamente lo mismo que yo ya he hecho y/o descrito.

En mi anterior mensaje, he intentado aplicar este workaround, y puedes observar el error al intentar desplegar el EXT que he tenido, por el bug que Liferay tiene cuando intentas sobrescribir un portlet.

La solución ya la tengo, si modifico la clase DLIndexer en el core, y recompilo el portal-impl funciona. Pero como he comentado antes, esto no es "elegante", ni sigue uno las reglas de buenas prácticas, lo ideal es extender esta clase, sobrescribir únicamente el método que he tocado y aplicarlo al ROOT mediante un plugin EXT. Pero tengo el problema del bug LPS-35565.

Mi versión de Liferay es la 6.1.1GA2 Community.

De nuevo gracias Jose por aportar tu grano de arena, si se te ocurre alguna idea de como sortear este problema del EXT de alguna manera, soy todo oídos ;)

[Jose Jiménez, modificado hace 10 años.]

Hola de nuevo,

Supongo que tus pruebas fueron realizadas tras reindexar con dicha configuración, en tal caso antes que hacer un ext intentaría encontrar la causa raíz.

No obstante dado que ya tienes una solución codificada y necesitas un workaround hasta que el bug sea solucionado, yo no usaria el ext para sobrescribir definiciones en liferay-portlet.xml, y directamente haría la modificación en el fichero original: ROOT/WEB-INF/liferay-portlet.xml

Como te digo es un workaround y no una solución, por lo que espero que te valga.

Un saludo
Jose

[Sergio Romero Zayas, modificado hace 10 años.]

Efectivamente Jose, lo que tengo es un workaround, sobre todo por el problema que tengo con ese bug.

Lo ideal sería que DLIndexer ya tratará también los idiomas, esto si podría considerarse solución, ¿no?

Si se le aplicará la lógica correcta, ¿podría aportarse como mejora?

[Jose Jiménez, modificado hace 10 años.]

Claro!
El camino adecuado sería crear la Feature Request a través del Canal de Ideas y luego contribuir la solución de la misma a través de git, por una lado Product Management evaluaría la funcionalidad y por otro los ingenieros de desarrollo la implementación. Te animo a ello
Saludos!