Move from HTMLArea to Xinha

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

Felix Knecht (JIRA) pisze:
[ 
https://issues.apache.org/jira/browse/COCOON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
]


Felix Knecht closed COCOON-2091. 

Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN)

- Added xinha and needed stylesheets to cocoon-forms-impl - Added 
sample to cocoon-forms-sample


The xinha license seems to be still the same license htmlarea used 
(htmlarea license). As this license has already be used and is also
listed in the legal folder I don't see any problems concerning the 
license.


Feel free to reopen if any error occur.


I haven't tested your changes but I would like to something more general.

I wonder if you have not hurried up too much with this change. Even 
though Xinha is an obvious replacement for HTMLArea they are _not_ the 
same projects. I think that if someone wants to switch to a new project 
she should give others a few days for comments, raising concerns etc. Of 
course, I think that formal vote would be overkill in this case.


It's especially valid in this case because Rice proposed to use Dojo's 
editor as an alternative. I was going to raise the same issue but wanted 
to do some research before so I could add some value to the discussion. 
Unfortunately, I have not had enough time to do it.


Felix, all in all, I'm not against this particular change and speaking 
honestly I _am_ happy that we finally moved to Xinha but I couldn't 
resist commenting general practise.


Was htmlarea removed completly or is it just a styling option whether I want to 
use Xinha or Htmlarea?


Without having a deprecation period I'm against a complet removal of htmlarea as 
users might have their own configurations (e.g. Daisy Wiki).


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Move from HTMLArea to Xinha

[Reinhard Poetz]

Felix Knecht wrote:

Reinhard Poetz schrieb:

Was htmlarea removed completly or is it just a styling option whether
I want to use Xinha or Htmlarea?


It's just a styling option you have (xinha instead of htmlarea) and no
real replacement has be done. You can use both at the moment, it depends
on the styling option you use.
I agree, 'replacment' was definitely the wrong term. It's an addition
that you now have the choice which one you want to use.


Then I don't see a problem (as long as Xinha resources are not loaded from every 
form ... haven't had time to look into the implementation yet).


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Move from HTMLArea to Xinha

[Reinhard Poetz]

Felix Knecht wrote:

If you we are already in this area. What about deprecating HTMLArea?
The project is not maintained any more so I think it would be very
wise to deprecate HTMLArea, especially when we have replacement for
it, already.

What others think about it? Do we need a vote?


yes please so that the decision gets explicit to everybody who doesn't follow 
each mail thread in every detail.



Felix, could you handle deprecation work (it consists mainly of adding
entry in changes.xml and comments in code)?


Well, I'll take the chance and try to.
As all of the scripts are executed on client side (and I don't think
it's a good idea to have a popup there saying it's depracated) where
would it be best place except the changes.xml to have a printout that it
is deprecated?


Once we had a deprecation logger but I don't think that the infrastructure for 
it is still in place.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Move from HTMLArea to Xinha

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

Reinhard Poetz pisze:


Once we had a deprecation logger but I don't think that the 
infrastructure for it is still in place.


Do you talk about client or server logger?


server logger. IIRC there was a log target named deprecated. Maybe Carsten 
knows more.


I think that we could create special matcher for HTMLArea resources and 
put a simple action (DeprecateAction?) that would produce a deprecation 
warning each time HTMLArea resource is accessed.
Thanks to servlet-service-fw migration in CForms we can be pretty sure 
that files will be accessed through our matcher.


good idea!

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

CocoonGT2007 - When?

[Reinhard Poetz]

Hi Gianugo,

are there already some concrete plans, when the GT will take place this year? I 
would be very interested to know it asap, because a project will start around 
the suggested dates of end of September or beginning of October and if possible 
I want to avoid timing collisions as far as possible.


Thanks!

Best,
Reinhard

P.S. I send this mail to [EMAIL PROTECTED] too because others might be interested in 
your answer as well

Re: Cocoon Maven plugin - Merging deployer rcl

[Reinhard Poetz]

Olivier Billard wrote:

Reinhard Poetz wrote:

Olivier Billard wrote:

Guys,

I plug into your thread because I'm right into it : I checked-out the 
Cocoon ACEGI sample, completed it and tested it, it's great.
But I've got trouble with the xweb file : using the block-only rcl 
webapp, patch is correctly applied, but I would like to make my app 
security with ACEGI a block (seems promising with ACEGI as a filter 
and xweb), but such a block included into a webapp block does not 
triggers web.xml patching when calling mvn package.


Did I missed something ?


Yes, you have to use the deployer goal ('mvn cocoon:deploy') in order 
to get your xweb patches applied. The package plugin isn't aware of 
Cocoon's xweb patching mechanism.





Thank you for your answer Reinhard, I really missed this plugin part, 
sorry.


note
This could be continued in the users list if you think this is more suited.
Nevertheless, as this seems to be a bug in the dev version (not released 
yet), I continue on the dev list for the moment.

/note

This perfectly works with the deploy mojo, but not for the 
deploy-war one, with exactly the same configuration.
I meet a strange phenomenon, that could possibly be a bug in the 
cocoon-maven-plugin ? web.xml patch is not applied with the 
deploy-war, except after a deploy mojo call :). Of course these 
mojos are not meant to be called one after the other, but this could be 
a clue for resolution: maybe a context is not properly initialized when 
deploy-war mojo is called alone?



Maven outputs below.


Olivier,

thanks for your investigations. Could you please file a Jira bug report? Thanks!


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Module cocoon-forms-sample depends on JDBI that is not on Maven repo

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

Jeroen Reijn pisze:

Hi Grzegorz,

I do not have much time during the days, but in the evening I can try 
to help you out.


Ok. Another issue is that we need a mechanism for creating tables and 
feeding them with initial data for samples so they have something to 
operate on. I have no idea how it was done in C2.1. Some research is 
needed.


The database related samples in 2.1 use an embedded hsql instance which is 
already filled with the required data.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Module cocoon-forms-sample depends on JDBI that is not on Maven repo

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

Reinhard Poetz pisze:


The database related samples in 2.1 use an embedded hsql instance 
which is already filled with the required data.


The question is how the database is filled with the required data? Isn't 
a *.sql file applied on startup?


Hsqldb uses sql scripts to store its data. See the 2.1 samples to get the idea.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Cocoon Maven plugin - Merging deployer rcl

[Reinhard Poetz]

Olivier Billard wrote:

Guys,

I plug into your thread because I'm right into it : I checked-out the 
Cocoon ACEGI sample, completed it and tested it, it's great.
But I've got trouble with the xweb file : using the block-only rcl 
webapp, patch is correctly applied, but I would like to make my app 
security with ACEGI a block (seems promising with ACEGI as a filter and 
xweb), but such a block included into a webapp block does not triggers 
web.xml patching when calling mvn package.


Did I missed something ?


Yes, you have to use the deployer goal ('mvn cocoon:deploy') in order to get 
your xweb patches applied. The package plugin isn't aware of Cocoon's xweb 
patching mechanism.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: HSSFSerializer ( XML2XLS Converter )

[Reinhard Poetz]

Chan Mei Theng wrote:

Hi, Giacomo,

So, which email address I should post it to in the below different cases ...

1.  Ask for help.
2.  Sharing my findings.


[EMAIL PROTECTED]

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Why Continuum does not inform when build fails?

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

Hello,

Does anyone know why Continuum does not report if build fails? How to 
enable it?


According to the Continuum webapp, everything is configured properly. I broke 
trunk and manually triggered a build. Let's see what happens.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

[cocoon-maven-plugin] Known issues

[Reinhard Poetz]

Giacomo Pati wrote:

There are some itches left (RCL-Plugin) IMHO but they are for sure no show 
stoppers.


yes, the RCL goal has (at least) three known issues:

 1) doesn't work with Spring security ATM
 2) if used with Flowscript + cForms bindings classes don't get reloaded as soon
as an exception occurs
 3) if you use Spring AOP and the proxied class/interface is loaded by the
reloading classloader, every subsequent reload breaks the Spring app context

I will have a look at 1) ASAP.
2) is very difficult to debug. I _guess_ that the problems is somewhere in the 
Flowscript interpreter or in Rhino.
3) seems to be a problem with commons-jci. I will file a bug report ASAP so that 
Torsten can have a look at it. Note, that it can be worked around if you make 
sure that the proxied class/interface is _not_ loaded by the RCL.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: svn commit: r552371 - trunk broken, help needed

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

[EMAIL PROTECTED] pisze:

Author: gkossakowski
Date: Sun Jul  1 16:13:44 2007
New Revision: 552371

URL: http://svn.apache.org/viewvc?view=revrev=552371
Log:
COCOON-2082: Getting rid of Avalon dependencies, it includes:
* conversion JS, JXPath and JEXL compilers to Spring beans
* conversion DefaultExpressionFactory to Spring bean, it collects 
language compilers by using bean-map from Spring configurator


As you see, I'm in between of Avalon-Spring conversion process for 
expression languages. I have not moved and adjusted tests (thus build 
will fail) because I came across very obscure problem.


First of all I would like you to ask to do svn up and mvn clean install 
-Dmaven.test.skip=true for trunk, run cocoon-webapp, access 
http://localhost:/blocks/cocoon-template-sample/view/caching2

and check if you get following error:
TypeError: Cannot read property parameters from undefined (#1)

I would be grateful for any reports to be sure if it's not a JDK issue 
or so. Also, any help with sorting this out is really appreciated 
because I'm really out of ideas how to track such a weird problem. 
Details below.


I'm not sure if it is really a JDK issue. I guess that your setup got messed up 
by your refactorings. After fixing the compilation error (see my commit) I was 
able to run the cocoon-template-sample using the webapp produced by the rcl goal 
(I checked in the configuration) of the Cocoon Maven plugin with Java 5 
(1.5.0_11) without a problem.


Make sure that there are no old Java classes that haven't been deleted by SVN 
(run 'svn stat' on your working copy) and then run 'mvn clean'. As a next step I 
suggest that you remove all org.apache.cocoon artifacts from your local 
repository and finally run 'mvn install -Dmaven.test.skip=true'. This should 
make sure that your classpath doesn't contain any unwanted classes. HTH


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Versioning XML Schemas

[Reinhard Poetz]

Joerg Heinicke wrote:
You need to have the following in mind: Somebody wants to upgrade from 
Cocoon 2.2.3 to 2.2.4. In that step to one of the schemas an additional 
and optional attribute was added (like that case in Spring's AOP 
schema). In theory the jars would be a drop-in replacement. With 
increasing the version number of the schema you have to adapt all your 
references to the new version just to get your app working again. Or 
you'd need to hold all versions probably in use in your local XML 
catalogue or access them remotely. Since Spring has the schemas on the 
class path, they are just replaced with the jars. Despite the vagueness 
nobody actually needs to care about the schema version. For that reason 
I'd probably go with a constant number as long as it is backwards 
compatible. And it should be for on particular minor level.


I agree with Jörg.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: cocoon 2.2 - some more questions

[Reinhard Poetz]

Grzegorz Kossakowski wrote:
ok, i can guess the first line - but why (and when) to exclude libs? 
The doc

http://cocoon.zones.apache.org/daisy/cdocs/g1/g5/g1/g1/1298.html does not
give that much detailed information yet


I'm not sure (I hope that Reinhard will comment) but I think that you 
include classes compiled by your IDE (first line) and thus you must 
exclude classes from JAR of block2. If we didn't do this, we would have 
every class in classpath present twice.


exactly. If you want to make sure that the JAR is not pulled from your local 
repository and added to your classpath, exclude lib helps.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: cocoon 2.2 - some more questions

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

xweber pisze:

hi,

actually i'm trying to get a 2.2 based thingy up and running. Based on 
the

existing daisy docs there are some questions open for me. Current
questions:

1.) the demo-application-context.xml file
what about that filename - must it reflect the package name? Or must 
there
only be a file ending with ..-application-context.xml. Is there only 
one of

this files for all packages in that block?


You can choose filename whatever you like. The only requirement is its 
location, it must be located at MEA-INF/cocoon/spring since all Spring 
configuration is read from there by default.


IIRC the .xml suffix is mandatory.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: svn commit: r552371 - trunk broken, help needed

[Reinhard Poetz]

Grzegorz Kossakowski wrote:
Reinhard, could you give it another try? I'll try to reproduce it on 
Windows.


