Re: Extension of PropertiesFileModule
Mark Lundquist lundquist.mark at gmail.com writes: [...] Hi Nicole, In terms of the current code base, for overriding one properties file with another the most parsimonious solution is to instantiate a ChainMetaModule in cocoon.xconf. Declare it to chain two PropertiesFileModule instances — first the one for local.properties, then the one for default.properties. No new classes required But maybe it will be felt that supporting multiple properties files in a single output module is desirable — in that case, it might be better to just enhance PropertiesFileModule rather than add an additional class? cheers, —ml— Hi Mark, thanks for your answer and the hint with the ChainMetaModule. Since Cocoon is so big you sometimes don't see, that it already has a solution for your problem, like it is in my case. I didn't know the module and what it can do. But next time I will look for existing solution or ask the mailing list first. :-) Thanks, Nicole
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 24 Jan 2007, Alexander Klimetschek wrote: Date: Wed, 24 Jan 2007 14:10:53 +0100 From: Alexander Klimetschek [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven) I think the idea is to have separate release cycles and thus different versions for each block. So there is no general cocoon version any more, this version, like currently 2.2, only regards the core modules. But as we are having our own version of cocoon 2.2 including our patches during development, I know the problem of going through all poms and changing the version number... At least there is this pom-updater tool in tools/ which automatically modifies all poms. It can be modified quite easily (it's XSLT) to do other things with the version number. We've managed other projects with lots of module by the dependencyManagement section in the root pom where all dependencies are listed with version numbers. Module poms will thus never have a version defined in their dependencies. Ciao Mark Lundquist schrieb: On Jan 21, 2007, at 12:09 PM, Mark Lundquist wrote: I need to learn how to manage multiple local artifact sets in my Maven repo. I have *two* different trunk build areas on my machine under svk (my local mirror of the ASF repo, and a local development branch), but I haven't put all the pieces of that story together w.r.t. Maven... I think what is standing in my way right now is all the hard-coded version ids in poms. What's the deal with that? There are a handful of unique ones in trunk right now, there must be some reason why they are all hardcoded into the individual project poms instead of defined as properties in the root pom or the several intermediate parent poms... and I just don't know the reason? If they were properties, then I could trigger a profile using file activation in my settings.xml and override the version property/ies, setting them uniquely for whatever local branch I'm building in. - -- 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) iD8DBQFFuI35LNdJvZjjVZARAp4YAJ9MMR8ET0EocPLPu1KUtO1237UoZQCg8Gw8 agjaAlYsInzEzGJBtGSLCQE= =YmHx -END PGP SIGNATURE-
Re: cforms dojo updates: calendar, help and validation messages, multivalue editor
Hi Bruno Excellent work !! regards Jeremy On 21 Jan 2007, at 15:04, Bruno Dumon wrote: Hi, I've replaced the calendar, the help and validation message popups and the multi-value editor with dojo-based implementations. Thanks to Jeremy for upgrading to dojo 0.4, which made this possible and easier. For the first 3, these now use dojo's popup-things, which has the user-visible advantages of using a backing iframe in IE (so the popups are displayed on top of other input fields), correct positioning of the popups in IE, and at most one popup is open at the same time. Since validation messages are also displayed via these popups, any mixed content in them will now be preserved. For the calendar, it now supports date, time, and datetime selection, this is driven by the 'variant' attribute of the formatting date convertor. As before, the server-side date/time patterns are also also used on the client. The calendar is internationalized, for the precise supported languages see the dojo-languages parameter in form-field-styling.xsl. If anyone notices problems, feel free to fix or report them. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
RE: Continuation exception - 2.1.10 upgrade
Hi Antonio. Thanks for taking a look at this.
hi Gary, would you confirm if the issue is similar to:
http://issues.apache.org/jira/browse/COCOON-1579
The issue is similar in that I'm using a flow function and jx template with
a continuation. The behavior is reversed as my first continuation throws an
exception and after that the continuations work.
My exception is thrown at FOM_Cocoon.jsGet_request (rather than
FOM_Cocoon.jsGet_continuation) but my guess is that they are both due to
currentCall being null.
I'm using the rhino js-1.6R5.jar that installed with 2.1.10. (this is
another reason for upgrading to hopefully be able to install in WebLogic)
In case it's helpful the matchers and flow are below. Maybe a different
coding approach would work better?
I'm lost inside Cocoon code so any pointers on debugging this would be
helpful. I tried adding some debug logging in FOM_Cocoon but that didn't
help me.
Thanks,
Gary
map:match pattern=form/do-*
map:call function=handleForm
map:parameter name=function value=do_{1}/
map:parameter name=definitionURI
value=context://site/forms/definition/{1}Form.xml/
map:parameter name=bindingURI
value=context://site/forms/binding/{1}FormBinding.xml/
/map:call
/map:match
---
function do_netvisnAdministration(form) {
var appContext = cocoon.context.getAttribute(applicationContextKey);
var bean =
Packages.com.envisn.nv.form.BeanFactory.getNetVisnAdminForm(appContext);
form.load(bean);
form.showForm(form/display-netvisnAdministration);
.
---
map:match pattern=form/display-*
map:generate type=jx label=debug1
src=context://site/forms/template/{1}Template.xml/
map:transform type=forms label=content1/
map:call resource=simple-page2html label=content2
map:parameter name=file
value=context://site/forms/template/{1}Template.xml/
/map:call
map:transform
src=context://site/forms/resources/forms-samples-styling.xsl
label=content3/
map:serialize/
/map:match
map:match pattern=*.continue
map:call continuation={1}/
/map:match
Re: org.apache.cocoon:cocoon-maven-reports:jar:1.0 missing
Reinhard Poetz wrote: If not, we should vote on the rules. It will be a lot of fun to read dozens of mails about coding conventions ;-) Yet again? Give it a rest, follow the book [1]. Vadim http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
Re: Keys for cache are insufficient when using multiple block servlets
Daniel Fagerstrom wrote: Alexander Klimetschek skrev: Hi, when using multiple block-servlets in one cocoon application (2.2), they will all use the same EHDefaultStore as cache. If there are similar matchers in the sitemaps, eg. images/header.png, the key for the cached resource will be the same for both blocks (just images/header.png), and, as the cache is global, the same cached object will be returned for both requests. This happens with expires-caching. This should be fixed by adding a unique key prefix for each block-servlet or by one cache per block-servlet, but I do not know how to configure this. The Spring bean name for the block-servlet would work fine as an unique bean prefix. Prefix from parent sitemap used to be part of the key, IIRC. Works even better. And it is available from ServletConfig.getServletName() in the block-servlet. The next and more complicated question is how to get the identifier to the caching key ... ... or how to fix the regression. Vadim
Re: Sprinifying CForms
Daniel Fagerstrom wrote:
Vadim Gritsenko skrev:
Daniel Fagerstrom wrote:
void setWidgetDefinitionBuilders(Map wdbs) { this.wdbs=wdbs; }
...
this.wdbs.get(form);
Hint: this operation is map lookup. So you have replaced one lookup
from injected object with another lookup on another injected object.
Net result: no change. :-P
The important change is that Map not is container specific. You can use
the component by just filling a map and testing it. No container
dependency.
Indeed.
But thinking further on it, it doesn't matter that much in the
particular scenario of forms. It is only the various builder and manager
classes that use selectors. And they are not useful by them self anyway.
So DI and avoiding container dependencies makes much more sense for the
widgets than for the builder infra structure.
Well but, generally speaking, if you have container (especially dependency on
specific container implementation - like spring web context - instead of
dependency on base interface) and/or servlet API dependencies, it makes that
much harder writing JUnit tests.
And the map is provided by a factory bean that looks up all beans
that implements an interface and get the selector role from a property:
property name=widgetDefinitionBuilders
bean class=o.a.c...BeansByIntefaceFactoryBean
property name=inteface
value=o.a.c.f.f.WidgetDefinitionBuilder/
property name=roleAttribute value=role/
/bean
/property
This is *exactly* what we have now: nested declaration. And this is
*exactly* what causes the problem: there is no way to easily extend
standard configuration.
There should be a way to add declarations of new forms component as
stand alone spring beans, and forms should be able to pick them up. I
figure we just should re-use existing machinery used in the sitemap.
It certainly beats introduction of Yet Another Way To Lookup Components.
I guess my description was to terse. What I tried to describe is an
adaption of the whiteboard pattern from OSGi, that is used precisely for
allowing pluggable extensions.
The BeanByIntefaceFactoryBean above is not a nested dependency at all.
It is a factory bean that searches for all components in the container
that implements a certain interface. For each such component it looks up
the value of a property and then create a map that contains associations
between property values and the components.
A more complete example would be that we define a number of components,
that could be spread out in many independent blocks:
bean id=o.a.c.f.validation.WidgetValidatorBuilderSelector/length
class=o.a.c.f.validation.impl.LengthValidatorBuilder
property name=type value=length/
/bean
bean id=o.a.c.f.validation.WidgetValidatorBuilderSelector/range
class=o.a.c.f.validation.impl.RangeValidatorBuilder
property name=type value=range/
/bean
...
Then we have components like that use the widget components that
currently depends on selectors, they could be configured like this:
bean id=o.a.c.f.f.WidgetDefinitionBuilder/form
class=org.apache.cocoon.forms.formmodel.FormDefinitionBuilder
property name=type value=form/
property name=widgetValidatorBuilders
bean class=o.a.c...BeansByIntefaceFactoryBean
property name=inteface
value=o.a.c.f.f.WidgetValidatorBuilder/
/bean
/property
...
/bean
Where the BeanByIntefaceFactoryBean looks up the beans fulfilling a
certain interface as described above.
It is rather verbose, but yes, it does solve the problem.
But, again, in this particular case it is probably not worthwhile to
strive for complete DI. Implementing a Spring selector as Giacomo
described in the original mail is probably the simplest way to create
extendability.
My only concern - please use same lookup method consistently. Both sitemap
looking up generators/etc and forms manager looking up widgets should use same
mechanism.
Vadim
Re: Object pooling considered harmful
Daniel Fagerstrom wrote: What is this object pooling about? Once, long time ago, Java was really slow in creating and destroying objects ... Now with modern JVMs (1.2 and later), things has changed dramatically. Creation and destruction of objects is amazingly fast. A new Object() is about 10 machine instructions ... In Cocoon pooling was mostly for (relatively heavy) sitemap components. Problem is not memory allocation (new FooGenerator()) - this is the fastest part - problem lies in component lifecycle. If you combine costs of instance initialization, contextualization, configuration, setting service manager for a component, you'd arrive to much greater number. Granted, some of the sitemap components are trivial to create (e.g: StripNamespacesTransformer), but some others might take ages. There is no one size fits all solution, I'm afraid. If pooling is dropped completely, heavier sitemap components would have to be split up into back end components doing heavy lifting and front end components with simplified lifecycle. I18nTransformer could be thought of as an example of this pattern. It won't help though mid-weight components, whose fat is mostly located in the configure() method. Vadim
RE: Continuation exception - 2.1.10 upgrade
I just tried my application using 2.1.9 and the forms/continuations are working OK. This Cocoon version is using rhino1.5r4-continuations-R26.jar so I would like to move to 2.1.10 if possible. I'm not sure if this is a problem of my configuration/code compatibilty with 2.1.10 or possibly a bug in that version. Any suggestions on how a non-cocoon-dev person can track down this problem (if that's possible :-) would be great. Thanks, Gary hi Gary, would you confirm if the issue is similar to: http://issues.apache.org/jira/browse/COCOON-1579 The issue is similar in that I'm using a flow function and jx template with a continuation. The behavior is reversed as my first continuation throws an exception and after that the continuations work. My exception is thrown at FOM_Cocoon.jsGet_request (rather than FOM_Cocoon.jsGet_continuation) but my guess is that they are both due to currentCall being null.
Re: org.apache.cocoon:cocoon-maven-reports:jar:1.0 missing
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
If not, we should vote on the rules. It will be a lot of fun to read
dozens of mails about coding conventions ;-)
Yet again? Give it a rest, follow the book [1].
aren't you missing it? We haven't had a coding conventions discussion for months
(or even years)! :-p
Vadim
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
Carsten, in a previous mail you said that you used a stripped down version of
rules. But of what rules, the Sun rules that Vadim refers to? I assume you did
this because the Sun rules caused too many errors and warnings and made the
report unreadable, didn't it?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
applicationContext.xml not valid according to schema?
Hi, I can't start Cocoon 2.2, because the file WEB-INF/applicationContext.xml isn't valid. I get the following exception: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 30 in XML document from ServletContext resource [/WEB-INF/applicationContext.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. I really don't understand why this error occurs. The file is created by cocoon's webapp archetype, and I was able to run my application before today. If I open the file in Eclipse (using WTP's XML editor, it also notices the errors). Does anybody have any clue (I'm using spring 2.0.2, cocoon 2.2.0-M3-SNAPSHOT)? Thanks, Bart.
Re: applicationContext.xml not valid according to schema?
Bart Molenkamp wrote: Hi, I can't start Cocoon 2.2, because the file WEB-INF/applicationContext.xml isn't valid. I get the following exception: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 30 in XML document from ServletContext resource [/WEB-INF/applicationContext.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. I really don't understand why this error occurs. The file is created by cocoon's webapp archetype, and I was able to run my application before today. If I open the file in Eclipse (using WTP's XML editor, it also notices the errors). Does anybody have any clue (I'm using spring 2.0.2, cocoon 2.2.0-M3-SNAPSHOT)? The syntax you're using is outdated (I also have hard time to keep up lately). Your applicationContext.xml should state: beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:util=http://www.springframework.org/schema/util; xmlns:configurator=http://cocoon.apache.org/schema/configurator; xmlns:avalon=http://cocoon.apache.org/schema/avalon; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd http://cocoon.apache.org/schema/configurator http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.xsd http://cocoon.apache.org/schema/avalon http://cocoon.apache.org/schema/avalon/cocoon-avalon-1.0.xsd; !-- Activate Cocoon Spring Configurator -- configurator:settings/ !-- Configure Log4j -- bean name=org.apache.cocoon.spring.configurator.log4j class=org.apache.cocoon.spring.configurator.log4j.Log4JConfigurator scope=singleton property name=settings ref=org.apache.cocoon.configuration.Settings/ property name=resource value=/WEB-INF/cocoon/log4j.xml/ /bean !-- Activate Avalon Bridge -- avalon:bridge/ /beans no cocoon:settings/ anymore... -- Leszek
RE: applicationContext.xml not valid according to schema?
Thanks, I just found out myself while looking at the resources in the archetype... Thanks! Bart. -Oorspronkelijk bericht- Van: Leszek Gawron [mailto:[EMAIL PROTECTED] Verzonden: donderdag 25 januari 2007 16:29 Aan: dev@cocoon.apache.org Onderwerp: Re: applicationContext.xml not valid according to schema? Bart Molenkamp wrote: Hi, I can't start Cocoon 2.2, because the file WEB-INF/applicationContext.xml isn't valid. I get the following exception: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 30 in XML document from ServletContext resource [/WEB-INF/applicationContext.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. I really don't understand why this error occurs. The file is created by cocoon's webapp archetype, and I was able to run my application before today. If I open the file in Eclipse (using WTP's XML editor, it also notices the errors). Does anybody have any clue (I'm using spring 2.0.2, cocoon 2.2.0-M3-SNAPSHOT)? The syntax you're using is outdated (I also have hard time to keep up lately). Your applicationContext.xml should state: beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:util=http://www.springframework.org/schema/util; xmlns:configurator=http://cocoon.apache.org/schema/configurator; xmlns:avalon=http://cocoon.apache.org/schema/avalon; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd http://cocoon.apache.org/schema/configurator http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.xsd http://cocoon.apache.org/schema/avalon http://cocoon.apache.org/schema/avalon/cocoon-avalon-1.0.xsd; !-- Activate Cocoon Spring Configurator -- configurator:settings/ !-- Configure Log4j -- bean name=org.apache.cocoon.spring.configurator.log4j class=org.apache.cocoon.spring.configurator.log4j.Log4JConfigurator scope=singleton property name=settings ref=org.apache.cocoon.configuration.Settings/ property name=resource value=/WEB-INF/cocoon/log4j.xml/ /bean !-- Activate Avalon Bridge -- avalon:bridge/ /beans no cocoon:settings/ anymore... -- Leszek
Re: Continuation exception - 2.1.10 upgrade
Hi Gary, We hit the same issue last week. It is a bug in the new rhino jar. Same as you all our flow applications fails with the new rhino introduced in 2.1.10. We also spent 2 days trying to fix it inside the rhino code. Our work around after 2 days was to continue using rhino1.5r4-continuations-R26.jar. The latest cocoon revision using the later jar on subversion is 479984. Best Regards, Antonio Gallardo. Gary Larsen escribió: I just tried my application using 2.1.9 and the forms/continuations are working OK. This Cocoon version is using rhino1.5r4-continuations-R26.jar so I would like to move to 2.1.10 if possible. I'm not sure if this is a problem of my configuration/code compatibilty with 2.1.10 or possibly a bug in that version. Any suggestions on how a non-cocoon-dev person can track down this problem (if that's possible :-) would be great. Thanks, Gary hi Gary, would you confirm if the issue is similar to: http://issues.apache.org/jira/browse/COCOON-1579 The issue is similar in that I'm using a flow function and jx template with a continuation. The behavior is reversed as my first continuation throws an exception and after that the continuations work. My exception is thrown at FOM_Cocoon.jsGet_request (rather than FOM_Cocoon.jsGet_continuation) but my guess is that they are both due to currentCall being null.
RE: Continuation exception - 2.1.10 upgrade
It good to know it's not only me. I'll try the revision you suggested. Thanks again for help, Gary -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Thursday, January 25, 2007 10:52 AM To: dev@cocoon.apache.org Subject: Re: Continuation exception - 2.1.10 upgrade Hi Gary, We hit the same issue last week. It is a bug in the new rhino jar. Same as you all our flow applications fails with the new rhino introduced in 2.1.10. We also spent 2 days trying to fix it inside the rhino code. Our work around after 2 days was to continue using rhino1.5r4-continuations-R26.jar. The latest cocoon revision using the later jar on subversion is 479984. Best Regards, Antonio Gallardo. Gary Larsen escribió: I just tried my application using 2.1.9 and the forms/continuations are working OK. This Cocoon version is using rhino1.5r4-continuations-R26.jar so I would like to move to 2.1.10 if possible. I'm not sure if this is a problem of my configuration/code compatibilty with 2.1.10 or possibly a bug in that version. Any suggestions on how a non-cocoon-dev person can track down this problem (if that's possible :-) would be great. Thanks, Gary hi Gary, would you confirm if the issue is similar to: http://issues.apache.org/jira/browse/COCOON-1579 The issue is similar in that I'm using a flow function and jx template with a continuation. The behavior is reversed as my first continuation throws an exception and after that the continuations work. My exception is thrown at FOM_Cocoon.jsGet_request (rather than FOM_Cocoon.jsGet_continuation) but my guess is that they are both due to currentCall being null.
Re: org.apache.cocoon:cocoon-maven-reports:jar:1.0 missing
Reinhard Poetz wrote: Vadim Gritsenko wrote: Reinhard Poetz wrote: If not, we should vote on the rules. It will be a lot of fun to read dozens of mails about coding conventions ;-) Yet again? Give it a rest, follow the book [1]. aren't you missing it? We haven't had a coding conventions discussion for months (or even years)! :-p :) http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html Carsten, in a previous mail you said that you used a stripped down version of rules. But of what rules, the Sun rules that Vadim refers to? I assume you did this because the Sun rules caused too many errors and warnings and made the report unreadable, didn't it? My guess: he does not like Sun's whitespace policies :-P Vadim
Re: cforms dojo updates: calendar, help and validation messages, multivalue editor
Bruno Dumon napisał(a): Hi, I've replaced the calendar, the help and validation message popups and the multi-value editor with dojo-based implementations. Thanks to Jeremy for upgrading to dojo 0.4, which made this possible and easier. snip/ If anyone notices problems, feel free to fix or report them. I would like to ask if Forms are still supposed to work without JS enabled? If so there is an issue with validation errors, see [1]. I think it's quite easy to fix this particular issue (I can take care of it) but I would like to know about general guidelines. Also there is still issue with loading forms resources in C2.2, but it's topic for another thread. I'll start it now. -- Grzegorz Kossakowski
RE: Bug in cocoon-22-archetype-webapp? (was: applicationContext.xml not valid according to schema?)
I just hit the send button too early, sorry... I was looking at the archetype source, and saw that the configuration for log4j pointed to the file: /WEB-INF/cocoon/log4j.xml But the file isn't in /WEB-INF/cocoon, but just in /WEB-INF. This seems to cause an exception when starting the webapp... So, I think the file should be moved to the cocoon/ directory, or the applicationContext.xml should be updated. Bart. -Oorspronkelijk bericht- Van: Bart Molenkamp Verzonden: donderdag 25 januari 2007 16:39 Aan: dev@cocoon.apache.org Onderwerp: Bug in cocoon-22-archetype-webapp? (was: applicationContext.xml not valid according to schema?) Looking at the archetype, I see the configuration: -Oorspronkelijk bericht- Van: Bart Molenkamp Verzonden: donderdag 25 januari 2007 16:32 Aan: dev@cocoon.apache.org Onderwerp: RE: applicationContext.xml not valid according to schema? Thanks, I just found out myself while looking at the resources in the archetype... Thanks! Bart. -Oorspronkelijk bericht- Van: Leszek Gawron [mailto:[EMAIL PROTECTED] Verzonden: donderdag 25 januari 2007 16:29 Aan: dev@cocoon.apache.org Onderwerp: Re: applicationContext.xml not valid according to schema? Bart Molenkamp wrote: Hi, I can't start Cocoon 2.2, because the file WEB-INF/applicationContext.xml isn't valid. I get the following exception: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 30 in XML document from ServletContext resource [/WEB-INF/applicationContext.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. I really don't understand why this error occurs. The file is created by cocoon's webapp archetype, and I was able to run my application before today. If I open the file in Eclipse (using WTP's XML editor, it also notices the errors). Does anybody have any clue (I'm using spring 2.0.2, cocoon 2.2.0-M3-SNAPSHOT)? The syntax you're using is outdated (I also have hard time to keep up lately). Your applicationContext.xml should state: beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:util=http://www.springframework.org/schema/util; xmlns:configurator=http://cocoon.apache.org/schema/configurator; xmlns:avalon=http://cocoon.apache.org/schema/avalon; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd http://cocoon.apache.org/schema/configurator http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.xsd http://cocoon.apache.org/schema/avalon http://cocoon.apache.org/schema/avalon/cocoon-avalon-1.0.xsd; !-- Activate Cocoon Spring Configurator -- configurator:settings/ !-- Configure Log4j -- bean name=org.apache.cocoon.spring.configurator.log4j class=org.apache.cocoon.spring.configurator.log4j.Log4JConfigurator scope=singleton property name=settings ref=org.apache.cocoon.configuration.Settings/ property name=resource value=/WEB-INF/cocoon/log4j.xml/ /bean !-- Activate Avalon Bridge -- avalon:bridge/ /beans no cocoon:settings/ anymore... -- Leszek
Bug in cocoon-22-archetype-webapp? (was: applicationContext.xml not valid according to schema?)
Looking at the archetype, I see the configuration: -Oorspronkelijk bericht- Van: Bart Molenkamp Verzonden: donderdag 25 januari 2007 16:32 Aan: dev@cocoon.apache.org Onderwerp: RE: applicationContext.xml not valid according to schema? Thanks, I just found out myself while looking at the resources in the archetype... Thanks! Bart. -Oorspronkelijk bericht- Van: Leszek Gawron [mailto:[EMAIL PROTECTED] Verzonden: donderdag 25 januari 2007 16:29 Aan: dev@cocoon.apache.org Onderwerp: Re: applicationContext.xml not valid according to schema? Bart Molenkamp wrote: Hi, I can't start Cocoon 2.2, because the file WEB-INF/applicationContext.xml isn't valid. I get the following exception: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 30 in XML document from ServletContext resource [/WEB-INF/applicationContext.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. I really don't understand why this error occurs. The file is created by cocoon's webapp archetype, and I was able to run my application before today. If I open the file in Eclipse (using WTP's XML editor, it also notices the errors). Does anybody have any clue (I'm using spring 2.0.2, cocoon 2.2.0-M3-SNAPSHOT)? The syntax you're using is outdated (I also have hard time to keep up lately). Your applicationContext.xml should state: beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:util=http://www.springframework.org/schema/util; xmlns:configurator=http://cocoon.apache.org/schema/configurator; xmlns:avalon=http://cocoon.apache.org/schema/avalon; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd http://cocoon.apache.org/schema/configurator http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.xsd http://cocoon.apache.org/schema/avalon http://cocoon.apache.org/schema/avalon/cocoon-avalon-1.0.xsd; !-- Activate Cocoon Spring Configurator -- configurator:settings/ !-- Configure Log4j -- bean name=org.apache.cocoon.spring.configurator.log4j class=org.apache.cocoon.spring.configurator.log4j.Log4JConfigurator scope=singleton property name=settings ref=org.apache.cocoon.configuration.Settings/ property name=resource value=/WEB-INF/cocoon/log4j.xml/ /bean !-- Activate Avalon Bridge -- avalon:bridge/ /beans no cocoon:settings/ anymore... -- Leszek
Block resources in 2.2 (Forms in particular case)
Hello, I've tried Forms blocks using /core/cocoon-webapp block(?) lately and I've found that resources loading does not work. I would like to fix it but in the manner of using blocks-fw as it seems to be mature enough. It is, right? So my questions are: 1. Should block resources be served directly by block owning them? I mean, should request for some javascript files be dispatched (by blocks-fw dispatcher) directly to forms block and some matcher in there would catch up the request? 2. Or maybe always block that uses forms block should catch the request for resources and redirect them (by using some source from block-fw?) to the forms block? 3. What about paths? Are they supposed to be absolute? If not, which block (and phase of processing request) is responsible for link rewriting and what technique is advised? Thanks for any pointers, advices. I would like to say, that I'm going to document all these sort of things when I was confident enough myself. -- Grzegorz Kossakowski
Re: cforms dojo updates: calendar, help and validation messages, multivalue editor
Bruno Dumon napisał(a): On Thu, 2007-01-25 at 17:39 +0100, Grzegorz Kossakowski wrote: I think you forgot your [1] link. Sorry, here it goes: http://thread.gmane.org/gmane.text.xml.cocoon.user/59615 I'm aware that this particular problem has other reason that need to be fixed but this shows exactly what happens were there is no js. All the things I've changed were already Javascript based, so I see little problems there. It's of course possible to override the default XSLs to do something non-javascript based. I know, but AFAIR before dojo transition if js had failed to load validation still have been displayed. Or it wasn't the case then? What is more important, if there is any agreement on treating this kind of issues? Should we just require JS for Forms or try create html output that easily fallbacks if there is no js? Is it possible and worth the effort? -- Grzegorz Kossakowski
Re: cforms dojo updates: calendar, help and validation messages, multivalue editor
On Thu, 2007-01-25 at 18:34 +0100, Grzegorz Kossakowski wrote: Bruno Dumon napisał(a): On Thu, 2007-01-25 at 17:39 +0100, Grzegorz Kossakowski wrote: I think you forgot your [1] link. Sorry, here it goes: http://thread.gmane.org/gmane.text.xml.cocoon.user/59615 I'm aware that this particular problem has other reason that need to be fixed but this shows exactly what happens were there is no js. All the things I've changed were already Javascript based, so I see little problems there. It's of course possible to override the default XSLs to do something non-javascript based. I know, but AFAIR before dojo transition if js had failed to load validation still have been displayed. Or it wasn't the case then? Ah yes. That could be easily fixed by adding the validation error icon as part of the widget-defining element (i.e. the element that gets replaced by the dojo widget). What is more important, if there is any agreement on treating this kind of issues? Should we just require JS for Forms or try create html output that easily fallbacks if there is no js? Is it possible and worth the effort? Some stuff simply requires javascript (popups, datepickers, etc). But you're right that the validation error icon should always be displayed, even if the js fails to load. Not sure if you want more than this? -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: cforms dojo updates: calendar, help and validation messages, multivalue editor
On Thu, 2007-01-25 at 17:39 +0100, Grzegorz Kossakowski wrote: Bruno Dumon napisał(a): Hi, I've replaced the calendar, the help and validation message popups and the multi-value editor with dojo-based implementations. Thanks to Jeremy for upgrading to dojo 0.4, which made this possible and easier. snip/ If anyone notices problems, feel free to fix or report them. I would like to ask if Forms are still supposed to work without JS enabled? If so there is an issue with validation errors, see [1]. I think it's quite easy to fix this particular issue (I can take care of it) but I would like to know about general guidelines. Also there is still issue with loading forms resources in C2.2, but it's topic for another thread. I'll start it now. I think you forgot your [1] link. All the things I've changed were already Javascript based, so I see little problems there. It's of course possible to override the default XSLs to do something non-javascript based. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: Continuation exception - 2.1.10 upgrade
We also spent 2 days trying to fix it inside the rhino code. Our work around after 2 days was to continue using rhino1.5r4-continuations-R26.jar. The latest cocoon revision using the later jar on subversion is 479984. When I extracted this revision it looks like Tortoise extracted the trunk version of the blocks so I get compile errors: cocoon-block-forms-compile: Compiling 380 source files to C:\development\envisn\cocoon-2.1.10.479984\build\c ocoon\blocks\forms\dest C:\development\envisn\cocoon-2.1.10.479984\src\blocks\forms\java\org\apache\ coco on\forms\util\JavaScriptHelper.java:63: compileReader(org.mozilla.javascript.Scr iptable,java.io.Reader,java.lang.String,int,java.lang.Object) in org.mozilla.jav ascript.Context cannot be applied to (java.io.StringReader,java.lang.String,int, nulltype) script = ctx.compileReader(new StringReader(jsText), // in I guess I'll try 2.1.9 unless there is an easy way to get a revision where the blocks work also. Gary
Re: cforms dojo updates: calendar, help and validation messages, multivalue editor
Bruno Dumon napisał(a): On Thu, 2007-01-25 at 18:34 +0100, Grzegorz Kossakowski wrote: Ah yes. That could be easily fixed by adding the validation error icon as part of the widget-defining element (i.e. the element that gets replaced by the dojo widget). Could you take care of it or should I apply the patch? Some stuff simply requires javascript (popups, datepickers, etc). But you're right that the validation error icon should always be displayed, even if the js fails to load. Not sure if you want more than this Let it be that only basic functionality should work without JS, the rest that makes Forms intriguing demands JS working properly, dot. I'm fine with that. Also thanks for your effort, new dojo-based widgets rock! :) -- Grzegorz Kossakowski
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
On Jan 25, 2007, at 3:01 AM, Giacomo Pati wrote: On Wed, 24 Jan 2007, Alexander Klimetschek wrote: But as we are having our own version of cocoon 2.2 including our patches during development, I know the problem of going through all poms and changing the version number... At least there is this pom-updater tool in tools/ which automatically modifies all poms. It can be modified quite easily (it's XSLT) to do other things with the version number. We've managed other projects with lots of module by the dependencyManagement section in the root pom where all dependencies are listed with version numbers. Module poms will thus never have a version defined in their dependencies. For the standard case (not my local branch problem), I think dependencyManagement could be used and we could get rid of the pom-updater. At first I (Maven noob) thought it wouldn't work because Cocoon is no longer a monolithic project, i.e. a person should be able to do an isolated checkout of a block and build and develop on it, without having all of trunk checked out. But then I realized (d'oh!) that the root pom and other aggregating poms are in artifacts that will be fetched into the local maven repo, they don't have to be built locally. So, it looks like using the standard dependencyManagement instead of custom pom-updater is using the right tool for the right job, WDOT? Now can we please get back to talking about my local branch problem? :-) dependencyMangement of course does not help me, because the only things you can set in an ad hoc local profile are repository locations and properties. Everything else was deemed too dangerous [1] by the Maven developers, because it militates against build reproducibility (they call it portability). IMHO, that was a bad decision and the wrong solution to the reproducibility problem! How can I have multiple local builds of the same artifact coexisting on my machine, without modifying any Subversion-controlled resources (e.g. poms)? That's the question. I'm in need of some brilliant ideas here, does somebody have any? thx, —ml— [1] http://maven.apache.org/guides/introduction/introduction-to- profiles.html
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Mark Lundquist schrieb: dependencyMangement of course does not help me, because the only things you can set in an ad hoc local profile are repository locations and properties. Everything else was deemed too dangerous [1] by the Maven developers, because it militates against build reproducibility (they call it portability). IMHO, that was a bad decision and the wrong solution to the reproducibility problem! Full ACK. When I read about what you can put in a profile and what not, I was thinking the same thing. They should have simply allowed it, but with a big warning sign in the documentation to not use it the wrong way... How can I have multiple local builds of the same artifact coexisting on my machine, without modifying any Subversion-controlled resources (e.g. poms)? That's the question. I'm in need of some brilliant ideas here, does somebody have any? What's with the properties idea you suggested? Put properties for all child-pom-versions in the root pom and overwrite them in your profile. Alex -- Alexander Klimetschek http://www.mindquarry.com
Re: Keys for cache are insufficient when using multiple block servlets
I just wrote a pipeline that fixes my other problem [1] (by selecting
between two different pipelines based on the actual running mode) and
included this fix for the caching key which works fine. I have to pass
through each of the ProcessingPipeline methods anyway and in each call
that has the Environment as parameter I change the uri prefix set in it:
private void fixEnvironmentForCachingPrefix(Environment env) {
if (this.fixMissingCachingPrefixWithBlockServlets
(env.getURIPrefix() == null || env.getURIPrefix().equals())) {
ServletContext context =
BlockCallStack.getCurrentBlockContext();
if (context instanceof BlockContext) {
// use the mount path of the block as the prefix
String mountPath =
((BlockContext) context).getMountPath() + /;
env.setURI(mountPath, env.getURI());
}
}
}
The trick is using the static method
BlockCallStack.getCurrentBlockContext() and using the mount path as a
unique and short URI prefix, which is then used by the caching pipeline
implemenations. You are free to consider it as a dirty hack ;-)
Alex
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116957460020578w=2
Vadim Gritsenko schrieb:
Daniel Fagerstrom wrote:
Alexander Klimetschek skrev:
Hi,
when using multiple block-servlets in one cocoon application (2.2),
they will all use the same EHDefaultStore as cache. If there are
similar matchers in the sitemaps, eg. images/header.png, the key for
the cached resource will be the same for both blocks (just
images/header.png), and, as the cache is global, the same cached
object will be returned for both requests. This happens with
expires-caching.
This should be fixed by adding a unique key prefix for each
block-servlet or by one cache per block-servlet, but I do not know
how to configure this.
The Spring bean name for the block-servlet would work fine as an
unique bean prefix.
Prefix from parent sitemap used to be part of the key, IIRC. Works even
better.
And it is available from ServletConfig.getServletName() in the
block-servlet. The next and more complicated question is how to get
the identifier to the caching key ...
or how to fix the regression.
Vadim
--
Alexander Klimetschek
http://www.mindquarry.com
Re: cforms dojo updates: calendar, help and validation messages, multivalue editor
On Thu, 2007-01-25 at 19:02 +0100, Grzegorz Kossakowski wrote: Bruno Dumon napisał(a): On Thu, 2007-01-25 at 18:34 +0100, Grzegorz Kossakowski wrote: Ah yes. That could be easily fixed by adding the validation error icon as part of the widget-defining element (i.e. the element that gets replaced by the dojo widget). Could you take care of it or should I apply the patch? I could have a look at it in the weekend, but a patch is welcome. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Mark Lundquist wrote:
What I'm trying to have is (a) a reference build of trunk that does
not have any of my local fingerprints on it, and (b) a local development
build (or even, potentially, more than one of those). Then I can play
How about having 2 local repositories ? Put a settings.xml in your
reference checkout and invoke maven using -s settings.xml. Do the same
for your local dev checkout and make sure that the localRepository
element [1] in both is different.
Each lower-level pom would use the appropriate ${cocoon.verision...}
property in setting its version, and would similarly use these
properties to define versions of its dependencys. If e.g. trunk
development requires, say, that some level have a different version
number, then it would be changed at that level in the root pom's tree of
version property definitions. (I'm talking about controlled changes in
Subversion here, not local changes). (Note, there would be no more need
for the pom-updater in this scheme).
sure.
Now, this breaks good design because the root pom has to know details
about the whole project tree, which countervails decomposition by
hierarchal project aggregation. But... it does allow me to have
countervailing decomposition by hierarchical project aggregation, mind
if i use that one in my next presentation to senior management? :P
multiple builds that can coexist because they do not create artifact
clashes in my local maven repo, because I can trigger a build profile
that overrides whichever version properties I require to be unique for
that build.
Mark, i think you have a lot of great ideas about improving our build.
At this point i cannot say whether any of them will fully work, you
should just try it out a bit and report back.
Maven2 is not bug-free by any means, and some of its advertised ways of
how it should work (eg dependencyManagement) simply don't. For
example, my experience with version properties in the root pom is that
the variable interpolation on artifact deployment time is buggy. Perhaps
this has been fixed already, if so then great but everyone will need to
upgrade to 2.0.5-SNAPSHOT for it to work. Also, if you cram the
dependencies of 100+ modules and their version numbers in the root pom
then this can become a management bottleneck as well as this pom will
need to be managed and included in the release process of every module.
Regards
Jorg
[1] http://maven.apache.org/settings.html
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
On Jan 25, 2007, at 11:46 AM, Jorg Heymans wrote: countervailing decomposition by hierarchical project aggregation, mind if i use that one in my next presentation to senior management? :P Ha Jorg, I *challenge* you to slip it in somewhere into your very next presentation to senior management, whatever that may be! :-) :-) —ml—
Re: Sprinifying CForms
Vadim Gritsenko skrev: Daniel Fagerstrom wrote: Vadim Gritsenko skrev: Daniel Fagerstrom wrote: ... A more complete example would be that we define a number of components, that could be spread out in many independent blocks: bean id=o.a.c.f.validation.WidgetValidatorBuilderSelector/length class=o.a.c.f.validation.impl.LengthValidatorBuilder property name=type value=length/ /bean bean id=o.a.c.f.validation.WidgetValidatorBuilderSelector/range class=o.a.c.f.validation.impl.RangeValidatorBuilder property name=type value=range/ /bean ... Then we have components like that use the widget components that currently depends on selectors, they could be configured like this: bean id=o.a.c.f.f.WidgetDefinitionBuilder/form class=org.apache.cocoon.forms.formmodel.FormDefinitionBuilder property name=type value=form/ property name=widgetValidatorBuilders bean class=o.a.c...BeansByIntefaceFactoryBean property name=inteface value=o.a.c.f.f.WidgetValidatorBuilder/ /bean /property ... /bean Where the BeanByIntefaceFactoryBean looks up the beans fulfilling a certain interface as described above. It is rather verbose, but yes, it does solve the problem. It is verbose, but using the xml extension mechanism in Spring 2.0 we could create a shorter notation as e.g.: bean id=o.a.c.f.f.WidgetDefinitionBuilder/form class=org.apache.cocoon.forms.formmodel.FormDefinitionBuilder property name=type value=form/ property name=widgetValidatorBuilders selector:interface=o.a.c.f.f.WidgetValidatorBuilder/ ... /bean Or even shorter by parsing the bean id for /form, don't think it is such a good idea to parse ids though. /Daniel
Re: Object pooling considered harmful
Vadim Gritsenko skrev: Daniel Fagerstrom wrote: What is this object pooling about? Once, long time ago, Java was really slow in creating and destroying objects ... Now with modern JVMs (1.2 and later), things has changed dramatically. Creation and destruction of objects is amazingly fast. A new Object() is about 10 machine instructions ... In Cocoon pooling was mostly for (relatively heavy) sitemap components. Problem is not memory allocation (new FooGenerator()) - this is the fastest part - problem lies in component lifecycle. If you combine costs of instance initialization, contextualization, configuration, setting service manager for a component, you'd arrive to much greater number. Sure, but these life cycles steps is much cheaper for a Spring managed bean that uses prototype scope than for an ECM managed single threaded component. For a Spring managed bean in prototype scope the configuration is only needed to be parsed once at container setup time while the configuration needs to be traversed at every component creation for Avalon components that are single threaded. Likewise for service lookup and contextualization. Of course some components might still be so heavy to create that pooling is worthwhile. But compiler development together with that Spring framework works differently than ECM, changes the situation so that many components that many components that were worthwhile to manage with a pool once, is much cheaper to recreate today. Granted, some of the sitemap components are trivial to create (e.g: StripNamespacesTransformer), but some others might take ages. There is no one size fits all solution, I'm afraid. If pooling is dropped completely, heavier sitemap components would have to be split up into back end components doing heavy lifting and front end components with simplified lifecycle. I18nTransformer could be thought of as an example of this pattern. It won't help though mid-weight components, whose fat is mostly located in the configure() method. There is no reason to drop pooling for Avalon components as we have an implementation of pooling in the Avalon-Spring bridge. For the components that we convert to Spring managed POJOs, it is in general better to try to rewrite them as you describe above as pooling doesn't fit well together with the way the Spring framework works. /Daniel
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
On Jan 25, 2007, at 11:46 AM, Jorg Heymans wrote: How about having 2 local repositories ? Put a settings.xml in your reference checkout and invoke maven using -s settings.xml. Do the same for your local dev checkout and make sure that the localRepository element [1] in both is different. LOL, Reinhard suggested the same thing earlier on in this thread. I might end up trying to do it this way temporarily, if that's what it takes to get some work done. The main problem with it is that because it's not location-dependent, it's not set-and-forget, which means it's not foolproof, which means that ML is guaranteed to cock it up within the first 24 hours (either through confusion or sheer forgetfulness) :-/ It's also kind of a heavy-handed kluge that goes against the spirit of Maven (IMHO alternative local repo locations should only be used for testing purposes), but that's a secondary issue... Maven2 is not bug-free by any means, and some of its advertised ways of how it should work (eg dependencyManagement) simply don't. For example, my experience with version properties in the root pom is that the variable interpolation on artifact deployment time is buggy. Perhaps this has been fixed already, if so then great but everyone will need to upgrade to 2.0.5-SNAPSHOT for it to work. Right, and I realize that Maven 2 is a work in progress. In spite of that, and even though it gets harshed on by a lot of people in the Java world, I think the Mavenization of Cocoon will turn out to have been one of the best decisions for Cocoon ever. That and the Springification... so 2.2 is really something to hang your hat on. Many thx to all you guys for all the great work. Anyway [ahem]... Maven may not be perfect yet, but like Eric Raymond said, all bugs are shallow given enough eyeballs, and there are a lot of eyeballs on Maven right now, so I think it will get better. Also, if you cram the dependencies of 100+ modules and their version numbers in the root pom then this can become a management bottleneck as well as this pom will need to be managed and included in the release process of every module. Yes — a pain. I don't like centralizing this. Anyway, w.r.t. while there may yet be a role for dependencyManagement in our build system, it looks to me like it does not help with the intra-project dependencies, because it only addresses the dependent side and not the installing side. The reference [1] doesn't say anything about dependencyManagement affecting the version of any artifact being built. It just says anybody that uses artifact Foo, you get version XYZ of it. If I'm actually building Foo though, this doesn't make it build version XYZ, it still builds whatever its project/version says. cheers, —ml—
Re: Block resources in 2.2 (Forms in particular case)
Grzegorz Kossakowski skrev: Hello, I've tried Forms blocks using /core/cocoon-webapp block(?) lately and I've found that resources loading does not work. Are you using it the standard way: http://localhost:/blocks/cocoon-forms-sample/ or are you using it through the blocks-fw? In the former case resource loading seems to work for me. I would like to fix it but in the manner of using blocks-fw as it seems to be mature enough. It is, right? It should be stable enough, although I'm working on changing the naming as discussed in http://marc.theaimsgroup.com/?t=11673185421r=1w=2. But that will only change some names for the user, so it will be easy to adapt any work that you start to the new naming. So my questions are: 1. Should block resources be served directly by block owning them? I mean, should request for some javascript files be dispatched (by blocks-fw dispatcher) directly to forms block and some matcher in there would catch up the request? In most cases this should be the best solution. 2. Or maybe always block that uses forms block should catch the request for resources and redirect them (by using some source from block-fw?) to the forms block? This requires more work and means less separation of concern as the using block must know and repeat the resource handling of the used block. But in cases where you want the used block to be internal only, (i.e. not mounted on any path and just usable through the block protocol or named dispacther), alternative 2. is the best option. 3. What about paths? Are they supposed to be absolute? It makes the the using block slightly less reusable, as it assumes that the used block is mounted at specific position. But for a normal application that not is supposed to be reused in other, unknown, applications, it is OK to use absolute paths for resources (relative to the context though). If not, which block (and phase of processing request) is responsible for link rewriting and what technique is advised? You can use the block-path module together with the LinkRewriterTransformer in the linkrewriter block. A setup like: map:transformer name=linkrewriter src=org.apache.cocoon.transformation.LinkRewriterTransformer link-attrshref src/link-attrs schemesblock/schemes /map:transformer have worked before, but I haven't tested for a while. It would simplify use to have a special purpose transformer or maybe even a servlet filter, that took care about the rewriting. Thanks for any pointers, advices. I would like to say, that I'm going to document all these sort of things when I was confident enough myself. Great. What I wrote above is my preliminary thoughts. More use is needed before we can have any more authoritative best practice. It would be interesting to hear about the thoughts from other people who are using the blocks-fw. /Daniel
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
On Jan 25, 2007, at 11:12 AM, Alexander Klimetschek wrote: Mark Lundquist schrieb: dependencyMangement of course does not help me, because the only things you can set in an ad hoc local profile are repository locations and properties. Everything else was deemed too dangerous [1] by the Maven developers, because it militates against build reproducibility (they call it portability). IMHO, that was a bad decision and the wrong solution to the reproducibility problem! Full ACK. When I read about what you can put in a profile and what not, I was thinking the same thing. They should have simply allowed it, but with a big warning sign in the documentation to not use it the wrong way... Well, I've been studying this some more, and I think that even if dependencyManagement were overridable within an external profile, it would not be enough (see my recent reply to Jorg)... How can I have multiple local builds of the same artifact coexisting on my machine, without modifying any Subversion-controlled resources (e.g. poms)? That's the question. I'm in need of some brilliant ideas here, does somebody have any? What's with the properties idea you suggested? Put properties for all child-pom-versions in the root pom and overwrite them in your profile. It's just sort of disgusting :-/. I think it would work, but... there are like 248 poms in Cocoon, up to 4 levels deep. I doubt we really want to mirror that structure in the root pom. This would have to be kept in sync with the source tree at all times, even for local changes, and that introduces new friction for refactoring efforts, or even just adding a new block. Also, modules will go away and people will forget to delete the corresponding properties from the root pom, so it will get cluttered with obsolete stuff. As I was thinking about this, at one point just a bit ago it seemed to me that this really cries out for IOC for poms! I was thinking, what if your external profile could intercept any pom in the build and override something therein? Then I started looking through the pom elements, and it appears the only thing that's at all reasonable to override on an ad hoc basis (i.e. without touching controlled files like poms) is the version id for subprojects. I also realized that I was too liberal in my criticism of the Maven approach to ad hoc profiles, because this is a very legitimate measure to preserve build reproducibility in the committer = repository direction. Everything else in the pom would break reproducibility under local overriding, but this one thing does not: the version id to use for (a) building module X and (b) for satisfying dependencies on X within this top-level project. So we don't need or want a general-purpose IOC here. What we need is a very specific profile-driven mechanism in Maven for addressing the specific problem of allowing multiple coexisting project builds on one machine so as to not result in artifact clashes in the repository. That's it. A very quick and dirty workaround would be to for Maven to introduce a localRepository element (a la settings.xml) in an external profile. It's un-Maveny and inelegant, but it would be relatively easy and low-risk. cheers, —ml—
Re: org.apache.cocoon:cocoon-maven-reports:jar:1.0 missing
On Friday 26 January 2007 00:26, Vadim Gritsenko wrote: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html My guess: he does not like Sun's whitespace policies :-P Code convention written by vi and emacs nerds of the 80s, with 80x24 character VT100 terminals, really sux... Saving screen real-estate is not a concern anymore. Readability is. But change in this field is like mass conversion of religious devotees... ;o) Cheers Niclas
