Re: Use Maven 2 for the generation of the Cocoon documentation
Bruno Dumon wrote:
OTOH, having the docs
split up between a lot of little maven-sites might lessen the overview.
Because of the nature of Daisy this shouldn't become a problem:
- we can have one navigation document which is a collection of all
block navigation docs
- we have Daisy books
- if that's not enough, we can refer to the same document from different
navigation docs
--
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: Status of block development
* Reinhard Poetz: For those of you, who think that blocks will never get finished - here a short list on our achievments so far: - splitting up of the monolytic Cocoon core has started by Daniel's refactorings - we use Spring as component framework and finally got rid of ECM, Avalon, etc. - sitemap blocks are working - block deployment is working - trunk is mavenized - virtual sitemap components - we defined the directory structure of blocks - ... and probably I've forgotten this or that important point ;-) Thanks for this explanation, I have a few questions though. - [cocoon-deployer-webapp-sample] is a very simple example. Here we need something more useful. We have to identify blocks that we want to show. I suggest # cforms + samples # ctemplate + samples # auth + samples # session-fw + samples Don't you think we should provide all stable and not deprecated blocks? Except cforms all these blocks are not shared between 2.1 and changing cforms shouldn't be a big problem as the cforms directories are references from 2.1 on a very detailed level. Right? Can you elaborate what changes are required for CForms? * I introduced the new Maven goals - cocoon:deploy and - cocoon:deploy-war Both are based on the Maven war plugin. A demo can be found in [cocoon-deployer-webapp-sample]. As you can see, deployment is based on cocoon-deploy.xml. This file describes which blocks you want to deploy and how they are configured. These blocks are deployed to the webapplication. What (or where) is the schema of this file? What component is using this file? Why is there redundancy with pom.xml, both are referencing cocoon-default. What is cocoon-default? When I « mvn install » in cocoon-block-deployer/cocoon-deployer-webapp-sample, the generated webapp in target/demo does not contain sitemaps and other resources, only web.xml and jars, am I missing something? Before block deployment, the normal web app creation of the war plugin takes place which mainly consists of copying files from src/main/webapp to target/[finalName]. How to achieve this step? It seems it is not done automatically. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: Use Maven 2 for the generation of the Cocoon documentation
Bruno Dumon wrote: On Mon, 2006-03-06 at 18:39 +0100, Reinhard Poetz wrote: hepabolu wrote: Finally, adding the proposed plugin can always be added later without loosing the effort of the current setup. ok, that's right. Anyway, I can't do it myself now but if somebody is interested, I can help. Maybe some of the Daisy gurus here can comment on the idea itself? It shouldn't be too hard. If it is just for publishing, you don't even need the Daisy client libraries, being able to do a HTTP request is enough. Actually, I should correct my previous statement the Forrest plugin uses the http API not the Java client API. No need for the Java API at this stage. I'm not sure what the difficulties are that Ross refers too in reusing the navigation documents. A basic plugin can probably be created in a day (by an experienced Java/XSLT person). Actually, my comment was misleading, sorry. The difficulties are not with Daisy itself, rather with the fact that we need(e) to maintain the existing directory structures of the documents and the Daisy nav system didn't work in the same way as the old nav system. With the 2.2 docs there is no legacy structure to maintain so it will be much easier. Ross
Re: Use Maven 2 for the generation of the Cocoon documentation
On Tue, 2006-03-07 at 09:06 +0100, Reinhard Poetz wrote: Bruno Dumon wrote: OTOH, having the docs split up between a lot of little maven-sites might lessen the overview. Because of the nature of Daisy this shouldn't become a problem: - we can have one navigation document which is a collection of all block navigation docs - we have Daisy books - if that's not enough, we can refer to the same document from different navigation docs Yes indeed, we can republish the same content in different ways. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
[jira] Assigned: (COCOON-1793) [PATCH] Enum selection list with apache enum support and null-text
[ http://issues.apache.org/jira/browse/COCOON-1793?page=all ] Ugo Cei reassigned COCOON-1793: --- Assign To: Ugo Cei [PATCH] Enum selection list with apache enum support and null-text -- Key: COCOON-1793 URL: http://issues.apache.org/jira/browse/COCOON-1793 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Assignee: Ugo Cei Attachments: enumselectionlist-samples.diff, enumselectionlist.diff Added support for apache enum in the EnumSelectionList. This will grant selection list items order on those JREs (expecially IBM, used by WebSphere) that will honor litteraly the Class.getDeclaredFields() javadocs and return elements in random order. This also adds the ability to implement the getEnumList method in the enum classes and implement a custom order. In case it isn't possible to retrieve a valid iterator for the apache enum, then the common way will be used. Since i felt the lack of it, i also added a null-text=i18nkey so that it's now possible to specify a label for the null element when the selection list is nullable=true. The second patch updates the samples adding a PreferredContact apache enum to the Contact bean, the form2 files (both for bean and xml binding) and messages, to demostrate the usage of both apache enum and the new null-text. -- 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-1793) [PATCH] Enum selection list with apache enum support and null-text
[ http://issues.apache.org/jira/browse/COCOON-1793?page=comments#action_12369188 ] Ugo Cei commented on COCOON-1793: - Looks like you forgot to add the PreferredContact class to your patch (forgot to svn add, maybe?). [PATCH] Enum selection list with apache enum support and null-text -- Key: COCOON-1793 URL: http://issues.apache.org/jira/browse/COCOON-1793 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Attachments: enumselectionlist-samples.diff, enumselectionlist.diff Added support for apache enum in the EnumSelectionList. This will grant selection list items order on those JREs (expecially IBM, used by WebSphere) that will honor litteraly the Class.getDeclaredFields() javadocs and return elements in random order. This also adds the ability to implement the getEnumList method in the enum classes and implement a custom order. In case it isn't possible to retrieve a valid iterator for the apache enum, then the common way will be used. Since i felt the lack of it, i also added a null-text=i18nkey so that it's now possible to specify a label for the null element when the selection list is nullable=true. The second patch updates the samples adding a PreferredContact apache enum to the Contact bean, the form2 files (both for bean and xml binding) and messages, to demostrate the usage of both apache enum and the new null-text. -- 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] Updated: (COCOON-1793) [PATCH] Enum selection list with apache enum support and null-text
[ http://issues.apache.org/jira/browse/COCOON-1793?page=all ] Simone Gianni updated COCOON-1793: -- Attachment: enumselectionlist-samples2.diff Yeah, right, forgot svn add :) this is the patch for it. [PATCH] Enum selection list with apache enum support and null-text -- Key: COCOON-1793 URL: http://issues.apache.org/jira/browse/COCOON-1793 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Assignee: Ugo Cei Attachments: enumselectionlist-samples.diff, enumselectionlist-samples2.diff, enumselectionlist.diff Added support for apache enum in the EnumSelectionList. This will grant selection list items order on those JREs (expecially IBM, used by WebSphere) that will honor litteraly the Class.getDeclaredFields() javadocs and return elements in random order. This also adds the ability to implement the getEnumList method in the enum classes and implement a custom order. In case it isn't possible to retrieve a valid iterator for the apache enum, then the common way will be used. Since i felt the lack of it, i also added a null-text=i18nkey so that it's now possible to specify a label for the null element when the selection list is nullable=true. The second patch updates the samples adding a PreferredContact apache enum to the Contact bean, the form2 files (both for bean and xml binding) and messages, to demostrate the usage of both apache enum and the new null-text. -- 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] Closed: (COCOON-1793) [PATCH] Enum selection list with apache enum support and null-text
[ http://issues.apache.org/jira/browse/COCOON-1793?page=all ] Ugo Cei closed COCOON-1793: --- Fix Version: 2.1.9-dev (current SVN) Resolution: Fixed Applied. Please cross-check. [PATCH] Enum selection list with apache enum support and null-text -- Key: COCOON-1793 URL: http://issues.apache.org/jira/browse/COCOON-1793 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Assignee: Ugo Cei Fix For: 2.1.9-dev (current SVN) Attachments: enumselectionlist-samples.diff, enumselectionlist-samples2.diff, enumselectionlist.diff Added support for apache enum in the EnumSelectionList. This will grant selection list items order on those JREs (expecially IBM, used by WebSphere) that will honor litteraly the Class.getDeclaredFields() javadocs and return elements in random order. This also adds the ability to implement the getEnumList method in the enum classes and implement a custom order. In case it isn't possible to retrieve a valid iterator for the apache enum, then the common way will be used. Since i felt the lack of it, i also added a null-text=i18nkey so that it's now possible to specify a label for the null element when the selection list is nullable=true. The second patch updates the samples adding a PreferredContact apache enum to the Contact bean, the form2 files (both for bean and xml binding) and messages, to demostrate the usage of both apache enum and the new null-text. -- 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] Updated: (COCOON-1707) Allow configuration of initial context in LDAPTransformer
[ http://issues.apache.org/jira/browse/COCOON-1707?page=all ] Jean-Baptiste Quenot updated COCOON-1707: - Attachment: 20060307-cocoon-ldaptr Proposed patch Allow configuration of initial context in LDAPTransformer - Key: COCOON-1707 URL: http://issues.apache.org/jira/browse/COCOON-1707 Project: Cocoon Type: Improvement Components: Blocks: Naming Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: 20051212-naming-LDAPTransformer, 20060307-cocoon-ldaptr LDAPTransformer does not currently provide a way to specify the attributes in the initial context. Credit goes to Sébastien Grimault [EMAIL PROTECTED] -- 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] Updated: (COCOON-1707) Allow configuration of initial context in LDAPTransformer
[ http://issues.apache.org/jira/browse/COCOON-1707?page=all ] Jean-Baptiste Quenot updated COCOON-1707: - Attachment: (was: 20060307-cocoon-ldaptr) Allow configuration of initial context in LDAPTransformer - Key: COCOON-1707 URL: http://issues.apache.org/jira/browse/COCOON-1707 Project: Cocoon Type: Improvement Components: Blocks: Naming Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: 20051212-naming-LDAPTransformer, 20060307-cocoon-ldaptr LDAPTransformer does not currently provide a way to specify the attributes in the initial context. Credit goes to Sébastien Grimault [EMAIL PROTECTED] -- 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] Updated: (COCOON-1707) Allow configuration of initial context in LDAPTransformer
[ http://issues.apache.org/jira/browse/COCOON-1707?page=all ] Jean-Baptiste Quenot updated COCOON-1707: - Attachment: 20060307-cocoon-ldaptr Updated patch Allow configuration of initial context in LDAPTransformer - Key: COCOON-1707 URL: http://issues.apache.org/jira/browse/COCOON-1707 Project: Cocoon Type: Improvement Components: Blocks: Naming Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: 20051212-naming-LDAPTransformer, 20060307-cocoon-ldaptr LDAPTransformer does not currently provide a way to specify the attributes in the initial context. Credit goes to Sébastien Grimault [EMAIL PROTECTED] -- 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] Created: (COCOON-1794) [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding
[PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding - Key: COCOON-1794 URL: http://issues.apache.org/jira/browse/COCOON-1794 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Suzan Foster Attachments: repeater-binding-patch.txt This patch corrects the following issues: - Namespaced back-end XML model not correctly binding to the repeaters child widgets. - Nodes bound to row widgets not being reordered according to row position on save. Files affected: - JXPathBindingBase: - member applyLeniency changed from private to protected. - member applyNSDeclarations changed from private to protected. - RepeaterJXPathBinding: - constructor changed for passing a binding for moveRow. - applyLeniency and applyNSDeclarations applied to created relative contexts. - member moveRowBinding added. - method getMoveRowBinding added. - doSave changed to incorporate the use of moveRowBinding. - RepeaterJXPathBindingBuilder: - buildBinding changed to incorporate the construction of moveRowBinding. Files added: - MoveNodeJXPathBinding. - MoveNodeJXPathBindingBuilder. -- 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: Status of block development
Jean-Baptiste Quenot wrote:
* Reinhard Poetz:
- [cocoon-deployer-webapp-sample] is a very simple example. Here we need
something more useful. We have to identify blocks that we want
to show. I suggest
# cforms + samples
# ctemplate + samples
# auth + samples
# session-fw + samples
Don't you think we should provide all stable and not deprecated blocks?
yes, but IMO not in the first run. We only have very little experience with the
complete blocks idea and therefore we should work incrementally. (e.g. if the
block.xml is changing, you have to update it for *all* blocks and it's a
difference if you do it for a handful or for 100+ files)
Except cforms all these blocks are not shared between 2.1 and changing
cforms shouldn't be a big problem as the cforms directories are
references from 2.1 on a very detailed level. Right?
Can you elaborate what changes are required for CForms?
The directory structure of blocks is different. See
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-block-deployer/cocoon-deployer-plugin-demo/src/
which already uses the new one. In the archives you find some threads about
the reasons that led to it.
* I introduced the new Maven goals
- cocoon:deploy and
- cocoon:deploy-war
Both are based on the Maven war plugin. A demo can be found in [cocoon-deployer-webapp-sample]. As you can see,
deployment is based on cocoon-deploy.xml. This file describes which blocks you want to deploy and how they are
configured. These blocks are deployed to the webapplication.
What (or where) is the schema of this file?
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-block-deployer/cocoon-deployer-core/src/main/resources/xsd/deploy-schema-1.0.xsd
What component is
using this file?
the block-deployer
(http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-block-deployer)
Why is there redundancy with pom.xml, both are
referencing cocoon-default. What is cocoon-default?
pom.xml describes which artifacts are required to build a project. The
difference is, that block.xml describes which requirements in the form of other
blocks a block has but *doesn't* say anything about conrecte implementations.
In cocoon-deploy.xml you can define which _concrete_ blocks that *you* in the
role of the deployer want to use to satisfy a requirement.
ad cocoon-default: this is a collection of blocks that are necessary to get a
minimal Cocoon. As this will be under heavy refactoring for some time (e.g.
cocoon-core will be split up in more parts), I introduced this module to make
the dependencies of depending blocks more stable.
When I « mvn install » i
cocoon-block-deployer/cocoon-deployer-webapp-sample, the generated
webapp in target/demo does not contain sitemaps and other
resources, only web.xml and jars, am I missing something?
No :-)
Have a look into WEB-INF/web.xml. It uses the BlocksManager as servlet, or IOW
as entry point into the Cocoon world. The BlocksManager sets up Cocoon by using
all the deployed blocks. The sitemaps that you're missing can be found in the
block directories (/blocks/[block]/COB-INF/sitemap.xmap). There is no such a
thing as a root sitemap anymore.
The configuration file of the BlocksManager is /WEB-INF/wiring.xml. It is
generated by the block deployer and contains all deployed blocks. A sitemap
block (= a block that has a COB-INF directory and a sitemap) can be mounted to
the managed URI-space. If a request hits the servlet (BlocksManager), it looks
first if a block is mounted to the requested path and if yes, it delegates
processing to the block's controller (currently we only have the sitemap as
implementation, but here we have room for other ways)
Before block deployment, the normal web app creation of the war plugin takes place which mainly consists of copying
files from src/main/webapp to target/[finalName].
How to achieve this step? It seems it is not done automatically.
hmm, it works for me. The plugin would copy any content from within
./src/main/webapp to ./target/demo but ATM the only file that is copied is
web.xml (from ./src/main/webapp/WEB-INF/web.xml).
I did
mvn clean cocoon:deploy jetty6:run
and then I entered
http://localhost:/p1/test and
http://localhost:/p2/test
If I find some time today, I will extend the sample webapp by some more blocks.
--
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
[jira] Commented: (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?page=comments#action_12369260 ] Max Pfingsthorn commented on COCOON-1794: - This is an interesting topic. However, retrospectively moving the rows around doesn't seem to be the best way to solve this. Instead, the InsertNodeJXPathBinding should know to insert a node after another (or before). I'm having a look into it right now as we have the same problem. Additionally, we should try to stay backward compatible with the repeater definition and we shouldn't break being able to bind to beans. Keeping it consistent between XML and JavaBeans bindings might be a problem as beans don't support moving children around after they are added. And requiring a move binding which doesn't exist for beans of course makes the repeater unusable for that case. I would put some XML specific code in to the RepeaterJXPathBinding if the insertBinding is a InsertNodeJXPathBinding. That way, we can ensure the relative AND absolute positioning of the XML elements created by the binding. By absolute I mean this: We often use the repeater without an enclosing context for each row. New rows will always end up in the end of the document (or enclosing element), not after the bulk of other rows, which can be a big problem if you need to validate the resulting xml. So, I'll be working on some specific hacks to make this work for XML and not break it for beans without influencing the configs. [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding - Key: COCOON-1794 URL: http://issues.apache.org/jira/browse/COCOON-1794 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Suzan Foster Attachments: repeater-binding-patch.txt This patch corrects the following issues: - Namespaced back-end XML model not correctly binding to the repeaters child widgets. - Nodes bound to row widgets not being reordered according to row position on save. Files affected: - JXPathBindingBase: - member applyLeniency changed from private to protected. - member applyNSDeclarations changed from private to protected. - RepeaterJXPathBinding: - constructor changed for passing a binding for moveRow. - applyLeniency and applyNSDeclarations applied to created relative contexts. - member moveRowBinding added. - method getMoveRowBinding added. - doSave changed to incorporate the use of moveRowBinding. - RepeaterJXPathBindingBuilder: - buildBinding changed to incorporate the construction of moveRowBinding. Files added: - MoveNodeJXPathBinding. - MoveNodeJXPathBindingBuilder. -- 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: Status of block development
Jean-Baptiste Quenot wrote:
snip/
In cocoon-deploy.xml you can define which _concrete_ blocks that
*you* in the role of the deployer want to use to satisfy a
requirement.
So if we write an Eclipse plugin to configure deployment, we will
have to edit both cocoon-deploy.xml and pom.xml?
No, fortunatly not. cocoon-deployer-webapp-sample/pom.xml only has a dependency
on cocoon-default to make the Jetty plugin happy. For some reason the servlet
needs to be in the Maven classpath when the plugin is executed.
If you're working on a *single block*, you can use *cocoon:simple-deploy* which
doesn't need a cocoon-deploy.xml. Checkout the first block tutorial to learn more.
Just curious,
is it possible to skip cocoon-deploy.xml if we don't have
polymorphism nor inheritance?
I don't think so as there are more differences between dependencies in Cocoon
and Maven 2. We additionally want to
- give a dependency an ID (needed for the block protocol)
- want to set properties at deployment time
- want to deploy one block several times (e.g. to different mount-points
or with different parameters)
- point to paths instead of artifacts (for RAD)
Any of these points is supported by Maven. Maybe we can work on getting our
wishes fullfilled by the Maven community in the long run, but I don't have the
energy to do it right now and as said, we have to learn more about what we need
before we ask to change a released contract like pom.xml IMHO.
Do we necessarily need something
more than the Maven infrastructure at the moment?
IMHO yes. I don't know if *we* need it. I just can speak for myself when I say
that *I* need it (see the reasons about + block polymorphism is a must for my
use cases). I've been patient enough for more than 2 years to get real blocks
and I don't want to cut the concept just because we need another 2 months to
become 'feature complete' or because Maven is different.
skip/
And it's quick! Thanks for your work.
Thanks for testing!
--
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
Problems with tree buiilder
I updated SVN and tried to run the block deployment samples
(cocoon-deployer-webapp-sample or cocoon-deployer-plugin-demo) and get the
following stacktrace:
25336 [BoundedThreadPool0-1] WARN org.mortbay.log - /p1/test
org.apache.avalon.framework.configuration.ConfigurationException: Could not load
TreeBuilder configuration from resource
://org/apache/cocoon/components/treeprocessor/sitemap-language.xml
at
org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage.build(SitemapLanguage.java:423)
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:324)
at
org.apache.cocoon.core.container.handler.PoolableComponentHandler$ProxyHandler.invoke(PoolableComponentHandle
r.java:155)
at $Proxy1.build(Unknown Source)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.buildConcreteProcessor(TreeProcessor.java:405)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.setupConcreteProcessor(TreeProcessor.java:340)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:241)
at
org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:161)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
at
org.apache.cocoon.blocks.servlet.BlockManager.service(BlockManager.java:158)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
at
org.apache.cocoon.blocks.BlocksContext$PathDispatcher.forward(BlocksContext.java:178)
at
org.apache.cocoon.blocks.servlet.BlocksManager.service(BlocksManager.java:233)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:423)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:350)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:195)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:164)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:536)
at org.mortbay.jetty.Server.handle(Server.java:309)
at org.mortbay.jetty.Server.handle(Server.java:285)
at org.mortbay.jetty.HttpConnection.doHandler(HttpConnection.java:364)
at org.mortbay.jetty.HttpConnection.access$1600(HttpConnection.java:46)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:612)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:485)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:194)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:298)
at
org.mortbay.jetty.nio.SelectChannelConnector$HttpEndPoint.run(SelectChannelConnector.java:710)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:412)
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.get(ArrayList.java:326)
at
org.apache.cocoon.environment.internal.EnvironmentHelper.getSitemapServiceManager(EnvironmentHelper.java:396)
at
org.apache.cocoon.components.source.CocoonSourceResolver.getComponentLocator(CocoonSourceResolver.java:212)
at
org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(CocoonSourceResolver.java:140)
at
org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(CocoonSourceResolver.java:181)
at
org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage.build(SitemapLanguage.java:414)
... 31 more
Any ideas?
--
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
FOP 0.91 Serializer
Hello everybody,
to get Apache FOP 0.91 beta working with Cocoon, a new Serializer is
necessary (the FOP API changed considerably). I wrote a very simple but
working Serializer and hope that helps a little for future releases of
Cocoon. The Serializer doesn't accept any configuration except 'mime-type'
yet.
Best regards,
Alexander
snip
package org.apache.cocoon.serialization;
import org.apache.fop.apps.Fop;
import java.io.OutputStream;
import java.io.Serializable;
import javax.xml.parsers.SAXParserFactory;
import org.apache.avalon.framework.configuration.Configurable;
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;
import org.apache.avalon.framework.logger.Logger;
import org.apache.avalon.framework.service.ServiceException;
import org.apache.avalon.framework.service.ServiceManager;
import org.apache.avalon.framework.service.Serviceable;
import org.apache.cocoon.caching.CacheableProcessingComponent;
import org.apache.excalibur.source.SourceValidity;
import org.apache.fop.apps.FOUserAgent;
import org.xml.sax.helpers.DefaultHandler;
public class FOP091Serializer
extends AbstractSerializer
implements
Configurable, CacheableProcessingComponent, Serviceable/*, Disposable */ {
protected Logger logger;
protected String mimetype;
protected boolean setContentLength = true;
protected FOUserAgent userAgent = null;
protected Fop fop = null;
protected ServiceManager manager;
protected javax.xml.transform.stream.StreamResult res = null;
public void service( ServiceManager manager )
throws ServiceException {
this.manager = manager;
}
public void configure( Configuration conf )
throws ConfigurationException {
this.logger = getLogger().getChildLogger( fop );
this.setContentLength =
conf.getChild( set-content-length
).getValueAsBoolean( true );
String configUrl =
conf.getChild( user-config ).getValue( null );
this.mimetype = conf.getAttribute( mime-type );
// TODO get and use user configuration
// TODO get and use user's renderer definition, ...
}
public String getMimeType() {
return this.mimetype;
}
public void setOutputStream( OutputStream o ) {
DefaultHandler dh = null;
fop = new Fop( this.mimetype );
fop.setOutputStream( o );
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware( true );
try {
dh = fop.getDefaultHandler();
setContentHandler( dh );
} catch( Exception ex) {
; // TODO FIXME
}
}
public Serializable getKey() {
return 0;
}
public SourceValidity getValidity() {
return null; //NOPValidity.SHARED_INSTANCE;
}
public void recycle() {
super.recycle();
this.userAgent = null;
this.fop = null;
}
public boolean shouldSetContentLength() {
return this.setContentLength;
}
}
snip
Re: FOP 0.91 Serializer
Please add it to our issue tracker Jira at https://issues.apache.org/jira/browse/COCOON for organizational and especially legal reasons. Thanks. Jörg On 07.03.2006 19:52, Alexander Lochschmied wrote: Hello everybody, to get Apache FOP 0.91 beta working with Cocoon, a new Serializer is necessary (the FOP API changed considerably). I wrote a very simple but working Serializer and hope that helps a little for future releases of Cocoon. The Serializer doesn't accept any configuration except 'mime-type' yet. Best regards, Alexander
[jira] Commented: (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?page=comments#action_12369295 ] Suzan Foster commented on COCOON-1794: -- I don't think the InsertNodeJXPathBinding is the correct place to implement positioning. Positioning doesn't imply insertion as an existing row can be freely repositioned. This means that it is perfectly sane to have a repeater which doesn't define an insertion method but does define a positioning method. The proposal is exactly the same approach as used for both on-insert-row and on-delete-row, so seemd the most logical to implement. [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding - Key: COCOON-1794 URL: http://issues.apache.org/jira/browse/COCOON-1794 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Suzan Foster Attachments: repeater-binding-patch.txt This patch corrects the following issues: - Namespaced back-end XML model not correctly binding to the repeaters child widgets. - Nodes bound to row widgets not being reordered according to row position on save. Files affected: - JXPathBindingBase: - member applyLeniency changed from private to protected. - member applyNSDeclarations changed from private to protected. - RepeaterJXPathBinding: - constructor changed for passing a binding for moveRow. - applyLeniency and applyNSDeclarations applied to created relative contexts. - member moveRowBinding added. - method getMoveRowBinding added. - doSave changed to incorporate the use of moveRowBinding. - RepeaterJXPathBindingBuilder: - buildBinding changed to incorporate the construction of moveRowBinding. Files added: - MoveNodeJXPathBinding. - MoveNodeJXPathBindingBuilder. -- 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: Problems with tree buiilder
Reinhard Poetz wrote: I updated SVN and tried to run the block deployment samples (cocoon-deployer-webapp-sample or cocoon-deployer-plugin-demo) and get the following stacktrace: Any ideas? Yupp :) This is due to a change I did last week; the change is not finished as I wanted to discuss possible solutions first here in the list but didn't have time yet... Now, the problem is that the code is trying to get the current bean factory of the sitemap while the sitemap is constructed. With the old core, we have a fallback with the Cocoon class which calls the enterEnvironment() method. I guess in the case of the blocks-fw you don't have this fallback. So the workaround should be to call enterEnvironment somewhere and but the root processor with the root bean factory on the stack. The problem I wanted to discuss is where to store the current bean factory. Currently I added a getBeanFactory() method to the Processor interface, allowing each and every processor to have an own bean factory. An alternative would be to have this outside the processor and have a processor manager kind of a class which stores the corresponding bean factory for a processor (if it has one). I think both solutions make sense. While the first one is easier to implement, the second one is cleaner as it separates the concerns better. So which way do we want to proceed? Or is there a better option? With these changes I'm trying to reduce the impact of the internal pipeline handling as much as possible. In the optimum case we are able to remove the environment stack handling completly or at least make it as small as possible. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