Now I can reproduce the problem. Sorry.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: svn commit: r552371 - trunk broken, help needed

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

[EMAIL PROTECTED] pisze:

Author: gkossakowski
Date: Sun Jul  1 16:13:44 2007
New Revision: 552371

URL: http://svn.apache.org/viewvc?view=revrev=552371
Log:
COCOON-2082: Getting rid of Avalon dependencies, it includes:
* conversion JS, JXPath and JEXL compilers to Spring beans
* conversion DefaultExpressionFactory to Spring bean, it collects 
language compilers by using bean-map from Spring configurator


As you see, I'm in between of Avalon-Spring conversion process for 
expression languages. I have not moved and adjusted tests (thus build 
will fail) because I came across very obscure problem.


First of all I would like you to ask to do svn up and mvn clean install 
-Dmaven.test.skip=true for trunk, run cocoon-webapp, access 
http://localhost:/blocks/cocoon-template-sample/view/caching2

and check if you get following error:
TypeError: Cannot read property parameters from undefined (#1)


AFAICS the problem is that we want to support the syntax

  cocoon.request.parameters.foo

to access request parameters. For some reason this isn't supported anymore after 
your refactorings though I can't see from your commits where this could be 
caused. (Well actually I don't have an idea where this feature is implemented at 
all.)


I would be grateful for any reports to be sure if it's not a JDK issue 
or so. Also, any help with sorting this out is really appreciated 
because I'm really out of ideas how to track such a weird problem. 
Details below.



After conversion (changes in r552371) ExpressionContext creation is 
slightly broken. Take a look at 
TemplateObjectModelHelper#getTemplateObjectModel method, the most 
interesting fragment is line:


cocoon.put(settings, 
(Settings)WebAppContextUtils.getCurrentWebApplicationContext().getBean(Settings.ROLE)); 



Cocoon object is normal Java's HashMap, so it seems that there should 
happen nothing fancy. As you guess, something weird happens, though ;)
More specifically, this put breaks completely cocoon object. Inspection 
in debugger of this object shows that before put operation mentioned 
above everything looks ok and just after keys of HashMap are getting out 
of sync of values (table). In a fact, the table of values contains 3 
items (and is lacking request object, that explains an exception) and 
keySet contains 4 items (including request). Moreover, if I change key 
from settings to something else like test, cocoon object is less 
broken (table includes request) but if you iterate the cocoon object you 
will never reach the request object.


From using the debugger I came to the conclustion that the cocoon object is 
setup correctly (at least for me). I don't see this weird behaviour.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 others

[Reinhard Poetz]

Giacomo Pati wrote:

Grzegorz Kossakowski wrote:

Giacomo Pati pisze:


I could confirm that Cocoon was working up to last friday. But after
updating my local repo an hour
ago or so, I'm facing serious problems with Cocoon throwing an
exception like the one below so I
have to revert my previous vote to a _-1_:

Do you use Cocoon from trunk or Cocoon from staging repo that we vote on?


Sorry, I meant trunk so I missread Reinhards mail and thus can give again a +1 
for the stuff in the staging repo.

But anyway, something beyond revision 552148 has broke trunk.


yes, see the svn commit: r552371 - trunk broken, help needed thread.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

[result][vote] Releasing from trunk: Cocoon 2.2-RC1 others (take 3)

[Reinhard Poetz]

The proposed modules have been accepted by 4 +1 (Giacomo voted at a different 
thread but meant take 3) and 1 +0 vote. I will move the artifacts into the 
Apache Maven M2 sync repository asap.


I will work on the website and an announcement mail but this will take some more 
time though.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: svn commit: r552371 - trunk broken, help needed

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

Reinhard Poetz pisze:

Grzegorz Kossakowski wrote:
Reinhard, could you give it another try? I'll try to reproduce it on 
Windows.


Now I can reproduce the problem. Sorry.


I think that my last commit (r552518) fixes the problem. It was a silly 
mistake: JS and JEXL beans where mixed up so initialization was not done 
properly.


Test and report if it works for you, please. Thanks!


works again. Thanks!

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: cocoon 2.2 - some more questions

[Reinhard Poetz]

Joerg Heinicke wrote:

On 02.07.2007 21:39, xweber wrote:

is it possible to call java directly from sitemap.xmap - so that 
java is
the flow language? I looked up in the docs but did not find something 
like

that. If its possible - is the a docs like it is for flowscript?


Yes, there is a Java equivalent for flow script. It's mostly called 
javaflow. The API should actually be the same. I'm not aware of some 
documentation. But a search on both lists should reveal some comparisons.


Unfortunatly Javaflow doesn't work in trunk (AFAIK).

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Eclipse Jetty plugin configuration with C22

[Reinhard Poetz]

Jean-Christophe Kermagoret wrote:

Reinhard Poetz a écrit :

Jean-Christophe Kermagoret wrote:

Hi,
I configured Eclipse Jetty plugin with Cocoon-22 a few days ago and 
everything was fine.


I updated my cocoon distribution with svn and it is now necessary to 
indicate all libs in jetty configuration.


Why is it now necessary ? Is it the correct behaviour ?


Are you using the reloading classloader goal to create a web 
application for your block?




Yes, I configured it.
I also noticed source are not available when debugging, but projects are 
present under eclipse and compile correctly.


Are you using snapshot artifacts built by yourself? AFAIK source artifacts are 
not put into your local repository if you run the Maven build yourself.


If you use the proposed release artifacts (2.2RC1) you have to run 'mvn 
eclipse:eclipse -DdownloadSources=true' in order to get the sources attached to 
the libraries. Then also using the Eclipse Jetty plugin (pointing to 
./target/rcl/webapp) works as expected.


(Note: I had some problems with the Maven Eclipse plugin 2.3 and downgraded to 
2.2.)

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Cocoon Maven plugin - RCL goal refactorings

[Reinhard Poetz]

Giacomo Pati wrote:

Reinhard Poetz wrote:

Giacomo Pati wrote:

If you need some help just ask. Maybe I can snip up a sample. Would
that be feasible?

yes, provding a minimal Spring Security sample would help a lot because
I've not used it yet. It would be great if you create the sample based
on the block archetype. Thanks!


Ok, watch out for the commit of it _NOW_ :-) as I've already prepared a simple 
sample.

It's not yet finished but if you launch it by 'mvn clean install jetty:run' and 
point you browser to
http://localhost:888/cocoon-acegisecurity-sample/supervisor you should be 
redirected to a login
page. Enter the cocoon/cocoon user/pw pair and afterward each request will give 
you aforementioned
exception.


