date:20060517

Giacomo Pati wrote:

 
 No!?! I probably missed something.
 
Most blocks add their component configs to the cocoon.roles files during
build. As you originally build Cocoon without the template block, these
configs are now missing in the cocoon.jar. So all you have to do is
rebuild Cocoon with the template block enabled and upload that jar.
(This clearly shows that this way of configuration is a problem which we
gladly solved in 2.2).

Carsten
-- 
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [2.2] Configuration issues

Carsten Ziegeler skrev:

I'm currently wondering what the best way to configure 2.2 from a user
perspective is. We now have includes for xconfs and property
replacements which is great.
Now, each block comes with its own configuration files: all of them are
stored in the jar and on deployment some of these files are extracted:
so in the end there are roles files in the jar, xconf and property files
on the WEB-INF folder.
A user should never touch/change these files - so only way to customize
the settings is through properties. This requires that each and every
user configurable value must be replaced with a property! Now while this
approach is fine it has at least two problems:
1. A huge number of properties which sooner or later will create a mess.

Requiring the user of the block to define every property is far to
inconvenient and error prone. A much better model is to have default
values in the configuration file in the block and make it possible for
the block user to optionally override the default value with own
properties. This is the way configuration is handled in OSGi with a
declarative service configuration file that gives the default and a
configuration service that can override the default. Spring has some
similar mechanism with the PropertyOverrideConfigurer
http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/beans/factory/config/PropertyOverrideConfigurer.html.

2. This works only as long as the user wants to use the same
implementation for a component. Switching to an own implementation with
an own configuration is not possible.

Any idea on how to solve this?
Here the IMO best and most natural solution is to have different blocks
for different implementations. Say we have two different components that
implements the XsltProcessor inteface, the Xalan and the Saxon
implementation. Then if you have a Xalan block with its own embedded
configuration and a Saxon block with its own embedded configuration. If
you want to use the Xalan implementation you deploy the Xalan block and
if you want the Saxon implementation you deply the Saxon block.

The result of this thinking is that you have typically smaller and more
focused blocks, that contain components that are used togerther.

WDYT?

/Daniel

[forms] Repeater.moveRow() method

2006-05-17 Thread Bruno Dumon

Hi,

While using the repeater.moveRow(from, to) method, there were two things
about it which I found illogical:

* to move a row to the last position, say x, one needs to
specify a to-index of x + 1

* if the to-index is larger then from-index, the to-index is
lowered by one. I don't understand why, since if one specifies
that a row should be moved to e.g. position 5, to me it seems it
should really go to position 5, and not position 4.

Maybe someone can shine some light on this, but in any case I'm planning
on adding a second moveRow method which has the (IMO) normal
behaviour. Changing the behaviour of the current method would be
backwards incompatible.

Bruno.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

[jira] Subscription: COCOON-open-with-patch

2006-05-17 Thread jira

Issue Subscription
Filter: COCOON-open-with-patch (93 issues)
Subscriber: cocoon


Key Summary
COCOON-1848 [PATCH] using setRequired in Ajax mode does not generate bu:replace
http://issues.apache.org/jira/browse/COCOON-1848
COCOON-1847 [PATCH] AJAX errors' popup window not resizable/scrollable
http://issues.apache.org/jira/browse/COCOON-1847
COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the 
rigth time with IE
http://issues.apache.org/jira/browse/COCOON-1846
COCOON-1843 LDAPTransformer: add-entry tag doesn't work
http://issues.apache.org/jira/browse/COCOON-1843
COCOON-1842 LDAPTransformer: ClassCastException with Binary fields
http://issues.apache.org/jira/browse/COCOON-1842
COCOON-1840 [PATCH] XMLFileModule file-specific configuration ignored
http://issues.apache.org/jira/browse/COCOON-1840
COCOON-1839 exception2html.xslt script / causes IE display problem
http://issues.apache.org/jira/browse/COCOON-1839
COCOON-1838 Always use 3-digit version number
http://issues.apache.org/jira/browse/COCOON-1838
COCOON-1825 Ajax errror when an active state widget become invisible state 
widget
http://issues.apache.org/jira/browse/COCOON-1825
COCOON-1811 [PATCH] Flow Script: Allow dynamic loading of JavaScript objects 
even when scope is locked
http://issues.apache.org/jira/browse/COCOON-1811
COCOON-1810 [PATCH] JMSEventMessageListener does not work
http://issues.apache.org/jira/browse/COCOON-1810
COCOON-1794 [PATCH] Propagation of namespaces to a repeaters child bindings and 
implementation of a move-node binding
http://issues.apache.org/jira/browse/COCOON-1794
COCOON-1776 [PATCH]Reload Bookmarks on bookmark file validity
http://issues.apache.org/jira/browse/COCOON-1776
COCOON-1774 Fine Tuning Ajax Handling in CForms
http://issues.apache.org/jira/browse/COCOON-1774
COCOON-1744 NullPointerException in template block
http://issues.apache.org/jira/browse/COCOON-1744
COCOON-1741 [PATCH] Output widget does not initialize from fd:initial-value
http://issues.apache.org/jira/browse/COCOON-1741
COCOON-1738 double-listbox problem in repeaters
http://issues.apache.org/jira/browse/COCOON-1738
COCOON-1732 Ajax and IE empty textarea bugfix
http://issues.apache.org/jira/browse/COCOON-1732
COCOON-1726 Implementation of Source that supports conditional GETs
http://issues.apache.org/jira/browse/COCOON-1726
COCOON-1717 Use custom cache keys for caching uri coplets using input modules.
http://issues.apache.org/jira/browse/COCOON-1717
COCOON-1706 Allow TeeTransformer to run a system command for debugging purposes
http://issues.apache.org/jira/browse/COCOON-1706
COCOON-1703 A patch for caching fonts (fixes GDI issues), vertical text 
orientation, color code fix, prefered unit for margins and measure unit 
converter
http://issues.apache.org/jira/browse/COCOON-1703
COCOON-1697 Allow request parameters to be used in for (var k in h) kind of 
Javascript Loops
http://issues.apache.org/jira/browse/COCOON-1697
COCOON-1694 Error decommissioning component: 
org.apache.cocoon.components.store.impl.EHDefaultStore
http://issues.apache.org/jira/browse/COCOON-1694
COCOON-1692 [PATCH] Tree widget not handling on-selection-change events 
correctly.
http://issues.apache.org/jira/browse/COCOON-1692
COCOON-1686 [PATCH] COCOON-1671 Form not binding when prefix in binding 
definition is unequal to that in the instance data for the same namespace.
http://issues.apache.org/jira/browse/COCOON-1686
COCOON-1648 I18nTransformer add support for ISO8601
http://issues.apache.org/jira/browse/COCOON-1648
COCOON-1622 [PATCH] SendMailTransformer and HTML body
http://issues.apache.org/jira/browse/COCOON-1622
COCOON-1618 [PATCH] SoapGenerator/Serializer for Axis Block
http://issues.apache.org/jira/browse/COCOON-1618
COCOON-1611 [PATCH] Add additonal constructor to FormInstance.java to be able 
to pass a locale
http://issues.apache.org/jira/browse/COCOON-1611
COCOON-1606 [BUG+PATCH] FormattingDecimalConvertor.java does not parse in 
BigDecimal mode
http://issues.apache.org/jira/browse/COCOON-1606
COCOON-1603 [PATCH] handling of alternatives in MailTransformer
http://issues.apache.org/jira/browse/COCOON-1603
COCOON-1573 Improvement SetAttributeJXPathBinding and Contribution 
SetNodeValueJXPathBinding
http://issues.apache.org/jira/browse/COCOON-1573
COCOON-1557 [PATCH] Change access to AbstractContinuable.getContext to protected
http://issues.apache.org/jira/browse/COCOON-1557
COCOON-1556 [PATCH] Add a JXPathConvertor for conversion betwean beans and 
Strings
http://issues.apache.org/jira/browse/COCOON-1556
COCOON-1535 [PATCH]

[jira] Commented: (COCOON-1838) Always use 3-digit version number

2006-05-17 Thread Reinhard Poetz (JIRA)

[ 
http://issues.apache.org/jira/browse/COCOON-1838?page=comments#action_12412135 
] 

Reinhard Poetz commented on COCOON-1838:


If a version or a groupId is missing, the values are taken from the parent 
artifact. Taking this into consideration, do you know of any other errors?

 Always use 3-digit version number
 -

  Key: COCOON-1838
  URL: http://issues.apache.org/jira/browse/COCOON-1838
  Project: Cocoon
 Type: Improvement

   Components: - Build System: Maven
 Versions: 2.2-dev (Current SVN)
 Reporter: Ben Pope
 Priority: Trivial
  Attachments: version.patch

 Continuing the theme of Carsten in commit 394739
 (This sits on top of my other patch JIRA 1837, so 1 or two files might fail 
 if that one is not commited)
 License granted to ASF.
 The patch is essentially a search and replace of 
 version1-SNAPSHOT/version and version1.0-SNAPSHOT/version to 
 version1.0.0-SNAPSHOT/version

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1838) Always use 3-digit version number

