You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Mark Diggory <md...@gmail.com> on 2010/05/09 00:37:23 UTC
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 like"resource" and "blockcontext"?
Cheers,
Mark Diggory
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Understanding Cocoon 2.2 URL Request Handlers
Posted by Mark Diggory <md...@gmail.com>.
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:mdiggory@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 <md...@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 <md...@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 like"resource" and "blockcontext"?
>>>
>>> Cheers,
>>> Mark Diggory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Understanding Cocoon 2.2 URL Request Handlers
Posted by Robby Pelssers <ro...@ciber.com>.
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:mdiggory@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 <md...@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 <md...@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 like"resource" and "blockcontext"?
>>
>> Cheers,
>> Mark Diggory
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Understanding Cocoon 2.2 URL Request Handlers
Posted by Mark Diggory <md...@gmail.com>.
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 <md...@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 <md...@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 like"resource" and "blockcontext"?
>>
>> Cheers,
>> Mark Diggory
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Understanding Cocoon 2.2 URL Request Handlers
Posted by Mark Diggory <md...@gmail.com>.
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 <md...@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 like"resource" 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 Tog@ther
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org