Re: [RT] RESTful web applications
Hi,
I think this is a really great idea. In the past months, I have been working
with AJAX-RESTful architectures. For instance, I have mixed Ext js [1] with
Cocoon 2.2 as XML provider and SOAP Web Services as services provider.
Although, I think Cocoon 2.2 is a too big stuff if only it´s dedicated to
produce XML. A microCocoon could be a goog idea.
BR,
Juanjo.
[1] http://extjs.com/
On Dec 5, 2007 3:16 PM, Reinhard Poetz [EMAIL PROTECTED] wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
snip/
For me those are the reasons why I said that I have changed the camp
and think that Stefano was right with his opinion that traditional web
frameworks would become obsolete. But, in contrast to him, I think
that Cocoon, which in some respect isn't 'traditional' at all, can
become the ideal server-side counterpart for such RESTful web
applications.
Interesting! Can you elaborate on why you think Cocoon is great for
RESTful applications? Is it because of its URL pattern matching
features?
That's one half of the story. The other one is XML pipelines and content
aggregation on an XML level (XML plays in many RESTful architectures an
important role, at least in ours) which make Cocoon still very appealing
to me.
Actually all three together are the virus that has infected me long time
ago at
the good old Cocoon 2.0alphaX days.
- o -
Recently I've been thinking more and more about some kind of
Micro-Cocoon[*]
that consists of
o a slimmed-down sitemap language available in as an XML and as a Java
dialect
(no component declarations, no sub-sitemaps, no resources, merged
match/select),
o a controller implementation that is optimized for being used in RESTful
scenarios (similar to Apples) and
o a lean forms framework that borrows some ideas from Webforms 2.0 and
follows the principles of REST. Daniel and I had some discussions about
it in
Rome and I've started with some experiments but don't have anything
substantial so far.
All the parts mentioned above should be useable in parallel with a
traditional Cocoon 2.2 application. Thanks to the servlet-service
framework this
shouldn't be too hard to be achieved.
If this sounds interesting to anybody, just let me know.
[*] borrowing the term micro from Bertrand who used it for a slimmed
down
version of Sling which seems to be another (too) huge beast in the webapp
framework arena.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Problem with Cocoon Spring Configurator 1.0.0 and Weblogic 9.2
Hi,
Thank you Daniel for your support and deep explanation.
I have chosen the second solution because i don´t like a weblogic specific
code. I attach the resulting code DeploymentUtil class.
Because of Weblogic is a very popular application server, I think this error
would be consider a bug and IMHO a patch should go in future cocoon
releases.
BR,
Juanjo
On 9/30/07, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
Juanjo Vázquez skrev:
Hi all,
I´m working in an Cocoon 2.2-RC1 web application with one block.
Everything is ok when i deploy to Tomcat but i´m getting errors when i
deploy to Weblogic 9.2. I have been looking for a workaround or a
solution and it seems the problem is the blocks are not deployed to the
public web directory in the weblogic domain.
Everything points to the method deployBlockResources in
DeploymentUtil class (cocoon-spring-configuratior-1.0.0.jar) is not
working properly in this environment. I have been debugging the
application deployed to weblogic with these discoveries:
1. Spring loads the jar configurations with zip protocol instead jar
protocol, i.e.
zip:C:/bea/user_projects/domains/cm_domain/servers/AdminServer/tmp/_WL_user/proxy-ear/53xotj/war/WEB-INF/lib/cocoon-
servlet-service-impl-1.0.0-M2.jar!/META-INF/cocoon/spring/cocoon-callstack-environment.xml
2. In Runtime, the URLConnection class is a
weblogic.utils.ZipUrlConnection not a JarURLConnection
Can anybody help me with this problem?
Some background:
Blocks can contain resources that are intended to be available in e.g.
sitemaps. These resources are put in a directory called COB-INF at the
root of the directory structure of a block. The blocks are ordinary jars
that are put in WEB-INF/lib (during development the blocks can expanded
also).
The task of DeploymentUtil.deployBlockResources is to search the class
path for all urls to COB-INF resources. If the url is of the type file:
the url and the block name is registred. Then the resources in the
COB-INF directory of the block is available through the blockcontext:
source. If the url is a jar, the resources in the COB-INF directory are
extracted to a temp directory in the file system and the url of the
extracted resources is registred together with the clock name.
For Weblogic it seem like the classloader contains zip: urls for
resources. A solution would be to extend the
DeploymentUtil.deployBlockResources method with a case for the zip:
protocol, it would be similar to the jar: case but a little bit more
compliacted as the zip protocol doesn't know about mainfest attributes.
A problem with this is that the ZipUrlConnection is Weblogic specific,
so the protocol handling code in deployBlockResources would need to be
extracted to some components.
Another, and much simpler solution if it works, would be to just replace
zip: with jar: in the url string, create a new url object from the
patched url string, and use the existing jar handling code.
/Daniel
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the License); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.cocoon.spring.configurator.impl;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.JarURLConnection;
import java.net.URL;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Map;
import java.util.jar.JarFile;
import java.util.zip.ZipEntry;
import org.apache.commons.io.IOUtils;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* Helper class for deploying resources from the block artifacts.
*
* @version $Id: DeploymentUtil.java 555608 2007-07-12 12:12:54Z felixk $
* @since 1.0
*/
public abstract class DeploymentUtil {
protected static final Log logger = LogFactory.getLog(DeploymentUtil.class);
protected static final String BLOCK_RESOURCES_PATH = COB-INF;
/**
* Deploy all files with a given prefix from a jar file to a directory
* in the file system.
* @param jarFile The jar file containing the resources.
* @param prefix The common prefix for the files.
* @param destination The destination directory.
* @throws IOException
Problem with Cocoon ContextSourceFactory and Weblogic 9.2
Hi all, I have found another problem with Cocoon 2.2 and Weblogic 9.2. The stacktrace is: java.net.MalformedURLException: context://sitemap.xmap could not be found. (possible context problem) at org.apache.cocoon.components.source.impl.ContextSourceFactory.getSource( ContextSourceFactory.java:132) at org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI( CocoonSourceResolver.java:152) at org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI( CocoonSourceResolver.java:182) at org.apache.cocoon.components.treeprocessor.TreeProcessor.configure( TreeProcessor.java:232) at org.apache.avalon.framework.container.ContainerUtil.configure( ContainerUtil.java:202) at org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor.postProcessBeforeInitialization (AvalonBeanPostProcessor.java:235) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization (AbstractAutowireCapableBeanFactory.java:301) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean (AbstractAutowireCapableBeanFactory.java:1167) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean (AbstractAutowireCapableBeanFactory.java:425) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject( AbstractBeanFactory.java:251) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton (DefaultSingletonBeanRegistry.java:156) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:248) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:160) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons (DefaultListableBeanFactory.java:287) at org.springframework.context.support.AbstractApplicationContext.refresh( AbstractApplicationContext.java:352) at org.springframework.web.context.ContextLoader.createWebApplicationContext( ContextLoader.java:244) at org.springframework.web.context.ContextLoader.initWebApplicationContext( ContextLoader.java:187) at org.springframework.web.context.ContextLoaderListener.contextInitialized( ContextLoaderListener.java:49) at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run (EventsManager.java:376) at weblogic.security.acl.internal.AuthenticatedSubject.doAs( AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java :121) at weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent( EventsManager.java:82) at weblogic.servlet.internal.WebAppServletContext.preloadResources( WebAppServletContext.java:1609) at weblogic.servlet.internal.WebAppServletContext.start( WebAppServletContext.java:2764) at weblogic.servlet.internal.WebAppModule.startContexts( WebAppModule.java:889) at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:333) at weblogic.application.internal.flow.ModuleStateDriver$3.next( ModuleStateDriver.java:204) at weblogic.application.utils.StateMachineDriver.nextState( StateMachineDriver.java:26) at weblogic.application.internal.flow.ModuleStateDriver.start( ModuleStateDriver.java:60) at weblogic.application.internal.flow.ScopedModuleDriver.start( ScopedModuleDriver.java:200) at weblogic.application.internal.flow.ModuleListenerInvoker.start( ModuleListenerInvoker.java:117) at weblogic.application.internal.flow.ModuleStateDriver$3.next( ModuleStateDriver.java:204) I have been debugging ContextSourceFactory and the problem seems to be that neither getRealPath nor getResource are able to find the context://sitemap.xml resource. Furthermore, I have seen that the temp public directory (in weblogic) contains a folder blocks and a folder cocoon_xml_resolver_entities but the last is empty. Is this normal?. Please, any help is welcome. Thanks in advance. BR, Juanjo.
Problem with Cocoon Spring Configurator 1.0.0 and Weblogic 9.2
Hi all, I´m working in an Cocoon 2.2-RC1 web application with one block. Everything is ok when i deploy to Tomcat but i´m getting errors when i deploy to Weblogic 9.2. I have been looking for a workaround or a solution and it seems the problem is the blocks are not deployed to the public web directory in the weblogic domain. Everything points to the method deployBlockResources in DeploymentUtil class (cocoon-spring-configuratior-1.0.0.jar) is not working properly in this environment. I have been debugging the application deployed to weblogic with these discoveries: 1. Spring loads the jar configurations with zip protocol instead jar protocol, i.e. zip:C:/bea/user_projects/domains/cm_domain/servers/AdminServer/tmp/_WL_user/proxy-ear/53xotj/war/WEB-INF/lib/cocoon- servlet-service-impl-1.0.0-M2.jar!/META-INF/cocoon/spring/cocoon-callstack-environment.xml 2. In Runtime, the URLConnection class is a weblogic.utils.ZipUrlConnection not a JarURLConnection Can anybody help me with this problem? Thanks in advance. Juanjo.
