Re: Lucene jar version (1.4.2??) - cocoon 2.1.11
Adding a comment about the last release for JVM 1.3 for a jar in jars.xml is a great idea. Thank you Alfred. Best Regards, Antonio Gallardo. Alfred Nathaniel escribió: On Thu, 2008-04-17 at 11:05 -0600, Antonio Gallardo wrote: I had no time to confirm, but I suspect the reason can be the cocoon 2.1 minimal requirement of JVM 1.3. If lucene migrated to JVM 1.4 for version 2.0 we cannot update the jar. Lucene 1.4.3 is indeed the last release for JVM 1.2. The next higher release 1.9.1 (2 Mar 2006) already requires JVM 1.4. http://svn.apache.org/viewvc/lucene/java/tags/lucene_1_9_1/BUILD.txt?r1=150277&r2=168332&sortby=rev Cheers, Alfred. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lucene jar version (1.4.2??) - cocoon 2.1.11
On Thu, 2008-04-17 at 11:05 -0600, Antonio Gallardo wrote: > I had no time to confirm, but I suspect the reason can be the cocoon 2.1 > minimal requirement of JVM 1.3. If lucene migrated to JVM 1.4 for > version 2.0 we cannot update the jar. Lucene 1.4.3 is indeed the last release for JVM 1.2. The next higher release 1.9.1 (2 Mar 2006) already requires JVM 1.4. http://svn.apache.org/viewvc/lucene/java/tags/lucene_1_9_1/BUILD.txt?r1=150277&r2=168332&sortby=rev Cheers, Alfred. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Old Cocoon query
On 17 Apr 2008, Derek Hohls wrote: in this mail: http://marc.info/?l=xml-cocoon-users&m=119996793507680&w=2 you gave guidance on how to post-process escaped tags from a database. However, when I implement it, it also strips out all the tags as well, leaving just text inside the tags. How can the code be modified not to lose the nested tags? My fault for posting untested code! Try modifying the first XSLT, unescape-pre.xsl, like this: (still untested) Tobia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: webdav transformer
Thanks, Jeroen - someone mentioned that one once before but I had forgotten it. Looking at the description in the wiki, I think it is not as good a fit for my needs as the webdav approach, since the Forrest project uses a generator instead of a transformer. I need to update the Solr index with the output of a CForm, so being able to transform the data as part of a pipeline before generating a Solr doc and pushing it up to Solr is very convenient. It makes it easy to do all those little normalization and validation steps to keep the data clean. Peter From: Jeroen Reijn [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 1:29 AM To: users@cocoon.apache.org; users@cocoon.apache.org Subject: RE: webdav transformer Hi Peter, I had to dig a bit deeper in my memory, before I was able to answer this. Almost a year ago, I did some research for the SOLR and Cocoon combination and I came across some Apache Forrest plugins that are useful in combination with Cocoon. See [1] for more information on this plugin. The plugin contains a couple of generators that can handle both GET and POST requests to SOLR. I hope this helps you with your problem, and now you don't have to wrap your request into a webdav request. Regards, Jeroen [1] http://wiki.apache.org/solr/SolrForrest -Original Message- From: Binkley, Peter [mailto:[EMAIL PROTECTED] Sent: Wed 4/16/2008 5:11 PM To: users@cocoon.apache.org Subject: RE: webdav transformer Solr speaks POST, and so does the webdav transfomer. I've blogged about this here: http://www.wallandbinkley.com/quaedam/?p=104 . I was surprised how difficult it was to find an easy way to post blocks of XML (as opposed to name-value pairs) without writing code. No doubt this could be added to the CInclude transformer without too much trouble. I wonder why there hasn't been enough demand to make this happen; it's a fairly common requirement these days, I'd have thought. (Not that I've got my act together to post an enhancement request, and I haven't looked at 2.2). Peter From: Jeroen Reijn [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 16, 2008 1:21 AM To: users@cocoon.apache.org; users@cocoon.apache.org Subject: RE: webdav transformer Hi Robert, what is the stacktrace that you get from the webbdav transformer that sends the request? Just because I'm curious: solr speaks webdav? Regards, Jeroen -Original Message- From: news on behalf of Robert Goené Sent: Tue 4/15/2008 8:55 PM To: users@cocoon.apache.org Subject: webdav transformer Hi! I try to use the webdav transformer in Cocoon 2.1.10 to post some data to Solr. When I do not provide a element, I get the expected error message from Solr: no data provided. So far so good. When I do provide a element, I get a very general NullPointerException. I use the Saxon transformer, because I need some EXSLT features. Could this explain my problem? Would explicitely defining the webdav transformer do any good? Thanks in advance, Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lucene jar version (1.4.2??) - cocoon 2.1.11
HI, I had no time to confirm, but I suspect the reason can be the cocoon 2.1 minimal requirement of JVM 1.3. If lucene migrated to JVM 1.4 for version 2.0 we cannot update the jar. Best Regards, Antonio Gallardo. dynnamitt escribió: Why is Lucene "frozen-in-time" ?! (the version shipped w cocoon 2.1.11 is only 1.4.3..) Will there be any problems for me If I wanna swap to latest and greatest Lucene 2.3.1 or 2.3.0?? regards Dynnamitt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[HELP] SitemapEvenListener
Hello together!
I am trying to implement an OpenSessionInViewInterceptor (OSIVI) using Cocoons
(2.2) Enter/LeaveSitemapEventListener. I have one class wich implements both
Listener interfaces:
...
public void enteredSitemap(EnterSitemapEvent event) {
log.debug("Opening Hibernate Session and beginning transaction.");
Session session = sessionFactory.openSession();
session.beginTransaction();
TransactionSynchronizationManager.bindResource(
sessionFactory, new SessionHolder(session));
TransactionSynchronizationManager.initSynchronization();
}
...
public void leftSitemap(LeaveSitemapEvent event) {
Session session = sessionFactory.getCurrentSession();
try {
log.debug("Committing the database transaction.");
session.getTransaction().commit();
} catch ( RuntimeException ex ) {
try {
log.error( ex );
log.debug("Rolling back the database transaction.");
session.getTransaction().rollback();
if ( session.isOpen() ) {
session.close();
}
} catch ( RuntimeException e ) {
log.error( e );
throw e; // Let the exception propagate up the stack.
}
} finally {
try {
if ( session.isOpen() ) {
session.close();
}
} catch ( RuntimeException e ) { /* do nothing */ }
TransactionSynchronizationManager.unbindResource( sessionFactory );
TransactionSynchronizationManager.clearSynchronization();
}
}
...
I thought this would work, since i manually bind the session to the 'current'
thread. But after opening the session (and some DB Work wich is logged to
stdout) I get following Exception from out of leftSitemap( ... ):
org.hibernate.HibernateException: No Hibernate Session bound to thread, and
configuration does not allow creation of non-transactional one here
at
org.springframework.orm.hibernate3.SpringSessionContext.currentSession(SpringSessionContext.java:63)
at
org.hibernate.impl.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:544)
at
de.ifado.isac.web.OpenSessionInViewInterceptor.leftSitemap(OpenSessionInViewInterceptor.java:70)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:256)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:247)
at
org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:351)
at
org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:169)
at
org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:84)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:468)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:443)
at
org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:264)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy5.service(Unknown Source)
at
org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:106)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at
org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(MultipartFilter.java:131)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:324)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828)
Lucene jar version (1.4.2??) - cocoon 2.1.11
Why is Lucene "frozen-in-time" ?! (the version shipped w cocoon 2.1.11 is only 1.4.3..) Will there be any problems for me If I wanna swap to latest and greatest Lucene 2.3.1 or 2.3.0?? regards Dynnamitt -- View this message in context: http://www.nabble.com/Lucene-jar-version-%281.4.2--%29---cocoon-2.1.11-tp16741120p16741120.html Sent from the Cocoon - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: webdav transformer
Hi Peter, I had to dig a bit deeper in my memory, before I was able to answer this. Almost a year ago, I did some research for the SOLR and Cocoon combination and I came across some Apache Forrest plugins that are useful in combination with Cocoon. See [1] for more information on this plugin. The plugin contains a couple of generators that can handle both GET and POST requests to SOLR. I hope this helps you with your problem, and now you don't have to wrap your request into a webdav request. Regards, Jeroen [1] http://wiki.apache.org/solr/SolrForrest -Original Message- From: Binkley, Peter [mailto:[EMAIL PROTECTED] Sent: Wed 4/16/2008 5:11 PM To: users@cocoon.apache.org Subject: RE: webdav transformer Solr speaks POST, and so does the webdav transfomer. I've blogged about this here: http://www.wallandbinkley.com/quaedam/?p=104 . I was surprised how difficult it was to find an easy way to post blocks of XML (as opposed to name-value pairs) without writing code. No doubt this could be added to the CInclude transformer without too much trouble. I wonder why there hasn't been enough demand to make this happen; it's a fairly common requirement these days, I'd have thought. (Not that I've got my act together to post an enhancement request, and I haven't looked at 2.2). Peter From: Jeroen Reijn [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 16, 2008 1:21 AM To: users@cocoon.apache.org; users@cocoon.apache.org Subject: RE: webdav transformer Hi Robert, what is the stacktrace that you get from the webbdav transformer that sends the request? Just because I'm curious: solr speaks webdav? Regards, Jeroen -Original Message- From: news on behalf of Robert Goené Sent: Tue 4/15/2008 8:55 PM To: users@cocoon.apache.org Subject: webdav transformer Hi! I try to use the webdav transformer in Cocoon 2.1.10 to post some data to Solr. When I do not provide a element, I get the expected error message from Solr: no data provided. So far so good. When I do provide a element, I get a very general NullPointerException. I use the Saxon transformer, because I need some EXSLT features. Could this explain my problem? Would explicitely defining the webdav transformer do any good? Thanks in advance, Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
