Reinhard Pötz | 2 Feb 09:00
Picon
Favicon

Re: Using spring configurator (for properties) in block

Robby Pelssers wrote:
> Hi all,
> 
> I read the documentation on the spring configurator.  First let me
> describe the usecase.  I want to develop a block which should do not
> much more then reading xml files from the filesystem.  I want to use a
> property file for the sitemap of the block.
> 
>  
> 
> Example:
> 
> <map:generate src="file://${repository.dir.flyerdefinitions}/{1}.xml
> <file:///\\$%7brepository.dir.flyerdefinitions%7d\%7b1%7d.xml>" />
> 
>  
> 
> So I created following  property file in
> /META-INF/cocoon/properties/application.properties
> 
>  
> 
> repository.dir=D:/_testdata_
> 
> repository.dir.released=${repository._dir_}/XML Repository
> 
> repository.dir.flyerdefinitions=${repository._dir_.released}/Flyer
> Definitions
<snip/>

(Continue reading)

Carsten Ziegeler | 2 Feb 17:51
Picon
Favicon

Re: [RT] C3: Cleaning up SAX module

Andreas Pieber wrote:
> 
> I'm not convinced that removing XProducer and XConsumer will resolve all 
> problems described by you since you still need a reference to Cocoon (e.g. for 
> PipelineComponent and Producer/Consumer). 
Yes, you got me :)

> One possibility to get rid of all 
> references could be the spring framework. POJOs with a ContentHandler and an 
> setConsumer(Object) method could be (very easily) described in XML and wrapped 
> at runtime to "real" PipelineComponents.
Yes, but if I really want to do this, I can do this regardless if we
have SAXConsumer (XMLConsumer) or not.

> 
> An other option would be to let XProducer and XConsumer (maybe renaming them 
> to SAXProducer and SAXConsumer :) ) 
(Yes, we should rename them and I think we already agreed on this on)

> and just weaken the conditions. The 
> components simply check for an ContentHandler/LexicalHandler as they require. 
> With this approach you let the decision to the developer if he like to simply 
> inherit from the X-Interfaces and has an SAXPipelineComponent, a 
> ContentHandler and so on at once or do it on his own. WDYT about this 
> approach? 
Hmm, not sure :) Seems like a wrong compromise to me :) Either we really
want these interfaces for symmetrical reasons (which I think is not
worth doing it and given the different between the formats itself
doesn't help) or if we want the simplest approach for each type (xml,
dom, stax). I would vote for the second approach.
(Continue reading)

Picon
Favicon

[jira] Created: (COCOON3-24) Cleanup PipelineComponent#finish()

Cleanup PipelineComponent#finish()
----------------------------------

                 Key: COCOON3-24
                 URL: https://issues.apache.org/jira/browse/COCOON3-24
             Project: Cocoon 3
          Issue Type: Bug
          Components: cocoon-pipeline
            Reporter: Reinhard Poetz
            Assignee: Reinhard Poetz
             Fix For: 3.0.0-alpha-2

Remove the exception parameter from the PipelineComponent#finish() method.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Picon
Favicon

[jira] Assigned: (COCOON3-21) mac/linux bat-incompatibility


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

Reinhard Poetz reassigned COCOON3-21:
-------------------------------------

    Assignee: Reinhard Poetz  (was: Cocoon Developers Team)

> mac/linux bat-incompatibility
> -----------------------------
>
>                 Key: COCOON3-21
>                 URL: https://issues.apache.org/jira/browse/COCOON3-21
>             Project: Cocoon 3
>          Issue Type: Improvement
>          Components: cocoon-docs
>    Affects Versions: 3.0.0-alpha-1
>            Reporter: Andreas Pieber
>            Assignee: Reinhard Poetz
>             Fix For: 3.0.0-alpha-2
>
>         Attachments: linux-mac-exec.patch
>
>
> Since the REM tag is not know by linux/mac bash at this platforms all commands in the it.bat and
svn-release-tags.bat have to be executed by hand.
> Possible solution: bash executable doing the same as the .bat files
> Drawback: two files to maintain with (more or less) the identical content.

(Continue reading)

Picon
Favicon

[jira] Closed: (COCOON3-21) mac/linux bat-incompatibility


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

Reinhard Poetz closed COCOON3-21.
---------------------------------

    Resolution: Fixed

I've applied it.sh but not svn-release-tags.sh. If somebody wants to use it on mac/linux its better to copy
it manually than IMO.

Thanks Andreas!

> mac/linux bat-incompatibility
> -----------------------------
>
>                 Key: COCOON3-21
>                 URL: https://issues.apache.org/jira/browse/COCOON3-21
>             Project: Cocoon 3
>          Issue Type: Improvement
>          Components: cocoon-docs
>    Affects Versions: 3.0.0-alpha-1
>            Reporter: Andreas Pieber
>            Assignee: Reinhard Poetz
>             Fix For: 3.0.0-alpha-2
>
>         Attachments: linux-mac-exec.patch
>
>
(Continue reading)