2006-05-17 Thread Ben Pope (JIRA)

[ 
http://issues.apache.org/jira/browse/COCOON-1838?page=comments#action_12412136 
] 

Ben Pope commented on COCOON-1838:
--

A while go I had a look at all the pom files, but I wasn't entirely sure how 
they worked with respect to the missing version numbers, you've just clarified 
that.

I have to say that I didn't see any 1 digit version numbers that were not just 
listing other modules, so I think it's fair to close this issue on that basis.

I do recall seeing some 2 digit version numbers, so it migth be worth checking 
for those and fixing them.

 Always use 3-digit version number
 -

  Key: COCOON-1838
  URL: http://issues.apache.org/jira/browse/COCOON-1838
  Project: Cocoon
 Type: Improvement

   Components: - Build System: Maven
 Versions: 2.2-dev (Current SVN)
 Reporter: Ben Pope
 Priority: Trivial
  Attachments: version.patch

 Continuing the theme of Carsten in commit 394739
 (This sits on top of my other patch JIRA 1837, so 1 or two files might fail 
 if that one is not commited)
 License granted to ASF.
 The patch is essentially a search and replace of 
 version1-SNAPSHOT/version and version1.0-SNAPSHOT/version to 
 version1.0.0-SNAPSHOT/version

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

RAD with Cocoon 2.2



Maven brings a lot of advantages to standardize the development process but also 
makes development of applications more difficult as you spread your applications 
over different artifacts.


In the light of this I think we should revert our removal of the per-sitemap 
classloading 
(http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=114150323011155w=2). As the 
removal was part of a refactoring of the sitemap engine, could sombody give me a 
description of what needs to be done?


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


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

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






___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: RAD with Cocoon 2.2

2006-05-17 Thread Sylvain Wallez

Reinhard Poetz wrote:

 Maven brings a lot of advantages to standardize the development
 process but also makes development of applications more difficult as
 you spread your applications over different artifacts.

 In the light of this I think we should revert our removal of the
 per-sitemap classloading
 (http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=114150323011155w=2).
 As the removal was part of a refactoring of the sitemap engine, could
 sombody give me a description of what needs to be done?

The main idea is to create a classloader with what is defined by
map:classpath in the sitemap, and use that classloader to create the
container for components in map:components

This is achieved by giving this classloader to the container (was
possible with ECM, don't know with Spring) and setting it as the
thread's default classloader before processing a request in the sitemap
(and restoring the old one at the end).

This allowed classes to be reloaded when the sitemap was reloaded.
Torsten later added a file monitor that tracks changes to the contents
of the classpath and triggers the sitemap reloading.

Sylvain

-- 
Sylvain Wallez - http://bluxte.net

[HEADS UP] Xalan XSLTC

2006-05-17 Thread Torsten Curdt


In order to replace a snaphot jar in Cocoon with a proper release we
need the BCEL release to come through. Unfortunately BCEL is missing
some feedback on the RC2 to do the release though.

So if anyone is using Xalan XSLTC - please give it a try. Just replace
the shipped BCEL jar with the one available here:

http://people.apache.org/~tcurdt/bcel/rc2/

and give some feedback whether Xalan is still working for you.

Thanks
--
Torsten

Re: RAD with Cocoon 2.2


Reinhard Poetz skrev:


Maven brings a lot of advantages to standardize the development 
process but also makes development of applications more difficult as 
you spread your applications over different artifacts.


In the light of this I think we should revert our removal of the 
per-sitemap classloading 
(http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=114150323011155w=2). 
As the removal was part of a refactoring of the sitemap engine, could 
sombody give me a description of what needs to be done?


I agree that RAD is important, but I would prefer to put the dynamic 
classloading in the block level container rather than within the 
sitemap. Component handling within the sitemap is mix of concern IMO. I 
know that it has been a must for this far, as sub sitemap has been the 
only mechanism for modularization. But with blocks we have a much better 
mechanism for modularization so I think we should focus on that and 
maybe even deprecate the sitemap component declarations.


By separating the dynamic classloading from the sitemap and connect it 
to the container, we simplify our architecture considerably. Also 
dynamic classloading could be interesting for other Spring users, so 
maybe we could even cooperate with the Spring community about it.


/Daniel

Re: RAD with Cocoon 2.2

Reinhard Poetz wrote:
 Maven brings a lot of advantages to standardize the development process but 
 also 
 makes development of applications more difficult as you spread your 
 applications 
 over different artifacts.
 
 In the light of this I think we should revert our removal of the per-sitemap 
 classloading 
 (http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=114150323011155w=2). As 
 the 
 removal was part of a refactoring of the sitemap engine, could sombody give 
 me a 
 description of what needs to be done?
 
I'm not against readding the per sitemap classloaders, but before this I
would suggest that we think about how development with 2.2 can be done.
With 2.1.x you can develop your application directory from within your
IDE, you don't have to invoke a build script, you don't have to copy
files after you changed them etc.; And you don't have to use different
configurations (like classpaths) for development. It just works.
And I think this should be the way for 2.2 as well.

Carsten

-- 
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: RAD with Cocoon 2.2

Sylvain Wallez wrote:
 Reinhard Poetz wrote:
 Maven brings a lot of advantages to standardize the development
 process but also makes development of applications more difficult as
 you spread your applications over different artifacts.

 In the light of this I think we should revert our removal of the
 per-sitemap classloading
 (http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=114150323011155w=2).
 As the removal was part of a refactoring of the sitemap engine, could
 sombody give me a description of what needs to be done?
 
 The main idea is to create a classloader with what is defined by
 map:classpath in the sitemap, and use that classloader to create the
 container for components in map:components
 
 This is achieved by giving this classloader to the container (was
 possible with ECM, don't know with Spring) and setting it as the
 thread's default classloader before processing a request in the sitemap
 (and restoring the old one at the end).
 
Afaik, Spring has no support for own classloaders (but I might be
wrong), but I guess if we instantiate the new BeanFactory in an own
classloader everything should work from there as expected.
So, creating an own classloader, setting/restoring the thread context
classloader and creating the bean factory using this classloader should
be all.

Carsten

-- 
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

ForrestBot build for cocoon-docs FAILED

2006-05-17 Thread Forrestbot

Automated build for cocoon-docs FAILED
Log attached.

--
Forrestbot run ended at 17 May 12:24 PM
Using Forrest 0.8-dev
Forrestbot administrator: ForrestBot
--

 [echo] 
  ... Forrest render START 2006-05-17 12:02:27
  ... Rendering docs in 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs


check-java-version:
 [echo] This is apache-forrest-0.8-dev
 [echo] Using Java 1.4 from /usr/j2se/jre

init-props:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

echo-settings:

check-skin:

init-proxy:

fetch-skins-descriptors:

fetch-skin:

unpack-skins:

init-skins:

fetch-plugins-descriptors:
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/plugins.xml
  [get] To: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml
  [get] ...
  [get] last modified = Fri Feb 24 09:07:16 GMT+00:00 2006
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] To: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml
  [get] ..
  [get] last modified = Thu Apr 06 07:54:56 GMT+00:00 2006
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/plugins.xml.
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/whiteboard-plugins.xml.

init-plugins:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] 
  --
  Installing plugin: org.apache.forrest.plugin.output.pdf
  --
   

