Re: svn commit: r407477 - in /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/util: ./ log/
Vadim Gritsenko wrote: So you are saying it is still possible to log to LogKit, but it won't be feature complete / backwards compatible with 2.1? Hm... Yepp, if people think it's worth having this, I would suggest to add an own module just for the logkit stuff. The core should have as less dependencies as possible. Just to satisfy curiosity, is there a log4j support for Cocoon log format? (looking at .../core/cocoon-webapp/src/main/webapp/WEB-INF/log4j.xconf, I'd guess that the answer is 'no'). Yepp, you're right. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: svn commit: r413889 - /cocoon/trunk/README.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 13 Jun 2006, Vadim Gritsenko wrote: Jorg Heymans wrote: [EMAIL PROTECTED] wrote: + +You may need anywhere from 5 minutes to 4 hours for this step to +complete. + Unless you want absolutely nobody to try the new build I suggest you remove this witty comment. It's not witty, it's factual. Giacomo recently reported that it can be in as little as 5 minutes. Yes, with all the artifacts already downloaded. And as we all know download can be very slow. I think this make the very wide span of 5 mins to 4 h and could be explained (which I did right now). Why not insert a few lines describing how to change the primary mirror Please do, especially since you know how. +1 like i suggested to you yesterday [1] ? That would convey a much more positive message. The mirror you suggested seems to be noticeably slower than default. IIRC the mirror was mentione for European locations. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEj8PTLNdJvZjjVZARAsWJAKDpxnQzi3K13BwrPTHgwL4VBuxpdgCgqzAe QT/aQbNjbfPt/5eTH/K9mzk= =hHyL -END PGP SIGNATURE-
[jira] Subscription: COCOON-open-with-patch
Issue Subscription
Filter: COCOON-open-with-patch (82 issues)
Subscriber: cocoon
Key Summary
COCOON-1862 HSQLDB improper shutdown
http://issues.apache.org/jira/browse/COCOON-1862
COCOON-1861 Check for Null URI in LDAPTransformer
http://issues.apache.org/jira/browse/COCOON-1861
COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the
rigth time with IE
http://issues.apache.org/jira/browse/COCOON-1846
COCOON-1843 LDAPTransformer: add-entry tag doesn't work
http://issues.apache.org/jira/browse/COCOON-1843
COCOON-1842 LDAPTransformer: ClassCastException with Binary fields
http://issues.apache.org/jira/browse/COCOON-1842
COCOON-1838 Always use 3-digit version number
http://issues.apache.org/jira/browse/COCOON-1838
COCOON-1811 [PATCH] Flow Script: Allow dynamic loading of JavaScript objects
even when scope is locked
http://issues.apache.org/jira/browse/COCOON-1811
COCOON-1810 [PATCH] JMSEventMessageListener does not work
http://issues.apache.org/jira/browse/COCOON-1810
COCOON-1794 [PATCH] Propagation of namespaces to a repeaters child bindings and
implementation of a move-node binding
http://issues.apache.org/jira/browse/COCOON-1794
COCOON-1776 [PATCH]Reload Bookmarks on bookmark file validity
http://issues.apache.org/jira/browse/COCOON-1776
COCOON-1774 Fine Tuning Ajax Handling in CForms
http://issues.apache.org/jira/browse/COCOON-1774
COCOON-1738 double-listbox problem in repeaters
http://issues.apache.org/jira/browse/COCOON-1738
COCOON-1732 Ajax and IE empty textarea bugfix
http://issues.apache.org/jira/browse/COCOON-1732
COCOON-1726 Implementation of Source that supports conditional GETs
http://issues.apache.org/jira/browse/COCOON-1726
COCOON-1717 Use custom cache keys for caching uri coplets using input modules.
http://issues.apache.org/jira/browse/COCOON-1717
COCOON-1706 Allow TeeTransformer to run a system command for debugging purposes
http://issues.apache.org/jira/browse/COCOON-1706
COCOON-1703 A patch for caching fonts (fixes GDI issues), vertical text
orientation, color code fix, prefered unit for margins and measure unit
converter
http://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
http://issues.apache.org/jira/browse/COCOON-1697
COCOON-1692 [PATCH] Tree widget not handling on-selection-change events
correctly.
http://issues.apache.org/jira/browse/COCOON-1692
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.
http://issues.apache.org/jira/browse/COCOON-1686
COCOON-1648 I18nTransformer add support for ISO8601
http://issues.apache.org/jira/browse/COCOON-1648
COCOON-1622 [PATCH] SendMailTransformer and HTML body
http://issues.apache.org/jira/browse/COCOON-1622
COCOON-1618 [PATCH] SoapGenerator/Serializer for Axis Block
http://issues.apache.org/jira/browse/COCOON-1618
COCOON-1611 [PATCH] Add additonal constructor to FormInstance.java to be able
to pass a locale
http://issues.apache.org/jira/browse/COCOON-1611
COCOON-1603 [PATCH] handling of alternatives in MailTransformer
http://issues.apache.org/jira/browse/COCOON-1603
COCOON-1573 Improvement SetAttributeJXPathBinding and Contribution
SetNodeValueJXPathBinding
http://issues.apache.org/jira/browse/COCOON-1573
COCOON-1557 [PATCH] Change access to AbstractContinuable.getContext to protected
http://issues.apache.org/jira/browse/COCOON-1557
COCOON-1556 [PATCH] Add a JXPathConvertor for conversion betwean beans and
Strings
http://issues.apache.org/jira/browse/COCOON-1556
COCOON-1535 [PATCH] enhancement to {global:} input module: return all sitemap
globals
http://issues.apache.org/jira/browse/COCOON-1535
COCOON-1527 [PATCH] Cache control logic sheets for XSP to override getKey and
getValidity
http://issues.apache.org/jira/browse/COCOON-1527
COCOON-1526 [PATCH] processToDOM returns a read-only DOM
http://issues.apache.org/jira/browse/COCOON-1526
COCOON-1519 [PATCH] TeeTransformer refactoring
http://issues.apache.org/jira/browse/COCOON-1519
COCOON-1508 [PATCH] Avalonize TranscoderFactory
http://issues.apache.org/jira/browse/COCOON-1508
COCOON-1506 [PATCH] Manually specifying a mounted sitemap's context
http://issues.apache.org/jira/browse/COCOON-1506
COCOON-1488 [PATCH] htmlunit-based testing, needs to be ported to 2.2
http://issues.apache.org/jira/browse/COCOON-1488
COCOON-1467 ESQL exception handling problem
http://issues.apache.org/jira/browse/COCOON-1467
COCOON-1439 [poi] vertical text orientation and font
Re: [2.2] Release?
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
AFAICT there is not much work left to get a first beta release out of the door.
The only issue that I know of is that the reloading classloader doesn't work
which would be important to get it fixed. Does somebody have time to look into
this problem?
Then we could release
- cocoon-core
- cocoon-bootstrap
- cocoon-template
- cocoon-deployer-plugin
- cocoon-22-archetype-webapp
- cocoon-22-archetype-block
I would like to see those modules released *before* the ApacheCon. Does anything
speak a release on Monday (June, 19th)?
Yes, most samples are currently not working and this includes the
template block
yes, I looked briefly into the issue but haven't found the cause. IIUC the list
cocoon.parameters contains the values instead of the names.
- I wrote an email last week (or the week before), but
got no reply for the problem at hand.
So, imho we should try to get most samples working - it's not necessary
that all samples work, but there should be more working samples than
failing ones. So as long as this is the case, I'm -1 on a release.
which samples are failing?
In addition, I would like to have a support for paranoid classloasding
in the deployer: controlled by a property the deploy could rewrite my
web.xml and add the paranoid servlet, listener and filters. Now, I could
come up with the code for rewriting the web.xml, but have no clue how
and where to add this in the deploy code.
yes I agree but we shouldn't delay a release just because of this missing
feature.
I will give more detailed advise about where you can add your code ASAP.
Finally :) how to we do the actual release? We have to take care of
legal aspects as well, like adding all licenses of the uses dependencies
etc.
I don't think that we should only provide Maven artifacts for our first release,
nothing more. Getting out a perfect sample distribution (which only has demo
purpose - people should *never* use it as the base for their own projects) could
take ages ... and I don't want to wait for it.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Release?
Reinhard Poetz wrote: So, imho we should try to get most samples working - it's not necessary that all samples work, but there should be more working samples than failing ones. So as long as this is the case, I'm -1 on a release. which samples are failing? Just try some of the core module; most of them failed for me (I tested it two weeks ago, so I can't remember which ones exactly failed). In addition, I would like to have a support for paranoid classloasding in the deployer: controlled by a property the deploy could rewrite my web.xml and add the paranoid servlet, listener and filters. Now, I could come up with the code for rewriting the web.xml, but have no clue how and where to add this in the deploy code. yes I agree but we shouldn't delay a release just because of this missing feature. Oh, yes, I agree with that as well. It's just nice to have but not require. I will give more detailed advise about where you can add your code ASAP. Great! I don't think that we should only provide Maven artifacts for our first release, nothing more. Getting out a perfect sample distribution (which only has demo purpose - people should *never* use it as the base for their own projects) could take ages ... and I don't want to wait for it. So this means we release some jars and the plugins? I think one important goal of this release should be to get feedback, so we should try to make the barrier to test 2.2 as low as possible while puttint as less effort as possible into it. I'm not sure if just releasing maven artifacts is enough here. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Release?
Carsten Ziegeler wrote:
So this means we release some jars and the plugins? I think one
important goal of this
release should be to get feedback, so we should try to make the barrier
to test 2.2 as low as possible while puttint as less effort as possible
into it. I'm not sure if just releasing maven artifacts is enough here.
Which kind of feedback do you want?
I think we need feedback from people that migrate their projects to C22. I don't
believe it makes sense to use C22 without a Maven 2 based build. And, as I said
in many previous mails, a distribution that can be compared to a C21 release has
its only purpose in being a demo application, nothing more.
So yes, I think that the named artifacts are enough for a first release.
Releasing forms, fop, javaflow, apples, batik, mail and portal should be the
next step so that more people can start to experiment with a migration. During
this phase we should fix their samples too.
Finally, we don't have to provide *one* release that contains all our 50+ blocks
anymore. Luckily we can release iterativly whenever something is ready :-)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: svn commit: r407477 - in /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/util: ./ log/
Carsten Ziegeler wrote: Vadim Gritsenko wrote: So you are saying it is still possible to log to LogKit, but it won't be feature complete / backwards compatible with 2.1? Hm... Yepp, if people think it's worth having this, I would suggest to add an own module just for the logkit stuff. The core should have as less dependencies as possible. Just to satisfy curiosity, is there a log4j support for Cocoon log format? (looking at .../core/cocoon-webapp/src/main/webapp/WEB-INF/log4j.xconf, I'd guess that the answer is 'no'). Yepp, you're right. Ok, thanks for confirming it... Vadim
Re: [2.2] Release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Jun 2006, Reinhard Poetz wrote: Date: Wed, 14 Jun 2006 14:29:41 +0200 From: Reinhard Poetz [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [2.2] Release? Carsten Ziegeler wrote: So this means we release some jars and the plugins? I think one important goal of this release should be to get feedback, so we should try to make the barrier to test 2.2 as low as possible while puttint as less effort as possible into it. I'm not sure if just releasing maven artifacts is enough here. Which kind of feedback do you want? I think we need feedback from people that migrate their projects to C22. I don't believe it makes sense to use C22 without a Maven 2 based build. And, as I said in many previous mails, a distribution that can be compared to a C21 release has its only purpose in being a demo application, nothing more. So yes, I think that the named artifacts are enough for a first release. Releasing forms, fop, javaflow, apples, batik, mail and portal should be the next step so that more people can start to experiment with a migration. During this phase we should fix their samples too. And don't forget the archetypes and plugins. Finally, we don't have to provide *one* release that contains all our 50+ blocks anymore. Luckily we can release iterativly whenever something is ready :-) - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEkAU5LNdJvZjjVZARArn7AJ4oynf6LGHUCpTTW1oNlxHsqIEc+QCdHHeB 7c7jbp8hLM782mo0jpowRd8= =kjmi -END PGP SIGNATURE-
Re: [2.2] Release?
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 14 Jun 2006, Reinhard Poetz wrote:
Date: Wed, 14 Jun 2006 14:29:41 +0200
From: Reinhard Poetz [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [2.2] Release?
Carsten Ziegeler wrote:
So this means we release some jars and the plugins? I think one
important goal of this
release should be to get feedback, so we should try to make the barrier
to test 2.2 as low as possible while puttint as less effort as possible
into it. I'm not sure if just releasing maven artifacts is enough here.
Which kind of feedback do you want?
I think we need feedback from people that migrate their projects to
C22. I don't believe it makes sense to use C22 without a Maven 2 based
build. And, as I said in many previous mails, a distribution that can
be compared to a C21 release has its only purpose in being a demo
application, nothing more.
So yes, I think that the named artifacts are enough for a first
release. Releasing forms, fop, javaflow, apples, batik, mail and
portal should be the next step so that more people can start to
experiment with a migration. During this phase we should fix their
samples too.
And don't forget the archetypes and plugins.
both already work (for me). I will write documentation for them over the next
days.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Release?
Reinhard Poetz wrote: Carsten Ziegeler wrote: So this means we release some jars and the plugins? I think one important goal of this release should be to get feedback, so we should try to make the barrier to test 2.2 as low as possible while puttint as less effort as possible into it. I'm not sure if just releasing maven artifacts is enough here. Which kind of feedback do you want? I think we need feedback from people that migrate their projects to C22. I don't believe it makes sense to use C22 without a Maven 2 based build. And, as I said in many previous mails, a distribution that can be compared to a C21 release has its only purpose in being a demo application, nothing more. I suspect that Carsten didn't understand what you were saying as this sentence, I don't think that we should only provide Maven artifacts for our first release, nothing more. would lead one to believe that you do NOT want to ship anything regarding maven 2. So yes, I think that the named artifacts are enough for a first release. Releasing forms, fop, javaflow, apples, batik, mail and portal should be the next step so that more people can start to experiment with a migration. During this phase we should fix their samples too. Finally, we don't have to provide *one* release that contains all our 50+ blocks anymore. Luckily we can release iterativly whenever something is ready :-) I have no problem with this release as a first step, but I'd hesitate to even call it 2.2M1. OTOH, if I had an idea of what our subsequent milestones are this might make more sense to me. Ralph
[jira] Created: (COCOON-1863) Save form model with empty fields: Binding model to document fails
Save form model with empty fields: Binding model to document fails -- Key: COCOON-1863 URL: http://issues.apache.org/jira/browse/COCOON-1863 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.9 Reporter: Feliciano Borrego In the Cocoon example samples/blocks/forms/form2xml.flow, when submit the form with the fields IP adress, phone number and all contacts fields empty, in Cocoon 2.1.8 the XML is: data wrapper context info email boolBindingWorks=false[EMAIL PROTECTED]/email number value=3/ choose value=true/ phone cntr= zone/ number/ /phone /info ipaddress changed=true/ birthday1960-04-10/birthday drinks drinkJupiler/drinkdrinkHoegaarden/drink/drinks contacts contact id=1 row-state=original firstname/ lastname/ phone nr=/ email/ /contact contact id=2 row-state=original firstname/ lastname/ phone nr=/ email/ /contact /contacts /context /wrapper /data Therefore in Cocoon 2.1.9 the XML result is: data wrapper context info email boolBindingWorks=false[EMAIL PROTECTED]/email number value=3/ choose value=false/ phone /phone /info birthday1960-04-10/birthday drinks drinkJupiler/drinkdrinkLeffe/drink/drinks contacts contact id=1 row-state=original phone/ /contact contact id=2 row-state=original phone/ /contact /contacts /context /wrapper /data The Simple XML Binding and Bean Binding examples works fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1863) Save form model with empty fields: Binding model to document fails
[ http://issues.apache.org/jira/browse/COCOON-1863?page=comments#action_12416222 ] Feliciano Borrego commented on COCOON-1863: --- In my form, if string field mail_pers is empty, the jpath expression jpath:value-of select=mail_pers / thows the error: --- org.apache.commons.jxpath.JXPathException: No value for xpath: mail_pers at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getValue(JXPathContextReferenceImpl.java:344) at org.apache.commons.jxpath.ri.JXPathCompiledExpression.getValue(JXPathCompiledExpression.java:57) at org.apache.cocoon.www.file_.D_.Des.Proy.SigPortal.web.portal.xsp.PersonalPerfil_bind_xsp.generate(org.apache.cocoon.www.file_.D_.Des.Proy.SigPortal.web.portal.xsp.PersonalPerfil_bind_xsp:567) at org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:228) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:578) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:281) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:779) at org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:412) at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:100) at org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:320) at org.apache.cocoon.sitemap.ContentAggregator.generate(ContentAggregator.java:124) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:578) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:281) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:480) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.handleCocoonRedirect(ConcreteTreeProcessor.java:298) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.access$000(ConcreteTreeProcessor.java:47) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector.cocoonRedirect(ConcreteTreeProcessor.java:339) at org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:59) at org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo(AbstractInterpreter.java:209) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.forwardTo(FOM_JavaScriptInterpreter.java:905) at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.forwardTo(FOM_Cocoon.java:698) at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsFunction_sendPage(FOM_Cocoon.java:269) at inv9.invoke() Save form model with empty fields: Binding model to document fails -- Key: COCOON-1863 URL: http://issues.apache.org/jira/browse/COCOON-1863 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.9 Reporter: Feliciano Borrego In the Cocoon example samples/blocks/forms/form2xml.flow, when submit the form with the fields IP adress, phone number and all contacts fields empty, in Cocoon 2.1.8 the XML is: data wrapper context info email boolBindingWorks=false[EMAIL PROTECTED]/email number value=3/ choose value=true/ phone cntr= zone/ number/ /phone /info ipaddress changed=true/ birthday1960-04-10/birthday drinks drinkJupiler/drinkdrinkHoegaarden/drink/drinks
[jira] Commented: (COCOON-1112) [PATCH] Client-side: window.onload handler clobbered by body onload=...
[
http://issues.apache.org/jira/browse/COCOON-1112?page=comments#action_12416223
]
Feliciano Borrego commented on COCOON-1112:
---
script language=JavaScript type=text/javascript
//![CDATA[
!--
function addLoadEvent(func) {
var oldonload = window.onload;
if (typeof window.onload != 'function') {
window.onload = func;
} else {
window.onload = function() {
oldonload();
func();
}
}
}
addLoadEvent( myJsFunction );
//in MS-Iexporer == if (window.attachEvent) window.attachEvent(onload,
myJsFunction);
//--
//]]
/script
[PATCH] Client-side: window.onload handler clobbered by body onload=...
---
Key: COCOON-1112
URL: http://issues.apache.org/jira/browse/COCOON-1112
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.1.8
Environment: Operating System: other
Platform: Other
Reporter: Mark Lundquist
Assignee: Cocoon Developers Team
Attachments: cocoon.bug28012.patch
See: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107952785825215w=2
Granted, the transformation on the body element does preserve whatever JS
statements may have
been contained in the transformed body, but those in themselves are not the
window.onload
handler. Rather, the effect of @onload is to set (i.e., overwrite)
window.onload. So if I want my onload
logic not to be clobbered here, I have to specify it via @onload â but
this is not convenient for me, as
my HTML body element is generated by a common page stylesheet several
transformations down
the pipeline from the source document that cares about the onload handler. I
shouldn't have to add
more coupling (tags and XSL) to drive this styling template and micromanage
the body element it
writes; much nicer to say window.onload = initialize; or whatever, in an
external javascript resource (I
already have transformations in place that let me drive a child of head
into the HTML... e.g., script
type=text/javascript src=...). At any rate, if forms-lib.js would
accomodate (i.e., preserve)
window.onload, that would just be one less surprise (and one less thing to
spend time debugging) for
the user.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[Vote] New committers
Hello, I'd like to introduce some people of our community and invite them for becoming committers of the Cocoon project. Three people do I have in mind: Andreas Hochsteger, Peter Hunsberger and Jason Johnston. 1. Andreas Hochsteger He has been active in our community since more than 4 years. Nearly from the beginning he has been actively taking part in discussions on this list. In the nearest past his main focus seemed to be the stabilization of our trunk, especially with M10N. IMO with his help we can further improve in that area - and others as well. 2. Peter Hunsberger Yes, he is one of those candidates many people wonder they are not already committers. He has a very good and in-depth knowledge of the Cocoon internals. He always provides very valuable comments to our RT discussions. Due to legal restrictions within the company he works for he might not deliver so much code, but he would not be the first one. His knowledge and the deriving involvement make him also a valuable member of our community. 3. Jason Johnston Jason has a completely different focus. His involvement seems to have risen from the typical user perspective. Getting more and more used to Cocoon and especially CForms he helps our users by answering many questions and providing helpful comments on the users list - a typical area where the Cocoon community wants to improve steadily. With Andreas, Peter and Jason becoming Cocoon committers I hope for further improvements on the Cocoon project. Especially their quite different foci might help very much. So please cast your votes about inviting Andreas, Peter and Jason as Cocoon committers. Regards, Jörg
Re: [Vote] New committers
On 14.06.2006 21:16, Joerg Heinicke wrote: I'd like to introduce some people of our community and invite them for becoming committers of the Cocoon project. 1. Andreas Hochsteger +1 2. Peter Hunsberger +1 3. Jason Johnston +1 Jörg
Re: [Vote] New committers
Joerg Heinicke wrote:
Hello,
I'd like to introduce some people of our community and invite them for
becoming committers of the Cocoon project. Three people do I have in
mind: Andreas Hochsteger, Peter Hunsberger and Jason Johnston.
1. Andreas Hochsteger
He has been active in our community since more than 4 years. Nearly from
the beginning he has been actively taking part in discussions on this
list. In the nearest past his main focus seemed to be the stabilization
of our trunk, especially with M10N. IMO with his help we can further
improve in that area - and others as well.
+1
2. Peter Hunsberger
Yes, he is one of those candidates many people wonder they are not
already committers. He has a very good and in-depth knowledge of the
Cocoon internals. He always provides very valuable comments to our RT
discussions. Due to legal restrictions within the company he works for
he might not deliver so much code, but he would not be the first one.
His knowledge and the deriving involvement make him also a valuable
member of our community.
+1
3. Jason Johnston
Jason has a completely different focus. His involvement seems to have
risen from the typical user perspective. Getting more and more used to
Cocoon and especially CForms he helps our users by answering many
questions and providing helpful comments on the users list - a typical
area where the Cocoon community wants to improve steadily.
+1
With Andreas, Peter and Jason becoming Cocoon committers I hope for
further improvements on the Cocoon project. Especially their quite
different foci might help very much.
So please cast your votes about inviting Andreas, Peter and Jason as
Cocoon committers.
welcome abord!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [Vote] New committers
Joerg Heinicke wrote: 1. Andreas Hochsteger 2. Peter Hunsberger 3. Jason Johnston +3 :-) Jorg
Re: [2.2] Release?
Reinhard Poetz wrote: - cocoon-core - cocoon-bootstrap - cocoon-template - cocoon-deployer-plugin - cocoon-22-archetype-webapp - cocoon-22-archetype-block +1 (I won't be able to help out though as i'm on holiday) Jorg
Re: [Vote] New committers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Jun 2006, Joerg Heinicke wrote: 1. Andreas Hochsteger +1 2. Peter Hunsberger +1 3. Jason Johnston +1 Welcome to all three - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEkHDKLNdJvZjjVZARAjoEAJ9BP72vc6PYF3TSLMKz3Bh/i8/3xgCguQQH 4kAwrAo9Vm4J/vrzA4XwOJ8= =K0nf -END PGP SIGNATURE-
Re: [2.2] Release?
Carsten Ziegeler wrote: Finally :) how to we do the actual release? We have to take care of legal aspects as well, like adding all licenses of the uses dependencies etc. core has a dependency on the licenses block, does that cover your legal requirements ? As to how to actually do the release, unsure. If it was me doing it next week i would do something like this for the maven part of things: 1. change the poms manually to reflect the correct version number of the core (eg 2.2.0M1 or whatever). Also change the version number of each module itself to be non-snapshot (eg 1.0-SNAPSHOT becomes 1.0). 2. tag 3. mvn source:jar javadoc:jar repository:bundle-create for each module we're releasing, don't forget the module poms 4. bump the version numbers for all modules, 1.0.0 becomes 1.0.1-SNAPSHOT or 1.1.0-SNAPSHOT etc. Reset the version number of core back to 2.2.0-SNAPSHOT. 4. create a jira issue for the jars to be uploaded, described here http://maven.apache.org/guides/mini/guide-ibiblio-upload.html HTH Jorg
Re: [Vote] New committers
Joerg Heinicke escribió: Hello, I'd like to introduce some people of our community and invite them for becoming committers of the Cocoon project. Three people do I have in mind: Andreas Hochsteger, Peter Hunsberger and Jason Johnston. +3! :-) Welcome. Best Regards, Antonio Gallardo
[cforms] New ProcessingPhases added a repeater bug?
Hi folks, Carlos and I suspect we hit a recently introduced bug. Steps to reproduce == 1. Open http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/form2bean.flow 2. Change birthday date to a valid date (just changing the year to 2000 is enough). 3. Delete the unique contact in the repeater. 4. Now press Add contact. 6. Fill the firstname (an a is enough). 7. Save the form (press send button). Comments We suspect the error was introduced in revision 410241 [1]. Can anyone reproduce the bug and confirm the issue? Best Regards, Antonio Gallardo [1] http://svn.apache.org/viewvc?rev=410241view=rev * Full stacktrace org.apache.cocoon.ProcessingException: Error calling continuation at resource://org/apache/cocoon/forms/flow/javascript/Form.js:256:-1 at file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/samples/blocks/forms/flow/binding_example.js:89:-1 at resource://org/apache/cocoon/forms/flow/javascript/Form.js:0:-1 at map:call - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/samples/blocks/forms/sitemap.xmap:180:38 at map:mount - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/samples/blocks/sitemap.xmap:66:68 at map:mount - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/samples/sitemap.xmap:201:65 at map:mount - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/sitemap.xmap:1017:92 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:144) at org.apache.cocoon.components.flow.javascript.LocationTrackingDebugger.getException(LocationTrackingDebugger.java:131) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:840) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:123) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:252) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:252) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at
Re: [Fwd: New copyright header policy]
Reinhard Poetz wrote: FYI, find attached a mail about the new copyright header policy. I will attend to the issue of updating the license headers in all source files. However i cannot do this until after the end of June. -David additionally I want to point your interest to following comment. I hope Maven will solve this for us *before* August, 1st ... ~~ Carlos Sanchez wrote: What would be the policy for jar files that can be distributed individually through the Apache repository? do all of them need to have the LICENSE and NOTICE files inside the jar? Yes -- if they are the result of work created at the ASF (not third- party works, which should just be left as they were found) Cliff ~~ [Snip attached stuff about licenses.]
Re: [Fwd: New copyright header policy]
David Crossley wrote:
Reinhard Poetz wrote:
FYI, find attached a mail about the new copyright header policy.
I will attend to the issue of updating the license headers
in all source files. However i cannot do this until after
the end of June.
that's great! Thanks.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [Vote] New committers
Antonio Gallardo wrote: Joerg Heinicke escribió: Hello, I'd like to introduce some people of our community and invite them for becoming committers of the Cocoon project. Three people do I have in mind: Andreas Hochsteger, Peter Hunsberger and Jason Johnston. +3! :-) +3 here as well. Vadim
Re: [Vote] New committers
Joerg Heinicke wrote: Hello, I'd like to introduce some people of our community and invite them for becoming committers of the Cocoon project. Three people do I have in mind: Andreas Hochsteger, Peter Hunsberger and Jason Johnston. 1. Andreas Hochsteger +1 2. Peter Hunsberger +1 3. Jason Johnston +1 Ralph
Re: [2.2] Release?
On Thursday 15 June 2006 04:39, Jorg Heymans wrote: Carsten Ziegeler wrote: Finally :) how to we do the actual release? We have to take care of legal aspects as well, like adding all licenses of the uses dependencies etc. core has a dependency on the licenses block, does that cover your legal requirements ? As to how to actually do the release, unsure. If it was me doing it next week i would do something like this for the maven part of things: 1. change the poms manually to reflect the correct version number of the core (eg 2.2.0M1 or whatever). Also change the version number of each module itself to be non-snapshot (eg 1.0-SNAPSHOT becomes 1.0). 2. tag 3. mvn source:jar javadoc:jar repository:bundle-create for each module we're releasing, don't forget the module poms 4. bump the version numbers for all modules, 1.0.0 becomes 1.0.1-SNAPSHOT or 1.1.0-SNAPSHOT etc. Reset the version number of core back to 2.2.0-SNAPSHOT. 4. create a jira issue for the jars to be uploaded, described here http://maven.apache.org/guides/mini/guide-ibiblio-upload.html I think that Maven's Release plugin is expected to handle all of that in one go. mvn release:prepare mvn release:perform However, the latest Release plugin (beta4) has regressed and in my cases working less well than the beta3 (which I would recommend). What is needed is that the POM(s) are properly configured for the Release process. At least distributionManagement, scm and the configuration for the release plugin must be correctly specified. Possibly a repository as well. I'll give it a go later today and see what is missing and try to figure out what should go in there... Cheers Niclas
Re: [Vote] New committers
1. Andreas Hochsteger +1 2. Peter Hunsberger +1 3. Jason Johnston +1 Cheers Niclas
Re: [2.2] Release?
On Thursday 15 June 2006 12:33, Niclas Hedhman wrote: I think that Maven's Release plugin is expected to handle all of that in one go. Let me clarify that; Provided that there are no SNAPSHOT dependencies... Cheers Niclas
Re: [2.2] Release?
Niclas Hedhman wrote: I think that Maven's Release plugin is expected to handle all of that in one go. Yep I know. I experimented with it a few weeks ago but found it quite difficult to get it working for our usecase. mvn release:prepare mvn release:perform ... I'll give it a go later today and see what is missing and try to figure out what should go in there... The poms are correctly configured for the release plugin AFAIK, you should just be able to run the goals and get something going. Please note that we don't want to release all blocks, so you'll have to do a non-recursive release of the root pom first, then core, and then all other blocks separately in their normal dependency order. Jorg
