Re: Cocoon server not responding
If someone can put me in the sudoers list i'ld be happy to do this. Bertrand Delacretaz wrote: Le 11 déc. 05, à 16:37, juan a écrit : ...Aparently there is some problem with your server. http://cocoon.zones.apache.org I'm tied today, it would be good if someone could restart the services according to https://svn.apache.org/repos/private/committers/pmc/cocoon/cocoon.zones.apache.org/admin-notes/howto-restart-zone.txt -Bertrand
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 12 December 08:02 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2005-12-12 08:02:08 ... 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: 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 init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: 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 files 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 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Thu Nov 24 11:07:14 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Sun Nov 27 03:07:04 GMT+00:00 2005 [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. fetch-plugin: [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 findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.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-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip [get] . [get] last modified = Wed Nov 16 13:07:07 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install fetchplugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins install-plugin: configure-plugin: configure-input-plugin: [echo] Mounting input plugin: org.apache.forrest.plugin.input.Daisy [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/input.xmap to
Re: m2 build broken?
Daniel Fagerstrom wrote: I'll talk to Upayavira, and see if we can take care about it. I saw that you had changed the Cocoon group id to org.apache.cocoon from apache-cocoon in the main pom and the core pom but nowhere else. What is your plane for this? Should we just start to change group id to org.apache.cocoon in all poms? The unofficial groupId policy from the maven ppl states that one should try to use a package based groupId ie org.apache.cocoon rather than just apache-cocoon. I'll see about getting our poms changed unless you beat me to it. Jorg
Re: Cocoon server not responding
On 12 Dec 2005, at 08:58, Jorg Heymans wrote: If someone can put me in the sudoers list i'ld be happy to do this. Done. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org
Re: ForrestBot build for cocoon-docs FAILED
[EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Log attached. ... Copying broken links file to site root. [copy] Copying 1 file to /var/apache2/htdocs/ft/build/cocoon-docs [echo] Oops, something broke Looks like something in Forrest has broken. Since it is nothing to do with Cocoon I'm redirecting notifications to te Forrest list until this is sorted. Ross
Re: Cocoon server not responding
Steven Noels wrote: On 12 Dec 2005, at 08:58, Jorg Heymans wrote: If someone can put me in the sudoers list i'ld be happy to do this. Done. hmmm, i thought that being in the sudoers list would allow me to run commands as root without having to enter the root password. It seems that this is not the case. so : can someone just restart the service or send me the root password in a secure way ? Jorg
Re: Cocoon server not responding
Le 12 déc. 05, à 10:23, Jorg Heymans a écrit : ...hmmm, i thought that being in the sudoers list would allow me to run commands as root without having to enter the root password. It seems that this is not the case To sudo you need to enter your own password, not root's. -Bertrand smime.p7s Description: S/MIME cryptographic signature
AW: How to connect Avalon Component and SessionListener
Yes, I read about that and tried to find out a bit more about
HTTPSessionBindingListener. However I don't quite get the store your
component as a session attribute-part.
1. I'm using my component in the pipline implementation. I assume you'd do
it some way like this (made it short):
ObjectModelHelper.getRequest(environment.getObjectModel()).getSession().setA
ttribute(mycomponent,component);
However, this would be called everytime the pipeline is processed, which
makes no sense. I might get this wrong though. If it was this way, it seems
easier to me to do it that way:
2.
session = ObjectModelHelper.getRequest(...).getSession();
if (session.isNew()) {
mycomponent.newSession(session.getId())
}
This leaves me with two problems:
Using 1. I does not seem to be able to store my component in a new session
ONCE, but anew with every request.
Using 2. I cannot track if a session has been destroyed.
Stefan
| -Ursprüngliche Nachricht-
| Von: Ralph Goers [mailto:[EMAIL PROTECTED]
| Gesendet: Sonntag, 11. Dezember 2005 18:49
| An: dev@cocoon.apache.org
| Betreff: Re: How to connect Avalon Component and SessionListener
|
|
|
| Stefan Pietschmann wrote:
|
| It's a new day and a new problem arises for me:
|
|
|
| I want to notify my Avalon component when a session is created or
| destroyed. I had previously written a simple HttpSessionListener which
| I declared in web.xml. sessionCreated() and sessionDestroyed() get
| invoked just as they should.
|
| Now what's the best practise to notify my component from there? These
| are the ideas I had:
|
|
|
| 1) Make the SessionListener a Serviceable Component itself, so
| it can use the ServiceManager to lookup my other component and invoke
| some method there.
|
| 2) Make my Avalon component a SessionListener itself (I don't
| think that's possible, is it? I added it to web.xml as listener class
| and cocoon.xconf as component, but the session methods were not invoked)
|
| 3) Keep both classes as they are and do it the right way ;) ?
|
|
|
| How would you go about this?
|
| I'd do it the way I have told folks before. Don't use
| HttpSessionListener. Make your component implement
| HttpSessionBindingListener. Then store your component as a session
| attribute. When the session is destroyed it will be notified. This
| doesn't require anything in web.xml.
|
| Ralph
Re: Cocoon server not responding
Bertrand Delacretaz wrote: Le 12 déc. 05, à 10:23, Jorg Heymans a écrit : ...hmmm, i thought that being in the sudoers list would allow me to run commands as root without having to enter the root password. It seems that this is not the case To sudo you need to enter your own password, not root's. services restarted! Jorg
[jira] Created: (COCOON-1706) Allow TeeTransformer tu run a system command for debugging purposes
Allow TeeTransformer tu run a system command for debugging purposes --- Key: COCOON-1706 URL: http://issues.apache.org/jira/browse/COCOON-1706 Project: Cocoon Type: Improvement Reporter: Jean-Baptiste Quenot Priority: Minor Attachments: 20051212-naming-TeeTransformer Hello, The TeeTransformer is great, but it would be still greater if it could run a system command every time it is invoked, to ease debugging of a Cocoon application. The system command can be eg vi, emacs, put your favorite editor here, so that every time the pipeline is executed, your editor pops up. Credit goes to Philippe Gassmann [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-1707) Allow configuration of initial context in LDAPTransformer
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 Priority: Minor Attachments: 20051212-naming-LDAPTransformer 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
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Hi, On 7 Dec 2005, at 23:26, Thomas Lutz wrote: Second argument: It was hard to explain, why I kicked struts out, and used cocoon instead. And it was even harder to explain that there is JavaScript in the server part. Managers who buy oracle don't like to hear things like this... To provide a counterpoint to this - we spoke with one large organisation that was really excited by being able to use JavaScript rather than Java, since it lowered the barrier to entry for some of their less-skilled developers and meant more people were able to work on the project. On 7 Dec 2005, at 14:23, Berin Loritsch wrote: What's your preference for the vision? [ ] All web apps written in JavaScript [ ] All web apps written in pure Java [X] Mix and match (not as simple, but is status quo with today) Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
[jira] Created: (COCOON-1708) Allow CopletInstanceDataManager to be cloneable
Allow CopletInstanceDataManager to be cloneable --- Key: COCOON-1708 URL: http://issues.apache.org/jira/browse/COCOON-1708 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Priority: Minor Attachments: 20051212-portal-AbstractAspectalizable, 20051212-portal-CopletInstanceDataManager CopletInstanceDataManager should be cloneable in order to load the coplets one time, and clone that object to provide a different copy for every user (using eg AuthenticationProfileManager). -- 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
Performance Issue / Class Loading by Rhino
Hi, after doing some profiling and analysis I have found that rhino is doing a lot of class loading which often fails. This is coming from NativeJavaPackage.java / getPkgProperty (a lot of ClassNotFoundException exceptions are thrown and catched there). This stems from references in a flow script to Java classes, ... Although there is a cache this does not prevent a lot of class loading (failing most of the time) for each new request (until the cache is filled anew). The originating call is in ContinuationInterpreter (ScriptRuntime.getProp). I am not sure how a real fix of this problem would look like. Nevertheless, I have made a naive fix for the problem (patch attached) that simply adds a cache to NativeJavaPackage. This resolved the issue for my test scenario and resulted in a great performance increase. When looking at the initial code I think there could be a more elegant solution (that does not need a secondary cache). Furthermore, I am not sure if my quick fix has side effects or not (e.g. when a huge number of classes is referenced of one and the same package). Has anybody else already encountered this issue and found a different solution? What do you think of my solution? Any other ideas / comments? Regards, Georg -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner NativeJavaPackage.java.diff Description: Binary data
[jira] Created: (COCOON-1709) Speedup portal loading
Speedup portal loading -- Key: COCOON-1709 URL: http://issues.apache.org/jira/browse/COCOON-1709 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow. This patch allows to cache the result for further invocations. However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets. Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable. An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles. Note that the key of the object is the URI returned by the source. This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map. -- 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-1710) Speedup portal loading
Speedup portal loading -- Key: COCOON-1710 URL: http://issues.apache.org/jira/browse/COCOON-1710 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow. This patch allows to cache the result for further invocations. However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets. Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable. An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles. Note that the key of the object is the URI returned by the source. This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map. -- 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-1711) [PATCH] correct position of help popup for tab styling
[PATCH] correct position of help popup for tab styling
--
Key: COCOON-1711
URL: http://issues.apache.org/jira/browse/COCOON-1711
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.1.9-dev (current SVN)
Reporter: Werner Masik
Priority: Minor
Attachments: forms-advanced-field-styling.xsl.diff
Help popups appear in the wrong position when the tab styling is used.
Usually it pops up below the div that contains the tabbed form, which means
that the popup is often outside of the visible viewing area.
Looks like the bug exists since the stylesheets of 2.1.7 and dev branch were
merged.
The problem is that the function forms_createPopupWindow does not get called
when
the page is loaded into the browser. In current 2.1.X branch the function gets
called
directly from the a href= ...
a
onclick=forms_createPopupWindow('email:help').showPopup('email:help:a');return
false; href=# name=email:help:a id=email:help:aimg alt=helppopup
src=resources/forms/img/help.gif/a
So the function is executed when then link to the popup is clicked.
In 2.1.7 it was called like this:
script type=text/javascript
var helpWinN1003B = forms_createPopupWindow('helpN1003B');
/script
a onclick=helpWinN1003B.showPopup('N1003B');return false; href=#
name=N1003B id=N1003Bimg alt=helppopup src=/images/help.gif/a
Here the popup window was created at the first display of the browser page.
Actually when in tab-styling the whole popup-tree was just copied right below
the body-tag because of the positioning issues. This was done
with the forms_moveInBody function which was called in the onload handler of
the forms.
Therefore 2 possible solutions exist:
- revert the code to the old version, to register the handler before the onload
is executed
- alter forms-advanced-field-styling.xsl so the divs for the popups are all
created as a child of the body tag
The patch I'm submitting takes the second aproach. All it does is create the
divs where they should be
from the beginning (below body). This is done by introducing a mode called
'forms-help', to make the fi:help
tags get processed twice. In the first run the divs are created and in the
second run links for the popups
are created just behind the field (as usual). Moving the divs with javascript
therefore becomes obsolete. I think
that registering the onloadHanlder to call forms_moveInBody can be removed. But
I was not sure if
it is needed for something else, so I kept it.
I'm not a XSLT expert. There might be a better way to process the help popups.
Feel free
to make corrections. I also have no experience with ajax. I tested it with ajax
activated
and it worked. But I'm not sure if my test was using ajax the right way.
--
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-1712) Speedup loading of profiles
Speedup loading of profiles --- Key: COCOON-1712 URL: http://issues.apache.org/jira/browse/COCOON-1712 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS When loading profiles (using eg AuthenticationProfileManager) portal parses the profiles using Castor, and this can be very slow. The attached patch caches the result in a HashMap for subsequent invocations to avoid loading them every time. Note that the key of the object in the map is source.getURI(), which may be different from the variable uri as resolveURI() may return the same result for different values of uri. This bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable, because coplet instances are cloned to ensure that every user gets its own copy of the coplets. -- 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-1710) Speedup portal loading
[ http://issues.apache.org/jira/browse/COCOON-1710?page=all ] Jean-Baptiste Quenot closed COCOON-1710: Resolution: Duplicate Speedup portal loading -- Key: COCOON-1710 URL: http://issues.apache.org/jira/browse/COCOON-1710 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow. This patch allows to cache the result for further invocations. However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets. Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable. An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles. Note that the key of the object is the URI returned by the source. This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map. -- 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-1712) Speedup loading of profiles
[ http://issues.apache.org/jira/browse/COCOON-1712?page=all ] Jean-Baptiste Quenot closed COCOON-1712: Resolution: Duplicate Speedup loading of profiles --- Key: COCOON-1712 URL: http://issues.apache.org/jira/browse/COCOON-1712 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS When loading profiles (using eg AuthenticationProfileManager) portal parses the profiles using Castor, and this can be very slow. The attached patch caches the result in a HashMap for subsequent invocations to avoid loading them every time. Note that the key of the object in the map is source.getURI(), which may be different from the variable uri as resolveURI() may return the same result for different values of uri. This bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable, because coplet instances are cloned to ensure that every user gets its own copy of the coplets. -- 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: Cocoon 2.2 - Build and deployment with Maven2
After working on the deployer and learning more about the Maven2 internals, I
want to share 2 thougths:
I've already raised the question whether it is possible to merge block.xml and
pom.xml. For now it's not as dependencies in pom.xml can't carry all the
necessary information for us. Maven 1.1 models had support for properties
elements, but they have been dropped in Maven 2.0 (Does anybody know the reason
for it?). I also mentioned my concerns about tieing us to closely to Maven.
I think the solution for this is very simple: Our contract is block.xml.
As soon as a Maven pom.xml can give us all the required information and people
use it as build descriptor, block.xml can be *automatically* generated for them
during the build lifecycle and they don't have to care for it anymore. People
that don't want to use Maven, have to provide a hand-crafted block.xml.
Going this way we are not blocked by getting the missing Maven features and
blocks don't get tied to Maven which would make a future replacement of Maven
very difficult.
- o -
A second thought: As outlined in one of my previous mails, a Cocoon block will
become a valid jar file, for example with following content:
ROOT
+-- block.xml
+-- pom.xml
+-- sitemap.xmap
+-- org
| +--myProject
| +-- MyJavaflowController.class
+-- app
+-- formTemplate.jx
+-- image.gif
+-- formDefinition.xml
At deployment this file is extracted into e.g. /WEB-INF/blocks/001. I wonder
if this can cause problems as a lot of resources become part of the classpath
but only MyJavaflowController.class should be.
If it is a problem we could provide two artifacts, one JAR file containing the
classes and one that contains the resources which is extracted into
/WEB-INF/blocks/001 but not added to the classpath. ... but this makes the
build and the deployment more complicated for our users ...
Ideas/opinions?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: AW: How to connect Avalon Component and SessionListener
Stefan Pietschmann wrote:
Yes, I read about that and tried to find out a bit more about
HTTPSessionBindingListener. However I don't quite get the store your
component as a session attribute-part.
1. I'm using my component in the pipline implementation. I assume you'd do
it some way like this (made it short):
ObjectModelHelper.getRequest(environment.getObjectModel()).getSession().setA
ttribute(mycomponent,component);
I call this method during login - it is in the SessionData class
public static SessionData getInstance(Session session)
{
SessionData sessionData = (SessionData)
session.getAttribute(SESSION_DATA);
if (sessionData == null)
{
sessionData = new SessionData();
session.setAttribute(SESSION_DATA, sessionData);
}
return sessionData;
}
Re: AW: How to connect Avalon Component and SessionListener
Ralph Goers wrote:
Stefan Pietschmann wrote:
Yes, I read about that and tried to find out a bit more about
HTTPSessionBindingListener. However I don't quite get the store your
component as a session attribute-part.
1. I'm using my component in the pipline implementation. I assume
you'd do
it some way like this (made it short):
ObjectModelHelper.getRequest(environment.getObjectModel()).getSession().setA
ttribute(mycomponent,component);
I call this method during login - it is in the SessionData class
I should be clearer. This code assumes that login is single threaded so
synchronization is not necessary.
public static SessionData getInstance(Session session)
{
SessionData sessionData = (SessionData)
session.getAttribute(SESSION_DATA);
if (sessionData == null)
{
sessionData = new SessionData();
session.setAttribute(SESSION_DATA, sessionData);
}
return sessionData;
}
Re: [RF] Chainsaws and Seeds
Antonio Gallardo wrote: dave- wrote: Stefano Mazzocchi wrote: Mark Lowe wrote: Nice charts.. They assume that the same folk that are there at the start of the start line are the same folk that are end or even perhaps middle. Despite having a lot of respect for stefano's achievements and the contribution that cocoon has made, I think the graphs are wrong, or at least fail to account for iterations of staff turnover. Hmmm, this is a very valid point, I'll have to think about it some more. Hmm... IMHO, it does not matter whether the graphs are right or wrong, I think the web 2..0 movement has transcended the issue in any case. Model Based Architectures and Graphical interfaces have allowed far less technical people access to complex environments. I think, although I am not absolutely positive, that a java/pipeline/sitemap is a better base than perl/python upon which to build such systems. It is for that reason I posted the following 2 visions in another thread: As a first vision, I would like to see cocoon accessible to less technical people. This could be done with elegant simplicity and a graphical interface. Here is a good web 2.0 example http://www.activegrid.com/what/applicationbuilder.php. As a second vision, artifacts created by the graphical interface along with any written code could become the model from which alternative implementation systems might be generated. For example, a model POJO could be implementationally persisted in various ways. dave- Should not be this more a Lepido[1] concern? Yes, it is currently a Lepido concern, but perhaps it should be a general community concern. I think the cocoon community should refocus their vision to a model based architecture (MBA) as the single point to align to. A MBA would allow for concurrent competing implementation possibilities rather than having to choose between them. For example, the model could be implemented as a pure java implementation or as a java./javascript implementation without having to choose between them.. I think Lepido would then refocus toward providing a graphical front end to the model.
Re: [RT] Ditching the environment abstraction
In general I agree with this - it makes learning Cocoon internal a little bit easier. But I think the current environment api is not our biggest problem. Anyways, our current Request object has more functionality as the servlet request object, e.g. to get the sitemap prefix and sitemap uri and more important the request attribute handling for internal requests. How can we keep this functionality when switching to the servlet api? And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? Or for a later version? Carsten Daniel Fagerstrom wrote: It seem like we all agree about that the Cocoon core need to be simplified, although we have different opinions about how to achieve it. IMO it can be done in steps by refactoring of the trunk. One of the complications with Cocoon is the environment abstraction: o.a.c.environment.Request, Response, Context etc. They are similar but not identical to the javax.servlet and javax.servlet.http interfaces, which means yet another thing to learn for the user. It also means that it becomes more complicated to use externally developed components, as these typically implement the servlet family of interfaces. Furthermore it leads to a more complicated setup process of Cocoon. So, do we need this extra layer of abstraction? It made sense when Cocoon was mainly a publication framework, for publication the servlet family of interfaces has a lot of functionlity that is irrelevant. But now when Cocoon has developed to a webapp framework, it makes much less sense to have an own abstraction of what already has a standardized abstraction. o.a.c.e.Request has expanded so that it is close to identical to HttpRequest. For o.a.c.e.Response and Context there are larger differences to their servlet counterparts, they are subsets. But what is not implemented either could be implemented or just throw an not implemented exception. Another reason for having an own abstraction was to be able to use Cocoon in none servlet environments. This has not happened to any large extent, in addition to the Http environment, we have CLI, Faces and Portal environment. For the Http, Faces and Portal environment, using the servlet interfaces should be a simpilification and improvement. For CLI, I dont see that it would complicate anything either. The main problem with swithing to the servlet interfaces AFAICS, except for that it takes some work, is back incompability. This could be solved to some extent by letting our abstactions extend the servlet interfaces. Nearly all methods have the same names and types. But IMO it would be better to simplify Cocoon and take the back incompability now and just remove our own abstraction, we could have some adapter utilities in some compability block. So in a first step I would like to switch our environment abstraction to their servlet correspondances. In an next step I think we should use Servlet instead of processor for our controllers: Cocoon, Sitemap, Flow and possibly the Pipeline. This would make it simpler to reuse Cocoon functionality, and also to experiment with new kinds of controllers. As discussed before the Processor interface contains a far to much implementation details that are connected to sitemap engine internals for beeing suitable as a general controller interface within Cocoon. I'm considering to reimplement the two controllers in the blocks architecture: the BlocksManager and the BlockManager, as servlets, and thus get rid of a lot of start up complications. Also it would make it possible to let a block contain any servlet with a set of components, instead of hardwiring it to the sitemap controller. WDYT? /Daniel -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Ditching the environment abstraction
Carsten Ziegeler wrote: In general I agree with this - it makes learning Cocoon internal a little bit easier. But I think the current environment api is not our biggest problem. Anyways, our current Request object has more functionality as the servlet request object, e.g. to get the sitemap prefix and sitemap uri and more important the request attribute handling for internal requests. How can we keep this functionality when switching to the servlet api? And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? Or for a later version? Carsten I would imagine for a leter version. I'd think it would be too soon. We have two implementations of the Cocoon environment abstraction: CLI and WebApp. If we rip out the abstraction now, Forrest would break. I think that alone would push it out a bit.
New ASF members
Hi all, An ASF members meeting was held yesterday evening here in San Diego during which new members were voted in. Among the 33 new members, some are well known here: - Bruno Dumon - Antonio Gallardo - Ross Gardler - Reinhard Poetz - Jeremy Quinn Congratulations and a warm welcome to the new members! Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[EMAIL PROTECTED]: Project cocoon-block-portal (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-portal has an issue affecting its community integration. This issue affects 3 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-faces : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-scratchpad : Java XML Framework Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-portal/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [portal-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-portal/gump_work/build_cocoon_cocoon-block-portal.html Work Name: build_cocoon_cocoon-block-portal (Type: Build) Work ended in a state of : Failed Elapsed: 33 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-12122005 -Dblock-name=portal gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[EMAIL PROTECTED]: Project cocoon-block-portal (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-portal has an issue affecting its community integration. This issue affects 3 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-faces : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-scratchpad : Java XML Framework Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-portal/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [portal-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-portal/gump_work/build_cocoon_cocoon-block-portal.html Work Name: build_cocoon_cocoon-block-portal (Type: Build) Work ended in a state of : Failed Elapsed: 33 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-12122005 -Dblock-name=portal gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
Re: [RT] Ditching the environment abstraction
Berin Loritsch wrote: Carsten Ziegeler wrote: In general I agree with this - it makes learning Cocoon internal a little bit easier. But I think the current environment api is not our biggest problem. Anyways, our current Request object has more functionality as the servlet request object, e.g. to get the sitemap prefix and sitemap uri and more important the request attribute handling for internal requests. How can we keep this functionality when switching to the servlet api? And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? Or for a later version? Carsten I would imagine for a leter version. I'd think it would be too soon. We have two implementations of the Cocoon environment abstraction: CLI and WebApp. If we rip out the abstraction now, Forrest would break. I think that alone would push it out a bit. no, it wouldn't. The servlet api is itself an abstraction. So what we have is an abstraction of an abstraction. The suggestion is to scrap this double abstraction. We could easily have our own CLI implementation of javax.servlet.* That is the suggestion. Regards, Upayavira
Re: New ASF members
Le 12 déc. 05, à 19:28, Sylvain Wallez a écrit : Congratulations and a warm welcome to the new members! +1 ! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: New ASF members
+1 from me too! Bertrand Delacretaz schrieb: Le 12 déc. 05, à 19:28, Sylvain Wallez a écrit : Congratulations and a warm welcome to the new members! +1 ! -Bertrand
Re: Cocoon 2.2 - Build and deployment with Maven2
Reinhard Poetz skrev: After working on the deployer and learning more about the Maven2 internals, I want to share 2 thougths: I've already raised the question whether it is possible to merge block.xml and pom.xml. For now it's not as dependencies in pom.xml can't carry all the necessary information for us. Maven 1.1 models had support for properties elements, but they have been dropped in Maven 2.0 (Does anybody know the reason for it?). There is a configuration element within the plugin element where you can put any xml, the OSGi M2 plugin of Felix uses that, see http://docs.safehaus.org/display/OSGI/OSGi+Plugin+for+Maven+2.0. I also mentioned my concerns about tieing us to closely to Maven. I can agree about that, but I don't think it is the right time to care about that right now. Even if we happen to have well designed formats with schemes for wiring and block descriptions, they are basically armchair speculations. We haven't exactly checked them with a lot of detailed use cases, not talking about used them in practice. So although they seem to be good designs, we don't know, experience will tell. So I think worrying about the final format is premature. Lets get something that work that we can start experimenting with. I think the solution for this is very simple: Our contract is block.xml. As soon as a Maven pom.xml can give us all the required information and people use it as build descriptor, block.xml can be *automatically* generated for them during the build lifecycle and they don't have to care for it anymore. I'm not such a large fan of automatically generated configuration file. If you need to generate it, it means that the basic desigend sucked. Also it means that you are going to get error messages from a file that you don't recognize whan you deply the block, and that is not user friendly. People that don't want to use Maven, have to provide a hand-crafted block.xml. IMO that is FS, we should start by making it work before we start to generalize the stuff. I'm all for making parts of Cocoon more reusable. But I don't think we should achieve that by supporting all kinds of uses at each abstraction level. IMO for the block and deployment level we support M2, period. If there comes something much greater than M2 the next year or so it will do things conceptually different from M2, so trying to adapt to that will just complicate things. Going this way we are not blocked by getting the missing Maven features and blocks don't get tied to Maven which would make a future replacement of Maven very difficult. As said above, we shouldn't worry to much about future replacements of M2. If it happen, we solve it then. A second thought: As outlined in one of my previous mails, a Cocoon block will become a valid jar file, for example with following content: ROOT +-- block.xml +-- pom.xml +-- sitemap.xmap +-- org | +--myProject | +-- MyJavaflowController.class +-- app +-- formTemplate.jx +-- image.gif +-- formDefinition.xml At deployment this file is extracted into e.g. /WEB-INF/blocks/001. I wonder if this can cause problems as a lot of resources become part of the classpath but only MyJavaflowController.class should be. As long as the non class resource are put into easy recognizable file and directories, it should be easy to filter them in our block class loader, for non block uses people are probably only using the Java classes and the facts that there are resources with the same name in different jars shouldn't matter. If it is a problem we could provide two artifacts, one JAR file containing the classes and one that contains the resources which is extracted into /WEB-INF/blocks/001 but not added to the classpath. ... but this makes the build and the deployment more complicated for our users ... No, one jar per block is a must from usablity POV. Then in practice it is probable that most blocks will be class only or resource only, but that is a different matter. /Daniel
Re: [RT] Ditching the environment abstraction
Carsten Ziegeler skrev: In general I agree with this - it makes learning Cocoon internal a little bit easier. But I think the current environment api is not our biggest problem. We have had quite a few threads about our problems, so I'm not going to try to find our biggest problem in this thread ;) But one of our problems is that core is monolitic and hard to understand. And this in turn depends on many small complexities that adds upp to overall complexity. One of these problems is th environment abstraction, and that is a problem that I happen to be motivated to atack now. The reason for that is that I want to make the block architecture as independent of Cocoon specifics as possible. And I want to use servlet interfaces instead of our own, but this will require CLI to use servlet interfaces to be able to use blocks. So I wanted to know the communities thoughts about this. Anyways, our current Request object has more functionality as the servlet request object, e.g. to get the sitemap prefix and sitemap uri and more important the request attribute handling for internal requests. How can we keep this functionality when switching to the servlet api? We can either ave an own extension or better have an extra interface that only contains the extension, then we can check if this extra interface is used in the code. Also we seem to be heading towards making controllers more of a first class citicen in Cocoon, and then we shouldn't force people to handle sitemap specifics in the new controllers. And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? It depends on the timeframe for 2.2 ;) I will be offline for the next two weeks (kitesurfing in Mexico :) ) after that I would like to ditch the enviroment abstraction ASAP. So it sounds like 2.2. /Daniel
Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Daniel Fagerstrom wrote: And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? It depends on the timeframe for 2.2 ;) I will be offline for the next two weeks (kitesurfing in Mexico :) ) after that I would like to ditch the enviroment abstraction ASAP. So it sounds like 2.2. Hmm, ok, this is a point where I disagree :) I think we should get 2.2 out asap to have our mind clear for new stuff. Of course, you're right that if we plan to develop 2.2 for another year, we can ditch the abstraction as well. But I really fear that in that case we never get 2.2 out. I strongly suggest that we start creating roadmaps. This also would make the development of Cocoon for users much more transparent. Currently I have only two points which I really think have to be finished for 2.2: the build/deployment stuff and making the current blocks available separatly/providing an own versioning for them. So as soon as the m2 integration works, we can polish 2.2 a little bit and then release the core and each blocks as 2.2 and from the on develop the core and the blocks independently and release them independently. Everything else can follow later on. WDYT? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Carsten Ziegeler wrote: I strongly suggest that we start creating roadmaps. This also would make the development of Cocoon for users much more transparent. Currently I have only two points which I really think have to be finished for 2.2: the build/deployment stuff and making the current blocks available separatly/providing an own versioning for them. So as soon as the m2 integration works, we can polish 2.2 a little bit and then release the core and each blocks as 2.2 and from the on develop the core and the blocks independently and release them independently. Everything else can follow later on. WDYT? Carsten +1 Ralph
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
I agree that the main focus must be to get a 2.2 release. So the question is what to do with the real blocks. They are currently rather close to the specification, but we don't know if the specification is good enough without getting experience from the blocks. For ditching the environment abstraction, that should of course not block any releases. It can always be solved by making the change in a branch and merge it back when it works. /Daniel Carsten Ziegeler skrev: Daniel Fagerstrom wrote: And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? It depends on the timeframe for 2.2 ;) I will be offline for the next two weeks (kitesurfing in Mexico :) ) after that I would like to ditch the enviroment abstraction ASAP. So it sounds like 2.2. Hmm, ok, this is a point where I disagree :) I think we should get 2.2 out asap to have our mind clear for new stuff. Of course, you're right that if we plan to develop 2.2 for another year, we can ditch the abstraction as well. But I really fear that in that case we never get 2.2 out. I strongly suggest that we start creating roadmaps. This also would make the development of Cocoon for users much more transparent. Currently I have only two points which I really think have to be finished for 2.2: the build/deployment stuff and making the current blocks available separatly/providing an own versioning for them. So as soon as the m2 integration works, we can polish 2.2 a little bit and then release the core and each blocks as 2.2 and from the on develop the core and the blocks independently and release them independently. Everything else can follow later on. WDYT? Carsten
Re: RFC: Ajax Roadmap
Ralph Goers wrote: Jeremy Quinn wrote: Hi Ralph On 9 Dec 2005, at 15:06, Ralph Goers wrote: Jeremy Quinn wrote: The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) If there are multiple forms on a page (i.e. in the portal) will multiple copies be loaded? I don't know :) Is there anything in the portal samples I can try this on? I don't know. Carsten has been working on Ajax support. The ajax support in the portal is currently just for the portal itself (reloading of coplets etc.), but not for the portlets itself. (Yes, Ralf I'm mixing coplet and portlet again - like I did in the presentation :( ) Now, we could integrate a cforms test tab in the portal. If someone could give me one or two urls for simple forms samples, I can integrate them into the portal and we can see what happens and what has to be done. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: RFC: Ajax Roadmap
Carsten Ziegeler wrote: The ajax support in the portal is currently just for the portal itself (reloading of coplets etc.), but not for the portlets itself. (Yes, Ralf I'm mixing coplet and portlet again - like I did in the presentation :( ) Sorry, I misspelled your name, it should read Ralph of course (Ralf is the german version)...sorry! Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: RFC: Ajax Roadmap
Carsten Ziegeler wrote: I think this global switch is a misconception. Can we change the meaning to: use ajax if it's enabled in the form *and* if the current browser supports it? Currently I only have the choice for switching ajax on for *all* users. Now if they happen to have turned off javascript, they simply can't use the form. So I would prefer to have a detection mechanism, if the current browser supports ajax or something like that. AFAIK, we have a detection mechanism at the browser level: http://svn.apache.org/viewcvs.cgi/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/resources/js/cforms.js?view=markup (see the end of the cocoon.forms.submitForm, at the end we founda comment: /// Non ajax-aware browser : regular submit/ / Best Regards, Antonio Gallardo. / Apart from that a general +1 for your ideas. Carsten
Re: [HELP] Javadocs link broken. Redirecting more than expected.
Antonio Gallardo wrote: Hi: While reviewing the javadocs, I found there is a link that is broken. The content is there, but the linkrewriter is non-correrctly redirecting the content. Try: http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/xml/xlink/package-frame.html I found the .htaccess file in /www/cocoon.apache.org/2.1 contains the following rule that makes the javadocs to not display correclty: RedirectMatch link/(.*)$ http://cocoon.apache.org/link/$1; I don't wanted to touch the code, because I don't have an idea why we have this redirection. Can someone fix this? Thanks in advance. The reason that it is there is that we used to have the link section of documents for our live sites in the 2.1 docs, then they got moved up to the top-level. I just tweaked it to be a better match. -David
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
On 12/13/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote: I agree that the main focus must be to get a 2.2 release. So the question is what to do with the real blocks. They are currently rather close to the specification, but we don't know if the specification is good enough without getting experience from the blocks. For ditching the environment abstraction, that should of course not block any releases. It can always be solved by making the change in a branch and merge it back when it works. I tend to disagree. The environment abstraction is to me part of the underlying public contracts users rely upon: changing contracts between minor versions is borderline but acceptable given the cost/benefit ratio, but it's out of question between revision. Having 2.2 with the old environment and, say, 2.2.1 with a new one seems like breaking our versioning guidelines to me. I'd suggest we ditch it altogether while we still have time. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [HELP] Javadocs link broken. Redirecting more than expected.
David Crossley wrote: Antonio Gallardo wrote: Hi: While reviewing the javadocs, I found there is a link that is broken. The content is there, but the linkrewriter is non-correrctly redirecting the content. Try: http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/xml/xlink/package-frame.html I found the .htaccess file in /www/cocoon.apache.org/2.1 contains the following rule that makes the javadocs to not display correclty: RedirectMatch link/(.*)$ http://cocoon.apache.org/link/$1; I don't wanted to touch the code, because I don't have an idea why we have this redirection. Can someone fix this? Thanks in advance. The reason that it is there is that we used to have the link section of documents for our live sites in the 2.1 docs, then they got moved up to the top-level. I just tweaked it to be a better match. thanks, David. :-) Best Regards, Antonio Gallardo
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Gianugo Rabellino wrote: On 12/13/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote: I agree that the main focus must be to get a 2.2 release. So the question is what to do with the real blocks. They are currently rather close to the specification, but we don't know if the specification is good enough without getting experience from the blocks. For ditching the environment abstraction, that should of course not block any releases. It can always be solved by making the change in a branch and merge it back when it works. I tend to disagree. The environment abstraction is to me part of the underlying public contracts users rely upon: changing contracts between minor versions is borderline but acceptable given the cost/benefit ratio, but it's out of question between revision. Having 2.2 with the old environment and, say, 2.2.1 with a new one seems like breaking our versioning guidelines to me. I'd suggest we ditch it altogether while we still have time. Ciao, Just make sure it doesn't break anyone accidentally.
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Gianugo Rabellino skrev: On 12/13/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote: I agree that the main focus must be to get a 2.2 release. So the question is what to do with the real blocks. They are currently rather close to the specification, but we don't know if the specification is good enough without getting experience from the blocks. For ditching the environment abstraction, that should of course not block any releases. It can always be solved by making the change in a branch and merge it back when it works. I tend to disagree. The environment abstraction is to me part of the underlying public contracts users rely upon: changing contracts between minor versions is borderline but acceptable given the cost/benefit ratio, but it's out of question between revision. Having 2.2 with the old environment and, say, 2.2.1 with a new one seems like breaking our versioning guidelines to me. I'd suggest we ditch it altogether while we still have time. Agree. We probably have a couple of milestone releases first. If we ditch it during the milestone phase it should be ok. But definitly not between revisions. The only layer in Cocoon where users has any contact with the environment abstraction is through the object model in sitemap components. So we can push the use of the environment abstraction down a couple of layers in the Cocoon internal without affecting anybody. But of course I would prefer geting rid of them once and for all. /Daniel
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Berin Loritsch skrev: Gianugo Rabellino wrote: On 12/13/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote: I agree that the main focus must be to get a 2.2 release. So the question is what to do with the real blocks. They are currently rather close to the specification, but we don't know if the specification is good enough without getting experience from the blocks. For ditching the environment abstraction, that should of course not block any releases. It can always be solved by making the change in a branch and merge it back when it works. I tend to disagree. The environment abstraction is to me part of the underlying public contracts users rely upon: changing contracts between minor versions is borderline but acceptable given the cost/benefit ratio, but it's out of question between revision. Having 2.2 with the old environment and, say, 2.2.1 with a new one seems like breaking our versioning guidelines to me. I'd suggest we ditch it altogether while we still have time. Ciao, Just make sure it doesn't break anyone accidentally. No risk, we will break peoples code intentionally ;) More seriously, it was an RT, I wanted to hear what people think and if there was any problems that I hadn't thought about. I will of course cast a vote before commiting anything. We could possibly provide some optional back compability mode that puts the environment abstraction objects in the object model. But I would suppose most users would be happy to get rid of this extra complication. /Daniel
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Gianugo Rabellino wrote: I tend to disagree. The environment abstraction is to me part of the underlying public contracts users rely upon: changing contracts between minor versions is borderline but acceptable given the cost/benefit ratio, but it's out of question between revision. Having 2.2 with the old environment and, say, 2.2.1 with a new one seems like breaking our versioning guidelines to me. I'd suggest we ditch it altogether while we still have time. Ciao, While I agree that it is OK to break compatibility to some degree between 2.1 and 2.2, I think this is more of a change than I'd really like to see between 2.1 and 2.2 as it will require modifications to every Cocoon application. In addition, I'm still not clear as to where the extra request methods would go. Ralph