check-plugin:
 [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. 
Trying to update it...

init-props:

echo-settings:

init-proxy:

fetch-plugins-descriptors:

fetch-plugin:
 [echo] Trying to find the description of 
org.apache.forrest.plugin.output.pdf in the different descriptor files
 [echo] Using the descriptor file 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml...
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl

fetch-local-unversioned-plugin:

get-local:
 [echo] Trying to locally get org.apache.forrest.plugin.output.pdf
 [echo] Looking in local /export/opt/forrest-trunk/plugins
 [echo] Found !

init-build-compiler:

echo-init:

init:

compile:

jar:

local-deploy:
 [echo] Locally deploying org.apache.forrest.plugin.output.pdf

build:
 [echo] Plugin org.apache.forrest.plugin.output.pdf deployed ! Ready to 
configure

fetch-remote-unversioned-plugin-version-forrest:

fetch-remote-unversioned-plugin-unversion-forrest:

has-been-downloaded:

downloaded-message:

uptodate-message:

not-found-message:
 [echo] Fetch-plugin Ok, installing !

unpack-plugin:

install-plugin:

configure-plugin:

configure-output-plugin:
 [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl
 [move] Moving 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

configure-plugin-locationmap:
 [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml 
to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl
 [move] Moving 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] 
  --
  Installing plugin: org.apache.forrest.plugin.input.projectInfo
  --
   

check-plugin:
 [echo]

Re: RAD with Cocoon 2.2

Daniel Fagerstrom schrieb:
 Reinhard Poetz skrev:
 Maven brings a lot of advantages to standardize the development 
 process but also makes development of applications more difficult as 
 you spread your applications over different artifacts.

 In the light of this I think we should revert our removal of the 
 per-sitemap classloading 
 (http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=114150323011155w=2). 
 As the removal was part of a refactoring of the sitemap engine, could 
 sombody give me a description of what needs to be done?

 I agree that RAD is important, but I would prefer to put the dynamic 
 classloading in the block level container rather than within the 
 sitemap. Component handling within the sitemap is mix of concern IMO. I 
 know that it has been a must for this far, as sub sitemap has been the 
 only mechanism for modularization. But with blocks we have a much better 
 mechanism for modularization so I think we should focus on that and 
 maybe even deprecate the sitemap component declarations.
 
 By separating the dynamic classloading from the sitemap and connect it 
 to the container, we simplify our architecture considerably. Also 
 dynamic classloading could be interesting for other Spring users, so 
 maybe we could even cooperate with the Spring community about it.
 
Now I think that per sitemap configuration and even per sitemap class
loading are key features of 2.2. I see no need to deprecate them or
something like this. With 2.2 you include your component configs from
the sitemap and you define your classpath in the sitemap. With real
blocks there are only minimal changes as you just have to remove the
include and the classpath definition from your sitemap and but these
somewhere in the block config - and that's it. Your configuration of
your components stays the same.

Carsten
-- 
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: svn commit: r407153 - in /cocoon/trunk/blocks: cocoon-portal/cocoon-portal-impl/pom.xml cocoon-scratchpad/cocoon-scratchpad-impl/pom.xml

2006-05-17 Thread Antonio Gallardo


[EMAIL PROTECTED] escribió:

Author: giacomo
Date: Tue May 16 21:58:44 2006
New Revision: 407153

URL: http://svn.apache.org/viewcvs?rev=407153view=rev
Log:
keep versions in sync
  

Thanks Giacomo.

Best Regards,

Antonio Gallardo.

Re: [2.2] Configuration issues

2006-05-17 Thread Ralph Goers

Daniel Fagerstrom wrote:

Carsten Ziegeler skrev:

For the Avalon configurations we could find some convention for
translating configuration file element paths to property strings and
then write a implementation of the avalon Configuration that override
the configuration file based configuration with the property values.
And feed that overridable configuration to the component in the
BeanPostProcessor for the Avalon life cycle.
This is already the way it works in both 2.1 and 2.2. Cocoon provides
values for everything in property files within the block. The user can
then provide their own values which override them. I think Carsten is
simply worried because there are a lot of values you can specify.

2. This works only as long as the user wants to use the same
implementation for a component. Switching to an own implementation with
an own configuration is not possible.

Any idea on how to solve this?
Here the IMO best and most natural solution is to have different
blocks for different implementations. Say we have two different
components that implements the XsltProcessor inteface, the Xalan and
the Saxon implementation. Then if you have a Xalan block with its own
embedded configuration and a Saxon block with its own embedded
configuration. If you want to use the Xalan implementation you deploy
the Xalan block and if you want the Saxon implementation you deply the
Saxon block.

The result of this thinking is that you have typically smaller and
more focused blocks, that contain components that are used togerther.
I think Carsten is worried about the Portal. The portal has a lot of
configurable elements in it.

WDYT?

/Daniel

Re: RAD with Cocoon 2.2


Daniel Fagerstrom wrote:

Reinhard Poetz skrev:



Maven brings a lot of advantages to standardize the development 
process but also makes development of applications more difficult as 
you spread your applications over different artifacts.


In the light of this I think we should revert our removal of the 
per-sitemap classloading 
(http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=114150323011155w=2). 
As the removal was part of a refactoring of the sitemap engine, could 
sombody give me a description of what needs to be done?


I agree that RAD is important, but I would prefer to put the dynamic 
classloading in the block level container rather than within the 
sitemap. Component handling within the sitemap is mix of concern IMO. 


I agree

I 
know that it has been a must for this far, as sub sitemap has been the 
only mechanism for modularization. But with blocks we have a much better 
mechanism for modularization so I think we should focus on that and 
maybe even deprecate the sitemap component declarations.


With 2.2 blocks are only deployment units. Within Cocoon 2.2 there is no concept 
of blocks, no blocks protocol, no shielded classloader (I know that you know but 
just to speak it out)


By separating the dynamic classloading from the sitemap and connect it 
to the container, we simplify our architecture considerably. Also 
dynamic classloading could be interesting for other Spring users, so 
maybe we could even cooperate with the Spring community about it.


hmm, not sure if I understand what you mean. IIUC each sitemap has its own 
Spring bean factory (container). Do you want to make the classloader, which is 
used to create the bean factory, configureable?



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


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

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






___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: RAD with Cocoon 2.2


Carsten Ziegeler wrote:


Now I think that per sitemap configuration and even per sitemap class
loading are key features of 2.2. I see no need to deprecate them or
something like this. 


With Cocoon 3.0 and applications that are really split into blocks, we should 
only support one way of application modularization and I agree with Daniel that 
this should be at the block level. But things like this don't need to be decided 
today.



With 2.2 you include your component configs from
the sitemap and you define your classpath in the sitemap. With real
blocks there are only minimal changes as you just have to remove the
include and the classpath definition from your sitemap and but these
somewhere in the block config - and that's it. Your configuration of
your components stays the same.


right except that each block already has it's own classloader (remember, OSGi 
;-) ...).



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


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

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






___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [2.2] Configuration issues

Ralph Goers wrote:
 I think Carsten is worried about the Portal. The portal has a lot of 
 configurable elements in it.
No actually I'm not worried about the portal - this will have a clean
solution for 2.2; I'm just more worried about core, for example how can
I configure my own store implementation without changing the core xconf?

Carsten
-- 
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [2.2] Configuration issues

Daniel Fagerstrom wrote:

 Here the IMO best and most natural solution is to have different blocks 
 for different implementations. Say we have two different components that 
 implements the XsltProcessor inteface, the Xalan and the Saxon 
 implementation. Then if you have a Xalan block with its own embedded 
 configuration and a Saxon block with its own embedded configuration. If 
 you want to use the Xalan implementation you deploy the Xalan block and 
 if you want the Saxon implementation you deply the Saxon block.
 
 The result of this thinking is that you have typically smaller and more 
 focused blocks, that contain components that are used togerther.
 
 WDYT?
I'm not sure - on the one hand you're probably right. But this will lead
to too many blocks. If you think this through, this will require that
you make for each and every component an own block just to be able to
use a different implementation.

Carsten

-- 
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [2.2] Configuration issues


Carsten Ziegeler wrote:

Daniel Fagerstrom wrote:


Here the IMO best and most natural solution is to have different blocks 
for different implementations. Say we have two different components that 
implements the XsltProcessor inteface, the Xalan and the Saxon 
implementation. Then if you have a Xalan block with its own embedded 
configuration and a Saxon block with its own embedded configuration. If 
you want to use the Xalan implementation you deploy the Xalan block and 
if you want the Saxon implementation you deply the Saxon block.


The result of this thinking is that you have typically smaller and more 
focused blocks, that contain components that are used togerther.


WDYT?


I'm not sure - on the one hand you're probably right. But this will lead
to too many blocks. If you think this through, this will require that
you make for each and every component an own block just to be able to
use a different implementation.


What about having at least a configuration file for each and every component? 
This way, it would be simple to provide some overriding mechanism, e.g. all 
files in ./src/main/cocoon-xconf override files coming from a deployed block at 
deployment.


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


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

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






___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: RAD with Cocoon 2.2

Reinhard Poetz wrote:
 Carsten Ziegeler wrote:
 
 Now I think that per sitemap configuration and even per sitemap class
 loading are key features of 2.2. I see no need to deprecate them or
 something like this. 
 
 With Cocoon 3.0 and applications that are really split into blocks, we should 
 only support one way of application modularization
Exactly.

 and I agree with Daniel that
 this should be at the block level. 
Totally agree.

 But things like this don't need to be decided today.
 
 With 2.2 you include your component configs from
 the sitemap and you define your classpath in the sitemap. With real
 blocks there are only minimal changes as you just have to remove the
 include and the classpath definition from your sitemap and but these
 somewhere in the block config - and that's it. Your configuration of
 your components stays the same.
 
 right except that each block already has it's own classloader (remember, OSGi 
 ;-) ...).
