You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2006/09/03 19:50:19 UTC
XPatch support for maven-cocoon-deployer-plugin
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.
--
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: XPatch support for maven-cocoon-deployer-plugin
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
>> - 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
replied elsewhere. I do not like the idea of having 20 same web.xml
files residing in each application block.
>
>> - tweaking store janitor
>
> Should be adjustable by properties (dunno exactly what you wantto tweak)
You're right. Still: should be but isn't
>> - configuring transient store max objects
>
> Same as above: Property
same as above: someone has to do it.
>
>> - configuring continuations manager
>
> Again: Properties
again here. you're right, but ...
>
>> - 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"?
I mean that there has to be one of the committers that has will, skills
and time to do it. As we all are busy with our things most of the
current 2.2 problems outlined above won't make into next 2.2 release.
The user base for 2.2 is hardly existent. Now having maven you a lot of
artifact jars and cocoon deployer. Users got used to patching. We cannot
drop it because cocoon simply isn't ready for it.
We could have patch mechanism separated from main deployer:
mvn clean compile cocoon:deploy cocoon:patch cocoon:shield 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: XPatch support for maven-cocoon-deployer-plugin
Posted by Giacomo Pati <gi...@apache.org>.
-----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 <lg...@mobilebox.pl>
> 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: XPatch support for maven-cocoon-deployer-plugin
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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: XPatch support for maven-cocoon-deployer-plugin
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> I'm quite -0 on that xpatch support. I don't see the benefit.
Just try to implement some mavenized cocoon based webapp that needs to
change something in .xconf files. The urgent need will come.
> I support the idea of rewriting how cform should be configures to allow
> easy additions of additional Converter Datatypes etc. and am with
> Carsten on the rest being property driven.
I like the idea except this is still and idea and I already mavenized
some my production sites. As I started to do it about a month ago I also
started to hammer this mailing list with questions and requests. At the
same time almost the same request came into jira from cocoon user.
The common agreement here is we want to release 2.2 ASAP. Now some users
already started testing it and found holes in our functionality. If we
tell them to wait the user will simply switch back to 2.1.x. I have
spent more time during last month fighting with cocoon build/deploy than
actually writing my software. I haven't resigned just because I may
commit stuff that allows me to make another few steps forward. Users do
not have such comfort.
BTW: I do not want to patch cforms at all. I never needed it. It was
just an example. I have lots of other cases in other cocoon areas that
will not be resolved by fixing cforms.
--
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: XPatch support for maven-cocoon-deployer-plugin
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 4 Sep 2006, Carsten Ziegeler wrote:
> Date: Mon, 04 Sep 2006 09:46:59 +0200
> From: Carsten Ziegeler <cz...@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: 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.
I'm quite -0 on that xpatch support. I don't see the benefit.
I support the idea of rewriting how cform should be configures to
allow easy additions of additional Converter Datatypes etc. and am
with Carsten on the rest being property driven.
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/H6SLNdJvZjjVZARAohEAJ9dgigzfVZ5RC/+OF0KLbqjI1UyrgCeLklk
aQCNyqLGogiRZO0OQletJcU=
=mdNx
-----END PGP SIGNATURE-----
Re: XPatch support for maven-cocoon-deployer-plugin
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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
Re: XPatch support for maven-cocoon-deployer-plugin
Posted by Carsten Ziegeler <cz...@apache.org>.
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, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: XPatch support for maven-cocoon-deployer-plugin
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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)
- tweaking store janitor
- configuring transient store max objects
- configuring continuations manager
- 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.
--
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: XPatch support for maven-cocoon-deployer-plugin
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> 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
We've been discussing a variation of this approach here [1]. My point was:
there is myblock-opensessioninview-enabler. It has a patch to web.xml:
<?xml version="1.0"?>
<xweb xpath="/web-app"
unless="comment()[contains(., 'OpenSessionInView')]"
insert-before="servlet">
<!-- OpenSessionInView -->
<filter>
<filter-name>openSessionInViewFilter</filter-name>
<filter-class>
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>openSessionInViewFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</xweb>
If the patch is carried along with the myblock-opensessioninview-enabler
block any other block (say myblock-client-interface) is able to have
web.xml patched just by stating dependency on
myblock-opensessioninview-enabler.
There are already some blocks in cocoon that are used alike:
cocoon-trunk\blocks\cocoon-databases\cocoon-databases-oracle-client
cocoon-trunk\blocks\cocoon-databases\cocoon-databases-postgresql-client
The only thing the block does is ensuring the proper class gets loaded.
> src/test/webapp/WEB-INF/web.xml
> src/test/webapp/sitemap.xmap
Those are not the only files that need patching right now.
>
> 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!
Same goes for webapp. Even if I have a total control over webapp I want
this definition to look exactly the same in all projects in my company.
This way I make my myapp-webapp depend on
myblock-opensessioninview-enabler and thats it.
[1] http://issues.apache.org/jira/browse/COCOON-1898
--
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: XPatch support for maven-cocoon-deployer-plugin
Posted by Giacomo Pati <gi...@apache.org>.
-----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 <lg...@mobilebox.pl>
> 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
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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 know patching should be the last resort. Still I prefer to use cocoon
2.2 as is and patch it here and there than to not use 2.2 at all and
wait for all the issues to be resolved. After fixing some things lately
I was able to finish a prototype system that quickly went into
production. After I've experienced some annoyances with current build I
was able to feedback even more.
> After my holidays I will have a closer look at this topic and can give
> some more qualified feedback.
Superb. Looking forward to it.
--
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