Thanks, that helps a lot! I can reproduce the problem but TBH I have no clue why 
this can happen at all :-( AFAICS the app context is setup correctly but once it 
gets used together with the acegi stuff, it complains that the app context is 
closed.


I will have a closer look at it ASAP.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Eclipse Jetty plugin configuration with C22

[Reinhard Poetz]

Jean-Christophe Kermagoret wrote:

Hi,
I configured Eclipse Jetty plugin with Cocoon-22 a few days ago and 
everything was fine.


I updated my cocoon distribution with svn and it is now necessary to 
indicate all libs in jetty configuration.


Why is it now necessary ? Is it the correct behaviour ?


Are you using the reloading classloader goal to create a web application for 
your block?



--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Random thoughts on object model

[Reinhard Poetz]

Daniel Fagerstrom wrote:

Maybe other people have different or more positive experience of branching?


Not really :-(
Keeping trunk and branch in sync is a lot of work.


In the end, use your judgement and do what you think is best.


I agree with this. Grek, if you think that your commits affect Cocoon trunk in a 
way so that it becomes unuseable for all others then consider branching. I (we) 
learned from history that an unusable trunk is a very bad thing for a community. 
If you see any chance to keep trunk working, don't branch.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

[vote] Releasing from trunk: Cocoon 2.2-RC1 others (take 3)

[Reinhard Poetz]

Because of Vadim's findings 
(http://marc.info/?l=xml-cocoon-devm=118295221205686w=2) I've recreated 
following release artifacts


org.apache.cocoon.cocoon:4
org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1
org.apache.cocoon:cocoon-core:2.2.0-RC1

  - o -

I prepared another series of releases from trunk, see the list of all 43
modules below. Most of them are proposed to be released as RC1 (release 
candidate 1). The exceptions are


 - the forms and the ajax block which need more work related to their usage
   of the servlet service framework
 - the servlet-service framework which introduces some contracts
   that are under discussion
 - the Cocoon Maven 2 plugin which needs more user feedback

The release of release candidates means that we don't/can't change contracts 
without a deprecation period (e.g. deprecate something in 2.2.x, keep it in 
2.3.x and remove it in 2.4.x or 3.x).



You can find the staged artifacts of all modules (sources, binaries, javadocs +
checksums + pgp signatures) at

 - http://people.apache.org/builds/cocoon/
   (Maven 2 repo)
 - http://people.apache.org/builds/cocoon/cocoon-2.2RC1-all.tar.gz
   (tar archive of all artifacts).

SVN tags of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/. I put my pgp key into 
the http://svn.apache.org/repos/asf/cocoon/trunk/commons/KEYS.

Find instructions about how you can test in a seperate mail. Report your
findings to that thread and use this one for voting only. Thanks!

This majority vote stays open for 72 hours.

Finally, here's the list of modules to be voted on:

Core artifacts (jar)

org.apache.cocoon:cocoon-pipeline-api:1.0.0-RC1
org.apache.cocoon:cocoon-util:1.0.0-RC1
org.apache.cocoon:cocoon-xml-api:1.0.0-RC1
org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1
org.apache.cocoon:cocoon-xml-impl:1.0.0-RC1
org.apache.cocoon:cocoon-pipeline-components:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-api:1.0.0-RC1
org.apache.cocoon:cocoon-thread-api:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-impl:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-components:1.0.0-RC1
org.apache.cocoon:cocoon-xml-resolver:1.0.0-RC1
org.apache.cocoon:cocoon-store-impl:1.0.0-RC1
org.apache.cocoon:cocoon-thread-impl:1.0.0-RC1
org.apache.cocoon:cocoon-core:2.2.0-RC1

Subproject: Servlet-Service (jar)
-
org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M2
org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M2

Blocks (jar)

org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC1
org.apache.cocoon:cocoon-template-impl:1.0.0-RC1
org.apache.cocoon:cocoon-apples-impl:1.0.0-RC1
org.apache.cocoon:cocoon-linkrewriter-impl:1.0.0-RC1
org.apache.cocoon:cocoon-auth-api:1.0.0-RC1
org.apache.cocoon:cocoon-auth-impl:1.0.0-RC1
org.apache.cocoon:cocoon-batik-impl:1.0.0-RC1
org.apache.cocoon:cocoon-captcha-impl:1.0.0-RC1
org.apache.cocoon:cocoon-databases-mocks:1.0.0-RC1
org.apache.cocoon:cocoon-databases-impl:1.0.0-RC1
org.apache.cocoon:cocoon-databases-hsqldb-client:1.0.0-RC1
org.apache.cocoon:cocoon-databases-hsqldb-server:1.0.0-RC1
org.apache.cocoon:cocoon-fop-impl:1.0.0-RC1
org.apache.cocoon:cocoon-html-impl:1.0.0-RC1
org.apache.cocoon:cocoon-mail-impl:1.0.0-RC1

org.apache.cocoon:cocoon-forms-impl:1.0.0-M3
org.apache.cocoon:cocoon-ajax-impl:1.0.0-M3

Maven plugins, archetypes and related (jar)
---
org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1
org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1
org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1

org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC1

POM artifacts
-
org.apache.cocoon.cocoon:4
org.apache.cocoon:cocoon-core-modules:4
org.apache.cocoon:cocoon-blocks-modules:4
org.apache.cocoon:cocoon-tools-modules:4

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

[test] Cocoon 2.2-RC1 others (take 3)

[Reinhard Poetz]

If you have already tested the RC1 release (take 1 or take 2), you have to 
remove the artifacts from your local repository. Otherwise Maven won't download 
them  again.


  - o -

The proposed release artifacts are available at
http://people.apache.org/builds/cocoon/.

Except for the archetypes the easiest way to test the artifacts is by adding a
cocoon-staging profile to your ~/.m2/settings.xml:

settings
  profiles
profile
  idcocoon-staging/id
repositories
  repository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
  /repository
/repositories
pluginRepositories
  pluginRepository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
  /pluginRepository
/pluginRepositories
/profile
  /profiles
/settings

Then change the version number of the artifacts that you use in your POMs
to the number of the proposed artifact and append -P cocoon-staging to all
your Maven commands, e.g.

mvn install -P cocoon-staging

  - o -

Because of a bug with the Maven archetyp feature, using profiles doesn't work 
with the Maven archetype goal. In order to test them you can either check them 
out from SVN


http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon-22-archetype-block/cocoon-22-archetype-block-1.0.0-RC1
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon-22-archetype-webapp/cocoon-22-archetype-webapp-1.0.0-RC1
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon-22-archetype-block-plain/cocoon-22-archetype-block-plain-1.0.0-RC1

or use the latest version from SVN and change the version numbers of the 
dependencies to the numbers of the proposed modules.


The commands to use the archetypes and explanations of what they are for can be
found at http://cocoon.zones.apache.org/daisy/cdocs/g2/g5/g1/1208.html.

  - o -

I also want to draw your attention to
http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1370.html which contains
references to 4 tutorials that help you to get started with Cocoon 2.2 and also
help to test the release artifacts. Again, make sure that you use the
cocoon-staging profile for all your commands as explained above. Otherwise the
referenced artifacts can't be found.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 others (take 3)

[Reinhard Poetz]

+1

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Cocoon Maven plugin - RCL goal refactorings

[Reinhard Poetz]

Giacomo Pati wrote:

Giacomo Pati wrote:


Reinhard Poetz wrote:

Before I'm going to release the Cocoon Maven plugin, I worked on the
XPatcher for the web.xml. All .xweb snippets now get rewritten so that
the ReloadingClassloader interceptors get applied to filters, listeners
and servlets.
As I was at it I also implemented a wrapper around the normal Spring
web application context. It takes care of context reloads internally and
is completly synchronized. Giacomo reported that he had problems when
you accessed the Spring application context from outside of Cocoon, e.g.
from within a servlet filter. This _might_ be helpful in that case
though I haven't tested it yet.

I'll test it today, thanks.


Now here are my results: It doesn't work as expected!


That's strange :-(

What do I have to do to reproduce it? Is writing another servlet that accesses 
the Spring application context enough?


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Cocoon Maven plugin - RCL goal refactorings

[Reinhard Poetz]

Giacomo Pati wrote:

Reinhard Poetz wrote:

Giacomo Pati wrote:

Giacomo Pati wrote:

Reinhard Poetz wrote:

Before I'm going to release the Cocoon Maven plugin, I worked on the
XPatcher for the web.xml. All .xweb snippets now get rewritten so that
the ReloadingClassloader interceptors get applied to filters, listeners
and servlets.
As I was at it I also implemented a wrapper around the normal Spring
web application context. It takes care of context reloads internally
and
is completly synchronized. Giacomo reported that he had problems when
you accessed the Spring application context from outside of Cocoon,
e.g.
from within a servlet filter. This _might_ be helpful in that case
though I haven't tested it yet.

I'll test it today, thanks.

Now here are my results: It doesn't work as expected!

That's strange :-(

What do I have to do to reproduce it? Is writing another servlet that
accesses the Spring application context enough?


To be honest, I have no clue :-( I've simply configured acegi into the web.xml 
(as a patch) and at
the second request mentioned stacktrace is thrown.


I have never used acegi but will give it a try.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Cocoon Maven plugin - RCL goal refactorings

[Reinhard Poetz]

Giacomo Pati wrote:

If you need some help just ask. Maybe I can snip up a sample. Would that be 
feasible?


yes, provding a minimal Spring Security sample would help a lot because I've not 
used it yet. It would be great if you create the sample based on the block 
archetype. Thanks!


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 others (take 2)

[Reinhard Poetz]

Vadim Gritsenko wrote:

cocoon-core-2.2.0-RC1-tests.jar and 
cocoon-pipeline-impl-1.0.0-RC1-tests.jar have no required LICENSE, 
NOTICE files.


*argh*


cocoon-4.pom file has no license header.


I guess it got lost after the first release :-(


All of maven-metadata.xml files have no license header either.


Do we really have to add our license header to those files? AFAICS nobody does 
it. Do they really contain (enough) protectable intellectual property? I don't 
think so.


 - o -

Anyway, I have to release cocoon-4, cocoon-core-2.2.0-RC1-tests and 
cocoon-pipeline-impl-1.0.0-RC1-tests again. Since all other modules depend on 
them, this stops the release of all other artifacts too :-(


The problem is that

 a) I'm not sure how to add LICENSE and NOTICE to the _old_ code.
I guess I have to create branches of those modules first,
add the files there and run mvn release again.
 b) I don't have much time for opensource stuff ATM hence I can't say
when I can do it. Sorry.

If somebody has more time for the release of the three artifacts, just let me 
know ...


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

[jira] Commented: (COCOON-2080) interface com.atn.htest.PersonDAO is not visible from class loader

[Reinhard Poetz (JIRA)]

[ 
https://issues.apache.org/jira/browse/COCOON-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508564
 ] 

Reinhard Poetz commented on COCOON-2080:


The problem is that if a class or an interface is loaded by the reloading 
classloader and it is used to create a proxy from it, it can't be found. As a 
workaround you can put the interface in a different module which is added as 
normal dependency to your block (of course you mustn't add this other module to 
your rcl.properties either).

 interface com.atn.htest.PersonDAO is not visible from class loader
 --

 Key: COCOON-2080
 URL: https://issues.apache.org/jira/browse/COCOON-2080
 Project: Cocoon
  Issue Type: Bug
  Components: * Cocoon Core, - Build System: Maven
Affects Versions: 2.2-dev (Current SVN)
Reporter: Vladimir S Bronnikov

 I'm wrote my own Generator. The main purpose of them is to find spring 
 beans in application context and invoke thier methods.
   WebApplicationContext ctx = 
 WebAppContextUtils.getCurrentWebApplicationContext();
   Object bf = ctx.getBean(beanName);
   Method method = BeanUtils.findMethod(bf.getClass(), methodName, 
 paramTypes);
   Object result = method.invoke(bf, paramValues);
 When I deploy my cocoon block first time - all fine.
 But if I change some resource and rcl do it's work, I get this error:
 org.springframework.beans.factory.BeanCreationException: Error creating bean 
 with name 'com.atn.htest.PersonDAO' defined in URL 
 [file:D:/work/eclipse-3.2.1/workspaces/springframework/block2/target/classes/META-INF/cocoon/spring/demo-application-context.xml]:
  Invocation of init method failed; nested exception is 
 java.lang.IllegalArgumentException: interface com.atn.htest.PersonDAO is not 
 visible from class loader
 Caused by: java.lang.IllegalArgumentException: interface 
 com.atn.htest.PersonDAO is not visible from class loader
   at java.lang.reflect.Proxy.getProxyClass(Proxy.java:353)
   at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
   at 
 org.springframework.aop.framework.JdkDynamicAopProxy.getProxy(JdkDynamicAopProxy.java:117)
   at 
 org.springframework.aop.framework.ProxyFactory.getProxy(ProxyFactory.java:110)
   at 
 org.springframework.aop.framework.AbstractSingletonProxyFactoryBean.getProxy(AbstractSingletonProxyFactoryBean.java:187)
   at 
 org.springframework.aop.framework.AbstractSingletonProxyFactoryBean.afterPropertiesSet(AbstractSingletonProxyFactoryBean.java:159)
   at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1202)
   at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1172)
   at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:428)
   at 
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251)
   at 
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:156)
   at 
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248)
   at 
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160)
   at 
 org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:284)
   at 
 org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352)
   at 
 org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:244)
   at 
 org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:187)
   at 
 org.apache.cocoon.tools.rcl.springreloader.SpringReloader.reload(SpringReloader.java:57)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingSpringFilter.doFilter(ReloadingSpringFilter.java:64)
   at 
 org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServletFilter.doFilter(ReloadingServletFilter.java:50)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
 Why after reload classloader interface is not visible?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email

[result][vote] Releasing from trunk: Cocoon 2.2-RC1 others (take 2)

[Reinhard Poetz]