Yes, that was actually what I meant :)
Cocoon 2.2: Configuration at sitemap level (Includes)
Cocoon 3.0: Configuration at block level
Hopefully you can use the same configuration files for both versions, so
only the includes are at a different location.

Carsten


-- 
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [2.2] Configuration issues

2006-05-17 Thread Peter Hunsberger


On 5/17/06, Daniel Fagerstrom [EMAIL PROTECTED] wrote:

snip/


 2. This works only as long as the user wants to use the same
 implementation for a component. Switching to an own implementation with
 an own configuration is not possible.

 Any idea on how to solve this?
Here the IMO best and most natural solution is to have different blocks
for different implementations. Say we have two different components that
implements the XsltProcessor inteface, the Xalan and the Saxon
implementation. Then if you have a Xalan block with its own embedded
configuration and a Saxon block with its own embedded configuration. If
you want to use the Xalan implementation you deploy the Xalan block and
if you want the Saxon implementation you deply the Saxon block.


Would this solution be able to deal with using both Saxon and Xalan or
two different versions of Saxon at different points in the same
pipeline?  In our case we have 1 critical XSLT that currently only
runs under Saxon 6 (I've tried repeatedly to get it to Saxon 8, but so
far no go).  Everything else exploits XSLT 2.0 and requires Saxon 8.
We mix these XSLT in the same pipelines all the time...

--
Peter Hunsberger

Re: RAD with Cocoon 2.2


Carsten Ziegeler wrote:


Hopefully you can use the same configuration files for both versions, so
only the includes are at a different location.


Yes, that's already implemented in C3.

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


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

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






___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

[continuum] BUILD SUCCESSFUL: Apache Cocoon

Online report : 
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1156
Build statistics:
  State: Ok
  Previous State: Failed
  Started at: Wed, 17 May 2006 17:53:57 +
  Finished at: Wed, 17 May 2006 17:54:36 +
  Total time: 38s
  Build Trigger: Forced
  Exit code: 0
  Building machine hostname: cocoon.zones.apache.org
  Operating system : SunOS(unknown)
  Java version : 1.4.2_06(Sun Microsystems Inc.)

Changes
 giacomo  keep versions in sync
 /cocoon/trunk/blocks/cocoon-portal/cocoon-portal-impl/pom.xml

/cocoon/trunk/blocks/cocoon-scratchpad/cocoon-scratchpad-impl/pom.xml
   cziegeler  Cleanup sitemap component configs
 
/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/cocoon.xconf

/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/sitemap-additions/cocoon-core-sitemap-additions.xconf

/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/sitemap-additions/cocoon-core-sitemap.xmap

/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/xconf/cocoon-core-sitemap.xconf
   bruno  Add a 'normal-behaving' moveRow2 method.

 
/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/Repeater.java
   cziegeler  Cleanup paranoid block and use paranoid servlet 
as default
 /cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/pom.xml

/cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/src/main/java/org/apache/cocoon/servlet/BootstrapServlet.java

/cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/src/main/java/org/apache/cocoon/servlet/ParanoidClassLoader.java

/cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/src/main/java/org/apache/cocoon/servlet/ParanoidCocoonServlet.java
/cocoon/trunk/core/cocoon-webapp/pom.xml
/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/web.xml
   jheymans  cvs.a.o wasn't a recommended hostname. Removed 
default install goal
 /cocoon/trunk/pom.xml


Output:

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'source'.
[INFO] 

[INFO] Building Apache Cocoon
[INFO]task-segment: [clean, source:jar, javadoc:jar, deploy]
[INFO] 

[INFO] [clean:clean]
[INFO] Deleting directory 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/1/target
[INFO] [source:jar]
[INFO] NOT adding java-sources to attached artifacts for packaging: 'pom'.
[INFO] Preparing javadoc:jar
[INFO] [javadoc:javadoc]
[INFO] Not executing Javadoc as the project is not a Java classpath-capable 
package
[INFO] [javadoc:jar]
[INFO] Not executing Javadoc as the project is not a Java classpath-capable 
package
[INFO] Skipping missing optional mojo: 
org.apache.maven.plugins:maven-site-plugin:attach-descriptor
[INFO] [install:install]
[INFO] Installing 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/1/pom.xml to 
/home/maven/.m2/repository/org/apache/cocoon/cocoon/1-SNAPSHOT/cocoon-1-SNAPSHOT.pom
[INFO] [deploy:deploy]
[INFO] Retrieving previous build number from apache-maven-snapshot
Uploading: 
scpexe://people.apache.org/x1/www/cvs.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon/1-SNAPSHOT/cocoon-1-20060517.175414-13.pom
[INFO] Retrieving previous metadata from apache-maven-snapshot
[INFO] Uploading repository metadata for: 'artifact org.apache.cocoon:cocoon'
[INFO] Retrieving previous metadata from apache-maven-snapshot
[INFO] Uploading repository metadata for: 'snapshot 
org.apache.cocoon:cocoon:1-SNAPSHOT'
[INFO] 

[INFO] BUILD SUCCESSFUL
[INFO] 

[INFO] Total time: 28 seconds
[INFO] Finished at: Wed May 17 17:54:36 GMT+00:00 2006
[INFO] Final Memory: 4M/8M
[INFO]

[continuum] BUILD SUCCESSFUL: Cocoon Blocks [modules]

Online report : 
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/2/buildId/1157
Build statistics:
  State: Ok
  Previous State: Failed
  Started at: Wed, 17 May 2006 17:59:58 +
  Finished at: Wed, 17 May 2006 18:00:24 +
  Total time: 26s
  Build Trigger: Forced
  Exit code: 0
  Building machine hostname: cocoon.zones.apache.org
  Operating system : SunOS(unknown)
  Java version : 1.4.2_06(Sun Microsystems Inc.)

Changes
 giacomo  keep versions in sync
 /cocoon/trunk/blocks/cocoon-portal/cocoon-portal-impl/pom.xml

/cocoon/trunk/blocks/cocoon-scratchpad/cocoon-scratchpad-impl/pom.xml
   bruno  Add a 'normal-behaving' moveRow2 method.

 
/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/Repeater.java
   cziegeler  Cleanup paranoid block and use paranoid servlet 
as default
 /cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/pom.xml

/cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/src/main/java/org/apache/cocoon/servlet/BootstrapServlet.java

/cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/src/main/java/org/apache/cocoon/servlet/ParanoidClassLoader.java

/cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/src/main/java/org/apache/cocoon/servlet/ParanoidCocoonServlet.java
/cocoon/trunk/core/cocoon-webapp/pom.xml
/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/web.xml


Output:

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'source'.
[INFO] 

[INFO] Building Cocoon Blocks [modules]
[INFO]task-segment: [clean, source:jar, javadoc:jar, deploy]
[INFO] 

[INFO] [clean:clean]
[INFO] Deleting directory 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/2/target
[INFO] [source:jar]
[INFO] NOT adding java-sources to attached artifacts for packaging: 'pom'.
[INFO] Preparing javadoc:jar
[INFO] [javadoc:javadoc]
[INFO] Not executing Javadoc as the project is not a Java classpath-capable 
package
[INFO] [javadoc:jar]
[INFO] Not executing Javadoc as the project is not a Java classpath-capable 
package
[INFO] Skipping missing optional mojo: 
org.apache.maven.plugins:maven-site-plugin:attach-descriptor
[INFO] [install:install]
[INFO] Installing 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/2/pom.xml to 
/home/maven/.m2/repository/org/apache/cocoon/cocoon-blocks-modules/1-SNAPSHOT/cocoon-blocks-modules-1-SNAPSHOT.pom
[INFO] [deploy:deploy]
[INFO] Retrieving previous build number from apache-maven-snapshot
Uploading: 
scpexe://people.apache.org/x1/www/cvs.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-blocks-modules/1-SNAPSHOT/cocoon-blocks-modules-1-20060517.180002-8.pom
[INFO] Retrieving previous metadata from apache-maven-snapshot
[INFO] Uploading repository metadata for: 'snapshot 
org.apache.cocoon:cocoon-blocks-modules:1-SNAPSHOT'
[INFO] Retrieving previous metadata from apache-maven-snapshot
[INFO] Uploading repository metadata for: 'artifact 
org.apache.cocoon:cocoon-blocks-modules'
[INFO] 

[INFO] BUILD SUCCESSFUL
[INFO] 

[INFO] Total time: 25 seconds
[INFO] Finished at: Wed May 17 18:00:24 GMT+00:00 2006
[INFO] Final Memory: 4M/8M
[INFO]

