[jira] Updated: (SLING-41) Create synthetic content in sling:include if real content does not exist
[ https://issues.apache.org/jira/browse/SLING-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-41: --- Summary: Create synthetic content in sling:include if real content does not exist (was: Create synthetic content content on sling:include if real content does not exist) > Create synthetic content in sling:include if real content does not exist > > > Key: SLING-41 > URL: https://issues.apache.org/jira/browse/SLING-41 > Project: Sling > Issue Type: Improvement > Components: JSP >Affects Versions: 2.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Consider a page component which includes a footer. Such a footer may or may > not exist. If no real content exists, it would be usefull, if a simple > Content instance with just the path and the component ID would be created to > render a default footer. To support this feature, a new attribute - the > component id - needs to be added to the sling:include tag. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-41) Create synthetic content in sling:include if real content does not exist
[ https://issues.apache.org/jira/browse/SLING-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-41. -- Resolution: Fixed First I added another implementation of the Content interface: org.apache.sling.content.jcr.SyntheticContent. This implementation is a blank extension of the abstract BaseContent class, which provides a constructor taking a path and component ID. This class makes it easy to provide content to the system to call specific handling. The sling:include tag is extended with a new componentId attribute, which only is used if the path attribute is set and the content attribute is not set: If the componentId attribute is set, the tag handler tries to request a Content object for the set path. If such a Content object exists, that object is used. If no such content object exists, a SyntheticContent instance is created with the set path and component Id. This synthetic Content object is then used. If the componentId attribute is not set, the path is forwarded to the request dispatcher for further treatment. Please be aware of the slight semantic difference regarding the path depending on whether the compoinentId attribute is set or not: If the componentId is not set, the path may include selectors and extensions besides the path to the Content itself as the request dispatcher is able to find the Content object and then use the selectors and extensions as input to the included Component. If the componentId is set, the request dispatcher is not used to find the Content object, instead the path must exactly address the content. > Create synthetic content in sling:include if real content does not exist > > > Key: SLING-41 > URL: https://issues.apache.org/jira/browse/SLING-41 > Project: Sling > Issue Type: Improvement > Components: JSP >Affects Versions: 2.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Consider a page component which includes a footer. Such a footer may or may > not exist. If no real content exists, it would be usefull, if a simple > Content instance with just the path and the component ID would be created to > render a default footer. To support this feature, a new attribute - the > component id - needs to be added to the sling:include tag. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-41) Create synthetic content in sling:include if real content does not exist
[ https://issues.apache.org/jira/browse/SLING-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-41: --- Component/s: Content Add Content component as the SyntheticContent has been created as part of the Content component. > Create synthetic content in sling:include if real content does not exist > > > Key: SLING-41 > URL: https://issues.apache.org/jira/browse/SLING-41 > Project: Sling > Issue Type: Improvement > Components: Content, JSP >Affects Versions: 2.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Consider a page component which includes a footer. Such a footer may or may > not exist. If no real content exists, it would be usefull, if a simple > Content instance with just the path and the component ID would be created to > render a default footer. To support this feature, a new attribute - the > component id - needs to be added to the sling:include tag. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-31) maven-sling-plugin: build failure caused by qdox/maven-plugin-tools-java
[ https://issues.apache.org/jira/browse/SLING-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532592 ] Felix Meschberger commented on SLING-31: Hmm, the BundleDeployFileMojo has a Java five attribute (@Override) at that location. Could it be that you are trying to compile with an older version of Maven or the Maven Plugin Plugin ? > maven-sling-plugin: build failure caused by qdox/maven-plugin-tools-java > > > Key: SLING-31 > URL: https://issues.apache.org/jira/browse/SLING-31 > Project: Sling > Issue Type: Bug > Components: Plugin > Environment: Mac OS X 10.4.10 (8R218), PowerPC > java version "1.5.0_07" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) > Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing) >Reporter: Oliver Lietz > > had to change qdox version in maven-plugin-tools-java's pom.xml from 1.5 to > 1.6.1 to prevent following build failure: > [INFO] [plugin:descriptor] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] syntax error @[45,5] in > file:/[...]/sling/trunk/maven-sling-plugin/src/main/java/org/apache/sling/maven/bundlesupport/BundleDeployFileMojo.java > [INFO] > > [INFO] Trace > com.thoughtworks.qdox.parser.ParseException: syntax error @[45,5] in > file:/[...]/sling/trunk/maven-sling-plugin/src/main/java/org/apache/sling/maven/bundlesupport/BundleDeployFileMojo.java > at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:504) > at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:610) > at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:488) > [...] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-42) Potential NullPointerException when initializing Components
Potential NullPointerException when initializing Components --- Key: SLING-42 URL: https://issues.apache.org/jira/browse/SLING-42 Project: Sling Issue Type: Bug Components: Core Affects Versions: 2.0.0 Reporter: Felix Meschberger Fix For: 2.0.0 When a Component is registered with the system, the ComponentResolverFilter gets them and if active calls the Component.init method. This may happen at a time, that the ComponentRequestHandlerImpl is not registered yet with the HttpService and thus the ServletContext is still null. If now the Component init method tries to access the ServletContext of the provided ComponentContext, a NullPointerException is thrown. This whole registration mechanism must be modified such as to only call the init methods when the ComponentRequestHandlerImpl is registered with the HttpService and has itself been provided with the ServletConfig and ServletContext of the servlet container. This exception may be seen if the Sling sampl bundle is started before the Sling core bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-31) maven-sling-plugin: build failure caused by qdox/maven-plugin-tools-java
[ https://issues.apache.org/jira/browse/SLING-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532632 ] Felix Meschberger commented on SLING-31: Thanks for the hint. I will update the the Sling parent pom to reer to plugin plugin 2.3. Thanks for reporting. > maven-sling-plugin: build failure caused by qdox/maven-plugin-tools-java > > > Key: SLING-31 > URL: https://issues.apache.org/jira/browse/SLING-31 > Project: Sling > Issue Type: Bug > Components: Plugin > Environment: Mac OS X 10.4.10 (8R218), PowerPC > java version "1.5.0_07" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) > Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing) >Reporter: Oliver Lietz >Assignee: Felix Meschberger > Attachments: pom.diff > > > had to change qdox version in maven-plugin-tools-java's pom.xml from 1.5 to > 1.6.1 to prevent following build failure: > [INFO] [plugin:descriptor] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] syntax error @[45,5] in > file:/[...]/sling/trunk/maven-sling-plugin/src/main/java/org/apache/sling/maven/bundlesupport/BundleDeployFileMojo.java > [INFO] > > [INFO] Trace > com.thoughtworks.qdox.parser.ParseException: syntax error @[45,5] in > file:/[...]/sling/trunk/maven-sling-plugin/src/main/java/org/apache/sling/maven/bundlesupport/BundleDeployFileMojo.java > at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:504) > at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:610) > at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:488) > [...] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-31) maven-sling-plugin: build failure caused by qdox/maven-plugin-tools-java
[ https://issues.apache.org/jira/browse/SLING-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-31: -- Assignee: Felix Meschberger > maven-sling-plugin: build failure caused by qdox/maven-plugin-tools-java > > > Key: SLING-31 > URL: https://issues.apache.org/jira/browse/SLING-31 > Project: Sling > Issue Type: Bug > Components: Plugin > Environment: Mac OS X 10.4.10 (8R218), PowerPC > java version "1.5.0_07" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) > Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing) >Reporter: Oliver Lietz >Assignee: Felix Meschberger > Attachments: pom.diff > > > had to change qdox version in maven-plugin-tools-java's pom.xml from 1.5 to > 1.6.1 to prevent following build failure: > [INFO] [plugin:descriptor] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] syntax error @[45,5] in > file:/[...]/sling/trunk/maven-sling-plugin/src/main/java/org/apache/sling/maven/bundlesupport/BundleDeployFileMojo.java > [INFO] > > [INFO] Trace > com.thoughtworks.qdox.parser.ParseException: syntax error @[45,5] in > file:/[...]/sling/trunk/maven-sling-plugin/src/main/java/org/apache/sling/maven/bundlesupport/BundleDeployFileMojo.java > at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:504) > at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:610) > at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:488) > [...] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-31) maven-sling-plugin: build failure caused by qdox/maven-plugin-tools-java
[ https://issues.apache.org/jira/browse/SLING-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz updated SLING-31: -- Attachment: pom.diff Maven 2.07, I only had Maven Plugin Plugin 2.0 in my local m2 repo. Adding Maven Plugin Plugin 2.3 to parent's pom.xml pluginManagement also fixes this problem. > maven-sling-plugin: build failure caused by qdox/maven-plugin-tools-java > > > Key: SLING-31 > URL: https://issues.apache.org/jira/browse/SLING-31 > Project: Sling > Issue Type: Bug > Components: Plugin > Environment: Mac OS X 10.4.10 (8R218), PowerPC > java version "1.5.0_07" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) > Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing) >Reporter: Oliver Lietz > Attachments: pom.diff > > > had to change qdox version in maven-plugin-tools-java's pom.xml from 1.5 to > 1.6.1 to prevent following build failure: > [INFO] [plugin:descriptor] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] syntax error @[45,5] in > file:/[...]/sling/trunk/maven-sling-plugin/src/main/java/org/apache/sling/maven/bundlesupport/BundleDeployFileMojo.java > [INFO] > > [INFO] Trace > com.thoughtworks.qdox.parser.ParseException: syntax error @[45,5] in > file:/[...]/sling/trunk/maven-sling-plugin/src/main/java/org/apache/sling/maven/bundlesupport/BundleDeployFileMojo.java > at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:504) > at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:610) > at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:488) > [...] -- 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: (SLING-31) maven-sling-plugin: build failure caused by qdox/maven-plugin-tools-java
[ https://issues.apache.org/jira/browse/SLING-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532622 ] olli edited comment on SLING-31 at 10/5/07 4:19 AM: Maven 2.0.7, I only had Maven Plugin Plugin 2.0 in my local m2 repo. Adding Maven Plugin Plugin 2.3 to parent's pom.xml pluginManagement also fixes this problem. was (Author: olli): Maven 2.07, I only had Maven Plugin Plugin 2.0 in my local m2 repo. Adding Maven Plugin Plugin 2.3 to parent's pom.xml pluginManagement also fixes this problem. > maven-sling-plugin: build failure caused by qdox/maven-plugin-tools-java > > > Key: SLING-31 > URL: https://issues.apache.org/jira/browse/SLING-31 > Project: Sling > Issue Type: Bug > Components: Plugin > Environment: Mac OS X 10.4.10 (8R218), PowerPC > java version "1.5.0_07" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) > Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing) >Reporter: Oliver Lietz > Attachments: pom.diff > > > had to change qdox version in maven-plugin-tools-java's pom.xml from 1.5 to > 1.6.1 to prevent following build failure: > [INFO] [plugin:descriptor] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] syntax error @[45,5] in > file:/[...]/sling/trunk/maven-sling-plugin/src/main/java/org/apache/sling/maven/bundlesupport/BundleDeployFileMojo.java > [INFO] > > [INFO] Trace > com.thoughtworks.qdox.parser.ParseException: syntax error @[45,5] in > file:/[...]/sling/trunk/maven-sling-plugin/src/main/java/org/apache/sling/maven/bundlesupport/BundleDeployFileMojo.java > at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:504) > at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:610) > at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:488) > [...] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-31) maven-sling-plugin: build failure caused by qdox/maven-plugin-tools-java
[ https://issues.apache.org/jira/browse/SLING-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-31. Resolution: Fixed Fix Version/s: 2.0.0 Added org.apache.maven.plugins maven-plugin-plugin 2.3 to the plugin management section of the Sling parent POM . Please close this issue if this fixes your problem. Thanks. Fixed in Rev. 582217. > maven-sling-plugin: build failure caused by qdox/maven-plugin-tools-java > > > Key: SLING-31 > URL: https://issues.apache.org/jira/browse/SLING-31 > Project: Sling > Issue Type: Bug > Components: Plugin > Environment: Mac OS X 10.4.10 (8R218), PowerPC > java version "1.5.0_07" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) > Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing) >Reporter: Oliver Lietz >Assignee: Felix Meschberger > Fix For: 2.0.0 > > Attachments: pom.diff > > > had to change qdox version in maven-plugin-tools-java's pom.xml from 1.5 to > 1.6.1 to prevent following build failure: > [INFO] [plugin:descriptor] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] syntax error @[45,5] in > file:/[...]/sling/trunk/maven-sling-plugin/src/main/java/org/apache/sling/maven/bundlesupport/BundleDeployFileMojo.java > [INFO] > > [INFO] Trace > com.thoughtworks.qdox.parser.ParseException: syntax error @[45,5] in > file:/[...]/sling/trunk/maven-sling-plugin/src/main/java/org/apache/sling/maven/bundlesupport/BundleDeployFileMojo.java > at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:504) > at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:610) > at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:488) > [...] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-40) Define proper ContentResolver service
[ https://issues.apache.org/jira/browse/SLING-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532653 ] Felix Meschberger commented on SLING-40: Removed the old interfaces in the org.apache.sling.core.mapper package in Rev. 582247. These interfaces were very outdated and dysfunctional. They are replaced by the new o.a.s.core.ResolvedURL and o.a.s.core.ContentResovler interfaces. > Define proper ContentResolver service > - > > Key: SLING-40 > URL: https://issues.apache.org/jira/browse/SLING-40 > Project: Sling > Issue Type: New Feature > Components: Core >Affects Versions: 2.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Mapping request URI paths to Content objects is currently implemented in the > URLMapperFilter, which is registered as a request filter for Sling. Other > than that this functionality is not currently usable. > Instead the mapping functionality should be defined in a separate service, > which we could name ContentResolver (just like the ComponentResolver which > selects the component) . This service may be implemented by a specifialized > class. That class might even provide for extensibility. > The URLMapperFilter should be renamed to ContentResolverFilter to match the > service name and would be refactored to use the ContentResolver service as > available and log appropriate messges if missing. Actually, the filter could > be the service itself, but it should be ensured, that the filter would be > available even in the absence of a repository to provide meaningfull error > handling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-42) Potential NullPointerException when initializing Components
[ https://issues.apache.org/jira/browse/SLING-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-42: -- Assignee: Felix Meschberger > Potential NullPointerException when initializing Components > --- > > Key: SLING-42 > URL: https://issues.apache.org/jira/browse/SLING-42 > Project: Sling > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > When a Component is registered with the system, the ComponentResolverFilter > gets them and if active calls the Component.init method. This may happen at a > time, that the ComponentRequestHandlerImpl is not registered yet with the > HttpService and thus the ServletContext is still null. If now the Component > init method tries to access the ServletContext of the provided > ComponentContext, a NullPointerException is thrown. > This whole registration mechanism must be modified such as to only call the > init methods when the ComponentRequestHandlerImpl is registered with the > HttpService and has itself been provided with the ServletConfig and > ServletContext of the servlet container. > This exception may be seen if the Sling sampl bundle is started before the > Sling core bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-40) Define proper ContentResolver service
[ https://issues.apache.org/jira/browse/SLING-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532659 ] Felix Meschberger commented on SLING-40: Renamed the URLMapperFilter to ComponentResolverFilter and added the ResolvedURL and ContentResolver interfaces (part of the o.a.s.core.resolver package and not the core package directly as mentioned above). Also the metatype.properties file as been adapted to reflect the property names defined in the ComponentResolverFilter. Fixed in Rev. 582254. > Define proper ContentResolver service > - > > Key: SLING-40 > URL: https://issues.apache.org/jira/browse/SLING-40 > Project: Sling > Issue Type: New Feature > Components: Core >Affects Versions: 2.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Mapping request URI paths to Content objects is currently implemented in the > URLMapperFilter, which is registered as a request filter for Sling. Other > than that this functionality is not currently usable. > Instead the mapping functionality should be defined in a separate service, > which we could name ContentResolver (just like the ComponentResolver which > selects the component) . This service may be implemented by a specifialized > class. That class might even provide for extensibility. > The URLMapperFilter should be renamed to ContentResolverFilter to match the > service name and would be refactored to use the ContentResolver service as > available and log appropriate messges if missing. Actually, the filter could > be the service itself, but it should be ensured, that the filter would be > available even in the absence of a repository to provide meaningfull error > handling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-42) Potential NullPointerException when initializing Components
[ https://issues.apache.org/jira/browse/SLING-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-42. -- Resolution: Fixed Fixed by reorganizing the order in which the ComponentRequestHandlerImpl is activated. Now servlet is first registered with the HttpService and only after that is are the registered Component Filters initialized. Fixed in Rev. 582254. > Potential NullPointerException when initializing Components > --- > > Key: SLING-42 > URL: https://issues.apache.org/jira/browse/SLING-42 > Project: Sling > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > When a Component is registered with the system, the ComponentResolverFilter > gets them and if active calls the Component.init method. This may happen at a > time, that the ComponentRequestHandlerImpl is not registered yet with the > HttpService and thus the ServletContext is still null. If now the Component > init method tries to access the ServletContext of the provided > ComponentContext, a NullPointerException is thrown. > This whole registration mechanism must be modified such as to only call the > init methods when the ComponentRequestHandlerImpl is registered with the > HttpService and has itself been provided with the ServletConfig and > ServletContext of the servlet container. > This exception may be seen if the Sling sampl bundle is started before the > Sling core bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-40) Define proper ContentResolver service
[ https://issues.apache.org/jira/browse/SLING-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-40. -- Resolution: Fixed This issue can be closed as the service has been implemented and the old URLMapperFilter replaced by the new ContentResolverFilter. > Define proper ContentResolver service > - > > Key: SLING-40 > URL: https://issues.apache.org/jira/browse/SLING-40 > Project: Sling > Issue Type: New Feature > Components: Core >Affects Versions: 2.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Mapping request URI paths to Content objects is currently implemented in the > URLMapperFilter, which is registered as a request filter for Sling. Other > than that this functionality is not currently usable. > Instead the mapping functionality should be defined in a separate service, > which we could name ContentResolver (just like the ComponentResolver which > selects the component) . This service may be implemented by a specifialized > class. That class might even provide for extensibility. > The URLMapperFilter should be renamed to ContentResolverFilter to match the > service name and would be refactored to use the ContentResolver service as > available and log appropriate messges if missing. Actually, the filter could > be the service itself, but it should be ensured, that the filter would be > available even in the absence of a repository to provide meaningfull error > handling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-39) RequestDispatcher should use ContentResolver to try to resolve paths to Content objects
[ https://issues.apache.org/jira/browse/SLING-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-39. -- Resolution: Fixed Adapted various parts in Sling Core for this. (1) The methods to access the resolved URL parts like Content, selectors, extension, suffix are moved from the RequestData to the ContentData. Now an included component has its own selectors, extension and suffix. (2) The ComponentContextImpl class has been modified for support for the ContentResolver to feed a path provided to it to decompose the path, should it contain selectors, extension and suffix. Please note, that there may still be some loose ends in this area: * Parameters (?xxx&xx&xx..) are not yet supported by the Sling RequestDispatcher * It should probably be decided what to do in case an included content has no selector, extension and/or suffix. Should they just be empty (as in the default) or should the respective values from the parent (including) component/content be inherited ? > RequestDispatcher should use ContentResolver to try to resolve paths to > Content objects > --- > > Key: SLING-39 > URL: https://issues.apache.org/jira/browse/SLING-39 > Project: Sling > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Currently the Sling RequestDispatcher just tries to use the exact path to > resolve a Content object. Instead the ContentResolver should be used to > enable supplying selectors and extensions to the included request. > In addition supplying such information is not currently implemented in the > request inclusion functionality. This must also be implemented. As well > support must be added to the sling:include tag when used with the content > attribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Sling Report
Hi all, As we are new to the incubator, we have to report monthly and the reports are due again :-) I created a page on our wiki [1] to catch what we ultimately would report. Please add anything you might feel needed such that we can finalize the report by Oct. 10. Thanks and Regards Felix [1] http://cwiki.apache.org/confluence/x/vAkB
[jira] Created: (SLING-43) Extend the sling-app project by support to build a complete jar file
Extend the sling-app project by support to build a complete jar file Key: SLING-43 URL: https://issues.apache.org/jira/browse/SLING-43 Project: Sling Issue Type: Improvement Components: Launcher Affects Versions: 2.0.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 When building the sling-app project a JAR file is created which contains the launcher, the Felix framework, the OSGi core and compendium interfaces as well as core bundles installed and started on first start. This package contains enough bundles to launch Sling and present the Sling Management Console so as to install more bundles to complete the Sling environment. It would be practical to have a bundling of all bundles needed for a complete Sling environment in one JAR file. This could be implemented in the pom with a separate build profile, which just lists the additional dependencies and includes them the same way as in the default build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Web Framework Integration (was how to build sling components with complex user interaction and write capabilities?)
Hi Edgar, Sorry for the belated answer, I was busy fixing issues and extending Sling over the last few days. Taking your original mail apart for easier tracking of the issues raised. Am Montag, den 24.09.2007, 11:34 -0300 schrieb Edgar Poce: > First of all congratulations for the good work!. I've been playing > with sling the last few days and I like the framework very much. Thank you very much ! As you may have seen I also committed a small sample project which shows some of the functionality of Sling in action. > My first impression is that Sling is an integration framework. My > understanding is that Sling provides the glue to integrate different > applications but it doesn't provide the tools to build rich web based > applications as others web frameworks do, e.g. wicket. Is this > impression correct? and in case it is, would it be a good idea to use > another web framework to build a Sling component?. You are probably right, yes. Sling itself provides close to no web framework support. As such we will probably have to build integration points for other web frameworks of which Wicket in fact came to my mind first. What I am thinking of is some Component/Content implementations to adapt Wicket into Sling. Yet, I have to admit, that I did not yet do any research in this direction. Of course any suggestions and patches in this direction would be very welcome. Regards Felix
Components Writing Content (was: how to build sling components with complex user interaction and write capabilities?)
Hi,
Am Montag, den 24.09.2007, 11:34 -0300 schrieb Edgar Poce:
> Another doubt is what's the recommended practice to create a simple
> sling component with write capabilities, how the component should
> access the jcr repository to perform write operations? and how the jcr
> session should be acquired?
The nice thing about Sling is, that you do not have to write the data
yourself by acquiring a session and calling all these JCR methods. You
just take the Content you get from the request, update it using the
Content's setter methods and call the ContentManager.store(Content)
method. That is all.
For example: Consider you have a TextComponent and a TextContent, where
the TextContent has a title and a text field. In your
TextComponent.service() method you might do the following:
if ("POST".equalsIgnoreCase(request.getMethod())) {
TextContext textContent = (TextContent) request.getContent();
textContent.setTitle(request.getParameter("title"));
textContent.setText(request.getParameter("text"));
ContentManager contentManager = (ContentManager)
request.getAttribute(org.apache.sling.core.Constants.ATTR_CONTENT_MANAGER);
contentManager.store(textContent);
contentManager.save();
}
This is more or less the idea. If you look at the
org.apache.sling.core.components.DefaultComponent you will see more
elaborate code showing this intention.
To create content, you would just instantiate your Content object, set
the properties and call the ContentManager.create(String path, Content
content) (currently missing, see SLING-44 [1]) to store the content at
the given path.
Hope this helps.
Regards
Felix
[1] https://issues.apache.org/jira/browse/SLING-44
[jira] Created: (SLING-44) Add ContentManager.create(String path, Content content) method
Add ContentManager.create(String path, Content content) method -- Key: SLING-44 URL: https://issues.apache.org/jira/browse/SLING-44 Project: Sling Issue Type: New Feature Components: Content Affects Versions: 2.0.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 Currently the ContentManager interface has only one method to create a Content instance, which takes a path, the Content class and a Map of properties to be set on a Content instance to be created by the method. A method to create Content object in the component and have that object stored would be an important enhancement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-43) Extend the sling-app project by support to build a complete jar file
[ https://issues.apache.org/jira/browse/SLING-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-43. -- Resolution: Fixed Commited the extend pom with a new build profile "full", which builds said JAR file using the "full" classifier on the file created. In addition, I modified the dependency plugin configuration to not strip the version names off the jar files copied such that it is easier to see, what is actually contained in the package (this is of course only convenience as the running framework has the final knowledge of what is installed at what version). > Extend the sling-app project by support to build a complete jar file > > > Key: SLING-43 > URL: https://issues.apache.org/jira/browse/SLING-43 > Project: Sling > Issue Type: Improvement > Components: Launcher >Affects Versions: 2.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > When building the sling-app project a JAR file is created which contains the > launcher, the Felix framework, the OSGi core and compendium interfaces as > well as core bundles installed and started on first start. This package > contains enough bundles to launch Sling and present the Sling Management > Console so as to install more bundles to complete the Sling environment. > It would be practical to have a bundling of all bundles needed for a complete > Sling environment in one JAR file. This could be implemented in the pom with > a separate build profile, which just lists the additional dependencies and > includes them the same way as in the default build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Move ContentManager to Sling API
Hi all,
Upon replying to Edgar's question regarding writing Content, I came to
thinking, that the ContentManager is a core interface of Sling and
probably should be made available more prominently. The most prominent
location for an interface in Sling would be the Sling API itself.
What do you think of moving the o.a.s.content.ContentManager interface
to the Sling API and provide it through the ComponentRequest instead of
having to access a request attribute:
public interface ComponentRequest extends HttpServletRequest {
public ContentManager getContentManager();
}
What do you think ? If feedback is positive, I would also include this
in the Sling API proposal (SLING-28).
Regards
Felix
[jira] Updated: (SLING-44) Replace ContentManager.create(String, Class, Map) by create(Content) method
[ https://issues.apache.org/jira/browse/SLING-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-44: --- Description: The create(String, Class, Map) method was once assumed to take the responsibility to abstractly create and configure a Content object on behalf of Components or even on behalf of some system functionality at a time, where the Component interface had split methods to handle actions and rendering. Nowadays the Component interface just has one single service method (and is to be removed as per SLING-28 pending vote) and it is assumed that each Component implementation would knows its Content implementation and would be able to set the fields from any request parameters. If a requirment for a generic Content generator would rise again, I suggest to implement that on higher level than the "low-level" ContentManager. So the new method would be create(Content) which would just store the Content object at the location described by the Content.getPath() field. Any opinions on this ? Or proposals for better names, by that matter ? was:Currently the ContentManager interface has only one method to create a Content instance, which takes a path, the Content class and a Map of properties to be set on a Content instance to be created by the method. A method to create Content object in the component and have that object stored would be an important enhancement. Summary: Replace ContentManager.create(String, Class, Map) by create(Content) method (was: Add ContentManager.create(String path, Content content) method) Retargeting this issue to actually replace the create(String, Class, Map) method by a new create(Content) method. > Replace ContentManager.create(String, Class, Map) by create(Content) method > --- > > Key: SLING-44 > URL: https://issues.apache.org/jira/browse/SLING-44 > Project: Sling > Issue Type: New Feature > Components: Content >Affects Versions: 2.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > The create(String, Class, Map) method was once assumed to take the > responsibility to abstractly create and configure a Content object on behalf > of Components or even on behalf of some system functionality at a time, where > the Component interface had split methods to handle actions and rendering. > Nowadays the Component interface just has one single service method (and is > to be removed as per SLING-28 pending vote) and it is assumed that each > Component implementation would knows its Content implementation and would be > able to set the fields from any request parameters. If a requirment for a > generic Content generator would rise again, I suggest to implement that on > higher level than the "low-level" ContentManager. > So the new method would be create(Content) which would just store the Content > object at the location described by the Content.getPath() field. > Any opinions on this ? Or proposals for better names, by that matter ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Move ContentManager to Sling API
Felix Meschberger wrote:
> Hi all,
>
> Upon replying to Edgar's question regarding writing Content, I came to
> thinking, that the ContentManager is a core interface of Sling and
> probably should be made available more prominently. The most prominent
> location for an interface in Sling would be the Sling API itself.
>
> What do you think of moving the o.a.s.content.ContentManager interface
> to the Sling API and provide it through the ComponentRequest instead of
> having to access a request attribute:
>
> public interface ComponentRequest extends HttpServletRequest {
>
> public ContentManager getContentManager();
>
>
>
> What do you think ? If feedback is positive, I would also include this
> in the Sling API proposal (SLING-28).
>
I'm not sure - it definitly makes repository based components much
easier, but draws in some stuff into the (now simple) sling api and the
core. As ContentManager does not have any further dependencies this
seems to be ok.
So I'm +0 on this :)
I'm wondering if it is sufficient to have a single content manager in
the application? Or could it be that some components might use a
different content manager than others? For example some components
writing/reading from one workspace or others doing it with another
workspace?
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
Re: Move ContentManager to Sling API
Am Freitag, den 05.10.2007, 17:14 +0200 schrieb Carsten Ziegeler: > > What do you think ? If feedback is positive, I would also include this > > in the Sling API proposal (SLING-28). > > > I'm not sure - it definitly makes repository based components much > easier, but draws in some stuff into the (now simple) sling api and the > core. As ContentManager does not have any further dependencies this > seems to be ok. That is the point: The ContentManager makes no actual references to any concrete storage, it is only its (currently only one) extension JcrContentManager which brings in the JCR Repository. But this would remain in the content bundle. > > So I'm +0 on this :) > > I'm wondering if it is sufficient to have a single content manager in > the application? Or could it be that some components might use a > different content manager than others? For example some components > writing/reading from one workspace or others doing it with another > workspace? Well having the getContentManager method would allow for ComponentRequestWrapper implementations to overwrite this method and return a different ContentManager while still allowing access to the original one by just unwrapping and wrapped requests. This is not as easy with the request attribute based solution. On the other hand, nobody is hindered to get the JcrContentManagerFactory service and acquire a different JcrContentManager for specific use cases. Regards Felix
Re: Move ContentManager to Sling API
On 5 Oct 2007, at 15:56, Felix Meschberger wrote:
What do you think of moving the o.a.s.content.ContentManager interface
to the Sling API and provide it through the ComponentRequest
instead of
having to access a request attribute:
public interface ComponentRequest extends HttpServletRequest {
public ContentManager getContentManager();
}
What do you think ? If feedback is positive, I would also include this
in the Sling API proposal (SLING-28).
Having done some work recently with Day Communique, one of the
annoying things was that it subclasses HttpServletRequest.
-1
--
Torgeir Veimo
[EMAIL PROTECTED]
Re: Move ContentManager to Sling API
Hi Torgeir, Am Freitag, den 05.10.2007, 17:25 +0100 schrieb Torgeir Veimo: > Having done some work recently with Day Communique, one of the > annoying things was that it subclasses HttpServletRequest. Can you please elaborate on this ? Because we initially did not extend HttpServletRequest but found that extending it would make the implementation much easier in multiple places not the least support for running JSP scripts. Regards Felix
Re: Move ContentManager to Sling API
On 5 Oct 2007, at 17:30, Felix Meschberger wrote: Hi Torgeir, Am Freitag, den 05.10.2007, 17:25 +0100 schrieb Torgeir Veimo: Having done some work recently with Day Communique, one of the annoying things was that it subclasses HttpServletRequest. Can you please elaborate on this ? Because we initially did not extend HttpServletRequest but found that extending it would make the implementation much easier in multiple places not the least support for running JSP scripts. I feel it's cleaner to fetch the manager from some sort of factory instance. It wouldn't expose the implementation details of how the manager is kept local to the request, nor does it make any dependent code reliant on any such implementation details staying stable. As you say yourself, you now keep the manager as a request-scoped attribute, but would like to make a subclass of HttpServletRequest include a method to retrieve it. If you used a factory to retrieve the manager, that change wouldn't have any impact on any code that uses that manager. The factory method to retrieve the manager could easily take an HttpServletRequest as parameter, which would allow you to implement it in any way you choose. -- Torgeir Veimo [EMAIL PROTECTED]
