You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Mansour Al Akeel <ma...@gmail.com> on 2013/02/09 05:09:59 UTC
Connecting 2 blocks with C3.0
I am trying to follow this tutorial http://cocoon.apache.org/2.2/1291_1_1.html
to connect 2 blocks. I was able to do this in the past easily with C2.1 and 2.2.
With C3.0 as soon as I add the depency block to pom.xml I star getting an error:
2013-02-08 23:06:52,805 btpool0-1 INFO
support.DefaultListableBeanFactory - Pre-instantiating singletons in
org.springframework.beans.factory.support.DefaultListableBeanFactory@177b4d3:
defining beans []; parent:
org.springframework.beans.factory.support.DefaultListableBeanFactory@97b7e5
2013-02-08 23:06:52,870 btpool0-1 ERROR servlet.XMLSitemapServlet -
Can't initialize the RequestProcessor correctly.
org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException:
Can't build sitemap.
at org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:57)
at org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:191)
at org.apache.cocoon.servlet.RequestProcessor.<init>(RequestProcessor.java:81)
at org.apache.cocoon.servlet.XMLSitemapServlet.lazyInitialize(XMLSitemapServlet.java:60)
at org.apache.cocoon.servlet.XMLSitemapServlet.service(XMLSitemapServlet.java:44)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)
at org.apache.cocoon.jnet.URLHandlerFactoryCollector.installURLHandlers(URLHandlerFactoryCollector.java:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
I have created the project from maven archetypes. Additionally, when
following the same tutorial, and I modify the rcl.properties to
include the classes for the first project, matchers stop matching on
any patterns.
Is there something I need to do to get this to work properly ??
Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Connecting 2 blocks with C3.0
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 09/02/2013 21:33, Mansour Al Akeel wrote:
> I truly appreciate your help, and I agree with you that this needs to
> be documented in a place where it's easy to find. It is taking me a
> lot of time to try to figure out what is wrong.
> I think it's related more to the running mode and the configurations.
> For example when you declare a block as a dependency, its
>
> resources/META-INF/cocoon/spring/dev/mysite-servlet-service.xml
>
> has to have different name in the importing block, for example no two
> blocks should have this:
>
> resources/META-INF/cocoon/spring/block-servlet-service.xml
>
> I am still investigating, and can not confirm that this is the issue.
Just name the '*servlet-service.xml' file according to the containing
block, as I did in my sample project [4] [5].
> Additionally
>
>
> <!-- A Cocoon-Sitemap based servlet-service. -->
> <bean id="com.mycompany.mysite.service"
> class="org.apache.cocoon.servlet.XMLSitemapServlet">
> <servlet:context mount-path="/mysite"
> context-path="jar:classpath:/COB-INF/"/>
> </bean>
>
> in
>
> https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite/src/main/resources/META-INF/cocoon/spring/dev/mysite-servlet-service.xml
>
> needs a bit more clarification. Specifically
>
> <servlet:context mount-path="/mysite"
> context-path="jar:classpath:/COB-INF/"/>
>
> in development mode and this line in production:
>
> <servlet:context mount-path="/mysite"
> context-path="jar:classpath:lib/${project.build.finalName}.jar!/COB-INF/"/>
>
> It will be nice if this is documented with the scenarios where we
> should use one of another.
Don't fear, it will be ;-)
Basically, the development mode (and related configuration files) is
used when you are supposed to perform, well, actual development of your
block, e.g. when you launch
mvn jetty:run
from your block's source directory, while the production mode is used
when your block is deployed within a containing webapp.
Anyway, why don't you prepare a draft of the page for COCOON3-119 [6]?
As you can see from this sample [7], the format is APT [8], quite simple
to handle.
Regards.
[1] https://github.com/ilgrosso/cocoon3EmptyProject/tree/COCOON3-105
[2] https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/src/main/resources/COB-INF/sitemap.xmap
[3] http://cocoon.apache.org/2.2/1291_1_1.html
[4] https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite/src/main/resources/META-INF/cocoon/spring/mysite-servlet-service.xml
[5] https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/src/main/resources/META-INF/cocoon/spring/mysite2-servlet-service.xml
[6] https://issues.apache.org/jira/browse/COCOON3-119
[7] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/parent/src/site/apt/features.apt
[8] http://maven.apache.org/doxia/references/apt-format.html
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Connecting 2 blocks with C3.0
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 10/02/2013 22:59, Mansour Al Akeel wrote:
> Hello Francesco,
>
> I noticed from the read me file in the project you created as an example:
>
>
>
> IMPORTANT: be sure to use the latest Cocoon 3 SNAPSHOT artifacts
> from ASF repository
>
>
> Does this mean that block communication is not supported in 3.0.0-beta-1 ??
Still supported, but deprecated. There is a way to re-enabled it, but it
not performed by default.
> I am getting this error with the pom generated by cocoon archetype.
>
> 2013-02-09 17:27:28.070::WARN: Failed startup of context
> org.mortbay.jetty.plugin.Jetty6PluginWebAppContext@c50e46{/,/home/mansour/workspace/flamenco/pipelines/channel-website/target/rcl/webapp}
> java.lang.RuntimeException: Cannot invoke listener
> org.springframework.web.context.ContextLoaderListener@19e681c
> at org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingListener.invoke(ReloadingListener.java:298)
> at org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingListener.contextInitialized(ReloadingListener.java:150)
> at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:540)
> at org.mortbay.jetty.servlet.Context.startContext(Context.java:135)
> at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1220)
> at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:510)
>
> I will look deeper into this error, but I am very interested in
> knowing if "block communication" is not supported except in the
> snapshot.
The "block communication" is fully supported in 3.0.0-beta-1-SNAPSHOT
but not enabled via the "blockcontext:/" protocol.
This is the reason why I have published my sample project [1], e.g. to
show how to achieve block communication *without* blockcontext:
As you have requested in another e-mail of this thread, I will also
update [1] with another block's pipeline invocation. I'll keep you updated.
Consider that there is still the possibility to use blockcontext:
protocol in 3.0.0-beta-1-SNAPSHOT, even though you will need to make
some modifications on the project generated via archetype. I will add
this to the page for COCOON3-119 [3].
FYI, You can read through COCOON3-105 if you want to understand more the
reasons behind this switch.
Regards.
[1] https://github.com/ilgrosso/cocoon3EmptyProject/tree/COCOON3-105
[2] https://issues.apache.org/jira/browse/COCOON3-105
[3] https://issues.apache.org/jira/browse/COCOON3-119
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Connecting 2 blocks with C3.0
Posted by Mansour Al Akeel <ma...@gmail.com>.
Hello Francesco,
I noticed from the read me file in the project you created as an example:
IMPORTANT: be sure to use the latest Cocoon 3 SNAPSHOT artifacts
from ASF repository
Does this mean that block communication is not supported in 3.0.0-beta-1 ??
I am getting this error with the pom generated by cocoon archetype.
2013-02-09 17:27:28.070::WARN: Failed startup of context
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext@c50e46{/,/home/mansour/workspace/flamenco/pipelines/channel-website/target/rcl/webapp}
java.lang.RuntimeException: Cannot invoke listener
org.springframework.web.context.ContextLoaderListener@19e681c
at org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingListener.invoke(ReloadingListener.java:298)
at org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingListener.contextInitialized(ReloadingListener.java:150)
at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:540)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:135)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1220)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:510)
I will look deeper into this error, but I am very interested in
knowing if "block communication" is not supported except in the
snapshot.
Thank you.
On Sat, Feb 9, 2013 at 9:04 PM, Mansour Al Akeel
<ma...@gmail.com> wrote:
> I am still looking for the way to call pipeline in another block and
> not an xslt file.
> For example:
>
> assuming I have a block called "contents" and the mounting path is
> "/contents" in the active configuration.
> What would be the url to call ?? Currently I have this:
>
>
> <map:generate src="servlet:contents:/contents/documentId/{map:1}/{map:2}.xml"
> />
>
> My understanding (if like C2.2), I would be using:
>
> servlet:block-name:/mount-point/url-to-match
>
> Is this correct ??
>
>
>
> On Sat, Feb 9, 2013 at 8:33 PM, Mansour Al Akeel
> <ma...@gmail.com> wrote:
>> I truly appreciate your help, and I agree with you that this needs to
>> be documented in a place where it's easy to find. It is taking me a
>> lot of time to try to figure out what is wrong.
>> I think it's related more to the running mode and the configurations.
>> For example when you declare a block as a dependency, its
>>
>> resources/META-INF/cocoon/spring/dev/mysite-servlet-service.xml
>>
>> has to have different name in the importing block, for example no two
>> blocks should have this:
>>
>> resources/META-INF/cocoon/spring/block-servlet-service.xml
>>
>> I am still investigating, and can not confirm that this is the issue.
>>
>> Additionally
>>
>>
>> <!-- A Cocoon-Sitemap based servlet-service. -->
>> <bean id="com.mycompany.mysite.service"
>> class="org.apache.cocoon.servlet.XMLSitemapServlet">
>> <servlet:context mount-path="/mysite"
>> context-path="jar:classpath:/COB-INF/"/>
>> </bean>
>>
>> in
>>
>> https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite/src/main/resources/META-INF/cocoon/spring/dev/mysite-servlet-service.xml
>>
>> needs a bit more clarification. Specifically
>>
>> <servlet:context mount-path="/mysite"
>> context-path="jar:classpath:/COB-INF/"/>
>>
>> in development mode and this line in production:
>>
>> <servlet:context mount-path="/mysite"
>> context-path="jar:classpath:lib/${project.build.finalName}.jar!/COB-INF/"/>
>>
>> It will be nice if this is documented with the scenarios where we
>> should use one of another.
>>
>>
>> Thank you.
>>
>>
>>
>>
>> On Sat, Feb 9, 2013 at 7:19 AM, Francesco Chicchiriccò
>> <il...@apache.org> wrote:
>>> On 09/02/2013 05:09, Mansour Al Akeel wrote:
>>>>
>>>> I am trying to follow this tutorial
>>>> http://cocoon.apache.org/2.2/1291_1_1.html
>>>> to connect 2 blocks. I was able to do this in the past easily with C2.1
>>>> and 2.2.
>>>>
>>>> With C3.0 as soon as I add the depency block to pom.xml I star getting an
>>>> error:
>>>>
>>>> [...]
>>>>
>>>>
>>>>
>>>> I have created the project from maven archetypes. Additionally, when
>>>> following the same tutorial, and I modify the rcl.properties to
>>>> include the classes for the first project, matchers stop matching on
>>>> any patterns.
>>>> Is there something I need to do to get this to work properly ??
>>>
>>>
>>> Hi,
>>> COCOON3-105 changed the way how blocks are deployed in a Cocoon webapp: this
>>> affects only C3 SNAPSHOTS of course, and even in this case you can restore
>>> the old (i.e. 2.2) way of connecting blocks.
>>>
>>> I've prepared a simple C3 project at [1] that shows how to deal with this:
>>> the README there should be enough to get it working and a quick look at
>>> sources can help in understanding what has changed "under the hood".
>>>
>>> More specifically, as you can see from [2], the block mysite2 can refer to
>>> block mysite1's resources as
>>>
>>> <map:read
>>> src="jar:classpath:lib/mysite-${project.version}.jar!/COB-INF/{map:1}.xsl"/>
>>>
>>> where ${project.version} is changed by Maven at build time into the version
>>> declared in pom.xml.
>>>
>>>
>>> We need of course to provide a proper documentation for how to get started
>>> with C3: I've opened COCOON3-119 for this.
>>> Hope this helps, in the meanwhile.
>>>
>>> Regards.
>>>
>>> [1] https://github.com/ilgrosso/cocoon3EmptyProject/tree/COCOON3-105
>>> [2]
>>> https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/src/main/resources/COB-INF/sitemap.xmap
>>> [3] http://cocoon.apache.org/2.2/1291_1_1.html
>>>
>>> --
>>> Francesco Chicchiriccò
>>>
>>> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
>>> http://people.apache.org/~ilgrosso/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Connecting 2 blocks with C3.0
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 25/02/2013 05:42, Mansour Al Akeel wrote:
> Francesco,
> I know this is an old thread, but I was trying to update my pom.xml so
> that I get the
>
> <servlet:context mount-path="/mysite"
> context-path="jar:classpath:lib/${project.build.finalName}.jar!/COB-INF/"/>
>
> replaced by maven at build time.
> Now the whole build is failing.
> Is there another way to get this placeholder replaced without using
> the pom included with your project, especially that it has many
> missing dependencies:
>
> [INFO] ------------------------------------------------------------------------
> [INFO] Building contents SNAPSHOT-1.0
> [INFO] ------------------------------------------------------------------------
> [WARNING] The POM for org.springframework:spring-dao:jar:3.1.2.RELEASE
> is missing, no dependency information available
> [WARNING] The POM for commons-jexl:commons-jexl:jar:2.1.1 is missing,
> no dependency information available
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1.534s
> [INFO] Finished at: Sun Feb 24 23:35:48 GMT 2013
> [INFO] Final Memory: 7M/88M
> [INFO] ------------------------------------------------------------------------
>
> I have added the repositories to my pom.xml
Hi,
let me try to summarize your situation (correct me if I am wrong):
1. you have generated the C3 project before the fix for COCOON3-105
(that removed the default support for blockcontext:/)
2. recently you have re-built this project, Maven re-downloaded the
latest versions of C3 SNAPSHOT artifacts (containing the fix for
COCOON3-105, hence not working by default with blockcontext;/ stuff);
with these new dependencies, you started getting error messages about
classes not found
At this point you have two options:
(a) stuck with blockcontext:/ stuff: simply re-add this dependency in
the webapp (i.e. the Maven submodule project that collects all blocks)
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-block-deployment</artifactId>
<version>1.2.1</version>
</dependency>
(b) adapt your project to the new structure: the easiest path to achieve
this is to generate an empty project (or take mine [1] as reference) and
start changing / removing / adding things in your project by taking the
empty one as reference.
My guess is that you are in the middle of (b); however, (a) is by far
easier and quicker. The choice is up to you.
> On the side of this discussion, I am wondering if there is a release
> date for C3.0. I have been prototyping a project for a client,
> and really can not much done, due to the continuous changes introduced
> to a "beta" phase ! If we can just stop changing the configurations,
> and
> make the project in a "Real Beta" state and focus on bug fixing and
> documentation, I think it will help users like me getting things done.
I must correct you, C3 is not yet in "beta" phase: the latest stable
release is still "alpha", as the disclaimer says at
http://cocoon.apache.org/3.0/alpha-warning.html
You would be using the stable, e.g. not changing over time, C3 artifacts
if your C3 version was 3.0.0-alpha-3.
Instead, you are using the 3.0.0-beta-1-SNAPSHOT artifacts, which are
more cool because embed all latest fixes and features but is also more
unstable.
If you are interested in which issues are left before releasing the
stable 3.0.0-beta-1 version, please take a look at
https://issues.apache.org/jira/issues/?jql=project%20%3D%20COCOON3%20AND%20fixVersion%20%3D%20%223.0.0-beta-1%22%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
If you are willing to help to speed up and improve this process, your
contribution is highly appreciated.
Regards.
> On Mon, Feb 11, 2013 at 10:09 AM, Francesco Chicchiriccò
> <il...@apache.org> wrote:
>> On 09/02/2013 22:04, Mansour Al Akeel wrote:
>>> I am still looking for the way to call pipeline in another block and not
>>> an xslt file.
>>> For example:
>>>
>>> assuming I have a block called "contents" and the mounting path is
>>> "/contents" in the active configuration.
>>> What would be the url to call ?? Currently I have this:
>>>
>>>
>>> <map:generate
>>> src="servlet:contents:/contents/documentId/{map:1}/{map:2}.xml"/>
>>> My understanding (if like C2.2), I would be using:
>>>
>>> servlet:block-name:/mount-point/url-to-match
>>>
>>> Is this correct ??
>>
>> In this respect nothing has changed since C2.2: I have updated my sample
>> application [1] to include a specific entry for invoking another block's
>> pipeline.
>> As you will see from [2] and [3], I have just applied the C2.2 instructions
>> from [4].
>>
>> Regards.
>>
>> [1] https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105
>> [2] https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/src/main/resources/META-INF/cocoon/spring/mysite2-servlet-service.xml
>> [3] https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/rcl.properties
>> [4] http://cocoon.apache.org/2.2/1291_1_1.html
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Properties replacement (was Re: Connecting 2 blocks with C3.0)
Posted by Thorsten Scherler <sc...@gmail.com>.
Hi Mansour,
we are happy you are so active but please use the dev list for your
questions since c3 is not stable. Meaning by definition we have devs no
user working on c3. Please let us discuss this mail and other on the dev
list. TIA.
On 02/25/2013 05:42 AM, Mansour Al Akeel wrote:
> Francesco,
> I know this is an old thread, but I was trying to update my pom.xml so
> that I get the
>
> <servlet:context mount-path="/mysite"
> context-path="jar:classpath:lib/${project.build.finalName}.jar!/COB-INF/"/>
>
> replaced by maven at build time.
> Now the whole build is failing.
> Is there another way to get this placeholder replaced without using
> the pom included with your project, especially that it has many
> missing dependencies:
>
> [INFO] ------------------------------------------------------------------------
> [INFO] Building contents SNAPSHOT-1.0
> [INFO] ------------------------------------------------------------------------
> [WARNING] The POM for org.springframework:spring-dao:jar:3.1.2.RELEASE
> is missing, no dependency information available
> [WARNING] The POM for commons-jexl:commons-jexl:jar:2.1.1 is missing,
> no dependency information available
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1.534s
> [INFO] Finished at: Sun Feb 24 23:35:48 GMT 2013
> [INFO] Final Memory: 7M/88M
> [INFO] ------------------------------------------------------------------------
The only thing from the pom you need is something along the lines of:
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>false</filtering>
<excludes>
<exclude>META-INF/cocoon/spring/**</exclude>
</excludes>
</resource>
<resource>
<directory>src/main/resources/META-INF/cocoon/spring</directory>
<filtering>true</filtering>
<targetPath>${project.build.outputDirectory}/META-INF/cocoon/spring
</targetPath>
</resource>
</resources>
</build>
That is doing the filtering and replacing the properties.
However in our latest project we have dropped a bit the configuration of
cocoon in terms of properties from
META-INF/cocoon/properties/xxx.properties and use a central place for
the configuration. This allows to use the project specific properties in
a wide range of modules from a central place.
<build>
<filters>
<filter>../src/main/filter/general.properties</filter>
<filter>../src/main/filter/${env}.properties</filter>
</filters>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>false</filtering>
<excludes>
<exclude>META-INF/cocoon/spring/**</exclude>
<exclude>META-INF/cocoon/properties/**</exclude>
</excludes>
</resource>
<resource>
<directory>src/main/resources/META-INF/cocoon/spring</directory>
<filtering>true</filtering>
<targetPath>${project.build.outputDirectory}/META-INF/cocoon/spring</targetPath>
</resource>
<resource>
<directory>src/main/resources/META-INF/cocoon/properties</directory>
<filtering>true</filtering>
<targetPath>${project.build.outputDirectory}/META-INF/cocoon/properties</targetPath>
</resource>
</resources>
Here we assume that you have a couple of general properties that may not
change but as well some environment specific properties. Then in our
properties file in cocoon we just use
common.resources=${common.resources}
extractor.host=${extractor.host}
and the "real" values come from ../src/main/filter/general.properties
and ../src/main/filter/${env}.properties
common.resources=${project.parent.basedir}/api/src/main/resources/COB-INF/resources/
extractor.host=http://localhost:8888/
We may want to look into changing our artifacts to
1) parent provides filter
2) modules uses this filter from parent module
The advantages is that the configuration is taken place in a single
place and can be used in a cross module manner. For us we use the same
properties in c3 and in our droids module.
wdyt?
salu2
--
Thorsten Scherler <scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
Properties replacement (was Re: Connecting 2 blocks with C3.0)
Posted by Thorsten Scherler <sc...@gmail.com>.
Hi Mansour,
we are happy you are so active but please use the dev list for your
questions since c3 is not stable. Meaning by definition we have devs no
user working on c3. Please let us discuss this mail and other on the dev
list. TIA.
On 02/25/2013 05:42 AM, Mansour Al Akeel wrote:
> Francesco,
> I know this is an old thread, but I was trying to update my pom.xml so
> that I get the
>
> <servlet:context mount-path="/mysite"
> context-path="jar:classpath:lib/${project.build.finalName}.jar!/COB-INF/"/>
>
> replaced by maven at build time.
> Now the whole build is failing.
> Is there another way to get this placeholder replaced without using
> the pom included with your project, especially that it has many
> missing dependencies:
>
> [INFO] ------------------------------------------------------------------------
> [INFO] Building contents SNAPSHOT-1.0
> [INFO] ------------------------------------------------------------------------
> [WARNING] The POM for org.springframework:spring-dao:jar:3.1.2.RELEASE
> is missing, no dependency information available
> [WARNING] The POM for commons-jexl:commons-jexl:jar:2.1.1 is missing,
> no dependency information available
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1.534s
> [INFO] Finished at: Sun Feb 24 23:35:48 GMT 2013
> [INFO] Final Memory: 7M/88M
> [INFO] ------------------------------------------------------------------------
The only thing from the pom you need is something along the lines of:
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>false</filtering>
<excludes>
<exclude>META-INF/cocoon/spring/**</exclude>
</excludes>
</resource>
<resource>
<directory>src/main/resources/META-INF/cocoon/spring</directory>
<filtering>true</filtering>
<targetPath>${project.build.outputDirectory}/META-INF/cocoon/spring
</targetPath>
</resource>
</resources>
</build>
That is doing the filtering and replacing the properties.
However in our latest project we have dropped a bit the configuration of
cocoon in terms of properties from
META-INF/cocoon/properties/xxx.properties and use a central place for
the configuration. This allows to use the project specific properties in
a wide range of modules from a central place.
<build>
<filters>
<filter>../src/main/filter/general.properties</filter>
<filter>../src/main/filter/${env}.properties</filter>
</filters>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>false</filtering>
<excludes>
<exclude>META-INF/cocoon/spring/**</exclude>
<exclude>META-INF/cocoon/properties/**</exclude>
</excludes>
</resource>
<resource>
<directory>src/main/resources/META-INF/cocoon/spring</directory>
<filtering>true</filtering>
<targetPath>${project.build.outputDirectory}/META-INF/cocoon/spring</targetPath>
</resource>
<resource>
<directory>src/main/resources/META-INF/cocoon/properties</directory>
<filtering>true</filtering>
<targetPath>${project.build.outputDirectory}/META-INF/cocoon/properties</targetPath>
</resource>
</resources>
Here we assume that you have a couple of general properties that may not
change but as well some environment specific properties. Then in our
properties file in cocoon we just use
common.resources=${common.resources}
extractor.host=${extractor.host}
and the "real" values come from ../src/main/filter/general.properties
and ../src/main/filter/${env}.properties
common.resources=${project.parent.basedir}/api/src/main/resources/COB-INF/resources/
extractor.host=http://localhost:8888/
We may want to look into changing our artifacts to
1) parent provides filter
2) modules uses this filter from parent module
The advantages is that the configuration is taken place in a single
place and can be used in a cross module manner. For us we use the same
properties in c3 and in our droids module.
wdyt?
salu2
--
Thorsten Scherler <scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Connecting 2 blocks with C3.0
Posted by Mansour Al Akeel <ma...@gmail.com>.
Francesco,
I know this is an old thread, but I was trying to update my pom.xml so
that I get the
<servlet:context mount-path="/mysite"
context-path="jar:classpath:lib/${project.build.finalName}.jar!/COB-INF/"/>
replaced by maven at build time.
Now the whole build is failing.
Is there another way to get this placeholder replaced without using
the pom included with your project, especially that it has many
missing dependencies:
[INFO] ------------------------------------------------------------------------
[INFO] Building contents SNAPSHOT-1.0
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for org.springframework:spring-dao:jar:3.1.2.RELEASE
is missing, no dependency information available
[WARNING] The POM for commons-jexl:commons-jexl:jar:2.1.1 is missing,
no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.534s
[INFO] Finished at: Sun Feb 24 23:35:48 GMT 2013
[INFO] Final Memory: 7M/88M
[INFO] ------------------------------------------------------------------------
I have added the repositories to my pom.xml
On the side of this discussion, I am wondering if there is a release
date for C3.0. I have been prototyping a project for a client,
and really can not much done, due to the continuous changes introduced
to a "beta" phase ! If we can just stop changing the configurations,
and
make the project in a "Real Beta" state and focus on bug fixing and
documentation, I think it will help users like me getting things done.
Thank you.
On Mon, Feb 11, 2013 at 10:09 AM, Francesco Chicchiriccò
<il...@apache.org> wrote:
> On 09/02/2013 22:04, Mansour Al Akeel wrote:
>>
>> I am still looking for the way to call pipeline in another block and not
>> an xslt file.
>> For example:
>>
>> assuming I have a block called "contents" and the mounting path is
>> "/contents" in the active configuration.
>> What would be the url to call ?? Currently I have this:
>>
>>
>> <map:generate
>> src="servlet:contents:/contents/documentId/{map:1}/{map:2}.xml"/>
>> My understanding (if like C2.2), I would be using:
>>
>> servlet:block-name:/mount-point/url-to-match
>>
>> Is this correct ??
>
>
> In this respect nothing has changed since C2.2: I have updated my sample
> application [1] to include a specific entry for invoking another block's
> pipeline.
> As you will see from [2] and [3], I have just applied the C2.2 instructions
> from [4].
>
> Regards.
>
> [1] https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105
> [2]
> https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/src/main/resources/META-INF/cocoon/spring/mysite2-servlet-service.xml
> [3]
> https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/rcl.properties
> [4] http://cocoon.apache.org/2.2/1291_1_1.html
>
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
>
>
> ---------------------------------------------------------------------
> 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: Connecting 2 blocks with C3.0
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 09/02/2013 22:04, Mansour Al Akeel wrote:
> I am still looking for the way to call pipeline in another block and not an xslt file.
> For example:
>
> assuming I have a block called "contents" and the mounting path is
> "/contents" in the active configuration.
> What would be the url to call ?? Currently I have this:
>
>
> <map:generate src="servlet:contents:/contents/documentId/{map:1}/{map:2}.xml"/>
> My understanding (if like C2.2), I would be using:
>
> servlet:block-name:/mount-point/url-to-match
>
> Is this correct ??
In this respect nothing has changed since C2.2: I have updated my sample
application [1] to include a specific entry for invoking another block's
pipeline.
As you will see from [2] and [3], I have just applied the C2.2
instructions from [4].
Regards.
[1] https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105
[2]
https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/src/main/resources/META-INF/cocoon/spring/mysite2-servlet-service.xml
[3]
https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/rcl.properties
[4] http://cocoon.apache.org/2.2/1291_1_1.html
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Connecting 2 blocks with C3.0
Posted by Mansour Al Akeel <ma...@gmail.com>.
I am still looking for the way to call pipeline in another block and
not an xslt file.
For example:
assuming I have a block called "contents" and the mounting path is
"/contents" in the active configuration.
What would be the url to call ?? Currently I have this:
<map:generate src="servlet:contents:/contents/documentId/{map:1}/{map:2}.xml"
/>
My understanding (if like C2.2), I would be using:
servlet:block-name:/mount-point/url-to-match
Is this correct ??
On Sat, Feb 9, 2013 at 8:33 PM, Mansour Al Akeel
<ma...@gmail.com> wrote:
> I truly appreciate your help, and I agree with you that this needs to
> be documented in a place where it's easy to find. It is taking me a
> lot of time to try to figure out what is wrong.
> I think it's related more to the running mode and the configurations.
> For example when you declare a block as a dependency, its
>
> resources/META-INF/cocoon/spring/dev/mysite-servlet-service.xml
>
> has to have different name in the importing block, for example no two
> blocks should have this:
>
> resources/META-INF/cocoon/spring/block-servlet-service.xml
>
> I am still investigating, and can not confirm that this is the issue.
>
> Additionally
>
>
> <!-- A Cocoon-Sitemap based servlet-service. -->
> <bean id="com.mycompany.mysite.service"
> class="org.apache.cocoon.servlet.XMLSitemapServlet">
> <servlet:context mount-path="/mysite"
> context-path="jar:classpath:/COB-INF/"/>
> </bean>
>
> in
>
> https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite/src/main/resources/META-INF/cocoon/spring/dev/mysite-servlet-service.xml
>
> needs a bit more clarification. Specifically
>
> <servlet:context mount-path="/mysite"
> context-path="jar:classpath:/COB-INF/"/>
>
> in development mode and this line in production:
>
> <servlet:context mount-path="/mysite"
> context-path="jar:classpath:lib/${project.build.finalName}.jar!/COB-INF/"/>
>
> It will be nice if this is documented with the scenarios where we
> should use one of another.
>
>
> Thank you.
>
>
>
>
> On Sat, Feb 9, 2013 at 7:19 AM, Francesco Chicchiriccò
> <il...@apache.org> wrote:
>> On 09/02/2013 05:09, Mansour Al Akeel wrote:
>>>
>>> I am trying to follow this tutorial
>>> http://cocoon.apache.org/2.2/1291_1_1.html
>>> to connect 2 blocks. I was able to do this in the past easily with C2.1
>>> and 2.2.
>>>
>>> With C3.0 as soon as I add the depency block to pom.xml I star getting an
>>> error:
>>>
>>> [...]
>>>
>>>
>>>
>>> I have created the project from maven archetypes. Additionally, when
>>> following the same tutorial, and I modify the rcl.properties to
>>> include the classes for the first project, matchers stop matching on
>>> any patterns.
>>> Is there something I need to do to get this to work properly ??
>>
>>
>> Hi,
>> COCOON3-105 changed the way how blocks are deployed in a Cocoon webapp: this
>> affects only C3 SNAPSHOTS of course, and even in this case you can restore
>> the old (i.e. 2.2) way of connecting blocks.
>>
>> I've prepared a simple C3 project at [1] that shows how to deal with this:
>> the README there should be enough to get it working and a quick look at
>> sources can help in understanding what has changed "under the hood".
>>
>> More specifically, as you can see from [2], the block mysite2 can refer to
>> block mysite1's resources as
>>
>> <map:read
>> src="jar:classpath:lib/mysite-${project.version}.jar!/COB-INF/{map:1}.xsl"/>
>>
>> where ${project.version} is changed by Maven at build time into the version
>> declared in pom.xml.
>>
>>
>> We need of course to provide a proper documentation for how to get started
>> with C3: I've opened COCOON3-119 for this.
>> Hope this helps, in the meanwhile.
>>
>> Regards.
>>
>> [1] https://github.com/ilgrosso/cocoon3EmptyProject/tree/COCOON3-105
>> [2]
>> https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/src/main/resources/COB-INF/sitemap.xmap
>> [3] http://cocoon.apache.org/2.2/1291_1_1.html
>>
>> --
>> Francesco Chicchiriccò
>>
>> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
>> http://people.apache.org/~ilgrosso/
>>
>>
>> ---------------------------------------------------------------------
>> 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: Connecting 2 blocks with C3.0
Posted by Mansour Al Akeel <ma...@gmail.com>.
I truly appreciate your help, and I agree with you that this needs to
be documented in a place where it's easy to find. It is taking me a
lot of time to try to figure out what is wrong.
I think it's related more to the running mode and the configurations.
For example when you declare a block as a dependency, its
resources/META-INF/cocoon/spring/dev/mysite-servlet-service.xml
has to have different name in the importing block, for example no two
blocks should have this:
resources/META-INF/cocoon/spring/block-servlet-service.xml
I am still investigating, and can not confirm that this is the issue.
Additionally
<!-- A Cocoon-Sitemap based servlet-service. -->
<bean id="com.mycompany.mysite.service"
class="org.apache.cocoon.servlet.XMLSitemapServlet">
<servlet:context mount-path="/mysite"
context-path="jar:classpath:/COB-INF/"/>
</bean>
in
https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite/src/main/resources/META-INF/cocoon/spring/dev/mysite-servlet-service.xml
needs a bit more clarification. Specifically
<servlet:context mount-path="/mysite"
context-path="jar:classpath:/COB-INF/"/>
in development mode and this line in production:
<servlet:context mount-path="/mysite"
context-path="jar:classpath:lib/${project.build.finalName}.jar!/COB-INF/"/>
It will be nice if this is documented with the scenarios where we
should use one of another.
Thank you.
On Sat, Feb 9, 2013 at 7:19 AM, Francesco Chicchiriccò
<il...@apache.org> wrote:
> On 09/02/2013 05:09, Mansour Al Akeel wrote:
>>
>> I am trying to follow this tutorial
>> http://cocoon.apache.org/2.2/1291_1_1.html
>> to connect 2 blocks. I was able to do this in the past easily with C2.1
>> and 2.2.
>>
>> With C3.0 as soon as I add the depency block to pom.xml I star getting an
>> error:
>>
>> [...]
>>
>>
>>
>> I have created the project from maven archetypes. Additionally, when
>> following the same tutorial, and I modify the rcl.properties to
>> include the classes for the first project, matchers stop matching on
>> any patterns.
>> Is there something I need to do to get this to work properly ??
>
>
> Hi,
> COCOON3-105 changed the way how blocks are deployed in a Cocoon webapp: this
> affects only C3 SNAPSHOTS of course, and even in this case you can restore
> the old (i.e. 2.2) way of connecting blocks.
>
> I've prepared a simple C3 project at [1] that shows how to deal with this:
> the README there should be enough to get it working and a quick look at
> sources can help in understanding what has changed "under the hood".
>
> More specifically, as you can see from [2], the block mysite2 can refer to
> block mysite1's resources as
>
> <map:read
> src="jar:classpath:lib/mysite-${project.version}.jar!/COB-INF/{map:1}.xsl"/>
>
> where ${project.version} is changed by Maven at build time into the version
> declared in pom.xml.
>
>
> We need of course to provide a proper documentation for how to get started
> with C3: I've opened COCOON3-119 for this.
> Hope this helps, in the meanwhile.
>
> Regards.
>
> [1] https://github.com/ilgrosso/cocoon3EmptyProject/tree/COCOON3-105
> [2]
> https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/src/main/resources/COB-INF/sitemap.xmap
> [3] http://cocoon.apache.org/2.2/1291_1_1.html
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
>
>
> ---------------------------------------------------------------------
> 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: Connecting 2 blocks with C3.0
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 09/02/2013 05:09, Mansour Al Akeel wrote:
> I am trying to follow this tutorial http://cocoon.apache.org/2.2/1291_1_1.html
> to connect 2 blocks. I was able to do this in the past easily with C2.1 and 2.2.
>
> With C3.0 as soon as I add the depency block to pom.xml I star getting an error:
>
> [...]
>
>
> I have created the project from maven archetypes. Additionally, when
> following the same tutorial, and I modify the rcl.properties to
> include the classes for the first project, matchers stop matching on
> any patterns.
> Is there something I need to do to get this to work properly ??
Hi,
COCOON3-105 changed the way how blocks are deployed in a Cocoon webapp:
this affects only C3 SNAPSHOTS of course, and even in this case you can
restore the old (i.e. 2.2) way of connecting blocks.
I've prepared a simple C3 project at [1] that shows how to deal with
this: the README there should be enough to get it working and a quick
look at sources can help in understanding what has changed "under the hood".
More specifically, as you can see from [2], the block mysite2 can refer
to block mysite1's resources as
<map:read
src="jar:classpath:lib/mysite-${project.version}.jar!/COB-INF/{map:1}.xsl"/>
where ${project.version} is changed by Maven at build time into the
version declared in pom.xml.
We need of course to provide a proper documentation for how to get
started with C3: I've opened COCOON3-119 for this.
Hope this helps, in the meanwhile.
Regards.
[1] https://github.com/ilgrosso/cocoon3EmptyProject/tree/COCOON3-105
[2]
https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/src/main/resources/COB-INF/sitemap.xmap
[3] http://cocoon.apache.org/2.2/1291_1_1.html
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org