[continuum] BUILD SUCCESSFUL: Cocoon Core [modules]

Online report : 
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/156/buildId/1159
Build statistics:
  State: Ok
  Previous State: Failed
  Started at: Wed, 17 May 2006 18:02:57 +
  Finished at: Wed, 17 May 2006 18:03:25 +
  Total time: 27s
  Build Trigger: Forced
  Exit code: 0
  Building machine hostname: cocoon.zones.apache.org
  Operating system : SunOS(unknown)
  Java version : 1.4.2_06(Sun Microsystems Inc.)

Changes
 cziegeler  Cleanup sitemap component configs
 
/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/cocoon.xconf

/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/sitemap-additions/cocoon-core-sitemap-additions.xconf

/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/sitemap-additions/cocoon-core-sitemap.xmap

/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/xconf/cocoon-core-sitemap.xconf
   cziegeler  Cleanup paranoid block and use paranoid servlet 
as default
 /cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/pom.xml

/cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/src/main/java/org/apache/cocoon/servlet/BootstrapServlet.java

/cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/src/main/java/org/apache/cocoon/servlet/ParanoidClassLoader.java

/cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/src/main/java/org/apache/cocoon/servlet/ParanoidCocoonServlet.java
/cocoon/trunk/core/cocoon-webapp/pom.xml
/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/web.xml
   cziegeler  Log everything using log4j
 
/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/core/container/spring/CocoonBeanFactory.java
/cocoon/trunk/core/cocoon-webapp/pom.xml
/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/log4j.xconf


Output:

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'source'.
[INFO] 

[INFO] Building Cocoon Core [modules]
[INFO]task-segment: [clean, source:jar, javadoc:jar, deploy]
[INFO] 

[INFO] [clean:clean]
[INFO] Deleting directory 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/156/target
[INFO] [source:jar]
[INFO] NOT adding java-sources to attached artifacts for packaging: 'pom'.
[INFO] Preparing javadoc:jar
[INFO] [javadoc:javadoc]
[INFO] Not executing Javadoc as the project is not a Java classpath-capable 
package
[INFO] [javadoc:jar]
[INFO] Not executing Javadoc as the project is not a Java classpath-capable 
package
[INFO] Skipping missing optional mojo: 
org.apache.maven.plugins:maven-site-plugin:attach-descriptor
[INFO] [install:install]
[INFO] Installing 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/156/pom.xml to 
/home/maven/.m2/repository/org/apache/cocoon/cocoon-core-modules/1-SNAPSHOT/cocoon-core-modules-1-SNAPSHOT.pom
[INFO] [deploy:deploy]
[INFO] Retrieving previous build number from apache-maven-snapshot
Uploading: 
scpexe://people.apache.org/x1/www/cvs.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-core-modules/1-SNAPSHOT/cocoon-core-modules-1-20060517.180302-8.pom
[INFO] Retrieving previous metadata from apache-maven-snapshot
[INFO] Uploading repository metadata for: 'artifact 
org.apache.cocoon:cocoon-core-modules'
[INFO] Retrieving previous metadata from apache-maven-snapshot
[INFO] Uploading repository metadata for: 'snapshot 
org.apache.cocoon:cocoon-core-modules:1-SNAPSHOT'
[INFO] 

[INFO] BUILD SUCCESSFUL
[INFO] 

[INFO] Total time: 26 seconds
[INFO] Finished at: Wed May 17 18:03:24 GMT+00:00 2006
[INFO] Final Memory: 4M/8M
[INFO]

[continuum] BUILD SUCCESSFUL: Core Webapp

Online report : 
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/163/buildId/1160
Build statistics:
  State: Ok
  Previous State: Failed
  Started at: Wed, 17 May 2006 18:03:28 +
  Finished at: Wed, 17 May 2006 18:05:41 +
  Total time: 2m 12s
  Build Trigger: Forced
  Exit code: 0
  Building machine hostname: cocoon.zones.apache.org
  Operating system : SunOS(unknown)
  Java version : 1.4.2_06(Sun Microsystems Inc.)

Changes
 cziegeler  Cleanup sitemap component configs
 
/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/cocoon.xconf

/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/sitemap-additions/cocoon-core-sitemap-additions.xconf

/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/sitemap-additions/cocoon-core-sitemap.xmap

/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/xconf/cocoon-core-sitemap.xconf
   cziegeler  Cleanup paranoid block and use paranoid servlet 
as default
 /cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/pom.xml

/cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/src/main/java/org/apache/cocoon/servlet/BootstrapServlet.java

/cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/src/main/java/org/apache/cocoon/servlet/ParanoidClassLoader.java

/cocoon/trunk/blocks/cocoon-paranoid/cocoon-paranoid-impl/src/main/java/org/apache/cocoon/servlet/ParanoidCocoonServlet.java
/cocoon/trunk/core/cocoon-webapp/pom.xml
/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/web.xml
   cziegeler  Log everything using log4j
 
/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/core/container/spring/CocoonBeanFactory.java
/cocoon/trunk/core/cocoon-webapp/pom.xml
/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/log4j.xconf


Output:

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'source'.
[INFO] org.codehaus.mojo: checking for updates from snapshots
[WARNING] repository metadata for: 'org.codehaus.mojo' could not be retrieved 
from repository: snapshots due to an error: Error transferring file
[INFO] Repository 'snapshots' will be blacklisted
[INFO] 

[INFO] Building Core Webapp
[INFO]task-segment: [clean, source:jar, javadoc:jar, deploy]
[INFO] 