Since no PMC can overrule ASF wide release guidelines (see Vadim's findings), we 
can't release the proposed artifacts as they are.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Separate projects on JIRA - final proposal

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

Hello,

Reinhard asked[1] me to provide a final list of Cocoon modules that 
would get their own JIRA projects. Here is the list of projects with

proposed JIRA identifiers in brackets:
- Cocoon Core (COCOONCORE)
  includes following artifacts:
  * org.apache.cocoon:cocoon-pipeline-api
  * org.apache.cocoon:cocoon-util
  * org.apache.cocoon:cocoon-xml-api
  * org.apache.cocoon:cocoon-pipeline-impl
  * org.apache.cocoon:cocoon-xml-impl
  * org.apache.cocoon:cocoon-pipeline-components
  * org.apache.cocoon:cocoon-sitemap-api
  * org.apache.cocoon:cocoon-thread-api
  * org.apache.cocoon:cocoon-sitemap-impl
  * org.apache.cocoon:cocoon-sitemap-components
  * org.apache.cocoon:cocoon-xml-resolver
  * org.apache.cocoon:cocoon-store-impl
  * org.apache.cocoon:cocoon-thread-impl
  * org.apache.cocoon:cocoon-core
  * org.apache.cocoon:cocoon-core-main-sample
- Servlet service framework (SERVLETSERVICE)
  * org.apache.cocoon:cocoon-servlet-service-components
  * org.apache.cocoon:cocoon-servlet-service-impl
  * org.apache.cocoon:cocoon-servlet-service-sample
- Template (TEMPLATE)
  * org.apache.cocoon:cocoon-template-impl
  * org.apache.cocoon:cocoon-template-sample
- Flowscript (FLOWSCRIPT)
  * org.apache.cocoon:cocoon-flowscript-impl
- Database (DATABASE)
  * org.apache.cocoon:cocoon-databases-mocks
  * org.apache.cocoon:cocoon-databases-hsqldb-server
  * org.apache.cocoon:cocoon-databases-hsqldb-client
  * org.apache.cocoon:cocoon-databases-impl
- Forms (FORMS)
  * org.apache.cocoon:cocoon-forms-impl
  * org.apache.cocoon:cocoon-forms-sample
- M2 Plugins and archetypes (COCOONM2)
  * org.apache.cocoon:cocoon-maven-plugin
  * org.apache.cocoon:cocoon-rcl-spring-reloader
  * org.apache.cocoon:cocoon-rcl-webapp-wrapper
  * org.apache.cocoon:cocoon-22-archetype-block
  * org.apache.cocoon:cocoon-22-archetype-block-plain
  * org.apache.cocoon:cocoon-22-archetype-webapp

The main idea is to split up current big COCOON JIRA project into 
smaller projects focused on one area. Artifacts that are not listed 
above would stay in COCOON project, at least for now. I don't want to 
create new separate projects for every artifact/block because big number 
of project in JIRA would not improve maintenance, quite contrary I would 
say. After taking this first step towards separation we should just wait 
and see if further divisions are needed.


sounds good


Each artifact belonging to JIRA project would become its component.


makes sense

That 
means we still have to have shared version number in JIRA's projects 
(e.g. in COCOONCORE where cocoon-core is 2.0.0 and sitemap-impl is 
1.0.0) but I think its compromise between situation we have today and a 
situation where we have about fifty different JIRA projects that no one 
wants to force her way through.


that's no problem to have shared version numbers in the proposed projects AFAICT

If we agree on the proposal I would take care of labour work, like 
asking JIRA for projects creation, moving issues, adjusting poms etc., 
myself during next weekend. What do you think?


Do you ask for a seperate JIRA instance or new projects only?

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 others (take 2)

[Reinhard Poetz]

Reinhard Poetz wrote:

snip/

You can find the staged versions of all modules (sources, binaries, 
javadocs +

checksums + gpg signatures) at

 - http://people.apache.org/builds/cocoon/
   (Maven 2 repo)
 - http://people.apache.org/builds/cocoon/cocoon-2.2RC1-all.tar.gz
   (tar archive of all artifacts).

SVN tags of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/. I put my pgp 
key into the http://svn.apache.org/repos/asf/cocoon/trunk/commons/KEYS.

Find instructions about how you can test in a seperate mail. Report your
findings to that thread and use this one for voting only. Thanks!

This majority vote stays open for 120 hours.

Finally, here's the list of modules to be voted on:


snip/

+1

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Separate projects on JIRA - final proposal

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

Reinhard Poetz pisze:

Grzegorz Kossakowski wrote:


snip/



If we agree on the proposal I would take care of labour work, like 
asking JIRA for projects creation, moving issues, adjusting poms 
etc., myself during next weekend. What do you think?


Do you ask for a seperate JIRA instance or new projects only?


I think that having new projects will be sufficient. Do you know any 
advantages of having separate JIRA instance?


No, I don't think so.

Repeating the question: shall I start a vote after clarifying the issues 
above?


Please do!

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Cocoon Maven plugin - RCL goal refactorings

[Reinhard Poetz]

Giacomo Pati wrote:

Reinhard Poetz wrote:

Before I'm going to release the Cocoon Maven plugin, I worked on the
XPatcher for the web.xml. All .xweb snippets now get rewritten so that
the ReloadingClassloader interceptors get applied to filters, listeners
and servlets.

As I was at it I also implemented a wrapper around the normal Spring
web application context. It takes care of context reloads internally and
is completly synchronized. Giacomo reported that he had problems when
you accessed the Spring application context from outside of Cocoon, e.g.
from within a servlet filter. This _might_ be helpful in that case
though I haven't tested it yet.


I'll test it today, thanks.


You can either test with trunk or use the artifacts from the staging repository 
(though you have to make sure that you don't have the old artifacts 
org.apache.cocoon:cocoon, org.apache.cocoon:cocoon-maven-plugin, 
org.apache.cocoon:cocoon-rcl-* in your repository):


profile
  idcocoon-staging/id
repositories
  repository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
  /repository
/repositories
pluginRepositories
  pluginRepository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
  /pluginRepository
/pluginRepositories
/profile



Since the reloads are done within the wrapper (-- the object instance
doesn't change anymore), this might also make the app context reload
check of the DispatcherServlet obsolete. Though I haven't tested this
either because I ran all my tests with RC1 modules. Additionally it
could help with Giacomo's problem too.


You say might help too, does that mean it is still doing so or you have 
removed said code?


No I haven't removed that code neither in trunk nor locally and therefore 
haven't been able to test it. But I think it's worth a try :-)



Finally, I also ran into a problem if the application context contains
proxied beans. If their interfaces are loaded by the reloading
classloader, the application context refuses to work after a reload. I
guess it is somehow related to the reloading classloader of commons-jci.
As a workaround you have to put all those interfaces of proxied beans
into a module which is not loaded by the reloading classloader.


Can you briefly explain how this is done?


It worked for me when I set up a seperate module that contains the interfaces 
which are used to create a proxy bean instance from. Then I run 'mvn install' to 
put the jar of the module into my local repo and added the dependency to the pom 
of the project that uses the RCL goal.
That's not ideal but at least it makes it possible to use the reloading 
classloader together with proxied beans.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

[vote] Releasing from trunk: Cocoon 2.2-RC1 others (take 2)

[Reinhard Poetz]

I prepared another series of releases from trunk, see the list of all 43
artifacts below. The problems with references to snapshots and the usage of the 
repository element in some of the poms are sorted out.


Most of the modules are proposed to be released as RC1 (release candidate 1). 
The exceptions are


 - the forms and the ajax block which need more work related to their usage
   of the servlet service framework
 - the servlet-service framework which introduces some contracts
   that are under discussion
 - the Cocoon Maven 2 plugin which needs more user feedback

The release of release candidates means that we don't/can't change contracts 
without a deprecation period (e.g. deprecate something in 2.2.x, keep it in 
2.3.x and remove it in 2.4.x or 3.x).



You can find the staged versions of all modules (sources, binaries, javadocs +
checksums + gpg signatures) at

 - http://people.apache.org/builds/cocoon/
   (Maven 2 repo)
 - http://people.apache.org/builds/cocoon/cocoon-2.2RC1-all.tar.gz
   (tar archive of all artifacts).

SVN tags of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/. I put my pgp key into 
the http://svn.apache.org/repos/asf/cocoon/trunk/commons/KEYS.

Find instructions about how you can test in a seperate mail. Report your
findings to that thread and use this one for voting only. Thanks!

This majority vote stays open for 120 hours.

Finally, here's the list of modules to be voted on:

Core artifacts (jar)

org.apache.cocoon:cocoon-pipeline-api:1.0.0-RC1
org.apache.cocoon:cocoon-util:1.0.0-RC1
org.apache.cocoon:cocoon-xml-api:1.0.0-RC1
org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1
org.apache.cocoon:cocoon-xml-impl:1.0.0-RC1
org.apache.cocoon:cocoon-pipeline-components:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-api:1.0.0-RC1
org.apache.cocoon:cocoon-thread-api:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-impl:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-components:1.0.0-RC1
org.apache.cocoon:cocoon-xml-resolver:1.0.0-RC1
org.apache.cocoon:cocoon-store-impl:1.0.0-RC1
org.apache.cocoon:cocoon-thread-impl:1.0.0-RC1
org.apache.cocoon:cocoon-core:2.2.0-RC1

Subproject: Servlet-Service (jar)
-
org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M2
org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M2

Blocks (jar)

org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC1
org.apache.cocoon:cocoon-template-impl:1.0.0-RC1
org.apache.cocoon:cocoon-apples-impl:1.0.0-RC1
org.apache.cocoon:cocoon-linkrewriter-impl:1.0.0-RC1
org.apache.cocoon:cocoon-auth-api:1.0.0-RC1
org.apache.cocoon:cocoon-auth-impl:1.0.0-RC1
org.apache.cocoon:cocoon-batik-impl:1.0.0-RC1
org.apache.cocoon:cocoon-captcha-impl:1.0.0-RC1
org.apache.cocoon:cocoon-databases-mocks:1.0.0-RC1
org.apache.cocoon:cocoon-databases-impl:1.0.0-RC1
org.apache.cocoon:cocoon-databases-hsqldb-client:1.0.0-RC1
org.apache.cocoon:cocoon-databases-hsqldb-server:1.0.0-RC1
org.apache.cocoon:cocoon-fop-impl:1.0.0-RC1
org.apache.cocoon:cocoon-html-impl:1.0.0-RC1
org.apache.cocoon:cocoon-mail-impl:1.0.0-RC1

org.apache.cocoon:cocoon-forms-impl:1.0.0-M3
org.apache.cocoon:cocoon-ajax-impl:1.0.0-M3

Maven plugins, archetypes and related (jar)
---
org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1
org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1
org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1

org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC1

POM artifacts
-
org.apache.cocoon.cocoon:4
org.apache.cocoon:cocoon-core-modules:4
org.apache.cocoon:cocoon-blocks-modules:4
org.apache.cocoon:cocoon-tools-modules:4

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

[test] Cocoon 2.2-RC1 others (take 2)

[Reinhard Poetz]

The proposed release artifacts are available at
http://people.apache.org/builds/cocoon/.

Except for the archetypes the easiest way to test the artifacts is by adding a
cocoon-staging profile to your ~/.m2/settings.xml:

settings
  profiles
profile
  idcocoon-staging/id
repositories
  repository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
  /repository
/repositories
pluginRepositories
  pluginRepository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
  /pluginRepository
/pluginRepositories
/profile
  /profiles
/settings

Then change the version number of the artifacts that you use in your POMs
to the number of the proposed artifact and append -P cocoon-staging to all
your Maven commands, e.g.

mvn install -P cocoon-staging

  - o -

Because of a bug with the Maven archetyp feature, using profiles doesn't work 
with the Maven archetype goal. In order to test them you can either check them 
out from SVN


http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon-22-archetype-block/cocoon-22-archetype-block-1.0.0-RC1
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon-22-archetype-webapp/cocoon-22-archetype-webapp-1.0.0-RC1
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon-22-archetype-block-plain/cocoon-22-archetype-block-plain-1.0.0-RC1

or use the latest version from SVN.

The commands to use the archetypes and explanations of what they are for can be
found at http://cocoon.zones.apache.org/daisy/cdocs/g2/g5/g1/1208.html.

  - o -

I also want to draw your attention to
http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1370.html which contains
references to 4 tutorials that help you to get started with Cocoon 2.2 and also
help to test the release artifacts. Again, make sure that you use the
cocoon-staging profile for all your commands as explained above. Otherwise the
referenced artifacts can't be found.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Trunk doesn't build?

[Reinhard Poetz]

Giacomo Pati wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Reinhard, can it be that you left some dependencyMgmt stuff commented in the 
root pom?

The trunk doesn't build here because of the cocoon-ajax block is missing some 
versions of other blocks.

Ciao and thanks


uuups, sorry. I'm going to fix this. As soon as the build runs through I will 
commit the root pom.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Releasing 2.2RC1

[Reinhard Poetz]

Reinhard Poetz wrote:

Grzegorz Kossakowski wrote:

Reinhard, how long will it take for you to prepare new release?


I'm working on it. Since I'm only replacing the faulty arifacts (4),
it should be finished by this evening.


It takes me longer than expected. I had a nasty bug in the Spring reloading 
mechanism that I wanted to see fixed before the release.


Now I'm running out of time for the actual release work but hope to continue 
this afternoon or tommorrow morning.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Releasing 2.2RC1

[Reinhard Poetz]

Reinhard Poetz wrote:

Reinhard Poetz wrote:

Grzegorz Kossakowski wrote:

Reinhard, how long will it take for you to prepare new release?


I'm working on it. Since I'm only replacing the faulty arifacts (4),
it should be finished by this evening.


It takes me longer than expected. I had a nasty bug in the Spring 
reloading 


of the Cocoon Maven plugin (rcl goal)


mechanism that I wanted to see fixed before the release.

Now I'm running out of time for the actual release work but hope to 
continue this afternoon or tommorrow morning.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Cocoon Maven plugin - RCL goal refactorings

[Reinhard Poetz]

Before I'm going to release the Cocoon Maven plugin, I worked on the XPatcher 
for the web.xml. All .xweb snippets now get rewritten so that the 
ReloadingClassloader interceptors get applied to filters, listeners and servlets.


As I was at it I also implemented a wrapper around the normal Spring web 
application context. It takes care of context reloads internally and is 
completly synchronized. Giacomo reported that he had problems when you accessed 
the Spring application context from outside of Cocoon, e.g. from within a 
servlet filter. This _might_ be helpful in that case though I haven't tested it yet.


Since the reloads are done within the wrapper (-- the object instance doesn't 
change anymore), this might also make the app context reload check of the 
DispatcherServlet obsolete. Though I haven't tested this either because I ran 
all my tests with RC1 modules. Additionally it could help with Giacomo's problem 
too.


Finally, I also ran into a problem if the application context contains proxied 
beans. If their interfaces are loaded by the reloading classloader, the 
application context refuses to work after a reload. I guess it is somehow 
related to the reloading classloader of commons-jci.
As a workaround you have to put all those interfaces of proxied beans into a 
module which is not loaded by the reloading classloader.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Interblock communication

[Reinhard Poetz]

Ralph Goers wrote:

Daniel Fagerstrom wrote:
Letting all blocks share the same global session would lead to code 
that would be hard to debug and reuse, so that would not be such a 
good idea. We could think about having a local session for each 
servlet service, but that is not implemented yet.


What you currently do is that you have a main servlet service that 
contain session handling etc and that calls other servlet services 
that does there work without sessions. For me that is enough, but if 
other people have use cases that require more, we can find some way to 
extend it.


/Daniel
Thanks for this info. This does raise concern although perhaps it is 
misplaced. I am working on a project that heavily uses portlets. The 
current portlet spec makes it difficult to share session attributes 
across the web application. The downside is that it leads to all kinds 
of kludges and performance problems. For example, you would like to call 
a single business service and have its data available to multiple 
portlets as each might simply provide different views of the data.  I 
could easily see the same sort of requirement with blocks.


In general, the isolation is probably the correct approach, but only if 
there is a way to explicitly declare that certain objects should be shared.


I'm not sure if it is directly helpful for your problem, but Spring 2.x offers 
request, session and global-session scoped beans 
(http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-other).


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Interblock communication

[Reinhard Poetz]

Ralph Goers wrote:



Reinhard Poetz wrote:
I'm not sure if it is directly helpful for your problem, but Spring 
2.x offers request, session and global-session scoped beans 
(http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-other). 

Thanks, but that doesn't help. A portal typically consists of the portal 
webapp and several portlet wars. The session variables have to be shared 
across theses various webapps. However, the portlet spec mandates that 
they each have their own session. Most portal vendors provide 
proprietary ways around this.  Also, in this environment each portlet 
war will have its own Spring container. The beans can't be shared 
without getting ClassLoader errors.


These are the types of issues you want to avoid creating.


hmmm, just wondering what the globalSession scope of Spring is good for then? 
According to the Spring documentation it solves exactly this problem.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [ANNOUNCEMENT] release of common jci 1.0

[Reinhard Poetz]

Torsten Curdt wrote:

Jakarta Commons JCI 1.0 is now available!

 http://jakarta.apache.org/commons/jci/

JCI is a java compiler interface. It can be used to either compile java 
(or any other language that can be compiled to java classes like e.g. 
groovy or javascript) to java. It is well integrated with a FAM 
(FilesystemAlterationMonitor) that can be used with the JCI 
compiling/reloading classloader. All the currently supported compilers 
(even javac before java6) feature in-memory compilation. It currently 
supports compilers like eclipse, janino, groovy, rhino and javac.


Apache Jakarta Commons JCI is available in either binary or source form 
from the JCI downloads page or your favorite maven repository mirror.


 http://jakarta.apache.org/site/downloads/downloads_commons-jci.cgi


Thanks Torsten, that's really great news for us!!!

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [ANNOUNCEMENT] release of common jci 1.0

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

Reinhard, how long will it take for you to prepare new release?


I'm working on it. Since I'm only replacing the faulty arifacts (4),
it should be finished by this evening.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: How to import cocoon-forms-sample in a new created block architecture

[Reinhard Poetz]

Jean-Christophe Kermagoret wrote:

Hi,
I want to use RCL because I need to make modifications in CForms block. 
And RCL seems the good way to do it.


Maybe I'm wrong ?


No, I don't think so. Unfortunatly I haven't had time to try it myself yet but I 
will give it a shot myself this week.


Here two hints, what _could_ be wrong with your configuration:

 - the block name must be the name of the forms-samples block
 - add the forms-samples block to the dependencies section of your custom
   block before you run mvn cocoon:rcl

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: svn commit: r544906 - /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-components/src/main/java/org/apache/cocoon/servletservice/postable/components/

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

I also wouldn't mind to have Daisy's Adminstraton rights myself.


here you are

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

[jira] Commented: (COCOON-2076) Exception when Reloading Classloader

[Reinhard Poetz (JIRA)]

[ 
https://issues.apache.org/jira/browse/COCOON-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503160
 ] 

Reinhard Poetz commented on COCOON-2076:


You're right, the solution isn't the most elegant one. IIRC the problem was 
that the DispatcherServlet is managed by the servlet container and I wasn't 
able to get access to it in a clean way (yes, I could introduce a static method 
but this is even more awkward than the check of the startup date IMO).

As long as we don't have a better idea, I suggest that we put the check of the 
startup date back into the code and add a TODO.

 Exception when Reloading Classloader
 

 Key: COCOON-2076
 URL: https://issues.apache.org/jira/browse/COCOON-2076
 Project: Cocoon
  Issue Type: Bug
  Components: * Cocoon Core, - Build System: Maven, - Servlet service 
 framework
Affects Versions: 2.2-dev (Current SVN)
Reporter: Vladimir S Bronnikov

 I'm running own cocoon block using Reload Classloader (see 
 http://cocoon.zones.apache.org/dev-docs/2.2/maven-plugins/maven-plugin/1.0/1297_1_1.html).
  Then I change one of my class. After update my browser I get foloowing error 
 in stactrace:
 2007-06-07 12:57:38,518 btpool0-1 ERROR cocoon - Internal Cocoon Problem
 org.apache.cocoon.ProcessingException: Processor is not set.
   at 
 org.apache.cocoon.environment.internal.EnvironmentHelper.enterProcessor(EnvironmentHelper.java:275)
   at 
 org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:345)
   at 
 org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:171)
   at 
 org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:62)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
   at 
 org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:538)
   at 
 org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:520)
   at 
 org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:229)
   at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
   at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
   at $Proxy0.service(Unknown Source)
   at 
 org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:92)
 ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: DispatcherServlet

