[jira] Created: (COCOON-2204) [PATCH]
[PATCH] Key: COCOON-2204 URL: https://issues.apache.org/jira/browse/COCOON-2204 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Fix For: 2.2-dev (Current SVN) According to this page: http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html If you you are using Ajax, a div (or similar element) must surround the fields of a group. eg: ft:group id=info div pft:widget id=foo//p pft:widget id=bar//p /div /ft:group CForms (through the magic of the forms-field-styling.xsl) will put the group's id on the div. The code to this, seems broken as it does not match on the div, but on the fi:group. NOTE: This is another solution to the problem described here: https://issues.apache.org/jira/browse/COCOON-1825 However, the solution described within it seems to make the suggestion in http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either way, either this issue or that one is not necessary. Patch is provided below: Index: D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl === --- D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (revision 651922) +++ D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (working copy) @@ -706,7 +706,7 @@ xsl:apply-templates/ /xsl:template - xsl:template match=fi:group mode=copy-parent-id + xsl:template match=* mode=copy-parent-id xsl:copy xsl:attribute name=idxsl:value-of select=../@id//xsl:attribute xsl:copy-of select=@*/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2204) [PATCH] ft:group internal div not handled correctly.
[ https://issues.apache.org/jira/browse/COCOON-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamal Bhatt updated COCOON-2204: Summary: [PATCH] ft:group internal div not handled correctly. (was: [PATCH] ) Changed title to something more descriptive than just [PATCH]. [PATCH] ft:group internal div not handled correctly. Key: COCOON-2204 URL: https://issues.apache.org/jira/browse/COCOON-2204 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Fix For: 2.2-dev (Current SVN) According to this page: http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html If you you are using Ajax, a div (or similar element) must surround the fields of a group. eg: ft:group id=info div pft:widget id=foo//p pft:widget id=bar//p /div /ft:group CForms (through the magic of the forms-field-styling.xsl) will put the group's id on the div. The code to this, seems broken as it does not match on the div, but on the fi:group. NOTE: This is another solution to the problem described here: https://issues.apache.org/jira/browse/COCOON-1825 However, the solution described within it seems to make the suggestion in http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either way, either this issue or that one is not necessary. Patch is provided below: Index: D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl === --- D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (revision 651922) +++ D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (working copy) @@ -706,7 +706,7 @@ xsl:apply-templates/ /xsl:template - xsl:template match=fi:group mode=copy-parent-id + xsl:template match=* mode=copy-parent-id xsl:copy xsl:attribute name=idxsl:value-of select=../@id//xsl:attribute xsl:copy-of select=@*/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [2.2] Dynamically generating XML tags in JXTemplates
Kamal pisze: I remember that there was some (good) reason to not have this feature in JX template but I fail to find an e-mail in archives right now. Do you remember if those reasons related to JXTemplates architecture or a was there a case of stopping the user from doing this? I remember reading something about problems with SAX nature of JXTemplates but I remember it was an old discussion so it may not be relevant anymore. -- Grzegorz Kossakowski
Re: Preparing OSGi-ready artifacts
Grzegorz Kossakowski wrote:
This brings us to couple of questions:
1. Do we want to have a policy to have only one base package (e.g.
o.a.c.servletservice.*) per one module (artifact, JAR, you name it)?
2. What OSGi folks can say about this situation? I remember that there
was some requirement to have clean package structure in order to run in
OSGi environment easily but I'm not expert in this area.
There shouldn't be two different artifacts *exporting* the same package,
which means having classes intendet to be used by other artifacts in
this package. That's afaik the only requirement for OSGi.
This can be easily reached if a block uses o.a.c.{blockname} for its own
packages.
Carstem
--
Carsten Ziegeler
[EMAIL PROTECTED]
Re: Preparing OSGi-ready artifacts
Carsten Ziegeler pisze:
Grzegorz Kossakowski wrote:
This brings us to couple of questions:
1. Do we want to have a policy to have only one base package (e.g.
o.a.c.servletservice.*) per one module (artifact, JAR, you name it)?
2. What OSGi folks can say about this situation? I remember that there
was some requirement to have clean package structure in order to run
in OSGi environment easily but I'm not expert in this area.
There shouldn't be two different artifacts *exporting* the same package,
which means having classes intendet to be used by other artifacts in
this package. That's afaik the only requirement for OSGi.
This can be easily reached if a block uses o.a.c.{blockname} for its own
packages.
So do you think we need to rename o.a.c.callstack into
o.a.c.servletservice.callstack ?
--
Grzegorz Kossakowski
[jira] Updated: (COCOON-1825) Ajax error when an active state widget become invisible state widget
[
https://issues.apache.org/jira/browse/COCOON-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Heinicke updated COCOON-1825:
--
Summary: Ajax error when an active state widget become invisible state
widget (was: [PATCH] Ajax error when an active state widget become invisible
state widget)
Ajax error when an active state widget become invisible state widget
Key: COCOON-1825
URL: https://issues.apache.org/jira/browse/COCOON-1825
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.9
Reporter: Vincent Demay
Assignee: Antonio Gallardo
Some widget (field with selection-list and styling=radio, group, etc...) can
not be hidden (state=invisible)in ajax mode.
I declare some widgets without state attribute in the form definition, my
form is in ajax mode, when I set the widget state to INVISIBLE, the ajax
response can not be applied to the form because span
id=widget-name.../span is not available in source code.
I think about 2 patches :
*putting a span/span in forms-field-styling.xsl where is not set
*or modifing abstractWidgetDefinition.java in ordre to generate a placeholder
around each widget (but patch seems to need a lot of modification in
forms-field-styling.xsl too)
Here is the patch for first
--- forms-field-styling.orig 2006-04-13 15:37:06.590221200 +0200
+++ forms-field-styling.xsl 2006-04-13 15:38:22.525291200 +0200
@@ -198,8 +198,9 @@
xsl:variable name=value select=fi:value/
xsl:variable name=vertical
select=string(fi:styling/@list-orientation) != 'horizontal'/
xsl:choose
- xsl:when test=$vertical
-table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
+ xsl:when test=$vertical
+ span id={$id}
+ table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
xsl:for-each select=fi:selection-list/fi:item
xsl:variable name=item-id select=concat($id, ':',
position())/
tr
@@ -224,6 +225,7 @@
/tr
/xsl:for-each
/table
+/span
/xsl:when
xsl:otherwise
span id={$id} title={fi:hint}
@@ -682,22 +684,24 @@
| know where to insert the widget if it becomes visible
+--
xsl:template match=fi:placeholder
-span id=[EMAIL PROTECTED]/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:struct - has no visual representation by default
+--
xsl:template match=fi:struct
-xsl:apply-templates/
+ span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:group - has no visual representation by default
+--
xsl:template match=fi:group
-xsl:apply-templates/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
+
+
xsl:template match=@*|node() priority=-1
xsl:copy
Here for the second
--- AbstractWidget.orig 2006-04-13 15:31:07.851701200 +0200
+++ AbstractWidget.java 2006-04-13 15:30:31.446616200 +0200
@@ -483,6 +483,10 @@
public void generateSaxFragment(ContentHandler contentHandler, Locale
locale)
throws SAXException {
+ AttributesImpl placeHolderAttrs = new AttributesImpl();
+ placeHolderAttrs.addCDATAAttribute(id, getRequestParameterName());
+contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder,
placeHolderAttrs);
+
if (getCombinedState().isDisplayingValues()) {
// FIXME: we may want to strip out completely widgets that
aren't updated when in AJAX mode
String element = this.getXMLElementName();
@@ -497,15 +501,9 @@
generateItemSaxFragment(contentHandler, locale);
-contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
-
-} else {
-// Generate a placeholder that can be used later by AJAX updates
-AttributesImpl attrs = new AttributesImpl();
-attrs.addCDATAAttribute(id, getRequestParameterName());
-contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder, attrs);
-contentHandler.endElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder);
+contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
}
+contentHandler.endElement(FormsConstants.INSTANCE_NS, placeholder,
FormsConstants.INSTANCE_PREFIX_COLON +
[jira] Commented: (COCOON-2197) Making the cocoon-auth-block acegi-security-sample work
[ https://issues.apache.org/jira/browse/COCOON-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592655#action_12592655 ] Grzegorz Kossakowski commented on COCOON-2197: -- Patrick, I've tried to apply your patch and it looks good to me (I just removed SNAPSHOT suffix). However, I would like to know if you ran successfully this block? I have a feeling that it's somehow not finished and needs more polish. Making the cocoon-auth-block acegi-security-sample work --- Key: COCOON-2197 URL: https://issues.apache.org/jira/browse/COCOON-2197 Project: Cocoon Issue Type: Wish Components: - Samples Affects Versions: 2.2 Reporter: Patrick Heiden Assignee: Grzegorz Kossakowski Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: cocoon-acegi-sample-svn-diff.patch The current acegi-security-sample doesn't work with acegi version used! So an update to spring-security (2.0.0-SNAPSHOT) fixed that problem. Following steps need to be performed: 1) get the latest trunk from spring-security (acegi) (see [1] for details) 2) compile and install that trunk (mvn install, maybe skip the more than 1000 tests ;) 3) change the pom.xml of cocoon-acegisecurity-sample block: replace the acegi dependency with: dependency groupIdorg.springframework.security/groupId artifactIdspring-security-core/artifactId version2.0.0-SNAPSHOT/version exclusions exclusion groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId /exclusion /exclusions /dependency 4) replacements in META-INF/cocoon/xpatch/acegi-filter-patch.xweb: every org.acegi. ... should be replaced by org.springframework.security 5) the same needs to be done for all bean's class attribute inside META-INF/cocoon/spring/cocoon-acegisecurity.xml 6) mvn install; mvn jetty:run I would guess, that by making acegi a spring portfolio project, the rework on that project contains better adoption of spring bean-lifecycles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Preparing OSGi-ready artifacts
Grzegorz Kossakowski skrev: Hi folks, I've tried refactored SSF (1.1.0-SNAPSHOT version) and it looks very good to me. I'm thinking about releasing first milestone of this module (along with cocoon-jnet) but I've been struck by a little mess in packages we have in SSF and cocoon-jnet. Let's have a look at SSF, we have following packages: o.a.c.callstack.* o.a.c.servletscope.* o.a.c.servletservice.* The reason that I used a separate top level package for the o.a.c.callstack was that I had some idea about using it as some kind of generic call stack for the site map engine (and move it to an own module). That would have required some refactoring that I never felt motivated enough to pursue. I don't know (or remember if I was responsible ;) ) about the o.a.c.servletscope package. As o.a.c.callstack.* probably isn't useful outside the context of servlet services and only used in the implementation it might be safe to move it to o.a.c.servletservice.callstack.* Now cocoon-jnet: o.a.c.jnet.* o.a.excalibur.sourceresolve.jnet.* This brings us to couple of questions: 1. Do we want to have a policy to have only one base package (e.g. o.a.c.servletservice.*) per one module (artifact, JAR, you name it)? That is preferable. But it is not necessary. If a module already contains several top level packages that people are using, it might not be worthwhile to introduce back incompatibility just for the sake of minor elegance. 2. What OSGi folks can say about this situation? I remember that there was some requirement to have clean package structure in order to run in OSGi environment easily but I'm not expert in this area. The requirement for making OSGi use possible is the opposite way around. Two modules cannot use the same package. If two modules (bundles) add different classes to the same package just the classes from one of the module will be available in the OSGi framework. An example of this problem is the package o.a.c.generation that is populated with interfaces and implementations in numerous modules. But neither cocoon-jnet nor SSF has any such problems AFAIK. 3. Why cocoon-jnet has excalibur-specific classes at all? I thought that we agreed we are not going to support Sources as URLs and only focus on new functionality. Then o.a.excalibur.sourceresolve.jnet.* should be removed right? Don't know. /Daniel
Re: Preparing OSGi-ready artifacts
Daniel Fagerstrom pisze: Grzegorz Kossakowski skrev: Hi folks, I've tried refactored SSF (1.1.0-SNAPSHOT version) and it looks very good to me. I'm thinking about releasing first milestone of this module (along with cocoon-jnet) but I've been struck by a little mess in packages we have in SSF and cocoon-jnet. Let's have a look at SSF, we have following packages: o.a.c.callstack.* o.a.c.servletscope.* o.a.c.servletservice.* The reason that I used a separate top level package for the o.a.c.callstack was that I had some idea about using it as some kind of generic call stack for the site map engine (and move it to an own module). That would have required some refactoring that I never felt motivated enough to pursue. I don't know (or remember if I was responsible ;) ) about the o.a.c.servletscope package. Ok, that was me who introduced this one. ;-) As o.a.c.callstack.* probably isn't useful outside the context of servlet services and only used in the implementation it might be safe to move it to o.a.c.servletservice.callstack.* Agreed. Will do this shortly. Now cocoon-jnet: o.a.c.jnet.* o.a.excalibur.sourceresolve.jnet.* This brings us to couple of questions: 1. Do we want to have a policy to have only one base package (e.g. o.a.c.servletservice.*) per one module (artifact, JAR, you name it)? That is preferable. But it is not necessary. If a module already contains several top level packages that people are using, it might not be worthwhile to introduce back incompatibility just for the sake of minor elegance. Yep, but if we introduce back incompatibility for some other reason I think we should take the opportunity to clean up packages as well. 2. What OSGi folks can say about this situation? I remember that there was some requirement to have clean package structure in order to run in OSGi environment easily but I'm not expert in this area. The requirement for making OSGi use possible is the opposite way around. Two modules cannot use the same package. If two modules (bundles) add different classes to the same package just the classes from one of the module will be available in the OSGi framework. An example of this problem is the package o.a.c.generation that is populated with interfaces and implementations in numerous modules. But neither cocoon-jnet nor SSF has any such problems AFAIK. I see. Thanks for clarifying. -- Grzegorz Kossakowski
Re: svn commit: r651728 - /cocoon/trunk/tools/cocoon-maven-plugin/src/main/resources/org/apache/cocoon/maven/rcl/profiles/cocoon-22/WEB-INF/web.xml
[EMAIL PROTECTED] pisze: Author: gkossakowski Date: Fri Apr 25 15:40:48 2008 New Revision: 651728 URL: http://svn.apache.org/viewvc?rev=651728view=rev Log: RCL must take into account newly created BlockDeploymentServletContextListener. [...] listener + listener-classorg.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener/listener-class + /listener + listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class /listener listener At the time of committing this fix I forgot about our xpath functionality for web.xml. Now I wonder what's better solution, to add this to RCL profile or just let cocoon-blockdeployer to provide XPath file for web.xml? Reinhard, could you comment? -- Grzegorz Kossakowski
[jira] Commented: (COCOON-2204) ft:group internal div not handled correctly.
[
https://issues.apache.org/jira/browse/COCOON-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592684#action_12592684
]
Kamal Bhatt commented on COCOON-2204:
-
{quote}
Is there still any documentation out there in which we say to prefix summary
with [PATCH]? We have the Patch available check box now which is sufficient.
{quote}
Probably not. Case of Monkey see, Monkey do.
ft:group internal div not handled correctly.
Key: COCOON-2204
URL: https://issues.apache.org/jira/browse/COCOON-2204
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.2, 2.2-dev (Current SVN)
Reporter: Kamal Bhatt
Fix For: 2.2-dev (Current SVN)
According to this page:
http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html
If you you are using Ajax, a div (or similar element) must surround the
fields of a group. eg:
ft:group id=info
div
pft:widget id=foo//p
pft:widget id=bar//p
/div
/ft:group
CForms (through the magic of the forms-field-styling.xsl) will put the
group's id on the div. The code to this, seems broken as it does not match on
the div, but on the fi:group.
NOTE: This is another solution to the problem described here:
https://issues.apache.org/jira/browse/COCOON-1825
However, the solution described within it seems to make the suggestion in
http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either
way, either this issue or that one is not necessary.
Patch is provided below:
Index:
D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
===
---
D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(revision 651922)
+++
D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(working copy)
@@ -706,7 +706,7 @@
xsl:apply-templates/
/xsl:template
- xsl:template match=fi:group mode=copy-parent-id
+ xsl:template match=* mode=copy-parent-id
xsl:copy
xsl:attribute name=idxsl:value-of
select=../@id//xsl:attribute
xsl:copy-of select=@*/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COCOON-2204) ft:group internal div not handled correctly.
[
https://issues.apache.org/jira/browse/COCOON-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592684#action_12592684
]
kambha edited comment on COCOON-2204 at 4/27/08 3:07 PM:
--
Quote: Is there still any documentation out there in which we say to prefix
summary with [PATCH]? We have the Patch available check box now which is
sufficient.
Probably not. Case of Monkey see, Monkey do.
was (Author: kambha):
{quote}
Is there still any documentation out there in which we say to prefix summary
with [PATCH]? We have the Patch available check box now which is sufficient.
{quote}
Probably not. Case of Monkey see, Monkey do.
ft:group internal div not handled correctly.
Key: COCOON-2204
URL: https://issues.apache.org/jira/browse/COCOON-2204
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.2, 2.2-dev (Current SVN)
Reporter: Kamal Bhatt
Fix For: 2.2-dev (Current SVN)
According to this page:
http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html
If you you are using Ajax, a div (or similar element) must surround the
fields of a group. eg:
ft:group id=info
div
pft:widget id=foo//p
pft:widget id=bar//p
/div
/ft:group
CForms (through the magic of the forms-field-styling.xsl) will put the
group's id on the div. The code to this, seems broken as it does not match on
the div, but on the fi:group.
NOTE: This is another solution to the problem described here:
https://issues.apache.org/jira/browse/COCOON-1825
However, the solution described within it seems to make the suggestion in
http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either
way, either this issue or that one is not necessary.
Patch is provided below:
Index:
D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
===
---
D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(revision 651922)
+++
D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(working copy)
@@ -706,7 +706,7 @@
xsl:apply-templates/
/xsl:template
- xsl:template match=fi:group mode=copy-parent-id
+ xsl:template match=* mode=copy-parent-id
xsl:copy
xsl:attribute name=idxsl:value-of
select=../@id//xsl:attribute
xsl:copy-of select=@*/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2204) ft:group internal div not handled correctly.
[ https://issues.apache.org/jira/browse/COCOON-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke reassigned COCOON-2204: - Assignee: Jörg Heinicke ft:group internal div not handled correctly. Key: COCOON-2204 URL: https://issues.apache.org/jira/browse/COCOON-2204 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Assignee: Jörg Heinicke Fix For: 2.2-dev (Current SVN) According to this page: http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html If you you are using Ajax, a div (or similar element) must surround the fields of a group. eg: ft:group id=info div pft:widget id=foo//p pft:widget id=bar//p /div /ft:group CForms (through the magic of the forms-field-styling.xsl) will put the group's id on the div. The code to this, seems broken as it does not match on the div, but on the fi:group. NOTE: This is another solution to the problem described here: https://issues.apache.org/jira/browse/COCOON-1825 However, the solution described within it seems to make the suggestion in http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either way, either this issue or that one is not necessary. Patch is provided below: Index: D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl === --- D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (revision 651922) +++ D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (working copy) @@ -706,7 +706,7 @@ xsl:apply-templates/ /xsl:template - xsl:template match=fi:group mode=copy-parent-id + xsl:template match=* mode=copy-parent-id xsl:copy xsl:attribute name=idxsl:value-of select=../@id//xsl:attribute xsl:copy-of select=@*/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2204) ft:group internal div not handled correctly.
[ https://issues.apache.org/jira/browse/COCOON-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592700#action_12592700 ] Jörg Heinicke commented on COCOON-2204: --- Confirming the bug ... it does not exist in 2.1. No idea how/when it was introduced/fixed. The stylesheet is completely out of sync in 2.1 and 2.2. ft:group internal div not handled correctly. Key: COCOON-2204 URL: https://issues.apache.org/jira/browse/COCOON-2204 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Assignee: Jörg Heinicke Fix For: 2.2-dev (Current SVN) According to this page: http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html If you you are using Ajax, a div (or similar element) must surround the fields of a group. eg: ft:group id=info div pft:widget id=foo//p pft:widget id=bar//p /div /ft:group CForms (through the magic of the forms-field-styling.xsl) will put the group's id on the div. The code to this, seems broken as it does not match on the div, but on the fi:group. NOTE: This is another solution to the problem described here: https://issues.apache.org/jira/browse/COCOON-1825 However, the solution described within it seems to make the suggestion in http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either way, either this issue or that one is not necessary. Patch is provided below: Index: D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl === --- D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (revision 651922) +++ D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (working copy) @@ -706,7 +706,7 @@ xsl:apply-templates/ /xsl:template - xsl:template match=fi:group mode=copy-parent-id + xsl:template match=* mode=copy-parent-id xsl:copy xsl:attribute name=idxsl:value-of select=../@id//xsl:attribute xsl:copy-of select=@*/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2204) ft:group internal div not handled correctly.
[ https://issues.apache.org/jira/browse/COCOON-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke closed COCOON-2204. - Resolution: Fixed Affects version (Component): Parent values: Blocks: Forms(10167). Level 1 values: 1.0.0-RC3-SNAPSHOT(10331). (was: Parent values: Blocks: Forms(10167). Level 1 values: 1.0.0-RC2(10330). ) Fix version (Component): Parent values: Blocks: Forms(10239). (was: Parent values: Blocks: Forms(10239). Level 1 values: 1.0.0-RC2(10332). ) ft:group internal div not handled correctly. Key: COCOON-2204 URL: https://issues.apache.org/jira/browse/COCOON-2204 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Assignee: Jörg Heinicke Fix For: 2.2-dev (Current SVN) According to this page: http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html If you you are using Ajax, a div (or similar element) must surround the fields of a group. eg: ft:group id=info div pft:widget id=foo//p pft:widget id=bar//p /div /ft:group CForms (through the magic of the forms-field-styling.xsl) will put the group's id on the div. The code to this, seems broken as it does not match on the div, but on the fi:group. NOTE: This is another solution to the problem described here: https://issues.apache.org/jira/browse/COCOON-1825 However, the solution described within it seems to make the suggestion in http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either way, either this issue or that one is not necessary. Patch is provided below: Index: D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl === --- D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (revision 651922) +++ D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (working copy) @@ -706,7 +706,7 @@ xsl:apply-templates/ /xsl:template - xsl:template match=fi:group mode=copy-parent-id + xsl:template match=* mode=copy-parent-id xsl:copy xsl:attribute name=idxsl:value-of select=../@id//xsl:attribute xsl:copy-of select=@*/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2204) ft:group internal div not handled correctly.
[ https://issues.apache.org/jira/browse/COCOON-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated COCOON-2204: -- Priority: Minor (was: Major) Urgency: Normal (was: Urgent) Affects Version/s: (was: 2.2-dev (Current SVN)) ft:group internal div not handled correctly. Key: COCOON-2204 URL: https://issues.apache.org/jira/browse/COCOON-2204 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2 Reporter: Kamal Bhatt Assignee: Jörg Heinicke Priority: Minor Fix For: 2.2-dev (Current SVN) According to this page: http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html If you you are using Ajax, a div (or similar element) must surround the fields of a group. eg: ft:group id=info div pft:widget id=foo//p pft:widget id=bar//p /div /ft:group CForms (through the magic of the forms-field-styling.xsl) will put the group's id on the div. The code to this, seems broken as it does not match on the div, but on the fi:group. NOTE: This is another solution to the problem described here: https://issues.apache.org/jira/browse/COCOON-1825 However, the solution described within it seems to make the suggestion in http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either way, either this issue or that one is not necessary. Patch is provided below: Index: D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl === --- D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (revision 651922) +++ D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (working copy) @@ -706,7 +706,7 @@ xsl:apply-templates/ /xsl:template - xsl:template match=fi:group mode=copy-parent-id + xsl:template match=* mode=copy-parent-id xsl:copy xsl:attribute name=idxsl:value-of select=../@id//xsl:attribute xsl:copy-of select=@*/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2204) ft:group internal div not handled correctly.
[ https://issues.apache.org/jira/browse/COCOON-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592718#action_12592718 ] Kamal Bhatt commented on COCOON-2204: - Thanks. Am I correct in saying that this issue: https://issues.apache.org/jira/browse/COCOON-1825 Is redundant? ft:group internal div not handled correctly. Key: COCOON-2204 URL: https://issues.apache.org/jira/browse/COCOON-2204 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2 Reporter: Kamal Bhatt Assignee: Jörg Heinicke Priority: Minor Fix For: 2.2-dev (Current SVN) According to this page: http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html If you you are using Ajax, a div (or similar element) must surround the fields of a group. eg: ft:group id=info div pft:widget id=foo//p pft:widget id=bar//p /div /ft:group CForms (through the magic of the forms-field-styling.xsl) will put the group's id on the div. The code to this, seems broken as it does not match on the div, but on the fi:group. NOTE: This is another solution to the problem described here: https://issues.apache.org/jira/browse/COCOON-1825 However, the solution described within it seems to make the suggestion in http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either way, either this issue or that one is not necessary. Patch is provided below: Index: D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl === --- D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (revision 651922) +++ D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (working copy) @@ -706,7 +706,7 @@ xsl:apply-templates/ /xsl:template - xsl:template match=fi:group mode=copy-parent-id + xsl:template match=* mode=copy-parent-id xsl:copy xsl:attribute name=idxsl:value-of select=../@id//xsl:attribute xsl:copy-of select=@*/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-1825) Ajax error when an active state widget become invisible state widget
[
https://issues.apache.org/jira/browse/COCOON-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Heinicke reassigned COCOON-1825:
-
Assignee: Jörg Heinicke (was: Antonio Gallardo)
Ajax error when an active state widget become invisible state widget
Key: COCOON-1825
URL: https://issues.apache.org/jira/browse/COCOON-1825
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.9
Reporter: Vincent Demay
Assignee: Jörg Heinicke
Some widget (field with selection-list and styling=radio, group, etc...) can
not be hidden (state=invisible)in ajax mode.
I declare some widgets without state attribute in the form definition, my
form is in ajax mode, when I set the widget state to INVISIBLE, the ajax
response can not be applied to the form because span
id=widget-name.../span is not available in source code.
I think about 2 patches :
*putting a span/span in forms-field-styling.xsl where is not set
*or modifing abstractWidgetDefinition.java in ordre to generate a placeholder
around each widget (but patch seems to need a lot of modification in
forms-field-styling.xsl too)
Here is the patch for first
--- forms-field-styling.orig 2006-04-13 15:37:06.590221200 +0200
+++ forms-field-styling.xsl 2006-04-13 15:38:22.525291200 +0200
@@ -198,8 +198,9 @@
xsl:variable name=value select=fi:value/
xsl:variable name=vertical
select=string(fi:styling/@list-orientation) != 'horizontal'/
xsl:choose
- xsl:when test=$vertical
-table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
+ xsl:when test=$vertical
+ span id={$id}
+ table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
xsl:for-each select=fi:selection-list/fi:item
xsl:variable name=item-id select=concat($id, ':',
position())/
tr
@@ -224,6 +225,7 @@
/tr
/xsl:for-each
/table
+/span
/xsl:when
xsl:otherwise
span id={$id} title={fi:hint}
@@ -682,22 +684,24 @@
| know where to insert the widget if it becomes visible
+--
xsl:template match=fi:placeholder
-span id=[EMAIL PROTECTED]/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:struct - has no visual representation by default
+--
xsl:template match=fi:struct
-xsl:apply-templates/
+ span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:group - has no visual representation by default
+--
xsl:template match=fi:group
-xsl:apply-templates/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
+
+
xsl:template match=@*|node() priority=-1
xsl:copy
Here for the second
--- AbstractWidget.orig 2006-04-13 15:31:07.851701200 +0200
+++ AbstractWidget.java 2006-04-13 15:30:31.446616200 +0200
@@ -483,6 +483,10 @@
public void generateSaxFragment(ContentHandler contentHandler, Locale
locale)
throws SAXException {
+ AttributesImpl placeHolderAttrs = new AttributesImpl();
+ placeHolderAttrs.addCDATAAttribute(id, getRequestParameterName());
+contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder,
placeHolderAttrs);
+
if (getCombinedState().isDisplayingValues()) {
// FIXME: we may want to strip out completely widgets that
aren't updated when in AJAX mode
String element = this.getXMLElementName();
@@ -497,15 +501,9 @@
generateItemSaxFragment(contentHandler, locale);
-contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
-
-} else {
-// Generate a placeholder that can be used later by AJAX updates
-AttributesImpl attrs = new AttributesImpl();
-attrs.addCDATAAttribute(id, getRequestParameterName());
-contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder, attrs);
-contentHandler.endElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder);
+contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
}
+contentHandler.endElement(FormsConstants.INSTANCE_NS, placeholder,
FormsConstants.INSTANCE_PREFIX_COLON + placeholder);
}
public Object getAttribute(String name) {
--
This message is automatically generated by
[jira] Commented: (COCOON-2204) ft:group internal div not handled correctly.
[ https://issues.apache.org/jira/browse/COCOON-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592727#action_12592727 ] Jörg Heinicke commented on COCOON-2204: --- The fi:struct part was still missing. Applied now as well. ft:group internal div not handled correctly. Key: COCOON-2204 URL: https://issues.apache.org/jira/browse/COCOON-2204 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2 Reporter: Kamal Bhatt Assignee: Jörg Heinicke Priority: Minor Fix For: 2.2-dev (Current SVN) According to this page: http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html If you you are using Ajax, a div (or similar element) must surround the fields of a group. eg: ft:group id=info div pft:widget id=foo//p pft:widget id=bar//p /div /ft:group CForms (through the magic of the forms-field-styling.xsl) will put the group's id on the div. The code to this, seems broken as it does not match on the div, but on the fi:group. NOTE: This is another solution to the problem described here: https://issues.apache.org/jira/browse/COCOON-1825 However, the solution described within it seems to make the suggestion in http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either way, either this issue or that one is not necessary. Patch is provided below: Index: D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl === --- D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (revision 651922) +++ D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (working copy) @@ -706,7 +706,7 @@ xsl:apply-templates/ /xsl:template - xsl:template match=fi:group mode=copy-parent-id + xsl:template match=* mode=copy-parent-id xsl:copy xsl:attribute name=idxsl:value-of select=../@id//xsl:attribute xsl:copy-of select=@*/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1825) Ajax error when an active state widget become invisible state widget
[
https://issues.apache.org/jira/browse/COCOON-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Heinicke closed COCOON-1825.
-
Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
2.1.12-dev (Current SVN)
Affects version (Component): Parent values: Blocks: Forms(10167). Level 1
values: 1.0.0-RC3-SNAPSHOT(10331).
Fix version (Component): Parent values: Blocks: Forms(10239).
The fix for fi:group was already in SVN, just broken in Cocoon 2.2/Cocoon Forms
1.0/1.1 (COCOON-2204). Applied fix for fi:struct.
Ajax error when an active state widget become invisible state widget
Key: COCOON-1825
URL: https://issues.apache.org/jira/browse/COCOON-1825
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.9
Reporter: Vincent Demay
Assignee: Jörg Heinicke
Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN)
Some widget (field with selection-list and styling=radio, group, etc...) can
not be hidden (state=invisible)in ajax mode.
I declare some widgets without state attribute in the form definition, my
form is in ajax mode, when I set the widget state to INVISIBLE, the ajax
response can not be applied to the form because span
id=widget-name.../span is not available in source code.
I think about 2 patches :
*putting a span/span in forms-field-styling.xsl where is not set
*or modifing abstractWidgetDefinition.java in ordre to generate a placeholder
around each widget (but patch seems to need a lot of modification in
forms-field-styling.xsl too)
Here is the patch for first
--- forms-field-styling.orig 2006-04-13 15:37:06.590221200 +0200
+++ forms-field-styling.xsl 2006-04-13 15:38:22.525291200 +0200
@@ -198,8 +198,9 @@
xsl:variable name=value select=fi:value/
xsl:variable name=vertical
select=string(fi:styling/@list-orientation) != 'horizontal'/
xsl:choose
- xsl:when test=$vertical
-table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
+ xsl:when test=$vertical
+ span id={$id}
+ table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
xsl:for-each select=fi:selection-list/fi:item
xsl:variable name=item-id select=concat($id, ':',
position())/
tr
@@ -224,6 +225,7 @@
/tr
/xsl:for-each
/table
+/span
/xsl:when
xsl:otherwise
span id={$id} title={fi:hint}
@@ -682,22 +684,24 @@
| know where to insert the widget if it becomes visible
+--
xsl:template match=fi:placeholder
-span id=[EMAIL PROTECTED]/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:struct - has no visual representation by default
+--
xsl:template match=fi:struct
-xsl:apply-templates/
+ span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:group - has no visual representation by default
+--
xsl:template match=fi:group
-xsl:apply-templates/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
+
+
xsl:template match=@*|node() priority=-1
xsl:copy
Here for the second
--- AbstractWidget.orig 2006-04-13 15:31:07.851701200 +0200
+++ AbstractWidget.java 2006-04-13 15:30:31.446616200 +0200
@@ -483,6 +483,10 @@
public void generateSaxFragment(ContentHandler contentHandler, Locale
locale)
throws SAXException {
+ AttributesImpl placeHolderAttrs = new AttributesImpl();
+ placeHolderAttrs.addCDATAAttribute(id, getRequestParameterName());
+contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder,
placeHolderAttrs);
+
if (getCombinedState().isDisplayingValues()) {
// FIXME: we may want to strip out completely widgets that
aren't updated when in AJAX mode
String element = this.getXMLElementName();
@@ -497,15 +501,9 @@
generateItemSaxFragment(contentHandler, locale);
-contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
-
-} else {
-// Generate a placeholder that can be used later by AJAX updates
-AttributesImpl attrs = new AttributesImpl();
-attrs.addCDATAAttribute(id, getRequestParameterName());
-contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder, attrs);
-
Re: Avoiding OutOfMemory Errors by limiting data in pipeline
On 24.04.2008 16:08, Bruce Atherton wrote: Thanks for the response. About setting the buffer size, this looks like it could be what I am looking for. A few questions: 1. Do I have to set the buffer size on each transformer and the serializer as well as the generator? What about setting it on the pipeline? It is on the pipeline and only there. You can set it on the map:pipe element in the map:components section, so that it is applied to each pipeline of that type. Or on any individual map:pipeline element in the map:pipelines section. 2. Does the full amount of the buffer automatically get allocated for each request, or does it grow gradually based on the xml stream size? I have a lot of steps in the pipeline, so I am worried about the impact of creating too many buffers even if they are relatively small. A 1 Meg buffer might be too much if it is created for every element of every pipeline for every request. That's a very good question - with a negative answer: A buffer of that particular size is created initially. That's why I want to bring this issue up on dev again: With my changes for COCOON-2168 [1] it's now not only a problem for applications with over-sized downloads but potentially for everyone relying on Cocoon's default configuration. One idea would be to change our BufferedOutputStream implementation to take 2 parameters: one for the initial buffer size and one for the flush size. The flush treshold would be the configurable outputBufferSize, the initial buffer size does not need to be configurable I think. What do other think? On an unrelated note, is there some way to configure caching so that nothing is cached that is larger than a certain size? I'm worried that this might be a caching issue rather than a buffer issue. Not that I'm aware of. Why do you think it's caching? Caching is at least configurable in terms of number of cache entries and I also think in terms of max cache size. But beyond a certain cache size the cache entries are written to disk anyway so it's unlikely resulting in a memory issue. How do you read the object graph from the heap dump? To tell you the truth, I'm not sure. This is the hierarchy generated by the Heap Analyzer tool from IBM, and is from a heap dump on an AIX box running the IBM JRE. My guess as to the Object referencing the ComponentsSelector is that the ArrayList is not generified, so the analyzer doesn't know the actual type of the Object being referenced. What the object actually is would depend on what CachingProcessorPipeline put into the ArrayList. That is just a guess, though. And I have no explanation for the link between FOM_Cocoon$CallContext and ConcreteCallProcessor. Perhaps things were different in the 2.1.9 release? No serious changes since 2.1.9 which is rev 392241 [2]. Joerg [1] https://issues.apache.org/jira/browse/COCOON-2168 [2] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java?view=log
Re: Preparing OSGi-ready artifacts
Grzegorz Kossakowski wrote:
Carsten Ziegeler pisze:
Grzegorz Kossakowski wrote:
This brings us to couple of questions:
1. Do we want to have a policy to have only one base package (e.g.
o.a.c.servletservice.*) per one module (artifact, JAR, you name it)?
2. What OSGi folks can say about this situation? I remember that
there was some requirement to have clean package structure in order
to run in OSGi environment easily but I'm not expert in this area.
There shouldn't be two different artifacts *exporting* the same
package, which means having classes intendet to be used by other
artifacts in this package. That's afaik the only requirement for OSGi.
This can be easily reached if a block uses o.a.c.{blockname} for its
own packages.
So do you think we need to rename o.a.c.callstack into
o.a.c.servletservice.callstack ?
IMO, no. It doesn't violate the rule that there shouldn't be two
different artifacts exporting the same package.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair [EMAIL PROTECTED]
Releasing Cocoon subprojects
Grzegorz Kossakowski wrote:
Hi folks,
I've tried refactored SSF (1.1.0-SNAPSHOT version) and it looks very
good to me. I'm thinking about releasing first milestone of this module
(along with cocoon-jnet)
If you release SSF 1.1.0, also cocoon-blockdeployment,
cocoon-configuration, cocoon-spring-configurator and as you proposed
cocoon-jnet should be released.
Additionally it's probably a good idea to release the Cocoon Maven
plugin and the archetypes.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair [EMAIL PROTECTED]
