[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524437 ] Daniel Fagerstrom commented on COCOON-1765: --- When I look at the same link I find client code examples for Log4J, Jakarta Commons Logging, SLF4J, Avalon Logging, JDK Logging, Knopflerfish Log and Pax Logging in the client code section. Also they are moving their documentation to Confluence, a newer version of the document can be found here http://wiki.ops4j.org/confluence/display/ops4j/Pax+Logging. > Logging > --- > > Key: COCOON-1765 > URL: https://issues.apache.org/jira/browse/COCOON-1765 > Project: Cocoon > Issue Type: New Feature > Components: - OSGi integration >Reporter: Reinhard Poetz > > [...] But my main thoughts is that logging need to be a centralized service, > common for all blocks (separate logging solutions for each block would be a > pain). > The logging implementation is contained in a block (that is installed early) > and makes the logger available as a service that other block can get through > the service manager. This way the logging implementation is chosen by the > choice of logging block. Observe that I only is talking about the blocks fw, > within a block an ordinary ECM can be set up and it will inject the logger in > its managed objects through the usual Avalon style. > Using the same logger interface everywhere is also practical I guess we > continue to use the o.a.avalon.framework.logger.Logger one. > (by Daniel Fagerstrom: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113889468124728&w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524403 ] Daniel Fagerstrom commented on COCOON-1765: --- Pax logging supports all major logging framework in an OSGi friendly way. Currently I just use it as an (better) implementation of Commons Logging. All the classloading tricks of the ordinary Commons Logging implementation makes it frustrating to use in an OSGi environment. The point with using the Pax OSGi logging service from OPS4J in combination with the Commons Logging implementation would be that the logging output would be available though the API of the OSGi logging service. But at this point I don't know whether that would be useful or not, so it can wait. > Logging > --- > > Key: COCOON-1765 > URL: https://issues.apache.org/jira/browse/COCOON-1765 > Project: Cocoon > Issue Type: New Feature > Components: - OSGi integration >Reporter: Reinhard Poetz > > [...] But my main thoughts is that logging need to be a centralized service, > common for all blocks (separate logging solutions for each block would be a > pain). > The logging implementation is contained in a block (that is installed early) > and makes the logger available as a service that other block can get through > the service manager. This way the logging implementation is chosen by the > choice of logging block. Observe that I only is talking about the blocks fw, > within a block an ordinary ECM can be set up and it will inject the logger in > its managed objects through the usual Avalon style. > Using the same logger interface everywhere is also practical I guess we > continue to use the o.a.avalon.framework.logger.Logger one. > (by Daniel Fagerstrom: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113889468124728&w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1833) Make OSGi-based Cocoon useable from within servlet containers
[ https://issues.apache.org/jira/browse/COCOON-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524391 ] Daniel Fagerstrom commented on COCOON-1833: --- The current work is based on Felix. So a webapp embedding of the Felix framework corresponding to the Eclipse one (http://www.eclipse.org/equinox/server/http_in_container.php) would be nice. Felix is designed to be easily embedded (http://felix.apache.org/site/launching-and-embedding-apache-felix.html) so with some inspiration from the Eclipse work it would probably not be to complicated to implement. Now, the OSGi-ification of the Cocoon blocks is supposed to work with any OSGi framework. But for builds and examples it is easier to focus on one framework. > Make OSGi-based Cocoon useable from within servlet containers > - > > Key: COCOON-1833 > URL: https://issues.apache.org/jira/browse/COCOON-1833 > Project: Cocoon > Issue Type: New Feature > Components: - Servlet service framework >Reporter: Reinhard Poetz > > We are not the first having this need :-) > We just have to use http://www.eclipse.org/equinox/incubator/server/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524387 ] Daniel Fagerstrom commented on COCOON-1765: --- I use Pax Logging in the whiteboard and it works well. But there is work left to do on logging configuration and on decide if the OSGi logiing service from OPS4J should be used or not. > Logging > --- > > Key: COCOON-1765 > URL: https://issues.apache.org/jira/browse/COCOON-1765 > Project: Cocoon > Issue Type: New Feature > Components: - Servlet service framework >Reporter: Reinhard Poetz > > [...] But my main thoughts is that logging need to be a centralized service, > common for all blocks (separate logging solutions for each block would be a > pain). > The logging implementation is contained in a block (that is installed early) > and makes the logger available as a service that other block can get through > the service manager. This way the logging implementation is chosen by the > choice of logging block. Observe that I only is talking about the blocks fw, > within a block an ordinary ECM can be set up and it will inject the logger in > its managed objects through the usual Avalon style. > Using the same logger interface everywhere is also practical I guess we > continue to use the o.a.avalon.framework.logger.Logger one. > (by Daniel Fagerstrom: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113889468124728&w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1834) Integrate OSGi extensions into build system
[ https://issues.apache.org/jira/browse/COCOON-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524386 ] Daniel Fagerstrom commented on COCOON-1834: --- Currently this is done in wrappers in the whiteboard for some of the core Cocoon blocks. When the work stabilizes and there is more community involvement the OSGi builds could be moved to the affected blocks in the trunk. > Integrate OSGi extensions into build system > --- > > Key: COCOON-1834 > URL: https://issues.apache.org/jira/browse/COCOON-1834 > Project: Cocoon > Issue Type: New Feature > Components: - Servlet service framework >Reporter: Reinhard Poetz >Assignee: Reinhard Poetz > > Make Cocoon block artifacts valid OSGi bundles at build time (of course using > Maven 2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1830) Implement OSGiSpringBridge
[ https://issues.apache.org/jira/browse/COCOON-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524384 ] Daniel Fagerstrom commented on COCOON-1830: --- This task is much easier and maybe not needed at all as we use Spring-OSGi http://www.springframework.org/osgi in the current Cocoon-OSGi integration. A possible problem with Spring-OSGi is that explicit references to all used services are needed for using beans from other bundles. This might be to much configuration and to unflexible when used with the sitemap that dynamically imports services. Here we maybe should use the idea from earlier Cocoon-OSGi integration work with having a root Spring context in bundles that use sitemaps, that ask the OSGi framework directly for non local beans. > Implement OSGiSpringBridge > -- > > Key: COCOON-1830 > URL: https://issues.apache.org/jira/browse/COCOON-1830 > Project: Cocoon > Issue Type: New Feature > Components: - Servlet service framework >Reporter: Reinhard Poetz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1835) Deployment bundle
[ https://issues.apache.org/jira/browse/COCOON-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524383 ] Daniel Fagerstrom commented on COCOON-1835: --- During development Peter Kriens fileInstall bundle http://www.aqute.biz/Code/FileInstall could be convenient to use. It watches a directory and install and starts bundles that are added to the directory, stops and uninstalls those that are removed and updates those that are changed. Maybe the fileInstall could somehow be extended with mechanisms from the RCL stuff for more fine grained bundle updating. > Deployment bundle > - > > Key: COCOON-1835 > URL: https://issues.apache.org/jira/browse/COCOON-1835 > Project: Cocoon > Issue Type: New Feature > Components: - Servlet service framework >Reporter: Reinhard Poetz >Assignee: Reinhard Poetz > > Write a bundle that can install, start, update and stop Cocoon blocks. It is > configured by a deployment descriptor. > Internally it works based on the OSGi configuration service. > Some notes: > - go through the tutorial of PDE development in "Eclipse Rich Client Platform" > - read Jeff McAffer on [EMAIL PROTECTED]: Installing bundles by reference > (Feb 2006) > - make it configureable which bundles you want to install > a) create an OSGi application > b) create a WAR file that internally uses OSGi > - make the deployer check if all contracts are fullfilled (mail on [EMAIL > PROTECTED] by Jeff McAffer, 30th of August) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1836) Cocoon blocks development support
[ https://issues.apache.org/jira/browse/COCOON-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Fagerstrom closed COCOON-1836. - Resolution: Fixed See last comment. > Cocoon blocks development support > - > > Key: COCOON-1836 > URL: https://issues.apache.org/jira/browse/COCOON-1836 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Reinhard Poetz >Assignee: Reinhard Poetz > > some ideas (DF/RP) > - go through the tutorial of PDE development in "Eclipse Rich Client Platform" > - Talk to Equinox and Felix how they manage the development process > - Talk to the Eclipse PDE community as all resources need to be in the root > directory > - Create a Mojo that creates the target platform containing all bundles out > of a pom.xml or > a deployment descriptor. Make it configureable so that you can easily > switch between bundled > versions and exploded bundles mounted as projects in Eclipse > - Create a Mojo that copies all needed external libraries into > ./target/osgi/lib so that they > can be seen by the PDE (a bit of a hack but well ...) > - extend the Felix OSGi plugin so that you can change the path for integrated > plugins -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1836) Cocoon blocks development support
[ https://issues.apache.org/jira/browse/COCOON-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524381 ] Daniel Fagerstrom commented on COCOON-1836: --- The current Cocoon-OSGi development in the white board uses the Felix Maven bundle plugin that makes it fairly easy to create bundles from ordinary jars. But it doesn't work that well together with the PDE that (at least a year ago) required that the manifest.mf is fixed rather than generated. It seem like the Eclipse developers and large parts of the rest OSGi-community has different philosophy about manifest generation so there is probably not much to do about it. The assembly plugin is used in the whiteboard for collecting together all needed bundles, so there is no need for some special purpose Mojo for that. So all the items above is either solved or less relevant with the current development strategy. > Cocoon blocks development support > - > > Key: COCOON-1836 > URL: https://issues.apache.org/jira/browse/COCOON-1836 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Reinhard Poetz >Assignee: Reinhard Poetz > > some ideas (DF/RP) > - go through the tutorial of PDE development in "Eclipse Rich Client Platform" > - Talk to Equinox and Felix how they manage the development process > - Talk to the Eclipse PDE community as all resources need to be in the root > directory > - Create a Mojo that creates the target platform containing all bundles out > of a pom.xml or > a deployment descriptor. Make it configureable so that you can easily > switch between bundled > versions and exploded bundles mounted as projects in Eclipse > - Create a Mojo that copies all needed external libraries into > ./target/osgi/lib so that they > can be seen by the PDE (a bit of a hack but well ...) > - extend the Felix OSGi plugin so that you can change the path for integrated > plugins -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2038) Implement true Object Oriented approach for handling super calls
[ https://issues.apache.org/jira/browse/COCOON-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523226 ] Daniel Fagerstrom commented on COCOON-2038: --- There is a known bug in handling of multi level super calls (COCOON-1939) I linked this issue to that issue. > Implement true Object Oriented approach for handling super calls > > > Key: COCOON-2038 > URL: https://issues.apache.org/jira/browse/COCOON-2038 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: BlockCallHttpServletResponse.java.patch, > cocoon-servlet-service-impl.patch, DispatcherServlet.java.patch, > ServletServiceContext.java.patch, StatusRetrievableResponse.java > > > As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 > implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2066) BlockCompletePathModule returns wrong path in scope of internal servlet call
[
https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502127
]
Daniel Fagerstrom commented on COCOON-2066:
---
Great that you are working on it.
Considering the setRequest method I think it makes sense to use
HttpServletRequest as neither Cocoon nor any other conceivable servlet based
webapp will have any use for requests that only implement ServletRequest (which
among many other things lacks context and servlet paths). So IMO it is better
to down cast to the arguments to the forward method and fail as fast as
possible in the unlikely situation that the arguments doesn't implement
HttpServlet[Request|Response].
> BlockCompletePathModule returns wrong path in scope of internal servlet call
>
>
> Key: COCOON-2066
> URL: https://issues.apache.org/jira/browse/COCOON-2066
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Grzegorz Kossakowski
>Assignee: Grzegorz Kossakowski
>
> BlockCompletePathModule uses this construct:
> public Object getAttribute(String name, Configuration modeConf, Map
> objectModel) throws ConfigurationException {
> return ObjectModelHelper.getRequest(objectModel).getContextPath() +
> blockPathModule.getAttribute(name, modeConf, objectModel);
> }
> However, when internal (service call or not) request is being made
> BlockCallHttpServletRequest becomes an object represnting current request but
> it has no meaningful representation of getContextPath method.
> Solution to this problem might be forwarding context path value from original
> request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2066) BlockCompletePathModule returns wrong path in scope of internal servlet call
[
https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502071
]
Daniel Fagerstrom commented on COCOON-2066:
---
The solution that I have in mind is based on always having the current
Sevlet(Service)Context, HttpServletRequest and HttpServletResponse available in
the callstack. Then all the needed context and servlet paths are available when
constructing the request and response objects for the internal call.
In more detail it could be implemented the following way:
* The o.a.c.callstack and o.a.c.callstack.environment (in
cocoon-sevlet-service-impl) are allready implemented so that the call stack can
contain request and response objects besides the context object. Take a look at
the CallFrameHelper. Actually the whole thing is design so that it implements a
special call stack Spring scope so that the objects on the call stack is
available with dependecy injection. The later part doesn't work completetly
yet, so just use the CallFrameHelper for the moment.
* The ServletConnection gets the current request (and possibly response) object
from the call stack and uses these in the construction of more correct
BlockCallHttpServlet[Request|Response] objects. One possibility is to let the
new request/response objects wrap the current ones. An even better (although
more complicated) possibility is to wrap the current request/reponse objects
with dynamic proxies. By doing that extensions in the incomming
request/response objects, like e.g. SAX awareness, are preserved for the sub
calls.
* The newly created request/response object are used in the forward method of a
dispatcher from the ServletServiceContext. Within the forward method the
CallStackHelper.enterServlet methods are used for pushing the new
ServletServiceContext on the call stack. These methods need to be extended so
that the forward method can push the new request and response objects as well.
* With the above mechanism in place the current request, response and context
objects are always avaliable att the call stack. So now the
BlockCompletePathModule can get the current (and correct) request object from
the call stack and get the needed context path.
> BlockCompletePathModule returns wrong path in scope of internal servlet call
>
>
> Key: COCOON-2066
> URL: https://issues.apache.org/jira/browse/COCOON-2066
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Grzegorz Kossakowski
>
> BlockCompletePathModule uses this construct:
> public Object getAttribute(String name, Configuration modeConf, Map
> objectModel) throws ConfigurationException {
> return ObjectModelHelper.getRequest(objectModel).getContextPath() +
> blockPathModule.getAttribute(name, modeConf, objectModel);
> }
> However, when internal (service call or not) request is being made
> BlockCallHttpServletRequest becomes an object represnting current request but
> it has no meaningful representation of getContextPath method.
> Solution to this problem might be forwarding context path value from original
> request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2038) Implement true Object Oriented approach for handling super calls
[ https://issues.apache.org/jira/browse/COCOON-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487442 ] Daniel Fagerstrom commented on COCOON-2038: --- The explicit super call is because I didn't find any good way to call sitemaps in a "call through" way long time ago when I implemented the first version of the blocks fw. But of course it would be neater to not need to use an explicit super call. As the servlet service fw is supposed to work with any servlet the implicit super call mechanism need to use general servlet mechanisms. One way would be to call the base servlet and check for the status code of the http response object. If it is "200 OK" and possibly some other responses in the 2xx (and maybe 3xx) series, the response is just returned. If the response is "404 Not Found" (and maybe for some response codes in the 4xx and 5xx series) the super servlet is called. Otherwise the error response code is just returned. The mechanism should probably be implemented somewhere in the ServletServiceContext as most of the rest of the OO stuff is implemented there. > Implement true Object Oriented approach for handling super calls > > > Key: COCOON-2038 > URL: https://issues.apache.org/jira/browse/COCOON-2038 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Reporter: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > > As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 > implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2034) Configure servlet prefix for link rewriting automatically
[ https://issues.apache.org/jira/browse/COCOON-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485261 ] Daniel Fagerstrom commented on COCOON-2034: --- I have a "clever" idea about how to solve it ;) We discussed the problem in http://marc.info/?l=xml-cocoon-dev&m=117009688607351&w=2. And I implemented the solution as you can see in /cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/DynamicProxyRequestHandler.java#invoke. You just use the context path module instead of the hard coded path and the it should work. This is because: contextPath = wrapped.getContextPath() + wrapped.getServletPath() which is the prefix of the servlet dispatcher. > Configure servlet prefix for link rewriting automatically > - > > Key: COCOON-2034 > URL: https://issues.apache.org/jira/browse/COCOON-2034 > Project: Cocoon > Issue Type: Task > Components: - Servlet service framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski > > Currently prefix at which Cocoon's servlet dispatcher is mounted is hardcoded > in > /cocoon-servlet-service-components/src/main/resources/META-INF/cocoon/avalon/cocoon-servlet-complete-path-resolver.xconf > file. We should find some way setting it automatically. > Do you know any way how to get value from in web.xml? Or maybe > any other clever idea how to resolve this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2025) Create XML Schema for servlet-service
[ https://issues.apache.org/jira/browse/COCOON-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482432 ] Daniel Fagerstrom commented on COCOON-2025: --- There is allready a scheme http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/resources/org/apache/cocoon/servletservice/schema/cocoon-servlet-1.0.xsd. What is needed is to publish it at the Cocoon site. I don't how to do that, but Carsten have suceeded for the schemes that he has authored, so it is probably possible ;) > Create XML Schema for servlet-service > - > > Key: COCOON-2025 > URL: https://issues.apache.org/jira/browse/COCOON-2025 > Project: Cocoon > Issue Type: Task > Components: * Cocoon Core >Reporter: Grzegorz Kossakowski >Priority: Minor > Fix For: 2.2-dev (Current SVN) > > > Currently a non-existing schema for http://cocoon.apache.org/schema/servlet > is being referenced in many places in Cocoon. It would be really helpful to > have such a schema (as we already reference to it). > Daniel, can you take care of creating it as you are original author of > servlet configuration syntax? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2009) Pipelines more HTTP-compliant (respecting and producing HTTP headers and status codes)
[ https://issues.apache.org/jira/browse/COCOON-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474868 ] Daniel Fagerstrom commented on COCOON-2009: --- In a comment in the patch you say: IMPORTANT: It *has* to be called *after* caching because date in Last-Modified header must be later than time stored in cache to get it properly working. Looking at HttpEnvironment.isResponseModified, I would rather say: later or at the _same time_ as the time stored in cache. And based on that I would use environment.isResponseModified(this.cachedResponse.getLastModified()); instead of environment.isResponseModified(new Date().getTime()); Because otherwise it might happen that Last-Modified == new Date().getTime() (>this.cachedResponse.getLastModified()) the first time the pipeline is called and that the next and future times the pipeline is called it will (due to line 279 in AbstractCachingProcessingPipeline.processXMLPipeline) have Last-Modified==this.cachedResponse.getLastModified(). It could happen that this would confuse the browser. Probably it doesn't matter at all, but as caching is notouriosly hard to test, and rather subtle, I would like to understand your reasoning exactly. > Pipelines more HTTP-compliant (respecting and producing HTTP headers and > status codes) > -- > > Key: COCOON-2009 > URL: https://issues.apache.org/jira/browse/COCOON-2009 > Project: Cocoon > Issue Type: Improvement > Components: - Components: Sitemap >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-pipeline-impl-http-compliant-patch-1.txt > > > This issue was discussed a little here: > http://news.gmane.org/find-root.php?group=gmane.text.xml.cocoon.devel&article=70383 > Main aim is to respect cache-related headers and produce necessary > information for clients to do proper caching. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1993) Make Forms resources loaded directly
[ https://issues.apache.org/jira/browse/COCOON-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474282 ] Daniel Fagerstrom commented on COCOON-1993: --- The samples works for me. But as said above we cannot apply it until it either works with 2.1 (which seem complicated) or until we have stoped sharing the 2.1 and 2.2 code. > Make Forms resources loaded directly > > > Key: COCOON-1993 > URL: https://issues.apache.org/jira/browse/COCOON-1993 > Project: Cocoon > Issue Type: Sub-task > Components: Blocks: Forms >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-forms-impl-patch-1.txt, > cocoon-forms-impl-patch-2.txt, cocoon-forms-impl-patch-3.txt, > cocoon-forms-impl-patch-4.txt, cocoon-forms-sample-patch-1.txt, > cocoon-forms-sample-patch-2.txt, cocoon-forms-sample-patch-3.txt > > > Steps required to achieve this goal are the same as in > https://issues.apache.org/jira/browse/COCOON-1992 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1992) Make Ajax resourced loaded directly from cocoon-ajax-impl
[ https://issues.apache.org/jira/browse/COCOON-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474281 ] Daniel Fagerstrom commented on COCOON-1992: --- The samples works for me. But as you say above we cannot apply it until it either works with 2.1 (which seem complicated) or until we have stoped sharing the 2.1 and 2.2 code. > Make Ajax resourced loaded directly from cocoon-ajax-impl > - > > Key: COCOON-1992 > URL: https://issues.apache.org/jira/browse/COCOON-1992 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: Ajax >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-ajax-impl-patch-1.txt, > cocoon-ajax-impl-patch-2.txt, cocoon-ajax-sample-patch-1, > cocoon-ajax-sample-patch-2.txt, cocoon-ajax-sample-patch-3.txt > > > This task includes: > 1. creating new sitemap in cocoon-ajax-impl and registering it as servlet in > dispatcher from servelt-service-fw. > 2. Fixing paths in cocoon-ajax-samples -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1997) Configure servlet: links rewriting
[ https://issues.apache.org/jira/browse/COCOON-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Fagerstrom closed COCOON-1997. - Resolution: Fixed > Configure servlet: links rewriting > -- > > Key: COCOON-1997 > URL: https://issues.apache.org/jira/browse/COCOON-1997 > Project: Cocoon > Issue Type: Sub-task > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: > cocoon-servlet-service-components-linkrewriting-patch-2.txt, > cocoon-servlet-service-impl-linkrewriting-transformer-patch-1.txt, > cocoon-webapp-switch-to-servlet-service-patch-1.txt > > > This issue is on configuring (or creating new) transformer that will take > care of servlet: link rewriting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1996) New input module: StringConcatMetaModule
[ https://issues.apache.org/jira/browse/COCOON-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Fagerstrom closed COCOON-1996. - Resolution: Fixed > New input module: StringConcatMetaModule > > > Key: COCOON-1996 > URL: https://issues.apache.org/jira/browse/COCOON-1996 > Project: Cocoon > Issue Type: New Feature > Components: - Components: Sitemap >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski >Priority: Minor > Fix For: 2.2-dev (Current SVN) > > Attachments: > cocoon-sitemap-components-StringConcatMetaModule-patch.txt > > > StringConcatMetaModule concats strings from configured module chain. It > assumes that all modules have string attributes, on the contrary, it calls > toString() method. > If null is returned by some module RuntimeException will be thrown. > For configuration of input module chain take a look at example on > ChainMetaModule. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2008) servletContext of BlockPathModule persists between seperate requests
[ https://issues.apache.org/jira/browse/COCOON-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Fagerstrom closed COCOON-2008. - Resolution: Fixed > servletContext of BlockPathModule persists between seperate requests > > > Key: COCOON-2008 > URL: https://issues.apache.org/jira/browse/COCOON-2008 > Project: Cocoon > Issue Type: Bug > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > Attachments: COCOON-2008-prototype-scope.txt, COCOON-2008.txt > > > The same servlet context is being reused between _separate_ requests leading > to returning invalid absolute uri's. > It seems that this line: > this.servletContext = CallStackHelper.getBaseServletContext(); > is being called only once, when BlockPathModule is used first time, and then > servletContext is never null (holds old value). > I'm not sure, but it seems that life cycle of this class is not set up > correctly. Even though I'm going to figure it out, it would be great if > someone with better Spring/Cocoon internals knowledge could take a look on > this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1954) [Patch] RequestProcessor swallows exceptions in blocks case
[ https://issues.apache.org/jira/browse/COCOON-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Fagerstrom closed COCOON-1954. - Resolution: Fixed > [Patch] RequestProcessor swallows exceptions in blocks case > --- > > Key: COCOON-1954 > URL: https://issues.apache.org/jira/browse/COCOON-1954 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core, - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek > Attachments: > cocoon-request-processor-swallows-exceptions-for-blocks.patch > > > While updating to the latest Cocoon I stepped into the problem that you > cannot see the exceptions thrown in a BlockServlet called by another one, > since the new refactored RequestProcessor swallows all exceptions. The > generated error page is fed into the response output stream which is > eventually read by anything in the calling pipeline, which mostly cannot > handle that html error page (in my case it gets some xml) and will throw > another exception like SAXParseException. > This patch adds a boolean rethrowExceptions() method to the RequestProcessor > that is used inside service() to check whether a catched exception should be > rethrown. The standard return value is false, in the subclass > o.a.c.sitemap.SitemapServlet$RequestProcessor it returns true so that the > exception is passed on to the "root" sitemap (handling the servletrequest > that actually comes from a browser or so) which will eventually create the > error page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1993) Make Forms resources loaded directly
[ https://issues.apache.org/jira/browse/COCOON-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474039 ] Daniel Fagerstrom commented on COCOON-1993: --- The new content and location of manifest.js seem to be lacking in the patch. Now it is only removed. > Make Forms resources loaded directly > > > Key: COCOON-1993 > URL: https://issues.apache.org/jira/browse/COCOON-1993 > Project: Cocoon > Issue Type: Sub-task > Components: Blocks: Forms >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski (aka g[R]eK) > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-forms-impl-patch-1.txt, > cocoon-forms-impl-patch-2.txt, cocoon-forms-impl-patch-3.txt, > cocoon-forms-sample-patch-1.txt, cocoon-forms-sample-patch-2.txt, > cocoon-forms-sample-patch-3.txt > > > Steps required to achieve this goal are the same as in > https://issues.apache.org/jira/browse/COCOON-1992 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1997) Configure servlet: links rewriting
[ https://issues.apache.org/jira/browse/COCOON-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474022 ] Daniel Fagerstrom commented on COCOON-1997: --- Applied. Thanks for the patches! > Configure servlet: links rewriting > -- > > Key: COCOON-1997 > URL: https://issues.apache.org/jira/browse/COCOON-1997 > Project: Cocoon > Issue Type: Sub-task > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski (aka g[R]eK) > Fix For: 2.2-dev (Current SVN) > > Attachments: > cocoon-servlet-service-components-linkrewriting-patch-2.txt, > cocoon-servlet-service-impl-linkrewriting-transformer-patch-1.txt, > cocoon-webapp-switch-to-servlet-service-patch-1.txt > > > This issue is on configuring (or creating new) transformer that will take > care of servlet: link rewriting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1996) New input module: StringConcatMetaModule
[ https://issues.apache.org/jira/browse/COCOON-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472920 ] Daniel Fagerstrom commented on COCOON-1996: --- Applied. Thanks! > New input module: StringConcatMetaModule > > > Key: COCOON-1996 > URL: https://issues.apache.org/jira/browse/COCOON-1996 > Project: Cocoon > Issue Type: New Feature > Components: - Components: Sitemap >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski (aka g[R]eK) >Priority: Minor > Fix For: 2.2-dev (Current SVN) > > Attachments: > cocoon-sitemap-components-StringConcatMetaModule-patch.txt > > > StringConcatMetaModule concats strings from configured module chain. It > assumes that all modules have string attributes, on the contrary, it calls > toString() method. > If null is returned by some module RuntimeException will be thrown. > For configuration of input module chain take a look at example on > ChainMetaModule. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2008) servletContext of BlockPathModule persists between seperate requests
[ https://issues.apache.org/jira/browse/COCOON-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472910 ] Daniel Fagerstrom commented on COCOON-2008: --- I added some faulty code while testing call stack scoped beans. My intention was to use a scope proxied servlet context from the setServletContext if such a property was present in the configuration and otherwise get the current call stack frame. But instead I just got the current call stack frame the first time the getAttribute and used that value to set the property. So in the sequel the same value was used. This problem could be fixed by using prototype scope as you suggested. But it seemed better to continue to have singleton scope and fix the faulty logic. So I did that. Please check that it works in your context. > servletContext of BlockPathModule persists between seperate requests > > > Key: COCOON-2008 > URL: https://issues.apache.org/jira/browse/COCOON-2008 > Project: Cocoon > Issue Type: Bug > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski (aka g[R]eK) > Fix For: 2.2-dev (Current SVN) > > Attachments: COCOON-2008-prototype-scope.txt, COCOON-2008.txt > > > The same servlet context is being reused between _separate_ requests leading > to returning invalid absolute uri's. > It seems that this line: > this.servletContext = CallStackHelper.getBaseServletContext(); > is being called only once, when BlockPathModule is used first time, and then > servletContext is never null (holds old value). > I'm not sure, but it seems that life cycle of this class is not set up > correctly. Even though I'm going to figure it out, it would be great if > someone with better Spring/Cocoon internals knowledge could take a look on > this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1950) org.apache.cocoon.blocks.util.RequestParameters incorrectly parses Multi-byte symbols
[
https://issues.apache.org/jira/browse/COCOON-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464507
]
Daniel Fagerstrom commented on COCOON-1950:
---
Applied, thanks for the patch. Please check.
> org.apache.cocoon.blocks.util.RequestParameters incorrectly parses Multi-byte
> symbols
> -
>
> Key: COCOON-1950
> URL: https://issues.apache.org/jira/browse/COCOON-1950
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.8, 2.1.9
>Reporter: Bohdan Mushkevych
>
> In cases, when request comes in unicode and contains both single byte and
> multi byte symbols, Cocoon processes them incorrectly
> The validator crashes with the requst like:
> http://localhost:8080/service?navigationID=/media/mmc2
> &selectionIDList=4200053228%094200053227%094200053226%094200053225
> &selectionIDListDisp=%u4F0F%u5C14%u52A0%09%u4F0F%u5C14%u52A0%20%3E%20%u673A%u52A8%u8F66%09%u4F0F%u5C14%u52A0%20%3E%20%u673A%u52A8%u8F66%20%3E%20%u658B%09%u4F0F%u5C14%u52A0%20%3E%20%u673A%u52A8%u8F66%20%3E%20%u658B%20%3E%20%u5149%u5B66%u8BC6%u522B%u7CFB%u7EDF
> &selectionTopNList=4200053228%09%u4F0F%u5C14%u52A0%094200053227%09%u4F0F%u5C14%u52A0%20%3E%20%u673A%u52A8%u8F66%094200053226%09%u4F0F%u5C14%u52A0%20%3E%20%u673A%u52A8%u8F66%20%3E%20%u658B%094200053225%09%u4F0F%u5C14%u52A0%20%3E%20%u673A%u52A8%u8F66%20%3E%20%u658B%20%3E%20%u5149%u5B66%u8BC6%u522B%u7CFB%u7EDF&
> As it stands from the code below, parseName method symply extracts 2
> characters after % and works ok with pattrens %YY
> however, it does not handle %u correctly:
> private String parseName(String s)
> {
> StringBuffer sb = new StringBuffer();
> for(int i = 0; i < s.length(); i++)
> {
> char c = s.charAt(i);
> switch(c)
> {
> case 43: // '+'
> sb.append(' ');
> break;
> case 37: // '%'
> try
> {
> sb.append((char)Integer.parseInt(s.substring(i + 1, i +
> 3), 16));
> i += 2;
> break;
> ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1964) Redirects inside a block called via the blocks protocol fail
[
https://issues.apache.org/jira/browse/COCOON-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464506
]
Daniel Fagerstrom commented on COCOON-1964:
---
The patch seem a little bit dangerous to me. Wouldn't it be better to try to
fix the problem in the form flowscript?
> Redirects inside a block called via the blocks protocol fail
>
>
> Key: COCOON-1964
> URL: https://issues.apache.org/jira/browse/COCOON-1964
> Project: Cocoon
> Issue Type: Bug
> Components: - Blocks Framework
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Alexander Klimetschek
> Attachments: cocoon-allow-redirect-in-called-block.patch
>
>
> If you do a redirect (from within a piece of flowscript
> "cocoon.redirectTo('cocoon:/foobar')" or via redirect-to in the sitemap)
> inside a block that was called via the block: protocol will fail since the
> re-use of the outputstream of the response (which happens to be a
> BlockCallHttpServletResponse) does not work.
> This is due to the use of getWriter() after getOutputStream() has already
> been called. The servlet api says that only one of them should be called, so
> there is a check in the implementation of getWriter() that will throw an
> IllegalStateException. The patch removes that check, which is kinda hack, but
> I don't know of any other cases within cocoon where such a re-use is made.
> The problem could be avoided if during the redirect a reset() or
> resetBuffer() would be called on the response, but for some reason this does
> not happen with a redirect from within a flowscript for a form.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1955) [Patch] Allow shielded class loading for a single block
[ https://issues.apache.org/jira/browse/COCOON-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464505 ] Daniel Fagerstrom commented on COCOON-1955: --- Apllied, thanks for the patch. Please check. > [Patch] Allow shielded class loading for a single block > --- > > Key: COCOON-1955 > URL: https://issues.apache.org/jira/browse/COCOON-1955 > Project: Cocoon > Issue Type: New Feature > Components: * Cocoon Core, - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek > Attachments: cocoon-aop-shieldingblockservlet.patch, > cocoon-enable-shielded-block-libs.patch, > cocoon-new-shieldingblockservlet.patch > > > == Problem == > When trying to integrate Apache Solr in our Cocoon webapplication, we got a > problem with conflicting versions of jars. Our jackrabbit block needs an old > lucene, whereas Solr wants a fresh new lucene nightly build. > == Solution == > Since we integrate the SolrServlet (and the other servlets from solar) inside > a BlockServlet to have them all inside our cocoon webapp with consistent > URLs, we considered adding a ShieldingServlet. Thus the BlockServlet wraps > the ShieldingServlet which in turn wraps the SolrServlet. The configuration > for the BlockServlet bean looks like this: > class="org.apache.cocoon.blocks.BlockServlet"> > > > value="org.apache.cocoon.bootstrap.servlet.ShieldingServlet" /> > value="blockcontext:/mindquarry-solr-block/" /> > > > > value="org.apache.solr.servlet.SolrServlet" /> > value="/paranoid-classpath.txt" /> >value="true" /> > > value="org.apache.cocoon.classloader.DefaultClassLoaderFactory" /> > > > > The directory structure of the solr-block: > src/main/resources/ >COB-INF/ > paranoid-classpath.txt > paranoid-lib/ > .jar > (including the jar which contains the > solr servlet) > META-INF/ > cocoon/ > spring/ > solr-blockservlet.xml > The paranoid-classpath.txt contains the following single line: > lib-dir: context:paranoid-lib > == The Patch == > To get the ShieldingServlet work with the blocks-fw and the basic shielding > that is done in the Cocoon webapp anyway (via a ShieldingListener in the > web.xml), two things must be done: > a) The BootstrapClassLoaderManager in cocoon-bootstrap must not store the > classloader it creates in a static variable so that in each call of > getClassLoader() a new ClassLoader is created. That method is exactly called > 2 times in our situation: first by the cocoon webapp shielding listener and > then by the ShieldingServlet in our block. > b) The method BlockContext.getResourcePaths() must be implemented to list the > resources in that block context (stuff under COB-INF of that block). > Lots of the work was done by my colleague Alexander Saar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1954) [Patch] RequestProcessor swallows exceptions in blocks case
[ https://issues.apache.org/jira/browse/COCOON-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464470 ] Daniel Fagerstrom commented on COCOON-1954: --- Applied, please check. Thanks for the patch. > [Patch] RequestProcessor swallows exceptions in blocks case > --- > > Key: COCOON-1954 > URL: https://issues.apache.org/jira/browse/COCOON-1954 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core, - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek > Attachments: > cocoon-request-processor-swallows-exceptions-for-blocks.patch > > > While updating to the latest Cocoon I stepped into the problem that you > cannot see the exceptions thrown in a BlockServlet called by another one, > since the new refactored RequestProcessor swallows all exceptions. The > generated error page is fed into the response output stream which is > eventually read by anything in the calling pipeline, which mostly cannot > handle that html error page (in my case it gets some xml) and will throw > another exception like SAXParseException. > This patch adds a boolean rethrowExceptions() method to the RequestProcessor > that is used inside service() to check whether a catched exception should be > rethrown. The standard return value is false, in the subclass > o.a.c.sitemap.SitemapServlet$RequestProcessor it returns true so that the > exception is passed on to the "root" sitemap (handling the servletrequest > that actually comes from a browser or so) which will eventually create the > error page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1939) Stack overflow when inheriting from block that alread inherits from another one
[ http://issues.apache.org/jira/browse/COCOON-1939?page=comments#action_12446406 ] Daniel Fagerstrom commented on COCOON-1939: --- I found the problem with the latest patch and have hopefully solved that with a new patch. There still might be some problems left though. For example I don't think inheritance works in three levels. And also the inheritance of properties need some more review. I'll return to it. I would appriciate if you could contribute extensions to the cocoon-blocks-fw-sample that illustrates the cases that you have had problems with this far. in a later step we should build unit test cases from the examples. > Stack overflow when inheriting from block that alread inherits from another > one > --- > > Key: COCOON-1939 > URL: http://issues.apache.org/jira/browse/COCOON-1939 > Project: Cocoon > Issue Type: Bug > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek > > There are problems with the following scenario: I have one Block A, another > one B that has A as super-block defined and a third one C that has B as > super-block defined. > The super-relation between B and A works ok, but if you start in C, then > forward to B, which in turn wants to forward to block A (all via the > block:super: protocol), a stack overflow happens. It looks like he always > thinks he is in C, so that block:super: from B will always get to B, thus > creating an endless loop. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1939) Stack overflow when inheriting from block that alread inherits from another one
[ http://issues.apache.org/jira/browse/COCOON-1939?page=comments#action_12445360 ] Daniel Fagerstrom commented on COCOON-1939: --- Forgot to mention that I commited the fix. > Stack overflow when inheriting from block that alread inherits from another > one > --- > > Key: COCOON-1939 > URL: http://issues.apache.org/jira/browse/COCOON-1939 > Project: Cocoon > Issue Type: Bug > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek > > There are problems with the following scenario: I have one Block A, another > one B that has A as super-block defined and a third one C that has B as > super-block defined. > The super-relation between B and A works ok, but if you start in C, then > forward to B, which in turn wants to forward to block A (all via the > block:super: protocol), a stack overflow happens. It looks like he always > thinks he is in C, so that block:super: from B will always get to B, thus > creating an endless loop. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1939) Stack overflow when inheriting from block that alread inherits from another one
[ http://issues.apache.org/jira/browse/COCOON-1939?page=comments#action_12445359 ] Daniel Fagerstrom commented on COCOON-1939: --- The BlockContext wasn't pushed at the BlockCallStack when doing a polymorphic call through the block protocol, like block:/foo in your example, this made subsequent block protocol call be called relative to the wrong context of the super block A instead of relative the context of B. Please check if it solves the problem for you. > Stack overflow when inheriting from block that alread inherits from another > one > --- > > Key: COCOON-1939 > URL: http://issues.apache.org/jira/browse/COCOON-1939 > Project: Cocoon > Issue Type: Bug > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek > > There are problems with the following scenario: I have one Block A, another > one B that has A as super-block defined and a third one C that has B as > super-block defined. > The super-relation between B and A works ok, but if you start in C, then > forward to B, which in turn wants to forward to block A (all via the > block:super: protocol), a stack overflow happens. It looks like he always > thinks he is in C, so that block:super: from B will always get to B, thus > creating an endless loop. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1939) Stack overflow when inheriting from block that alread inherits from another one
[ http://issues.apache.org/jira/browse/COCOON-1939?page=comments#action_12444741 ] Daniel Fagerstrom commented on COCOON-1939: --- Implemented the fix described above. Not much testing though. Please check that your usecase works, and close the issue if that is the case. > Stack overflow when inheriting from block that alread inherits from another > one > --- > > Key: COCOON-1939 > URL: http://issues.apache.org/jira/browse/COCOON-1939 > Project: Cocoon > Issue Type: Bug > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek > > There are problems with the following scenario: I have one Block A, another > one B that has A as super-block defined and a third one C that has B as > super-block defined. > The super-relation between B and A works ok, but if you start in C, then > forward to B, which in turn wants to forward to block A (all via the > block:super: protocol), a stack overflow happens. It looks like he always > thinks he is in C, so that block:super: from B will always get to B, thus > creating an endless loop. -- 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-1943) [Patch] Parameters in blocks-protocol URIs get decoded too early
[ http://issues.apache.org/jira/browse/COCOON-1943?page=all ]
Daniel Fagerstrom closed COCOON-1943.
-
Resolution: Fixed
The patch is applied, thanks for the patch.
For reference, the offtopic issue is discussed in
http://marc.theaimsgroup.com/?t=11617765091&r=1&w=2.
> [Patch] Parameters in blocks-protocol URIs get decoded too early
>
>
> Key: COCOON-1943
> URL: http://issues.apache.org/jira/browse/COCOON-1943
> Project: Cocoon
> Issue Type: Bug
> Components: - Blocks Framework
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Alexander Klimetschek
> Attachments: cocoon-blocks-fw-raw-encoded-URIs.patch
>
>
> When you pass parameters in the query part of a block-protocol URI, eg.
> "block:super:/dosomething?param1=alpha¶m2=beta", and they include some
> encoded stuff, eg. "" encoded as "%3Cbr/%3E", this will get decoded
> before the actual servlet request happens. This takes place in
> BlockConnection.parseBlockURI() when uri.getSchemeSpecificPart() is called,
> which will decode the string. Instead, one should call
> uri.getRawSchemeSpecificPart(), which is exactly what the patch does.
> (A little bit Off-topic): The general point here is that I am calling a form
> that is handled in the super block. Since you cannot pass on request
> parameters from a POST call (that comes from the browser) to the other
> (super) block called via the blocks-protocol (because the only interface you
> have is the Source, where you can only pass information via the URI), you
> have to put all parameters in the uri. I have written a simple input module
> that creates a "param1=alpha¶m2=beta" string from another input module
> (preferrably request-param) so that you simply call:
> "block:super:/dosomething?{params-to-uri:request-param}". This might be
> integrated into Cocoon as a standard InputModule.
--
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-1940) [Patch] NPE in BlockCallHttpServletRequest.getSession()
[ http://issues.apache.org/jira/browse/COCOON-1940?page=all ] Daniel Fagerstrom closed COCOON-1940. - Resolution: Fixed Applied, thanks for the patch. The implementation of the servlet APIs within the blocks fw are rather uncomplete as, so there are still plenty of methods that needs top be fixed to do anything meanifull. > [Patch] NPE in BlockCallHttpServletRequest.getSession() > --- > > Key: COCOON-1940 > URL: http://issues.apache.org/jira/browse/COCOON-1940 > Project: Cocoon > Issue Type: Bug > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek > Attachments: cocoon-blocks-fw-create-HttpSession.patch > > > The BlockCallHttpServletRequest returns a null HttpSession in getSession(). > This leads to an NPE in code accessing the request's session. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1939) Stack overflow when inheriting from block that alread inherits from another one
[ http://issues.apache.org/jira/browse/COCOON-1939?page=comments#action_12444507 ] Daniel Fagerstrom commented on COCOON-1939: --- Thanks for spotting this subtle bug. The call mechanism for inheritance uses a stack. Say that you have an inheritance B->A (A is super block to B). If you call an uri in B, "block:B:/foo", the block context for B will be pushed on the BlockCallStack. Then say that "/foo" isn't defined in block B, in this case it will be called in the super block A instead (the super block is found through the connection map element with the name "super"). But when a super block is called the block context is *not* pushed, so the block context of block B still is on the top of the stack. Say then that while evaluating "/foo", block A do a polymorphic call "block:/bar". Such calls are always done relative the block context on the top of the stack i.e. the context of block B. So "/bar" will first be evaluated in block B and if not foun d there in its super block A. This far everything work as it should even for the case you described above C -> B -> A. Now the problem is that "block:super:/foo" is evaluated relative the top of the call stack. instead of relative the currently called blocks context. This happens to work in the case of inheritance in one step (B->A), as if you call super in the block B, the current block and the block on the call stack is the same: B. But in the case you described above it will not work as B will call its super block relative C rather than it self, and thus get into an infinite loop as you experienced. What needs to be done to solve this problem is to push all called blocks contexts on the stack and mark the super calls in some way. Then a super call should be done relative the top block context, and other (polymorphic) calls should be made relative to the top *non* super call block context. > Stack overflow when inheriting from block that alread inherits from another > one > --- > > Key: COCOON-1939 > URL: http://issues.apache.org/jira/browse/COCOON-1939 > Project: Cocoon > Issue Type: Bug > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek > > There are problems with the following scenario: I have one Block A, another > one B that has A as super-block defined and a third one C that has B as > super-block defined. > The super-relation between B and A works ok, but if you start in C, then > forward to B, which in turn wants to forward to block A (all via the > block:super: protocol), a stack overflow happens. It looks like he always > thinks he is in C, so that block:super: from B will always get to B, thus > creating an endless loop. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1938) [Patch] Allow blocks mounted at "/" to handle more than just the "/" URL
[ http://issues.apache.org/jira/browse/COCOON-1938?page=comments#action_1279 ] Daniel Fagerstrom commented on COCOON-1938: --- IMO "/style.css" and "/index.html" are not mounted on "/" but on "". With this intepretation the implementation works, although it might be somewhat subtle and should be documented. If we compare with web.xml the "root" servlet is mounted on "/*" rather than on "/", but that requires wildcard handling which I found to be overkill. We could introduce special handling for "/" as you suggest, but in that case the equation: uri = contextPath + servletPath + mountPath + pathInfo, will not be valid anymore. Opinions? > [Patch] Allow blocks mounted at "/" to handle more than just the "/" URL > > > Key: COCOON-1938 > URL: http://issues.apache.org/jira/browse/COCOON-1938 > Project: Cocoon > Issue Type: Improvement > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek >Priority: Minor > Attachments: cocoon-blocks-fw-improve-root-mounting.patch > > > The current DispatcherServlet allows for blocks mounted at "/" only the > simple "/" URL to be handled because all other cases (eg. "/style.css" or > "/index.html") will be interpreted as blocks - and because these don't exist, > the matching will fail. > For this case, I added a short piece of code that will allow to handle such > cases for the root block. -- 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-1935) [Patch] NPE in ResourceReader when InputSource returns null on getURI
[ http://issues.apache.org/jira/browse/COCOON-1935?page=all ] Daniel Fagerstrom closed COCOON-1935. - Resolution: Fixed Applied (both patches). Thanks for spotting the bug. > [Patch] NPE in ResourceReader when InputSource returns null on getURI > - > > Key: COCOON-1935 > URL: http://issues.apache.org/jira/browse/COCOON-1935 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core, - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek >Priority: Critical > Attachments: cocoon-blocksource-fix-getURI-NPE.patch, > cocoon-core-resourcereader-getURI-NPE.patch > > > The ResourceReader crashes on a NPE when the InputSource returns a null > String in getURI() while checking the cache and the lastmodified value. > The problem was very invisible because the exception was completely hidden > due to reflection when calling the ResourceReader from the pipeline. > Problem was triggered by the BlockSource, which falsely returns a null > systemId in getURI(). To solve the problem there are two ways, both included > as patches: fix the ResourceReader and fix the BlockSource. -- 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-1934) [Patch] Allow file system URLs for blockContextURL in BlockServlets
[ http://issues.apache.org/jira/browse/COCOON-1934?page=all ] Daniel Fagerstrom closed COCOON-1934. - Resolution: Fixed Applied. Thanks for the patch. > [Patch] Allow file system URLs for blockContextURL in BlockServlets > --- > > Key: COCOON-1934 > URL: http://issues.apache.org/jira/browse/COCOON-1934 > Project: Cocoon > Issue Type: Improvement > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek > Attachments: cocoon-blocks-fw-filesystem-for-blockContextURL.patch > > > When configuring a BlockServlet, you have to specify a blockContextURL which > is used to find the resources for a block (eg. the sitemap when using a > SitemapServlet inside). Currently it does not accept file:/ URLs, which are > useful if you want the development resource reloading feature and have that > URL directly point to the src/main/resources/COB-INF folder. > This patch allows file:// URLs by explicitly checking for them and directly > creating the corresponding URL object. In all other cases, the normal URL > handling of the servlet context is used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1802) Script for m10n of old blocks
[ http://issues.apache.org/jira/browse/COCOON-1802?page=comments#action_12370979 ] Daniel Fagerstrom commented on COCOON-1802: --- I have fixed the simple build problems related to artifactIds and version numbers in SVN: Added the suffix -impl to some block dependencies to reflect the standard structure. Also changed version 2.2-SNAPSHOT to 1.0-SNAPSHOT for block dependencies, only cocoon-core has version 2.2. Removed dependencies on cocoon-test-core, that don't exists anymore, the test is part of the cocoon-core following standard Maven idiom. I am not sure if the cocoon-core test classes are available for other modules however, have not tested. As long as we have connection problems with some of the involved Maven repositories, I suggest that we not move all of the blocks to trunk. That will make the first build (and artifact download) even more painful than today. We could move some important remaining but not all of them. > Script for m10n of old blocks > - > > Key: COCOON-1802 > URL: http://issues.apache.org/jira/browse/COCOON-1802 > Project: Cocoon > Type: New Feature > Components: - Build System: Maven > Versions: 2.2-dev (Current SVN) > Reporter: Andreas Hochsteger > Attachments: m10n-blocks.zip, m10n-blocks.zip > > See thread starting with > http://www.mail-archive.com/dev@cocoon.apache.org/msg42233.html for > discussion details. > Here's the info from the file README.txt: > What is it? > --- > m10n-blocks.sh is a script which automates parts of the conversion from the > "old" blocks to the "new" mavenized ones. > Configuration > - > Only 2 variables have to be adjusted: > blksrc: > Local directory where https://svn.apache.org/repos/asf/cocoon/blocks is > checked out > blkdest: > Local directory where https://svn.apache.org/repos/asf/cocoon/trunk is > checked out > Usage > - > # ./m10n-blocks.sh ... > Example: > # ./m10n-blocks.sh asciiart faces > Conventions > --- > The script assumes, that every block will consist of a parent block > (cocoon-), an implementation block (cocoon--impl) > and a sample block (cocoon--sample). > TODOs > - > The subversion commands are currently untested and commented-out. > The implementation pom has to be manually merged with the original pom of the > "old" block. In many cases it is enough to add the dependencies. > The build section should not be merged, since the new directory structure uses > maven defaults and thus doesn't need a special configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1769) Role Handling
[ http://issues.apache.org/jira/browse/COCOON-1769?page=comments#action_12365186 ] Daniel Fagerstrom commented on COCOON-1769: --- ATM role handling works for core components as I explicitly include resource://org/apache/cocoon/cocoon.roles in ECMBlockServiceManager, so that all blocks get the cocoon.roles in their local role manager. That is obviously a hack that not generalize to the situation where other blocks declare roles. The role handling do basically two different things, it provide shorthands (like the file key above) and it provide default implementations for roles. For the default implementations this could possibly be solved with letting the service manager register the role together with the service manager that contains the role manager with the default in it, in the ServiceManagerRegistry. If the role manager register default values before the actual component registrations, an explicit declaration of a role would overwrite the default implementation (I know, it is hacky and fragile scheme). For the shorthands the situation is more complicated, I don't think that they just can be saved in a global registry with a association to a certain block container, as one role shorthand can be connected several selector keys that can be connected to components in several blocks. One way is to require that each used role file is included in the component configuration that uses it. Another is to consider the shorthand as a component that contain the full role name and let the ECMBlockServiceManager do a two step lookup when it gets a "shorthand component". > Role Handling > - > > Key: COCOON-1769 > URL: http://issues.apache.org/jira/browse/COCOON-1769 > Project: Cocoon > Type: Sub-task > Components: - Blocks Framework > Reporter: Daniel Fagerstrom > > The concept of role handling is Avalon specific, so it doesn't work that well > if we want to register e.g. our sitemap components as OSGi services or Spring > components. Maybe we could just put the role info in the container as well so > that we don't need to maintain a parallel set of rolemanagers for the > blocks. -- 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-1770) Component Configuration
Component Configuration --- Key: COCOON-1770 URL: http://issues.apache.org/jira/browse/COCOON-1770 Project: Cocoon Type: Sub-task Components: - Blocks Framework Reporter: Daniel Fagerstrom There is no mechanism implemented yet for deployment parameters for components in blocks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1764) Component handling
[ http://issues.apache.org/jira/browse/COCOON-1764?page=comments#action_12365175 ] Daniel Fagerstrom commented on COCOON-1764: --- The implementation is changed to a global registry. The current soultion is rather ECM specific though, and more work is needed to make it work with OSGi. > Component handling > -- > > Key: COCOON-1764 > URL: http://issues.apache.org/jira/browse/COCOON-1764 > Project: Cocoon > Type: New Feature > Components: - Blocks Framework > Reporter: Reinhard Poetz > > see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113813135727508&w=2 > In the current implementation of blocks, each block has an own component > manager (the choice of which type is configurable) for managing the > components of the block. The block local CM has an InterBlockServiceManager > as parent manager and through it it can access components from component > managers in other blocks that it is *wired* to, (and not from the other > blocks of the system). Let us call this behavior wiring based CM for later > reference. > Now I'm starting to think that the above described behavior is unnecessarily > complicated and has some other problems as well. So if no one protests I'm > going to change it so that the blocks still has own component managers, but > that they register their (exposed) components in a global registry and that > the parent manager of the local component managers access components from the > global registry and not only from the connected blocks. > Consequences > > A global registry is much more similar to the situation in our "compile time" > blocks than the wiring based CM, so it should be easier to migrate, > furthermore so is a global registry used in OSGi so it will be more future > safe as well. > A global registry requires less configuration in block.xml and wiring.xml. It > is enough to declare the dependency on the interfaces of the components in > the POM. If one want to make certain that a certain block is used at run > time, a run time dependency can declared in the POM. Connections in the > block.xml is only used for declaring inter block servlet communication. > A possible disadvantage is that role names could collide in the global > registry but by using URIs or package names it should be possible to > distinguish between components from different manufacturers. > The global registry approach might give run time errors when components are > missing instead of deploy time errors. But this depends to a large extent on > what lookup strategy the components and the local CMs use. If most of the > component lookup is done from within the components using a service manager > the setup problems might be defered to runtime. But if configuration based > dependency injection is used the problems can at least in principle be > detected early. > Local vs Global CMs > --- > A question that not will matter much until we use OSGi is whether the CMs are > used from within the block or from the outside. > The current design assumes that the CM is internal to each block. The reason > for this is that with OSGi R3 it was, IIUC, the only way to be able to have > the implementation classes for the components internal to the bundle. A > global CM would have requried that all implementation packages to be exported. > With R4 there are some new possibilities, one can get a class loader from a > bundle and use that for constructing components in a global CM. OSGi R4 uses > this for the new declarative services manager. A bundle that want to use the > declarative service manager signals that by pointing out its component > declaration with a special manifest header, "Service-Component". We could > have a similar global ECM++ manager for legacy support. It is rather probable > that there will be a OSGi adapted Spring CM, following the same principles. >--- o0o --- > AFAIR, we haven't discussed what lookup strategy we wanted for components in > blocks, I implemented the wiring based strategy because it seemed more > natural for me before. The OSGi CM bridge that Sylvain implemented used OSGis > service registry as a global registry. Gianugo tried to convince me that > global registry was better at ApacheCon, but I was obviously not ready for it > then -- 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-1769) Role Handling
Role Handling - Key: COCOON-1769 URL: http://issues.apache.org/jira/browse/COCOON-1769 Project: Cocoon Type: Sub-task Components: - Blocks Framework Reporter: Daniel Fagerstrom The concept of role handling is Avalon specific, so it doesn't work that well if we want to register e.g. our sitemap components as OSGi services or Spring components. Maybe we could just put the role info in the container as well so that we don't need to maintain a parallel set of rolemanagers for the blocks. -- 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