[Reinhard Poetz]

Daniel Fagerstrom wrote:

Grzegorz Kossakowski skrev:

So we could have:

servlet:connection_name:/path
for relative URLs and

servlet://bean_ID:/path
for absolute URLs


Don't like having a bean id where you would expect to have a servername. 
 I think the servlet:!com.mycompany.block1.servlet:/... would be OK. It 
has a correct syntax, at least I don't have any associations to the '!' 
and it looks quite technical which is good as it mainly is available 
for internal use.


+1

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Cocoon22 : Exception during streaming source

[Reinhard Poetz]

Jean-Christophe Kermagoret wrote:

Hi,
I made the following :
  svn update (so I get the last svn from trunk  - 22 version)
cd trunk
mvn -P allblocks -Dmaven.test.skip=true install
cd core/cocoon-webapp
mvn jetty:run

Everything went fine : I get the sample page

Then, I decided to create a new block with archetype in a test directory 
I just created :
 mvn archetype:create -DarchetypeGroupId=org.apache.cocoon 
-DarchetypeArtifactId=cocoon-22-archetype-block 
-DarchetypeVersion=1.0.0-RC1 -DgroupId=com.mycompany -DartifactId=myBlock1


and then I installed cocoon-rcl and maven-plugin by going to trunk/tools :
  mvn install

Finally, I go to test directory and issued the following commands :
  mvn cocoon:rcl
The webapp seems to be correctly created, then :
  mvn jetty:run

When I go to http://localhost:/myBlock1/, I then get the following 
error.

If I add a very simple test like this one,
 map:match pattern=test
 map:redirect-to uri=http://www.google.fr/
 /map:match

I still get the same error. Any ideas ?



It might be that you got confused with version numbers and Maven swallowed the 
exceptions, though I'm not sure.


If you build the archetypes from trunk, you have to use the SNAPSHOT versions:

mvn archetype:create -DarchetypeGroupId=org.apache.cocoon 
-DarchetypeArtifactId=cocoon-22-archetype-block 
-DarchetypeVersion=1.0.0-RC2-SNAPSHOT -DgroupId=com.mycompany

   ^^
-DartifactId=myBlock1

The same is true for the cocoon-maven-plugin.

If this doesn't help, please create a Jira issue and append a zip of your block1 
directory to it.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 others

[Reinhard Poetz]

Because of Joakim's and Grek's findings, I hereby withdraw the vote. I will 
provide the corrected artifacts



org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC1
org.apache.cocoon.cocoon:4


as soon as commons-jci is available on the central Maven repo and start the vote 
then again.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: slight problem with testing RC1

[Reinhard Poetz]

[EMAIL PROTECTED] wrote:

Grzegorz Kossakowski [EMAIL PROTECTED] writes:


[EMAIL PROTECTED] pisze:

Grzegorz Kossakowski [EMAIL PROTECTED] writes:

I followed your example but still get exactly the same error!

Joakim, could you please try again with testing-cocoon-settings.xml included 
below?


A brief test confirms that seems to work.
The page I get from the myBlock1 sample is empty, so I suppose I must
continue to follow the tutorial to see anything. At least it doesnt
crash :)


Thanks Joakim and Grek!

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [test] Cocoon 2.2-RC1 others

[Reinhard Poetz]

Carsten Ziegeler wrote:

Reinhard Poetz wrote:

Leszek Gawron wrote:

Reinhard Poetz wrote:


The proposed release artifacts are available at
http://people.apache.org/builds/cocoon/.


Why is there no release of cocoon spring configurator?


because there has already been a final release 1.0.0 of it and there 
haven't been any changes that would justify a 1.0.1.


Hmm, there have been some changes and actually the 1.0.0 release is not 
100% correct as it contains 1.0.1 references :) So, it would be great to 
have a 1.0.1 release as well.


Ok. I will do so.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Discussion about Maven

[Reinhard Poetz]

Grzegorz Kossakowski wrote:
Even though I agree that it's the best to release all of our 
dependencies I would like to know your opinion on how to handle cases 
when not all our dependencies are on central server. I'm going to play 
with profiles.xml file and see how it performs for us. I would like to 
no if anyone is going to have a better/other idea.


We have to distinguish between two scenarios:

 1. building your own application using Cocoon artifacts
 2. building Cocoon from SVN

ad 1): It was my mistake that I released a POM with dependencies that are not 
available on the central Maven repository. As soon as commons-jci is available, 
there is no need for it anymore.


ad 2): It's only some blocks (e.g. some portal stuff) that depend on 
dependencies outside. As long as they don't get released, that's not a problem.
Note that the root POM doesn't have any dependency on any other repository than 
the central Maven repository anymore.
Things might be different with Maven 2.1 but I suggest that we solve this 
problem when Maven 2.1 is generally available.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 others

[Reinhard Poetz]

Vadim Gritsenko wrote:

Reinhard Poetz wrote:

I prepared another series of releases from trunk, see the list of all 43
artifacts below. 

...
You can find the staged versions of the modules (sources, binaries, 
javadocs + checksums + gpg signatures) at 
http://people.apache.org/builds/cocoon/.


To produce a binding vote, I'd have to download each artifact and peek 
inside it. Given sheer number of files in the download location, it is 
practically impossible (short of mirroring the whole directory or 
creating .tar.bz2 by myself and downloading it). To simplify release 
checking process for all PMC members - can you create a single (or 
couple of - but not dozens!) download file? Thanks.


here you are: 
http://people.apache.org/builds/cocoon/cocoon-2.2RC1_staging.tar.gz

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

[test] Cocoon 2.2-RC1 others

[Reinhard Poetz]

The proposed release artifacts are available at
http://people.apache.org/builds/cocoon/.

Except for the archetypes the easiest way to test the artifacts is by adding a
cocoon-staging profile to your ~/.m2/settings.xml:

settings
  profiles
profile
  idcocoon-staging/id
repositories
  repository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
  /repository
/repositories
pluginRepositories
  pluginRepository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
  /pluginRepository
/pluginRepositories
/profile
  /profiles
/settings

Then change the version number of the artifacts that you use in your POMs
to the number of the proposed artifact and append -P cocoon-staging to all
your Maven commands, e.g.

mvn install -P cocoon-staging

  - o -

Because of a bug with the Maven archetyp feature, using profiles doesn't work 
with the Maven archetype goal. In order to test them you can either check them 
out from SVN


http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon-22-archetype-block/cocoon-22-archetype-block-1.0.0-RC1
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon-22-archetype-webapp/cocoon-22-archetype-webapp-1.0.0-RC1
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon-22-archetype-block-plain/cocoon-22-archetype-block-plain-1.0.0-RC1

or use the latest version from SVN and use the snapshot version numbers.

The commands to use the archetypes and explanations of what they are for can be
found at http://cocoon.zones.apache.org/daisy/cdocs/g2/g5/g1/1208.html.

  - o -

I also want to draw your attention to
http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1370.html which contains
references to 4 tutorials that help you to get started with Cocoon 2.2 and also
help to test the release artifacts. Again, make sure that you use the
cocoon-staging profile for all your commands as explained above. Otherwise the
referenced artifacts can't be found.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

[vote] Releasing from trunk: Cocoon 2.2-RC1 others

[Reinhard Poetz]

I prepared another series of releases from trunk, see the list of all 43
artifacts below. This time most of the modules are proposed to be released as 
RC1 (release candidate 1). The exceptions are


 - the forms and the ajax block which need more work related to their usage
   of the servlet service framework
 - the servlet-service framework which introduces some contracts
   that are under discussion
 - the Cocoon Maven 2 plugin which has a dependency on Commons JCI which
   hasn't been releases as final yet.

The release of release candidates means that we don't/can't change contracts 
without a deprecation period (e.g. deprecate something in 2.2.x, keep it in 
2.3.x and remove it in 2.4.x or 3.x).


