Re: [CForms] Load/Save model events never send?
I removed the phase checks for load and save. Carsten Sylvain Wallez wrote: > Carsten Ziegeler wrote: >> Giacomo Pati wrote: >> >> >>> Will this enable to try to store something like "abc" into a integer >>> widget/model (which obviously would raise an Exception). If this would >>> be possible I would certainly be against allowing >>> unvalidated/invalid-state saves. >>> >> I don't know :) I guess it depends, if your model is using an int, I >> guess you will get an exception. But if your form model is using an int >> datatype but your data model is using a string (for whatever reason) >> this might work. It also might work if you're binding to xml. But all >> these are just guesses. >> >> Now, we could argue that if someone explicitly calls save() he should >> have ensured beforehand that his data is valid. >> > > +1. > > CForms makes sure in all places that any data returned to the > application to be valid, and returns null otherwise (with a validation > error being set). This therefore completely shields the application from > buggy data, which simplifies application development and avoids bugs and > to some extend rogue data injection. > > However some people have some use cases where they want to be able to > save a form in a "draft" state, even if it's invalid. In this context, > "saving" should'nt considered IMO to be the same as the form's save > operation, as the form data can be not only semantically invalid (i.e. > validators fail), but also syntactically invalid (i.e. a "abc" for an > integer). Invalid syntax means the form's binding more than likely to > fail to save the form (invalid bean property types). > > Saving as draft therefore means saving the form values as plain text and > restoring them as such, just as if they where read from the request. > This is however not possible today because of the lack of the needed > entry points in widgets. This can be solved though if people really > needed with a couple of setStringValue()/getStringValue() methods. > > Sylvain > -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Releases?
Carsten Ziegeler wrote:
What do we really have to do for a 2.2 Milestone release?
- decide which modules we want to release. My proposal was
* cocoon-core
* cocoon-bootstrap
* cocoon-deployer-plugin
* cocoon-22-archetype-block
* cocoon-template
* cocoon (pom module)
* cocoon-core (pom module)
* cocoon-blocks (pom module)
* cocoon-tools (pom module)
* use the release plugin
* fix the IndexOutOfBoundException in cocoon-core (or am I the only one
getting it)
Anything else?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
[continuum] BUILD ERROR: core-samples-main Block Implementation
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/182/buildId/1660 Build statistics: State: Error Previous State: Error Started at: Fri, 7 Jul 2006 03:21:45 + Finished at: Fri, 7 Jul 2006 03:21:47 + Total time: 1s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
Re: Choreographed releases (was [RANT] This Maven thing is killing us....)
On Wednesday 05 July 2006 18:29, Steve Loughran wrote: > Now that Cocoon is using OSGi, does that change versioning rules? > Because that lets components run different versions of things > side-by-side, doesnt it? To some extent. Individual Java Packages can be versioned and one can declare a runtime dependency on a specific, ranged or 'later than' version of a package. But problems will still surface. A dependsOn B A dependsOn C ver1.0 (only) B dependsOn C ver1.1 (or later) In such case, the classes of C may clash and therefor OSGi will not be able to (reliably) resolve A (i.e. 'wire' the classloading) and therefor not attempt it. But in many cases it is possible to have scenarios working, which may not even be possible to build from Ant and Maven, hence the Eclipse insistence on having their own build system, which resolves OSGi packages according to the spec. Cheers Niclas
Re: Session invalidate fails from flow?
On 7/6/06, Peter Hunsberger <[EMAIL PROTECTED]> wrote: I'm attempting to migrate some more of our code from sitemap based action handlers to flow. Cocoon is at 2.1.8 and I'm seeing problems invalidating sessions from flow. Just discovered that we're still on Cocoon 2.1.6. Anyone know if this might have been fixed in newer releases? It's a bit of work for us to move to a new Cocoon release... -- Peter Hunsberger
Please Help - Cocoon Hangs - Urgent
It is throwing the following error. Can someone give me any pointers? Thanks, Dinesh INFO (2006-07-06) 14:24.28:622 [slide.repository] (Unknown-URI) Unknown-Thread/SlideLoggerAdapter: Stopping RM at '/home/idgar/jakarta-tomcat-5.5.9/webapps/cocoon/slide/store/metadata' / '/home/idgar/jakarta-tomcat-5.5.9/work/Catalina/localhost/cocoon/cocoon-file s/slide/work/metadata' INFO (2006-07-06) 14:24.28:622 [slide.repository] (Unknown-URI) Unknown-Thread/SlideLoggerAdapter: Stopped RM INFO (2006-07-06) 14:24.28:623 [slide.repository] (Unknown-URI) Unknown-Thread/SlideLoggerAdapter: Stopping RM at '/home/idgar/jakarta-tomcat-5.5.9/webapps/cocoon/slide/store/content' / '/home/idgar/jakarta-tomcat-5.5.9/work/Catalina/localhost/cocoon/cocoon-file s/slide/work/content' INFO (2006-07-06) 14:24.28:623 [slide.repository] (Unknown-URI) Unknown-Thread/SlideLoggerAdapter: Stopped RM WARN (2006-07-06) 14:24.28:625 [core.manager] (Unknown-URI) Unknown-Thread/ExcaliburComponentSelector: Attempted to release a org.apache.cocoon.portal.impl.PortalManagerImpl but its handler could not be located. WARN (2006-07-06) 14:24.28:711 [core.manager] (Unknown-URI) Unknown-Thread/ThreadSafeComponentHandler: Error decommissioning component: org.apache.cocoon.components.treeprocessor.TreeProcessor java.lang.NullPointerException at org.apache.excalibur.source.impl.SourceResolverImpl.release(SourceResolverIm pl.java:285) at org.apache.cocoon.components.CocoonComponentManager.release(CocoonComponentM anager.java:548) at org.apache.cocoon.components.treeprocessor.TreeProcessor.dispose(TreeProcess or.java:368) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.ja va:306) at org.apache.avalon.excalibur.component.DefaultComponentFactory.decommission(D efaultComponentFactory.java:356) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.dispose(Thr eadSafeComponentHandler.java:165) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.dispose(Exca liburComponentManager.java:623) at org.apache.cocoon.components.CocoonComponentManager.dispose(CocoonComponentM anager.java:509) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.ja va:306) at org.apache.cocoon.Cocoon.dispose(Cocoon.java:543) at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.ja va:306) at org.apache.cocoon.servlet.CocoonServlet.disposeCocoon(CocoonServlet.java:155 3) at org.apache.cocoon.servlet.CocoonServlet.destroy(CocoonServlet.java:517) at org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1316) at org.apache.catalina.core.StandardWrapper.stop(StandardWrapper.java:1651) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:892) at org.apache.catalina.core.StandardContext.removeChild(StandardContext.java:30 35) at org.apache.catalina.startup.ContextConfig.stop(ContextConfig.java:1083) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java: 271) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor t.java:119) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4265) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:892) at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1143) at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1115) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:313) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor t.java:119) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1053) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1065) at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:447) at org.apache.catalina.core.StandardService.stop(StandardService.java:512) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:717) at org.apache.catalina.startup.Catalina.stop(Catalina.java:586) at org.apache.catalina.startup.Catalina.start(Catalina.java:561) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409) INFO (2006-07-06) 14:24.28:737 [cron] (Unknown-URI) Unknown-Thread/QuartzJobScheduler: shutting down scheduler graceful (waiting for running jobs to complete) WARN (2006-07-06) 14:24.28:774 [core.manager] (Unknown-
Session invalidate fails from flow?
I'm attempting to migrate some more of our code from sitemap based
action handlers to flow. Cocoon is at 2.1.8 and I'm seeing problems
invalidating sessions from flow.
Essentially, we are using Javascript flow to invoke a Java class as follows:
var handler = Packages.org.stjude.ct.ui.login.LogoffActionHandler();
handler.logoff( cocoon );
The LogoffAction among other things does:
public final void logoff( FOM_Cocoon cocoon ) throws BadSessionException {
Request request = cocoon.getRequest();
Session session = request.getSession( false );
if ( session != null ) {
session.invalidate();
}
Sometime later, the same user using the same browser session will
attempt to logon back to our application. This invokes flow like:
var handler = Packages.org.stjude.ct.ui.login.ActionHandler();
var logonOk = handler.logon( cocoon );
And this ActionHandler then gets the session with code essentially the
same as the above.
If I trace the LogoffAction I see the session get marked as invalid.
However, the subsequent session retrieval gets the exact same session
(session id is the same) but the valid flag is now true (session is
not considered invalid).
I thought at first this might be a JBoss issue, but I don't see how, I
now suspect it has something to do with the way Cocoon flow wraps
request and session objects. Anyone have an idea on what might be
going wrong and how to work around it? Is this a Coccon bug?
--
Peter Hunsberger
Re: [CForms] Load/Save model events never send?
Carsten Ziegeler wrote: > Giacomo Pati wrote: > > >> Will this enable to try to store something like "abc" into a integer >> widget/model (which obviously would raise an Exception). If this would >> be possible I would certainly be against allowing >> unvalidated/invalid-state saves. >> > I don't know :) I guess it depends, if your model is using an int, I > guess you will get an exception. But if your form model is using an int > datatype but your data model is using a string (for whatever reason) > this might work. It also might work if you're binding to xml. But all > these are just guesses. > > Now, we could argue that if someone explicitly calls save() he should > have ensured beforehand that his data is valid. > +1. CForms makes sure in all places that any data returned to the application to be valid, and returns null otherwise (with a validation error being set). This therefore completely shields the application from buggy data, which simplifies application development and avoids bugs and to some extend rogue data injection. However some people have some use cases where they want to be able to save a form in a "draft" state, even if it's invalid. In this context, "saving" should'nt considered IMO to be the same as the form's save operation, as the form data can be not only semantically invalid (i.e. validators fail), but also syntactically invalid (i.e. a "abc" for an integer). Invalid syntax means the form's binding more than likely to fail to save the form (invalid bean property types). Saving as draft therefore means saving the form values as plain text and restoring them as such, just as if they where read from the request. This is however not possible today because of the lack of the needed entry points in widgets. This can be solved though if people really needed with a couple of setStringValue()/getStringValue() methods. Sylvain -- Sylvain Wallez - http://bluxte.net
Releases?
I think it's time again to think about a release. What do people about releasing 2.1.10 shortly? (Which means announcing code freeze/test phase next week or so) What do we really have to do for a 2.2 Milestone release? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [CForms] Load/Save model events never send?
Giacomo Pati wrote: > > Will this enable to try to store something like "abc" into a integer > widget/model (which obviously would raise an Exception). If this would > be possible I would certainly be against allowing > unvalidated/invalid-state saves. > I don't know :) I guess it depends, if your model is using an int, I guess you will get an exception. But if your form model is using an int datatype but your data model is using a string (for whatever reason) this might work. It also might work if you're binding to xml. But all these are just guesses. Now, we could argue that if someone explicitly calls save() he should have ensured beforehand that his data is valid. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Created: (COCOON-1878) Validation block: conflict over Xerces xml-apis and jsr-173 javax.xml.XMLConstants
Validation block: conflict over Xerces xml-apis and jsr-173 javax.xml.XMLConstants -- Key: COCOON-1878 URL: http://issues.apache.org/jira/browse/COCOON-1878 Project: Cocoon Type: Bug Components: Blocks: Validation Versions: 2.1.8, 2.1.9 Reporter: Ellis Pritchard Priority: Minor blocks/validation/java/org/apache/cocoon/components/validation/jaxp/JaxpSchemaParser.java relies on the following constants defined in javax.xml.XMLConstants : XMLConstants.RELAXNG_NS_URI XMLConstants.W3C_XML_SCHEMA_NS_URI XMLConstants.XML_DTD_NS_URI These constants come from xml-apis-1.3.02.jar, which is part of Xerces; however the official release of javax.xml.XMLConstants from Sun (e.g. jsr-173 [1]) does not contain these constants, and therefore installing e.g. stax-api-1.0.1.jar, which contains the official XML API, may create a build or run-time failure, depending on the order that jars are loaded. These constants should probably be obtained from elsewhere to avoid future problems. Work-around: disable validation block, or remove XMLConstants from offical jars. [1] http://java.sun.com/webservices/docs/1.6/api/index.html -- 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
Re: [CForms] Load/Save model events never send?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 6 Jul 2006, Carsten Ziegeler wrote:
Date: Thu, 06 Jul 2006 08:32:19 +0200
From: Carsten Ziegeler <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [CForms] Load/Save model events never send?
Quoin Developers wrote:
Actually, it appears that I can save from an action handler - but it's
a little tricky and probably not the recommended way (calling validate
on the Form from the action handler).
form.form.validate()
if (form.form.isValid()) {
form.save(facade);
facade.save();
form.getChild("contentMessages").addMessage(new I18nMessage('saved',
'application'));
}
Uh, that's ugly. Now my intention with the phase checking for save was
that you can only save if the form is valid which imho makes sense.
Saving an invalid form can lead to unpredictable situations I guess.
Now, I would be interested in other opinions. Should we remove these
checks or not?
Will this enable to try to store something like "abc" into a integer
widget/model (which obviously would raise an Exception). If this would
be possible I would certainly be against allowing
unvalidated/invalid-state saves.
- --
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.4 (GNU/Linux)
iD8DBQFErMMYLNdJvZjjVZARAqkXAKDn8Hk5P1WYImgalr4JfobFwYUp7QCbBgVe
GHLni3NsKiyKJPDBlaXQM74=
=GmRq
-END PGP SIGNATURE-