[INFO] [clean:clean]
[INFO] Deleting directory 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/163/target
[INFO] [source:jar]
[INFO] Building jar: 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/163/target/cocoon-webapp-sources.jar
[INFO] Preparing javadoc:jar
[INFO] snapshot org.apache.cocoon:cocoon-paranoid-impl:1.0.0-SNAPSHOT: checking 
for updates from central
[INFO] snapshot org.apache.cocoon:cocoon-paranoid-impl:1.0.0-SNAPSHOT: checking 
for updates from apache.snapshot
[INFO] snapshot org.apache.cocoon:cocoon-paranoid-impl:1.0.0-SNAPSHOT: checking 
for updates from apache-cvs
[INFO] snapshot org.apache.cocoon:cocoon-paranoid-impl:1.0.0-SNAPSHOT: checking 
for updates from apache.snapshots
[INFO] snapshot org.apache.cocoon:cocoon-paranoid:1-SNAPSHOT: checking for 
updates from central
[INFO] snapshot org.apache.cocoon:cocoon-paranoid:1-SNAPSHOT: checking for 
updates from apache.snapshot
[INFO] snapshot org.apache.cocoon:cocoon-paranoid:1-SNAPSHOT: checking for 
updates from apache-cvs
[INFO] snapshot org.apache.cocoon:cocoon-paranoid:1-SNAPSHOT: checking for 
updates from apache.snapshots
[INFO] [javadoc:javadoc]
[INFO] [javadoc:jar]
[INFO] Building jar: 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/163/target/cocoon-webapp-javadoc.jar
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
Downloading: 
http://mirrors.dotsrc.org/maven2/org/apache/cocoon/cocoon-paranoid-impl/1.0.0-SNAPSHOT/cocoon-paranoid-impl-1.0.0-20060513.094724-1.pom
[WARNING] Unable to get resource from repository central 
(http://ibiblio.org/maven2)
Downloading: 
http://svn.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-paranoid-impl/1.0.0-SNAPSHOT/cocoon-paranoid-impl-1.0.0-20060513.094724-1.pom
851b downloaded
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [war:war]
[INFO] Exploding webapp...
[INFO] Copy webapp resources to

[continuum] BUILD SUCCESSFUL: Forms Block

Online report : 
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/45/buildId/1161
Build statistics:
  State: Ok
  Previous State: Failed
  Started at: Wed, 17 May 2006 18:05:52 +
  Finished at: Wed, 17 May 2006 18:06:20 +
  Total time: 28s
  Build Trigger: Forced
  Exit code: 0
  Building machine hostname: cocoon.zones.apache.org
  Operating system : SunOS(unknown)
  Java version : 1.4.2_06(Sun Microsystems Inc.)

Changes
 bruno  Add a 'normal-behaving' moveRow2 method.

 
/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/Repeater.java


Output:

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'source'.
[INFO] 

[INFO] Building Forms Block
[INFO]task-segment: [clean, source:jar, javadoc:jar, deploy]
[INFO] 

[INFO] [clean:clean]
[INFO] Deleting directory 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/45/target
[INFO] [source:jar]
[INFO] NOT adding java-sources to attached artifacts for packaging: 'pom'.
[INFO] Preparing javadoc:jar
[INFO] [javadoc:javadoc]
[INFO] Not executing Javadoc as the project is not a Java classpath-capable 
package
[INFO] [javadoc:jar]
[INFO] Not executing Javadoc as the project is not a Java classpath-capable 
package
[INFO] Skipping missing optional mojo: 
org.apache.maven.plugins:maven-site-plugin:attach-descriptor
[INFO] [install:install]
[INFO] Installing 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/45/pom.xml to 
/home/maven/.m2/repository/org/apache/cocoon/cocoon-forms/1-SNAPSHOT/cocoon-forms-1-SNAPSHOT.pom
[INFO] [deploy:deploy]
[INFO] Retrieving previous build number from apache-maven-snapshot
Uploading: 
scpexe://people.apache.org/x1/www/cvs.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-forms/1-SNAPSHOT/cocoon-forms-1-20060517.180557-6.pom
[INFO] Retrieving previous metadata from apache-maven-snapshot
[INFO] Uploading repository metadata for: 'snapshot 
org.apache.cocoon:cocoon-forms:1-SNAPSHOT'
[INFO] Retrieving previous metadata from apache-maven-snapshot
[INFO] Uploading repository metadata for: 'artifact 
org.apache.cocoon:cocoon-forms'
[INFO] 

[INFO] BUILD SUCCESSFUL
[INFO] 

[INFO] Total time: 27 seconds
[INFO] Finished at: Wed May 17 18:06:20 GMT+00:00 2006
[INFO] Final Memory: 4M/8M
[INFO]

[continuum] BUILD SUCCESSFUL: Forms Block Samples

Online report : 
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/47/buildId/1162
Build statistics:
  State: Ok
  Previous State: Failed
  Started at: Wed, 17 May 2006 18:06:23 +
  Finished at: Wed, 17 May 2006 18:07:36 +
  Total time: 1m 13s
  Build Trigger: Forced
  Exit code: 0
  Building machine hostname: cocoon.zones.apache.org
  Operating system : SunOS(unknown)
  Java version : 1.4.2_06(Sun Microsystems Inc.)

Changes
  No files changed
  

Output:

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'source'.
[INFO] 

[INFO] Building Forms Block Samples
[INFO]task-segment: [clean, source:jar, javadoc:jar, deploy]
[INFO] 

[INFO] [clean:clean]
[INFO] Deleting directory 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/47/target
[INFO] [source:jar]
[INFO] Building jar: 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/47/target/cocoon-forms-sample-1.0.0-SNAPSHOT-sources.jar
[INFO] Preparing javadoc:jar
[INFO] [javadoc:javadoc]
[INFO] [javadoc:jar]
[INFO] Building jar: 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/47/target/cocoon-forms-sample-1.0.0-SNAPSHOT-javadoc.jar
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar: 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/47/target/cocoon-forms-sample-1.0.0-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/47/target/cocoon-forms-sample-1.0.0-SNAPSHOT.jar
 to 
/home/maven/.m2/repository/org/apache/cocoon/cocoon-forms-sample/1.0.0-SNAPSHOT/cocoon-forms-sample-1.0.0-SNAPSHOT.jar
[INFO] Installing 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/47/target/cocoon-forms-sample-1.0.0-SNAPSHOT-sources.jar
 to 
/home/maven/.m2/repository/org/apache/cocoon/cocoon-forms-sample/1.0.0-SNAPSHOT/cocoon-forms-sample-1.0.0-SNAPSHOT-sources.jar
[INFO] Installing 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/47/target/cocoon-forms-sample-1.0.0-SNAPSHOT-javadoc.jar
 to 
/home/maven/.m2/repository/org/apache/cocoon/cocoon-forms-sample/1.0.0-SNAPSHOT/cocoon-forms-sample-1.0.0-SNAPSHOT-javadoc.jar
[INFO] [deploy:deploy]
[INFO] Retrieving previous build number from apache-maven-snapshot
Uploading: 
scpexe://people.apache.org/x1/www/cvs.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-forms-sample/1.0.0-SNAPSHOT/cocoon-forms-sample-1.0.0-20060517.180652-3.jar
[INFO] Retrieving previous metadata from apache-maven-snapshot
[INFO] Uploading repository metadata for: 'artifact 
org.apache.cocoon:cocoon-forms-sample'
[INFO] Retrieving previous metadata from apache-maven-snapshot
[INFO] Uploading repository metadata for: 'snapshot 
org.apache.cocoon:cocoon-forms-sample:1.0.0-SNAPSHOT'
[INFO] Retrieving previous metadata from apache-maven-snapshot
[INFO] Uploading project information for cocoon-forms-sample 
1.0.0-20060517.180652-3
[INFO] Retrieving previous build number from apache-maven-snapshot
Uploading: 
scpexe://people.apache.org/x1/www/cvs.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-forms-sample/1.0.0-SNAPSHOT/cocoon-forms-sample-1.0.0-20060517.180652-3-sources.jar
[INFO] Retrieving previous build number from apache-maven-snapshot
Uploading: 
scpexe://people.apache.org/x1/www/cvs.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-forms-sample/1.0.0-SNAPSHOT/cocoon-forms-sample-1.0.0-20060517.180652-3-javadoc.jar
[INFO] 

[INFO] BUILD SUCCESSFUL
[INFO] 

[INFO] Total time: 1 minute 12 seconds
[INFO] Finished at: Wed May 17 18:07:36 GMT+00:00 2006
[INFO] Final Memory: 8M/15M
[INFO]

Re: [2.2] Configuration issues


Carsten Ziegeler skrev:

Reinhard Poetz wrote:

How does OSGi solve this?
Since OSGi4 declarative services are supported. Think of Spring dependency 
injection but considering interface/implementation relations. You can use the 
OSGi configuratonAdmin service to change an injected component or a component's 
properties.

Ok, but this is then configuration at runtime and not at development
time, right?


The configuration admin is called when a service (component) is registered.


Where are those values stored?


According to the spec they are stored persistently. The actual storage 
mechanism is not standardized though. In Felix they talking about 
connecting the configuration admin to the storage API from the directory 
project so that configurations can be stored in e.g. an LDAP server.


Reinhard and I have discussed initializing the configuration admin from 
an XML or property file.


Additionally we have the possibility to redisgn e.g. forms and portal to use the 
OSGi whiteboard pattern[1]. Using it makes extending them very simple as it 
makes extensions very simple - you just have to provide a component that 
implements a particular interface and it is automatically added as reference to 
another component.



I don't want to rewrite blocks in order to use OSGi and I think one of
our main goals for using OSGi is that this does not affect the way how I
develop blocks which means it is totally transparent. So imho we need an
OSGi-free way which works at development time.


The whiteboard pattern isn't about OSGi per se, but rather about how to 
organize extensible components in a plugin based architecture. The 
configuration model that is used for CForms is not suitable for a plugin 
architecture at all, as it assumes a single complete list of all 
components in one place. If you want to ad a component you need to edit 
the central configuration file.


With the whiteboard pattern, each plugin register its services, e.g. 
validators and widgets, in a registry (the whiteboard). Then the user, 
e.g. the form framework search for the services it needs from the 
registry. This is much more flexible and extensible than the current 
architecture.


/Daniel

[jira] Closed: (COCOON-1804) Javascript FOM_SCOPE issue when using Java as the flow engine - ReferenceError: cocoon is not defined

2006-05-17 Thread Simone Gianni (JIRA)

 [ http://issues.apache.org/jira/browse/COCOON-1804?page=all ]
 
Simone Gianni closed COCOON-1804:
-

Fix Version: 2.1.10-dev (current SVN)
 Resolution: Fixed

Committed the patch

 Javascript FOM_SCOPE issue when using Java as the flow engine - 
 ReferenceError: cocoon is not defined
 ---

  Key: COCOON-1804
  URL: http://issues.apache.org/jira/browse/COCOON-1804
  Project: Cocoon
 Type: Bug

   Components: Blocks: Java Flow
 Versions: 2.1.8
 Reporter: Andrew Madu
 Priority: Blocker
  Fix For: 2.1.10-dev (current SVN)
  Attachments: javaflow-fomcocoon.diff

 I have created a  java flow class which does the following:
 //Load in validation file
 FormInstance form = new FormInstance(forms/login.xml);
 My login map (snippet) is as follows:
 Login.xml:
 fd:validation
 fd:javascript
 var success = true;
 var newUserReg = new Packages.test.User();
 var username = widget.lookupWidget(username);
 var password = widget.lookupWidget(password);

 try {
 
 var checkUserTest = newUserReg.getUser(username.value, 
 password.value);
 
 if (checkUserTest != null) {
 cocoon.session.setAttribute(user, checkUserTest);
 success = true;
 }else{
 username.setValidationError(new 
 Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
 password.setValidationError(new 
 Packages.org.apache.cocoon.forms.validation.ValidationError(The password, 
 username combination does not exist. Please enter another one., false));
 success = false;
 }
 } catch (e) {
 username.setValidationError(new 
 Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
 password.setValidationError(new 
 Packages.org.apache.cocoon.forms.validation.ValidationError(e., false));
 success = false;
 }
 return success;
 /fd:javascript
 /fd:validation
 I am getting an error message when the line 
 'cocoon.session.setAttribute(user, checkUserTest)' is hit.:
 ReferenceError: cocoon is not defined
 What is the issue here, can I create a session object from within form 
 validation/javascript in another way?
 Andrew

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Releasing 2.2beta1


Carsten Ziegeler skrev:

Reinhard Poetz schrieb:

Carsten Ziegeler wrote:

Reinhard Poetz wrote


I have just committed it but didn't update SitemapLanguage.java accordingly.


A brief look reveals that you do not support all lifecycle interfaces.
Aren't SingleThreaded and ThreadSafe enough. We should consider making the node 
builders normal Java classes as the historical reasons are not valid any more 
(see Sylvain's mail).



Yes, sure, but currently they are not, the new VPCnodes for example use
Contextualize (don't know why).


To have some mechanism to register the VPCs relative to a certain 
sitemap so that they can be looked up in the current sitemap or sub 
sitemaps through the current context.


A better idea would be to make the VPCs ordinary components, so that we 
don't need any special VPC sitemap nodes at all.


/Daniel

Re: [2.2] Configuration issues

Ralph Goers skrev:

Daniel Fagerstrom wrote:

Carsten Ziegeler skrev:

This is already the way it works in both 2.1 and 2.2. Cocoon provides
values for everything in property files within the block. The user can
then provide their own values which override them. I think Carsten is
simply worried because there are a lot of values you can specify.

No, I meant something different than the mechanism today, something that
works like the PropertyOverrideConfigurer in Spring. Say that you have a
configuration file like:

store logger=core.store
parameter name=maxobjects value=1000/
parameter name=use-cache-directory value=true/
/store

Then my idea was that you should be able to override the maxobjects
property by just providing a property:

store.maxobjects=2000

The mechanism of today is more like the PropertyPlaceholderConfigurer in
Spring and would require you to rewrite the configuration file like:

store logger=core.store
parameter name=maxobjects value=${store.maxobjects}/
parameter name=use-cache-directory
value=${store.use-cache-directory}/

/store

and provide default property files for all properties.

/Daniel

Re: [2.2] Configuration issues


Carsten Ziegeler skrev:

Daniel Fagerstrom wrote:

Here the IMO best and most natural solution is to have different blocks 
for different implementations. Say we have two different components that 
implements the XsltProcessor inteface, the Xalan and the Saxon 
implementation. Then if you have a Xalan block with its own embedded 
configuration and a Saxon block with its own embedded configuration. If 
you want to use the Xalan implementation you deploy the Xalan block and 
if you want the Saxon implementation you deply the Saxon block.


The result of this thinking is that you have typically smaller and more 
focused blocks, that contain components that are used togerther.


WDYT?

I'm not sure - on the one hand you're probably right. But this will lead
to too many blocks. If you think this through, this will require that
you make for each and every component an own block just to be able to
use a different implementation.


Might be, we maybe need some mechanism so that one can override a 
complete component configuration, not just its properties.


OTH, we have lots of components that wouldn't need to be components at 
all or at least not be replaceable. Also some blocks are far to fat, the 
core contains more than 100 components, while I would guess that most 
users only use a handful components from core. In many cases having 
blocks that implements a set of interfaces that works together, and 
being able to change the block to another one that implements the same 
interfaces, is a convenient way to switch implementation. It also keep 
the application lean.


/Daniel

Re: [2.2] Configuration issues

2006-05-17 Thread Ralph Goers


Daniel Fagerstrom wrote:

No, I meant something different than the mechanism today, something 
that works like the PropertyOverrideConfigurer in Spring. Say that you 
have a configuration file like:


  store logger=core.store
parameter name=maxobjects value=1000/
parameter name=use-cache-directory value=true/
  /store

Then my idea was that you should be able to override the maxobjects 
property by just providing a property:


store.maxobjects=2000

The mechanism of today is more like the PropertyPlaceholderConfigurer 
in Spring and would require you to rewrite the configuration file like:


  store logger=core.store
parameter name=maxobjects value=${store.maxobjects}/
parameter name=use-cache-directory 
value=${store.use-cache-directory}/

  /store

and provide default property files for all properties.


Oh, OK. But we also support

   component-instance name=javascript 
class=org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter
 
load-on-startupresource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js/load-on-startup

 reload-scripts${javascript.reload-scripts}/reload-scripts
 check-time${javascript.check-time}/check-time
   /component-instance

Would this be replaced by

javascript.reload-scripts = true

i.e., How does it know when to look for attributes versus the value of 
child elements? Or would it just assume you won't have an attribute with 
the same name as a child element?


I'm actually surprised that the syntax for your example isn't

store.parameter.maxobjects = 2000.

But I've never looked into this feature in Spring.

Ralph

Re: [2.2] Configuration issues


Peter Hunsberger skrev:

On 5/17/06, Daniel Fagerstrom [EMAIL PROTECTED] wrote:

snip/


 2. This works only as long as the user wants to use the same
 implementation for a component. Switching to an own implementation with
 an own configuration is not possible.

 Any idea on how to solve this?
Here the IMO best and most natural solution is to have different blocks
for different implementations. Say we have two different components that
implements the XsltProcessor inteface, the Xalan and the Saxon
implementation. Then if you have a Xalan block with its own embedded
configuration and a Saxon block with its own embedded configuration. If
you want to use the Xalan implementation you deploy the Xalan block and
if you want the Saxon implementation you deply the Saxon block.


Would this solution be able to deal with using both Saxon and Xalan or
two different versions of Saxon at different points in the same
pipeline?  In our case we have 1 critical XSLT that currently only
runs under Saxon 6 (I've tried repeatedly to get it to Saxon 8, but so
far no go).  Everything else exploits XSLT 2.0 and requires Saxon 8.
We mix these XSLT in the same pipelines all the time...


No, XSLT processors was a rather bad example as they not are 
interchangeable even if they implement the same interface.


In OSGi service is registred with the interfaces that it implements and 
optionally with a map with properties. A service can be looked up based 
on its interfaces and optionally with an LDAP style filter on the 
property map.


So in the above example, both implementations would be registered as 
XsltProcessors, then could also have properties describing vendor name 
and version.


A component that can do with any XsltProcessor would just lookup the 
XSLT service based on the interface. While a component with special 
needs would use a filter that describe version range and/or vendor. I 
don't know if anything like this would be possible with Spring.


/Daniel

Re: [2.2] Configuration issues


Ralph Goers skrev:

Daniel Fagerstrom wrote:

No, I meant something different than the mechanism today, something 
that works like the PropertyOverrideConfigurer in Spring. Say that you 
have a configuration file like:


  store logger=core.store
parameter name=maxobjects value=1000/
parameter name=use-cache-directory value=true/
  /store

Then my idea was that you should be able to override the maxobjects 
property by just providing a property:


store.maxobjects=2000

The mechanism of today is more like the PropertyPlaceholderConfigurer 
in Spring and would require you to rewrite the configuration file like:


  store logger=core.store
parameter name=maxobjects value=${store.maxobjects}/
parameter name=use-cache-directory 
value=${store.use-cache-directory}/

  /store

and provide default property files for all properties.


Oh, OK. But we also support

   component-instance name=javascript 
class=org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter 

 
load-on-startupresource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js/load-on-startup 


 reload-scripts${javascript.reload-scripts}/reload-scripts
 check-time${javascript.check-time}/check-time
   /component-instance

Would this be replaced by

javascript.reload-scripts = true


It was just an example of a possible convention for using properties as 
paths in configuration files, I haven't tried to find a complete mapping 
yet.


But if we could find such a convention, it would save us the work to 
rewrite hundreds of configurations. So it would probably be worthwhile.


/Daniel

[jira] Created: (COCOON-1851) [CForms] fi:styling type=textarea/ throws NPE in BRANCH

[CForms] fi:styling type=textarea/ throws NPE in BRANCH
---

 Key: COCOON-1851
 URL: http://issues.apache.org/jira/browse/COCOON-1851
 Project: Cocoon
Type: Bug

  Components: Blocks: Forms  
Versions: 2.1.8
Reporter: Kaj Kandler
Priority: Critical


Hi there,
I'm using 2.1.8 and have trouble styling a form field as textarea.

 ft:widget id=question
fi:styling type=textarea rows=40 cols=10/
 /ft:widget

I'm getting a null pointer exception. Any ideas why? Does someone know a
solution?
---
java.lang.NullPointerException
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/stylesheets/video-page2xhtml.xsl
- 274:38

Failed to process pipeline
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/stylesheets/video-page2xhtml.xsl
- 274:38[TransformerException]
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
- 129:33map:serialize type=xml
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
- 415:41map:transform type=jx
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
- 414:47map:transform type=forms
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
- 410:81map:transform
file:/D:/M_Drive/cocoon-2.1.8/build/webapp/sitemap.xmap - 659:76
map:mount
resource://org/apache/cocoon/forms/flow/javascript/Form.js - 184:-1
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/forms/question_form.js
- 10:-1
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
- 422:35map:call
file:/D:/M_Drive/cocoon-2.1.8/build/webapp/sitemap.xmap - 659:76
---
org.apache.cocoon.ProcessingException: Failed to process pipeline
at [TransformerException] -
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/stylesheets/video-page2xhtml.xsl:274:38
at map:serialize type=xml -
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:129:33
at map:transform type=jx -
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:415:41
at map:transform type=forms -
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:414:47
at map:transform -
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:410:81
at map:mount -
file:/D:/M_Drive/cocoon-2.1.8/build/webapp/sitemap.xmap:659:76
at resource://org/apache/cocoon/forms/flow/javascript/Form.js:184:-1
at
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/forms/question_form.js:10:-1
at map:call -
file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:422:35
at map:mount -
file:/D:/M_Drive/cocoon-2.1.8/build/webapp/sitemap.xmap:659:76
at
org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:144)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.handleException(AbstractProcessingPipeline.java:951)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:582)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:183)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:480)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(ContainerNode.java:31)
at
org.apache.cocoon.components.treeprocessor.sitemap.TransformNode.invoke(TransformNode.java:84)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)
at

[jira] Commented: (COCOON-1851) [CForms] fi:styling type=textarea/ throws NPE in BRANCH

[ 
http://issues.apache.org/jira/browse/COCOON-1851?page=comments#action_12412269 
] 

Kaj Kandler commented on COCOON-1851:
-

Here is my hack for the Null Pointer Exceptions.

EffectWidgetReplacingPipe.java
 line 973 ---
if (elementNesting == 0  styling != null) {
styling.toSAX(getContentHandler());
}
-
EffectPipe.java
 line 487 ---
locators.addFirst(locator);
if (locator != null) {
locator = new LocatorImpl(locator);
}
this.buffer = new SaxBuffer();
-

I'm not sure this is the best or correct fix. At least it works for me
for now. It appears that under certain circumstances, the buffers don't
get put in the list and the locations neither. I guess the real issue is
 someplace else and needs to be fixed by someone more knowledgeable.

Hope this helps someone else.

Kaj
P.S.: See full modified *.java files attached (originals release 2.1.8)

 [CForms] fi:styling type=textarea/ throws NPE in BRANCH
 ---

  Key: COCOON-1851
  URL: http://issues.apache.org/jira/browse/COCOON-1851
  Project: Cocoon
 Type: Bug

   Components: Blocks: Forms
 Versions: 2.1.8
 Reporter: Kaj Kandler
 Priority: Critical
  Attachments: EffectPipe.java, EffectWidgetReplacingPipe.java

 Hi there,
 I'm using 2.1.8 and have trouble styling a form field as textarea.
  ft:widget id=question
   fi:styling type=textarea rows=40 cols=10/
  /ft:widget
 I'm getting a null pointer exception. Any ideas why? Does someone know a
 solution?
 ---
 java.lang.NullPointerException
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/stylesheets/video-page2xhtml.xsl
 - 274:38
 Failed to process pipeline
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/stylesheets/video-page2xhtml.xsl
 - 274:38  [TransformerException]
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
 - 129:33  map:serialize type=xml
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
 - 415:41  map:transform type=jx
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
 - 414:47  map:transform type=forms
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
 - 410:81  map:transform
 file:/D:/M_Drive/cocoon-2.1.8/build/webapp/sitemap.xmap - 659:76  
 map:mount
 resource://org/apache/cocoon/forms/flow/javascript/Form.js - 184:-1
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/forms/question_form.js
 - 10:-1
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
 - 422:35  map:call
 file:/D:/M_Drive/cocoon-2.1.8/build/webapp/sitemap.xmap - 659:76
 ---
 org.apache.cocoon.ProcessingException: Failed to process pipeline
   at [TransformerException] -
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/stylesheets/video-page2xhtml.xsl:274:38
   at map:serialize type=xml -
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:129:33
   at map:transform type=jx -
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:415:41
   at map:transform type=forms -
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:414:47
   at map:transform -
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:410:81
   at map:mount -
 file:/D:/M_Drive/cocoon-2.1.8/build/webapp/sitemap.xmap:659:76
   at resource://org/apache/cocoon/forms/flow/javascript/Form.js:184:-1
   at
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/forms/question_form.js:10:-1
   at map:call -
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:422:35
   at map:mount -
 file:/D:/M_Drive/cocoon-2.1.8/build/webapp/sitemap.xmap:659:76
   at
 org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:144)
   at
 org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.handleException(AbstractProcessingPipeline.java:951)
   at
 org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:582)
   at
 org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:183)
   at
 org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:480)
   at
 org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120)
   at
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
   at
 org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(ContainerNode.java:31)
   at