You can find the staged versions of the modules (sources, binaries, javadocs +
checksums + gpg signatures) at http://people.apache.org/builds/cocoon/. SVN tags
of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/. I put my pgp key into 
the http://svn.apache.org/repos/asf/cocoon/trunk/commons/KEYS.

Find instructions about how you can test in a seperate mail. Report your
findings to that thread and use this one for voting only. Thanks!

This majority vote stays open for 72 hours.

Finally, here's the list of modules to be voted on:

Core artifacts (jar)

org.apache.cocoon:cocoon-pipeline-api:1.0.0-RC1
org.apache.cocoon:cocoon-util:1.0.0-RC1
org.apache.cocoon:cocoon-xml-api:1.0.0-RC1
org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1
org.apache.cocoon:cocoon-xml-impl:1.0.0-RC1
org.apache.cocoon:cocoon-pipeline-components:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-api:1.0.0-RC1
org.apache.cocoon:cocoon-thread-api:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-impl:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-components:1.0.0-RC1
org.apache.cocoon:cocoon-xml-resolver:1.0.0-RC1
org.apache.cocoon:cocoon-store-impl:1.0.0-RC1
org.apache.cocoon:cocoon-thread-impl:1.0.0-RC1
org.apache.cocoon:cocoon-core:2.2.0-RC1

Subproject: Servlet-Service (jar)
-
org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M2
org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M2

Blocks (jar)

org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC1
org.apache.cocoon:cocoon-template-impl:1.0.0-RC1
org.apache.cocoon:cocoon-apples-impl:1.0.0-RC1
org.apache.cocoon:cocoon-linkrewriter-impl:1.0.0-RC1
org.apache.cocoon:cocoon-auth-api:1.0.0-RC1
org.apache.cocoon:cocoon-auth-impl:1.0.0-RC1
org.apache.cocoon:cocoon-batik-impl:1.0.0-RC1
org.apache.cocoon:cocoon-captcha-impl:1.0.0-RC1
org.apache.cocoon:cocoon-databases-mocks:1.0.0-RC1
org.apache.cocoon:cocoon-databases-impl:1.0.0-RC1
org.apache.cocoon:cocoon-databases-hsqldb-client:1.0.0-RC1
org.apache.cocoon:cocoon-databases-hsqldb-server:1.0.0-RC1
org.apache.cocoon:cocoon-fop-impl:1.0.0-RC1
org.apache.cocoon:cocoon-html-impl:1.0.0-RC1
org.apache.cocoon:cocoon-mail-impl:1.0.0-RC1

org.apache.cocoon:cocoon-forms-impl:1.0.0-M3
org.apache.cocoon:cocoon-ajax-impl:1.0.0-M3

Maven plugins, archetypes and related (jar)
---
org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1
org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1
org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1

org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC1

POM artifacts
-
org.apache.cocoon.cocoon:4
org.apache.cocoon:cocoon-core-modules:4
org.apache.cocoon:cocoon-blocks-modules:4
org.apache.cocoon:cocoon-tools-modules:4

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 others

[Reinhard Poetz]

Reinhard Poetz wrote:
snip/
You can find the staged versions of the modules (sources, binaries, 
javadocs +
checksums + gpg signatures) at http://people.apache.org/builds/cocoon/. 
SVN tags

of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/. 

snip/

+1

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [test] Cocoon 2.2-RC1 others

[Reinhard Poetz]

Leszek Gawron wrote:

Reinhard Poetz wrote:


The proposed release artifacts are available at
http://people.apache.org/builds/cocoon/.


Why is there no release of cocoon spring configurator?


because there has already been a final release 1.0.0 of it and there haven't 
been any changes that would justify a 1.0.1.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Documentation of sitemap components

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

Hi,

I'm going to start writing documentation for servlet-service-fw stuff. 
At the beginning, I would like to provide documentation for all sitemap 
components it provides. I wonder if the idea of extracting documentation 
from javadoc is still relevant and mechanisms work. Do we have any 
documentation describing how to write documentation for sitemap 
components? (like tags that can be used)


http://cocoon.zones.apache.org/daisy/cdocs-site-main/g3/1273.html, and yes, it 
works.



Does this mechanism work for input modules?


not that I know.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: DispatcherServlet

[Reinhard Poetz]

Carsten Ziegeler wrote:

Grzegorz Kossakowski wrote:

Reinhard Poetz pisze:

Some suggestions

servlet:byId:com.mycompany.block1.servlet:/...
servlet:!com.mycompany.block1.servlet:/...
servlet:~com.mycompany.block1.servlet:/...
servlet:@com.mycompany.block1.servlet:/...

My favorite is the last one.


I really like last one. I would agree to have such a syntax.

Now, I don't want to spoil the contest here, but I would be great if we 
could choose a real url syntax which is parsable by the java.net.URL 
class. It is a) good to have valid urls 


what's wrong with e.g. servlet:@com.mycompany.block1.servlet:/...?

and b) a long time ago we had 
the idea of just using plain java.net.url implementations instead of the 
source resolver bean (and actually I'm currently working on this), so 
all sources which are now available through the source resolver will be 
available using the plain java api.

So, I think its worth considering this now :)


AFAIU, we have to register our own protocols. For that purpose we have to call 
http://javadoc.developintelligence.com/java/net/URL.html#setURLStreamHandlerFactory(java.net.URLStreamHandlerFactory) 
and according to the javadocs it can only be called once per JVM. Is it a good 
idea to rely on having to be the first?


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: DispatcherServlet

[Reinhard Poetz]

Carsten Ziegeler wrote:

Reinhard Poetz wrote:


what's wrong with e.g. servlet:@com.mycompany.block1.servlet:/...?
It's valid - but it looks strange to me; I would expect a user name 
after the '@'.


valid point ... then it seems that we have to continue the contest :-)



AFAIU, we have to register our own protocols. For that purpose we have 
to call 
http://javadoc.developintelligence.com/java/net/URL.html#setURLStreamHandlerFactory(java.net.URLStreamHandlerFactory) 
and according to the javadocs it can only be called once per JVM. Is 
it a good idea to rely on having to be the first?

:)

Yes, this is what the docs say - but there are solutions which work even 
if you're not first, e.g. equinox is doing this. So it's technically 
possible and it makes using custom protocols even easier.


I thought that there was some solution but wasn't sure whether we could use if 
for our own purpose.


I don't say that we should switch from source resolver to url and change 
everything we have; I just want to point out, that we should keep this 
in mind when creating urls.


ok.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Separate projects on JIRA

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

Reinhard Poetz pisze:


Could you make a more detailed proposal of what new projects you want 
to be created and send it to this list first?




No problem. I guess that the list will include most of the artifacts you 
are currently releasing. Could provide current list of them? I'm little 
bit lost because it was proposed several times.


BTW. What's the status of the release?


I'm finished with the creation of the artifacts and I'm currently testing them 
in my applications. If everything works as expected, I will start the vote 
tommorrow. There you will also find a list of all artifacts :-)


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2

[Reinhard Poetz]

I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. It should be 
useful to people that want to avoid Maven 2 as build system for their Cocoon 
based projects. The mail below, that I sent to the users list, explains in more 
detail how this prototyp is supposed to work.


Feedback would be much appreciated.



Reinhard Poetz wrote:

Carsten Ziegeler wrote:
If someone can document the steps (which we should do anyway) I can 
try and come up with the ant script.


I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. You 
can download it from 
http://people.apache.org/~reinhard/cocoon-22-bootstrap.zip.


It contains a build.xml that has two targets:

 - webapp
   Build a web application
 - run
   Starts the webapp using Jetty

Some words to the directory structure:

[root]
 +-src
 |  +-webapp The Cocoon web application
 |  +-block1 A Cocoon demo block
 +-lib   All required libraries and Cocoon blocks
 +-jetty Minimum files to run a Jetty 6.1.3 instance
 +-build.xml The Ant build script

The Ant build is only a starting point but it shows how things are 
supposed to work together. It works well for me but it misses two 
important things in order to be useful for others:


1) make it simple to add just another _own_ block
   (adding a third-party block only means copying the libs into ./lib)

2) create a properties file that configures all servlet services to use the
   src/block1/src/main/resources/COB-INF files as block contexts

   Having this feature allows working on the sources with support for
   hot reload.

I think the build script shouldn't do much more because if people prefer 
to use Ant, they have their own way of building/deploying their Java 
applications anyway. Using this build script as template for that 
purpose, should give them a enough ideas to integrate it into their own 
build and deployment architectures.


WDYT? Feedback, not only from Carsten, is much appreciated!


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2

[Reinhard Poetz]

Leszek Gawron wrote:

Hello,

Reinhard Poetz wrote:


I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. It 
should be useful to people that want to avoid Maven 2 as build system 
for their Cocoon based projects. The mail below, that I sent to the 
users list, explains in more detail how this prototyp is supposed to 
work.


Feedback would be much appreciated.


My first question is: why would people want to avoid maven as a build 
system if they get from us everything on the plate?: standard structure, 
archetypes. You do not have to know maven at all and be able to run 
cocoon app in under 10 minutes.


I agree with you but there are people with different opinions that I can 
understand to some point.


Once cocoon libs (especially plugins and archetypes) are uploaded on 
public maven repo where is no easier way to start.


right, but see above


Custom build will always get outdated some time which will bring confusion.


Agreed, maintaining a non-Maven based build is more difficult but the difference 
is that this build system was invented and developed by the developer himself 
and updating libraries can be done in the same way as usual. He doesn't have to 
learn something new. He also knows how to do all the other things like 
releasing, adding e.g. source generation tools, etc.


Additionally there are tools like Ivy or the Maven Ant tasks which can make your 
life a lot easier.


I don't want to say that we should focus on this non-Maven Cocoon 2.2 archetyp - 
at least I won't and probably won't do much more than the prototyp already does 
- but providing alternatives to our ours is a good thing IMO.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: DispatcherServlet

[Reinhard Poetz]

Daniel Fagerstrom wrote:
A syntax that distinguishes the two cases is a must. Having a special 
protocol (like the servlets: one) is one possibility, but maybe we could 
find some sub syntax for the servlet: protocol.


Some suggestions

servlet:byId:com.mycompany.block1.servlet:/...
servlet:!com.mycompany.block1.servlet:/...
servlet:~com.mycompany.block1.servlet:/...
servlet:@com.mycompany.block1.servlet:/...

My favorite is the last one.

Comments/other ideas?

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: DispatcherServlet

[Reinhard Poetz]

Daniel Fagerstrom wrote:
That works for your use case, but not for the original one that creates 
a page with links to all samples.


Thanks for your explanations!

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Separate projects on JIRA

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

David Blevins pisze:


On May 19, 2007, at 5:28 AM, Joerg Heinicke wrote:


On 19.05.2007 14:10, Grzegorz Kossakowski wrote:

I would like to know your opinions on having multiple project on 
JIRA for Cocoon.


If you have a look at [1] you'll see that Jira knows the concept of 
category. And like Avalon, Geronimo or whatever have multiple 
projects in their category it should be no problem to have the same 
for Cocoon.


Not sure what kind of setup you guys have going on, but for stuff I 
work with seems like for every pool of version numbers you more or 
less have to have a Jira project.  At least that's why Geronimo has 
those projects -- each of those projects follows its own stream of 
version numbers.


I think we are going to have something similar. Blocks/modules that are 
released more frequently should have its own project on JIRA because 
it's impossible (or at least inconvenient) 


I'd even say unwanted

to keep all version ranges in 
sync.


I see that no one objects the need for separate projects. Do I have to 
start a formal vote on it before asking INFRA folks for anything?


Could you make a more detailed proposal of what new projects you want to be 
created and send it to this list first?


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Releasing 2.2-RC1

[Reinhard Poetz]

Reinhard Poetz wrote:
Please commit. Except from the archtetpyes and the cocoon-maven-plugin, 
I created all release artifacts.


I created all release artifacts except the forms and the ajax block. The missing 
thing is a release of the xreporter-expression and xreporter-grouping libraries 
to the central Maven repository. Then we can have a vote.


Any volunteers for this task?

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Releasing 2.2-RC1

[Reinhard Poetz]

Marc Portier wrote:



Reinhard Poetz wrote:

Reinhard Poetz wrote:
Please commit. Except from the archtetpyes and the 
cocoon-maven-plugin, I created all release artifacts.


