Cocoon 2.2/3.0 and Spring WebMVC
Cocoon Community, While, possibly unconventional, we are considering the the possibility of marrying Cocoon and WebMVC in our project to use Cocoon as a View technology while relying on WebMVC as our Controller/Model framework. I would like to explore if anyone else out there has approached such a solution? Cheers, Mark - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Cocoon 2.2/3.0 and Spring WebMVC
Igor and Thorsten, On Mon, Jul 18, 2011 at 2:48 PM, Igor Malinin igor...@gmail.com wrote: It not so unconventional. I am thinking about it since long ago, and decided to finally do it recently. Not so much progress at this time, but I was able to make some basic things running. Handling requests by Spring @Controllers and then running pipeline with default Spring ViewResolver. This works, but not with Cocoon Reloading ClassLoader - I have EntityManagerFactory configured in applicationContext.xml and Reloading ClassLoader recreates it on every request and subsequently closes the old instance which is used by Spring DispatcherServlet. I configured JRebel, and it serves reloading well in the less destructive way to spring context. Sounds like the reloading classloader is actually running in the background though? TBH, we've not been able to utilize the rcl at all with our work due to problems we've had with with cocoon-servlet-service, thus we approach a the classical cocoon approach with 2.2 without use of blocks atm (hopefully we can correct this when we adopt 3.0). I'm very interested in seeing how this works, we may actually want to be more aggressive about reloading the entire spring context for the webapp as well as cocoon itself, we also are looking for a means to reload the spring context on changes to the configuration properties (currently stored in a properties file but possibly in a database in the near future) I was planning to get back to the Cocoon community when some code is ready to show to the public, so you are not alone trying to marry Cocoon and Spring MVC and hopefully soon I will be back with something useful (and I would like to also marry it with JPA and JAXB (with EclipseLink) and also Spring forms/validation to make the full stack). PS. I am trying it with C3 and S3. Yes, all these are of interest. we are looking into legacy and JPA integration via Spring and then just using Cocoon to render the resulting state to the browser. Basically, we would be replacing the Cocoon Actions and Flow we currently are using with Spring WebMVC. Mark p.s. I will also look at Wicket. Thanks for the advice. On 2011-07-18 19:10, Mark Diggory wrote: Cocoon Community, While, possibly unconventional, we are considering the the possibility of marrying Cocoon and WebMVC in our project to use Cocoon as a View technology while relying on WebMVC as our Controller/Model framework. I would like to explore if anyone else out there has approached such a solution? Cheers, Mark - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: switch Cocoon 2.2 spring dependencies from 2.5.1 to 2.5.6
Charles, Charles Yates ceyates at stanford.edu writes: Yes, we use spring-3.0.4 and cocoon-2.2 but in a non-standard way. We use our own bean definitions for cocoon components rather than the ones built into the cocoon jars, and have subclassed a number of cocoon classes. The methodology used in getting it to work was to just change the dependency then fix what was broken until nothing was. Sorry I can't be more specific than that. The result is here: http://lane.stanford.edu/index.html Any chance you could identify the cocoon components you subclassed so we can evaluate/test them in our migration to Spring 3.0.5 as well? Best, Mark - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Any planned release of Cocoon 2.2.1 or 2.3? Or should we just be trying to use 3.0-beta?
Seems like a considerable amount of time has gone by without a formal cocoon release, we are relying on patched/hacked releases of our one fixes to cocoon 2.2 modules because the most recent releases of these modules do not seem to play well together for us. See: https://issues.apache.org/jira/browse/COCOON-2265 We int he DSpace community would really like to see a release of Cocoon 2.2.x off the dev trunk or a full release of 3.0 since our project has become so invested in it. Is there any planned timeframe for this happening in your community? Best Regards, Mark Diggory
Re: Understanding Cocoon 2.2 URL Request Handlers
Robby, I'm sorry you do not see the problem. I will clarify it again. Because we don't use the Jetty launch configuration when debugging in Intellej IDEA. We use IDEA's deployment which does not permute the changes to META-INF/MANIFEST the way that the Maven Cocoon plugin seems to do. Likewise, the same would probably be the case in Eclipse. Any level of detail that can be provided on what exactly the Cocoon Maven plugin is mapping to associate the appropriate resources on the CP would help in recreating similar mapping in other development tools/platforms. We can't always use such a custom startegy for testing/dev like the Maven Cocoon plugin is providing. In an ideal world, Cocoon should be developable in IDE's like NetBeans, Eclipse and Intellij. I like the direction 3.0 is taking things in regards to being able to adopt other frameworks to deploy Cocoon into (i.e.OSGi or SpringDM) and this will aid in getting away from this kind of custom dev environment stuff. But the lack of a roadmap or release timeframe for 3.0 and/or maintenance of 2.2 makes it seem like the community has lost steam on getting any new releases out. Mark On May 11, 2010, at 9:26 AM, Robby Pelssers wrote: I don't see the problem... Just create a launch configuration and start debuggin ;-) http://robbypelssers.blogspot.com/2010/05/quick-start-apache-cocoon.html Cheers, Robby -Original Message- From: Mark Diggory [mailto:mdigg...@gmail.com] Sent: Tuesday, May 11, 2010 5:55 PM To: users@cocoon.apache.org Subject: Re: Understanding Cocoon 2.2 URL Request Handlers Ok, I have finally uncovered what is happening to cause error in loading blocks and testing which lead to the previous error. I've determined that with the last release of the cocoon-servlet-service-impl (1.1.0 and 1.2.0), that something is just not right with the URL Protocol Handler resolution in cocoon-jnet. My solution has been to release our own version of cocoon-servlet-service-impl with the necessary fixes and no dependency on this jnet implementation. However, now I have uncovered that when using Intellij IDEA, because we are trying to execute blocks that are not packaged in jars, we get the following error. Can anyone recommend a solution that will allow blocks to be executed when working with unpackaged maven target/classes directories such as those in IDEA and Eclipse? Ideally it would be great to not have to have everything packaged up into jars to test/debug the webapplication, this defeats the point of using a debugging IDE. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.spring.configurator.BlockResourcesHolder': Invocation of init method failed; nested exception is java.lang.NullPointerException at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1338) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) at java.security.AccessController.doPrivileged(Native Method) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185) Mark On Sat, May 8, 2010 at 4:01 PM, Mark Diggory mdigg...@gmail.com wrote: Likewise, I'd like to get advice on the following... Which SitemapServlet should we be using in Cocoon 2.2? http://cocoon.apache.org/2.2/core-modules/core/2.2/apidocs/org/apache/cocoon/servlet/SitemapServlet.html or http://cocoon.apache.org/2.2/core-modules/core/2.2/apidocs/org/apache/cocoon/sitemap/SitemapServlet.html Mark On Sat, May 8, 2010 at 3:37 PM, Mark Diggory mdigg...@gmail.com wrote: Cocoon Developers, We continue to have problems utilizing the Cocoon 2.2 block capabilities dues to not being able to resolve cocoon request handlers where necessary. Could someone please be so kind as to clarify where the following request handlers are defined and how to configure them appropriately now that there is no cocoon.xconf? When we try to enable using cocoon blocks by adding the the cocoon maven plugin to maven and defining our rcl.properties we get the following type of error
Configuring and Optimizing Pipeline Caching in 2.2
Hello, I'm trying to optimize the Ehcache caching pipeline as recommended in Lenya for our application. If anyone could provide a little better detail on how/where this would be adjusted in 2.2 I would be much obliged. I assume that cocoon.xconf is now buried in a block and I should be using spring core.xml to configure this detail? http://lenya.apache.org/docu20/tutorials/production-checklist.html#N10066 Thanks, Mark Diggory - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Understanding Cocoon 2.2 URL Request Handlers
Ok, I have finally uncovered what is happening to cause error in loading blocks and testing which lead to the previous error. I've determined that with the last release of the cocoon-servlet-service-impl (1.1.0 and 1.2.0), that something is just not right with the URL Protocol Handler resolution in cocoon-jnet. My solution has been to release our own version of cocoon-servlet-service-impl with the necessary fixes and no dependency on this jnet implementation. However, now I have uncovered that when using Intellij IDEA, because we are trying to execute blocks that are not packaged in jars, we get the following error. Can anyone recommend a solution that will allow blocks to be executed when working with unpackaged maven target/classes directories such as those in IDEA and Eclipse? Ideally it would be great to not have to have everything packaged up into jars to test/debug the webapplication, this defeats the point of using a debugging IDE. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.spring.configurator.BlockResourcesHolder': Invocation of init method failed; nested exception is java.lang.NullPointerException at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1338) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) at java.security.AccessController.doPrivileged(Native Method) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185) Mark On Sat, May 8, 2010 at 4:01 PM, Mark Diggory mdigg...@gmail.com wrote: Likewise, I'd like to get advice on the following... Which SitemapServlet should we be using in Cocoon 2.2? http://cocoon.apache.org/2.2/core-modules/core/2.2/apidocs/org/apache/cocoon/servlet/SitemapServlet.html or http://cocoon.apache.org/2.2/core-modules/core/2.2/apidocs/org/apache/cocoon/sitemap/SitemapServlet.html Mark On Sat, May 8, 2010 at 3:37 PM, Mark Diggory mdigg...@gmail.com wrote: Cocoon Developers, We continue to have problems utilizing the Cocoon 2.2 block capabilities dues to not being able to resolve cocoon request handlers where necessary. Could someone please be so kind as to clarify where the following request handlers are defined and how to configure them appropriately now that there is no cocoon.xconf? When we try to enable using cocoon blocks by adding the the cocoon maven plugin to maven and defining our rcl.properties we get the following type of error: ava.net.MalformedURLException: unknown protocol: resource at java.net.URL.init(URL.java:574) at java.net.URL.init(URL.java:464) at java.net.URL.init(URL.java:413) at org.apache.cocoon.core.container.spring.avalon.SourceResource.getURL(SourceResource.java:97) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.convertSitemap(ConfigurationReader.java:263) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.readSitemap(ConfigurationReader.java:104) at org.apache.cocoon.core.container.spring.avalon.SitemapElementParser.readConfiguration(SitemapElementParser.java:99) at org.apache.cocoon.core.container.spring.avalon.BridgeElementParser.parse(BridgeElementParser.java:78) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69) or in another place... Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unable to read Avalon configuration from 'sitemap.xmap'.; nested exception is java.net.MalformedURLException: unknown protocol: resource at org.apache.cocoon.core.container.spring.avalon.BridgeElementParser.parse(BridgeElementParser.java:86) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1297) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1287
Understanding Cocoon 2.2 URL Request Handlers
Cocoon Developers, We continue to have problems utilizing the Cocoon 2.2 block capabilities dues to not being able to resolve cocoon request handlers where necessary. Could someone please be so kind as to clarify where the following request handlers are defined and how to configure them appropriately now that there is no cocoon.xconf? When we try to enable using cocoon blocks by adding the the cocoon maven plugin to maven and defining our rcl.properties we get the following type of error: ava.net.MalformedURLException: unknown protocol: resource at java.net.URL.init(URL.java:574) at java.net.URL.init(URL.java:464) at java.net.URL.init(URL.java:413) at org.apache.cocoon.core.container.spring.avalon.SourceResource.getURL(SourceResource.java:97) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.convertSitemap(ConfigurationReader.java:263) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.readSitemap(ConfigurationReader.java:104) at org.apache.cocoon.core.container.spring.avalon.SitemapElementParser.readConfiguration(SitemapElementParser.java:99) at org.apache.cocoon.core.container.spring.avalon.BridgeElementParser.parse(BridgeElementParser.java:78) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69) or in another place... Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unable to read Avalon configuration from 'sitemap.xmap'.; nested exception is java.net.MalformedURLException: unknown protocol: resource at org.apache.cocoon.core.container.spring.avalon.BridgeElementParser.parse(BridgeElementParser.java:86) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1297) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1287) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:92) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:507) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.j Is this caused because we are missing a specific block for registering Protocol Handlers likeresource and blockcontext? Cheers, Mark Diggory - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Understanding Cocoon 2.2 URL Request Handlers
Likewise, I'd like to get advice on the following... Which SitemapServlet should we be using in Cocoon 2.2? http://cocoon.apache.org/2.2/core-modules/core/2.2/apidocs/org/apache/cocoon/servlet/SitemapServlet.html or http://cocoon.apache.org/2.2/core-modules/core/2.2/apidocs/org/apache/cocoon/sitemap/SitemapServlet.html Mark On Sat, May 8, 2010 at 3:37 PM, Mark Diggory mdigg...@gmail.com wrote: Cocoon Developers, We continue to have problems utilizing the Cocoon 2.2 block capabilities dues to not being able to resolve cocoon request handlers where necessary. Could someone please be so kind as to clarify where the following request handlers are defined and how to configure them appropriately now that there is no cocoon.xconf? When we try to enable using cocoon blocks by adding the the cocoon maven plugin to maven and defining our rcl.properties we get the following type of error: ava.net.MalformedURLException: unknown protocol: resource at java.net.URL.init(URL.java:574) at java.net.URL.init(URL.java:464) at java.net.URL.init(URL.java:413) at org.apache.cocoon.core.container.spring.avalon.SourceResource.getURL(SourceResource.java:97) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.convertSitemap(ConfigurationReader.java:263) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.readSitemap(ConfigurationReader.java:104) at org.apache.cocoon.core.container.spring.avalon.SitemapElementParser.readConfiguration(SitemapElementParser.java:99) at org.apache.cocoon.core.container.spring.avalon.BridgeElementParser.parse(BridgeElementParser.java:78) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69) or in another place... Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unable to read Avalon configuration from 'sitemap.xmap'.; nested exception is java.net.MalformedURLException: unknown protocol: resource at org.apache.cocoon.core.container.spring.avalon.BridgeElementParser.parse(BridgeElementParser.java:86) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1297) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1287) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:92) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:507) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.j Is this caused because we are missing a specific block for registering Protocol Handlers likeresource and blockcontext? Cheers, Mark Diggory -- Mark R. Diggory Head of U.S. Operations - @mire http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get t...@ther - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Native XML database system / use cases
Exist uses cocoon and cocoon has xmldb generators. Cheers Mark On Feb 24, 2010, at 7:11 PM, Johannes Lichtenberger johannes.lichtenber...@uni-konstanz.de wrote: Hi all, can you think of nice use cases for an integration of Cocoon into a native XML database system? I've recently implemented a generic Generator which reads whole (shreddered) xml documents from the database system, am currently implementing a simple XPathTransformer which reads an attribute from an element xpath, e.g.: xpath expression=count(//text())/ and an XQueryTransformer which does basically the same (but with XQuery). Furthermore I have integrated Saxon, but I'm not sure if it improves performance and is more scalable if I write an XSLT Transformer which uses the database internal tree structure instead of the TinyTree Saxon uses... I've currently another lecture, where we have to visualize flickr pictures in Google Earth, but I think that it's nothing, which can benefit from Cocoon, because it doesn't really make use of the advantages of pipelines or REST (we have had to aggregate the pictures and sort them according to views, sentiment and date -- to show only the best pictures (furthermore we implemented a grid/circle layout to prevent or reduce overlapping)). Can you maybe imagine some nice simple examples, which really make use of Cocoons strengths (I think it's still multichannel publishing/pipelines and hopefully REST with Cocoon3). Maybe a simple blog would be nice, what do you think? It could make use of the StringTemplate integration and of the controller, which should simplify the implementation of a RESTful blog. Next week I've got a short presentation of my milestone which integrates the above meantioned Generator and Transformers, but maybe you have also ideas for other cool transformers. greetings, Johannes - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: how-to query an xml repository efficiently
eXist has been (IMO) a more productive project that already utilizes Cocoon for presentation. Its origins were in the same db:xml codebase that Xindice was based on, but it has (again IMO) a richer more active developer community around it. I've contributed and used it in the past, the developers have worked hard to address and improve the applications performance dramatically over the years. I think you will find it a more mature product than Xindice. http://exist.sourceforge.net/ Cheers, Mark On Mon, Sep 7, 2009 at 8:31 AM, David Leggdavid.l...@searchevent.co.uk wrote: Hi Robby, I have following use case. The customer has an xml repository which is nothing more then a directory on filesystem which contains subdirectories containing one or more xml files. They now want to query those xml files on some predefined criteria which might change over time… Maybe others with more experience could comment but what about Apache Xindice [1] ?. Not sure what the status is on this project but it was designed from the ground up to be able to store, query and retrieve XML. It may be that everyone abandoned it and started using Solr instead ;-) [1] http://xml.apache.org/xindice/index.html Regards, David Legg - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: how-to query an xml repository efficiently
I utilize Solr as well. I would exemplify the differences between
using Solr+Cocoon and eXist+Cocoon as the following
Solr: good for term indexing large amounts of content while not
retaining the structural nature of that XML content or necessarily
having to store it.
eXist: good for storing large amounts of XML content and retaining
structure, XQuery syntax provides powerful capability to evaluate the
structure of the XML content as well.
If you are seeking to provide user search across precalculated terms
from your xml content then use Solr. You will be parsing your XML and
extracting the terms you wish to provide search on in Solr prior to
your users executing such searches. Solr response format can be
configured in the Solr server via XSLT and other languages, solr
search syntax is Lucene and Solr is capable of providing faceting and
other Search Engine centric metrics on the search results.
If you don't know what queries you (or your users) want to use, or
expect to want to evaluate some structure of your XML in those
queries, then utilize eXist as a database solution for greater
flexibility in this area. Where you can use XQuery to achieve SQL like
FLOWER expressions and control the serialization to XML at the same
time.
I think they both have their place and could even fill important
search and query requirements within the same application. Solr will
give you a simpler search/result syntax while eXist will provide more
database capability. Both have a good Client API in REST and multiple
client library implementations in various languages. Both are highly
configurable.
For instance, you could place your XML repository into eXist and
utilize XQuery to extract the contents that should be indexed into
Solr for simple search and discovery of that content. You could also
the utilize eXist to retrieve required fragments of the content for
more detailed representation of your Solr results rather than having
to parse the entire XML document into memory to do so.
Mark
2009/9/8 DAVIGNON Andre - CETE NP/DIODé/PANDOC
andre.davig...@developpement-durable.gouv.fr:
Robby,
One more thing about this subject.
You can do all that stuff directly with Cocoon / Lucene with java code only,
but Solr offers rich possibilities of index configuration by schema.xml and
index can be handled with a HTTP client inside Cocoon through the Solr XML /
HTTP API. Or in java code with SolrJ API if you prefer.
André (not David ;-) )
Le 08/09/2009 11:12, Robby Pelssers (par Internet, dépôt
users-return-97980-andre.davignon=developpement-durable.gouv...@cocoon.apache.org)
a écrit :
You all convinced me to investigate the SOLR path further ;-)
I already installed SOLR yesterday but I probably did not spent enough
time on playing with it due to lack of time. That's why I ask the
experts on this mailing list ;-)
David's answer The facet research funtionality in Solr can give access
to all possible values in the index of your data for a given property so
the user can pick one among them, then find all matching data. was the
missing piece of the puzzle.
Thx a lot guys !!
Robby
-Original Message-
From: Jeroen Reijn [mailto:j.re...@onehippo.com] Sent: Tuesday, September
08, 2009 10:45 AM
To: users@cocoon.apache.org
Subject: Re: how-to query an xml repository efficiently
Hi Robby,
in this case I even think SOLR would be a great match for this use case.
You can push XML with a http client to SOLR and let SOLR index the
information. See the post.jar that comes with the SOLR example. It pushes
XML to the solr app and indexes it based on your configuration.
The great thing is that you can even configure all kinds of facets based
on what is stored in such a product file, so you can create a nice facet
view in your webapp.
A couple of years ago I was looking a some Forrest components [1], which
were made for using SOLR from a cocooon point of view. It helps you to
perform queries to a SOLR instance from your sitemap and get XML response
back.
Regards,
Jeroen
[1]http://wiki.apache.org/solr/SolrForrest
Robby Pelssers wrote:
Hi jeroen and others who replied to my mail... Let me further explain
my usecase and existing infrastructure.
My customer stores their product data in xml-files on file system
E.g. ${repofolder}/
products/
product-1/
product-1.xml
product-1-image.jpg
...
product-2/
product-2.xml
product-2-image.jpg
...
This is a simplified representation but as you see there is no concept
of an xml database.
Now let's start with a small fictive example for product-1.xml:
product
id/id
descriptiongrandma's cookies/description
categoryfood/category
price2.0/price
/product
From a functional point of view they want to be able to search for
products based on some