[jira] Updated: (COCOON-1851) [CForms] fi:styling type=textarea/ throws NPE in BRANCH

 [ http://issues.apache.org/jira/browse/COCOON-1851?page=all ]

Kaj Kandler updated COCOON-1851:


Attachment: EffectWidgetReplacingPipe.java

 [CForms] fi:styling type=textarea/ throws NPE in BRANCH
 ---

  Key: COCOON-1851
  URL: http://issues.apache.org/jira/browse/COCOON-1851
  Project: Cocoon
 Type: Bug

   Components: Blocks: Forms
 Versions: 2.1.8
 Reporter: Kaj Kandler
 Priority: Critical
  Attachments: EffectPipe.java, EffectWidgetReplacingPipe.java

 Hi there,
 I'm using 2.1.8 and have trouble styling a form field as textarea.
  ft:widget id=question
   fi:styling type=textarea rows=40 cols=10/
  /ft:widget
 I'm getting a null pointer exception. Any ideas why? Does someone know a
 solution?
 ---
 java.lang.NullPointerException
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/stylesheets/video-page2xhtml.xsl
 - 274:38
 Failed to process pipeline
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/stylesheets/video-page2xhtml.xsl
 - 274:38  [TransformerException]
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
 - 129:33  map:serialize type=xml
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
 - 415:41  map:transform type=jx
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
 - 414:47  map:transform type=forms
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
 - 410:81  map:transform
 file:/D:/M_Drive/cocoon-2.1.8/build/webapp/sitemap.xmap - 659:76  
 map:mount
 resource://org/apache/cocoon/forms/flow/javascript/Form.js - 184:-1
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/forms/question_form.js
 - 10:-1
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap
 - 422:35  map:call
 file:/D:/M_Drive/cocoon-2.1.8/build/webapp/sitemap.xmap - 659:76
 ---
 org.apache.cocoon.ProcessingException: Failed to process pipeline
   at [TransformerException] -
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/stylesheets/video-page2xhtml.xsl:274:38
   at map:serialize type=xml -
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:129:33
   at map:transform type=jx -
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:415:41
   at map:transform type=forms -
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:414:47
   at map:transform -
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:410:81
   at map:mount -
 file:/D:/M_Drive/cocoon-2.1.8/build/webapp/sitemap.xmap:659:76
   at resource://org/apache/cocoon/forms/flow/javascript/Form.js:184:-1
   at
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/resources/forms/question_form.js:10:-1
   at map:call -
 file:/D:/M_Drive/WorkspaceCocoon/Plan-B4OOo/webapp/OpenOffice/sitemap.xmap:422:35
   at map:mount -
 file:/D:/M_Drive/cocoon-2.1.8/build/webapp/sitemap.xmap:659:76
   at
 org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:144)
   at
 org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.handleException(AbstractProcessingPipeline.java:951)
   at
 org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:582)
   at
 org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:183)
   at
 org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:480)
   at
 org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120)
   at
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
   at
 org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(ContainerNode.java:31)
   at
 org.apache.cocoon.components.treeprocessor.sitemap.TransformNode.invoke(TransformNode.java:84)
   at
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
   at
 org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
   at
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
   at
 org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142)
   at
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
   at

[jira] Updated: (COCOON-1851) [CForms] fi:styling type=textarea/ throws NPE in BRANCH