I created all release artifacts except the forms and the ajax block. 
The missing thing is a release of the xreporter-expression and 
xreporter-grouping libraries to the central Maven repository. Then we 
can have a vote.


Any volunteers for this task?



to be clear on what needs to be done:

1. xreporter-svn checkout of revision 684


don't know which revision Jorg used to create 1.3-SNAPSHOT (see 
http://people.apache.org/repo/m1-snapshot-repository/xreporter/jars/)



2. build of xreporter-expression jar (oh and grouping jar?)


I can't tell whether we really need grouping or not but it is listed as 
dependency of cocoon-forms-impl.


3. decide on some 'version' number for these (I'm proposing 1.2.1.1 
since no other xreporter artifacts will be released at this time)


1.2.1.1 sounds good to me

4. finally go through 
http://maven.apache.org/guides/mini/guide-ibiblio-upload.html

to get the jar uploaded at repo1

which means
  - making a pom (group xreporter, artifact xreporter-expression, no 
dependencies)

  - creating a bundle-jar with pom and renamed jar
  - putting JIRA request up at 
http://jira.codehaus.org/secure/CreateIssue.jspa?pid=10367issuetype=3


sounds good to me.

Thanks Marc!

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: 2.2 deploying as webapp

[Reinhard Poetz]

Marc Portier wrote:

I get http://localhost:/block1/ and http://localhost:/block2/ 
both triggering the block1 sitemap!



anybody a clue where I should be looking?


If it's not a bug the only reason could be that you copied your servlet-service 
configuration from block1 to block2 and forgot to correct the blockcontext path.



regards
-marc=
PS: while searching I happened across: 
http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g5/1263.html

this looks like it's not completely up to date, or is it?


right, fixed now.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: 2.2 deploying as webapp

[Reinhard Poetz]

Marc Portier wrote:

Reinhard Poetz wrote:

Marc Portier wrote:

I get http://localhost:/block1/ and http://localhost:/block2/ 
both triggering the block1 sitemap!



anybody a clue where I should be looking?


If it's not a bug the only reason could be that you copied your 
servlet-service configuration from block1 to block2 and forgot to 
correct the blockcontext path.




aargh, exactly that!

hm, this almost sounds like you had that happen as well once in a while :-)


for that reason I always use the archetype

hm, this kinda puts on the table why the blocks themselves are stating 
this (and the mount-path)


what is this block-context-path anyway? sounds like a directory where 
the COB-INF is unpacked


yep

, couldn't that be implied from the block's 
jar-name?


We already put the block name as property into the MANIFEST.MF of a block (see 
the jar plugin which is configured in the block's pom). The problem is that we 
have to find a way to tell the servlet service bean, where all the resources 
that belong to the servlet service, can be found.


anyway, at least some advice or naming conventions should be made 
probably? (same for the bean/@ids in fact)


the configuration of a servlet service consists of at least three properties:

 - bean name
 - mount path
 - block context path

For now I don't have an idea how we could introduce a naming convention here, 
which doesn't confuse more than it helps.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: svn commit: r540144 - in /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main: java/org/apache/cocoon/spring/configurator/impl/ resources/META-INF/ resources/org/apache/coco

[Reinhard Poetz]

[EMAIL PROTECTED] wrote:

Author: giacomo
Date: Mon May 21 06:52:41 2007
New Revision: 540144

URL: http://svn.apache.org/viewvc?view=revrev=540144
Log:
enhance the bean-map for service servlet use case

Added:

cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/resources/org/apache/cocoon/spring/configurator/schema/cocoon-configurator-1.0.2.xsd
   (with props)


Since we haven't released 1.0.1 so far, it's not necessary to increment the 
version number.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Trunk is broken

[Reinhard Poetz]

Felix Knecht wrote:

Reinhard Poetz schrieb:

However, I haven't incremented the versions of cocoon,
cocoon-core-modules, cocoon-tools and cocoon-blocks. I will do this
tommorrow or on Friday.



It seems to be broken again.

I don't know the ongoing with the RC1 release Reinhard is doing - therefore I 
don't commit following patch which lets me
compile at least again:


Please commit. Except from the archtetpyes and the cocoon-maven-plugin, I 
created all release artifacts.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: More problems with implementing servlet services

[Reinhard Poetz]

Daniel Fagerstrom wrote:

Reinhard Poetz skrev:

Daniel Fagerstrom wrote:

...
I think that continuing this discussion doesn't solve the problem. 
Maybe we should start a poll on dev@, how others (except from Jörg, 
Alex, Grek, Vadim you and me) think about it because I guess that most 
of them probably don't follow this long thread anymore.


WDYT?


I think that what we are facing is that the Cocoon architecture, at 
last, start to embrace input that is more sophisticated than mere 
request parameters. We are getting to a point where input is becoming a 
first class citizen in the same way as output has been from the start.


This takes some time to get used to though and some work for finding the 
right concepts for. So, no IMO it is not the time for a vote nor is it a 
kind of subject that is suitable for voting.


That was the reason why I've avoided using the word vote. Probably the word 
poll wasn't a much better alternative either. And yes, you are right, we can't 
vote on something and just because the majority agrees, it doesn't mean that it 
becomes right. The funny thing in this particular case is that maybe both 
proposed solutions are not the best.


I would be interested in more opinions because I think that only a few people 
are following this thread anymore.
It would be great if somebody could summarize the current discussion and start a 
new thread or even an RT. I won't have the time of doing it myself - at least 
not in a foreseeable future - but I'd happily discuss it.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: DispatcherServlet

[Reinhard Poetz]

Daniel Fagerstrom wrote:

Reinhard Poetz skrev:

Daniel Fagerstrom wrote:

...
But there are important use cases for run time discovery of servlet 
services as well. 


definitly. For the use cases that *I* have, a generator will be good 
enough - I don't think that I need a source for them:


map:generate type=servlets src=data/myconfig.xml/

This could return something like this:

servlets
  service-A
config.../config
  /service-
  service-B
config.../config
  /service-B
/servlets

What are the usecases for implementing a servlets: protocol at all? 
(Maybe I'm overlooking something important here ...)


In the above output from your generator, you need to reference the 
actual resources of the listed servlet services. And to be able to do 
that you need an URI. 


The URI is data/myconfig.xml, resolved against all available servlet services.


And right now we have not any protocol that is suitable for that.


AFAIU we only have to create ServletConnection objects. Currently the 
constructor expects the connection name as parameter but it shouldn't be 
difficult to create those objects by implementing a second constructor that uses 
the bean id or a bean reference.


For the use case we are discussing, the assumption is that the caller of 
the servlets generator is not connected to all the servlet services. 
Thus we cannot use the servlet: protocol that by design assumes an 
explicit named connection.


So we need a protocol that allows (webapp) global servlet service URIs 
anyway. And then we could as well make it listable as a source is usable 
in more contexts than a generator.


ok. What I still don't understand is, why we want to make the bean id being part 
of this URI at all? Or do I misinterpret your discussion with Grek here?


Isn't having an URI

servlets:/data/myconfig.xml

good enough to configure a listable source? The getChildren() method of the 
created source will return all child sources that return true on 
childSource().exists().


I don't see the need to lookup not configured servlet services by their name. 
The only use case I can think of is optional servlet services. To solve it, I'd 
rather introduce an optional parameter for servlet service configurations. 
However, I'm not convinced that we need this feature at all if we can resolve 
servlets:/data/myconfig.xml URIs which would return servlet service sources that 
are unknow in the context of the current servlet service.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: DispatcherServlet

[Reinhard Poetz]

Reinhard Poetz wrote:

The getChildren() method of 
the created source will return all child sources that return true on 
childSource().exists().


Forget this statement. After reading it again, I see that it is non-sense :-)
The getChildren() method of the source will return all child sources and it's 
the concern of the user to call childSource().exists().


I also think that I understand know, why you'd need URIs containing the bean id 
because source.getChildren() returns a collection of sources and each of this 
sources has a getURI() method that has to be able to uniquly identify a child 
source.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: DispatcherServlet

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

I think it's time to support Reinhard :-)
I agree with his opinion that servlets: source is not needed at the 
moment and generator will be sufficient. 


It wasn't a general statement but rather, that *I* don't have the use case right 
now. This doesn't mean that they don't exist.
As Daniel said, a source could be used in more contexts than a generator, e.g. 
you could use it from within your Java code to access all servlets.


But I agree with you that the implementation of a generator is much simpler ;-)

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: DispatcherServlet

[Reinhard Poetz]

Grzegorz Kossakowski wrote:

Reinhard Poetz pisze:

Daniel Fagerstrom wrote:

Reinhard Poetz skrev:
...

In the above output from your generator, you need to reference the 
actual resources of the listed servlet services. And to be able to do 
that you need an URI. 


The URI is data/myconfig.xml, resolved against all available servlet 
services.



And right now we have not any protocol that is suitable for that.


AFAIU we only have to create ServletConnection objects. Currently the 
constructor expects the connection name as parameter but it shouldn't 
be difficult to create those objects by implementing a second 
constructor that uses the bean id or a bean reference.


For the use case we are discussing, the assumption is that the caller 
of the servlets generator is not connected to all the servlet 
services. Thus we cannot use the servlet: protocol that by design 
assumes an explicit named connection.


So we need a protocol that allows (webapp) global servlet service 
URIs anyway. And then we could as well make it listable as a source 
is usable in more contexts than a generator.


ok. What I still don't understand is, why we want to make the bean id 
being part of this URI at all? Or do I misinterpret your discussion 
with Grek here?


I guess that main reason is that we need unique URIs.


Isn't having an URI

servlets:/data/myconfig.xml

good enough to configure a listable source? The getChildren() method 
of the created source will return all child sources that return true 
on childSource().exists().


What would servlets: source return if getInputStream() was called for 
servlets:/data/myconfig.xml URI?


probably an exception, like the FileSource which is also a TraversableSource or 
an aggregated view.


I don't see the need to lookup not configured servlet services by 
their name. The only use case I can think of is optional servlet 
services. To solve it, I'd rather introduce an optional parameter 
for servlet service configurations. However, I'm not convinced that we 
need this feature at all if we can resolve servlets:/data/myconfig.xml 
URIs which would return servlet service sources that are unknow in the 
context of the current servlet service.


I can't parse the above. What does mean to lookup not configured 
servlet services by their name? How they can be not configured?


I mean a servlet service that is not configured as an entry of 
servlet:connections of the servlet service bean definition.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: More problems with implementing servlet services

[Reinhard Poetz]

Joerg Heinicke wrote:

On 19.05.2007 14:28, Grzegorz Kossakowski wrote:

But a service generator without any post data makes absolutely sense 
since it might really be optional to post anything. And I find it 
quite strange to write


That's not true. If you don't post a data it's not the service any 
more but you can call it that way:

map:generate src=servlet:test2:/extract-html/

Using normal FileGenerator.


Ah, ok. I think I already read this somewhere in this thread.

You can argue that it's strange that if service is called we put it as 
parameter and if it's casual GET it is put in the src attribute. I'd 
disagree then because GET and POST are so much different that even 
different sitemap syntax makes sense.


One more reason to always put the service URL into the src attribute as 
you don't need to discuss and differentiate between GET and POST. The 
sitemap was always GET/POST-unaware. Now you would need to change the 
nature of your generator by changing its type instead of just removing 
one parameter.


What about enhancing the file generator with the ServletServiceGenerator 
features?

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: xreporter expression library release

[Reinhard Poetz]

Jorg Heymans wrote:

Alexander Klimetschek wrote:

Yup, works now. Is it possible that you provide a release version of 
that jar? Doesn't have to be the full 1.3 release if it's not finished 
yet, maybe a 1.3-alpha, but I'd be glad to have no maven snapshots in 
all the transitive dependencies as I am working on a company-internal 
release of Cocoon 2.2-RC1.


It would be better if the xreporter project team were the driving 
release manager for this. The official approach would be to ping their 
mailinglist, but maybe Marc or Bruno can give us a quick update on [1] 
here ?


Any showstopper? Without a release of the two xreporter libraries, we can't 
release cocoon-forms-impl-1.0.0-M3.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Cocoon 2.2 status for a new project

[Reinhard Poetz]

Olivier Billard wrote:

Hi all,

