Re: Confusion about property-based beans configuration
Carsten Ziegeler pisze: > The javadoc is correct, "/" is used as the separator. Thanks. I corrected docs. > We distinguish between properties for configuring the application and > overriding bean definitions. The first one uses > /META-INF/cocoon/properties and all these values end up in the Settings > object. The properties can be used throughout the whole application and > references can occur in most configuration files like avalon configs, > spring bean configs, sitemaps etc. > > The bean override configuration is a special mechanism to override > settings of beans. There we use all files from /META-INF/cocoon/spring > to detect such things. > > So we have a clear separation between these two issues. Thanks for explanation! Everything works correctly now. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
[jira] Closed: (COCOON-2129) MailMessageSender does not allow setting of mail body by URL
[ https://issues.apache.org/jira/browse/COCOON-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Gritsenko closed COCOON-2129. --- Resolution: Fixed Fix Version/s: 2.1.11-dev (Current SVN) Applied to 2.1.x branch too. > MailMessageSender does not allow setting of mail body by URL > > > Key: COCOON-2129 > URL: https://issues.apache.org/jira/browse/COCOON-2129 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Mail >Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) >Reporter: Robin Wyles >Priority: Minor > Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) > > Attachments: MailMessageSender.patch > > > A simple null check on the wrong property prevents MailMessageSender working > when setting the email body content from a URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [cocoon-2.2] Deprecation
Reinhard Poetz wrote: Vadim Gritsenko wrote: I remember though that it was acknowledged that some of the stuff written on the sheet of deprecated things really had no substitutes or migration path towards 'new stuff'. Which only means that either it was on the list by mistake or because 'new stuff' is half baked at the moment. I think that you refer to the idea of deprecating sub-sitemaps which isn't an as good idea as it seemed from a quick glance because there is no equivalent to get the same functionality if you have to replace it with servlet-services and Spring AOP. Hence I won't suggest sub-sitemaps for deprecation. Ok. IIRC it wasn't the functionality of that made some people think that we should deprecate sub sitemaps but the part of sitemaps which causes a lot of complicated code that we have to maintain. However, deprecating shouldn't be a problem because there already exists a migration path of putting your component definitions into META-INF/cocoon/spring or META-INF/cocoon/avalon. Agreed, section can be deprecated if there is a replacement. However I would like to clarify though where components are declared. At the moment options are: For root container, includes: foo.jar!/META-INF/cocoon/spring /WEB-INF/cocoon/spring For sitemap container, includes: [sitemap-url]/cocoon/spring [sitemap-file]:/map:sitemap/map:components/map:include-beans To the sitemap container, adds: [sitemap-file]:/map:sitemap/map:components So if I understand correctly, only /map:sitemap/map:components section in the sitemap file is to be deprecated, for both avalon and spring components, and first three options are going to be supported. Is this correct? The second "big thing" for deprecation that we discussed in Rome was the cocoon:/ protocol and the the servlet:/ protocol instead. AFAIU the servlet:/ protocol doesn't provide all the "features" of the cocoon:/ protocol but that's mostly caused by getting rid of side-effects. Yep I'd like to hear more about those nasty "features" :) Can somebody who knows the code and the functionality of and cocoon:/ in more detail than me comment on this? - o - I think we should discuss these two big topics first and then we can continue with smaller things like the SimpleFormsTransformer, obsolete input modules, etc. I hope that I find some time soon to write a summary that contains a list with all those components. P.S. to Vadim: Of course we will give you a chance to comment on this :-) Thanks :) Vadim
[cocoon-2.2] Deprecation
Vadim Gritsenko wrote:
Grzegorz Kossakowski wrote:
Vadim, have you seen our whiteboard with the list of things people
have been wondering about when it
came to deprecation?
Seen it but I would not be able to recall it.
I remember though that it was acknowledged that some of the stuff
written on the sheet of deprecated things really had no substitutes or
migration path towards 'new stuff'. Which only means that either it was
on the list by mistake or because 'new stuff' is half baked at the moment.
I think that you refer to the idea of deprecating sub-sitemaps which isn't an as
good idea as it seemed from a quick glance because there is no equivalent to get
the same functionality if you have to replace it with servlet-services and
Spring AOP. Hence I won't suggest sub-sitemaps for deprecation.
IIRC it wasn't the functionality of that made some people think that
we should deprecate sub sitemaps but the part of sitemaps which
causes a lot of complicated code that we have to maintain. However, deprecating
shouldn't be a problem because there already exists a migration
path of putting your component definitions into META-INF/cocoon/spring or
META-INF/cocoon/avalon.
The second "big thing" for deprecation that we discussed in Rome was the
cocoon:/ protocol and the the servlet:/ protocol instead. AFAIU the servlet:/
protocol doesn't provide all the "features" of the cocoon:/ protocol but that's
mostly caused by getting rid of side-effects.
Can somebody who knows the code and the functionality of and
cocoon:/ in more detail than me comment on this?
- o -
I think we should discuss these two big topics first and then we can continue
with smaller things like the SimpleFormsTransformer, obsolete input modules,
etc. I hope that I find some time soon to write a summary that contains a list
with all those components.
P.S. to Vadim: Of course we will give you a chance to comment on this :-)
--
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: Preparing Cocoon 2.2-final
Grzegorz Kossakowski wrote: Vadim, have you seen our whiteboard with the list of things people have been wondering about when it came to deprecation? Seen it but I would not be able to recall it. I remember though that it was acknowledged that some of the stuff written on the sheet of deprecated things really had no substitutes or migration path towards 'new stuff'. Which only means that either it was on the list by mistake or because 'new stuff' is half baked at the moment. Vadim
Re: Zones are down
On 10/22/07, Joerg Heinicke <[EMAIL PROTECTED]> wrote: > Both trunk and 2.1 branch seem to have a problem ... Unless someone configured it in the last few months, I don't think the 2.2 trunk demo on the zones ever worked. To see how the demos are started: sudo su - cdemos crontab -l And the httpd configs are in /etc/apache2/httpd.conf which includes /home/config/cocoon.zone/apache2/local-httpd.conf See also http://www.apache.org/dev/solaris-zones.html for more info about the zones in general. -Bertrand
Re: Zones are down
On 10/25/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote: > ...I asked for karma several times exactly for this purpose without any luck. > I will try to contact > "right people" as soon as I figure out who has enough karma to give me some > on on our zone. > Then I could have a look I have created your account on the zone, will send you the info off-list. -Bertrand
Re: Preparing Cocoon 2.2-final
Vadim Gritsenko pisze: > Reinhard Poetz wrote: >> - deprecation (???) >>We have to deprecate everything that we want to remove in Cocoon 2.3. >>(If nobody beats me, I will start off a discussion about this soon.) > > I'd love to tune in into this thread but I'll be offline till Nov 5. Can > you promise not do any quick votes up to that time? :) No problem Vadim. I'll take care of reminding people. :) If you are going to be the one cooling our desire to deprecate lots of old junk I would fear that you are going to have a little bit problem with me. ;) After GT, I have got convinced to lobbying for deprecating lots of stuff. Vadim, have you seen our whiteboard with the list of things people have been wondering about when it came to deprecation? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Branches, Re: svn commit: r586238
Vadim Gritsenko pisze: > Vadim Gritsenko wrote: >> Grzegorz Kossakowski wrote: >> >> No problem... I almost forgot about branches, will have to fix those >> too... > > Done - only one change was required, in forms. Speaking of branches - > are these [1] branches still needed for anything or they - after RC2 is > done - are not needed anymore? IIUC, these are inactive branches, right? Thanks, Vadim! AFAIK, yes. I think we should remove all stale content both from branch and whiteboard directories. I'll take care of the stuff that I know of myself. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Preparing Cocoon 2.2-final
Reinhard Poetz wrote: - deprecation (???) We have to deprecate everything that we want to remove in Cocoon 2.3. (If nobody beats me, I will start off a discussion about this soon.) I'd love to tune in into this thread but I'll be offline till Nov 5. Can you promise not do any quick votes up to that time? :) Thanks Vadim
Branches, Re: svn commit: r586238
Vadim Gritsenko wrote: Grzegorz Kossakowski wrote: I thought that I was running a trunk version (done svn up before posting) but I forgot that I branched some modules before RC2 release and my working copy was sticking to these branches. Now everything runs fine. Sorry for a noise! No problem... I almost forgot about branches, will have to fix those too... Done - only one change was required, in forms. Speaking of branches - are these [1] branches still needed for anything or they - after RC2 is done - are not needed anymore? IIUC, these are inactive branches, right? Vadim [1] http://svn.apache.org/repos/asf/cocoon/branches/cocoon-2.2/
Re: [result][vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Reinhard Poetz pisze: > > The relese of these artifacts has been accepted by 5 +1 votes and no -1. > I will move the artifacts into the Apache Maven M2 sync repository asap > and also prepare an announcement mail. I was late on voting (gosh, I'm really busy now...) but I would like to say that I tested RC2 and everything seems to work ok. I'm also very happy to see it's happening and I think some kudos should really go to Reinhard for taking care of preparing release. BTW. When can we expect new release officialy announced? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Zones are down
Jeroen Reijn pisze: > Yes this still seems the case. Could somebody with enough karma and > knowledge have a look? > > Are these nightly builds or does somebody deploy a new version of both > demos? I asked for karma several times exactly for this purpose without any luck. I will try to contact "right people" as soon as I figure out who has enough karma to give me some on on our zone. Then I could have a look. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Zones are down
Yes this still seems the case. Could somebody with enough karma and knowledge have a look? Are these nightly builds or does somebody deploy a new version of both demos? Regards, Jeroen Reijn Joerg Heinicke wrote: Both trunk and 2.1 branch seem to have a problem ... Joerg
[jira] Updated: (COCOON-2142) getting an attribute of a xmlfilemodule returns 'org.apache.xerces.dom.AttrNSImpl' instead of a 'java.lang.String'
[
https://issues.apache.org/jira/browse/COCOON-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
christian planer updated COCOON-2142:
-
Description:
i have configured an xmlfilemodule in cocoon.xconf like this :
true
false
i try to access an an attribute from flowscript :
cmsProps.getAttribute("/cms/retouche/@maxPatternPerPage",null,null)
this line of code returns an 'org.apache.xerces.dom.AttrNSImpl' instead of a
'java.lang.String'
the same problem occurs when using the module inside a sitemap
this happens only in cocoon-2.1.11-dev. in cocoon 2.1.10 a string is returned.
thanks
was:
i have configured an xmlfilemodule in cocoon.xconf like this :
true
false
i try to access an an attribute from flowscript :
cmsProps.getAttribute("/cms/retouche/@maxPatternPerPage",null,null)
this line of code returns an 'org.apache.xerces.dom.AttrNSImpl' instead of a
'java.lang.String'
this happens only in cocoon-2.1.11-dev. in cocoon 2.1.10 a string is returned.
thanks
> getting an attribute of a xmlfilemodule returns
> 'org.apache.xerces.dom.AttrNSImpl' instead of a 'java.lang.String'
> ---
>
> Key: COCOON-2142
> URL: https://issues.apache.org/jira/browse/COCOON-2142
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.11-dev (Current SVN)
>Reporter: christian planer
>
> i have configured an xmlfilemodule in cocoon.xconf like this :
> class="org.apache.cocoon.components.modules.input.XMLFileModule"
> logger="core.modules.input" name="cms-props"
> role="org.apache.cocoon.components.modules.input.XMLFileModule">
>
> true
> false
>
> i try to access an an attribute from flowscript :
> cmsProps.getAttribute("/cms/retouche/@maxPatternPerPage",null,null)
> this line of code returns an 'org.apache.xerces.dom.AttrNSImpl' instead of a
> 'java.lang.String'
> the same problem occurs when using the module inside a sitemap
> this happens only in cocoon-2.1.11-dev. in cocoon 2.1.10 a string is returned.
> thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2142) getting an attribute of a xmlfilemodule returns 'org.apache.xerces.dom.AttrNSImpl' instead of a 'java.lang.String'
getting an attribute of a xmlfilemodule returns
'org.apache.xerces.dom.AttrNSImpl' instead of a 'java.lang.String'
---
Key: COCOON-2142
URL: https://issues.apache.org/jira/browse/COCOON-2142
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.11-dev (Current SVN)
Reporter: christian planer
i have configured an xmlfilemodule in cocoon.xconf like this :
true
false
i try to access an an attribute from flowscript :
cmsProps.getAttribute("/cms/retouche/@maxPatternPerPage",null,null)
this line of code returns an 'org.apache.xerces.dom.AttrNSImpl' instead of a
'java.lang.String'
this happens only in cocoon-2.1.11-dev. in cocoon 2.1.10 a string is returned.
thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
