Re: XPatch support for maven-cocoon-deployer-plugin
Leszek Gawron wrote: Just a few examples of what can be currently achieved only by patching: - tweaking store janitor - configuring transient store max objects - configuring continuations manager These three things could be configured through properties I guess. So there shouldn't be a need for patching. - you won't even be able to define a new cforms widget definition because they don't use the new service selector that allows to span components over several files. While some things are trivial to fix some are not and all definitely need some committer attention. The problem with declaring widgets in other files is probably a year old. Yes, I think cforms in general is the hardest bit: it's not possible for exampe to add a converter to a datatype without patching. We should definitly come up with a better configuration which does not require any patching just for adding new widgets, converters etc. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: XPatch support for maven-cocoon-deployer-plugin
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Just a few examples of what can be currently achieved only by patching:
- tweaking store janitor
- configuring transient store max objects
- configuring continuations manager
These three things could be configured through properties I guess. So
there shouldn't be a need for patching.
That is why i wrote some things are trivial :)
- you won't even be able to define a new cforms widget definition
because they don't use the new service selector that allows to span
components over several files.
While some things are trivial to fix some are not and all definitely
need some committer attention. The problem with declaring widgets in
other files is probably a year old.
Yes, I think cforms in general is the hardest bit: it's not possible for
exampe to add a converter to a datatype without patching. We should
definitly come up with a better configuration which does not require any
patching just for adding new widgets, converters etc.
Exactly. Still my point is valid: users need to use it as is and won't
be able to wait for developers mercy.
I have found yet another example: JXTemplate generator. Does anybody
even remember that you can use javascript in jxtg along with jexl and jxtg?
{jexl:expr}
{jxpath:expr}
{js:expr}
or simply {expr} for default language
instead of
${expr}
#{expr}
And why? Because there is no simple way (not even for a developer) to
make a switch.
--
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
reading settings in cocoon.xconf
Another feature request for Carsten. We have already discussed this once: While testing a development block the properties from /src/main/resources/META-INF/properties/* are not copied to webapp directory. In order to load them properly we need include-properties/ also in cocoon.xconf (currently it only works in sitemaps). This way we can load properties directly from source folder. -- 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
Re: reading settings in cocoon.xconf
Leszek Gawron wrote: Another feature request for Carsten. We have already discussed this once: While testing a development block the properties from /src/main/resources/META-INF/properties/* are not copied to webapp directory. In order to load them properly we need include-properties/ also in cocoon.xconf (currently it only works in sitemaps). This way we can load properties directly from source folder. Do we really need this? :) Currently the implementation is imho clean and separating concerns: there is one component reading the properties and providing them via Spring and another one is able to read avalon configurations. I don't want to mix these as some day in the future we will remove the Avalon stuff (or make it optional) and then we have to change everything again. Can we somehow configure this in a different way? Perhaps by passing in a system property pointing to the properties directory? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: reading settings in cocoon.xconf
Carsten Ziegeler wrote: Leszek Gawron wrote: Another feature request for Carsten. We have already discussed this once: While testing a development block the properties from /src/main/resources/META-INF/properties/* are not copied to webapp directory. In order to load them properly we need include-properties/ also in cocoon.xconf (currently it only works in sitemaps). This way we can load properties directly from source folder. Do we really need this? :) Currently the implementation is imho clean and separating concerns: there is one component reading the properties and providing them via Spring and another one is able to read avalon configurations. I don't want to mix these as some day in the future we will remove the Avalon stuff (or make it optional) and then we have to change everything again. Can we somehow configure this in a different way? Perhaps by passing in a system property pointing to the properties directory? As long as it is configured automatically so the only thing that user does is: mvn clean compile cocoon:deploy jetty:run -- 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
Re: reading settings in cocoon.xconf
Leszek Gawron wrote As long as it is configured automatically so the only thing that user does is: mvn clean compile cocoon:deploy jetty:run I'm not that familiar with all aspects of the cocoon:deploy plugin, but I thought that this one is deploying all files into the necessary locations? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: reading settings in cocoon.xconf
Carsten Ziegeler wrote:
Leszek Gawron wrote
As long as it is configured automatically so the only thing that user
does is:
mvn clean compile cocoon:deploy jetty:run
I'm not that familiar with all aspects of the cocoon:deploy plugin, but
I thought that this one is deploying all files into the necessary locations?
Not exactly. This is only one mode of operation when you work on
cocoon-webapp archetype.
If you invoke it for any project that is not war packaged then it is
assumed you are locally developing your cocoon block. Your main
sitemap.xmap, cocoon.xconf, web.xml and bunch of other core files get
generated:
--- sitemap.xmap ---
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:classloader factory-role=org.apache.cocoon.classloader.ClassLoaderFactory/reloading
class-dir
src=file:/c:/dev/projects/donnelley/donnelley-admin/target/classes//
/map:classloader
/map:components
map:pipelines
map:pipeline
map:match pattern=
map:redirect-to uri=blocks/donnelley-admin//
/map:match
!-- resources of block jars --
map:match pattern=_cocoon/resources/*/**
map:read src=resource://org/apache/cocoon/{1}/resources/{2}/
/map:match
!-- mount all development blocks --
map:match pattern=blocks/donnelley-block-common/**
map:mount uri-prefix=blocks/donnelley-block-common
src=file:/c:/dev/projects/donnelley/donnelley-admin/../donnelley-block-common/src/main/resources/COB-INF//
/map:match
map:match pattern=blocks/donnelley-admin/**
map:mount uri-prefix=blocks/donnelley-admin
src=file:/c:/dev/projects/donnelley/donnelley-admin/src/main/resources/COB-INF//
/map:match
!-- mount all deployed blocks --
map:match pattern=*/**
map:mount src={1}/ uri-prefix={1}/
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
features: - local classes loaded via reloading classloader
- COB-INF sources mounted directly from src/ directory
- COB-INF from other modules (if specified) also mounted from
source
--- web.xml ---
generated from scratch, all cocoon blocks contribute patches from
META-INF/xpatch/*.xweb
cocoon.xconf:
cocoon version=2.2
!--+
| Include the core roles definitions. This is for the sake of clarity,
| as they are implicitely loaded at startup, but we may want to remove
| this implicit behaviour in the future now that we have the include
| mechanism.
+--
include src=resource://org/apache/cocoon/cocoon.roles/
!--+
| Include all configuration files ending with .xconf
| from the xconf directory.
+--
include dir=context://WEB-INF/cocoon/xconf pattern=*.xconf/
!--+
| Include all configuration files ending with .xmap
| from the sitemap-additions directory.
+--
include dir=context://WEB-INF/cocoon/sitemap-additions pattern=*.xmap/
!--+
| Include Spring beans definition files ending with .xml from
| the spring directory.
+--
include-beans dir=context://WEB-INF/cocoon/spring pattern=*.xml/
include-beans
dir=file:/c:/dev/projects/donnelley/donnelley-admin/src/main/resources/META-INF/spring/
pattern=*.xml/
include dir=file:/c:/dev/projects/donnelley/donnelley-admin/src/main/resources/META-INF/legacy/xconf/ pattern=*.xconf/
include dir=file:/c:/dev/projects/donnelley/donnelley-admin/src/main/resources/META-INF/legacy/sitemap-additions/ pattern=*.xmap/
/cocoon
features:
- local spring contexts, avalon context and sitemap additions mounted
directly from source directory
The main goal is to provide everything from source folder.
The blocks consists of:
- COB-INF resources (covered with mount in sitemap)
- java classes (loaded on sitemap level with reloading classloader, now
gets me thinking it will break if block supplies some core spring beans)
- avalon contexts (covered by include in cocoon.xconf)
- spring contexts (covered by include in cocoon.xconf)
- sitemap additions (covered by include in cocoon.xconf)
- properties
- those in src/main/resources/COB-INF/config/properties/ covered by
automatic loading in block sitemap
- those in src/main/resources/META-INF/properties are NOT COVERED
--
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
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432499 ] Lars Trieloff commented on COCOON-1898: --- Leszek, there are some weak points in the XUpdate language, for example the if-semantics are not yet defined. Putting the patches below src/main/xpath is no problem when you add this path to the list of paths that are considered by the jar plugin (or whatever does the packaging) I understand your motivation for multiple patches targeting one file. For the long command line: could not the cocoon-deployer call cocoon:xupdate before finishing the deployment? The deployer scans the required jar files for patches, extracts them to a target/xpatch directory, calls cocoon:xupdate which then uses patches in target/xpatch and /src/main/xpatch to patch the extracted files. [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. -- 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: reading settings in cocoon.xconf
Leszek Gawron wrote: SNIP The blocks consists of: - COB-INF resources (covered with mount in sitemap) - java classes (loaded on sitemap level with reloading classloader, now gets me thinking it will break if block supplies some core spring beans) - avalon contexts (covered by include in cocoon.xconf) - spring contexts (covered by include in cocoon.xconf) - sitemap additions (covered by include in cocoon.xconf) - properties - those in src/main/resources/COB-INF/config/properties/ covered by automatic loading in block sitemap - those in src/main/resources/META-INF/properties are NOT COVERED Thanks for the nice overview, Leszek - I've never used it this way. To be honest, I have no good idea how to solve this. But I think putting these include into the xconf is not the right way :( Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[
http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432504
]
Leszek Gawron commented on COCOON-1898:
---
Concerning src/main/xpatch:
We have have agreed some time ago to keep all the specific cocoon resources in
resources/META-INF subdirectory (spring context, avalon contexts, properties,
sitemap additions and now xpatch). Why make exceptions for xpatches?
On the other side If the resulting jar file contains patches in META-INF/xpatch
it really _should_ not matter whey they are picked from in the first place.
Unfortunately it does. There is one small problem with development blocks
mounted like this:
plugin
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-deployer-plugin/artifactId
version1.0.0-M2-SNAPSHOT/version
configuration
useShieldingClassloaderfalse/useShieldingClassloader
useShieldingRepositoryfalse/useShieldingRepository
blocks
developmentBlock
groupIdcom.mobilebox.donnelley/groupId
artifactIddonnelley-block-common/artifactId
localPath../donnelley-block-common/localPath
/developmentBlock
/blocks
/configuration
/plugin
this configuration is converted later on to a mount in sitemap:
map:match pattern=blocks/donnelley-block-common/**
map:mount uri-prefix=blocks/donnelley-block-common
src=file:/c:/dev/projects/donnelley/donnelley-admin/../donnelley-block-common/src/main/resources/COB-INF//
/map:match
map:match pattern=blocks/donnelley-admin/**
map:mount uri-prefix=blocks/donnelley-admin
src=file:/c:/dev/projects/donnelley/donnelley-admin/src/main/resources/COB-INF//
/map:match
The path is being built like this:
private static final String RESOURCES_DIR = src/main/resources/;
public void setLocalPath(String localPath) throws FileNotFoundException {
File localPathDir = new File(localPath);
if (!localPathDir.exists()) {
throw new FileNotFoundException(Directory ' + localPath + ' does not
exist!);
}
springConfPath = checkDir(new File(localPath, RESOURCES_DIR +
META-INF/spring));
xconfConfPath = checkDir(new File(localPath, RESOURCES_DIR +
META-INF/legacy/xconf));
sitemapAdditionsConfPath = checkDir(new File(localPath, RESOURCES_DIR +
META-INF/legacy/sitemap-additions));
xPatchPath = checkDir(new File(localPath, RESOURCES_DIR +
META-INF/xpatch));
targetClassesPath = checkDir(new File(localPath, target/classes));
cobInfPath = checkDir(new File(localPath, RESOURCES_DIR + COB-INF));
}
Statically. If you configure something else as a resource folder - it won't be
picked up by cocoon:deploy. We probably would have to use maven API to parse
appropriate pom.xml files.
We should follow both maven and cocoon conventions. Otherwise we'll have
pom.xml bloated from the start.
Concerning long command line:
I am not maven expert and have totally no idea how to invoke
create/configure/invoke a plugin from withing another plugin.
The run order should be: compile deploy patch shield. Patch goes before
shielding before shielding modifies web.xml. If you patched after shielding you
would have to permanently choose if you patch towards shielded/non shielded
webapp.
[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.
--
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:
Re: reading settings in cocoon.xconf
Carsten Ziegeler wrote:
Leszek Gawron wrote:
SNIP
The blocks consists of:
- COB-INF resources (covered with mount in sitemap)
- java classes (loaded on sitemap level with reloading classloader, now
gets me thinking it will break if block supplies some core spring beans)
- avalon contexts (covered by include in cocoon.xconf)
- spring contexts (covered by include in cocoon.xconf)
- sitemap additions (covered by include in cocoon.xconf)
- properties
- those in src/main/resources/COB-INF/config/properties/ covered by
automatic loading in block sitemap
- those in src/main/resources/META-INF/properties are NOT COVERED
Thanks for the nice overview, Leszek - I've never used it this way.
To be honest, I have no good idea how to solve this. But I think putting
these include into the xconf is not the right way :(
Your proposal to use a system property would work. But its ugly. You
would need to have this configured in every pom.xml:
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty6-plugin/artifactId
version6.0.0beta10/version
configuration
connectors
connector
implementation=org.mortbay.jetty.nio.SelectChannelConnector
port/port
maxIdleTime3/maxIdleTime
/connector
/connectors
webAppSourceDirectorytarget/${artifactId}-${version}/webAppSourceDirectory
contextPath//contextPath
systemProperties
systemProperty
nameorg.apache.cocoon.mode/name
valuedev/value
/systemProperty
systemProperty
nameorg.apache.cocoon.additional.property.directory/name
value/src/main/resources/META-INF/properties/value
/systemProperty
/systemProperties
/configuration
/plugin
It should not be something that needs configuring in pom.xml. This
configuration issue should go directly somewhere into /target/cocoon-webapp
--
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
Re: reading settings in cocoon.xconf
Carsten Ziegeler wrote: Leszek Gawron wrote: SNIP The blocks consists of: - COB-INF resources (covered with mount in sitemap) - java classes (loaded on sitemap level with reloading classloader, now gets me thinking it will break if block supplies some core spring beans) - avalon contexts (covered by include in cocoon.xconf) - spring contexts (covered by include in cocoon.xconf) - sitemap additions (covered by include in cocoon.xconf) - properties - those in src/main/resources/COB-INF/config/properties/ covered by automatic loading in block sitemap - those in src/main/resources/META-INF/properties are NOT COVERED Thanks for the nice overview, Leszek - I've never used it this way. To be honest, I have no good idea how to solve this. But I think putting these include into the xconf is not the right way :( Would it help, if you could specify the properties dir in the settings element in the applicationContext.xml? Currently cocoon:settings/ is used; we could simply extend it with support for an addition dir attribute. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: reading settings in cocoon.xconf
Carsten Ziegeler wrote: Carsten Ziegeler wrote: Leszek Gawron wrote: SNIP The blocks consists of: - COB-INF resources (covered with mount in sitemap) - java classes (loaded on sitemap level with reloading classloader, now gets me thinking it will break if block supplies some core spring beans) - avalon contexts (covered by include in cocoon.xconf) - spring contexts (covered by include in cocoon.xconf) - sitemap additions (covered by include in cocoon.xconf) - properties - those in src/main/resources/COB-INF/config/properties/ covered by automatic loading in block sitemap - those in src/main/resources/META-INF/properties are NOT COVERED Thanks for the nice overview, Leszek - I've never used it this way. To be honest, I have no good idea how to solve this. But I think putting these include into the xconf is not the right way :( Would it help, if you could specify the properties dir in the settings element in the applicationContext.xml? Currently cocoon:settings/ is used; we could simply extend it with support for an addition dir attribute. Hmmm ... not really. And the system property solution would not also work. Everything because you may mount more that one development block directly from source: plugin groupIdorg.apache.cocoon/groupId artifactIdcocoon-deployer-plugin/artifactId version1.0.0-M2-SNAPSHOT/version configuration useShieldingClassloaderfalse/useShieldingClassloader useShieldingRepositoryfalse/useShieldingRepository blocks developmentBlock groupIdcom.mobilebox.donnelley/groupId artifactIddonnelley-block-common/artifactId localPath../donnelley-block-common/localPath /developmentBlock /blocks /configuration /plugin which needs to read properties from: - src/main/resources/META-INF/properties - ../donnelley-block-common/src/main/resources/META-INF/properties -- 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
Re: reading settings in cocoon.xconf
Leszek Gawron wrote: Hmmm ... not really. And the system property solution would not also work. Everything because you may mount more that one development block directly from source: plugin groupIdorg.apache.cocoon/groupId artifactIdcocoon-deployer-plugin/artifactId version1.0.0-M2-SNAPSHOT/version configuration useShieldingClassloaderfalse/useShieldingClassloader useShieldingRepositoryfalse/useShieldingRepository blocks developmentBlock groupIdcom.mobilebox.donnelley/groupId artifactIddonnelley-block-common/artifactId localPath../donnelley-block-common/localPath /developmentBlock /blocks /configuration /plugin which needs to read properties from: - src/main/resources/META-INF/properties - ../donnelley-block-common/src/main/resources/META-INF/properties We could allow more than one directory in the system property or the attribute (separated by comma). Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: XPatch support for maven-cocoon-deployer-plugin
Carsten Ziegeler skrev: Leszek Gawron wrote: ... - you won't even be able to define a new cforms widget definition because they don't use the new service selector that allows to span components over several files. While some things are trivial to fix some are not and all definitely need some committer attention. The problem with declaring widgets in other files is probably a year old. Yes, I think cforms in general is the hardest bit: it's not possible for exampe to add a converter to a datatype without patching. We should definitly come up with a better configuration which does not require any patching just for adding new widgets, converters etc. The datatype should _look up_ converters instead of _containing_ them. In this way any block can contribute a converter that can be looked up. The current implementation is based on the idea that there is one central definition of all cform components. This is far to monolithic for use with blocks. /Daniel
RE: data added to our SVN for the ASF calendar
FYI, I have created a calendar file at http://svn.apache.org/repos/asf/cocoon/site/asf-calendar/ for display on http://asylum.zones.apache.org/rdfcal Great, thanks Bertrand! -- Arje
RE: Re: [GT2006] Registration is open! Cocoon GetTogether 2006 (Oct 2-4,Amsterdam)
Hi Bertrand, Do (potential) speakers have to register there as well? Yes, please register on the website, even if you're thinking of doing a talk. As usual, speakers will get a free pass. Please sign up but wait with the whole Paypal procedure until you know whether you'll be talking or not. Kind regards, Met vriendelijke groet, Arjé Cahn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl / [EMAIL PROTECTED] --
RE: Re: [GT2006] Registration is open! Cocoon GetTogether 2006 (Oct 2-4,Amsterdam)
I got a seat! Even made it through the Paypal forms in Dutch! Aw.. Really? Is it always in Dutch? It shouldn't do that! Do others have this as well?? -- Arje
Re: XPatch support for maven-cocoon-deployer-plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 3 Sep 2006, Leszek Gawron wrote: Date: Sun, 03 Sep 2006 20:00:15 +0200 From: Leszek Gawron [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: XPatch support for maven-cocoon-deployer-plugin Reinhard Poetz wrote: Leszek Gawron (JIRA) wrote: I want to implement some more features for cocoon:deploy XPatching: First, because of a lack of time I haven't had much time to understand in detail what your needs are. So take my concerns as what they are: a gut feeling. I think we are about to overdo what a deployment mechanism (and XPatch) is about and can/should do for us. Whenver you extend the deployer keep in mind what Cocoon blocks at a sitemap level are about (polymorphism inheritance) and that we can (and IMO should) backport the things that already work in the OSGi mode. Because of that I don't think it's a good idea to e.g. be able to patch any file at deployment time instead of only patching web.xml What I really need to patch is web.xml and main sitemap.xmap (which is generated for block testing). Probably some entries in WEB-INF/cocoon/xconf are not configurable other way than patching. I'm not sure what this xpatch stuff is all about (I thought we've been over it with patching in 2.2). But what about src/test/webapp/WEB-INF/web.xml src/test/webapp/sitemap.xmap if you need special ones for testing your block (packaging=jar)? For packaging=webapp you don't really need patching at all as you are in total control of it! My -0.02 cents to user driven patching in Cocooon 2.2 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.5 (GNU/Linux) iD8DBQFE/HwHLNdJvZjjVZARArjsAKCvkMJkyHWV3y8e34T1ujoLwZqPaQCfagWJ M4YrVE5oeahk4kiaIOMJSmo= =yrB1 -END PGP SIGNATURE-
Re: XPatch support for maven-cocoon-deployer-plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 3 Sep 2006, Leszek Gawron wrote: Date: Sun, 03 Sep 2006 20:34:19 +0200 From: Leszek Gawron [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: XPatch support for maven-cocoon-deployer-plugin Reinhard Poetz wrote: Leszek Gawron (JIRA) wrote: I want to implement some more features for cocoon:deploy XPatching: First, because of a lack of time I haven't had much time to understand in detail what your needs are. So take my concerns as what they are: a gut feeling. I think we are about to overdo what a deployment mechanism (and XPatch) is about and can/should do for us. Whenver you extend the deployer keep in mind what Cocoon blocks at a sitemap level are about (polymorphism inheritance) and that we can (and IMO should) backport the things that already work in the OSGi mode. Because of that I don't think it's a good idea to e.g. be able to patch any file at deployment time instead of only patching web.xml After my holidays I will have a closer look at this topic and can give some more qualified feedback. Just a few examples of what can be currently achieved only by patching: - modifying a generated sitemap when testing a block (mvn compile cocoon:deploy jetty:run on a development block) I'd suppose using own ones for such in the src/test path - tweaking store janitor Should be adjustable by properties (dunno exactly what you wantto tweak) - configuring transient store max objects Same as above: Property - configuring continuations manager Again: Properties - you won't even be able to define a new cforms widget definition because they don't use the new service selector that allows to span components over several files. So this cries for a patch ;-) While some things are trivial to fix some are not and all definitely need some committer attention. The problem with declaring widgets in other files is probably a year old. Yes I think we are aware of the cform new widget problems. But what do you mean by committer attention? 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.5 (GNU/Linux) iD8DBQFE/H0CLNdJvZjjVZARAiLzAJ9kgkgYjSAvyuzBPQxTlhBYMu0LXwCg5FQQ XND5Hsq90PhTgOQFVdWlkWo= =Titu -END PGP SIGNATURE-
Re: svn commit: r440049 - in /cocoon/trunk: blocks/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portal/event/aspect/impl/ blocks/cocoon-portal/cocoon-portal-impl/src/main/java/org/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No more usage of Avalon's LogEnabled and Contextualizable Added: cocoon/trunk/blocks/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portal/impl/AbstractLogEnabled.java URL: http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portal/impl/AbstractLogEnabled.java?view=autorev=440049 == --- cocoon/trunk/blocks/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portal/impl/AbstractLogEnabled.java (added) +++ cocoon/trunk/blocks/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portal/impl/AbstractLogEnabled.java Mon Sep 4 05:25:39 2006 Shouldn't this class be somewhere along core? That way more modules could benefit of your refactoring ;-) which I like. 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.5 (GNU/Linux) iD8DBQFE/JoRLNdJvZjjVZARApaSAJ9lQelb8wGNMrQta+W1FY8Sfh2RigCeLYMb 9YK4ZB3SLI26vy60p6R5+hU= =fqFw -END PGP SIGNATURE-
RE: Re: [GT2006] Registration is open! Cocoon GetTogether 2006 (Oct 2-4,Amsterdam)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Sep 2006, Arje Cahn wrote: Date: Mon, 4 Sep 2006 19:34:56 +0200 From: Arje Cahn [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: RE: Re: [GT2006] Registration is open! Cocoon GetTogether 2006 (Oct 2-4,Amsterdam) I got a seat! Even made it through the Paypal forms in Dutch! Aw.. Really? Is it always in Dutch? It shouldn't do that! Do others have this as well?? As soon as you change the country drop down to something you think comes near (as you need to guess what your country will look like in Dutch). So, I was searching for Switzerland or Schweiz but had to go down to Zwitzerland (or alike) to change the page language. 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.5 (GNU/Linux) iD8DBQFE/JsMLNdJvZjjVZARAgqBAKDXEf1g/7mRCnBELCFLkD/80O6rkACfaYIH ZPzyDD7Wq6ZOxVwPIj1pVis= =EbOC -END PGP SIGNATURE-
[jira] Created: (COCOON-1907) Entity resolution in imported XSLT stylesheets does not use catalog
Entity resolution in imported XSLT stylesheets does not use catalog --- Key: COCOON-1907 URL: http://issues.apache.org/jira/browse/COCOON-1907 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.9 Reporter: Mark Lundquist I have a stylesheet A.xslt containing xsl:import href=B.xslt/ B.xslt, in turn, has a DTD with external entities defined: !DOCTYPE stylesheet [ !ENTITY % HTMLlat1 PUBLIC -//W3C//ENTITIES Latin 1 for XHTML//EN http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent; %HTMLlat1; !ENTITY % HTMLspecial PUBLIC -//W3C//ENTITIES Special for XHTML//EN http://www.w3.org/TR/xhtml1/DTD/xhtml-special.ent; %HTMLspecial; ] In Cocoon running a machine that is disconnected from the Internet, an exception is thrown: java.net.UnknownHostException: www.w3.org at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:153) at java.net.Socket.connect(Socket.java:452) at java.net.Socket.connect(Socket.java:402) at sun.net.NetworkClient.doConnect(NetworkClient.java:139) at sun.net.www.http.HttpClient.openServer(HttpClient.java:402) at sun.net.www.http.HttpClient.openServer(HttpClient.java:618) at sun.net.www.http.HttpClient.init(HttpClient.java:306) at sun.net.www.http.HttpClient.init(HttpClient.java:267) at sun.net.www.http.HttpClient.New(HttpClient.java:339) at sun.net.www.http.HttpClient.New(HttpClient.java:320) at sun.net.www.http.HttpClient.New(HttpClient.java:315) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:521) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:498) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:626) at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.startPE(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.skipSeparator(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDInternalSubset(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.processor.ProcessorInclude.parse(ProcessorInclude.java:284) at org.apache.xalan.processor.ProcessorInclude.startElement(ProcessorInclude.java:150) at org.apache.xalan.processor.StylesheetHandler.startElement(StylesheetHandler.java:623) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315) at org.apache.excalibur.xmlizer.DefaultXMLizer.toSAX(DefaultXMLizer.java:128) at org.apache.cocoon.components.xslt.TraxProcessor.sourceToSAX(TraxProcessor.java:301) at org.apache.cocoon.components.xslt.TraxProcessor.getTransformerHandlerAndValidity(TraxProcessor.java:239) at org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java:330) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:397) If the external entities are defined in A.xslt, the exception is not thrown, and the entities are resolved correctly using