I plan to use Cocoon for a project on the starting blocks.
But I need to know if Cocoon 2.2 is ready for a new (big, critical) 
project (stable enough in terms of APIs for example), to make the good 
choice :).

Recently, some work has been done on the CForms, for example.

Can someone please give me a status on this branch ?


As Grek pointed out, trunk can be considered as stable, except the recently 
added servlet-services (aka postable sources) which are currently under 
development. If there aren't any unforeseeable showstoppers we can release 
Cocoon 2.2RC1 + the most important blocks: ajax, apples, auth, batik, catpcha, 
databases, flowscript, fop, forms, html, mail, template.
The most prominent missing blocks are javaflow, portal, lucene and serializers. 
If you don't need them, I'd say use 2.2RC1.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: DispatcherServlet

[Reinhard Poetz]

Daniel Fagerstrom wrote:
I think we make the servlet: protocol unnecessarily complicated if we 
try to overload it with webapp global interpretations as well.


agreed

And as I asked before, how does the URI parser given e.g. 
servlet:foo/bar know is foo is a servlet service local id or a 
Spring bean id?


no chance to distinguish between them, IMO.

snip/
But there are important use cases for run time discovery of servlet 
services as well. 


definitly. For the use cases that *I* have, a generator will be good enough - I 
don't think that I need a source for them:


map:generate type=servlets src=data/myconfig.xml/

This could return something like this:

servlets
  service-A
config.../config
  /service-
  service-B
config.../config
  /service-B
/servlets

What are the usecases for implementing a servlets: protocol at all? (Maybe I'm 
overlooking something important here ...)


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: More problems with implementing servlet services

[Reinhard Poetz]

Daniel Fagerstrom wrote:
The mycsv example above was a typical use case for how the servlet 
service generator is intended to be used. It replaces the virtual 
sitemap components that we had an experimental implementation of before.


If we were talking about a virtual generator, I'd agree with you. But, after 
introducing the concept of sitemap services which are, from a users 
perspective like a web service, they become the source in my opinion.


And in the example above I would say that the {1}.csv input file is 
from the users POV the important thing. That the transformation from the 
csv input file to the wanted XML format is done with a servlet service 
that happen to be at some particular URI instead of using some custom 
csv generator, that is an implementation detail.


And here we disagree ;-)

The CSV file is important for the called service but for the calling pipeline, 
it is just some data that is passed. The servlet service generator parses the 
output stream returned by the called servlet and not the CVS file.


  - o -

I think that continuing this discussion doesn't solve the problem. Maybe we 
should start a poll on dev@, how others (except from Jörg, Alex, Grek, Vadim you 
and me) think about it because I guess that most of them probably don't follow 
this long thread anymore.


WDYT?

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: DispatcherServlet

[Reinhard Poetz]

Giacomo Pati wrote:

I've had discussions with Felix (which is sitting next to me) about the issue 
that the mount path in
each block is carved in stone in the SitemapServlet bean definition (I suppose 
it is not
overwritable by Springs PropertyOverwrite mechanism we use as it is an 
attribute of our own servlet
Spring extension thingy).


You can override it by

[block-servlet-bean-id]/contextPath

See the output of the rcl goal 
(./target/rcl/webapp/WEB-INF/cocoon/spring/rcl.properties) of the Cocoon Maven 
plugin which already makes use of this configuration feature.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Version of Cocoon artifacts in our root pom for a release

[Reinhard Poetz]

Can anybody tell me what the right version for Cocoon artifacts in our 
*released* root pom is:


 a) the snapshot version
I don't think that's a good idea because IIUC, if a user adds a dependency
on cocoon-core which has many transitive dependencies, he would have to
set all versions in his own pom so that the versions don't get overriden by
a snapshot version.

 b) the release version
How do I know which version to set in advance? Or am I supposed to release
the root pom for every module I want to release? That sounds too silly to be
true, doesn't it?

 c) remove Cocoon internal dependencies from our root pom for the release?
The best option I can think of but I'm not sure ...

 d) ???

Any ideas/opinions?

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: Samples styling

[Reinhard Poetz]

Felix Knecht wrote:

Grzegorz Kossakowski schrieb:

As I previously said, I'm not sure if we need this either, so I won't
push you to use services.


I'm not feeling pushed ;-) But I think we should show in the samples
what's the common way of doing it - otherwise only some specialists will
use this (powerfull) feature and a common developer won't get notice of
it. Therefore I'm going to use it in the next samples I move to
servler-service.


+1

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Trunk is broken

[Reinhard Poetz]

Karel Vervaeke wrote:

mvn -Pallblocks install -Dtest=qsdf output: see below

My solution was to change blocks/pom.xml: see below
(This file probably got overlooked during a version-upgrade)

If I should make a bugzilla issue + attach the patch,
please say so.


I'm aware about it because I'm releasing RC1 and haven't fixed everything by 
now.

Trunk should build again in an hour or two.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Trunk is broken

[Reinhard Poetz]

Reinhard Poetz wrote:

Trunk should build again in an hour or two.


The build runs through now again, at least for me. I've tested with rm -rf 
~/.m2/repository/org/apache/cocoon.


However, I haven't incremented the versions of cocoon, cocoon-core-modules, 
cocoon-tools and cocoon-blocks. I will do this tommorrow or on Friday.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Releasing Cocoon 2.2-RC1

[Reinhard Poetz]

Reinhard Poetz wrote:

Reinhard Poetz wrote:


There was some discussion off-list when the next series of C22 modules 
will happen. I plan to do the release work next week but have to spend 
the next two days on fixing things here and there and to get the 2.2 
documentation online because I don't want to release anything that we 
label release candidate without having some minimal documentation at 
least.


I will keep you posted about my progress on Thursday of Friday.


Sorry, I can't prepare the release this week. Maybe this isn't too bad 
because we have time to work on Cocoon next week (ApacheCon) and this 
also gives us some time to polish the servlet-service-impl and forms.


My current plan is to work on the release starting with May, 7th.


I will start with the release work tommorrow. Basically I will set the version 
of _all_  artifacts to RC1, except for the Cocoon Maven plugin because it needs 
more tests and has a dependency (commons-jci) that still isn't available on the 
central Maven repository.


I'm not sure about cocoon-forms and cocoon-ajax. I'd prefer releasing another 
milestone release because we haven't got much feedback yet.


WDYT? Any showstoppers?

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Upgrading Daisy

[Reinhard Poetz]

Marc Portier wrote:
we need to decide on a namespace though, 'cdoc' for 'cocoon docs' is my 
naive first proposal.


fine for me.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Upgrading Daisy

[Reinhard Poetz]

Marc Portier wrote:

one less argument not to update


I haven't had enough time to have a deeper look on what has to be done to 
upgrade the Daisy plugin and the Daisy Java adapter 
(http://svn.cocoondev.org/repos/daisy/contrib/daisy-client-apps/trunk/daisy-java-adapter/). 
I'm sorry.


My priorities now are getting the RC1 release done and publish our new website. 
Then the upgrade of the two modules will follow. If anyone else wants the 
upgrade being done faster than this, I will help as much as I can but I'm 
against an upgrade without having both modules because we wouldn't be able to 
publish our docs anymore.


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

[docs] Snapshot available

[Reinhard Poetz]

After Helma's work on the skin, I have published a snapshot of our docs at 
http://cocoon.zones.apache.org/dev-docs/.


As you can see from http://cocoon.zones.apache.org/daisy/cdocs/g4/1346.html, 
most of the work on the docs building infrastructure has been done.


The next step is bringing the content of the main site into a good shape.

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [docs] Snapshot available

[Reinhard Poetz]

Marc Portier wrote:



Reinhard Poetz wrote:


After Helma's work on the skin, I have published a snapshot of our 
docs at http://cocoon.zones.apache.org/dev-docs/.




jummy

I did spot a small glitch while clicking around though:

at: http://cocoon.zones.apache.org/dev-docs/2.2/core-modules/
the links to the 'projects' are coded like this

 ul class=projectList
   lia href=../2.2/core-modules/Cocoon Core/a/li
   lia href=../2.2/blocks/Cocoon Blocks/a/li
   lia href=../subprojects/Subprojects/a/li
   lia href=../2.2/maven-plugins/Maven Plugins/a/li
 /ul

I have the impression they are missing an extra ../ to pop up an 
additional level?


Thanks, fixed now. I rebuilt the site.

As you can see from 
http://cocoon.zones.apache.org/daisy/cdocs/g4/1346.html, most of the 
work on the docs building infrastructure has been done.


The next step is bringing the content of the main site into a good shape.



is there a  detailed list of what needs to be done?


here you are: http://cocoon.zones.apache.org/daisy/cdocs/g4/1346.html

Some way to centrally dispatch and follow up so people can step in and 
help complete...

(maybe some smart status-field with ditto document query could help?)


Is that list good/detailed enough?

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: More problems with implementing servlet services

[Reinhard Poetz]

Daniel Fagerstrom wrote:

Reinhard Poetz skrev:

Daniel Fagerstrom wrote:
hmm, the src attribute of generators desribes, what is feed into 
the component. In the case of a servlet service generator, the 
output stream of a servlet is used as stream input.

Rather something that is transformed to SAX output.
The data parameter defines the content that is passed to the 
servlet service. IMO that's not the starting point of the generator.

IMO it is ;)

The normal case:

Source ==[octet stream]== Generator ==[SAX]== ...

Servlet service generator as I see it:

Source ==[octet stream]== Generator ==[SAX]== ...
 |  ^
 v  |
ServletService

As you can see, the connection to the servlet service is something 
that differ from the ordinary generator usage, and because of that it 
is natural to put it in a parameter.


:-) yes, technically that's of course right but from a user's POV the 
generator uses a servlet service as source.
I don't see how a user would gain anything in having a faulty conceptual 
view of what the component does or why we should add to the potential 
confusion by having a non consistent use of the source attribute.


The src attribute is used for reading from a source in all other cases, 
using it for posting would be really confusing from a user POV ;)


Actually the code uses the input stream of the called pipeline:

generate():
SourceUtil.parse(saxParser, this.servletSource, super.xmlConsumer);

setup():
Source inputSource;
try {
  try {
servletSource = (PostableSource)resolver.resolveURI(service);
 
  } catch (ClassCastException e) {
throw new ProcessingException(Resolved ' + service + ' to source that
  }
inputSource = super.resolver.resolveURI(src);

} catch (SourceException se) {
throw SourceUtil.handle(Error during resolving of ' + src + '., se);
}


IOUtils.copy(inputSource.getInputStream(), servletSource.getOutputStream());

The data is the payload added to the request and only the _indirect_ 
source for the calling pipeline.
This is really a technical POV, and no, there is nothing _indirect_ in 
this particular use of the src attribute.


By indirect I mean that in your example, the src attribute of the servlet 
service generator specifies not its own source but the source of the generator 
of the called pipeline. See the last statement.


I think the problem here is that we have two sources and depending on the 
context, one is the main source. But if it's only me having this view on that, 
I won't argue for it any more.


Any other opinions?

--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: More problems with implementing servlet services

[Reinhard Poetz]

Grzegorz Kossakowski wrote:
In this case content of test.html is POSTed to the service and is 
available to it by service-consumer: source. Generator in service 
pipeline reads data from service-consumer: so this effectively means 
that it reads test.html file, parsers it and returns SSAX stream 
representing html content back to the calling pipeline.


Service generator and its behavior fits current meaning of a generator 
component. Currently, we call a component generator if it takes some 
input data (may it be non-XML) and emits SAX events based on provided 
data, right?
Now, with service generator it means that generator redirects (posts) 
incoming raw data to the service and expects SAX events as output that 
it will pass down to the pipeline.


I hope this helps.



What about reversing the logic: Instead of

 map:match pattern=test5
   map:generate type=servletService src=test.html
 map:parameter name=service value=servlet:test2:/extract-html/
   /map:generate
   map:serialize type=xml/
 /map:match

we could use

map:match pattern=test5
  map:generate type=servletService src=servlet:test2:/extract-html
map:parameter name=data value=test.html/
  /map:generate
  map:serialize type=xml/
/map:match

It doesn't make that much difference for generators, but would save one line 
each for serializers and transformers.


WDYT?


--
Reinhard Pötz   Independent Consultant, Trainer  (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc