CForms: how to find widget by it's full id?
Hi, There's probably a very easy answer to my question: how can I find a widget by it's full id? I have an id, like boxes.1.contacts1 (it's a repeater inside an repeater), and now I want to find the repeater object (I have a reference to the Form instance). getChild(id) gives me a direct child member (as far as I can see), and lookupWidget(path) requires me to translate all the dots into slashes (boxes/1/contacts1 finds the correct widget). So I can solve it with lookupWidget(), but I was wondering if there is a method of direct accessing a deeper child widget without having to modify the ID string. Something like 'findWidget()'. I can submit a patch if such a method may be useful. Thanks, Bart.
Switching to servlet-service-fw
For those of you who are using the blocks-fw and want to switch to the
refactored servlet-service-fw (the blocks-fw can be considered as deprecated!),
here is a writeup of what needs to be done to switch:
- pom.xml: remove dependency on blocks-fw and replace it with
dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-servlet-service-components/artifactId
version1.0.0-SNAPSHOT/version
/dependency
- change your servlet bean definitions
See
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/src/main/resources/META-INF/cocoon/spring/
for working examples.
- if you use property replacement, you have to change the property
blockContextUrl to contextPath
- if you use the block: protocol, replace it with servlet:.
- update your web.xml to use the new DispatcherServlet:
servlet
descriptionCocoon blocks dispatcher/description
display-nameDispatcherServlet/display-name
servlet-nameDispatcherServlet/servlet-name
servlet-classorg.apache.cocoon.servletservice.DispatcherServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
For me that was all I had to do but the three projects that I updaded aren't the
most complicated ones. I won't put this into the CMS or the Wiki as it will
confuse people very soon rather than being helpful. As I guess that all
block-fw^^^servlet-service-fw users are reading this list, this information
should find its audience anyway.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Open file handles
When I use the reloading classloader plugin and make a mistake in some xslt
document, refresh the browser and cause an error, it seems to me that there
remains an open file handle to the XSLT document. This is a problem as Eclipse
wants to replace it and gets confused and finally refuses to work properly at
all until I stop the app container and rebuild the project.
Any ideas?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Error creating bean with name 'javax.servlet.http.HttpServletRequest/callstack'
Hi, Running the latest code from trunk, I get an error as the title described. The following is the exception stack: Caused by: org.springframework.beans.factory.BeanCreationException: Error creati ng bean with name 'javax.servlet.http.HttpServletRequest/callstack': Initializat ion of bean failed; nested exception is org.springframework.aop.framework.AopCon figException: Couldn't generate CGLIB subclass of class [interface javax.servlet .http.HttpServletRequest]: Common causes of this problem include using a final c lass or a non-visible class; nested exception is net.sf.cglib.core.CodeGeneratio nException: java.lang.reflect.InvocationTargetException--null at org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.createBean(AbstractAutowireCapableBeanFactory.java:452) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getOb ject(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistr y.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory. preInstantiateSingletons(DefaultListableBeanFactory.java:270) at org.springframework.context.support.AbstractApplicationContext.refres h(AbstractApplicationContext.java:346) at org.springframework.web.context.support.AbstractRefreshableWebApplica tionContext.refresh(AbstractRefreshableWebApplicationContext.java:156) at org.springframework.web.context.ContextLoader.createWebApplicationCon text(ContextLoader.java:246) at org.springframework.web.context.ContextLoader.initWebApplicationConte xt(ContextLoader.java:184) at org.springframework.web.context.ContextLoaderListener.contextInitiali zed(ContextLoaderListener.java:49) at org.apache.cocoon.servlet.ReloadingListener.invoke (ReloadingListener. java:148) ... 38 more Caused by: org.springframework.aop.framework.AopConfigException: Couldn't genera te CGLIB subclass of class [interface javax.servlet.http.HttpServletRequest]: Co mmon causes of this problem include using a final class or a non-visible class; nested exception is net.sf.cglib.core.CodeGenerationException: java.lang.reflect .InvocationTargetException--null at org.springframework.aop.framework.Cglib2AopProxy.getProxy (Cglib2AopPr oxy.java:206) at org.springframework.aop.framework.Cglib2AopProxy.getProxy (Cglib2AopPr oxy.java:145) at org.springframework.aop.framework.ProxyFactory.getProxy (ProxyFactory. java:72) at org.springframework.aop.scope.ScopedProxyFactoryBean.setBeanFactory(S copedProxyFactoryBean.java:103) at org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.initializeBean(AbstractAutowireCapableBeanFactory.java:1076) at org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.createBean(AbstractAutowireCapableBeanFactory.java:429) ... 49 more Caused by: net.sf.cglib.core.CodeGenerationException: java.lang.reflect.Invocati onTargetException--null at net.sf.cglib.core.AbstractClassGenerator.create (AbstractClassGenerato r.java:237) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285) at org.springframework.aop.framework.Cglib2AopProxy.getProxy (Cglib2AopPr oxy.java:200) ... 54 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at net.sf.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:384) at net.sf.cglib.core.AbstractClassGenerator.create (AbstractClassGenerato r.java:219) ... 57 more Caused by: java.lang.NoClassDefFoundError: org/springframework/aop/scope/ScopedO bject at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) ... 63 more Rice
Re: JIRA karma
Jason Johnston wrote: On Mon, 05 Feb 2007 16:21:14 +0100, Carsten Ziegeler [EMAIL PROTECTED] wrote: Jason Johnston wrote: Thanks Carsten. But does the change take a while to kick in, or should I see it immediately? I still see only the Feedback Required option under Available Workflow Actions. I presume I should be seeing some more options like a way to assign the issue to myself and to close it. It should work immediately. Can you assign the bug to yourself? (It should be below the Feedback Required link under the Operations section.) Nope... see http://people.apache.org/~jjohnston/jira.png for a screenshot. It seems that the user administration has changed with a newer version of Jira :( It should work now. Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: Open file handles
Reinhard Poetz wrote: When I use the reloading classloader plugin and make a mistake in some xslt document, refresh the browser and cause an error, it seems to me that there remains an open file handle to the XSLT document. This is a problem as Eclipse wants to replace it and gets confused and finally refuses to work properly at all until I stop the app container and rebuild the project. Any ideas? There has been a fix for a similar problem to the excalibur sourceresolver recently. So you might want to try latest sourceresolver from svn. Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: Error creating bean with name 'javax.servlet.http.HttpServletRequest/callstack'
It looks like you are lacking the cglib. It is (since yesterday) part of the dependencies for cocoon-servlet-service-impl. It should be included in your cocoon-webapp dependencies by transitive dependency handling. It works for me. It might be that you need to clean and rebuild your cocoon-webapp or something. /Daniel Rice Yeh skrev: Hi, Running the latest code from trunk, I get an error as the title described. The following is the exception stack: Caused by: org.springframework.beans.factory.BeanCreationException: Error creati ng bean with name ' javax.servlet.http.HttpServletRequest/callstack': Initializat ion of bean failed; nested exception is org.springframework.aop.framework.AopCon figException: Couldn't generate CGLIB subclass of class [interface javax.servlet .http.HttpServletRequest]: Common causes of this problem include using a final c lass or a non-visible class; nested exception is net.sf.cglib.core.CodeGeneratio nException: java.lang.reflect.InvocationTargetException-- null ...
Re: Error creating bean with name 'javax.servlet.http.HttpServletRequest/callstack'
I do have cglib-2.1_3.jar in the WEB/lib directory. By tracing the code, I find the classloader used in Enhancer is the classloder of javax.servlet.http.HttpServletRequest, which is an instance of org.codehaus.classworlds.RealmClassLoader. RealmClassLoader just include class path used in jetty, not include path in WEB/lib. Hence, an exception java.lang.NoClassDefFoundError: org/springframework/aop/scope/ScopedObject is thrown. Rice On 2/6/07, Daniel Fagerstrom [EMAIL PROTECTED] wrote: It looks like you are lacking the cglib. It is (since yesterday) part of the dependencies for cocoon-servlet-service-impl. It should be included in your cocoon-webapp dependencies by transitive dependency handling. It works for me. It might be that you need to clean and rebuild your cocoon-webapp or something. /Daniel Rice Yeh skrev: Hi, Running the latest code from trunk, I get an error as the title described. The following is the exception stack: Caused by: org.springframework.beans.factory.BeanCreationException: Error creati ng bean with name ' javax.servlet.http.HttpServletRequest/callstack': Initializat ion of bean failed; nested exception is org.springframework.aop.framework.AopCon figException: Couldn't generate CGLIB subclass of class [interface javax.servlet .http.HttpServletRequest]: Common causes of this problem include using a final c lass or a non-visible class; nested exception is net.sf.cglib.core.CodeGeneratio nException: java.lang.reflect.InvocationTargetException-- null ...
Re: Error creating bean with name 'javax.servlet.http.HttpServletRequest/callstack'
Any suggestion about what to do about it? /Daniel Rice Yeh skrev: I do have cglib-2.1_3.jar in the WEB/lib directory. By tracing the code, I find the classloader used in Enhancer is the classloder of javax.servlet.http.HttpServletRequest, which is an instance of org.codehaus.classworlds.RealmClassLoader . RealmClassLoader just include class path used in jetty, not include path in WEB/lib. Hence, an exception java.lang.NoClassDefFoundError: org/springframework/aop/scope /ScopedObject is thrown. Rice On 2/6/07, *Daniel Fagerstrom* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It looks like you are lacking the cglib. It is (since yesterday) part of the dependencies for cocoon-servlet-service-impl. It should be included in your cocoon-webapp dependencies by transitive dependency handling. It works for me. It might be that you need to clean and rebuild your cocoon-webapp or something. /Daniel Rice Yeh skrev: Hi, Running the latest code from trunk, I get an error as the title described. The following is the exception stack: Caused by: org.springframework.beans.factory.BeanCreationException: Error creati ng bean with name ' javax.servlet.http.HttpServletRequest /callstack': Initializat ion of bean failed; nested exception is org.springframework.aop.framework.AopCon figException: Couldn't generate CGLIB subclass of class [interface javax.servlet .http.HttpServletRequest]: Common causes of this problem include using a final c lass or a non-visible class; nested exception is net.sf.cglib.core.CodeGeneratio nException: java.lang.reflect.InvocationTargetException-- null ...
[jira] Created: (COCOON-2005) Cocoon's build broken due to invalid parent in cocoon-samples-style-default's pom
Cocoon's build broken due to invalid parent in cocoon-samples-style-default's pom - Key: COCOON-2005 URL: https://issues.apache.org/jira/browse/COCOON-2005 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski (aka g[R]eK) Priority: Blocker Fix For: 2.2-dev (Current SVN) While flattening poms it was missed to change parent pom of cocoon-samples-style-default module. Attached patch fixes this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2005) Cocoon's build broken due to invalid parent in cocoon-samples-style-default's pom
[ https://issues.apache.org/jira/browse/COCOON-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski (aka g[R]eK) updated COCOON-2005: -- Attachment: cocoon-samples-style-broken-pom.patch Cocoon's build broken due to invalid parent in cocoon-samples-style-default's pom - Key: COCOON-2005 URL: https://issues.apache.org/jira/browse/COCOON-2005 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski (aka g[R]eK) Priority: Blocker Fix For: 2.2-dev (Current SVN) Attachments: cocoon-samples-style-broken-pom.patch While flattening poms it was missed to change parent pom of cocoon-samples-style-default module. Attached patch fixes this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Rewriting links in js files
HI If you are using Dojo, it can already do this on the client. for instance : templatePath: dojo.uri.dojoUri(../viewr/templates/HtmlStory.html), Gives you a url relative to where Dojo loaded from. HTH regards Jeremy On 1 Feb 2007, at 23:13, Grzegorz Kossakowski wrote: Hi, Yes, it's me n-th time ;) I would like to discuss link rewriting in js files and other text resources (css for example). Obviosuly, soon or later, there will be need (actually it already is, in Forms) to store some paths in JS files. That means that we have to take care of rewriting links in this kind of resources. My proposal is to introduce new reader for this task. It would scan whole content of file for valid URLs to rewrite, and do the job. I think, it could be easily achieved by use of some regexps. Of course, this new reader would implement caching because rewriting of some big files would be quite time-consuming. I haven't looked into the code of LinkRewritingTransformer so I'm not sure if it's code could be reused. Even if I had to write it from scratch I'm enough motivated but need to be sure that my work is not waste of time. Do you have any thoughts? Other options? -- Grzegorz Kossakowski smime.p7s Description: S/MIME cryptographic signature
Re: Dojo paths problem
I think part of the problem is that I was unable to get the proper
sitemap glue working for Cocoon 2.2 as I was unable to run the samples.
This section in the root sitemap (same mechanism in 2.1.n) is
designed to handle dojo resources, allow you to register and serve
your own namespaces and override built-in libraries :
!--+
| Cocoon-provided client-side resources.
| Some block's jar files (e.g. Ajax Forms) include client-
side resources
| such as JavaScript, CSS and images. The system-level
pattern below
| fetches these resources, while allowing them to be
overridden if needed
| in the webapp's resources directory.
|
| Defining this pattern in the root sitemap avoids
duplicating it in subsitemaps,
| which reduces copy/pasting in application code and allows
better client-side
| caching by giving each resource a single URL.
|
| Furthermore, some Cocoon code such as the Forms-provided
XSLs assume that
| resources are available at that URL.
|
| The absolute path for these resources is
{request:contextPath}/_cocoon/resources
+--
map:match pattern=_cocoon/resources/*/**
map:select type=resource-exists
map:when test=resources/{1}/{2}
map:read src=resources/{1}/{2}/
/map:when
!-- For Cocoon development, read directly from source
directories
map:when test=../../src/blocks/{1}/resources/org/apache/
cocoon/{1}/resources/{2}
map:read src=../../src/blocks/{1}/resources/org/
apache/cocoon/{1}/resources/{2}/
/map:when
--
map:otherwise
map:read src=resource://org/apache/cocoon/{1}/resources/
{2}/
/map:otherwise
/map:select
/map:match
!-- mount Cocoon system pipelines (you may apply similar
overides to those above) --
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap uri-
prefix=_cocoon/system//
/map:when
!-- For Cocoon development, read directly from source
directories
map:when test=../../src/blocks/{1}/resources/org/apache/
cocoon/{1}/system/sitemap.xmap
map:mount src=../../src/blocks/{1}/resources/org/
apache/cocoon/{1}/system/sitemap.xmap uri-prefix=_cocoon/system/
{1}//
/map:when
--
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
On 1 Feb 2007, at 23:04, Grzegorz Kossakowski wrote:
Hello,
I'm still fighting with Dojo to get it working in refactored forms. My
main problem is that I want to split stuff into separate parts but it
seems that introduction of Dojo assumed that all js will be on similar
urls and relative paths would just work fine. While that was true with
old (_cocoon/*) way of loading resources it's not in refactored
environment.
We have our own namespace for our widgets and manifest.js registering
it. Dojo does not know about it, but is clever enough to guess
where is
it and load where required. However, in new way of loading block
resources of one block are completely separated from other block's
resource. While it's desired and one of my main aims it breaks dojo
guessing badly. Take a look:
http://localhost:/blocks-test/cocoon-ajax-impl/resources/forms/
manifest.js
http://localhost:/blocks-test/cocoon-ajax-impl/resources/forms.js
http://localhost:/blocks-test/cocoon-ajax-impl/resources/dojo/
__package__.js
Whereby manifest.js is stored under:
http://localhost:/blocks-test/cocoon-forms-impl/resources/forms/
manifest.js
Quick work-around was to tell dojo the path where manifest.js is
stored:
dojo.registerModulePath(forms,
servlet:forms:/resources/forms);!-- tell
dojo
how to find manifest registering our forms namespace --
This fixes problem described above but I'm sure it's dirty hack and
moreover another issues (path errors) arise really quickly.
What's best way to solve this kind of problems? Am I good guessing
that
assumption of relative paths has been made while introducing dojo?
Could some of those who has done this work actually speak on issues
described above? Jeremy? Bruno?
--
Grzegorz Kossakowski
smime.p7s
Description: S/MIME cryptographic signature
Re: [graphics] New version of masthead
Sylvain Wallez said the following on 6/2/07 08:49: Mo :-) Don't confuse your cows and your sheep. ;-) Collecting opinions is good, but we also need to define the decision process to avoid endless discussions and frustration in the end for those that may have the feeling the decision was imposed on them. +1 Having Thien and Helma making the final choice is fine if everybody knows it in advance. Thanks for the vote of confidence. I'm working with Thien now to fix some details. Bye, Helma
[continuum] BUILD ERROR: Ajax Block [modules]
Online report : http://cocoon.zones.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/3/buildId/1871 Build statistics: State: Error Previous State: Error Started at: Tue, 6 Feb 2007 12:56:15 + Finished at: Tue, 6 Feb 2007 12:56:27 + Total time: 11s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes reinhard flatting POM hierarchy /cocoon/trunk/blocks/cocoon-ajax/cocoon-ajax-impl/pom.xml /cocoon/trunk/blocks/cocoon-ajax/cocoon-ajax-sample/pom.xml /cocoon/trunk/blocks/cocoon-ajax/pom.xml Build Error: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Could not find Maven project descriptor. at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:108) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:64) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:273) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) at java.lang.Thread.run(Thread.java:534)
[continuum] BUILD ERROR: Cocoon samples styles [modules]
Online report : http://cocoon.zones.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/20/buildId/1873 Build statistics: State: Error Previous State: Error Started at: Tue, 6 Feb 2007 13:05:58 + Finished at: Tue, 6 Feb 2007 13:06:03 + Total time: 4s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes reinhard flatting POM hierarchy /cocoon/trunk/blocks/cocoon-samples-style/cocoon-samples-style-default/pom.xml /cocoon/trunk/blocks/cocoon-samples-style/pom.xml Build Error: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Could not find Maven project descriptor. at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:108) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:64) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:273) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) at java.lang.Thread.run(Thread.java:534)
Re: Dojo paths problem
Jeremy Quinn napisał(a): I think part of the problem is that I was unable to get the proper sitemap glue working for Cocoon 2.2 as I was unable to run the samples. This section in the root sitemap (same mechanism in 2.1.n) is designed to handle dojo resources, allow you to register and serve your own namespaces and override built-in libraries : snip/ The point is, while using servlet-service-fw there is *no* root sitemap handling all request. Request are handled by dispatcher servlet, instead. Given that, resources of forms should be absolutely separated from ajax's ones. We should not assume there is some root context path and we can calculate all relative paths against it. My latest patches remove this assumption but obviously breaks C2.1. Jemery, could you take a look at it and give your opinion if that changes could be incorporated into forms/ajax blocks and would not break 2.1 somehow? Thanks. PS. Latest changes to servlet-service-fw break my patches (they will not work anymore) but it could be easily fixed. I'm going to do it as soon as my Subclipse stops hanging on synchronization :( -- Grzegorz Kossakowski
[continuum] BUILD ERROR: Cocoon Apples Block [modules]
Online report : http://cocoon.zones.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/1874 Build statistics: State: Error Previous State: Error Started at: Tue, 6 Feb 2007 13:06:13 + Finished at: Tue, 6 Feb 2007 13:06:23 + Total time: 10s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes reinhard flatting POM hierarchy /cocoon/trunk/blocks/cocoon-apples/cocoon-apples-impl/pom.xml /cocoon/trunk/blocks/cocoon-apples/cocoon-apples-sample/pom.xml /cocoon/trunk/blocks/cocoon-apples/pom.xml Build Error: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Could not find Maven project descriptor. at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:108) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:64) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:273) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) at java.lang.Thread.run(Thread.java:534)
[continuum] BUILD ERROR: Core-samples Block [modules]
Online report : http://cocoon.zones.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/9/buildId/1875 Build statistics: State: Error Previous State: Error Started at: Tue, 6 Feb 2007 13:07:17 + Finished at: Tue, 6 Feb 2007 13:07:32 + Total time: 14s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes reinhard flatting POM hierarchy /cocoon/trunk/blocks/cocoon-core-sample/cocoon-core-additional-sample/pom.xml /cocoon/trunk/blocks/cocoon-core-sample/cocoon-core-main-sample/pom.xml /cocoon/trunk/blocks/cocoon-core-sample/pom.xml reinhard formatting /cocoon/trunk/blocks/cocoon-core-sample/cocoon-core-additional-sample/pom.xml /cocoon/trunk/blocks/cocoon-core-sample/cocoon-core-main-sample/pom.xml Build Error: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Could not find Maven project descriptor. at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:108) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:64) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:273) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) at java.lang.Thread.run(Thread.java:534)
[continuum] BUILD ERROR: Flowscript Block [modules]
Online report : http://cocoon.zones.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/12/buildId/1876 Build statistics: State: Error Previous State: Error Started at: Tue, 6 Feb 2007 13:07:34 + Finished at: Tue, 6 Feb 2007 13:07:38 + Total time: 3s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes reinhard flatting POM hierarchy /cocoon/trunk/blocks/cocoon-flowscript/cocoon-flowscript-impl/pom.xml /cocoon/trunk/blocks/cocoon-flowscript/pom.xml Build Error: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Could not find Maven project descriptor. at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:108) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:64) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:273) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) at java.lang.Thread.run(Thread.java:534)
[continuum] BUILD ERROR: Forms Block [modules]
Online report : http://cocoon.zones.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/14/buildId/1877 Build statistics: State: Error Previous State: Error Started at: Tue, 6 Feb 2007 13:07:38 + Finished at: Tue, 6 Feb 2007 13:08:12 + Total time: 33s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes reinhard flatting POM hierarchy /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/pom.xml /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-sample/pom.xml /cocoon/trunk/blocks/cocoon-forms/pom.xml Build Error: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Could not find Maven project descriptor. at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:108) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:64) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:273) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) at java.lang.Thread.run(Thread.java:534)
[continuum] BUILD ERROR: Template framework [modules]
Online report : http://cocoon.zones.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/17/buildId/1878 Build statistics: State: Error Previous State: Error Started at: Tue, 6 Feb 2007 13:08:12 + Finished at: Tue, 6 Feb 2007 13:08:34 + Total time: 21s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes reinhard flatting POM hierarchy /cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/pom.xml /cocoon/trunk/blocks/cocoon-template/cocoon-template-sample/pom.xml /cocoon/trunk/blocks/cocoon-template/pom.xml Build Error: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Could not find Maven project descriptor. at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:108) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:64) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:273) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) at java.lang.Thread.run(Thread.java:534)
Re: [graphics] New version of masthead - update
Guys, Thien did it again: - he changed the masthead, making it a bit smaller and darker. - he also added a search box and changed the color of apache cocoon to be more prominent. - he removed some tiles to make things look better at 800x600. - the green blocks are now moved also to make things look better at 800x600. - the green blocks are also a bit darker. - he added nice icons to the content. In short, I'm very happy with this result. Bye, Helma
Re: Switching to servlet-service-fw
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 6 Feb 2007, Reinhard Poetz wrote: - update your web.xml to use the new DispatcherServlet: servlet descriptionCocoon blocks dispatcher/description display-nameDispatcherServlet/display-name servlet-nameDispatcherServlet/servlet-name servlet-classorg.apache.cocoon.servletservice.DispatcherServlet/servlet-class load-on-startup1/load-on-startup /servlet Can we switch the web.xml the deployer plugin is using as well ? Ciao - -- 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.1 (GNU/Linux) iD8DBQFFyJPnLNdJvZjjVZARArRxAKCVuPKnx/RFZxpKa3xzxG2GSa3KgwCg9Lvv g7SV2fL8RL6YgN55fbewvOQ= =Lp/l -END PGP SIGNATURE-
Re: JIRA karma
Carsten Ziegeler wrote: Jason Johnston wrote: On Mon, 05 Feb 2007 16:21:14 +0100, Carsten Ziegeler [EMAIL PROTECTED] wrote: Jason Johnston wrote: Thanks Carsten. But does the change take a while to kick in, or should I see it immediately? I still see only the Feedback Required option under Available Workflow Actions. I presume I should be seeing some more options like a way to assign the issue to myself and to close it. It should work immediately. Can you assign the bug to yourself? (It should be below the Feedback Required link under the Operations section.) Nope... see http://people.apache.org/~jjohnston/jira.png for a screenshot. It seems that the user administration has changed with a newer version of Jira :( It should work now. It does indeed. Thank you Carsten.
Re: Switching to servlet-service-fw
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 6 Feb 2007, Reinhard Poetz wrote:
- update your web.xml to use the new DispatcherServlet:
servlet
descriptionCocoon blocks dispatcher/description
display-nameDispatcherServlet/display-name
servlet-nameDispatcherServlet/servlet-name
servlet-classorg.apache.cocoon.servletservice.DispatcherServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
Can we switch the web.xml the deployer plugin is using as well ?
We should, but I'm not sure if there isn't more to change than this.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [graphics] New version of masthead
Reinhard Poetz wrote: But before contininuing with further discusions we should clarify how we come to a final decision? My proposal: Everybody can share his thoughts/ideas about the design but the final decision is made by Thien and Helma. Is this okay for everybody? +1
Re: Switching to servlet-service-fw
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 6 Feb 2007, Reinhard Poetz wrote: Date: Tue, 06 Feb 2007 15:45:11 +0100 From: Reinhard Poetz [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Switching to servlet-service-fw Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 6 Feb 2007, Reinhard Poetz wrote: - update your web.xml to use the new DispatcherServlet: servlet descriptionCocoon blocks dispatcher/description display-nameDispatcherServlet/display-name servlet-nameDispatcherServlet/servlet-name servlet-classorg.apache.cocoon.servletservice.DispatcherServlet/servlet-class load-on-startup1/load-on-startup /servlet Can we switch the web.xml the deployer plugin is using as well ? We should, but I'm not sure if there isn't more to change than this. I do have a version here (see also patch from Felix recently) that seems to run just fine. I can commit it. Ciao - -- 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.1 (GNU/Linux) iD8DBQFFyJewLNdJvZjjVZARAi+3AKDhjaSjcanvX9PkBvxFm5Rm6BbI2wCguh+2 3QmD4e95Bqz3Bnbw6eqSraY= =qilT -END PGP SIGNATURE-
Re: [graphics] New version of masthead - update
OOPS now the link: http://people.apache.org/~hepabolu/final2.html Bye, Helma On 2/6/07, hepabolu [EMAIL PROTECTED] wrote: Guys, Thien did it again: - he changed the masthead, making it a bit smaller and darker. - he also added a search box and changed the color of apache cocoon to be more prominent. - he removed some tiles to make things look better at 800x600. - the green blocks are now moved also to make things look better at 800x600. - the green blocks are also a bit darker. - he added nice icons to the content. In short, I'm very happy with this result. Bye, Helma -- Bye, hepabolu
Re: [graphics] New version of masthead
On 2/5/07, Niclas Hedhman [EMAIL PROTECTED] wrote: On Tuesday 06 February 2007 00:22, Peter Hunsberger wrote: Very nice. I'm with the camp that would like to see it shrink a little, not much but just a little. Also, I still find it a little on the pastel side, I'd like to see a version with bolder colors. And I realize that asking developers for opinion on style and good taste is like asking sheep farmers to comment on Versace's latest designs; They are in the supply chain, but hardly the target audience... ;o) I wouldn't assume that; most of us have been working with the Cocoon web site for a long time now and there's a lot of talent in the development group. Personally, I grew up in a family of artists that also ran an art gallery so I realise that everyones opinions on any given piece of artistic content are going to vary widely. However, having been involved in web site design since it first became possible to be involved in web site design I do think we need to go through a limited critiquing process and that the development community is as good of source of opinions as any. Perhaps widening the audience to the user's lists is a good move. I'm not opposed, but I'm not sure that getting more opinions will help any? What value do you think they would add? -- Peter Hunsberger
Re: [graphics] New version of masthead - update
hepabolu wrote: OOPS now the link: http://people.apache.org/~hepabolu/final2.html I'm impressed - it works! http://people.apache.org/~vgritsenko/temp/screenshot98.png :-P Vadim On 2/6/07, hepabolu [EMAIL PROTECTED] wrote: Guys, Thien did it again: - he changed the masthead, making it a bit smaller and darker. - he also added a search box and changed the color of apache cocoon to be more prominent. - he removed some tiles to make things look better at 800x600. - the green blocks are now moved also to make things look better at 800x600. - the green blocks are also a bit darker. - he added nice icons to the content. In short, I'm very happy with this result. Bye, Helma
[jira] Assigned: (COCOON-2004) cocoon-block-deployer missed renaming of cocoon-block-fw
[ https://issues.apache.org/jira/browse/COCOON-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giacomo Pati reassigned COCOON-2004: Assignee: Giacomo Pati cocoon-block-deployer missed renaming of cocoon-block-fw Key: COCOON-2004 URL: https://issues.apache.org/jira/browse/COCOON-2004 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Giacomo Pati Priority: Critical Attachments: web.xml.diff cocoon-block-deployer-plugin missed renaming of cocoon-block-fw In the used web.xml is still the old class org.apache.cocoon.blocks.DispatcherServlet used which will result in a CNF exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2004) cocoon-block-deployer missed renaming of cocoon-block-fw
[ https://issues.apache.org/jira/browse/COCOON-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giacomo Pati closed COCOON-2004. Resolution: Fixed patch applied, thanks Felix cocoon-block-deployer missed renaming of cocoon-block-fw Key: COCOON-2004 URL: https://issues.apache.org/jira/browse/COCOON-2004 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht Assigned To: Giacomo Pati Priority: Critical Attachments: web.xml.diff cocoon-block-deployer-plugin missed renaming of cocoon-block-fw In the used web.xml is still the old class org.apache.cocoon.blocks.DispatcherServlet used which will result in a CNF exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [graphics] New version of masthead - update
On 2/6/07, hepabolu [EMAIL PROTECTED] wrote: OOPS now the link: http://people.apache.org/~hepabolu/final2.html Bye, Helma On 2/6/07, hepabolu [EMAIL PROTECTED] wrote: Guys, Thien did it again: - he changed the masthead, making it a bit smaller and darker. - he also added a search box and changed the color of apache cocoon to be more prominent. - he removed some tiles to make things look better at 800x600. - the green blocks are now moved also to make things look better at 800x600. - the green blocks are also a bit darker. - he added nice icons to the content. In short, I'm very happy with this result. I'm probably going to get dumped on for saying this, but I'd like to see the Cocoon logo on the left moved down about 2mm or so and maybe moved to the right about the same amount. This is so that it looks a little more balanced within the blocks and so that the blocks behind it are more clearly detached from the logo. This might not work, it could unbalance the rest of the design, but I'd sort of like to see what happens... However, I would certainly be very happy to see this as the final version, it's very good (once more). -- Peter Hunsberger
Re: [graphics] New version of masthead - update
Hi, On 6 Feb 2007, at 14:24, hepabolu wrote: Thien did it again: Awesome! Looks good ... but ... is that a page curl beside What is Apache Cocoon ? *shudder* Also, how would it look with Cocoon 2.1 somewhere in the top menubar too? Excellent work, though! Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Sourcesense: http://www.sourcesense.com/
Re: [graphics] New version of masthead
Peter Hunsberger said the following on 6/2/07 16:07: involved in web site design I do think we need to go through a limited critiquing process and that the development community is as good of source of opinions as any. +1 We need to agree on something that we all like, more or less. If you visit any project's website you get the end result whether you like it or not. In this case we have a choice, so we might get consensus. I'm not opposed, but I'm not sure that getting more opinions will help any? What value do you think they would add? I agree that asking for more opinions will only give you more _different_ opinions. I'd say the discussion about the new website design is a privilege of the committers. Bye, Helma
Re: Releasing from trunk
Reinhard Poetz wrote: As scheduled some weeks ago I want to ask for opinions about a next series of module releases. Here my proposal: - release cocoon-configuration-api and cocoon-spring-configuratur as 1.0 - release cocoon-core (+ all submodules) as RC1 - release the archetypes as RC1 - release cocoon-servlet-service as M1 - release cocoon-template and cocoon-forms as RC1 Releasing as RC or stable means that we don't change contracts anymore. Is this okay for the proposed modules? RC has a meaning of release candidate, which to most people means well tested almost production quality code. Going through recent commits I noticed a lot of refactoring, new code, untested code, and so on. This hardly qualifies as RC material. IMHO, it should be labeled as M(n+1). -1 on RC since code is not went through enough testing yet. Vadim
Re: [graphics] New version of masthead - update
Awesome! Looks good ... but ... is that a page curl beside What is Apache Cocoon ? *shudder* I suppose it is. I think it's very well done, no tackiness about it. What makes you shudder? Also, how would it look with Cocoon 2.1 somewhere in the top menubar too? True, that needs to be added. Bye, Helma
Re: [graphics] New version of masthead
On Feb 6, 2007, at 8:22 AM, hepabolu wrote: I agree that asking for more opinions will only give you more _different_ opinions. I'd say the discussion about the new website design is a privilege of the committers. Well maybe I can get a special dispensation, because IIRC this masthead revision was at my instigation... :-) I think it looks pretty good. Notes: 1) This latest version of the layout is robust w.r.t. window resizes (an improvement on the first one where the green boxes were floated). The new page does pretty well with the text scale-up test... no blowouts except in the green box content (at least, in Safari and Mozilla where I've tested). Don't know if you want to fix that or not...? 2) Would that page corner fold graphic be a link to more info? Seems like that's usually what it means... 3) W.r.t. the masthead itself... I meant to comment on this before, but never got to it until now so I understand if it's too late to do anything about it. Anyway, seeing it now in the context of a full web page strengthens my feeling about this design that the color palette is a little bit bland and boring. How about this... Thien, if you were to just take 3-4 of the blocks near the bottom-right corner of the block field — where that one block is sort of breaking away from the rest — and give them new colors outside of the blue shade scale used for the other blocks (I'm thinking purple, orange, bright green?) — that would break up the mum's kitchen tile effect and liven up the color scheme. How hard would that be to try? Just a suggestion from one of the sheep farmers :-) cheers, —ml—
Re: Releasing from trunk
Carsten Ziegeler wrote: Hmm, although I don't think that the latest changes have to be in the release, I think you have to redo the release anyway. Most files contain the old header and all releases require now the new header. I already updated the header for some sub projects but not for all. Dow! Is there a script i can use to update the headers? Jorg
continuum put offline
Hi, I've killed off the instance as obviously it can't cope with Reinhard's recent structural refactorings. I'll see about rebuilding in the next few weeks unless someone beats me to it. Jorg
[jira] Closed: (COCOON-2000) bug in saveXml function
[
https://issues.apache.org/jira/browse/COCOON-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Johnston closed COCOON-2000.
--
Resolution: Fixed
Assignee: Jason Johnston
Closing issue; thanks for the patch!
bug in saveXml function
---
Key: COCOON-2000
URL: https://issues.apache.org/jira/browse/COCOON-2000
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.10, 2.1.11-dev (Current SVN)
Reporter: Abbas Mousavi
Assigned To: Jason Johnston
Priority: Minor
when you use saveXml to save a form
to disk in flowscript this error happens
Serialization parameter {indent} must have the value yes or no
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Error creating bean with name 'javax.servlet.http.HttpServletRequest/callstack'
No. But I think this is a bug in the method setBeanFactory(..) of class org.springframework.aop.scope.ScopedProxyFactoryBean in springframeowrk 2.0.2. In the last line of this method, it is this.proxy = pf.getProxy(); ,where getProxy() is not passed a classloader. In the latest CVS version, the last line of the same method is this.proxy = pf.getProxy(cbf.getBeanClassLoader()); , where classloader is passed. Regards, Rice On 2/6/07, Daniel Fagerstrom [EMAIL PROTECTED] wrote: Any suggestion about what to do about it? /Daniel Rice Yeh skrev: I do have cglib-2.1_3.jar in the WEB/lib directory. By tracing the code, I find the classloader used in Enhancer is the classloder of javax.servlet.http.HttpServletRequest, which is an instance of org.codehaus.classworlds.RealmClassLoader . RealmClassLoader just include class path used in jetty, not include path in WEB/lib. Hence, an exception java.lang.NoClassDefFoundError: org/springframework/aop/scope /ScopedObject is thrown. Rice On 2/6/07, *Daniel Fagerstrom* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It looks like you are lacking the cglib. It is (since yesterday) part of the dependencies for cocoon-servlet-service-impl. It should be included in your cocoon-webapp dependencies by transitive dependency handling. It works for me. It might be that you need to clean and rebuild your cocoon-webapp or something. /Daniel Rice Yeh skrev: Hi, Running the latest code from trunk, I get an error as the title described. The following is the exception stack: Caused by: org.springframework.beans.factory.BeanCreationException : Error creati ng bean with name ' javax.servlet.http.HttpServletRequest /callstack': Initializat ion of bean failed; nested exception is org.springframework.aop.framework.AopCon figException: Couldn't generate CGLIB subclass of class [interface javax.servlet .http.HttpServletRequest]: Common causes of this problem include using a final c lass or a non-visible class; nested exception is net.sf.cglib.core.CodeGeneratio nException: java.lang.reflect.InvocationTargetException-- null ...
Problems with maven-war-plugin-2.0.1/2.0.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since yesterday I get the following error when trying to build my cocoon-2.2 application: [INFO] - [ERROR] BUILD ERROR [INFO] - [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war': Unable to find the mojo 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war' in the plugin 'org.apache.maven.plugins:maven-war-plugin' Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-war-plugin:2.0.1:war. Using the latest maven-war-plugin-2.0.2 (changing dependency version in tools/cocoon-block-deployer/cocoon-deployer-plugin/pom.xml) I can build my application again. Looking at the poms I saw that in the cocoons root pom.xml in the pluginManagement section the latest version is indicated. Why do we not use the dependencyManagement feature of maven as well to set dependency versions in the root pom. This would make things IMO easier to have the same version all over the place. Can we upgrade the version of the maven-war-plugin (dependency) in the cocoon-block-deployer to 2.0.2 as well? Regards Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFyXp22lZVCB08qHERAnUsAJ97UYGQHWjsFW6SC7I/eaIZfiNYRACgzIg5 yeh5XCadJ3mdjUOieyxws5A= =jbXC -END PGP SIGNATURE-
Re: Releasing from trunk
Jorg Heymans wrote: Carsten Ziegeler wrote: Hmm, although I don't think that the latest changes have to be in the release, I think you have to redo the release anyway. Most files contain the old header and all releases require now the new header. I already updated the header for some sub projects but not for all. Dow! Is there a script i can use to update the headers? I did it by hand...but there are scripts, have a look at: http://apache.org/legal/src-headers.html#faq Perhaps David can help as he did the conversion for Cocoon. Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: Releasing from trunk
Vadim Gritsenko wrote: RC has a meaning of release candidate, which to most people means well tested almost production quality code. Going through recent commits I noticed a lot of refactoring, new code, untested code, and so on. This hardly qualifies as RC material. IMHO, it should be labeled as M(n+1). -1 on RC since code is not went through enough testing yet. I really doubt that most of the code for final releases (or rc) is tested better than what we currently have in trunk. We do releases for 2.1.x without real tests for most of the code base. We rely on user experience/tests. The version from trunk is used by several of us already in production, several people have tried it out and it seems that most of the problems have been fixed. So I really think that this qualifies for an RC release. Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: Releasing from trunk
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
RC has a meaning of release candidate, which to most people means well tested
almost production quality code. Going through recent commits I noticed a lot of
refactoring, new code, untested code, and so on. This hardly qualifies as RC
material.
IMHO, it should be labeled as M(n+1). -1 on RC since code is not went through
enough testing yet.
I really doubt that most of the code for final releases (or rc) is
tested better than what we currently have in trunk. We do releases for
2.1.x without real tests for most of the code base. We rely on user
experience/tests. The version from trunk is used by several of us
already in production, several people have tried it out and it seems
that most of the problems have been fixed. So I really think that this
qualifies for an RC release.
Just wanted to write something similar. What we need now is more people who
use/try it and in this sense it doesn't help to ship more milestone releases.
I also think that it is an *important signal to us*: 2.2 is complete, the
contracts are stable and they can't be changed. The rest of the work is
polishing and writing documentation.
Yes guys, after almost 3 1/2 years we will ship something that isn't a patch
release!!!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: continuum put offline
Jorg Heymans wrote:
Hi,
I've killed off the instance as obviously it can't cope with Reinhard's
recent structural refactorings. I'll see about rebuilding in the next
few weeks unless someone beats me to it.
What needs to be done for a rebuild? I would remove all projects and create the
new ones based on the root pom. This create all our sub modules as Continuum
projects again, doesn't it?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
