headers
Felix Knecht | 1 Jan 01:56
Picon
Favicon

Re: [Vote] Cocoon Release 2.1.11

Carsten Ziegeler schrieb:
> Hi,
> 
> i've put up the 2.1.11 release at:
> 
> http://people.apache.org/~cziegeler/releases/cocoon/
> 
> please check, verify and cast your votes.

I found some (most likely more exist) not working samples, but they are all in the 'Unstable Blocks':
- http://localhost:8888/samples/blocks/captcha/simple
- http://localhost:8888/samples/blocks/mail/mail/index.html
- http://localhost:8888/docs/userdocs/actions/sendmail-action.html
- http://localhost:8888/docs/userdocs/xsp/sendmail.html
- http://localhost:8888/samples/blocks/petstore/ (most tables seem not being created on startup)
- http://localhost:8888/samples/blocks/qdox/welcome (only J2SE samples are working)

I don't think that this is a blocker, so
+1

Felix
Permalink | Reply | 0 comments |
headers
Michael Wechner | 1 Jan 14:10

Re: [PROPOSAL] Micro-Cocoon

Sylvain Wallez wrote:

>Jeroen Reijn wrote:
>  
>
>>Reinhard,
>>
>>sounds like a good thing. I guess not only Indoqa will get a benefit
>>out of this. Put it in the whiteboard, so if needed and possible other
>>people can help out and perhaps join the discussion?
>>    
>>
>
>+1 !
>  
>

+1

Michael

>Sylvain
>
>  
>

--

-- 
Michael Wechner
Wyona      -   Open Source Content Management - Yanel, Yulup
http://www.wyona.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
solprovider (JIRA | 1 Jan 20:21
Picon
Favicon

[jira] Closed: (COCOON-2074) Build ignores custom applications


     [
https://issues.apache.org/jira/browse/COCOON-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

solprovider closed COCOON-2074.
-------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 2.1.11)
                   2.1.12-dev (Current SVN)

Tested successfully:
1. Create new directory in src/webapp.
2. Add "Hello World" application to new directory.
3. Build and run Cocoon.
4. Browse to http://127.0.0.1:8888/{newdirectory}/  (Final slash is required due to different issue.)
5. See Hello World.

Thank you Carsten.  The new code is cleaner than the original and my proposals.

Applications not requiring Java compilation can be created in src/webapp; the standard build will
include the applications.

> Build ignores custom applications
> ---------------------------------
>
>                 Key: COCOON-2074
>                 URL: https://issues.apache.org/jira/browse/COCOON-2074
>             Project: Cocoon
>          Issue Type: Improvement
(Continue reading)

Permalink | Reply | 0 comments |
headers
solprovider | 1 Jan 21:19
Picon
Favicon

Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml

> Now, I'll not comment on all of this, but I still have a few comments:
> a) you still did not come up with a use case or a sample for the need of
> this patch.
> b) all your patches actually broke the build as they copied way too
> much, for instance the samples and test-suit dir should only be copied
> if they are not excluded during the build.
> c) I just applied a patch which should do what you want to do without
> breaking the build.
> d) I guess that there will be more maintenance releases of 2.1.x - so
> 2.1.11 won't be the last.
> e) The timing for applying this patch and the way it was done was
> not...well...optimal.
> f) I'll now continue with preparing the release.
> Thanks
> Carsten Ziegeler

a)  The documentation does not explain how to create an application.
The "samples" application is in the src/webapp directory.  Placing new
applications in the same directory is a reasonable assumption for
developers not discouraged by the lack of instructions.
- The use case is to add a simple (no Java) Cocoon application, build, and run.
- Would you please link to a good example of what information is
expected with proposed improvements?
- OT: My new application includes Java code.  My guesswork did not
discover how the standard build could compile the code, so I wrote a
separate process.  This cannot be the expected practice.

b) That is why having an experienced Cocoon Committer involved is a
very good thing.
c) You included my suggestion and improved the existing code.  Good job.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Reinhard Poetz | 1 Jan 21:26
Picon
Favicon

ServletSource#getInputStream()


Can somebody explain the purpose of this code to me? What's the use case that 
makes a second request necessary?

public InputStream getInputStream() throws IOException,
     SourceException {
     try {
         connect();
         if (servletConnection.getResponseCode() != HttpServletResponse.SC_OK) {
           ... redo the request here ...
         }

         return this.servletConnection.getInputStream();
     } catch (ServletException e) {
         throw new CascadingIOException(e.getMessage(), e);
     }
}

Thanks!

--

-- 
Reinhard Pötz                            Managing Director, {Indoqa} GmbH
                           http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair        reinhard <at> apache.org
_________________________________________________________________________
Permalink | Reply | 1 comment |
headers
Grzegorz Kossakowski | 1 Jan 23:34
Favicon
Gravatar

Re: ServletSource#getInputStream()

Reinhard Poetz pisze:
> 
> Can somebody explain the purpose of this code to me? What's the use case
> that makes a second request necessary?

Yes, sure. It has close relation to the fact that we use Conditional GETs/POSTs for implementing
caching of servlet source. For details see my explanations of the code

