Re: Cocoon 2.2 documentation online!
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
If you want to test it, change the stylesheet, then install the Daisy
export plugin into your local Maven repository by running 'mvn install',
Hmm this step failed with
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.daisycms:daisy-maven-plugin:jar:1.0.0-alpha-1
the daisy-maven-plugin isn't available at the central Maven repository. Please
try again with
mvn install -P daisy
(the 'daisy' profile contains a reference to the cocoondev.org Maven 2
repository)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
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.
Re: Problem with Cocoon Spring Configurator 1.0.0 and Weblogic 9.2
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
Re: Springifying CForms
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vadim Gritsenko wrote:
I think it is related to the refactoring. Trunk fails to build now with:
[INFO] Building Javaflow Block Samples
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce-once {execution: enforce-maven}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 2 source files to
/Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-javaflow/cocoon-javaflow-sample/target/classes
During the refactorings I've found sample classes in the cocoon-forms-impl
block which I've moved
to the cocoon-forms-sample block which IMHO they belong to. Thus the dependency
of the
javaflow-sample block was wrong (which you've already found and fixed, thanks
Vadim).
There could be more samples not migrated to new CForms behaviour wrt pring bean
vs. Avalon
Component handling but the code in CForms will make it clear if there are such
old constructs ;-)
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHAAgyLNdJvZjjVZARAgMcAKDsunFclopxHvVqEp10i5tx4TArRACeKBPA
UR6jcxC1Zs5ITdfvgdv9OBw=
=dUs5
-END PGP SIGNATURE-
Re: svn commit: r580786 - in /cocoon/whiteboard/osgi/core/cocoon-spring-osgi/cocoon-spring-osgi-impl/src/main: java/org/apache/cocoon/springosgi/config/ java/org/apache/cocoon/springosgi/service/expor
On 30.09.2007 17:02 Uhr, [EMAIL PROTECTED] wrote: Author: danielf Date: Sun Sep 30 14:02:24 2007 New Revision: 580786 URL: http://svn.apache.org/viewvc?rev=580786view=rev Log: Spring-OSGi doesn't contain any support for beans with prototype scope. This is mainly because there is no direct mapping between the prototype scope and any OSGi concepts. In OSGi services are either singletons at global level or at bundle level. The only reasonable mapping, AFAICS, is to export a factory bean as an OSGi service. As Cocoon uses prototypes in many places I have extended Spring-OSGi with support for exporting a factory bean instead of the bean by setting the attribute factory-export to true. In this case a SmartFactoryBean is exported and the classes of the contained bean is put in the org.springframework.osgi.beanclasses property. The import part is not written yet. The code contains a lot of copy and modify from Spring-OSGi as some of the involved classes wasn't really extendible. The idea is to try to contribute it back to Spring-OSGi. I don't know if it applies here at all, but in standard Spring to get access to the factory bean instead of the bean itself you prefix the bean name with an ampersand. Is it reasonable to go with that approach here as well compared to your new attribute factory-export? Joerg