Picon
Favicon

[jira] Created: (COCOON3-25) AbstractXMLPipe does the same as XMLConsumerAdapter.

AbstractXMLPipe does the same as XMLConsumerAdapter.
----------------------------------------------------

                 Key: COCOON3-25
                 URL: https://issues.apache.org/jira/browse/COCOON3-25
             Project: Cocoon 3
          Issue Type: Bug
          Components: cocoon-sax
    Affects Versions: 3.0.0-alpha-1
            Reporter: Reinhard Poetz
            Assignee: Reinhard Poetz
             Fix For: 3.0.0-alpha-2

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Picon
Favicon

[jira] Closed: (COCOON3-25) AbstractXMLPipe does the same as XMLConsumerAdapter.


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

Reinhard Poetz closed COCOON3-25.
---------------------------------

    Resolution: Fixed

> AbstractXMLPipe does the same as XMLConsumerAdapter.
> ----------------------------------------------------
>
>                 Key: COCOON3-25
>                 URL: https://issues.apache.org/jira/browse/COCOON3-25
>             Project: Cocoon 3
>          Issue Type: Bug
>          Components: cocoon-sax
>    Affects Versions: 3.0.0-alpha-1
>            Reporter: Reinhard Poetz
>            Assignee: Reinhard Poetz
>             Fix For: 3.0.0-alpha-2
>
>

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

(Continue reading)

Picon
Favicon

[jira] Closed: (COCOON3-24) Cleanup PipelineComponent#finish()


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

Reinhard Poetz closed COCOON3-24.
---------------------------------

    Resolution: Fixed

> Cleanup PipelineComponent#finish()
> ----------------------------------
>
>                 Key: COCOON3-24
>                 URL: https://issues.apache.org/jira/browse/COCOON3-24
>             Project: Cocoon 3
>          Issue Type: Bug
>          Components: cocoon-pipeline
>            Reporter: Reinhard Poetz
>            Assignee: Reinhard Poetz
>             Fix For: 3.0.0-alpha-2
>
>
> Remove the exception parameter from the PipelineComponent#finish() method.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

(Continue reading)

Favicon

Error:Cannot have multiple DOCTYPE declarations in Coccon sitemap

Hi All,

Iam using  Cocoon 2.1.10. 

I am using entity &deg; to display degree symbol in my xml. For the same
i am using serializerin my sitemap.xmap as follows

<map:serializer logger="sitemap.serializer.html" mime-type="text/xml"
name="ajaxxml"
                pool-max="${html-serializer.pool-max}"
                src="org.apache.cocoon.serialization.XMLSerializer">
	<doctype-public>-//W3C//DTD XHTML 1.1//EN</doctype-public>  
	<doctype-system>xhtml11-flat.dtd</doctype-system> 
        <encoding>UTF-8</encoding>
                <omit-xml-declaration>yes</omit-xml-declaration>
</map:serializer>

This particular piece is working like a charm in FireFox. I mean in the
XML is parsing properly. If  i try to acces my xml using Internet
Explorer(IE) i am getting the following xml parse error

========================================================================
=============

Cannot have multiple DOCTYPE declarations. Error processing resource
'http://localhost:8080/productpreview/transform/Produc...

<!DOCTYPE p PUBLIC "-//W3C//DTD XHTML 1.1//EN" "xhtml11-flat.dtd">
----------^

(Continue reading)

Picon
Favicon

[jira] Commented: (COCOON3-19) [PATCH] stax-sax converter


    [
https://issues.apache.org/jira/browse/COCOON3-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670131#action_12670131
] 

Reinhard Poetz commented on COCOON3-19:
---------------------------------------

Andreas, can you give a pointer to your message sent to the stax-utils community?

> [PATCH] stax-sax converter
> --------------------------
>
>                 Key: COCOON3-19
>                 URL: https://issues.apache.org/jira/browse/COCOON3-19
>             Project: Cocoon 3
>          Issue Type: Sub-task
>          Components: cocoon-stax
>            Reporter: Andreas Pieber
>            Assignee: Cocoon Developers Team
>         Attachments: cocooon-stax-converter.patch
>
>
> We experimented with wrappers to add SAX-components to StAX pipelines and with Adapters between StAX
pipelines and SAX pipelines. IMO they work quite fine :)
> The problem with this patch is that it relies on the stax-utils project. Most classes in
o.a.c.stax.converter.util are redistrubuted from the stax-utils
(https://stax-utils.dev.java.net/) project. This was required since there's an architectural issue
so that stax-utils can not be used directly as reference. I posted at the stax-utils dev mailing list two
weeks ago, if they could make some of their methods protected instead of private so that we could resolve
(Continue reading)


Gmane