cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Diggory <mdigg...@gmail.com>
Subject Re: Understanding Cocoon 2.2 URL Request Handlers
Date Fri, 14 May 2010 19:10:36 GMT
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 <mdiggory@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 <mdiggory@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


Mime
View raw message