headers
Leszek Gawron | 1 Sep 01:34
Picon

Re: MonolithicServer22 and file deploying

Reinhard Poetz wrote:
> Leszek Gawron wrote:
>> Is there any reason for:
> 
> as the deployer has a very looong history, this part changed many times. 
> your replacement looks good to me. if it works, go for it.
It does.

I have already a production site running on mavenized cocoon 2.2 - I'll 
know soon enough if I break something :)

--
Leszek Gawron, IT Manager                          MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65
Permalink | Reply | 1 comment |
headers
Justin Erenkrantz | 1 Sep 05:18

Re: svn commit: r438796 - /apr/apr/trunk/atomic/unix/apr_atomic.c

On 8/31/06, William A. Rowe, Jr. <wrowe <at> rowe-clan.net> wrote:
> jerenkrantz <at> apache.org wrote:
> > --- apr/apr/trunk/atomic/unix/apr_atomic.c (original)
> > +++ apr/apr/trunk/atomic/unix/apr_atomic.c Wed Aug 30 22:10:22 2006
> > @@ -179,7 +179,7 @@
> >  #endif /* APR_OVERRIDE_ATOMIC_CAS32 */
> >
> >  #if !defined(APR_OVERRIDE_ATOMIC_DEC32)
> > -APR_DECLARE(apr_uint32_t) apr_atomic_dec32(volatile apr_uint32_t *mem)
> > +APR_DECLARE(int) apr_atomic_dec32(volatile apr_uint32_t *mem)
> >  {
>
> This appears to be a binary break.
>
> You realize we can play macro magic to enforce the correct type?
>
> In any case, unless I'm imagining things, please revert

No.  apr_atomic.h says:

APR_DECLARE(int) apr_atomic_dec32(...)

with this Solaris 10 specific Atomics impl saying:

APR_DECLARE(apr_uint32_t) apr_atomic_dec32(...)

All other implementations of dec32() in apr_atomic.c match the int
return - not the uint32_t return.  Therefore, on a 64-bit platform, it
never could compile with the signature mismatch.  My commit allows APR
to compile on 64-bit Solaris.  -- justin
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dennis Dam (JIRA | 1 Sep 09:10
Picon
Favicon

[jira] Commented: (COCOON-1897) i18n transformer: catch date parsing exceptions silently

    [ http://issues.apache.org/jira/browse/COCOON-1897?page=comments#action_12432078 ] 

Dennis Dam commented on COCOON-1897:
------------------------------------

I'm wondering what the status is right now? 

> i18n transformer: catch date parsing exceptions silently
> --------------------------------------------------------
>
>                 Key: COCOON-1897
>                 URL: http://issues.apache.org/jira/browse/COCOON-1897
>             Project: Cocoon
>          Issue Type: Improvement
>          Components: * Cocoon Core
>    Affects Versions: 2.1.8, 2.1.9, 2.1.10-dev (current SVN)
>            Reporter: Dennis Dam
>         Attachments: I18nTransformer.java.patch
>
>
> When an empty/incorrect date value is specified, the i18n transformer throws an exception, breaking the
whole page. 
> This exception needs to be caught and handled silently. The patch logs a warning message and returns an
empty result when date parsing fails.

--

-- 
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
-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nathaniel Alfred | 1 Sep 09:24

RE: patch for an entityResolver problem in xsl stylesheets ...

Hi Hussayn,

thanks for sharing your patch.
I'll have a look at it.

Cheers, Alfred.

-----Original Message-----
From: news [mailto:news <at> sea.gmane.org] On Behalf Of Hussayn dabbous
Sent: Mittwoch, 30. August 2006 22:48
To: dev <at> cocoon.apache.org
Subject: patch for an entityResolver problem in xsl stylesheets ...

Hi;

I tried to use external entities like &uuml; etc. in xsl stylesheets.
For this purpose in first place i added a DOCTYPE definition on top of
my stylesheet, i.e.:

<?xml version="1.0"?>
<!DOCTYPE mydoc [
   <!ENTITY % ISOlat1 PUBLIC "ISO 8879:1986//ENTITIES Added Latin
1//EN//XML" "ISOlat1.pen"> %ISOlat1;
]><xsl:stylesheet version="1.0">
...

I assumed, the default entity resolver would resolve the ISOlat1.pen,
but it did not!
I tracked this down and found, that entity resolution only works
correctly when i
(Continue reading)

Permalink | Reply | 2 comments |
headers
Carsten Ziegeler | 1 Sep 12:17
Picon
Favicon

Re: Property replacement in spring config files

Giacomo Pati wrote:

> 
> Good question. Never used "plain" Spring that way, but 
> Cocoon-Spring-Integration ;-) and I loved being able to do it. That way I 
> was able to have "Mock"-Beans for mode=dev (speed), "Local"-Beans for 
> mode=test (functional), and "Prod"-Beans for mode=prod (live) just with a 
> set of properties no need to change/filter any config file.
> 
Ah, ok - hmm, so the question is if we want to support this. The current
implementation has the advantage the most of the work is done by Spring
whereas with the old version we had to do everything ourselves.

Though I see your use case I would prefer going the "spring way" :)

Carsten

--

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Permalink | Reply | 0 comments |
headers
Leszek Gawron | 1 Sep 12:26
Picon

running modes: spring contexts and xconfs

Just like the settings can be separated into different running modes I 
would like to propose the same functionality for spring contexts and 
xconf files. This way starting cocoon in development mode could mock 
some services instead of providing real implementations.

--

-- 
Leszek Gawron, IT Manager                          MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65
Permalink | Reply | 0 comments |
headers
Leszek Gawron | 1 Sep 14:23
Picon

Exception on loading non existent settings

> 3188 [main] INFO / - Running in mode: dev
> 3204 [main] INFO org.apache.cocoon.core.container.spring.SettingsBeanFactoryPostProcessor -
Unable to read properties from directory '/WEB-INF/cocoon/properties/dev' - Continuing initialization.
> java.io.FileNotFoundException: ServletContext resource [/WEB-INF/cocoon/properties/dev/]
cannot be resolved to URL because it does not exist
> 	at org.springframework.web.context.support.ServletContextResource.getURL(ServletContextResource.java:112)
> 	at org.springframework.core.io.support.PathMatchingResourcePatternResolver.isJarResource(PathMatchingResourcePatternResolver.java:369)
> 	at org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:321)
> 	at org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:272)
> 	at
org.apache.cocoon.core.container.spring.AbstractSettingsBeanFactoryPostProcessor.readProperties(AbstractSettingsBeanFactoryPostProcessor.java:106) 