> public InputStream getInputStream() throws IOException,
>     SourceException {
>     try {
>         connect();

Let's assume we are making POST request to a servlet service.
When connect() is called this.servletConnection.requestBody contains serialized content coming from
calling servlet that will be POSTed to the called servlet. Call of connect() method does actual
request to the servlet.

>         if (servletConnection.getResponseCode() !=
> HttpServletResponse.SC_OK) {
>           ... redo the request here ...

Here should testing is little bit weird because it should only test if SC_NOT_MODIFIED was returned
by called servlet. The situation is that called servlet responded that cached result of its previous
call is still valid. However, we are in getInputStream() so it means that calling servlet does not
have cached response anymore and it asks for a fresh content. That means we need to make a second
request, this time not a conditional one, asking for a content.

The problem is, that for POST requests when there is something to REPOST this code is broken which
is what Vadim found a few months ago. I discussed this problem with Vadim and Leszek and I remember
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robin Wyles (JIRA | 2 Jan 13:23
Picon
Favicon

[jira] Updated: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation


     [
https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robin Wyles updated COCOON-2133:
--------------------------------

    Attachment: RevisedResizeOperationPatch.txt

Revised patch that fixes a bug with the previous patch where scaling with allowEnlarge property would be
ignored when only one dimension needs to be reduced in size.

> Addition of "allow-enlarge" parameter to ImageOp resize operation
> -----------------------------------------------------------------
>
>                 Key: COCOON-2133
>                 URL: https://issues.apache.org/jira/browse/COCOON-2133
>             Project: Cocoon
>          Issue Type: Improvement
>          Components: Blocks: ImageOp
>    Affects Versions: 2.1.11, 2.2-dev (Current SVN)
>            Reporter: Robin Wyles
>            Priority: Minor
>         Attachments: ResizeOperation.patch, RevisedResizeOperationPatch.txt
>
>
> The addition of an "allow-enlarge" parameter to the resize operation allows the user to control whether
an image should be enlarged by the operation. 
> This new  parameter is declared in the sitemap like so:
> <map:read type="imageop" src="image.jpg">
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robin Wyles (JIRA | 2 Jan 13:23
Picon
Favicon

[jira] Commented: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation


    [
https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555291#action_12555291
] 

Robin Wyles commented on COCOON-2133:
-------------------------------------

I'd be happy to provide a test-case but I can't see how to set one up to test a Reader. Looking at
SitemapComponentTestCase I don't see a corresponding "read" method and I can't find any test-cases for
other readers in any other blocks. If you can let me know how I might implement this test-case then I'll
write it.

In the meantime I attach a revised patch that fixes a bug with the previous patch where scaling with
allowEnlarge property would be ignored when only one dimension needs to be reduced in size.

> Addition of "allow-enlarge" parameter to ImageOp resize operation
> -----------------------------------------------------------------
>
>                 Key: COCOON-2133
>                 URL: https://issues.apache.org/jira/browse/COCOON-2133
>             Project: Cocoon
>          Issue Type: Improvement
>          Components: Blocks: ImageOp
>    Affects Versions: 2.1.11, 2.2-dev (Current SVN)
>            Reporter: Robin Wyles
>            Priority: Minor
>         Attachments: ResizeOperation.patch, RevisedResizeOperationPatch.txt
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robin Wyles (JIRA | 2 Jan 13:44
Picon
Favicon

[jira] Updated: (COCOON-2052) Allow Ajax submission of forms with empty upload field


     [
https://issues.apache.org/jira/browse/COCOON-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robin Wyles updated COCOON-2052:
--------------------------------

    Attachment: C2.2-AjaxForm-upload-patch.txt

Patch for 2.2-dev

> Allow Ajax submission of forms with empty upload field
> ------------------------------------------------------
>
>                 Key: COCOON-2052
>                 URL: https://issues.apache.org/jira/browse/COCOON-2052
>             Project: Cocoon
>          Issue Type: Improvement
>          Components: Blocks: Forms
>    Affects Versions: 2.1.11
>            Reporter: Robin Wyles
>            Priority: Minor
>             Fix For: 2.1.11
>
>         Attachments: AjaxForm-upload-patch.txt, C2.2-AjaxForm-upload-patch.txt
>
>
> Currently AjaxForm.js disables Ajax if the form contains an active upload field regardless of whether it
contains a value or not. This simple patch only disables Ajax if the upload field is active and has a value.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robin Wyles (JIRA | 2 Jan 13:46
Picon
Favicon

[jira] Updated: (COCOON-2052) Allow Ajax submission of forms with empty upload field


     [
https://issues.apache.org/jira/browse/COCOON-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robin Wyles updated COCOON-2052:
--------------------------------

        Fix Version/s: 2.2-dev (Current SVN)
    Affects Version/s: 2.2-dev (Current SVN)

> Allow Ajax submission of forms with empty upload field
> ------------------------------------------------------
>
>                 Key: COCOON-2052
>                 URL: https://issues.apache.org/jira/browse/COCOON-2052
>             Project: Cocoon
>          Issue Type: Improvement
>          Components: Blocks: Forms
>    Affects Versions: 2.1.11, 2.2-dev (Current SVN)
>            Reporter: Robin Wyles
>            Priority: Minor
>             Fix For: 2.1.11, 2.2-dev (Current SVN)
>
>         Attachments: AjaxForm-upload-patch.txt, C2.2-AjaxForm-upload-patch.txt
>
>
> Currently AjaxForm.js disables Ajax if the form contains an active upload field regardless of whether it
contains a value or not. This simple patch only disables Ajax if the upload field is active and has a value.

--

--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane