Avalon-Spring bridge (Was: Excalibur potential)
Carsten Ziegeler ha scritto: You might want to have a look at the Avalon-Spring bridge from the Apache Cocoon project. This allows you to use Avalon/Excalibur configurations and components as Spring beans - which is very interesting if you already have used Avalon in the past and want to reuse your stuff in Spring. Hi Carsten, in the JAMES project we also developed something similar to an Avalon-Spring bridge. We most often call it a Spring based Avalon container compatible with the Phoenix configuration. It currently is 99% generic but at the moment is part of james main source tree and includes a couple of things specific to james: http://svn.apache.org/repos/asf/james/server/trunk/spring-deployment/ I searched for Avalon-Spring bridge from cocoon but I didn't find much information: can you give me more detail (links?). Maybe we can merge the Avalon-Spring bridge efforts with Cocoon, and maybe the avalon website should provide some information about the tool, WDYT? Stefano PS: sorry for the crosspost to cocoon and james dev lists in CC, please use the excalibur list for replies.
Database input-module and question about deadlocks
Hello
I'm having all sorts of problems with an input module I wrote that
makes a few databases queries to perform its work, using JDBI. I'm
still using Cocoon 2.1. I don't understand Avalon much and I'd
appreciate it if some of you could look over my code and tell me if
you see something blatantly wrong.
Moreover, I have a more basic question about database connections in
Cocoon. Every call to my pipeline passes through a couple of
SQLTransformers, then a LinkRewriter transformer that calls my input
module many times to expand some particular links, whenever such links
appear in the SAX stream. Every SQLTransformer and every call to my
input module needs a DB connection object to perform its work, ie. the
objects returned by
dataSourceSelector.select(datasource).getConnection().
How can I avoid deadlock situations?
I picture many requests arriving all at the same time, all the
components at the beginning of the pipelines getting their
connections, emptying the connection pool, and then all the pipelines
going into deadlock at a later stage because my input module (or any
other component called at a later stage) cannot get its connection. I
have the feeling this is exactly what's happening in some of my
tests. What would be the correct approach here?
Tobia
Here is the skeleton of my input module:
public class MyInputModule extends AbstractInputModule implements
Serviceable, Disposable, ThreadSafe {
protected ServiceManager manager;
protected ServiceSelector dataSourceSelector;
public void service(ServiceManager manager) throws ServiceException {
this.manager = manager;
dataSourceSelector = (ServiceSelector)
manager.lookup(DataSourceComponent.ROLE + Selector);
}
public void dispose() {
manager.release(dataSourceSelector);
}
private class DataSourceWrapper implements
org.skife.jdbi.ConnectionFactory {
private DataSourceComponent ds;
public DataSourceWrapper(DataSourceComponent ds) {
this.ds = ds;
}
public Connection getConnection() throws SQLException {
return ds.getConnection();
}
}
public Object getAttribute(String url, Configuration conf, Map om)
throws ConfigurationException {
DataSourceComponent datasource = null;
org.skife.jdbi.Handle dbi = null;
try {
try {
datasource = (DataSourceComponent)
dataSourceSelector.select(some-fixed-datasource-name);
} catch (ServiceException e) {
getLogger().warn(Error getting datasource, e);
}
dbi = new org.skife.jdbi.DBI(new
DataSourceWrapper(datasource)).open();
/*
* here goes lots of code using the dbi object to make queries,
etc.
*/
} finally {
try {
if (dbi != null) dbi.close();
} catch (org.skife.jdbi.DBIError dbe) {
getLogger().warn(Error closing JDBI handle, dbe);
}
if (datasource != null) dataSourceSelector.release(datasource);
}
}
}
[jira] Commented: (COCOON-2211) Support for jx:element
[ https://issues.apache.org/jira/browse/COCOON-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605545#action_12605545 ] Grzegorz Kossakowski commented on COCOON-2211: -- Patch applied to trunk in r668604. Thanks Kamal for providing it. I'm not sure if it should go into 2.1.x line. I would really like to see it as maintenance branch where no new features are being added. Support for jx:element -- Key: COCOON-2211 URL: https://issues.apache.org/jira/browse/COCOON-2211 Project: Cocoon Issue Type: New Feature Components: Blocks: Templating Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Assignee: Grzegorz Kossakowski Attachments: JXtemplateElementPatch JXTemplate does n't support a jx:element instruction. This patch provides this support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Moving XMLUtils class from cocoon-pipeline-impl to cocoon-xml-util
Hi, I've noticed that we have very handy XMLUtils[1] class in cocoon-pipeline-impl that is useful outside the cocoon-pipeline-impl and has no dependencies on the rest of the Cocoon. Therefore I would like to move it to cocoon-xml-util module which feels like natural location for such kind of class. Anyone minds? [1] http://svn.eu.apache.org/viewvc/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/xml/XMLUtils.java?view=markup -- Grzegorz Kossakowski
[jira] Created: (COCOON-2212) jx:attribute does not check name is correct before proceeding
jx:attribute does not check name is correct before proceeding - Key: COCOON-2212 URL: https://issues.apache.org/jira/browse/COCOON-2212 Project: Cocoon Issue Type: Improvement Components: Blocks: Templating Affects Versions: 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Fix For: 2.2-dev (Current SVN) Currently, jx:attribute does not validate that the name is correct before generating attribute. This patch fixes this. Also, refactors the JXTemplateGeneratorTestCase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2212) jx:attribute does not check name is correct before proceeding
[ https://issues.apache.org/jira/browse/COCOON-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamal Bhatt updated COCOON-2212: Attachment: JXtemplateAttributePatch jx:attribute does not check name is correct before proceeding - Key: COCOON-2212 URL: https://issues.apache.org/jira/browse/COCOON-2212 Project: Cocoon Issue Type: Improvement Components: Blocks: Templating Affects Versions: 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Fix For: 2.2-dev (Current SVN) Attachments: JXtemplateAttributePatch Currently, jx:attribute does not validate that the name is correct before generating attribute. This patch fixes this. Also, refactors the JXTemplateGeneratorTestCase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2212) jx:attribute does not check name is correct before proceeding
[ https://issues.apache.org/jira/browse/COCOON-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamal Bhatt updated COCOON-2212: Description: Currently, jx:attribute does not validate that the name is correct before generating attribute. This patch fixes this. Also, refactored the JXTemplateGeneratorTestCase was: Currently, jx:attribute does not validate that the name is correct before generating attribute. This patch fixes this. Also, refactors the JXTemplateGeneratorTestCase jx:attribute does not check name is correct before proceeding - Key: COCOON-2212 URL: https://issues.apache.org/jira/browse/COCOON-2212 Project: Cocoon Issue Type: Improvement Components: Blocks: Templating Affects Versions: 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Fix For: 2.2-dev (Current SVN) Attachments: JXtemplateAttributePatch Currently, jx:attribute does not validate that the name is correct before generating attribute. This patch fixes this. Also, refactored the JXTemplateGeneratorTestCase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (COCOON-2212) jx:attribute does not check name is correct before proceeding
Kamal Bhatt (JIRA) wrote: jx:attribute does not check name is correct before proceeding - Key: COCOON-2212 URL: https://issues.apache.org/jira/browse/COCOON-2212 Project: Cocoon Issue Type: Improvement Components: Blocks: Templating Affects Versions: 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Fix For: 2.2-dev (Current SVN) Currently, jx:attribute does not validate that the name is correct before generating attribute. This patch fixes this. Also, refactors the JXTemplateGeneratorTestCase I was also going to update jx:attribute to support namespaces and prefixes, but when I added the namespace to AttributeAwareXMLConsumer.attribute I got no namespace. I tracked the namespace and it was going through the system. Not too sure if this is a bug or a feature of AttributeAwareXMLConsumer, may investigate further, but it isn't a high priority for me.
Re: Moving XMLUtils class from cocoon-pipeline-impl to cocoon-xml-util
On Jun 17, 2008, at 6:49 AM, Grzegorz Kossakowski wrote: I've noticed that we have very handy XMLUtils[1] class in cocoon- pipeline-impl that is useful outside the cocoon-pipeline-impl and has no dependencies on the rest of the Cocoon. Therefore I would like to move it to cocoon-xml-util module which feels like natural location for such kind of class. Anyone minds? Not at all! Go ahead. Vadim [1] http://svn.eu.apache.org/viewvc/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/xml/XMLUtils.java?view=markup -- Grzegorz Kossakowski
Problem with Maven Daisy plug-in
Hi, I tried to publish my screencast on RCL and stuck at the point that I have no idea how to proceed from. Basically, I added flash file using MultiMediaObject as document type. Then created the whole infrastructure like page including the uploaded flash file, added to navigation files, etc. However the result I've got is far from being expected, you can see it for you own here: http://cocoon.zones.apache.org/nightly-docs/2.2/1448_1_1.html Notice in the source code that there is a XML for included document that has not been transformed into HTML. Does it mean that our plug-in fails to handle MultiMediaObjects? If so how hard would it be to fix it? -- Grzegorz Kossakowski
