Re: Cocoon trunk demos are down
On 1/25/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote: ...Are you sure? I could swear swear I was looking at them few days ago and there were working... http://cocoon.zones.apache.org/logs/cocoon-demos/trunk/stderr.log shows that the trunk demo tries to start the trunk using build.sh and cocoon.sh, and IIRC these stopped working a long time ago, replaced by the new Maven stuff. So, unless someone starts it by hand, the trunk demo cannot currenly work. -Bertrand
Re: Cocoon trunk demos are down
Bertrand Delacretaz napisał(a): On 1/24/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote: ...I would like to report that demos of trunk on zone are down... I don't think the trunk demo has been adapted to run with the current build, it's still trying to use the old ant build which obviously fails. Are you sure? I could swear swear I was looking at them few days ago and there were working... -- Grzegorz Kossakowski
Re: Continuation exception - 2.1.10 upgrade
hi Gary, would you confirm if the issue is similar to: http://issues.apache.org/jira/browse/COCOON-1579 Best Regards, Antonio Gallardo. Gary Larsen escribió: I apologize for the post to the dev list. I've been working at this strange behavior for two days and have run out of things to try. I'd appreciate any tips on how to locate or work around the problem. The first time in a session that a submit or action widget is clicked it throws a continuation exception due to currentCall in FOM_Cocoon.jsGet_request() being null. After that exception, the widget buttons work as expected. But, if I go to a form for the first time, hit the back button on the browser, and go to the form again, the buttons work OK! This has been working fine in 2.1.7 but I want to use newer xml libraries, hence the upgrade. I haven't been able to reproduce the exception in the samples, so I guess it's a config/initialize problem or the samples don't cover my form processing. My forms are processed with flow script and use binding. Is it possible the session is not being initialized properly? I found some cocoon sample flow script that used cocoon.createSession() but this appears not to be valid call. As a work around, is it possible to do a form.showForm() in background or just have it redirect to another matcher to simulate the browser back button? (my ignorance probably showing:-) Below are some details. Thanks for any pointers, Gary Exception occurs at this point in the sitemap: org.apache.cocoon.ProcessingException: Sitemap: error calling continuation at - file:/C:/work/netvisn-server/webapps/netvisn/sitemap.xmap:1103:64 ... Caused by: org.mozilla.javascript.WrappedException: Wrapped java.lang.NullPointerException (resource://org/apache/cocoon/forms/flow/javascript/Form.js#209) ... Caused by: java.lang.NullPointerException at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FO M_Cocoon.java:577) The only other thing unusual in the log is this exception at Tomcat shutdown: INFO [main] catalina.session.ManagerBase 2007-01-24 16:55:10,234 - Cannot serialize session attribute FOM JavaScript GLOBAL SCOPE/file:/C:/work/netvisn-server/webapps/netvisn/sitemap.xmap for session C35B93DAD99DB250D8394FA3CDEAB5E7 java.io.NotSerializableException: org.mozilla.javascript.LazilyLoadedCtor
Re: Cocoon trunk demos are down
On 1/24/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote: ...I would like to report that demos of trunk on zone are down... I don't think the trunk demo has been adapted to run with the current build, it's still trying to use the old ant build which obviously fails. I won't be able to improve this in the near future, if someone wants to do it I can help with the zone setup. If not, we'd better remove the links to that demo. -Bertrand
Continuation exception - 2.1.10 upgrade
I apologize for the post to the dev list. I've been working at this strange behavior for two days and have run out of things to try. I'd appreciate any tips on how to locate or work around the problem. The first time in a session that a submit or action widget is clicked it throws a continuation exception due to currentCall in FOM_Cocoon.jsGet_request() being null. After that exception, the widget buttons work as expected. But, if I go to a form for the first time, hit the back button on the browser, and go to the form again, the buttons work OK! This has been working fine in 2.1.7 but I want to use newer xml libraries, hence the upgrade. I haven't been able to reproduce the exception in the samples, so I guess it's a config/initialize problem or the samples don't cover my form processing. My forms are processed with flow script and use binding. Is it possible the session is not being initialized properly? I found some cocoon sample flow script that used cocoon.createSession() but this appears not to be valid call. As a work around, is it possible to do a form.showForm() in background or just have it redirect to another matcher to simulate the browser back button? (my ignorance probably showing:-) Below are some details. Thanks for any pointers, Gary Exception occurs at this point in the sitemap: org.apache.cocoon.ProcessingException: Sitemap: error calling continuation at - file:/C:/work/netvisn-server/webapps/netvisn/sitemap.xmap:1103:64 ... Caused by: org.mozilla.javascript.WrappedException: Wrapped java.lang.NullPointerException (resource://org/apache/cocoon/forms/flow/javascript/Form.js#209) ... Caused by: java.lang.NullPointerException at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FO M_Cocoon.java:577) The only other thing unusual in the log is this exception at Tomcat shutdown: INFO [main] catalina.session.ManagerBase 2007-01-24 16:55:10,234 - Cannot serialize session attribute FOM JavaScript GLOBAL SCOPE/file:/C:/work/netvisn-server/webapps/netvisn/sitemap.xmap for session C35B93DAD99DB250D8394FA3CDEAB5E7 java.io.NotSerializableException: org.mozilla.javascript.LazilyLoadedCtor
Re: Sprinifying CForms
Vadim Gritsenko skrev:
Daniel Fagerstrom wrote:
Vadim Gritsenko skrev:
Giacomo Pati wrote:
CFroms is utilizing lots of Avalon ServiceSelector and this hinders
extensibility of it as adding new Widget types etc. is becomming a
pain with config files in jars.
I've thought about a Spring version of a ServiceSelector to allow a
more flexible configuration and extensibility with a class like
class SpringServiceSelector implements BeanFactoryAware,
ServiceSelector
Eww :) Why do you need SpringServiceSelector? IMHO forms should be
just modified to obtain necessary dependencies directly from manager:
manager.lookup("o.a.c.f.f.WidgetDefinitionBuilder/form")
Eww ;) Why do you need lookup? IMHO we should use dependency injection:
Hint: ServiceManager is injected, or it should be.
BeanFactoryAware was mentioned above. But of course can the
ServiceManager be injected.
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.
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.
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:
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:
...
Then we have components like that use the widget components that
currently depends on selectors, they could be configured like this:
...
Where the BeanByIntefaceFactoryBean looks up the beans fulfilling a
certain interface as described above.
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. And yes, that is achievable by using the
BeanFactoryUtil.beansOfTypeIncludingAncestor
http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/beans/factory/BeanFactoryUtils.html.
/Daniel
Cocoon trunk demos are down
Hello, I would like to report that demos of trunk on zone are down. After taking a glance at logs[1] it seems that something got broken. http://cocoon.zones.apache.org/logs/cocoon-demos/trunk/stderr.log -- Grzegorz Kossakowski
Re: svn commit: r495859 - in /cocoon/trunk/core: cocoon-core/src/main/resources/org/apache/cocoon/ cocoon-store/cocoon-store-impl/ cocoon-store/cocoon-store-impl/src/main/java/org/apache/cocoon/compon
[EMAIL PROTECTED] wrote: POJOfied the cocoon-store-impl module. Needed to copy and adapt the MRUMemoryStore from Excalibur store to be able to POJOfy the DefaultStore and DefaultTransientStore. While adapting the MRUMemoryStore I commented away the instrumentation support as I don't know how it works. Should we support instrumentation and in that case should the Excalibur version be used? Excalibur instrumentation support was removed long time ago from the trunk. So no support for it is necessary. Vadim
Re: Extension of PropertiesFileModule
On Jan 24, 2007, at 5:35 AM, Nicole Hochleiter wrote: Hi, I need to extend the PropertiesFileModule (in fact I already have implemented my own Version of the class and use it). But I wonder if the community would like to have this extension in the project: instead of only reading one file to one name I read several files which can contain the same properties and the last one in the list is taken. This is interesting e.g. if you have a default.properties and a local.properties file where in the default you can define the default values and if a local installation needs to add specific properties or only specific values this can be configured in the local.properties which overwrite the default. 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—
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (91 issues) Subscriber: cocoon Key Summary COCOON-1988 Make cocoon-auth-samples working https://issues.apache.org/jira/browse/COCOON-1988 COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the blocks protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for "generator/reader already set" should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1955 [Patch] Allow shielded class loading for a single block https://issues.apache.org/jira/browse/COCOON-1955 COCOON-1954 [Patch] RequestProcessor swallows exceptions in blocks case https://issues.apache.org/jira/browse/COCOON-1954 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded https://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or XMLizable in JavaSelectionList https://issues.apache.org/jira/browse/COCOON-1915 COCOON-1914 Text as XMLizable in EmptySelectionList https://issues.apache.org/jira/browse/COCOON-1914 COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice https://issues.apache.org/jira/browse/COCOON-1899 COCOON-1898 [PATCH] XPatch support for maven-cocoon-deployer-plugin https://issues.apache.org/jira/browse/COCOON-1898 COCOON-1893 XML-Binding: Problem creating a new element https://issues.apache.org/jira/browse/COCOON-1893 COCOON-1887 Host selector should be case insensitive https://issues.apache.org/jira/browse/COCOON-1887 COCOON-1877 [PATCH] Pageable Repeater https://issues.apache.org/jira/browse/COCOON-1877 COCOON-1870 Lucene block does not store attributes when instructed so https://issues.apache.org/jira/browse/COCOON-1870 COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the rigth time with IE https://issues.apache.org/jira/browse/COCOON-1846 COCOON-1843 LDAPTransformer: add-entry tag doesn't work https://issues.apache.org/jira/browse/COCOON-1843 COCOON-1842 LDAPTransformer: ClassCastException with Binary fields https://issues.apache.org/jira/browse/COCOON-1842 COCOON-1838 Always use 3-digit version number https://issues.apache.org/jira/browse/COCOON-1838 COCOON-1810 [PATCH] JMSEventMessageListener does not work https://issues.apache.org/jira/browse/COCOON-1810 COCOON-1807 Workaround for IE Bug in https://issues.apache.org/jira/browse/COCOON-1807 COCOON-1794 [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding https://issues.apache.org/jira/browse/COCOON-1794 COCOON-1738 double-listbox problem in repeaters https://issues.apache.org/jira/browse/COCOON-1738 COCOON-1726 Implementation of Source that supports conditional GETs https://issues.apache.org/jira/browse/COCOON-1726 COCOON-1717 Use custom cache keys for caching uri coplets using input modules. https://issues.apache.org/jira/browse/COCOON-1717 COCOON-1703 A patch for caching fonts (fixes GDI issues), vertical text orientation, color code fix, prefered unit for margins and measure unit converter https://issues.apache.org/jira/browse/COCOON-1703 COCOON-1697 Allow request parameters to be used in "for (var k in h)" kind of Javascript Loops https://issues.apache.org/jira/browse/COCOON-1697 COCOON-1686 [PATCH] COCOON-1671 Form not binding when prefix in binding definition is unequal to that in the instance data for the same namespace. https://issues.apache.org/jira/browse/COCOON-1686 COCOON-1648 Add support for ISO8601 in I18nTransformer and Forms https://issues.apache.org/jira/browse/COCOON-1648 COCOON-1622 [PATCH] SendMailTransformer and HTML body https://issues.apache.org/jira/browse/COCOON-1622 COCOON-1618 [PATCH] SoapGenerator/Serializer for Axis Bl
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Hi Alex,
On Jan 24, 2007, at 5:10 AM, Alexander Klimetschek wrote:
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.
Right, but still... :-)
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.
The pom-updater is unsatisfactory for this because it still doesn't
really allow multiple builds of Cocoon to co-exist on my machine. At
best it just makes it slightly less tedious to set up the builds in the
first place, but still, installing either of the builds renders the
other unusable (until the other in turn is rebuilt).
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 with the reference build it or debug it and see "oh, this is
how it's supposed to work"... or, maybe sometimes I would see "ah, so
this is really broken in trunk, it's not the fault of my local
changes," etc. This is not possible right now, and I think it's the
hard-coded versions numbers that are standing in the way. If they were
implemented with properties, I could override them in a profile.
The other bad thing currently would be having local mods in my
development poms — if I'm going to submit a patch then I have to make
sure to strip out those local changes before generating the patch...
but that's not sustainable going forward because it defeats the purpose
of maintaining a local development branch, e.g. in svk. For you
committers it's no big, because you don't have to JIRA a patch and then
wait 'til when and if your patch gets accepted, you just commit it and
then you are in sync again. For other contributors it is harder, and
local development branches have the potential to make Cocoon
development tractable in the Mavenized world... but only if they work
:-/
I'm still pretty much a noob to the ways of Maven so bear with me for a
moment... but instead of inheriting in the aggregated project
poms, suppose (just for the sake of discussion!) that the root-level
pom defined a tree of parameters that is isomorphic to the project
hierarchy, like this:
2.2.whatever
${cocoon.version}
${cocoon.version.core}cocoon.version.core.cocoon-core>
${cocoon.version.core}cocoon.version.core.cocoon-pipeline>
.
.
${cocoon.version}
${cocoon.version.blocks}ks.ajax>
.
.
Each lower-level pom would use the appropriate ${cocoon.verision...}
property in setting its , and would similarly use these
properties to define s of its s. 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).
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
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.
So the question is, is there another way that can work like this idea,
but without the smelliness of the root pom having to contain details
about the whole hierarchy?
cheers,
—ml—
Re: [RT] Add schema validation for sitemap
Carsten Ziegeler wrote: I started writing an XML schema for our sitemap. You can find a first version in the 2.1.x branch at tools/src/sitemap-1.0.xsd. My idea is to add schema validation to our tree processor engine in trunk and validate a sitemap when it is read. Of course this will be configurable and can be turned off. I'm not interested in discussions whether XML schema is the best solution for validation. But I'm interested to hear if others think that this is a useful idea or not. As long as it is flexible enough to not die when it encounters unknown to it sitemap component (with unknown configuration syntax), +1. Vadim
Re: Artwork for cocoon.apache.org - next steps
Reinhard Poetz wrote: Isn't it possible to send in CCLA/ICLA documents as scanned documents either? I remember some disucussions some months ago but don't know what the outcome was. Does anybody know? Yes. PDFs via signed email are accepted since May. See email from Justin on board: Please remember that CLAs can be filed electronically now. You can send PGP/GPG-signed emails with the scanned PDFs of the signed CLA form to [EMAIL PROTECTED] and [EMAIL PROTECTED] This removes the need to fax or send physical mails of the CLA. I wonder why regular signed email is not mentioned... Vadim
Re: Sprinifying CForms
Daniel Fagerstrom wrote:
Vadim Gritsenko skrev:
Giacomo Pati wrote:
CFroms is utilizing lots of Avalon ServiceSelector and this hinders
extensibility of it as adding new Widget types etc. is becomming a
pain with config files in jars.
I've thought about a Spring version of a ServiceSelector to allow a
more flexible configuration and extensibility with a class like
class SpringServiceSelector implements BeanFactoryAware, ServiceSelector
Eww :) Why do you need SpringServiceSelector? IMHO forms should be
just modified to obtain necessary dependencies directly from manager:
manager.lookup("o.a.c.f.f.WidgetDefinitionBuilder/form")
Eww ;) Why do you need lookup? IMHO we should use dependency injection:
Hint: ServiceManager is injected, or it should be.
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
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:
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.
In short, I'm fine with any mechanism, as long as it is used consistently
throughout Cocoon.
Vadim
Extension of PropertiesFileModule
Hi, I need to extend the PropertiesFileModule (in fact I already have implemented my own Version of the class and use it). But I wonder if the community would like to have this extension in the project: instead of only reading one file to one name I read several files which can contain the same properties and the last one in the list is taken. This is interesting e.g. if you have a default.properties and a local.properties file where in the default you can define the default values and if a local installation needs to add specific properties or only specific values this can be configured in the local.properties which overwrite the default. Nicole
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. Alex 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 activation in my settings.xml and override the version property/ies, setting them uniquely for whatever local branch I'm building in. ??? —ml— -- Alexander Klimetschek http://www.mindquarry.com
Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
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 activation in my settings.xml and override the version property/ies, setting them uniquely for whatever local branch I'm building in. ??? —ml—
