Re: SourceResolver in SSF
Grzegorz Kossakowski wrote: Thanks Carsten for a summary! To be honest, I'm not sure what kind of action we should take here. What you described sounds great and it's very tempting to have sources properly working with just standard URL class. Anyway, I'm little bit worried that whole things bases on *ugly* hack. I'm wondering how reliable the solution is. I have a few additional questions: 1. Has this technique (not necessarily JNet's implementation) been used in some project? Or it's your brilliant invention? :-) Hehe, no, afaik other projects are using this as well and I borrowed the idea from there and made my own implementation. Among the projects is Equinox, the platform for Eclipse. I think there are some other projects out there using this as well. 2. What about debugging? What about stracktraces? Won't reflection hack break something? Ah ok, the reflection is just used to register an own url handler. As you can't call setHandler (the actual method name is different but I don't remember it) you search via reflection for the "handler" property and change this through reflection. 3. How intrusive it would be to integrate JNet into SSF? I think this has minimal impact; in theory you don't need jnet at all, just use plain urls in SSF and you're done. Cocoon can then use jnet to make the Spring source factories available as plain url objects. I'm interested in experimenting with your work but since this issue is rather urgent I would like to be able to count on your help if it's me who is going to resolve this problem. Sure, count me in :) What do others think? PS. Here we are talking about SSF only at the moment. Inside SitemapServlet the CocoonSourceResolver will be preserved, at least for now. Yepp, things change hopefully with Corona :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [2.2] Forms dependency on Ajax block
On 13.03.2008 16:20, Luca Morandini wrote: This means that Forms must depend on Ajax (Dojo to be more precise) despite the fact you use Ajax or not. This is not quite true I think. Forms used to have two different stylesheets: forms-field-styling.xsl and forms-advanced-field-styling.xsl. The first was a "pure" implementation, the second one used JS-enabled widgets. Which is a departure from 2.1.9, which, IIRC, worked even with Javascript disabled on the browser. I don't think Forms used to work without Javascript. There have always been onload handlers as far as I remember, but for the general idea, yes, it seems this has changed. If we are migrating to Dojo 1.0 that is definitely one of the requirements I'd like to see being addressed. Forms should work without Dojo. Dojo might be a requirement for Ajax-enabled though. GoogleMap should definitely be moved to advanced field stylesheet. I presume that a way to disentangle forms and ajax blocks would be to make two different forms-field-styling.xsl (one with Javascript and/or Ajax, the other without Javascript), loaded conditionally on ajax="true" by forms-samples-styling.xsl. As I wrote that was originally the idea between forms-field-styling.xsl and forms-advanced-field-styling.xsl. We should get back to this separation. Why I'm making such a plea ? Well, the use of non-Javascript forms is a requirement for making websites accessible, which is a mandatory for governmental websites in Italy. I don't quite agree with it, Javascript does not necessarily prevent accessibility. I'm not too familiar with all the accessibility requirements but for example the tabs we have in Forms should be fine, aren't they? Joerg
[jira] Updated: (COCOON-2169) ImageOp resize effect has broken/useless default dimensions
[ https://issues.apache.org/jira/browse/COCOON-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Lundquist updated COCOON-2169: --- Component/s: (was: Blocks: (Undefined)) Blocks: ImageOp Affects version (Component): Parent values: Blocks: ImageOp(10334). Fix version (Component): Parent values: Blocks: ImageOp(10336). > ImageOp resize effect has broken/useless default dimensions > --- > > Key: COCOON-2169 > URL: https://issues.apache.org/jira/browse/COCOON-2169 > Project: Cocoon > Issue Type: Bug > Components: Blocks: ImageOp >Affects Versions: 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN), > 2.2-dev (Current SVN) >Reporter: Mark Lundquist >Priority: Minor > > Class ResizeOperation in the ImageOp block has broken/useless default values > for the "height" and "width" parameters. The only reasonable default values > are zero. Zero height or width has a special meaning. > I am passing these parameters in from the sitemap using the request parameter > input module. If the parameter doesn't exist, I need the "zero" value and > behavior from the Reader. Setting the dimension to e.g. "300" is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2177) ImageOp with requested height & width both zero should be a no-op, instead it throws an exception
ImageOp with requested height & width both zero should be a no-op, instead it
throws an exception
-
Key: COCOON-2177
URL: https://issues.apache.org/jira/browse/COCOON-2177
Project: Cocoon
Issue Type: Bug
Components: Blocks: ImageOp
Affects Versions: 2.1.11, 2.1.10, 2.1.9, 2.1.8, 2.1.12-dev (Current SVN),
2.2-dev (Current SVN)
Reporter: Mark Lundquist
Priority: Minor
When the resize height and width are both zero, the resize operation throws:
java.awt.image.ImagingOpException: Unable to invert transform
AffineTransform[[0.0, 0.0, 0.0], [0.0, 0.0, 0.0]]
Note, if COCOON-2169 is fixed, this happens when no height or width parameter
is passed from the sitemap. In this case, the resize effect should simply pass
through the unaltered image... it should be a "no-op".
The patch is too small to bother attaching, here it is:
===
---
blocks/cocoon-imageop/cocoon-imageop-impl/src/main/java/org/apache/cocoon/reading/imageop/ResizeOperation.java
(revision 635771)
+++
blocks/cocoon-imageop/cocoon-imageop-impl/src/main/java/org/apache/cocoon/reading/imageop/ResizeOperation.java
(working copy)
@@ -57,6 +57,9 @@
if( ! enabled ) {
return image;
}
+if ( this.width == 0 && this.height == 0 ) {
+return image;
+}
double height = image.getHeight();
double width = image.getWidth();
double xScale = this.width / width
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 18 March 01:09 AM Using Forrest 0.9-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2008-03-18 12:12:08 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.9-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: fetch-plugins-descriptors: [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml [get] local file date : Tue Apr 10 05:50:24 GMT+00:00 2007 [get] . [get] last modified = Wed Apr 11 02:07:04 GMT+00:00 2007 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml [get] local file date : Fri Feb 15 13:06:17 GMT+00:00 2008 [get] Not modified - so not downloaded [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.output.pdf -- check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. Trying to update it... init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: [echo] Trying to find the description of org.apache.forrest.plugin.output.pdf in the different descriptor files [echo] Using the descriptor file /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml... [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-local-unversioned-plugin: get-local: [echo] Trying to locally get org.apache.forrest.plugin.output.pdf [echo] Looking in local /export/opt/forrest-trunk/plugins [echo] Found ! init-build-compiler: echo-init: init: compile: jar: local-deploy: [echo] Locally deploying org.apache.forrest.plugin.output.pdf build: [echo] Plugin org.apache.forrest.plugin.output.pdf deployed ! Ready to configure fetch-remote-unversioned-plugin-version-forrest: fetch-remote-unversioned-plugin-unversion-forrest: has-been-downloaded: downloaded-message: uptodate-message: not-found-message: [echo] Fetch-plugin Ok, installing ! unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 file to /export/home/config/forrestbot-tru
Re: Test release artifacts - Legal requirements check
Carsten Ziegeler wrote: > Reinhard Poetz wrote: > >David Crossley wrote: > >>I saw that some committers have been using lowercase filenames > >>e.g. "notice.txt", so the "release-builder" needs to handle that. > > > >Is there some requirement that the file names of notice.txt and > >license.txt have to be either lower or upper case? Or is it up to us? The uppercase might just be tradition, but also what people expect to see. > See http://www.apache.org/dev/apply-license.html#license-file-name > > so we should name them "NOTICE" and "LICENSE". > > We should use the same name throughout all modules. Ah thanks. Also from that page: "Can the LICENSE and NOTICE files be called LICENSE.txt and NOTICE.txt? This is permitted. However the preference is that the files be called LICENSE and NOTICE. " The .txt filename extension helps with svn clients. I am going to add explicit handling to the ASF committers configuration so we can use "NOTICE" and "LICENSE". http://www.apache.org/dev/version-control.html#https-svn-config Would all committers please update their configuration. -David
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: > David Crossley wrote: > > > >I see that the META-INF/NOTICE.txt etc. files in each > >of "cocoon-components" and "impl" directory, would correspond > >with those from the sources. However where does top-level > >NOTICE.txt file come from? Should it be generated as a > >combination of the other two? The files in the sub-directories > >could potentially be different. > > The problem is that the release artifacts are sometimes collections of > several more focused artifacts, at least in the Maven 2 world they get > distributed in smaller units. > > I guess that the correct solution is that each of those "collection release > artifacts" has to contain a hand-crafted NOTICE.txt file. > > The license > should because of the ASF policy always be the same. I gather from listening to legal-discuss@ list that the licenses of supporting products need to be appended to the main LICENSE file. This has been added to the draft legal pages. http://wiki.apache.org/legal/3party/notice This is another wrinkle that we have not yet fully addressed at Forrest. A comment from Roy made me realise why that is needed. The LICENSE and NOTICE files are intended to be shown to the user in an "About..." style pop-up box. http://markmail.org/message/evydcvctn6c6of27 -David
Re: SourceResolver in SSF
Carsten Ziegeler pisze:
Grzegorz Kossakowski wrote:
Carsten Ziegeler pisze:
Filled up an issue: https://issues.apache.org/jira/browse/COCOON-2176
My plan is to register default Excalibur's SourceResolver
implementation as a Spring-bean and use it by default. Then, Cocoon
Core would replace it with CocoonSourceResolver using Spring
configurator features (property overriding, etc.).
Not sure if it helps you, but can't we change the SSF to just rely on
java.net.URL and use excaliburs jnet underneath?
I don't know JNet and new solutions for source resolving so cannot
comment. Any pointers to documentation or discussions?
So far there is only the source code :(
Ok, we planned to do this step in Cocoon for years: just using plain
java.net.URL objects to get access the different sources.
Now, unfortunately even today, Sun has not provided a usable api to
register own url handlers. So this is the main challenge as you can only
register a url handler once for the whole jvm. And as some application
containers register their own url handler on startup, a webapp can't do
this anymore. Not to mention the problem when you have more than one
webapp trying to do this.
However, there is a trick (or call it hack) to circumvent this problem
by using reflection and registering a proxy which then forwards to the
appropriate url handler. Jnet has an implementation for this and is able
to forward it to excalibur's source resolver or more precisely directly
to the source factories. Now to work propertly for each request jnet
needs to be notified which source factories are available and when the
request is finished, this needs to be cleared. So it basically like the
context change we use in cocoon.
Then you can do something like URL u = new URL("cocoon:/mypipeline");
u.getInputStream(); // or similar
Of course, when it comes to XML getting an input stream is not the best
choice, therefore there is an additional handling, so you can call
u.getContent(SAXResult.class) returning a SAXResult (from the javax.xml
package)
Using this you have direct streaming of sax events (if the source
provides it) without using any additional interfaces.
Now, this comes with one problem: the hack to register the url handler
proxy might not work on all jvms, it should work on all Sun jvms and
getting it running on Harmony shouldn't be a problem. I think its
running on ibms jvm as well, but i'm not sure.
So, this is the rough idea - the implementation is a first prototype I
did last year, so there might be some rough edges.
If this code is of interest we could also move it to Cocoon to have
better control.
Thanks Carsten for a summary!
To be honest, I'm not sure what kind of action we should take here. What you described sounds great
and it's very tempting to have sources properly working with just standard URL class.
Anyway, I'm little bit worried that whole things bases on *ugly* hack. I'm wondering how reliable
the solution is. I have a few additional questions:
1. Has this technique (not necessarily JNet's implementation) been used in some project? Or it's
your brilliant invention? :-)
2. What about debugging? What about stracktraces? Won't reflection hack break
something?
3. How intrusive it would be to integrate JNet into SSF?
I'm interested in experimenting with your work but since this issue is rather urgent I would like to
be able to count on your help if it's me who is going to resolve this problem.
What do others think?
PS. Here we are talking about SSF only at the moment. Inside SitemapServlet the CocoonSourceResolver
will be preserved, at least for now.
--
Grzegorz Kossakowski
Re: [2.2] "A simple CForms example" doesn't work...
Luca Morandini pisze: Grzegorz Kossakowski wrote: Luca Morandini pisze: Done: do you mind checking it and, in case, put it LIVE ? I've checked your changes and had to add some more because you missed some resource:// replacements with servlet:/. It's been put live now. It is only me, or the page has not been updated yet (cache issue ?) ? No, it's not a cache issue but nature of our documentation system. I've put it live so it's visible to everyone in Daisy. In order to publish updated document on our site some committer must run export task that will regenerate site and commit it to repository. This will be done shortly (as soon as someone has a few minutes spare to spend on this). -- Grzegorz
Re: SourceResolver in SSF
Grzegorz Kossakowski wrote:
Carsten Ziegeler pisze:
Filled up an issue: https://issues.apache.org/jira/browse/COCOON-2176
My plan is to register default Excalibur's SourceResolver
implementation as a Spring-bean and use it by default. Then, Cocoon
Core would replace it with CocoonSourceResolver using Spring
configurator features (property overriding, etc.).
Not sure if it helps you, but can't we change the SSF to just rely on
java.net.URL and use excaliburs jnet underneath?
I don't know JNet and new solutions for source resolving so cannot
comment. Any pointers to documentation or discussions?
So far there is only the source code :(
Ok, we planned to do this step in Cocoon for years: just using plain
java.net.URL objects to get access the different sources.
Now, unfortunately even today, Sun has not provided a usable api to
register own url handlers. So this is the main challenge as you can only
register a url handler once for the whole jvm. And as some application
containers register their own url handler on startup, a webapp can't do
this anymore. Not to mention the problem when you have more than one
webapp trying to do this.
However, there is a trick (or call it hack) to circumvent this problem
by using reflection and registering a proxy which then forwards to the
appropriate url handler. Jnet has an implementation for this and is able
to forward it to excalibur's source resolver or more precisely directly
to the source factories. Now to work propertly for each request jnet
needs to be notified which source factories are available and when the
request is finished, this needs to be cleared. So it basically like the
context change we use in cocoon.
Then you can do something like URL u = new URL("cocoon:/mypipeline");
u.getInputStream(); // or similar
Of course, when it comes to XML getting an input stream is not the best
choice, therefore there is an additional handling, so you can call
u.getContent(SAXResult.class) returning a SAXResult (from the javax.xml
package)
Using this you have direct streaming of sax events (if the source
provides it) without using any additional interfaces.
Now, this comes with one problem: the hack to register the url handler
proxy might not work on all jvms, it should work on all Sun jvms and
getting it running on Harmony shouldn't be a problem. I think its
running on ibms jvm as well, but i'm not sure.
So, this is the rough idea - the implementation is a first prototype I
did last year, so there might be some rough edges.
If this code is of interest we could also move it to Cocoon to have
better control.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
SourceResolver in SSF (was: Re: COCOON-2150 testing)
Carsten Ziegeler pisze: Filled up an issue: https://issues.apache.org/jira/browse/COCOON-2176 My plan is to register default Excalibur's SourceResolver implementation as a Spring-bean and use it by default. Then, Cocoon Core would replace it with CocoonSourceResolver using Spring configurator features (property overriding, etc.). Not sure if it helps you, but can't we change the SSF to just rely on java.net.URL and use excaliburs jnet underneath? I don't know JNet and new solutions for source resolving so cannot comment. Any pointers to documentation or discussions? -- Grzegorz Kossakowski
Re: COCOON-2150 testing
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: yes, this dependency on the Cocoon source resolver has to removed ASAP because otherwise our claim that SSF is independant from Cocoon core is bogus. Filled up an issue: https://issues.apache.org/jira/browse/COCOON-2176 My plan is to register default Excalibur's SourceResolver implementation as a Spring-bean and use it by default. Then, Cocoon Core would replace it with CocoonSourceResolver using Spring configurator features (property overriding, etc.). Not sure if it helps you, but can't we change the SSF to just rely on java.net.URL and use excaliburs jnet underneath? Carsten Additionally, I think we should move BlockContext source implementation from components to impl module of SSF. Those two should resolve this issue. -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [GSoC_2008] Project ideas
On Mar 17, 2008, at 11:30 AM, Grzegorz Kossakowski wrote: Reinhard Poetz pisze: My statement was meant to be more general (SSF + Spring migration + Schema support). For an SSF project only, I don't see enough work (I only know about SAX buffering and support for redirects as missing features) ... but maybe I'm wrong here. There is not that much work left in "pure" SSF (cocoon-servlet- service-impl module) but there is still a room for improvement in module containing components integrating SSF and Cocoon (cocoon- servlet-service-components). Mentioned SAX buffer support involves modifications in impl and components modules. I would add to the list of nice-to-have-in-SSF servlet discovery feature based on some conditions (e.g. returning 200 status code as response to certain request path). This way one could discover blocks providing certain services (e.g. skinning). Nothing more comes to my mind right now. $ find cocoon/core/cocoon-servlet-service/cocoon-servlet-service- impl -name "*.java" | xargs grep TODO | wc -l 18 I'm not so sure that this is "not much" :) Vadim
Re: COCOON-2150 testing
Reinhard Poetz pisze: yes, this dependency on the Cocoon source resolver has to removed ASAP because otherwise our claim that SSF is independant from Cocoon core is bogus. Filled up an issue: https://issues.apache.org/jira/browse/COCOON-2176 My plan is to register default Excalibur's SourceResolver implementation as a Spring-bean and use it by default. Then, Cocoon Core would replace it with CocoonSourceResolver using Spring configurator features (property overriding, etc.). Additionally, I think we should move BlockContext source implementation from components to impl module of SSF. Those two should resolve this issue. -- Grzegorz Kossakowski
Re: [GSoC_2008] Project ideas
On 17 Mar 2008, at 13:53, Reinhard Poetz wrote: Jeremy Quinn wrote: Hi Reinhard On 13 Mar 2008, at 15:54, Reinhard Poetz wrote: Yesterday I was introduced to an Austrian student who would be interested in working on a GSoC for the Cocoon project this year. The best idea we've had so far was was an upgrade of cForms to Dojo 1.x (or replacing it with something else if that is what the community is interested in). Argh. I have been researching this for the past few weeks with the intention of starting work to make this upgrade myself. I guess I should have mentioned this earlier . I doubt I am eligible for GSoC :) What should we do? go ahead! I'm sure that we will find something else that is of interest to potential applicants that would want to work on the Dojo upgrade (broader support for widgets, making Javascript optional, etc.). Yes, there is a lot to do in CForms, even after changing it to use Dojo 1.n. IMHO all of the work CForms needs is dependant on the switch to the new Dojo. For instance it seems pointless working on Dojofying old widgets (etc.) if the API is changing. I suggest we put together a road-map for what we need to do. Here is a possible start (off the top of my head) : 1) Switch to Dojo 1.n, reworking current Widgets and infrastructure to use new Dojo APIs. 2) Re-write existing Widgets that still use 3rd-party libraries, as Dojo Widgets. 3) All CForms Widgets to be rendered as Dojo Widgets to get a consistent visual theme, theme modification, WAI behaviour etc. 4) Find a way to allow HTMLArea (etc.) to be a plugin replacement for Dojo Rich Text Editor (as I assume this would have been replaced in step 2). 5) Make use of Dojo Layout Widgets when rendering CForms. 6) Implement a nice solution for compiling minimised JavaScript to support a specific Form/Webapp/Project/Site. 7) Perform client-side validation (as defined in CForms Model) where possible eg. RegExp, Min/Max, Range, Required, etc. etc. 8) Melding Dojo's and Cocoon's I18n into a coherent whole. 9) Re-work BrowserUpdate mechanism to allow DOM/Widget Update as well as DOM Replacement, to overcome issues with broken round-tripping with certain Widgets in Repeaters (eg. populated fileupload). 10) Deprecate FormsTransformer in favour of the CForms JX Macros, cleanup support for obsolete schema. There are probably many more, let's discuss :) Apart from item (1), the order is not so important. Unless I suddenly get more work, I can work on item (1) now. If anyone wants to take up any of the other issues as a GSoC project, I would definitely consider offering myself as a mentor, if that would be useful. Ugh, so now I have to GOMA and actually deliver =:-0 (Thanks for the gentle kick, Reinhard :) best regards Jeremy
[jira] Updated: (COCOON-2176) Remove dependency on CocoonSourceResolver from Servlet Service Framework
[ https://issues.apache.org/jira/browse/COCOON-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2176: - Attachment: COCOON-2176-Webapp.tar.gz Added test-case for this problem. Just enter main directory and call mvn package jetty:run. You will see following exception: 2008-03-17 16:31:20.728::WARN: Nested in org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.servletservice.demo1.servlet': Cannot resolve reference to bean 'org.apache.cocoon.servletservice.demo2.servlet' while setting bean property 'connections' with key [TypedStringValue: value [demo2], target type [null]]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.servletservice.demo2.servlet': Invocation of init method failed; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'org.apache.excalibur.source.SourceResolver' is defined: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'org.apache.excalibur.source.SourceResolver' is defined at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:378) [...] > Remove dependency on CocoonSourceResolver from Servlet Service Framework > > > Key: COCOON-2176 > URL: https://issues.apache.org/jira/browse/COCOON-2176 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Grzegorz Kossakowski > Attachments: COCOON-2176-Webapp.tar.gz > > > The Servlet Service Framework depends on CocoonSourceResolver class from > cocoon-core. CocoonSourceResolver class is used to resolve paths in > context-path using custom source implementation, see ServletFactoryBean class > for details. > The SSF is meant to be Cocoon-independent subproject so this dependency must > be removed as soon as possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2176) Remove dependency on CocoonSourceResolver from Servlet Service Framework
[ https://issues.apache.org/jira/browse/COCOON-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2176: - Description: The Servlet Service Framework depends on CocoonSourceResolver class from cocoon-core. CocoonSourceResolver class is used to resolve paths in context-path using custom source implementation, see ServletFactoryBean class for details. The SSF is meant to be Cocoon-independent subproject so this dependency must be removed as soon as possible. was: The Servlet Service Framework depends on CocoonSourceResolver class from cocoon-core. CocoonSourceResolver class is used to resolve paths in context-path using custom source implementation, see ServletFactoryBean class for details. The SSF is meant to be Cocoon-independent subproject so this dependency must be removed as soon. > Remove dependency on CocoonSourceResolver from Servlet Service Framework > > > Key: COCOON-2176 > URL: https://issues.apache.org/jira/browse/COCOON-2176 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Grzegorz Kossakowski > > The Servlet Service Framework depends on CocoonSourceResolver class from > cocoon-core. CocoonSourceResolver class is used to resolve paths in > context-path using custom source implementation, see ServletFactoryBean class > for details. > The SSF is meant to be Cocoon-independent subproject so this dependency must > be removed as soon as possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2176) Remove dependency on CocoonSourceResolver from Servlet Service Framework
Remove dependency on CocoonSourceResolver from Servlet Service Framework Key: COCOON-2176 URL: https://issues.apache.org/jira/browse/COCOON-2176 Project: Cocoon Issue Type: Task Components: - Servlet service framework Reporter: Grzegorz Kossakowski The Servlet Service Framework depends on CocoonSourceResolver class from cocoon-core. CocoonSourceResolver class is used to resolve paths in context-path using custom source implementation, see ServletFactoryBean class for details. The SSF is meant to be Cocoon-independent subproject so this dependency must be removed as soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSoC_2008] Project ideas
Reinhard Poetz pisze: My statement was meant to be more general (SSF + Spring migration + Schema support). For an SSF project only, I don't see enough work (I only know about SAX buffering and support for redirects as missing features) ... but maybe I'm wrong here. There is not that much work left in "pure" SSF (cocoon-servlet-service-impl module) but there is still a room for improvement in module containing components integrating SSF and Cocoon (cocoon-servlet-service-components). Mentioned SAX buffer support involves modifications in impl and components modules. I would add to the list of nice-to-have-in-SSF servlet discovery feature based on some conditions (e.g. returning 200 status code as response to certain request path). This way one could discover blocks providing certain services (e.g. skinning). Nothing more comes to my mind right now. -- Grzegorz Kossakowski
Re: "Normal" release artifacts
On Mar 16, 2008, at 10:42 AM, Reinhard Poetz wrote: Vadim Gritsenko wrote: IMHO what's good a downloadable release if 'cocoon.sh run' does not work? I'm not sure if I understand your concerns here correctly. Maybe I wasn't clear about what release artifacts I want to create. Here's the list: 1. cocoon-core-2.2.0.zip cocoon-servlet-service-1.0.0.zip cocoon-configuration-1.0.0.zip 2. cocoon-fop-1.0.0.zip cocoon-forms-1.0.0.zip ... [all the other blocks] 3. cocoon-2.2-getting-started-1.0.0.zip cocoon-2.2-legacy-getting-started-1.0.0.zip 4. cocoon-samples-1.0.0.zip 1. and 2. are the releases of our production ready sources (+ docs, +javadocs, +binaries). If somebody wants to use Cocoon in one of his projects and doesn't want to use Maven 2, Ivy or the Maven Ant tasks, he has to download them and add the libraries to his (web) application. To some extend it is even dangerous to add third-party libraries because this might lead to the inclusion of conflicting versions (or at least to unintended duplication) just because you add the libraries of several e.g. Cocoon blocks that were created at different times. The second purpose of 1. and 2. is providing a single release artifact of parts that belong together (docs, apidocs, sources, binaries). As it was pointed out several times by you and others, it feels strange to have only Maven 2 release artifacts. 3. and 4. are different. 'cocoon-2.2-getting-started' is a suggestion how you could organize a Cocoon project that uses blocks and that uses Ant as build system. We could also have a 'cocon-2.2- legacy-getting-started' package, that uses Cocoon the old way without using the SSF infrastructure. 'cocoon-samples' is the package for that the 'cocoon.sh run' proposal applies, IMO. One of the points of such release is to make it one stop shop, to get everything up and running in one quick download. Is 'cocoon-samples' good enough to be the one-stop-shop that you intend? However, I would like add a big warning message, that it is not supposed to be used as starting-point for a new Cocoon project. If it includes core + all released blocks + all samples + all 3rd party dependencies -- yes I think that's exactly what I had in mind. So let me ask again: Do we need third-party libraries in 1. and 2. or not? (For 3. and 4. it's clear to me because they wouldn't be useable otherwise.) It would be good to have required dependencies there as well but given existence of 4. it is IMHO less critical. Vadim
Re: COCOON-2150 testing
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
Hello guys,
I believe that COCOON-2150 is finally fixed but that was quite
radical change involving lots of conditional coding craft so I cannot
be entirely sure if I hadn't missed any obscure case.
Therefore I would like you to give latest trunk Cocoon version
extensive testing and observing if there are no errors reported by
servlet container or Cocoon.
Looks good to me! The integration tests run through, I've tested it
with two internal projects and also tested with Corona.
You mentioned that Corona does not rely on CocoonSourceResolver but on
JNet. How Corona could work with SSF if it has dependency on
CocoonSourceResolver?
We haven't implemented source resolving yet but only use the SSF to manage the
Corona servlet. Before your patch we saw a lot of exceptions in the console when
we set status codes.
Thanks a lot, Grzegorz!
No problem, I'm glad to hear it's working fine. :-)
- o -
On my personal feature list for SSF, only SAX buffering and the
support for redirects are missing but this shouldn't block a 1.0 release.
+1. Those issues could be implemented in 1.1.0 release.
I'm still not entirely comfortable with SSF's dependency on
CocoonSourceResolver. I have investigated further into that and I have
already prepared a test-case presenting the problem. I'll file up an
issue today.
Anyway, I don't want to block this release. We can always cut 1.1.0 as
soon as the dependency is removed.
yes, this dependency on the Cocoon source resolver has to removed ASAP because
otherwise our claim that SSF is independant from Cocoon core is bogus.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Embedding Cocoon (was: Re: [GSoC_2008] Project ideas)
On Mar 17, 2008, at 11:15 AM, Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: External HTTP crawler is not a replacement for cocoon embedding APIs (which what our CLI was, allows you to embed cocoon and use it from within another java application, together with simple main() wrapper). I believe that similar effect could be achieved by application imitating DispatcherServlet from SSF. If application wants to embed Cocoon it should do basic initialization that DispatcherServlet does and call SitemapServlet.forward() method. Of course that means the application would need to implement few classes imitating ServletContext, Request, Respone but I don't it's that hard... WDYT? Yep. That's exactly how it was done -- see: http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/commandline/ Vadim
Embedding Cocoon (was: Re: [GSoC_2008] Project ideas)
Vadim Gritsenko pisze: External HTTP crawler is not a replacement for cocoon embedding APIs (which what our CLI was, allows you to embed cocoon and use it from within another java application, together with simple main() wrapper). I believe that similar effect could be achieved by application imitating DispatcherServlet from SSF. If application wants to embed Cocoon it should do basic initialization that DispatcherServlet does and call SitemapServlet.forward() method. Of course that means the application would need to implement few classes imitating ServletContext, Request, Respone but I don't it's that hard... WDYT? -- Grzegorz Kossakowski
Re: [GSoC_2008] Project ideas
Vadim Gritsenko wrote:
On Mar 16, 2008, at 7:07 AM, Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
On Mar 13, 2008, at 11:54 AM, Reinhard Poetz wrote:
Yesterday I was introduced to an Austrian student who would be
interested in
working on a GSoC for the Cocoon project this year.
The best idea we've had so far was was an upgrade of cForms to Dojo
1.x (or
replacing it with something else if that is what the community is
interested in).
Yes that is a good one.
+1
Any other suggestions? (the deadline for project proposals is
Monday, 17th of March)
Finish SSF implementation? There is a lot of TODOs in there last
time I've seen it.
+1
Optimize SSF? Get rid of buffering on service invocations - or at
least past SAX buffer around.
Actually, real streaming is not possible but using SAX buffer is a
good idea so: +1 for this proposal. I would add:
1. Migrate more stuff to Spring (like i18n transformer, databases
stuff, etc.)
2. Write complete Schema for all of our grammars (JX, Forms, Sitemap,
etc.)
WDYT?
+1 for the ideas, but they are very specific and only for insiders
like you.
I don't think SSF work is for insiders only. After all, you were one of
folks saying that SSF can be used without Cocoon. Which means you only
need javax.servlet knowledge to make progress on this work...
My statement was meant to be more general (SSF + Spring migration + Schema
support).
For an SSF project only, I don't see enough work (I only know about SAX
buffering and support for redirects as missing features) ... but maybe I'm wrong
here.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [GSoC_2008] Project ideas
On Mar 16, 2008, at 7:07 AM, Reinhard Poetz wrote: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: On Mar 13, 2008, at 11:54 AM, Reinhard Poetz wrote: Yesterday I was introduced to an Austrian student who would be interested in working on a GSoC for the Cocoon project this year. The best idea we've had so far was was an upgrade of cForms to Dojo 1.x (or replacing it with something else if that is what the community is interested in). Yes that is a good one. +1 Any other suggestions? (the deadline for project proposals is Monday, 17th of March) Finish SSF implementation? There is a lot of TODOs in there last time I've seen it. +1 Optimize SSF? Get rid of buffering on service invocations - or at least past SAX buffer around. Actually, real streaming is not possible but using SAX buffer is a good idea so: +1 for this proposal. I would add: 1. Migrate more stuff to Spring (like i18n transformer, databases stuff, etc.) 2. Write complete Schema for all of our grammars (JX, Forms, Sitemap, etc.) WDYT? +1 for the ideas, but they are very specific and only for insiders like you. I don't think SSF work is for insiders only. After all, you were one of folks saying that SSF can be used without Cocoon. Which means you only need javax.servlet knowledge to make progress on this work... Vadim
Re: [GSoC_2008] Project ideas
On Mar 17, 2008, at 7:28 AM, Reinhard Poetz wrote: Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Another idea: Provide a command-line interface again, maybe by working together with the Forrest folks so that they can migrate to 2.2? +100! I hope that you don't want to mimic our previous implementation of CLI that seriously impacted our APIs. I would like to see CLI implemented using external tools. My first step would be looking into Droids: | Droids - Droids aims to be an intelligent standalone crawl framework that External HTTP crawler is not a replacement for cocoon embedding APIs (which what our CLI was, allows you to embed cocoon and use it from within another java application, together with simple main() wrapper). Vadim
Re: COCOON-2150 testing
Reinhard Poetz pisze: Grzegorz Kossakowski wrote: Hello guys, I believe that COCOON-2150 is finally fixed but that was quite radical change involving lots of conditional coding craft so I cannot be entirely sure if I hadn't missed any obscure case. Therefore I would like you to give latest trunk Cocoon version extensive testing and observing if there are no errors reported by servlet container or Cocoon. Looks good to me! The integration tests run through, I've tested it with two internal projects and also tested with Corona. You mentioned that Corona does not rely on CocoonSourceResolver but on JNet. How Corona could work with SSF if it has dependency on CocoonSourceResolver? Thanks a lot, Grzegorz! No problem, I'm glad to hear it's working fine. :-) - o - On my personal feature list for SSF, only SAX buffering and the support for redirects are missing but this shouldn't block a 1.0 release. +1. Those issues could be implemented in 1.1.0 release. I'm still not entirely comfortable with SSF's dependency on CocoonSourceResolver. I have investigated further into that and I have already prepared a test-case presenting the problem. I'll file up an issue today. Anyway, I don't want to block this release. We can always cut 1.1.0 as soon as the dependency is removed. I believe that SSF is ready to be released. If nobody objects, I will create the release artifacts tommorrow, together with cocoon-parent and cocoon-configuration. +1 and thanks again. -- Grzegorz Kossakowski
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: If I understood some discussion on [EMAIL PROTECTED] correctly, we would also have to put NOTICE and LICENSE into the main directory of each "sub-tree", that in our case relates to each of our modules that are released separately. Yes. We should do this "clean-up work" in one go as soon as there is a Maven 2 plugin available, that picks up those files and puts them into META-INF. No need to wait for a plugin, we can just add this to our parent pom: .. src/main/resources . META-INF LICENSE* NOTICE* Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Test release artifacts - Legal requirements check
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
David Crossley wrote:
I saw that some committers have been using lowercase filenames
e.g. "notice.txt", so the "release-builder" needs to handle that.
Is there some requirement that the file names of notice.txt and
license.txt have to be either lower or upper case? Or is it up to us?
See http://www.apache.org/dev/apply-license.html#license-file-name
so we should name them "NOTICE" and "LICENSE".
We should use the same name throughout all modules.
If I understood some discussion on [EMAIL PROTECTED] correctly, we would also have to
put NOTICE and LICENSE into the main directory of each "sub-tree", that in our
case relates to each of our modules that are released separately.
We should do this "clean-up work" in one go as soon as there is a Maven 2 plugin
available, that picks up those files and puts them into META-INF.
WDOT?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: COCOON-2150 testing
Grzegorz Kossakowski wrote:
Hello guys,
I believe that COCOON-2150 is finally fixed but that was quite radical
change involving lots of conditional coding craft so I cannot be
entirely sure if I hadn't missed any obscure case.
Therefore I would like you to give latest trunk Cocoon version extensive
testing and observing if there are no errors reported by servlet
container or Cocoon.
Looks good to me! The integration tests run through, I've tested it with two
internal projects and also tested with Corona.
Thanks a lot, Grzegorz!
- o -
On my personal feature list for SSF, only SAX buffering and the support for
redirects are missing but this shouldn't block a 1.0 release.
I believe that SSF is ready to be released. If nobody objects, I will create the
release artifacts tommorrow, together with cocoon-parent and cocoon-configuration.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [GSoC_2008] Project ideas
Jeremy Quinn wrote:
Hi Reinhard
On 13 Mar 2008, at 15:54, Reinhard Poetz wrote:
Yesterday I was introduced to an Austrian student who would be
interested in
working on a GSoC for the Cocoon project this year.
The best idea we've had so far was was an upgrade of cForms to Dojo
1.x (or
replacing it with something else if that is what the community is
interested in).
Argh.
I have been researching this for the past few weeks with the intention
of starting work to make this upgrade myself.
I guess I should have mentioned this earlier .
I doubt I am eligible for GSoC :)
What should we do?
go ahead! I'm sure that we will find something else that is of interest to
potential applicants that would want to work on the Dojo upgrade (broader
support for widgets, making Javascript optional, etc.).
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [GSoC_2008] Project ideas
Jeremy Quinn pisze: Hi Reinhard On 13 Mar 2008, at 15:54, Reinhard Poetz wrote: Yesterday I was introduced to an Austrian student who would be interested in working on a GSoC for the Cocoon project this year. The best idea we've had so far was was an upgrade of cForms to Dojo 1.x (or replacing it with something else if that is what the community is interested in). Argh. I have been researching this for the past few weeks with the intention of starting work to make this upgrade myself. I guess I should have mentioned this earlier . I doubt I am eligible for GSoC :) What should we do? Hello Jeremy, Have you considered becoming a mentor? -- Grzegorz Kossakowski
Re: [GSoC_2008] Project ideas
Hi Reinhard On 13 Mar 2008, at 15:54, Reinhard Poetz wrote: Yesterday I was introduced to an Austrian student who would be interested in working on a GSoC for the Cocoon project this year. The best idea we've had so far was was an upgrade of cForms to Dojo 1.x (or replacing it with something else if that is what the community is interested in). Argh. I have been researching this for the past few weeks with the intention of starting work to make this upgrade myself. I guess I should have mentioned this earlier . I doubt I am eligible for GSoC :) What should we do? regards Jeremy
Re: [GSoC_2008] Project ideas
Felix Knecht wrote: I'm quite sure, that CForms is much more popular and used than the CLI. I also think that upgrading Dojo (or something else) will give a much larger idea of how things (Java, Javasrcipt (Flowscript), XML, XSL) can work together than providing a CLI. Just my thoughts. Regards Felix Yes I think I agree with Felix on this part. It will allow the student to learn a lot about Cocoon. +1 for the Dojo upgrade! Jeroen
Re: [GSoC_2008] Project ideas
+1 for Dojo 1.x in CForms. I knew that you would like it ;-) Very :-) I've posted a project description at http://wiki.apache.org/general/SummerOfCode2008#cocoon-forms-dojo-upgrade I could also think about not only upgrading but also fix things never work in ajax mode like [1], [2] and integrate new features of dojo1.1 to cocoon like TreeWidget (which IMO never really worked in C2.*), DojoGrids, ... [1] Doublelistbox https://issues.apache.org/jira/browse/COCOON-1822 ;-) [2] fi:validation-errors https://issues.apache.org/jira/browse/COCOON-1570 and others Regards felix
Re: [GSoC_2008] Project ideas
Gabriel Gruber wrote:
> >>> Yesterday I was introduced to an Austrian student who would be
> >>> interested in
> >>> working on a GSoC for the Cocoon project this year.
> >>>
> >>> The best idea we've had so far was was an upgrade of cForms to Dojo
> >>> 1.x (or
> >>> replacing it with something else if that is what the community is
> >>> interested in).
> >>
> >> Yes that is a good one.
> >
> > +1
+1 for Dojo 1.x in CForms.
I knew that you would like it ;-)
I've posted a project description at
http://wiki.apache.org/general/SummerOfCode2008#cocoon-forms-dojo-upgrade
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [GSoC_2008] Project ideas
Reinhard Poetz schrieb: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: On Mar 13, 2008, at 11:54 AM, Reinhard Poetz wrote: Yesterday I was introduced to an Austrian student who would be interested in working on a GSoC for the Cocoon project this year. The best idea we've had so far was was an upgrade of cForms to Dojo 1.x (or replacing it with something else if that is what the community is interested in). +1 Another idea: Provide a command-line interface again, maybe by working together with the Forrest folks so that they can migrate to 2.2? I'm quite sure, that CForms is much more popular and used than the CLI. I also think that upgrading Dojo (or something else) will give a much larger idea of how things (Java, Javasrcipt (Flowscript), XML, XSL) can work together than providing a CLI. Just my thoughts. Regards Felix
Re: [GSoC_2008] Project ideas
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
+1 for the ideas, but they are very specific and only for insiders
like you. Grzegorz, do you still consider applying for GSoC this year?
Not sure. I'd love to apply and do some more Cocoon-related work during
the summer but I'm really concerned about USD ratings. :-(
All in all, I have to pay bills like everyone other and I think that
these days I cannot trust USD anymore. However, I'm still considering
prons and cons...
Another idea: Provide a command-line interface again, maybe by working
together with the Forrest folks so that they can migrate to 2.2?
+100!
I hope that you don't want to mimic our previous implementation of CLI
that seriously impacted our APIs. I would like to see CLI implemented
using external tools.
My first step would be looking into Droids:
| Droids - Droids aims to be an intelligent standalone crawl framework that
| automatically seeks out relevant online information based on the user's
| specifications. The core is a simple crawler which can be easily extended by
| plugins. So if a project/app needs special processing for a crawled url one
| can easily write a plugin to implement the functionality
[http://labs.apache.org/labs.html]
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: David Crossley wrote: I saw that some committers have been using lowercase filenames e.g. "notice.txt", so the "release-builder" needs to handle that. Is there some requirement that the file names of notice.txt and license.txt have to be either lower or upper case? Or is it up to us? See http://www.apache.org/dev/apply-license.html#license-file-name so we should name them "NOTICE" and "LICENSE". We should use the same name throughout all modules. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Created: (COCOON-2175) Multipage form sample broken
Multipage form sample broken Key: COCOON-2175 URL: https://issues.apache.org/jira/browse/COCOON-2175 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Ross McDonald Hi, while poking around on 'http://cocoon.zones.apache.org/demos/trunk/samples/', I also noticed the multipage form sample is broken. It looks like it is probably the Ajax playing up, so the screens are not rendered correctly. Grzegorz commented : 'Apparently HTML returned by this samples contains some fi: elements that were not transformed into HTML so it looks like a bug.' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
