Sling graduates from the Apache Incubator!
(ccing jackrabbit PMC as our incubation sponsor) (and friends!) Hi Sling community, I'm pleased to announce that our Board of Directors, at yesterday's meeting, approved the graduation of Sling as a top-level project. I abstained from that vote (as working on Sling is part of my job), so it's not my fault ;-) Felix Meschberger is the chair of the new PMC, composed of * Alexandru Popescu apopescu * Bertrand Delacretaz bdelacretaz * Christophe Lombart clombart * Carsten Ziegeler cziegeler * Felix Meschberger fmeschbe * Gianugo Rabellino gianugo * Padraic Hannon hannonpi * Juan José Vázquez Delgado juanjo * Karl Pauls pauls * Vidar Ramdal vramdal Mike Müller is not listed above but of course remains a documentor as mentioned at http://incubator.apache.org/sling/site/project-team.html. This is just not part of the board's vote, which is about establishing the new project and PMC. Felix is preparing the infrastructure move and will keep us informed. Thanks very much to all involved and let's take Apache Sling to the next level! -- Bertrand
[jira] Commented: (SLING-1007) Implement helper classloader
[ https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721113#action_12721113 ] Carsten Ziegeler commented on SLING-1007: - I'll start with the original issue and when we've finished that we can have a look at the other use case. Implement helper classloader Key: SLING-1007 URL: https://issues.apache.org/jira/browse/SLING-1007 Project: Sling Issue Type: New Feature Components: Commons OSGi Affects Versions: Commons OSGi 2.0.4 Reporter: Felix Meschberger Assignee: Carsten Ziegeler Currently we require the ScriptEngine[Factory] implementation bundles to create bundle header DynamicImport-Package: * to be able to access anything from the scripts since scripts are executed in the class loader of the script engine bundle. The downside of running the scripts in the class loader of the script engine bundle and using this global dynamic import are: * scripts see internal classes of the script engine bundle * scripts engine bundles must provide for classes for the scripts * whenever a wire has been created for a script and the providing bundle is updated or uninstalled, the script engine bundle is also cycled. A better approach might be to provide a ClassLoader implementation which behind the scenes manages access to packages exported by the bundles installed in the system. I would imagine such an implementation along the following lines: * Uses PackageAdmin to find a bundle providing the required class * Copes with bundles being updated or uninstalled Maybe coping with bundles being updated or uninstalled requires a two level approach: a fronend class loader which answers the class and resource accesses by relaying to a backend class loader. The back end classloader does the hardwork of loading classes and resources by querying bundles. Whenever a bundle is updated or uninstalled the backend classloader gets replaced. A similar approach has been chosen for the Repository ClassLoader in the jcr/classloader bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1007) Implement helper classloader
[ https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-1007: --- Assignee: Carsten Ziegeler Implement helper classloader Key: SLING-1007 URL: https://issues.apache.org/jira/browse/SLING-1007 Project: Sling Issue Type: New Feature Components: Commons OSGi Affects Versions: Commons OSGi 2.0.4 Reporter: Felix Meschberger Assignee: Carsten Ziegeler Currently we require the ScriptEngine[Factory] implementation bundles to create bundle header DynamicImport-Package: * to be able to access anything from the scripts since scripts are executed in the class loader of the script engine bundle. The downside of running the scripts in the class loader of the script engine bundle and using this global dynamic import are: * scripts see internal classes of the script engine bundle * scripts engine bundles must provide for classes for the scripts * whenever a wire has been created for a script and the providing bundle is updated or uninstalled, the script engine bundle is also cycled. A better approach might be to provide a ClassLoader implementation which behind the scenes manages access to packages exported by the bundles installed in the system. I would imagine such an implementation along the following lines: * Uses PackageAdmin to find a bundle providing the required class * Copes with bundles being updated or uninstalled Maybe coping with bundles being updated or uninstalled requires a two level approach: a fronend class loader which answers the class and resource accesses by relaying to a backend class loader. The back end classloader does the hardwork of loading classes and resources by querying bundles. Whenever a bundle is updated or uninstalled the backend classloader gets replaced. A similar approach has been chosen for the Repository ClassLoader in the jcr/classloader bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[FYI] OSGi DevCon Europe is next Monday in Zürich, Switzerland
Hi, See http://www.osgi.org/DevConEurope2009/Schedule. From the Sling crowd, Felix, Karl and myself will be giving talks, along with a number of other Apache people and OSGi gurus (including some from the intersection of several of those sets ;-) See you there, hopefully! -Bertrand
Graduation tasks
Hi all, as per the graduation task list [1], we have to move things around a bit. I have asked infra@ to support us here [2]. On the frontend the following tasks will be done: * Move SVN from below incubator to our new TLP location * Rename the mailing lists (I have asked infra to keep current subscriptions) * Prepare our new TLP web site I will keep you posted, most notably regarding the SVN move. Regards Felix [1]http://incubator.apache.org/guides/graduation.html#life-after-graduation [2]https://issues.apache.org/jira/browse/INFRA-2102
Re: Sling graduates from the Apache Incubator!
2009/6/18 Bertrand Delacretaz bdelacre...@apache.org I'm pleased to announce that our Board of Directors, at yesterday's meeting, approved the graduation of Sling as a top-level project. Congratulations to all involved, tremendous effort now things can only accelerate in terms of both use and contribution! Many Thanks! Paul Noden
Re: [FYI] OSGi DevCon Europe is next Mond ay in Zürich, Switzerland
Hi Bertrand, OSGi on Scala - Ease OSGi development with a Scala DSL [1]. Please take notes for me if you attend this session! Michael [1]http://www.osgi.org/DevConEurope2009/Speakers#Seeberger Bertrand Delacretaz wrote: Hi, See http://www.osgi.org/DevConEurope2009/Schedule. From the Sling crowd, Felix, Karl and myself will be giving talks, along with a number of other Apache people and OSGi gurus (including some from the intersection of several of those sets ;-) See you there, hopefully! -Bertrand
SVN moved
Hi all, Thanks to Jukka I could already move the Sling source in SVN to the new location. To adapt your local check-out just use the svn switch, like in: $ svn switch http://svn.apache.org/repos/asf/incubator/sling/trunk from inside your trunk checkout. Regards Felix
Re: SVN moved
On Thu, Jun 18, 2009 at 11:26 AM, Felix Meschberger fmesc...@gmail.com wrote: Thanks to Jukka I could already move the Sling source in SVN to the new location. To adapt your local check-out just use the svn switch, like in: $ svn switch http://svn.apache.org/repos/asf/incubator/sling/trunk I think you mean svn switch http://svn.apache.org/repos/asf/sling/trunk Thanks! -Bertrand
[jira] Created: (SLING-1011) Remove incubator from versions and remove disclaimer
Remove incubator from versions and remove disclaimer Key: SLING-1011 URL: https://issues.apache.org/jira/browse/SLING-1011 Project: Sling Issue Type: Task Components: General Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1011) Remove incubator from versions and remove disclaimer
[ https://issues.apache.org/jira/browse/SLING-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1011. --- Resolution: Fixed I've removed the DISCLAIMER files and disclaimer sections from the readme's. Converted the svn locations Converted the links to the website Removed the -incubator from the module versions Remove incubator from versions and remove disclaimer Key: SLING-1011 URL: https://issues.apache.org/jira/browse/SLING-1011 Project: Sling Issue Type: Task Components: General Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling graduates from the Apache Incubator!
Congratulations!! Valentin Jacquemin On Thu, Jun 18, 2009 at 10:49 AM, Paul Noden nod...@nodster.co.uk wrote: 2009/6/18 Bertrand Delacretaz bdelacre...@apache.org I'm pleased to announce that our Board of Directors, at yesterday's meeting, approved the graduation of Sling as a top-level project. Congratulations to all involved, tremendous effort now things can only accelerate in terms of both use and contribution! Many Thanks! Paul Noden
Re: Sling graduates from the Apache Incubator!
Congrats, I guess it should help with project adoption among the broader audience considerably. Cheers Greg
[jira] Created: (SLING-1012) JcrResourceResolverFactoryImpl does not register JcrResourceTypeProviders correctly.
JcrResourceResolverFactoryImpl does not register JcrResourceTypeProviders correctly. Key: SLING-1012 URL: https://issues.apache.org/jira/browse/SLING-1012 Project: Sling Issue Type: Bug Components: JCR Resource Affects Versions: JCR Resource 2.0.6 Reporter: Ian Boston JcrResourceResolverFactoryImpl only works for 0 or 1 JcrResourceTypeProvider Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1012) JcrResourceResolverFactoryImpl does not register JcrResourceTypeProviders correctly.
[ https://issues.apache.org/jira/browse/SLING-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston updated SLING-1012: -- Attachment: SLING-1012.patch This area could also do with a bit of updating since its all a bit inefficient, creating a new array on very request and synchronizing every request on an effectively immutable object. JcrResourceResolverFactoryImpl does not register JcrResourceTypeProviders correctly. Key: SLING-1012 URL: https://issues.apache.org/jira/browse/SLING-1012 Project: Sling Issue Type: Bug Components: JCR Resource Affects Versions: JCR Resource 2.0.6 Reporter: Ian Boston Attachments: SLING-1012.patch JcrResourceResolverFactoryImpl only works for 0 or 1 JcrResourceTypeProvider Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1003) Integration of 3rd party servlet filters problematic
[ https://issues.apache.org/jira/browse/SLING-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Sprecher updated SLING-1003: -- Attachment: RequestData.diff Patch for RequestData#unwrap(SlingHttpServletRequest): *foreign* ServletWrappers are allowed. Please test it carefully! It runs both with and without the webcastellum filter, but I only tested it in standard configuration, i.e. no special filters enabled Integration of 3rd party servlet filters problematic Key: SLING-1003 URL: https://issues.apache.org/jira/browse/SLING-1003 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.0.4 Environment: Windows Vista, java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing) Reporter: Christian Sprecher Assignee: Felix Meschberger Priority: Minor Fix For: Engine 2.0.6 Attachments: RequestData.diff, SlingWebCastellum-1.0.jar There is a problem within the chain handling: the 3rd party filter uses it's own wrapper for requests and response, and supplies it to the chain in the chain.doFilter() call. This leads to a ClassCastException on line 54 of AbstractSlingFilterChain: ... RequestProgressTracker tracker = ((SlingHttpServletRequest) request).getRequestProgressTracker(); ... I am not sure if this cast is valid in the context of a filter chain. On the other hand I am not sure wether such a use case (filter that manipulates request and response) has a chance to run in Sling. == Please note that this servlet filter needs to run as early as possible in the filter chain java.lang.ClassCastException: org.webcastellum.RequestWrapper cannot be cast to org.apache.sling.api.SlingHttpServletRequest at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter (AbstractSlingFilterChain.java:54) at org.webcastellum.WebCastellumFilter.internalDoFilter(WebCastellumFilt er.java:2610) at org.webcastellum.WebCastellumFilter.doFilter(WebCastellumFilter.java: 1710) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
