[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.
[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] 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.
Re: Sling graduates from the Apache Incubator!
Congrats, I guess it should help with project adoption among the broader audience considerably. Cheers Greg
Re: Sling graduates from the Apache Incubator!
Congratulations!! Valentin Jacquemin On Thu, Jun 18, 2009 at 10:49 AM, Paul Noden wrote: > 2009/6/18 Bertrand Delacretaz > > > 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 >
[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.
[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.
Re: SVN moved
On Thu, Jun 18, 2009 at 11:26 AM, Felix Meschberger 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
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: [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
Re: Sling graduates from the Apache Incubator!
2009/6/18 Bertrand Delacretaz > 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
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
[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
[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.
[jira] Commented: (SLING-1007) Implement helper classloader
[ https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
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 * Bertrand Delacretaz * Christophe Lombart * Carsten Ziegeler * Felix Meschberger * Gianugo Rabellino * Padraic Hannon * Juan José Vázquez Delgado * Karl Pauls * Vidar Ramdal 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
