Re: creating new properties with HTTP request
>> I need to create more properties with HTTP request. When I send HTTP request >> with query string, which contents only one property, it's ok. >> I don't know, how can I separate more properties. (I tried coma and >> semicolon ) 2009/5/12 Tobias Bocanegra : > try '&' as delimiter. > > see: http://en.wikipedia.org/wiki/Query_string > and: > https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Functions/encodeURIComponent Actually, the semicolon is recommended by W3C [1], as the use of '&' often brings along some interesting escaping problems: "We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner." So maybe we should support ';' as a delimiter, in addition to '&'. WDYT? [1] http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 -- Vidar S. Ramdal - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
[jira] Commented: (SLING-967) Support davmount requests (RFC 4709)
[ https://issues.apache.org/jira/browse/SLING-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708809#action_12708809 ] Felix Meschberger commented on SLING-967: - Implementation support: * For Windows, the RFC contains the source for a Windows Script allowing to open davmount responses with Windows WebFolder * For Linux a gvfs-dav-mount tool is available in source from from http://github.com/gicmo/gvfs-dav-mount/tree/master > Support davmount requests (RFC 4709) > > > Key: SLING-967 > URL: https://issues.apache.org/jira/browse/SLING-967 > Project: Sling > Issue Type: New Feature > Components: JCR >Affects Versions: JCR Webdav 2.0.4 >Reporter: Felix Meschberger > > RFC 4709 [1] defines a file format and MIME type to convey WebDAV mount > information from servers to clients. > Generating such a response is easy for Sling in that the WebDAV support can > register servlet responding to the "davmount" extension, which maps to the > application/davmount+xml extension. This servlet would generate the correct > response. > For example a request to > http://host/some/content.davmount > might reply with > http://purl.org/NET/webdav/mount";> > http://host:80/ > some/content/ > > [1] http://www.ietf.org/rfc/rfc4709.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SLING-964) MimeTypeService: set correct default xml mimetype
[ https://issues.apache.org/jira/browse/SLING-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reopened SLING-964: - > Should this be fixed in Sling or in Commons? This is the Sling commons/mime project > I maintain the mime.types for Apache httpd, which is a lot more accurate than > any other source. > I suggest you merge the current version from Good idea. Reopening to update our file from the httpd file. > MimeTypeService: set correct default xml mimetype > - > > Key: SLING-964 > URL: https://issues.apache.org/jira/browse/SLING-964 > Project: Sling > Issue Type: Bug > Components: Commons MimeType >Affects Versions: Commons Mime 2.0.4 >Reporter: Dominique Jäggi >Assignee: Felix Meschberger >Priority: Minor > Fix For: Commons Mime 2.0.6 > > > currently the default mime type for .xml extensions is set to "text/html". > since this is deprecated i suggest updating the mime type to > "application/xml" as per spec. > i also suggest adding the mime type for rss: "application/rss+xml" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-964) MimeTypeService: set correct default xml mimetype
[ https://issues.apache.org/jira/browse/SLING-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-964. --- Resolution: Fixed Updated the mime type list with the types from Apache httpd in Rev. 774251. > MimeTypeService: set correct default xml mimetype > - > > Key: SLING-964 > URL: https://issues.apache.org/jira/browse/SLING-964 > Project: Sling > Issue Type: Bug > Components: Commons MimeType >Affects Versions: Commons Mime 2.0.4 >Reporter: Dominique Jäggi >Assignee: Felix Meschberger >Priority: Minor > Fix For: Commons Mime 2.0.6 > > > currently the default mime type for .xml extensions is set to "text/html". > since this is deprecated i suggest updating the mime type to > "application/xml" as per spec. > i also suggest adding the mime type for rss: "application/rss+xml" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-965) MimeTypeService: expose default mime types config in osgi web console
[ https://issues.apache.org/jira/browse/SLING-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708829#action_12708829 ] Felix Meschberger commented on SLING-965: - The MIME types are read by the MimeType service from all bundles containing "META-INF/mime.types" files. As such the actual MIME type configuration mainly depends on the bundles registered and thus exposure of these as OSGi configuration does not make sense. But, we could extend the MimeTypeService as follows * Plug into the web console listing all known MIME types * Add configuration support to add mime types by configuration > MimeTypeService: expose default mime types config in osgi web console > - > > Key: SLING-965 > URL: https://issues.apache.org/jira/browse/SLING-965 > Project: Sling > Issue Type: Improvement > Components: Commons MimeType >Affects Versions: Commons Mime 2.0.2 >Reporter: Dominique Jäggi >Priority: Minor > > please consider exposing the default mime types currently being defined in > launchpad's web.xml as an OSGi configuration accessible through the web > console or repository based content configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-967) Support davmount requests (RFC 4709)
[ https://issues.apache.org/jira/browse/SLING-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708831#action_12708831 ] Julian Reschke commented on SLING-967: -- More implementation support: * Xythos Drive Windows client (== SAP Portal Drive) Question: how about doing this in a way so that it can also be easily used from the base Jackrabbit WebDAV servlet? > Support davmount requests (RFC 4709) > > > Key: SLING-967 > URL: https://issues.apache.org/jira/browse/SLING-967 > Project: Sling > Issue Type: New Feature > Components: JCR >Affects Versions: JCR Webdav 2.0.4 >Reporter: Felix Meschberger > > RFC 4709 [1] defines a file format and MIME type to convey WebDAV mount > information from servers to clients. > Generating such a response is easy for Sling in that the WebDAV support can > register servlet responding to the "davmount" extension, which maps to the > application/davmount+xml extension. This servlet would generate the correct > response. > For example a request to > http://host/some/content.davmount > might reply with > http://purl.org/NET/webdav/mount";> > http://host:80/ > some/content/ > > [1] http://www.ietf.org/rfc/rfc4709.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: creating new properties with HTTP request
Hi, Vidar Ramdal schrieb: >>> I need to create more properties with HTTP request. When I send HTTP request >>> with query string, which contents only one property, it's ok. >>> I don't know, how can I separate more properties. (I tried coma and >>> semicolon ) > > 2009/5/12 Tobias Bocanegra : >> try '&' as delimiter. >> >> see: http://en.wikipedia.org/wiki/Query_string >> and: >> https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Functions/encodeURIComponent > > Actually, the semicolon is recommended by W3C [1], as the use of '&' > often brings along some interesting escaping problems: > > "We recommend that HTTP server implementors, and in particular, CGI > implementors support the use of ";" in place of "&" to save authors the > trouble of escaping "&" characters in this manner." > > So maybe we should support ';' as a delimiter, in addition to '&'. > WDYT? Sure. Now it of course depends on how is parsing the parameters. In the case of URL paramaters and application/x-www-form-urlencoded POST data, it is the servlet container parsing the parameters and we do nothing about it. Regards Felix
[jira] Commented: (SLING-967) Support davmount requests (RFC 4709)
[ https://issues.apache.org/jira/browse/SLING-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708840#action_12708840 ] Felix Meschberger commented on SLING-967: - For the base Jackrabbit WebDAV servlet, I would have proposed an IOHandler. But this has two drawbacks: (1) it would collide with the DirListingHandler and (2) trying to use a special extension will not easily work. Another option would be to overwrite the AbstractWebDavServlet.doGet method and check for the .davmount extension if the resource does not exist and return the dav mount response in this case Anyway, apart from the very simple core response generation, there is probably nothing, which could be shared... > Support davmount requests (RFC 4709) > > > Key: SLING-967 > URL: https://issues.apache.org/jira/browse/SLING-967 > Project: Sling > Issue Type: New Feature > Components: JCR >Affects Versions: JCR Webdav 2.0.4 >Reporter: Felix Meschberger > > RFC 4709 [1] defines a file format and MIME type to convey WebDAV mount > information from servers to clients. > Generating such a response is easy for Sling in that the WebDAV support can > register servlet responding to the "davmount" extension, which maps to the > application/davmount+xml extension. This servlet would generate the correct > response. > For example a request to > http://host/some/content.davmount > might reply with > http://purl.org/NET/webdav/mount";> > http://host:80/ > some/content/ > > [1] http://www.ietf.org/rfc/rfc4709.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: creating new properties with HTTP request
I need to create more properties with HTTP request. When I send HTTP request with query string, which contents only one property, it's ok. I don't know, how can I separate more properties. (I tried coma and semicolon ) >> >> 2009/5/12 Tobias Bocanegra : >>> try '&' as delimiter. >>> >>> see: http://en.wikipedia.org/wiki/Query_string >>> and: >>> https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Functions/encodeURIComponent > Vidar Ramdal schrieb: >> Actually, the semicolon is recommended by W3C [1], as the use of '&' >> often brings along some interesting escaping problems: >> >> "We recommend that HTTP server implementors, and in particular, CGI >> implementors support the use of ";" in place of "&" to save authors the >> trouble of escaping "&" characters in this manner." >> >> So maybe we should support ';' as a delimiter, in addition to '&'. >> WDYT? 2009/5/13 Felix Meschberger : > Sure. Now it of course depends on how is parsing the parameters. In the > case of URL paramaters and application/x-www-form-urlencoded POST data, > it is the servlet container parsing the parameters and we do nothing > about it. Ah, of course. Parsing the query string into parameters should probably be the job of the servlet container. However, from a quick look into Jetty, it doesn't seem to support ';' [1]. [1] http://jetty.mortbay.org/jetty/jetty-6/xref/org/mortbay/util/UrlEncoded.html#188 -- Vidar S. Ramdal - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
Re: [VOTE] Update to Community Roles and Processes
+1 (sorry for being late...) Regards Felix Felix Meschberger schrieb: > Hi all, > > An update draft of the Sling Community Roles and Processes as been on > the site since June 2008 [1]. This draft proposes to separate the roles > of Committers and (P)PMC members to lower the entry barrier for > committership. Additionally I added an explicit note, that regular > contributors of documentation may be elected as Committers just like > regular contributors of code. > > I think it is about time to put this draft on vote and accept or drop > it. So lets start a vote on this the current draft for the Sling > Community Roles and Processes [1]: > > [ ] +1 Yes > [ ] -1 No, because ... > > This is a majority vote running until Tuesday, 5. May 2009 (due to long > weekend in large parts of Europe). > > Thanks and Regards > Felix > > [1] > http://cwiki.apache.org/SLINGxSITE/apache-sling-community-roles-and-processes.html >
[RESULT] [VOTE] Update to Community Roles and Processes
Hi all, After having kept this vote open for more than a week, I now close it with the following result: +1 Dominik Süss +1 Juan Jose Vazquez Delgado (*) +1 Ian Boston +1 Jukka Zitting (*) +1 Vidar Ramdal (*) +1 Felix Meschberger (*) So this vote passes with 6 +1 votes (4 of which binding) and no 0 or -1 votes. Therefore this new Community Roles and Processes setup is put into effect. Regards Felix Felix Meschberger schrieb: > Hi all, > > An update draft of the Sling Community Roles and Processes as been on > the site since June 2008 [1]. This draft proposes to separate the roles > of Committers and (P)PMC members to lower the entry barrier for > committership. Additionally I added an explicit note, that regular > contributors of documentation may be elected as Committers just like > regular contributors of code. > > I think it is about time to put this draft on vote and accept or drop > it. So lets start a vote on this the current draft for the Sling > Community Roles and Processes [1]: > > [ ] +1 Yes > [ ] -1 No, because ... > > This is a majority vote running until Tuesday, 5. May 2009 (due to long > weekend in large parts of Europe). > > Thanks and Regards > Felix > > [1] > http://cwiki.apache.org/SLINGxSITE/apache-sling-community-roles-and-processes.html >
[DISCUSS] Graduation
Hi all, After the second release and an ever growing community, I think we are ready to graduate from the Incubator. At the beginning we entered the Incubator sponsored by the Apache Jackrabbit project with the potential goal of graduating as a subproject to Jackrabbit. Over time, it showed, that Sling will have a life on its own and that the communities of Jackrabbit and Sling are sufficiently different. As a consequence the common opinion of the PPMC is that Sling might best graduate as an Apache Top Level Project. Therefore, I hereby launch a discussion about our graduation. Everyone is invited to state her or his opinion. I also drafted a board resolution [1], which we will have to provide to the Incubator PMC as the basis for the graduation discussion on the Incubator general list. Next steps are then: * vote here about graduation * discuss graduation on the Incubator general list * have the Incubator PMC hold a recommendation vote * submit the board resolution If all goes well, we might be able to submit the resolution for the June board meeting. Regards Felix [1] http://cwiki.apache.org/SLING/graduation-resolution-draft.html
Re: Revision of Sling documentation, determining old stuff
Hi Mike, On Tue, May 12, 2009 at 10:24 PM, Mike Müller wrote: > So please give me some feedback on the following pages: > > - Architecture (seems to be up-to-date) [1] Looks good > - Eventing and Jobs (can someone check) [2] Looks good to me but Carsten is the man > - Internationalization Support (can someone check, seems to be outdated, > at least there's no getLocale() on SlingHttpServletRequest) [3] Correct. IMHO a typical example of a page that needs to have less details, to stand a better chance of staying in sync with the code. > - Installing and Upgrading Bundles (can someone check seems to be outdated > in favour of Felix management console) [4] Agreed, should point to http://felix.apache.org/site/apache-felix-web-console.html instead > - Assembly (can someone check, seems not to be part of Sling, maybe CRX) [5] We are not using assemblies anymore AFAIK, page should be removed? > - Apache Sling Rewriter (maybe ok, but can't find > org.apache.sling.rewriter.*) [6] AFAIK the code is still under https://svn.eu.apache.org/repos/asf/incubator/sling/whiteboard/rewriter > - Groovy Support (seems to be ok) [7] Looks good, didn't check the details. > - XSLT Processing Pipeline (seems to be ok) [8] Looks good, didn't check the details. > - Maven Sling Plugin (can someone check) [9] Looks good, didn't check the details. > - Maven JspC Plugin (can someone check) [10] Don't know enough to say. > BTW I didn't get why the new Sling release is Sling 5 and not Sling 4... Release 4 was broken so we didn't release it. Thanks for your investigations! -Bertrand > [1] http://incubator.apache.org/sling/site/architecture.html > [2] http://incubator.apache.org/sling/site/eventing-and-jobs.html > [3] http://incubator.apache.org/sling/site/internationalization-support.html > [4] > http://incubator.apache.org/sling/site/installing-and-upgrading-bundles.html > [5] http://incubator.apache.org/sling/site/assembly.html > [6] > http://incubator.apache.org/sling/site/rewriting-the-output-through-pipelines.html > [7] http://incubator.apache.org/sling/site/groovy-support.html > [8] http://incubator.apache.org/sling/site/xslt-processing-pipeline.html > [9] http://incubator.apache.org/sling/site/sling.html > [10] http://incubator.apache.org/sling/site/jspc.html > >
[RT] Generic "scriptable" launcher
Hi, I'm thinking of creating a generic launcher, using a text file definition to load and start jars, allowing a Sling launcher to take over and load and start bundles once a main class is started. Here's a rough idea - I haven't looked at Karaf closely yet, there's probably some overlap, but my idea is to create a generic Java launcher, having nothing to do with OSGi, that in turn launches an OSGi-aware main class. The launcher is a runnable jar, or a war file. It uses a text file named launch.txt to define what to launch, example below. # START launch.txt example properties: sling.home = ./sling org.apache.commons.launcher.protocols.maven.repository.1 = http://repo1.maven.org/maven2 org.apache.commons.launcher.protocols.maven.repository.2 = http://people.apache.org/repo/m2-incubating-repository protocols: # by default only the http and file protocol are provided to # load jar files, more can be added by loading protocol jars # The maven protocol, for example, grabs jar files from # repositories defined by the *.maven.repository properties # found above. jar http://some.repository/launcher-maven-protocol-1.4.2.jar md5=1231231239812cd21231987 bootstrap: # load a number of jars that are required to start the main class jar maven:org.apache.felix:org.osgi.compendium:jar:1.2.0 md5=1231231239812cd212315645 jar maven:org.apache.felix:org.osgi.core:jar:1.2.0 sha1=1231231239812cd21231123213 jar maven:org.apache.felix:org.osgi.foundation:jar:1.2.0 sha1=1231231239812cd2123112313 jar maven:org.apache.sling:org.apache.sling.launchpad.launcher:2.0.2-incubator md5=1231231239812cd2123112313 # now start the main class, from the org.apache.sling.launchpad.launcher jar main-class org.apache.sling.launchpad.launcher.Main -m launcher # The launcher stops processing here, and provides this file to the main class as its # standard input. The above launcher.Main processes the lines that follow the # above main-class statement # Load and start a few bundles, some with specific start levels bundle http://some.obr/some-bundle sha1=1231390890823121312 bundle maven:some.group:some.artifact:1.0 startlevel=2 md5=123213213984329843 # END launch.txt example Creating a launcher that will "never" change doesn't seem too hard, and then defining a Sling launchpad instance boils down to the launch.txt file. Using a text file to define bundles makes it easy for people to exchange configurations, as the text file fully defines the application assembly, based on the bundles URLs and digests. WDYT? -Bertrand
[jira] Commented: (SLING-946) jcrinstall integration tests fail on our Hudson build server
[ https://issues.apache.org/jira/browse/SLING-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708968#action_12708968 ] Bertrand Delacretaz commented on SLING-946: --- Tested a build on a Debian platform (instead of my mac) and all tests pass, so the problem is not the linux platform > jcrinstall integration tests fail on our Hudson build server > > > Key: SLING-946 > URL: https://issues.apache.org/jira/browse/SLING-946 > Project: Sling > Issue Type: Bug > Components: JCR Install >Reporter: Bertrand Delacretaz >Priority: Minor > > The jcrinstall integration tests in the > http://hudson.zones.apache.org/hudson/view/Sling/job/sling-contrib-1.5 build > fail with errors like > java.io.FileNotFoundException: > /home/hudson/hudson-slave/workspace/sling-contrib-1.5/contrib-1.5/launchpad/testing/target/launchpad-bundles/resources/bundles/15/cloned-bundles/observer_clone_1240993668015.jar > For some reason, the tests cannot find the cloned bundles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Pax web and Jetty XML
Hi, Has anyone tried to re-configure pax web with an a custom jetty.xml and managed to keep the Jetty Session Manager working ? For some reason, with a custom Jetty.xml with a modified AJP connector, the Jetty Session Manager (HashSessionManager) stops working, so no session cookies are sent. any pointers would be very welcomed, and am into the pax source code at the moment. The other worrying thing is I cant see a way of binding a clustered session manager to the osgi HttpService, since appear to have the same scoping of sessions as a standalone webapp container. Ian
Hudson build is back to stable: sling-contrib-1 .5 » Apache Sling Launchpad Contrib Testing #26
See http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.launchpad.contrib-testing/26/
Re: Pax web and Jetty XML
It might be worth also asking on the pax lists: http://lists.ops4j.org/mailman/listinfo/general -AZ On Wed, May 13, 2009 at 5:15 PM, Ian Boston wrote: > Hi, > Has anyone tried to re-configure pax web with an a custom jetty.xml and > managed to keep the Jetty Session Manager working ? > For some reason, with a custom Jetty.xml with a modified AJP connector, the > Jetty Session Manager (HashSessionManager) stops working, so no session > cookies are sent. > any pointers would be very welcomed, and am into the pax source code at the > moment. > > The other worrying thing is I cant see a way of binding a clustered session > manager to the osgi HttpService, since appear to have the same scoping of > sessions as a standalone webapp container. > Ian > > -- Aaron Zeckoski (aar...@vt.edu) Senior Research Engineer - CARET - Cambridge University [http://bugs.sakaiproject.org/confluence/display/~aaronz/] Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
Re: [RT] Generic "scriptable" launcher
Hi, On Wed, May 13, 2009 at 4:57 PM, Bertrand Delacretaz wrote: > Using a text file to define bundles makes it easy for people to > exchange configurations, as the text file fully defines the > application assembly, based on the bundles URLs and digests. See below for a somewhat related experiment I recently did for launching Apache Tika using Maven 2 as the launch engine. Running "mvn -f tika.xml exec:java" would download all the required jars, set up the correct classpath and launch the configured main class. The interesting thing here is that the only essential part of the script below are the Maven coordinates of the tika-app jar. With a little bit of scripting you could boil the startup command down to something like "mvnrun org.apache.tika tika-app 0.4-SNAPSHOT" with no Tika-specific configuration files required. And such a tool could be used to download and launch any runnable jar (and the full set of dependencies) in the Maven repository. Of course this doesn't do any of the OSGi stuff, but as you mention, the OSGi startup could well be handled as a second stage. BR, Jukka Zitting tika.xml http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd "> 4.0.0 org.example application SNAPSHOT pom org.codehaus.mojo exec-maven-plugin java org.apache.tika.gui.TikaGUI org.apache.tika tika-app 0.4-SNAPSHOT
Re: [DISCUSS] Graduation
IMHO Graduation should be done pretty soon since the major technical details have been clarified within the incubator phase and the topics turn more and more usecase specific or are cause by the common sideeffects of new features/changes. >From a developers point of view the incubator state doesn't reflect the maturity of Sling which is more and more used in real projects. I know I might not be in the position to complain about documentation since I yet didn't find time by myself to get involved in this obviously not so famous part of the framework. But in my opinion for this step some people should help Mike with his try to lower the barrier for "first-timers". Graduation could be used to get some attention and therefore enlarge the usergroup as welll as the contributors and commiters. BTW. at this point a users-mailinglist would really make sense since this mailinglist might be really confusing for a sling-rookie;) Is this user-mailinglist part of the graduationprocess? Best regards, Dominik On Wed, May 13, 2009 at 2:50 PM, Felix Meschberger wrote: > Hi all, > > After the second release and an ever growing community, I think we are > ready to graduate from the Incubator. > > At the beginning we entered the Incubator sponsored by the Apache > Jackrabbit project with the potential goal of graduating as a subproject > to Jackrabbit. Over time, it showed, that Sling will have a life on its > own and that the communities of Jackrabbit and Sling are sufficiently > different. > > As a consequence the common opinion of the PPMC is that Sling might best > graduate as an Apache Top Level Project. > > Therefore, I hereby launch a discussion about our graduation. Everyone > is invited to state her or his opinion. > > I also drafted a board resolution [1], which we will have to provide to > the Incubator PMC as the basis for the graduation discussion on the > Incubator general list. > > Next steps are then: > > * vote here about graduation > * discuss graduation on the Incubator general list > * have the Incubator PMC hold a recommendation vote > * submit the board resolution > > If all goes well, we might be able to submit the resolution for the June > board meeting. > > Regards > Felix > > [1] http://cwiki.apache.org/SLING/graduation-resolution-draft.html >
Re: [DISCUSS] Graduation
Hi, Dominik Süß schrieb: > IMHO Graduation should be done pretty soon since the major technical details > have been clarified within the incubator phase and the topics turn more and > more usecase specific or are cause by the common sideeffects of new > features/changes. >>From a developers point of view the incubator state doesn't reflect the > maturity of Sling which is more and more used in real projects. > > I know I might not be in the position to complain about documentation since > I yet didn't find time by myself to get involved in this obviously not so > famous part of the framework. But in my opinion for this step some people > should help Mike with his try to lower the barrier for "first-timers". > Graduation could be used to get some attention and therefore enlarge the > usergroup as welll as the contributors and commiters. > > BTW. at this point a users-mailinglist would really make sense since this > mailinglist might be really confusing for a sling-rookie;) Is this > user-mailinglist part of the graduationprocess? There is no hard relation-ship for having a users list and the graduation. A user list is more of a decission to split traffic. For now, I am not sure, whether we really need it. But if "the community" deems it useful to have two list, I am certainly open to also run a users list. Maybe to be set up during the graduation process. Regards Felix > > Best regards, > Dominik > > On Wed, May 13, 2009 at 2:50 PM, Felix Meschberger wrote: > >> Hi all, >> >> After the second release and an ever growing community, I think we are >> ready to graduate from the Incubator. >> >> At the beginning we entered the Incubator sponsored by the Apache >> Jackrabbit project with the potential goal of graduating as a subproject >> to Jackrabbit. Over time, it showed, that Sling will have a life on its >> own and that the communities of Jackrabbit and Sling are sufficiently >> different. >> >> As a consequence the common opinion of the PPMC is that Sling might best >> graduate as an Apache Top Level Project. >> >> Therefore, I hereby launch a discussion about our graduation. Everyone >> is invited to state her or his opinion. >> >> I also drafted a board resolution [1], which we will have to provide to >> the Incubator PMC as the basis for the graduation discussion on the >> Incubator general list. >> >> Next steps are then: >> >> * vote here about graduation >> * discuss graduation on the Incubator general list >> * have the Incubator PMC hold a recommendation vote >> * submit the board resolution >> >> If all goes well, we might be able to submit the resolution for the June >> board meeting. >> >> Regards >> Felix >> >> [1] http://cwiki.apache.org/SLING/graduation-resolution-draft.html >> >
Re: [RT] Generic "scriptable" launcher
Hi, Bertrand Delacretaz schrieb: > I'm thinking of creating a generic launcher, using a text file > definition to load and start jars, allowing a Sling launcher to take > over and load and start bundles once a main class is started. This sounds a lot like Tanuki Java Service Wrapper ... > > Here's a rough idea - I haven't looked at Karaf closely yet, there's > probably some overlap, but my idea is to create a generic Java > launcher, having nothing to do with OSGi, that in turn launches an > OSGi-aware main class. > > The launcher is a runnable jar, or a war file. > > It uses a text file named launch.txt to define what to launch, example below. > > # START launch.txt example > properties: > sling.home = ./sling > org.apache.commons.launcher.protocols.maven.repository.1 = > http://repo1.maven.org/maven2 > org.apache.commons.launcher.protocols.maven.repository.2 = > http://people.apache.org/repo/m2-incubating-repository > > protocols: > # by default only the http and file protocol are provided to > # load jar files, more can be added by loading protocol jars > > # The maven protocol, for example, grabs jar files from > # repositories defined by the *.maven.repository properties > # found above. > jar http://some.repository/launcher-maven-protocol-1.4.2.jar > md5=1231231239812cd21231987 > > bootstrap: > # load a number of jars that are required to start the main class > jar maven:org.apache.felix:org.osgi.compendium:jar:1.2.0 > md5=1231231239812cd212315645 > jar maven:org.apache.felix:org.osgi.core:jar:1.2.0 > sha1=1231231239812cd21231123213 > jar maven:org.apache.felix:org.osgi.foundation:jar:1.2.0 > sha1=1231231239812cd2123112313 > jar maven:org.apache.sling:org.apache.sling.launchpad.launcher:2.0.2-incubator > md5=1231231239812cd2123112313 > > # now start the main class, from the org.apache.sling.launchpad.launcher jar > main-class org.apache.sling.launchpad.launcher.Main -m launcher > > # The launcher stops processing here, and provides this file to the > main class as its > # standard input. The above launcher.Main processes the lines that follow the > # above main-class statement > > # Load and start a few bundles, some with specific start levels > bundle http://some.obr/some-bundle sha1=1231390890823121312 > bundle maven:some.group:some.artifact:1.0 startlevel=2 md5=123213213984329843 > > # END launch.txt example > > Creating a launcher that will "never" change doesn't seem too hard, > and then defining a Sling launchpad instance boils down to the > launch.txt file. > > Using a text file to define bundles makes it easy for people to > exchange configurations, as the text file fully defines the > application assembly, based on the bundles URLs and digests. > > WDYT? At first I thought: What may this be used for. Maybe just because I failed to understand the problem for which you present a solution. Is this about creating "custom Sling configurations" ? Now, this is certainly a valid request, to which we currently have two answers: * The launchpad/bundles project defines a package of bundles to be included in the app or webapp binary * A patch to extend the BootstrapInstaller to read more bundles for installation from the filesystem Maybe we need an additional mechanism for setting up an initial set of bundles. Now, there's pax runner [1] which sports so called profiles, which may be exactly what you are envisioning ? While I like our current construct of having very small environment-specific code (web app or standalone app) and the rest being unified, we might also go for favouring the standalone app... Regards Felix [1] http://paxrunner.ops4j.org/space/Pax+Runner > > -Bertrand >
Re: Revision of Sling documentation, determining old stuff
Hi, Bertrand Delacretaz schrieb: >> - Internationalization Support (can someone check, seems to be outdated, >> at least there's no getLocale() on SlingHttpServletRequest) [3] > > Correct. IMHO a typical example of a page that needs to have less > details, to stand a better chance of staying in sync with the code. I don't agree here. We don't expect casual Sling users/programmers to read our code in-depth. Otherwise we would not need a documentation site. Of course we could now point to the published JavaDoc. And as said on the page, the getLocale() and getLocales() method is inherited from the ServletRequest interface and hence certainly not duplicated in the SlingHttpServletRequest interface. IIRC I wrote this page with the actual extensions/i18n bundle in mind. So this page is probably rather up to date. Regards Felix
Re: Revision of Sling documentation, determining old stuff
Hi, Mike Müller schrieb: > Hi > > I'm reviewing the documentation on the Sling Site and need your help > do determine old stuff, because I'm not sure if they are up-to-date or not. > > So please give me some feedback on the following pages: > > - Architecture (seems to be up-to-date) [1] Yes, this is up to date, since it has only recently been written by me. > - Eventing and Jobs (can someone check) [2] > - Internationalization Support (can someone check, seems to be outdated, > at least there's no getLocale() on SlingHttpServletRequest) [3] > - Installing and Upgrading Bundles (can someone check seems to be outdated > in favour of Felix management console) [4] While the contents is still correct (except for the reference to Sling Web Console instead of the Felix Web Console), this page should probably be dropped. Maybe we should just create a general page on system managament and refer to various options like the Felix Web Console or the Felix Shell (soon there will be a standardized Shell) > - Assembly (can someone check, seems not to be part of Sling, maybe CRX) [5] It was part of Sling and is now in the whiteboard. This mechanism predates our knowledge about the OSGi Deployment Admin Service and was an attempt to mimick Eclipse Features. I agree with Bertrand, that we should drop this page. > - Apache Sling Rewriter (maybe ok, but can't find > org.apache.sling.rewriter.*) [6] > - Groovy Support (seems to be ok) [7] We might want to drop this page. Since Groovy 1.6 the groovy library is a bundle and can directly be deployed into any OSGi Container and is also supported by Sling. We even included it in the standard Sling 5 binary. > - XSLT Processing Pipeline (seems to be ok) [8] > - Maven Sling Plugin (can someone check) [9] This page might be incomplete because the latest version of the plugin supports uploading bundles into the repository to support the JCR Install functionality. HTH Regards Felix
Re: [RT] Generic "scriptable" launcher
While I see the value of a launcher - I don't think that this is the concern of Sling - we are the framework which should run in every OSGi installation; so let's focus on the framework and leverage other efforts like pax+runner, Karaf etc. instead of doing this stuff ourselves. Just my 2c Carsten Felix Meschberger wrote: > Hi, > > Bertrand Delacretaz schrieb: >> I'm thinking of creating a generic launcher, using a text file >> definition to load and start jars, allowing a Sling launcher to take >> over and load and start bundles once a main class is started. > > This sounds a lot like Tanuki Java Service Wrapper ... > > >> Here's a rough idea - I haven't looked at Karaf closely yet, there's >> probably some overlap, but my idea is to create a generic Java >> launcher, having nothing to do with OSGi, that in turn launches an >> OSGi-aware main class. >> >> The launcher is a runnable jar, or a war file. >> >> It uses a text file named launch.txt to define what to launch, example below. >> >> # START launch.txt example >> properties: >> sling.home = ./sling >> org.apache.commons.launcher.protocols.maven.repository.1 = >> http://repo1.maven.org/maven2 >> org.apache.commons.launcher.protocols.maven.repository.2 = >> http://people.apache.org/repo/m2-incubating-repository >> >> protocols: >> # by default only the http and file protocol are provided to >> # load jar files, more can be added by loading protocol jars >> >> # The maven protocol, for example, grabs jar files from >> # repositories defined by the *.maven.repository properties >> # found above. >> jar http://some.repository/launcher-maven-protocol-1.4.2.jar >> md5=1231231239812cd21231987 >> >> bootstrap: >> # load a number of jars that are required to start the main class >> jar maven:org.apache.felix:org.osgi.compendium:jar:1.2.0 >> md5=1231231239812cd212315645 >> jar maven:org.apache.felix:org.osgi.core:jar:1.2.0 >> sha1=1231231239812cd21231123213 >> jar maven:org.apache.felix:org.osgi.foundation:jar:1.2.0 >> sha1=1231231239812cd2123112313 >> jar >> maven:org.apache.sling:org.apache.sling.launchpad.launcher:2.0.2-incubator >> md5=1231231239812cd2123112313 >> >> # now start the main class, from the org.apache.sling.launchpad.launcher jar >> main-class org.apache.sling.launchpad.launcher.Main -m launcher >> >> # The launcher stops processing here, and provides this file to the >> main class as its >> # standard input. The above launcher.Main processes the lines that follow the >> # above main-class statement >> >> # Load and start a few bundles, some with specific start levels >> bundle http://some.obr/some-bundle sha1=1231390890823121312 >> bundle maven:some.group:some.artifact:1.0 startlevel=2 md5=123213213984329843 >> >> # END launch.txt example >> >> Creating a launcher that will "never" change doesn't seem too hard, >> and then defining a Sling launchpad instance boils down to the >> launch.txt file. >> >> Using a text file to define bundles makes it easy for people to >> exchange configurations, as the text file fully defines the >> application assembly, based on the bundles URLs and digests. >> >> WDYT? > > At first I thought: What may this be used for. Maybe just because I > failed to understand the problem for which you present a solution. > > Is this about creating "custom Sling configurations" ? > > Now, this is certainly a valid request, to which we currently have two > answers: > >* The launchpad/bundles project defines a package of bundles to > be included in the app or webapp binary > >* A patch to extend the BootstrapInstaller to read more bundles > for installation from the filesystem > > Maybe we need an additional mechanism for setting up an initial set of > bundles. Now, there's pax runner [1] which sports so called profiles, > which may be exactly what you are envisioning ? > > While I like our current construct of having very small > environment-specific code (web app or standalone app) and the rest being > unified, we might also go for favouring the standalone app... > > Regards > Felix > > [1] http://paxrunner.ops4j.org/space/Pax+Runner > >> -Bertrand >> > -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE RESULT] Release Apache Sling 5
I've uploaded our release yesterday and Sling is now available from the central maven repository and our download page. Carsten -- Carsten Ziegeler cziege...@apache.org