Carsten could you please revert to previous functionality where 
exception was only logged at DEBUG level?

--

-- 
Leszek Gawron, IT Manager                          MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65
Permalink | Reply | 1 comment |
headers
Carsten Ziegeler | 1 Sep 14:48
Picon
Favicon

Re: Exception on loading non existent settings

Leszek Gawron wrote:
>> 3188 [main] INFO / - Running in mode: dev
>> 3204 [main] INFO org.apache.cocoon.core.container.spring.SettingsBeanFactoryPostProcessor -
Unable to read properties from directory '/WEB-INF/cocoon/properties/dev' - Continuing initialization.
>> java.io.FileNotFoundException: ServletContext resource [/WEB-INF/cocoon/properties/dev/]
cannot be resolved to URL because it does not exist
>> 	at org.springframework.web.context.support.ServletContextResource.getURL(ServletContextResource.java:112)
>> 	at org.springframework.core.io.support.PathMatchingResourcePatternResolver.isJarResource(PathMatchingResourcePatternResolver.java:369)
>> 	at org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:321)
>> 	at org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:272)
>> 	at
org.apache.cocoon.core.container.spring.AbstractSettingsBeanFactoryPostProcessor.readProperties(AbstractSettingsBeanFactoryPostProcessor.java:106) 
> 
> Carsten could you please revert to previous functionality where 
> exception was only logged at DEBUG level?
> 
Ups, yepp sure; I'll do that tomorrow - in fact this is not an error at
all as it is allowed to not have this directory.

Carsten

--

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Permalink | Reply | 0 comments |
headers
Leszek Gawron (JIRA | 1 Sep 15:49
Picon
Favicon

[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin

    [ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432142 ] 

Leszek Gawron commented on COCOON-1898:
---------------------------------------

I have commited some initial version of xpatch support. There are some bugs and enhancements pending so I am
not closing the issue now.

> [PATCH] XPatch support for maven-cocoon-deployer-plugin
> -------------------------------------------------------
>
>                 Key: COCOON-1898
>                 URL: http://issues.apache.org/jira/browse/COCOON-1898
>             Project: Cocoon
>          Issue Type: Improvement
>          Components: - Build System: Maven
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Lars Trieloff
>         Attachments: maven-cocoon-deployer-plugin-with-xpatch-support.patch
>
>
> The cocoon-deployer-plugin has currently no support for XPatch, which makes it difficult to modify the
web.xml when developing cocoon blocks. For example the cocoon-xmldb-impl block should add, when
deployed, a servlet for xindice and a servlet mapping for the xindice servlet. This was possible in 2.1
using the XConfToolTask, but is no longer possible with the current state of the deployer-plugin.
> My patch adds support for patching the web.xml file using *.xweb files in the /conf directory of a block by
filtering the block's jar file during deployment for conf/*.xweb files, caching the patch document
temporarily and applying them (using code from the orgiginal XConfToolTask in 2.1) to the web.xml. The
patch has currently no support for other files than conf/*.xweb files and does not support any property expansion.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lars Trieloff (JIRA | 1 Sep 17:39
Picon
Favicon

[jira] Created: (COCOON-1906) [PATCH] simple-xml binding does not work with non file sources

[PATCH] simple-xml binding does not work with non file sources
--------------------------------------------------------------

                 Key: COCOON-1906
                 URL: http://issues.apache.org/jira/browse/COCOON-1906
             Project: Cocoon
          Issue Type: Bug
          Components: * Cocoon Core, Blocks: Forms
    Affects Versions: 2.2-dev (Current SVN)
            Reporter: Lars Trieloff

The cocoon forms flowscript API comes with a helper method form.loadXML, that retrieves data from an xml
document. The current implementation however does not work with documents that are referenced not as
files, but as SitemapSources, e.g. via the cocoon:/ or xmldb:// pseudo-protocol. In this case the Rhino
engine is unable to resolve the ambiguity between two method signatures:

org.mozilla.javascript.EvaluatorException:
"resource://org/apache/cocoon/forms/flow/javascript/Form.js", line 287: The choice of Java
constructor toSAX matching JavaScript argument types
(org.apache.cocoon.components.source.impl.SitemapSource,org.apache.cocoon.forms.util.XMLAdapter)
is ambiguous; candidate constructors are:
void toSAX(org.apache.excalibur.xml.sax.XMLizable,org.xml.sax.ContentHandler)
void toSAX(org.apache.excalibur.source.Source,org.xml.sax.ContentHandler)

--

-- 
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
(Continue reading)

Permalink | Reply | 11 comments |

Gmane