Re: svn commit: r377171 - in /cocoon/trunk/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portal: pluto/ profile/ profile/impl/
Carsten Ziegeler wrote:
Ralph Goers schrieb:
I'm having a hard time understanding this. populate seems to go through
and figure out what all the page labels should be, but it doesn't do
anything with them. I assume this is part of the discussion we've been
having? As I said there I'm not even sure this is necessary. When Castor
builds the layout each named item should be able to create its page
label by doing:
Item item = getParent().getParent();
if (item == null || !(item instanceof NamedItem)) {
this.label = this.name;
} else {
this.label = item.getLabel() + . + this.name;
}
Yes, that's true. Now the question is: Where to put this code? We could
add this to the item.
My idea was to provide extensions to the profile manager which are able
to post process the profile, like adding the page labels.
This label will then picked up by the tab renderer - and this part is
currently missing. Hmm, perhaps you're right and we can add this code
directly to an item or named item. Have to think about it.
I would create a setLabel method to NamedItem (probably protected or
even private) and then have setName() call it.
Carsten
Re: svn commit: r377171 - in /cocoon/trunk/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portal: pluto/ profile/ profile/impl/
Ralph Goers wrote:
Item item = getParent().getParent();
if (item == null || !(item instanceof NamedItem)) {
this.label = this.name;
} else {
this.label = item.getLabel() + . + this.name;
}
I would create a setLabel method to NamedItem (probably protected or
even private) and then have setName() call it.
Ok, sounds good to me - I'll change that today. Don't we need a loop in
the code you provided above? For example if there sub tabs are not
directly nested inside the main tab?
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
[jira] Assigned: (COCOON-1744) NullPointerException in template block
[ http://issues.apache.org/jira/browse/COCOON-1744?page=all ] Leszek Gawron reassigned COCOON-1744: - Assign To: Leszek Gawron NullPointerException in template block -- Key: COCOON-1744 URL: http://issues.apache.org/jira/browse/COCOON-1744 Project: Cocoon Type: Bug Components: Blocks: Templating Versions: 2.2-dev (Current SVN) Reporter: Tim Williams Assignee: Leszek Gawron Priority: Minor Attachments: template_block.patch I have been unsuccessful actually building Cocoon so this is an untested patch. Can someone take a look and, if ok, apply to the template block? Thanks, --tim -- 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
Re: svn commit: r377178 - in /cocoon/trunk/cocoon-block-deployer: cocoon-deployer-core/src/main/java/org/apache/cocoon/deployer/applicationserver/ cocoon-deployer-core/src/test/java/org/apache/cocoon/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've used the cocoon-trunk/cocoon-block-deployer/cocoon-tutorial-simple-block to be precise On Mon, 13 Feb 2006, Giacomo Pati wrote: Date: Mon, 13 Feb 2006 11:02:20 +0100 (CET) From: Giacomo Pati [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: svn commit: r377178 - in /cocoon/trunk/cocoon-block-deployer: cocoon-deployer-core/src/main/java/org/apache/cocoon/deployer/applications erver/ cocoon-deployer-core/src/test/java/org/apache/cocoon/deployer/applications erver/ cocoon-deployer-plugin/src/m... --[PinePGP]--[begin]-- On Sun, 12 Feb 2006, [EMAIL PROTECTED] wrote: Date: Sun, 12 Feb 2006 14:13:22 - From: [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: cvs@cocoon.apache.org Subject: svn commit: r377178 - in /cocoon/trunk/cocoon-block-deployer: cocoon-deployer-core/src/main/java/org/apache/cocoon/deployer/applications erver/ cocoon-deployer-core/src/test/java/org/apache/cocoon/deployer/applications erver/ cocoon-deployer-plugin/src/m... Author: reinhard Date: Sun Feb 12 06:13:21 2006 New Revision: 377178 URL: http://svn.apache.org/viewcvs?rev=377178view=rev Log: COCOON-1759 - RAD works now for resources - thanks to Daniel's latest changes to block-fw. After integrating the reloading classloader into the blocks-fw we have everything we want :-) Can you explain this? I've tried to build and run with mvn cocoon:simple-deploy jetty6:run which worked so far hit the browser on http://localhost:/test which works as well but changing the test.xml under src/main/resources didn't show any effects. TIA -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com --[PinePGP]--- gpg: Signature made Mon Feb 13 11:02:21 2006 CET using DSA key ID 98E35590 gpg: Good signature from Giacomo Pati [EMAIL PROTECTED] gpg: aka Giacomo Pati [EMAIL PROTECTED] gpg: aka Giacomo Pati [EMAIL PROTECTED] --[PinePGP][end]-- - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD8FnWLNdJvZjjVZARAsncAJ9GXtN72FYnt9WIyx45nm2VlB8DvwCgy788 2WFZh/lj7rxYDhWVYIzTyTw= =X+QN -END PGP SIGNATURE-
Re: svn commit: r377178 - in /cocoon/trunk/cocoon-block-deployer: cocoon-deployer-core/src/main/java/org/apache/cocoon/deployer/applicationserver/ cocoon-deployer-core/src/test/java/org/apache/cocoon/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 13 Feb 2006, Giacomo Pati wrote: Date: Mon, 13 Feb 2006 11:05:09 +0100 (CET) From: Giacomo Pati [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: svn commit: r377178 - in /cocoon/trunk/cocoon-block-deployer: cocoon-deployer-core/src/main/java/org/apache/cocoon/deployer/applications erver/ cocoon-deployer-core/src/test/java/org/apache/cocoon/deployer/applications erver/ cocoon-deployer-plugin/src/m... --[PinePGP]--[begin]-- I've used the cocoon-trunk/cocoon-block-deployer/cocoon-tutorial-simple-block to be precise Just to let you know. I was corrected by Reinhart. The RAD works with the cocoon-trunk/cocoon-block-deployer/cocoon-deployer-plugin-demo module (and not the one I was using for my tests as mentioned above). Also one needs to have Eclipse auto-build enabled so that changed resources will be copied over to the target directory (which isn't that pretty IMHO but maybe this can be fixed anyhow as Eclipse isn't the only IDE used in the world ;-) Thanks and ciao - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD8GMjLNdJvZjjVZARAnjMAKDtn1xRnaVx6xujEAMIHMzhqcTHjgCglPGc eZoo1JHWPJDh0eJKNu4WxBM= =ilEo -END PGP SIGNATURE-
RAD with blocks
Giacomo Pati wrote:
Just to let you know.
I was corrected by Reinhart.
Reinhard
^ ;-)
The RAD works with the
cocoon-trunk/cocoon-block-deployer/cocoon-deployer-plugin-demo module
(and not the one I was using for my tests as mentioned above). Also one
needs to have Eclipse auto-build enabled so that changed resources will
be copied over to the target directory (which isn't that pretty IMHO but
maybe this can be fixed anyhow as Eclipse isn't the only IDE used in the
world ;-)
Basically I agree with you but as soon as the ReloadingClassloader is integrated
I don't see a reason not to use it at development time which makes
auto-compilation mandatory. I'm an Eclipse user, but don't support IDEA and
Netbeans auto-compilation either?
BTW, if somebody is interested in working on making blocks reality and is
looking for a manageable task, he can do the integration of the
ReloadingClassloader into the blocks-fw. If so, just let me know (so that we
don't duplicate our efforts).
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: RAD with blocks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 13 Feb 2006, Reinhard Poetz wrote: Date: Mon, 13 Feb 2006 12:17:26 +0100 From: Reinhard Poetz [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: RAD with blocks Giacomo Pati wrote: Just to let you know. I was corrected by Reinhart. Reinhard ^ ;-) Oops, I'm so sorry (one should write names by heart) The RAD works with the cocoon-trunk/cocoon-block-deployer/cocoon-deployer-plugin-demo module (and not the one I was using for my tests as mentioned above). Also one needs to have Eclipse auto-build enabled so that changed resources will be copied over to the target directory (which isn't that pretty IMHO but maybe this can be fixed anyhow as Eclipse isn't the only IDE used in the world ;-) Basically I agree with you but as soon as the ReloadingClassloader is integrated I don't see a reason not to use it at development time which makes auto-compilation mandatory. I'm an Eclipse user, but don't support IDEA and Netbeans auto-compilation either? Well, from a users POV an XML, XSLT, sitemap file is a totally different thing than a class file (which he obviously knows to be compiled first before being usable). - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD8G15LNdJvZjjVZARArneAJ4+5VT3T6EEtx8rEv3R7A1UVKVSxACgz0wV mTx5Q5A6lkdihRALGh+aCfk= =DXj3 -END PGP SIGNATURE-
Re: RAD with blocks
Giacomo Pati wrote:
Basically I agree with you but as soon as the ReloadingClassloader is
integrated I don't see a reason not to use it at development time
which makes auto-compilation mandatory. I'm an Eclipse user, but don't
support IDEA and Netbeans auto-compilation either?
Well, from a users POV an XML, XSLT, sitemap file is a totally different
thing than a class file (which he obviously knows to be compiled first
before being usable).
I'd say that we should wait for user feedback on this. The thing is that I
hesitate to make too many things configureable, but sure, if configurations are
required, we can add them.
Currently cocoon:simple-deploy points to ./target/classes. We can make this
configureable so that people can point to ./src/java/resources. The only thing
that I really want to avoid is the possibility to set two locations for a block,
one for the compiled Java classes and one for the resources (smells like FS ...).
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] Using Spring instead of ECM++
Ok, I just committed the initial prototyp. The spring based container is setup in the Cocoon class (in initialize). I think I've covered most of the Avalon stuff including pooled components (but have not tested this). The remaining part would be to use the spring based container instead of ECM++ which requires changes in the Cocoon class and in the tree processor. Changing the Cocoon class should be fairly easy while the tree processor is more work. Now, this work can't be done without possibly breaking Cocoon until the work is finished. So how do we proceed? Once we use the Spring based container we can simplify the whole setup process and clean up things like the CoreUtil and the Cocoon class. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 56 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-13022006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-13022006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-13022006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-13022006.jar -Dbuild=build/cocoon-13022006 gump-core [Working Directory:
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 56 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-13022006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-13022006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-13022006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-13022006.jar -Dbuild=build/cocoon-13022006 gump-core [Working Directory:
Logkit (I know, again) was [RT] Using Spring instead of ECM++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 13 Feb 2006, Carsten Ziegeler wrote: Once we use the Spring based container we can simplify the whole setup process and clean up things like the CoreUtil and the Cocoon class. While we are at discussing cleanups. What about also getting rid of logkit and use what we already have in our dependency lists (log4J, commons-logging, ...)? I think we definitively need to get a smaller footprint and also get committed to fewer alternatives (of which we do have too many now IMHO, not mentioning other stuff we carry with us just because we do have them since years). - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD8IrdLNdJvZjjVZARAoi+AKCDTGanvWO2Hkz0nPOmRrw78qevKwCgnqft fxZ9hMImd577AtnyHF1pYrA= =gP3Y -END PGP SIGNATURE-
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Giacomo Pati wrote: On Mon, 13 Feb 2006, Carsten Ziegeler wrote: Once we use the Spring based container we can simplify the whole setup process and clean up things like the CoreUtil and the Cocoon class. While we are at discussing cleanups. What about also getting rid of logkit and use what we already have in our dependency lists (log4J, commons-logging, ...)? Yes, please :) I would suggest log4j as commons-logging has problems with classloading (afair) and noone is using jdk14 logging. I think we definitively need to get a smaller footprint and also get committed to fewer alternatives (of which we do have too many now IMHO, Exactly :) not mentioning other stuff we carry with us just because we do have them since years). So true! Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Le 13 févr. 06, à 14:50, Carsten Ziegeler a écrit : Giacomo Pati wrote: ...What about also getting rid of logkit and use what we already have in our dependency lists (log4J, commons-logging, ...)? Yes, please :) I would suggest log4j as commons-logging has problems with classloading (afair) and noone is using jdk14 logging +1 for log4j -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Bertrand Delacretaz wrote: Le 13 févr. 06, à 14:50, Carsten Ziegeler a écrit : Giacomo Pati wrote: ...What about also getting rid of logkit and use what we already have in our dependency lists (log4J, commons-logging, ...)? Yes, please :) I would suggest log4j as commons-logging has problems with classloading (afair) and noone is using jdk14 logging +1 for log4j +1 too. Upayavira
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Upayavira wrote:
Bertrand Delacretaz wrote:
Le 13 févr. 06, à 14:50, Carsten Ziegeler a écrit :
Giacomo Pati wrote:
...What about also getting rid of logkit and use what we already have in
our dependency lists (log4J, commons-logging, ...)?
Yes, please :) I would suggest log4j as commons-logging has problems
with classloading (afair) and noone is using jdk14 logging
+1 for log4j
+1 too.
I agree with you. log4j is the defacto-standard (at least in all my Java
projects it is used).
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 13 Feb 2006, Carsten Ziegeler wrote: Once we use the Spring based container we can simplify the whole setup process and clean up things like the CoreUtil and the Cocoon class. While we are at discussing cleanups. What about also getting rid of logkit and use what we already have in our dependency lists (log4J, commons-logging, ...)? I think we definitively need to get a smaller footprint and also get committed to fewer alternatives (of which we do have too many now IMHO, not mentioning other stuff we carry with us just because we do have them since years). +0. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Carsten Ziegeler wrote: ... Yes, please :) I would suggest log4j as commons-logging has problems with classloading (afair) and noone is using jdk14 logging. Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a facade for other logging frameworks but it doesn't suffer from the classloading problems of commons-logging. It's used by the Apache directory project. I think it's being developed by the guy behind log4j. Regards, Niklas Therning
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Niklas Therning wrote: Carsten Ziegeler wrote: ... Yes, please :) I would suggest log4j as commons-logging has problems with classloading (afair) and noone is using jdk14 logging. Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a facade for other logging frameworks but it doesn't suffer from the classloading problems of commons-logging. It's used by the Apache directory project. I think it's being developed by the guy behind log4j. We have discussed that before. Personally, just using the de-facto standard of Log4J, if it is capable of meeting our requirements, keeps things simple. And simple is something that Cocoon seriously needs to be moving towards. We've been there and done that in relation to lots of dependencies. Regards, Upayavira
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Niklas Therning wrote: Carsten Ziegeler wrote: Yes, please :) I would suggest log4j as commons-logging has problems with classloading (afair) and noone is using jdk14 logging. Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a facade for other logging frameworks but it doesn't suffer from the classloading problems of commons-logging. It's used by the Apache directory project. I think it's being developed by the guy behind log4j. Given the Avalon framework interfaces, we already have a log abstraction using the LogEnabled and Logger interfaces. Proper wrappers are also provided for Log4J and have been for years. There's no value add in introducing YALF (Yet Another Logging Facade). In the future when your components have no ties to Avalon, just use Log4J directly.
Re: [RT] Using Spring instead of ECM++
Carsten Ziegeler wrote: Ok, I just committed the initial prototyp. The spring based container is setup in the Cocoon class (in initialize). I think I've covered most of the Avalon stuff including pooled components (but have not tested this). The remaining part would be to use the spring based container instead of ECM++ which requires changes in the Cocoon class and in the tree processor. Changing the Cocoon class should be fairly easy while the tree processor is more work. Now, this work can't be done without possibly breaking Cocoon until the work is finished. So how do we proceed? Once we use the Spring based container we can simplify the whole setup process and clean up things like the CoreUtil and the Cocoon class. It depends on how long time you think that it will take. If you think that it take a week or so I suggest that you branch cocoon-core, and work on the branch until it works again and merge it back then. In the meantime the rest of us try to avoid doing larger changes in cocoon-core trunk. If it takes like a month or so, it is better to try to do some splitting of cocoon-core first, so that you only need to branch the tree-processor and the top layer that contain the Cocoon object. In any case it must be done in a branch. We are making good progress with the blocks work, and having a cocoon-core that doesn't would be a far to large disruption. /Daniel
Re: svn commit: r377171 - in /cocoon/trunk/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portal: pluto/ profile/ profile/impl/
Carsten Ziegeler wrote:
Ralph Goers wrote:
Item item = getParent().getParent();
if (item == null || !(item instanceof NamedItem)) {
this.label = this.name;
} else {
this.label = item.getLabel() + . + this.name;
}
I would create a setLabel method to NamedItem (probably protected or
even private) and then have setName() call it.
Ok, sounds good to me - I'll change that today. Don't we need a loop in
the code you provided above? For example if there sub tabs are not
directly nested inside the main tab?
I don't believe a loop is required. Castor is creating each of the
NamedItems and so it provides the looping.
Ralph
Re: Unified directory layout for trunk?
* Carsten Ziegeler: Upayavira schrieb: Carsten Ziegeler wrote: I was just looking briefly at the current directory layout of trunk and it seems that we are currently using different layouts for the blocks. Most blocks follow the layout suggested recently while others like the databases or the xmldb do not. Is this supposed to change? My impression is that this is a proposed layout, we're waiting to see how the few converted classes work out before converting any of the rest. Yes, I know - but the problem imho is that some of the already converted blocks do not use the proposed layout, so basically - using some hard words - we already have a mess wrt directly layout :( I'm responsible for this mess on the xmldb and database blocks, sorry ;-) In fact, the only reason the old location for these two blocks is still present is because of the samples. I only took care of mavenizing the implementations. I will take a look at it. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: RAD with blocks
Reinhard Poetz wrote: Giacomo Pati wrote: Just to let you know. I was corrected by Reinhart. Reinhard ^ ;-) The RAD works with the cocoon-trunk/cocoon-block-deployer/cocoon-deployer-plugin-demo module (and not the one I was using for my tests as mentioned above). Also one needs to have Eclipse auto-build enabled so that changed resources will be copied over to the target directory (which isn't that pretty IMHO but maybe this can be fixed anyhow as Eclipse isn't the only IDE used in the world ;-) Basically I agree with you but as soon as the ReloadingClassloader is integrated I don't see a reason not to use it at development time which makes auto-compilation mandatory. I'm an Eclipse user, but don't support IDEA and Netbeans auto-compilation either? BTW, if somebody is interested in working on making blocks reality and is looking for a manageable task, he can do the integration of the ReloadingClassloader into the blocks-fw. If so, just let me know (so that we don't duplicate our efforts). RT: When we move to OSGi the Cocoon platform will contain the same basic standard OSGi framework and service bundles as Eclipse (or maybe from Felix). And a Cocoon block will basically be a bundle, and such can be developed with the plug-in development environment in Eclipse. Maybe Eclipse auto build is gathered in a few plug-ins, in that case we could just reuse them for Cocoon development. Anyone who knows how it works in Eclipse? /Daniel
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Giacomo Pati wrote: While we are at discussing cleanups. What about also getting rid of logkit and use what we already have in our dependency lists (log4J, commons-logging, ...)? I think we definitively need to get a smaller footprint and also get committed to fewer alternatives (of which we do have too many now IMHO, not mentioning other stuff we carry with us just because we do have them since years). I thought we already discussed this and made log4j the default? If that is the proposal, I'm fine with it. If the proposal means getting rid of our Logger abstraction layer I'm -1 on that. Ralph
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 13 Feb 2006, Berin Loritsch wrote: Date: Mon, 13 Feb 2006 09:58:06 -0500 From: Berin Loritsch [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++ Niklas Therning wrote: Carsten Ziegeler wrote: Yes, please :) I would suggest log4j as commons-logging has problems with classloading (afair) and noone is using jdk14 logging. Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a facade for other logging frameworks but it doesn't suffer from the classloading problems of commons-logging. It's used by the Apache directory project. I think it's being developed by the guy behind log4j. Given the Avalon framework interfaces, we already have a log abstraction using the LogEnabled and Logger interfaces. Proper wrappers are also provided for Log4J and have been for years. There's no value add in introducing YALF (Yet Another Logging Facade). And we do have to maintain the contract mentioned interface requires for backward compatability to the dozends of component we already have. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD8KHDLNdJvZjjVZARAlaeAKCW4kkKDFgPq+v8NKVyWT6Q1LQ6jwCfec0w cHmzs1ofZIwV5oHP8baHbLw= =hG9K -END PGP SIGNATURE-
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 13 Feb 2006, Ralph Goers wrote: Date: Mon, 13 Feb 2006 07:07:58 -0800 From: Ralph Goers [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org, [EMAIL PROTECTED] To: dev@cocoon.apache.org Subject: Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++ Giacomo Pati wrote: While we are at discussing cleanups. What about also getting rid of logkit and use what we already have in our dependency lists (log4J, commons-logging, ...)? I think we definitively need to get a smaller footprint and also get committed to fewer alternatives (of which we do have too many now IMHO, not mentioning other stuff we carry with us just because we do have them since years). I thought we already discussed this and made log4j the default? If that is the proposal, I'm fine with it. If the proposal means getting rid of our Logger abstraction layer I'm -1 on that. If the logger abstraction you mentioned is the Avalon LogEnabled one than yes, we will still have to support that for backward compatability. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD8KJ6LNdJvZjjVZARAulkAJ0Td8xAWkSHgVvdBrS+QbiLy8RbuQCfdrV4 SRnldYHsPL4ohOutML/9h2k= =zl97 -END PGP SIGNATURE-
Re: Unified directory layout for trunk?
Carsten, I'm wondering where to put the mock classes for block databases. Where did you put portal's mock classes? Also, I cannot manage to find anything in src/blocks where I left the samples, still in need for M10N. Has it been removed? Concerning cocoon-xmldb, apart from the samples, what's wrong? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Giacomo Pati wrote: If the logger abstraction you mentioned is the Avalon LogEnabled one than yes, we will still have to support that for backward compatability. Of course we will support LogEnabled - with the only difference that you always get a wrapper around a Log4J (or whatever we decide) logger. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Berin Loritsch wrote: Niklas Therning wrote: Carsten Ziegeler wrote: Yes, please :) I would suggest log4j as commons-logging has problems with classloading (afair) and noone is using jdk14 logging. Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a facade for other logging frameworks but it doesn't suffer from the classloading problems of commons-logging. It's used by the Apache directory project. I think it's being developed by the guy behind log4j. Given the Avalon framework interfaces, we already have a log abstraction using the LogEnabled and Logger interfaces. Proper wrappers are also provided for Log4J and have been for years. There's no value add in introducing YALF (Yet Another Logging Facade). In the future when your components have no ties to Avalon, just use Log4J directly. Yes, I wouldn't have a problem with that. Just wanted to mention slf4j for those who hadn't heard of it before. But it seem like you guys already been discussing these thing in the past (I wouldn't know since I'm quite new to the list). /Niklas
Re: Unified directory layout for trunk?
* Jean-Baptiste Quenot: Also, I cannot manage to find anything in src/blocks where I left the samples, still in need for M10N. Has it been removed? OK, you removed the svn:externals to blocks. Got it. Need to checkout whole Cocoon. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: Unified directory layout for trunk?
Jean-Baptiste Quenot wrote: Carsten, I'm wondering where to put the mock classes for block databases. Where did you put portal's mock classes? The portals block has no mocks in 2.2 :) I think you're approach for the mocks is valid. What do others think? Also, I cannot manage to find anything in src/blocks where I left the samples, still in need for M10N. Has it been removed? Don't know - if it has you have to find the last revision containing the stuff. Concerning cocoon-xmldb, apart from the samples, what's wrong? For example compare the cocoon-template block with the cocoon-xmldb block. The template block contains a module for the implementation containing the source. It also uses the suggest m2 layout (src/main/java). So all you have to do, is create this impl module and move the sources into the appropriate directory. For the samples, you can create a samples modules. Have a look at the authentication-fw block for an example. HTH Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Daniel Fagerstrom wrote: It depends on how long time you think that it will take. If you think that it take a week or so I suggest that you branch cocoon-core, and work on the branch until it works again and merge it back then. In the meantime the rest of us try to avoid doing larger changes in cocoon-core trunk. If it takes like a month or so, it is better to try to do some splitting of cocoon-core first, so that you only need to branch the tree-processor and the top layer that contain the Cocoon object. Ok, I think this will take one or two days until Cocoon runs again while it might take a little bit longer to polish everything. In any case it must be done in a branch. We are making good progress with the blocks work, and having a cocoon-core that doesn't would be a far to large disruption. I'm wondering if I'm changing the right place. Now the switch to Spring is finished cocoon-core will look different (less use of Avalon). Now, has this any influence on the blocks implementation like block-fw? I looked there briefly and saw that for example ServiceManager is used there for getting components from a block. We should change that as well and perhaps use our own interface? And if the cocoon-core uses Spring what has to be done in the blocks-fw? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Unified directory layout for trunk?
Jean-Baptiste Quenot schrieb: * Jean-Baptiste Quenot: Also, I cannot manage to find anything in src/blocks where I left the samples, still in need for M10N. Has it been removed? OK, you removed the svn:externals to blocks. Got it. Need to checkout whole Cocoon. Or you can checkout just the xmldb directory from the blocks: http://svn.apache.org/repos/asf/cocoon/blocks/xmldb/trunk/ Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Unified directory layout for trunk?
* Carsten Ziegeler: Jean-Baptiste Quenot wrote: Carsten, I'm wondering where to put the mock classes for block databases. Where did you put portal's mock classes? The portals block has no mocks in 2.2 :) I think you're approach for the mocks is valid. What do others think? OK, I created cocoon-databases and put impl and mocks within. Concerning cocoon-xmldb, apart from the samples, what's wrong? So all you have to do, is create this impl module and move the sources into the appropriate directory. OK. But where do I put web.xml, cocoon.xconf and sitemap.xmap customizations? Is there a M10N documentation available? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: [RT] Using Spring instead of ECM++
Carsten Ziegeler said: Daniel Fagerstrom wrote: It depends on how long time you think that it will take. If you think that it take a week or so I suggest that you branch cocoon-core, and work on the branch until it works again and merge it back then. In the meantime the rest of us try to avoid doing larger changes in cocoon-core trunk. If it takes like a month or so, it is better to try to do some splitting of cocoon-core first, so that you only need to branch the tree-processor and the top layer that contain the Cocoon object. Ok, I think this will take one or two days until Cocoon runs again while it might take a little bit longer to polish everything. Really? I haven't been able to get a running portal on trunk in a while, so I'll look forward to being able to have that back in a couple of days.
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Ralph Goers wrote: Carsten Ziegeler said: Giacomo Pati wrote: If the logger abstraction you mentioned is the Avalon LogEnabled one than yes, we will still have to support that for backward compatability. Of course we will support LogEnabled - with the only difference that you always get a wrapper around a Log4J (or whatever we decide) logger. What do you mean by always? I thought that we switched the default from logkit to log4j a while ago? What more is needed? This switch never happened - the idea behind this is to remove the support for other logging frameworks completly. No more you can use this or you can use that or you can implement your own, but a simple use log4j. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Ralph Goers schrieb: Carsten Ziegeler said: Daniel Fagerstrom wrote: It depends on how long time you think that it will take. If you think that it take a week or so I suggest that you branch cocoon-core, and work on the branch until it works again and merge it back then. In the meantime the rest of us try to avoid doing larger changes in cocoon-core trunk. If it takes like a month or so, it is better to try to do some splitting of cocoon-core first, so that you only need to branch the tree-processor and the top layer that contain the Cocoon object. Ok, I think this will take one or two days until Cocoon runs again while it might take a little bit longer to polish everything. Really? I haven't been able to get a running portal on trunk in a while, so I'll look forward to being able to have that back in a couple of days. Ah, sorry, again one of my too short sentences: no, I'm not able to run the portal or any other block right now and I don't have a clue how to fix this. I meant that I need one or two days to replace ECM++ with Spring and then Cocoon runs again in the same way it runs today. Getting the blocks/samples run again is currently out of my scope for the Spring integration. But I really would love to have running stuff again :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Carsten Ziegeler said: Ralph Goers wrote: Carsten Ziegeler said: What do you mean by always? I thought that we switched the default from logkit to log4j a while ago? What more is needed? This switch never happened - the idea behind this is to remove the support for other logging frameworks completly. No more you can use this or you can use that or you can implement your own, but a simple use log4j. If that is the case then I'm -1 on this. We use our own logging framework with Cocoon.
Re: [RT] Using Spring instead of ECM++
Carsten Ziegeler said: Ah, sorry, again one of my too short sentences: no, I'm not able to run the portal or any other block right now and I don't have a clue how to fix this. I meant that I need one or two days to replace ECM++ with Spring and then Cocoon runs again in the same way it runs today. Getting the blocks/samples run again is currently out of my scope for the Spring integration. But I really would love to have running stuff again :) I guess you are braver than me. I haven't checked in my change to EncodeURLTransformer into trunk because I don't know how to test it.
Re: [RT] Using Spring instead of ECM++
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: It depends on how long time you think that it will take. If you think that it take a week or so I suggest that you branch cocoon-core, and work on the branch until it works again and merge it back then. In the meantime the rest of us try to avoid doing larger changes in cocoon-core trunk. If it takes like a month or so, it is better to try to do some splitting of cocoon-core first, so that you only need to branch the tree-processor and the top layer that contain the Cocoon object. Ok, I think this will take one or two days until Cocoon runs again while it might take a little bit longer to polish everything. A branch of cocoon-core then. In any case it must be done in a branch. We are making good progress with the blocks work, and having a cocoon-core that doesn't would be a far to large disruption. I'm wondering if I'm changing the right place. Now the switch to Spring is finished cocoon-core will look different (less use of Avalon). Now, has this any influence on the blocks implementation like block-fw? Probably ;) Take a look at the BlockManager. It first set up a container which for the moment is hardwired to o.a.c.container.ECMBlockServiceManager, but could be another container. The container is supposed to register the components that it want to make available to other block in a ServiceManagerRegistry, and it get components from other container through it parent manager (also the ServiceManagerRegsitry). Then a block servlet (typically o.a.c.sitemap.SitemapServlet that contains the tree processor) is set up and is given the component manager of the block. The contract for the Container is probably not the best possible, but I needed something to be able to continue. Comments are welcome. I looked there briefly and saw that for example ServiceManager is used there for getting components from a block. We should change that as well and perhaps use our own interface? Maybe, it was first idea as well. But the ServiceManager is a rather generic interface, so I don't see that we would find something different, so I don't see what it would by us to change. And in the somewhat longer perspective I would prefer using the OSGi interfaces for service management. And if the cocoon-core uses Spring what has to be done in the blocks-fw? I don't know how you are planning to integrate Spring, so it is hard to answer. If we think about it, the main reason for having a component manager within the sitemap and even in subsitemaps, is that 1) sitemap-components and ordinary components was supposed to be different concern in early Cocoon designs, and 2) that subsitemaps has been the major mechanism for modularizing large applications. We don't care about the difference between sitemap-components and ordinary components anymore and with blocks there is a better modularization mechanism than subsitemaps. So question is why we should configure components within sitemaps anymore. IMO it is a mix of concern and makes the tree-processor unnecessarily complicated. So I don't know if the tree-processor should use Spring (or any other component manager) anymore, it would be enough to just feed it a service manager. The Cocoon object and the CocoonServlet are not used anymore in the blocks fw. I tried to adapt to them early on but it required to much work to integrate the blocks within them without risking to disturb the rest of the system. Besides that, the setup sequence tended to give me severe headache, so I rewrote it to something less flexible and less complicated. /Daniel
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 13 Feb 2006, Ralph Goers wrote: Date: Mon, 13 Feb 2006 13:16:37 -0800 (PST) From: Ralph Goers [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++ Carsten Ziegeler said: Ralph Goers wrote: Carsten Ziegeler said: What do you mean by always? I thought that we switched the default from logkit to log4j a while ago? What more is needed? This switch never happened - the idea behind this is to remove the support for other logging frameworks completly. No more you can use this or you can use that or you can implement your own, but a simple use log4j. If that is the case then I'm -1 on this. We use our own logging framework with Cocoon. Can you explain how you use your own under Cocoon? Separate LogEnabled impls? CommonsLogging? - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD8Q4hLNdJvZjjVZARAp62AJ92Hg0ekydAdKmzdwnZiG+dMQ4RCQCfYXsw W/ed3irPnhqg09jTL9D9BvY= =9wQc -END PGP SIGNATURE-
Re: [RT] Using Spring instead of ECM++
Carsten Ziegeler skrev: Ralph Goers schrieb: Carsten Ziegeler said: Daniel Fagerstrom wrote: It depends on how long time you think that it will take. If you think that it take a week or so I suggest that you branch cocoon-core, and work on the branch until it works again and merge it back then. In the meantime the rest of us try to avoid doing larger changes in cocoon-core trunk. If it takes like a month or so, it is better to try to do some splitting of cocoon-core first, so that you only need to branch the tree-processor and the top layer that contain the Cocoon object. Ok, I think this will take one or two days until Cocoon runs again while it might take a little bit longer to polish everything. Really? I haven't been able to get a running portal on trunk in a while, so I'll look forward to being able to have that back in a couple of days. Ah, sorry, again one of my too short sentences: no, I'm not able to run the portal or any other block right now and I don't have a clue how to fix this. I meant that I need one or two days to replace ECM++ with Spring and then Cocoon runs again in the same way it runs today. Getting the blocks/samples run again is currently out of my scope for the Spring integration. But I really would love to have running stuff again :) I think everything run today, it is only that no one have cared to try. AFAIK, we hadn't made any changes of core that should affect anything since the M10N. All blocks work have been done in separate projects. So the cocoon-webapp when I tried it the last time (mvn war:inplace jetty6:run). That is without blocks. To add blocks it should be enough to 1) add them to the dependencies in the cocoon-webapp POM. 2) copy the content of src/main/resources/WEB-INF to the cocoon-webapp/src/main/webapp/WEB-INF. AFAICS, the only thing that would be required to make Cocoon trunk work as before the M10N, would be to write a Maven plugin that does this copying automatically for the configuration files in blocks. I haven't done it because I'm more thrilled about getting the real blocks to work. But for those of you that work on blocks like the portal, it would certainly be worthwhile. /Daniel
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Giacomo Pati wrote: - Can you explain how you use your own under Cocoon? Separate LogEnabled impls? CommonsLogging? I implement org.apache.avalon.excalibur.logging.LoggerManager and org.apache.avalon.excalibur.logging.Logger. These then interface with my logging framework. Ralph
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
On 14.02.2006, at 00:50, Carsten Ziegeler wrote: Giacomo Pati wrote: On Mon, 13 Feb 2006, Carsten Ziegeler wrote: Once we use the Spring based container we can simplify the whole setup process and clean up things like the CoreUtil and the Cocoon class. While we are at discussing cleanups. What about also getting rid of logkit and use what we already have in our dependency lists (log4J, commons-logging, ...)? Yes, please :) I would suggest log4j as commons-logging has problems with classloading (afair) and noone is using jdk14 logging. As a side note: There is a new release of commons-logging coming out (rc is already available) Simon and Robert claim that most of the classloading problems have been solved. JCL has now extensive tests for classloading. But as long as all libraries log into the same log file I don't care anymore ...sorry, the logging discussion finally make me go whatever! cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: New skin for web site
hepabolu wrote: BTW do you like the layout of the Notes, Warnings and Fixes? (See samples page) The main trouble that i see, is that it puts each note out-of-context with the main page, i.e. not sure what the warning refers to. Otherwise great. Thanks for your excellent work. -David
