[jira] Created: (SLING-521) Revert to hand written notice files
Revert to hand written notice files --- Key: SLING-521 URL: https://issues.apache.org/jira/browse/SLING-521 Project: Sling Issue Type: Task Affects Versions: 2.0.1 Reporter: Carsten Ziegeler Fix For: 2.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-504) Use optional scope for dependencies that must not be included in the NOTICE file
[ https://issues.apache.org/jira/browse/SLING-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-504. -- Resolution: Won't Fix We revert the automated generation. Use optional scope for dependencies that must not be included in the NOTICE file -- Key: SLING-504 URL: https://issues.apache.org/jira/browse/SLING-504 Project: Sling Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor See http://markmail.org/message/xgzwxfonp5mbpyjq - for now our automatically generated NOTICE files include too many dependencies, and we cannot exclude all the ones marked provided as we sometimes include them in the bundles using private-package statements for the maven-bundle-plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: I18N changes
As we're cutting a new release, it would imho be great to include these changes as well. Carsten Felix Meschberger wrote: Hi, Am Donnerstag, den 05.06.2008, 15:18 +0200 schrieb Alexander Klimetschek: On Thu, Jun 5, 2008 at 2:06 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Given the changes below, I think, we should not release the i18n module yet with the initial Sling release. Instead we should carefully build these changes into the module and release as soon as we are ready. Ok, sounds like the best way to handle this situation. AFAIK there is only one project using this bundle right now and we have control over it. Please, create an issue for these changes. I will do so once when we have concensus in this thread. I think we almost have consensus, except for the key thing below ... 6) The sling:key should be optional and only be used if the actual key (which would typically be the original, eg. english, source string) is not a valid JCR name. Otherwise the node name should be the key (no need for generating message1, message2, etc.) Not sure, whether this is implementable. If you could provide me with good queries to find messages by key, I might get convinced. In priniciple, I think it is not a bad idea. But it must be implementable ;-) Three solutions come to my mind: a) Use a sling:key == key OR nodename = escaped(key) (algorithm from 7) query. But I am not sure if this is possible. not needed, see (c) b) The query would run use algorithm from 7) below to generate the non-unique part of the node name and do a jcr:like(Same_name_%). If this results in multiple results (eg. Same_name_1, Same_name_2), it has to manually find the correct one by looping over the result set and looking at the sling:key properties. not needed, see (c) c) Don't load messages one-by-one but have the JcrResourceBundle load all messages up-front (upon the first call) in-memory. The internal hash-map would only store the actual keys. Pro: Simpler implementation and this might be more efficient anyway, since the messages get cached. Con: Yet another cache... WDYT? Actually, we have two queries in the i18n JcrResourceBundle class: One to get an exact message for a language given its key and one to get all messages for a language. Currently all key/message mappings are cached any way, and when the ResourceBundle.getKeys() method is called, all messages are loaded and cached anyway. So, we just could load these upfront. This of course also makes the code leaner, which giving some performance penalty to the first user of the resource bundle. The other advantage of loading everything upfront is, that we only need a single query which does NOT involve quering for the key value. So, I think, you can create the issue -- and fmeschbe says, he would be happy to also get a patch ;-) Thanks and Regards Felix -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Assigned: (SLING-503) Disable SCR plugin for Factory Components
[ https://issues.apache.org/jira/browse/SLING-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-503: -- Assignee: Carsten Ziegeler Disable SCR plugin for Factory Components - Key: SLING-503 URL: https://issues.apache.org/jira/browse/SLING-503 Project: Sling Issue Type: Bug Components: Engine, JCR Affects Versions: 2.0.0 Reporter: Felix Meschberger Assignee: Carsten Ziegeler Priority: Blocker Fix For: 2.0.1 After upgrading to a more recent maven-scr-plugin which includes the fix for FELIX-593, the manually crafted component descriptors for component factories must be removed again and the generation using the scr plugin must be renabled. This is the reverse task of SLING-502 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-503) Enable SCR plugin for Factory Components
[ https://issues.apache.org/jira/browse/SLING-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-503: --- Summary: Enable SCR plugin for Factory Components (was: Disable SCR plugin for Factory Components) Enable SCR plugin for Factory Components Key: SLING-503 URL: https://issues.apache.org/jira/browse/SLING-503 Project: Sling Issue Type: Bug Components: Engine, JCR Affects Versions: 2.0.0 Reporter: Felix Meschberger Assignee: Carsten Ziegeler Priority: Blocker Fix For: 2.0.1 After upgrading to a more recent maven-scr-plugin which includes the fix for FELIX-593, the manually crafted component descriptors for component factories must be removed again and the generation using the scr plugin must be renabled. This is the reverse task of SLING-502 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-519) Update to Felix SCR Implementation 1.0.1
Update to Felix SCR Implementation 1.0.1 Key: SLING-519 URL: https://issues.apache.org/jira/browse/SLING-519 Project: Sling Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Fix For: 2.0.1 We should update to the Felix SCR Implementation 1.0.1 when it's ready. It fixes a bug where we currently have a workaround. The changes of Rev. 662747 are to be reverted. See SLING-502 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Vote] Release Sling
David Nuescheler wrote: hi carsten, the release built just fine for me. congrats. a couple of assertion seem to fail on the sling client side testing: .../sling-test/sling/sling-test.html i don't think it is something major but maybe we want to clean that up or remove from the release. If it's not a major problem (and I think it isn't), we can live with this and fix this for the next release. Doing it for this release would mean rerunning the whole release process which I would like to avoid atm. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: How to check the release artifacts (was: [VOTE] Release Sling Artifacts)
Bertrand Delacretaz wrote: Here the goal is to check that the contents match what's tagged with the same release number under http://svn.apache.org/repos/asf/incubator/sling/tags/, right? Yes, and to make sure that everything is correct from a legal pov. However, org.apache.sling.launchpad.webapp-2.0.0-incubator-bin.tar.gz there does not contain the launchpad war file, where should I find it? Ah ok, so the webapp-bin is useless then, we might just drop it from the list. The war is in the maven artifacts directory. Could we add a KEYS file to our trunk for this? Done. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: The release is too complex? (Was: [VOTE] Release Sling Artifacts)
Jukka Zitting wrote: Hi, On Thu, Jun 5, 2008 at 8:54 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Hmm, don't know - noone came up with this *before* doing the release. :) I was expecting that we'd do a single release, not dozens of them at the same time. :-) In the end I see no real difference, you have to check the same amount of files, being it in one package or in 50. Separating this into several packages makes imho detecting stuff easier and might allow us to release at least some parts of it (if some other parts do not meet the release criteria - although I'm very confident that we did it right). There's a big difference between one release with many components and many releases each with one component. Think about an end user that wants to download the release sources and build them. With this release structure they'd need to separately download almost 50 different packages, check all their signatures, and build them in the correct sequence that AFAIK is nowhere defined. With this release structure I don't think anyone in their right mind would care to download the sources and build them, and that's IMHO a bad thing. Hmm, ok, this depends of course on your use case - but I see your point. So what about if I just rebundle the sources in one huge file, add a convenience maven pom and exclude the launchpad app/webapp and the apt stuff as they are broken? So we can get most of the stuff out of the door. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
VOTE CANCELLED [was Re: [VOTE] Release Sling Artifacts]
Ok, so I cancel this vote due to mainly two problems: a) a bug (SLING-512) which will be solved by Felix :) b) the source release should rather be one big archive The plan for release is as follows: a) We will fix the bugs in the affected modules and then tag them as 2.0.2 bundles/modules. b) We will remove the 2.0.0 tags from svn for the modules from a) c) The source release I will create a tag in svn (sling-2.0.0-incubator-release - we can use a different name) which gets the same layout as our svn trunk, but with all modules removed that we don't want to have in the release. Instead of copying everything we will use svn externals to point from this tree to the various tags of the bundles. This gives us both: a big source tree of everything and single tags for each bundle. d) We will release the source archive from c) and binaries only for the launchpad app and launchpad webapp. In addition we will provide all maven artifacts. I'll build all these from the tag created in c) e) All upcoming releases will be single bundle releases. I hope this is ok for everyone? Carsten Bertrand Delacretaz wrote: On Wed, Jun 4, 2008 at 7:51 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: org.apache.sling.launchpad.app-2.0.0-incubator ... org.apache.sling.launchpad.webapp-2.0.0-incubator... Are broken due to SLING-512, which apparently hides a slightly more serious problem. -Bertrand -- Carsten Ziegeler [EMAIL PROTECTED]
Re: VOTE CANCELLED [was Re: [VOTE] Release Sling Artifacts]
Bertrand Delacretaz wrote: On Thu, Jun 5, 2008 at 11:41 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ... e) All upcoming releases will be single bundle releases I think Jukka has valid points here, but we don't need to decide on this right now. ... I hope this is ok for everyone?... Ok for me, thanks. At some point we can maybe add an OBR + XSLT file like the one at http://oscar-osgi.sourceforge.net/obr-repo/releases.xml to point to our Maven artifacts, if people want do download them without using Maven. Felix and I have discussed this offline :( , but yes, we'll provide such a file - there is a maven plugin which generates it for us; we just have to figur out how this will work in our scenario :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Cannot find parent: org.apache.sling:sling for project
Craig L. Ching wrote: I know you fixed this once, but I'm getting it again now: Yes, I fixed it, did a new release and broke it again...sorry for that. I just fixed it (this time for real...) Sorry Carsten Project ID: null:org.apache.sling.launchpad.webapp:war:2.0.3-incubator-SNAPSHOT Reason: Cannot find parent: org.apache.sling:sling for project: null:org.apache. sling.launchpad.webapp:war:2.0.3-incubator-SNAPSHOT for project null:org.apache. sling.launchpad.webapp:war:2.0.3-incubator-SNAPSHOT Is that because you bumped the version again? Any way for me to work-around this easily? Cheers, Craig -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2008 12:52 AM To: sling-dev@incubator.apache.org Subject: Re: Cannot find parent: org.apache.sling:sling for project Mark wrote: Hi All I am trying to get started, however ( Am I missing a repository setting ? ) Hi, no this was a leftover from building the release candidate yesterday. Sorry for the inconvenience. It should be fixed now. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] -- Carsten Ziegeler [EMAIL PROTECTED]
[Vote] Release Sling
Hello everyone, let's give it a second try. I cut a new candidate as outlined today. I've put all release artifacts here: http://people.apache.org/~cziegeler/releases/sling/ The releases are in http://people.apache.org/~cziegeler/releases/sling/releases This is a big source tree of our release, so this is the important stuff. For convenience we have two additional binary releases here: the launchpad app and webapp. I've built the corresponding maven artifacts of all modules which can be found here: http://people.apache.org/~cziegeler/releases/sling/maven The KEYS file to check my signature is at http://people.apache.org/~cziegeler/releases/sling/ This is basically just one big release, so please cast your votes. Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [Vote] Release Sling
Carsten Ziegeler wrote: Hello everyone, let's give it a second try. I cut a new candidate as outlined today. I've put all release artifacts here: http://people.apache.org/~cziegeler/releases/sling/ The releases are in http://people.apache.org/~cziegeler/releases/sling/releases This is a big source tree of our release, so this is the important stuff. For convenience we have two additional binary releases here: the launchpad app and webapp. I've built the corresponding maven artifacts of all modules which can be found here: http://people.apache.org/~cziegeler/releases/sling/maven The KEYS file to check my signature is at http://people.apache.org/~cziegeler/releases/sling/ This is basically just one big release, so please cast your votes. +1 Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Bertrand Delacretaz wrote: On Wed, Jun 4, 2008 at 12:35 AM, Roy T. Fielding [EMAIL PROTECTED] wrote: ...I'd rather have a set of hand-edited NOTICE files that accurately reflect each of the release packages I see your point, and thanks for your changes in etc/notice/notices, that will help a lot. The nice thing (IMHO) about generating the notices from the Maven dependencies, is that this will expose any new dependencies that might have been added next time we do a release, without having to manually check our 55 notice files by hand. But I agree about refining the process with exceptions, I'll modify the mknotice script now, to ignore #comment lines. Ok, where are we now? :) I think we should make the final changes (as discussed recently here), recheck the notice files and then I can go ahead and make the release candidates. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Ok, can I have a short ok from other committers that they think the notice files are ok now? I'll check them myself now and would like to start the build process afterwards. Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
JSON is missing an entry in the notice file
Hi, the following line needs to be added to the notice file in the commons/json module: This product includes software developed at http://json.org. Don't know how to add this in the automated process? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Reopened: (SLING-495) Complete our NOTICE files
[ https://issues.apache.org/jira/browse/SLING-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reopened SLING-495: There are still issues: commons/json: This product includes software developed at http://json.org. commons/log: This product includes software developed by QOS (http://www.qos.ch) This product includes software developed at the OSGi Alliance (http://www.osgi.org/). Complete our NOTICE files - Key: SLING-495 URL: https://issues.apache.org/jira/browse/SLING-495 Project: Sling Issue Type: Bug Reporter: Bertrand Delacretaz Fix For: 2.0.0 We have to complete the NOTICE files for our module that embed non-ASF dependencies. The script created for SLING-493 can be used to generate those files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-495) Complete our NOTICE files
[ https://issues.apache.org/jira/browse/SLING-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602268#action_12602268 ] Carsten Ziegeler commented on SLING-495: commons/scheduler: This product includes software developed at Opensymphony (http://www.opensymphony.org/quartz). commons/scheduler: Does not contain software developed by mx4j. Complete our NOTICE files - Key: SLING-495 URL: https://issues.apache.org/jira/browse/SLING-495 Project: Sling Issue Type: Bug Reporter: Bertrand Delacretaz Fix For: 2.0.0 We have to complete the NOTICE files for our module that embed non-ASF dependencies. The script created for SLING-493 can be used to generate those files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Several issues with generated notice files
Hi, I just started to look at the new notice files and found several problems, so I reopened the bug and added the info there. I really think we should go back to hand written notice files, let's use the now generated once as a starting point. In addition I think we can remove the first blank line and the Apache..., so instead of: Apache Sling - Thread Support Apache Sling Copyright 2008 The Apache Software Foundation we just write: Apache Sling - Thread Support Copyright 2008 The Apache Software Foundation Another issue is that now all notices files have the based on Day Software stuff in it. While this is true for most of our modules, it's not for all. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Several issues with generated notice files
Bertrand Delacretaz wrote: Easy - just remove the first line of etc/notice/notices/prefix.txt. For now I left it because I think that's what Roy intendend, i.e. that Apache Sling as a whole is copyright ASF. Hmm, ok, might make sense. ...Another issue is that now all notices files have the based on Day Software stuff in it. While this is true for most of our modules, it's not for all Easy to fix with a fake day-based dependency for those modules where it's the case, declared in Or (better IMHO), we can modify the note in prefix.txt (which shows at the beginning of all generated NOTICEs) to say something like The Apache Sling project is based on code initially provided by Day Software, which is more generic and true. Yes, I think that's more appropriate. This notice issue is really becoming very annoying. For instance the mention of slf4j or quartz in the notice files is done in many other projects and I thought that we have to give them attribution if we include their stuff. Now, Roy removed these. I'm clueless what's right, sorry. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Several issues with generated notice files
Bertrand Delacretaz wrote: On Wed, Jun 4, 2008 at 2:51 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...I just started to look at the new notice files and found several problems, so I reopened the bug and added the info there... See my comments in SLING-495 - I think the current state reflects Roy's changes. ... I really think we should go back to hand written notice files, let's use the now generated once as a starting point If we do this, we lose the benefit of detecting when new dependencies are introduced by Maven, for future releases. This means going back to 100% manual maintenance of our 55 (currently) NOTICE files...not nice if we can avoid it. Given the problems we have I'm not sure what the best solution is. Dependencies do not just change and checking what you might get before you change a dependency is a good thing :) For instance maven thinks that there is a mx4j inclusion in the scheduler. But it is definitly not, mx4j is used by quartz at compile time, but it's neither used at runtime nor is it distributed by us. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Several issues with generated notice files
Bertrand Delacretaz wrote: On Wed, Jun 4, 2008 at 3:30 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Bertrand Delacretaz wrote: Easy - just remove the first line of etc/notice/notices/prefix.txt. For now I left it because I think that's what Roy intendend, i.e. that Apache Sling as a whole is copyright ASF. Hmm, ok, might make sense... I suggest that we keep this for now, it just looks a bit weird, not problematic. ...Or (better IMHO), we can modify the note in prefix.txt (which shows at the beginning of all generated NOTICEs) to say something like The Apache Sling project is based on code initially provided by Day Software, which is more generic and true. Yes, I think that's more appropriate... Ok, I'll do that right now. ...This notice issue is really becoming very annoying. For instance the mention of slf4j or quartz in the notice files is done in many other projects and I thought that we have to give them attribution if we include their stuff. Now, Roy removed these. I'm clueless what's right, sorry I suggest that we trust Roy on this for now. I trust Roy, but I know that other projects would definitly vote against such a notice file. And this is the strange point here. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Closed: (SLING-495) Complete our NOTICE files
[ https://issues.apache.org/jira/browse/SLING-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-495. -- Resolution: Fixed It seems that these are all non-issues, apart from mx4j which should be fixed now. Complete our NOTICE files - Key: SLING-495 URL: https://issues.apache.org/jira/browse/SLING-495 Project: Sling Issue Type: Bug Reporter: Bertrand Delacretaz Fix For: 2.0.0 We have to complete the NOTICE files for our module that embed non-ASF dependencies. The script created for SLING-493 can be used to generate those files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling Release
If noone stops me I'll start to build the release candidates now Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
I'm finished with building the release artifacts. Please note that our current trunk is not buildable due to this. The artifacts reference the release versions which are not available in a public maven repository and the versions in our svn are set to the next snapshot. I'll correct this asap and start the vote. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
The depenencies are now all set to 2.0.1-incubator-SNAPSHOT. Once the release is out to the maven repos, we will revert this to 2.0.0-incubator where appropriate. Carsten Carsten Ziegeler wrote: I'm finished with building the release artifacts. Please note that our current trunk is not buildable due to this. The artifacts reference the release versions which are not available in a public maven repository and the versions in our svn are set to the next snapshot. I'll correct this asap and start the vote. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[VOTE] Release Sling Artifacts
Hello everyone, after some struggling we finally managed to built the release candidates (hurray); thanks for everyone helping in getting this done. I've put all release artifacts here: http://people.apache.org/~cziegeler/releases/sling/ The releases (source archives) are in http://people.apache.org/~cziegeler/releases/sling/releases For convenience we built binary distributions: http://people.apache.org/~cziegeler/releases/sling/binaries and all the maven artifacts: http://people.apache.org/~cziegeler/releases/sling/maven The KEYS file to check my signature is at http://people.apache.org/~cziegeler/releases/sling/ This time we are releasing a lot of artifacts - after this first release we will release one or two artifacts at a time in different intervals. As always the initial release is the hardest one. Although we release a set of artifacts, this is not an all-or-nothing vote! If one (or more) artifacts for whatever reason do not meet the release criterias, we still can/should release the remaining good artifacts. So hopefully we can release at least one to decrease the count :) (As we have some dependencies between the arifacts, turning down one artifact might prevent us from releasing others of course). Anyway, please indicate clearly for which artifacts you vote and with which artifacts you have problems! Here is the full list of releases: sling-1-incubator maven-jcrocm-plugin-2.0.0-incubator maven-jspc-plugin-2.0.0-incubator maven-sling-plugin-2.0.0-incubator org.apache.sling.adapter-2.0.0-incubator org.apache.sling.api-2.0.0-incubator org.apache.sling.bundleresource.impl-2.0.0-incubator org.apache.sling.commons.json-2.0.0-incubator org.apache.sling.commons.log-2.0.0-incubator org.apache.sling.commons.mime-2.0.0-incubator org.apache.sling.commons.osgi-2.0.0-incubator org.apache.sling.commons.scheduler-2.0.0-incubator org.apache.sling.commons.testing-2.0.0-incubator org.apache.sling.commons.threads-2.0.0-incubator org.apache.sling.engine-2.0.0-incubator org.apache.sling.event-2.0.0-incubator org.apache.sling.extensions.apt.parser-2.0.0-incubator org.apache.sling.extensions.apt.servlet-2.0.0-incubator org.apache.sling.httpauth-2.0.0-incubator org.apache.sling.i18n-2.0.0-incubator org.apache.sling.jcr.api-2.0.0-incubator org.apache.sling.jcr.base-2.0.0-incubator org.apache.sling.jcr.classloader-2.0.0-incubator org.apache.sling.jcr.contentloader-2.0.0-incubator org.apache.sling.jcr.jackrabbit.api-2.0.0-incubator org.apache.sling.jcr.jackrabbit.client-2.0.0-incubator org.apache.sling.jcr.jackrabbit.server-2.0.0-incubator org.apache.sling.jcr.ocm-2.0.0-incubator org.apache.sling.jcr.resource-2.0.0-incubator org.apache.sling.jcr.webdav-2.0.0-incubator org.apache.sling.launchpad.app-2.0.0-incubator org.apache.sling.launchpad.base-2.0.0-incubator org.apache.sling.launchpad.content-2.0.0-incubator org.apache.sling.launchpad.webapp-2.0.0-incubator org.apache.sling.samples.path-based.rtp-2.0.0-incubator org.apache.sling.samples.simple-demo-2.0.0-incubator org.apache.sling.samples.webloader.service-2.0.0-incubator org.apache.sling.samples.webloader.ui-2.0.0-incubator org.apache.sling.scripting.api-2.0.0-incubator org.apache.sling.scripting.core-2.0.0-incubator org.apache.sling.scripting.jsp-2.0.0-incubator org.apache.sling.scripting.javascript-2.0.0-incubator org.apache.sling.scripting.jsp.taglib-2.0.0-incubator org.apache.sling.servlets.get-2.0.0-incubator org.apache.sling.servlets.post-2.0.0-incubator org.apache.sling.servlets.resolver-2.0.0-incubator So please cast your votes. Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Roy T. Fielding wrote: But the NOTICE files are not for describing build dependencies. They exist to satisfy the copyright license of packaged distributions. If the notices aren't required by the bits in the package, then they don't belong in NOTICE. That means there will be a different NOTICE file required for each differently packaged set of bits. We must do this by hand. So this basically means that we only have to add something to the NOTICE file if the license of an included project requires this, right? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Cannot find parent: org.apache.sling:sling for project
Alexander Klimetschek wrote: Have you built Sling from the root directory before (X:\java\labs\osgi-sling\svn\sling\ mvn install)? Looks like the Sling root pom is not yet in your local maven 2 repository (and since there is no release yet, it is not on any public repositories yet). Ups, you're right - will fix this asap. Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Cannot find parent: org.apache.sling:sling for project
Mark wrote: Hi All I am trying to get started, however ( Am I missing a repository setting ? ) Hi, no this was a leftover from building the release candidate yesterday. Sorry for the inconvenience. It should be fixed now. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: The release is too complex? (Was: [VOTE] Release Sling Artifacts)
Jukka Zitting wrote: Hi, Whoa, you are running almost 50 release votes in parallel?!? I'm all for modularity, but isn't this a bit extreme? What's wrong with just tagging the entire trunk and having the release candidate be the packaged svn export of that tag? Hmm, don't know - noone came up with this *before* doing the release. :) In the end I see no real difference, you have to check the same amount of files, being it in one package or in 50. Separating this into several packages makes imho detecting stuff easier and might allow us to release at least some parts of it (if some other parts do not meet the release criteria - although I'm very confident that we did it right). If you wish, you can extract all 50 packages into one directory and test them at once :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [VOTE] Release Sling Artifacts
Alexander Klimetschek wrote: On Wed, Jun 4, 2008 at 7:51 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: org.apache.sling.i18n-2.0.0-incubator I have some suggestions for changes to the i18n/message bundle node types (although not finalized). Could this artifact be released later? (AFAIK no other code in Sling depends on it, it is only referenced in the pom of the launchpad/app) Or would it be no problem to change the nodetypes in an upcoming release (expect^H^H^H^H^H^H hoping you accept my proposal ;-))? Hmm, this is a little bit late - but I guess not too late; we could withdraw i18n from the vote if there are *good* reasons for it. So I suggest you open a new thread to discuss your ideas. Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Created: (SLING-498) Execute jobs only on the instance they were created on
Execute jobs only on the instance they were created on -- Key: SLING-498 URL: https://issues.apache.org/jira/browse/SLING-498 Project: Sling Issue Type: New Feature Components: Event Affects Versions: 2.0.0 Reporter: Carsten Ziegeler In a clustered environment a job might be executed by the first free node. Usually this should not cause any problems as the job event should contain all necessary information. However in some cases it might not be possible/feasible to put all information into the event. In these cases the job is usually only executable on the cluster node where the job has been created. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r662458 - in /incubator/sling/trunk/launchpad: app/NOTICE base/NOTICE content/NOTICE jcrapp/NOTICE webapp/NOTICE
I'm also wondering if we really need to mention stuff that is only used during the build but not contained in the release, like junit? Carsten Roy T. Fielding wrote: Unnecessary whitespace, headers, horizontal rules, page breaks, instructions on how to edit, and related nonsense should never appear in the NOTICE file that is required by our license to be displayed by downstream binary distributions like an About box. Roy -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Created: (SLING-497) Keep order of jobs when executing
Keep order of jobs when executing - Key: SLING-497 URL: https://issues.apache.org/jira/browse/SLING-497 Project: Sling Issue Type: New Feature Components: Event Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Usually jobs are executed in random manner (usually first one, first out), but especially in a cluster this might not be true. For some jobs it might be interesting to keep the order of execution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-499) Specify url mappings in bundle headers
Specify url mappings in bundle headers -- Key: SLING-499 URL: https://issues.apache.org/jira/browse/SLING-499 Project: Sling Issue Type: New Feature Affects Versions: 2.0.0 Reporter: Carsten Ziegeler It would be nice to specify a url mapping directly in the bundle header, like: Sling-Initial-ContentSLING-INF/content/Sling-Initial-Content Sling-Root-Mapping/apps/xyz/docroot, /apps/abc/docroot/Sling-Root-Mapping This would create two mappings: - / to /apps/xyz/docroot/ - / to /apps/abc/docroot/ In addition we could generalize this and provide arbitrary mappings: Sling-Mapping /:=/apps/xyz/docroot, /images:=/libs/images Sling-Mapping This would create two mappings: - / to /apps/xyz/docroot - /images to /libs/images -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: NOTICE files, include junit? (was: svn commit: r662458....)
Bertrand Delacretaz wrote: On Tue, Jun 3, 2008 at 9:28 AM, Felix Meschberger [EMAIL PROTECTED] wrote: Am Dienstag, den 03.06.2008, 09:23 +0200 schrieb Bertrand Delacretaz: ...What do people think? Exclude just junit, or more? If possible, we should probably just include the stuff with test scope... I assume you mean omit the stuff with test scope - that should be doable. If that works, I'm fine - we should do a sanity check afterwards anyway - which means comparing the release with the notice file to be sure. Just relying on the information maven provides seems too dangerous for me :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [continuum] BUILD FAILURE: Sling - Sling - Jackrabbit Embedded Repository - Build Def:
Felix Meschberger wrote: Hi, Obviously continuum hit the OutOfMemory issue ... I think it is about time (for me) to change the jackrabbit-repository build to not fail :) So we can remove this annoying notice about setting the memory from the build as well, great :) Actually, continuum hit the issue from the first day. But until now, mails were not sent to this list :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Bertrand Delacretaz wrote: I'm finishing up the NOTICE stuff, I suggest regenerating *all* NOTICE files with the mknotice script. Great! I'll modify the script to concatenate an optional local.notice.txt file, found in the same directory as the module's pom.xml, to the end of the NOTICE, for stuff like dojo which does not appear in the pom dependencies. Ok. I just ran into a blocker :( https://issues.apache.org/jira/browse/SLING-501 Sling does not work with the latest SCR implementations from Felix (1.0.1-SNAPSHOT). Unfortunately my own stuff requires the latest SCR and of course latest Sling...so I'm wondering if we could fix this issue in a way that Sling runs with the old SCR and the new one? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Commented: (SLING-501) RequestLoggerService does not run with latest SCR implementation from Felix
[ https://issues.apache.org/jira/browse/SLING-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601875#action_12601875 ] Carsten Ziegeler commented on SLING-501: This occurs due to the changes in FELIX-593 RequestLoggerService does not run with latest SCR implementation from Felix --- Key: SLING-501 URL: https://issues.apache.org/jira/browse/SLING-501 Project: Sling Issue Type: Bug Components: Engine Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Priority: Blocker Fix For: 2.0.0 The latest changes in the SCR implementation of Apache Felix break our current impl: 03.06.2008 11:30:48.952 *ERROR* [FelixStartLevel] org.apache.sling.engine General problem with descriptor entry 'OSGI-INF/serviceComponents.xml' (org.osgi.service.component.ComponentException: Component org.apache.sling.engine.impl.log.RequestLoggerService validation failed: Factory cannot be immediate) org.osgi.service.component.ComponentException: Component org.apache.sling.engine.impl.log.RequestLoggerService validation failed: Factory cannot be immediate at org.apache.felix.scr.impl.ComponentMetadata.validationFailure(ComponentMetadata.java:352) at org.apache.felix.scr.impl.ComponentMetadata.validate(ComponentMetadata.java:314) at org.apache.felix.scr.impl.XmlHandler.endElement(XmlHandler.java:244) at org.apache.felix.scr.impl.parser.KXml2SAXParser.parseXML(KXml2SAXParser.java:77) at org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:154) at org.apache.felix.scr.impl.BundleComponentActivator.init(BundleComponentActivator.java:110) at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:227) at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:173) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:690) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:619) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:532) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3601) at org.apache.felix.framework.Felix._startBundle(Felix.java:1616) at org.apache.felix.framework.Felix.startBundle(Felix.java:1544) at org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1125) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:258) at java.lang.Thread.run(Thread.java:613) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling Release
Felix Meschberger wrote: Actually, it would run ;-) The problem is the maven-scr-plugin which always sets the immediate attribute to true (if not explicitly) set. This is incorrect in connection with using the factory attribute (the same happens for the jcr/jackrabbit-server and jcr/jackrabbit-client bundles). The real fix is to use the latest maven-scr-plugin which does NOT set the attribute and then it should run. Yes, it might run with scr snapshot, but it doesn't run with scr 1.0.0 then :( As we definitly don't want to wait until scr and the scr plugin is released, what about not using the scr plugin for the logger but hand writing the xml file? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Felix Meschberger wrote: It _will_ run with the scr 1.0.0 snapshot, unless the immediate flag is set, which is the real bug behind this. If the immediate flag is not explicitly set to any value, both versions of SCR -- 1.0.0 and 1.0.1-SNAPSHOT -- assume their own default value valid in their context. And hence the bundle works. Yes, that's my understanding as well :) The real culprit, if you wish, is the maven-scr-plugin, which always sets this flag to an explict true value, thus prevent the bundle to work. We might need a maven-scr-plugin release ?? Yes, but we don't want to wait for that I guess/hope :) therefore why not hand writing the scr config without the explicit flag just for the release? The alternative would be to release the scr plugin (and we could then also release the scr to get the latest version), but this would require us to delay the release until next week. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Felix Meschberger wrote: Hi, Am Dienstag, den 03.06.2008, 11:13 +0200 schrieb Carsten Ziegeler: I created a profile in our reactor pom with the modules we don't want to include in our first release. I'm not sure if this list is complete/correct, so please cross check. I think we should try to build the release today, so what else needs to be done? Apart from the NOTICE stuff, I would say we are ready for rock'n'roll, right ? Yes, I think so - I just tested your changes regarding the factory stuff (SLING-502) and they work like expected. Great. Thanks! Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Felix Meschberger wrote: Hi, Am Dienstag, den 03.06.2008, 15:29 +0200 schrieb Carsten Ziegeler: Bertrand Delacretaz wrote: On Tue, Jun 3, 2008 at 3:07 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...One solution I could see is, that we mark all dependencies, which are included in a bundle as optional. This is done for the launchpad/app module to not include all dependencies and transitives into a project's dependency list when adding app as a dependency Created SLING-504 for that. Sorry, but I think we are abusing the maven dependency mechanism here a little bit. If this deps are included in the bundle they are not optional. So marking them optional just to get a correct notice file seems to be wrong. Kind of agreeing here. OTOH we mark them optional to not taint the transitive dependency system with unneeded dependencies. We might make use of this fact when building the notice files. :) tricky... Btw, anyone against changing the repository pinger (see SLING-505) and remove the debug logs for the release? I'm currently trying to debug something with log level set to debug and the log is growing like mad. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Bertrand Delacretaz wrote: On Tue, Jun 3, 2008 at 3:07 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...One solution I could see is, that we mark all dependencies, which are included in a bundle as optional. This is done for the launchpad/app module to not include all dependencies and transitives into a project's dependency list when adding app as a dependency Created SLING-504 for that. Sorry, but I think we are abusing the maven dependency mechanism here a little bit. If this deps are included in the bundle they are not optional. So marking them optional just to get a correct notice file seems to be wrong. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Created: (SLING-505) RepositoryPinger makes log unusable in debug mode
RepositoryPinger makes log unusable in debug mode - Key: SLING-505 URL: https://issues.apache.org/jira/browse/SLING-505 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: 2.0.0 Reporter: Carsten Ziegeler If debug logging is used, every two seconds a lot of debug messages are added by the repository pinger. This makes the log nearly unusable as it grows way too fast. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling Release
Bertrand Delacretaz wrote: I agree, but aren't we abusing it already? We are marking dependencies as provided, but including them in the generated artifact using the maven-bundle-plugin. The correct scope (although it does not exist, and IIRC you said custom scopes pose problems) might be bundled in this case, and the maven-bundle-plugin would then complain if trying to include the code of any package in the bundle code, unless that package comes from a bundled dependency, or comes from the project itself. Usually I use the scope compile when including bundles :) which is closer as optional and provided to what we do...not optimal though. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Ok, can we release? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Closed: (SLING-505) RepositoryPinger makes log unusable in debug mode
[ https://issues.apache.org/jira/browse/SLING-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-505. -- Resolution: Fixed Unfortunately this is not the only component involved in debug logging if the pinger, but that's all we can do in this module. RepositoryPinger makes log unusable in debug mode - Key: SLING-505 URL: https://issues.apache.org/jira/browse/SLING-505 Project: Sling Issue Type: Improvement Components: JCR Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 If debug logging is used, every two seconds a lot of debug messages are added by the repository pinger. This makes the log nearly unusable as it grows way too fast. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling Release
Bertrand Delacretaz wrote: On Mon, Jun 2, 2008 at 10:38 AM, Felix Meschberger [EMAIL PROTECTED] wrote: ...Am Montag, den 02.06.2008, 10:36 +0200 schrieb Bertrand Delacretaz: ... I think we must update the NOTICE files of the launchpad/app and webapp modules to mention all non-Apache dependencies, as listed by mvn dependency:resolve. I agree Can we automate this ? IIRC, Wicket has a way of combining multiple NOTICE files using Maven, I'll have a look at that... Afaik this is done by the maven remote resources plugin. I looked at it some months ago and I though that it's a mess :) It is able to collect the information from the dependencies, but this is of course based on the information from the various poms - and these are never really correct or complete. So it's possible to override this stuff and you end up maintaining the info just to use the plugin anyway. As dependencies do not change that often, I would prefer doing it by hand. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Determining if Events are local or external in a clustered environment
Erik Buene wrote: This did seem like a good solution, but I can't get it working properly. Tried to follow the documentation. Made a JCR listener that generates an OSGi event with the topic org/apache/sling/event/job, with custom event.job.topic and event.job.id. This OGSi event is sent to the EventAdmin. A custom event handler picks up the event sent back from Sling's JobEventHandler and should process it. This sounds good - now, the optimum would be if you can start with an OSGi event instead of relying on changes in the repository. But I guess this is not working in your scenario. The event/job mechanism is exactly designed for these cases. The important part when creating the job.id is that it is unique in the sense that two different changes get a different job id *and* it has to be the same on all cluster nodes. Only then the job mechanism is able to detect that the same job has been started on different nodes. Since the JCR event is sent to all nodes, and the eventlistener has no way of knowing if the request is local or external both nodes tries to make the OSGi event. Sling eventing system will try to make up for this to allow only one processing of a job by writing jobs to the repository (/var/eventing/jobs), trying to lock and send back to only one instance of the application based on if a corresponding job was already there and a lock was possible or not. Yes, that's based on the job.id. We have sling/jackrabbit on every node and have set up clustering in jackrabbit with a SimpleDbPersistenceManager to the same MySql database and journal. In this setup the eventing system works approximatly 4 out of 5 times when sync delay is set to 5 in the jackrabbit cluster. 1 out of 5 times both nodes will pass the request through the queue to our custom handler. It seems the problem is less frequent with a lower sync delay. Is this system intended for clustered sling with one Jackrabbit instance (through RMI)? Yes, it is intended for all clustering scenarios :) What dou you mean by both nodes will pass the request through the queue to our custom handler? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Bertrand Delacretaz wrote: On Mon, Jun 2, 2008 at 11:15 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Bertrand Delacretaz wrote: ...IIRC, Wicket has a way of combining multiple NOTICE files using Maven, I'll have a look at that... Afaik this is done by the maven remote resources plugin. I looked at it some months ago and I though that it's a mess :)... Ok, and what it does IIUC is concatenating NOTICE files from subprojects in the top-level NOTICE, that's not really what we need. I'm working on a shell script to generate those files semi-automatically from mvn dependency:resolve output, stay tuned... Great, please note that we only need this for the launchpad stuff; the other modules should be ok as I checked them some time ago manually :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Determining if Events are local or external in a clustered environment
Erik Buene wrote: to be the same on all cluster nodes. Only then the job mechanism is able to detect that the same job has been started on different nodes. Yes, this would be the next problem. For testing purposes I've been making id's based on the node path, to ensure this would be the same on all instances. Ok, yes, creating this unique id can be a pain; with JCR 2.0 this will be easier as there will be a time stamp of the change which should be unique together with the path. The custom handler on both server instances in the cluster (nodes in the cluster) receives the event (the custom event, not the first org/apache/sling/event/job), and on both instances there is no application.id - which means both instances treats it as being a local event, and starts to process it. Argh, ok, then this is definitly a bug, could you try to debug the problem? Or could you set the logger to level DEBUG and provide the logs? Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Using official JSON
Bertrand Delacretaz wrote: On Thu, May 29, 2008 at 4:09 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...All in all, I think, that we should probably stay with the current refactored JSON library and forget about this all +1, it's not a big deal to maintain, we have solid tests to verify it, and the ordering of properties is useful in some cases. I agree that it's not a big deal, although I prefer to use a dependency for stuff like this. Don't know if it makes sense, but what about keeping an OrderedJSONObject in our lib while using everything else from json.org? And if we keep all the duplicates in our code base, what about removing stuff that we don't use like the cookies stuff etc? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Using official JSON
Felix Meschberger wrote: Don't know if it makes sense, but what about keeping an OrderedJSONObject in our lib while using everything else from json.org? That would certainly be an option. But we would also need a modified OrderedJSONTokener then such that the constructor OrderedJSONObject(String) actually creates OrderedJSONObjects internally. Hmm, yes and there are other places throughout the lib where JSONObject is used or created. So, if the devs of the original code are not willing to help us, let's keep our own copy. My stance would be: either have it all or having nothing. But removing parts might be confusing. Hmm, I think it's more confusing to have a big lib where only three classes are used from :) But either way works for me. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Current Tests fail in servlets resolver
Hi, the junit tests in the servlets resolver module fail, because the provider factory requires the SERVICE.ID in the properties of a service refereence (ServiceResourceProviderFactory line 225) The junit tests use the mock service reference which by default does not have this property. As from the osgi point of view, each and every service reference must have this unique id, what do you think about adding it to the code in the constructor of the service reference? We can create a random unique number there. If a unit test requires a special one, it can overwrite it by calling the setProperty method on the mock object. WDYT? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Closed: (SLING-483) Add javadocs to release artifacts
[ https://issues.apache.org/jira/browse/SLING-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-483. -- Resolution: Fixed I've disabled javadocs where we don't need them and excluded private packages for the bundles. Add javadocs to release artifacts - Key: SLING-483 URL: https://issues.apache.org/jira/browse/SLING-483 Project: Sling Issue Type: New Feature Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 We should create javadocs artifacts for each bundle containing the javadocs of the public api. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Sling Release
Ten..nine... ...five... ...two...one There's one single issue for a 2.0.0 release in Jira (and it's about docs), so it really seems that we can release next week. :) So I think it's time to ask if there are any outstanding issues? Something we are currently not aware of? The final question is, what = which parts we want to release? I think there are some bundles/modules which we don't need to include in a first cut. WDYT? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Updated: (SLING-486) Filter chain is not updated when filters are updated
[ https://issues.apache.org/jira/browse/SLING-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-486: --- Fix Version/s: (was: 2.0.0) 2.0.1 As this is not a bug in Sling but in Felix I'll remove it from the 2.0.0 schedule. Filter chain is not updated when filters are updated Key: SLING-486 URL: https://issues.apache.org/jira/browse/SLING-486 Project: Sling Issue Type: Bug Components: Engine Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Fix For: 2.0.1 When a bundle containing a servlet filter is updated, the old already disposed instance is still used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [RT] Sling status servlet
This sounds good to me. I've one question, where do you configure the path for the status servlet? At least the sling main servlet needs to know this path. So why not making this an integral feature of the main servlet? Carsten Bertrand Delacretaz wrote: Hi, We had a chat with Felix about a way to provide an URL that tells the outside world whether a Sling application is ready to run, after startup. I need this for an application that launches a Sling application, and opens the browser on its welcome page once the application is ready. The ready to run condition can be tricky to evaluate, as there's a lot of asynchronous stuff going on when starting a Sling application (which might include creating and initializing a JCR repository). The existing HttpTestBase.slingServerReady() method uses a simple mechanism that is good enough for integration testing, but not extensible and entirely defined on the client side. To provide a customizable readyness test, we suggest the following: 1) Create a SlingStatusServlet mapped to /system/sling/status 2) SlingStatusServlet depends on the JcrResourceResolverFactory, and returns an HTTP 503 status as long as that's not available. This is the minimal test of Sling readyness. 3) SlingStatusServlet looks for scripts in the repository, under /system/sling/status, which must only contain nodes that can be adapted to scripts 4) All scripts found there (finding none is acceptable) are executed, their output is concatenated in the servlet response, and if any of them throws an exception the status servlet returns a 503 error. 5) Before processing requests, the SlingMainServlet asks the SlingStatusServlet if it thinks the system is ready (based on the above dependencies + scripts), and if not throws a 503 error, indicating the reason. Requests to /system/sling/status bypass this mechanism, of course. Once the SlingStatusServlet returns true for this call, the SlingMainServlet does not make the call anymore. This should provide an easily extensible way of finding out whether Sling applications are completely initialized. WDYT? -Bertrand -- Carsten Ziegeler [EMAIL PROTECTED]
Continuum mails are not sent to our list
Hi, it seems that the continuum mails are not sent to our sling-commits list anymore. Sending mails from continuum in general works. Are they stuck in some moderation queue? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Created: (SLING-486) Filter chain is not updated when filters are updated
Filter chain is not updated when filters are updated Key: SLING-486 URL: https://issues.apache.org/jira/browse/SLING-486 Project: Sling Issue Type: Bug Components: Engine Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Fix For: 2.0.0 When a bundle containing a servlet filter is updated, the old already disposed instance is still used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-486) Filter chain is not updated when filters are updated
[ https://issues.apache.org/jira/browse/SLING-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600475#action_12600475 ] Carsten Ziegeler commented on SLING-486: Further debugging seems to reveal that this is the same problem as https://issues.apache.org/jira/browse/FELIX-550 Two instances are created and registered, however if the timing is different, for instance during debugging everything works as expected. Filter chain is not updated when filters are updated Key: SLING-486 URL: https://issues.apache.org/jira/browse/SLING-486 Project: Sling Issue Type: Bug Components: Engine Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Fix For: 2.0.0 When a bundle containing a servlet filter is updated, the old already disposed instance is still used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-486) Filter chain is not updated when filters are updated
[ https://issues.apache.org/jira/browse/SLING-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600471#action_12600471 ] Carsten Ziegeler commented on SLING-486: Yes, I did refresh - here are some updates: During an update, the old instance is disposed, a new instance is created, activate is called, then the configuration updater kicks in, deactivates the old instance and creates a new one. From this point on, both instances are in the filter chain. 28.05.2008 15:23:11.552 *WARN* [SCR Component Actor] com.day.cq.cms.linkchecker.filter.LinkCheckerFilter FILTER: activate [EMAIL PROTECTED] : [EMAIL PROTECTED] 28.05.2008 15:23:45.547 *WARN* [Background Updatecom.day.cq.cq-linkchecker (65)] com.day.cq.cms.linkchecker.filter.LinkCheckerFilter FILTER: deactivate [EMAIL PROTECTED] : null 28.05.2008 15:23:45.591 *WARN* [SCR Component Actor] com.day.cq.cms.linkchecker.filter.LinkCheckerFilter FILTER: activate [EMAIL PROTECTED] : [EMAIL PROTECTED] 28.05.2008 15:23:45.592 *WARN* [Configuration Updater] com.day.cq.cms.linkchecker.filter.LinkCheckerFilter FILTER: deactivate [EMAIL PROTECTED] : null 28.05.2008 15:23:45.597 *WARN* [SCR Component Actor] com.day.cq.cms.linkchecker.filter.LinkCheckerFilter FILTER: activate [EMAIL PROTECTED] : [EMAIL PROTECTED] 28.05.2008 15:24:26.560 *WARN* [http-8080-1] com.day.cq.cms.linkchecker.filter.LinkCheckerFilter FILTER: filter [EMAIL PROTECTED] : null 28.05.2008 15:24:26.562 *WARN* [http-8080-1] com.day.cq.cms.linkchecker.filter.LinkCheckerFilter FILTER: filter [EMAIL PROTECTED] : [EMAIL PROTECTED] Filter chain is not updated when filters are updated Key: SLING-486 URL: https://issues.apache.org/jira/browse/SLING-486 Project: Sling Issue Type: Bug Components: Engine Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Fix For: 2.0.0 When a bundle containing a servlet filter is updated, the old already disposed instance is still used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Continuum mails are not sent to our list
Roy T. Fielding wrote: On May 28, 2008, at 2:16 PM, Jukka Zitting wrote: On Thu, May 29, 2008 at 12:13 AM, Roy T. Fielding [EMAIL PROTECTED] wrote: I thought that was because Jukka disabled Continuum. I did that only for Jackrabbit. Haven't touched any Sling infra. I think there is something wrong with the Sling build in Continuum that causes it to never finish -- it is killing the server performance. I checked an archived message and the sender is [EMAIL PROTECTED], which means it is not being blocked by the mailing list. Strange, I configured my email address as a second receiver and I get the continuum mails; I'll check the sender the next time I get a mail :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Created: (SLING-477) Limit the number of job retries by default configuration
Limit the number of job retries by default configuration Key: SLING-477 URL: https://issues.apache.org/jira/browse/SLING-477 Project: Sling Issue Type: Improvement Components: Event Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 A job can be configured when the job event is sent with a number of retries indicating how often the job should be rescheduled if something goes wrong. If this configuration is not available in the job event, the event is retried forever! The JobEventHandler should get a default configuration which is used in this case instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-462) Endless loop in JobEventHandler
[ https://issues.apache.org/jira/browse/SLING-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599577#action_12599577 ] Carsten Ziegeler commented on SLING-462: Looking at the code, I curently can't see how this state could be reached. Can you turn on debug logging and try to reproduce this state? If something goes wrong there should be an exception in the log. Endless loop in JobEventHandler --- Key: SLING-462 URL: https://issues.apache.org/jira/browse/SLING-462 Project: Sling Issue Type: Bug Components: Event Affects Versions: 2.0.0 Reporter: Tobias Bocanegra Assignee: Carsten Ziegeler Priority: Critical the runInBackground method has an endless loop, when - the queue is not empty, - the item still exists - parallelProcessing is false - the processing map already has the topic - the eventNode is not locked i don't know how exactly this state was reached, most probably by a failing JobProcessor. note: after the respective nodes are deleted, the endless loop ends :-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-462) Endless loop in JobEventHandler
[ https://issues.apache.org/jira/browse/SLING-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-462: -- Assignee: Carsten Ziegeler Endless loop in JobEventHandler --- Key: SLING-462 URL: https://issues.apache.org/jira/browse/SLING-462 Project: Sling Issue Type: Bug Components: Event Affects Versions: 2.0.0 Reporter: Tobias Bocanegra Assignee: Carsten Ziegeler Priority: Critical the runInBackground method has an endless loop, when - the queue is not empty, - the item still exists - parallelProcessing is false - the processing map already has the topic - the eventNode is not locked i don't know how exactly this state was reached, most probably by a failing JobProcessor. note: after the respective nodes are deleted, the endless loop ends :-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-452) Check jira components list
[ https://issues.apache.org/jira/browse/SLING-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-452. -- Resolution: Fixed Cleaned up the list and added some new components. Check jira components list -- Key: SLING-452 URL: https://issues.apache.org/jira/browse/SLING-452 Project: Sling Issue Type: Task Components: Engine Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 After all the refactoring but before the initial release, we should check that we have a component entry for each bundle in Jira (we should remove/rename obsolete components) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Newbie access
Hi Jeremias, Jeremias Maerki wrote: Following up on a suggestion by Bertrand I'm checking out Sling. I've gone through the 15 min tutorial. Well, it took me a lot longer than that. Just Maven downloading all the dependencies takes that much. BTW, I had to disable the testAttributes() and testDirectives() methods in: http://svn.apache.org/repos/asf/incubator/sling/trunk/commons/osgi/src/test/java/org/apache/sling/commons/osgi/ManifestHeaderTest.java to make Sling compile. Hmm, that works on my machine - can you give me the error? For the simple-demo, I think you should invoke /sample/content/home.html Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Resolved: (SLING-460) commons/osgi testAttributes() and testDirectives() fail under Windows
[ https://issues.apache.org/jira/browse/SLING-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-460. Resolution: Fixed The order of the attributes and directives is now preserved. commons/osgi testAttributes() and testDirectives() fail under Windows -- Key: SLING-460 URL: https://issues.apache.org/jira/browse/SLING-460 Project: Sling Issue Type: Bug Components: Commons OSGi Affects Versions: 2.0.0 Environment: Windows XP SP2, Java 1.5.0_14 Reporter: Bertrand Delacretaz Assignee: Carsten Ziegeler Priority: Minor Fix For: 2.0.0 In http://markmail.org/message/2umcs2tbahereydy, Jeremias Maerki reports that those two tests fail under Windows. They work for me on macosx 10.5, java 1.5.0_13, svn revision 656970. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Newbie access
The order of attributes and directives is now preserved. Jeremias could you please test if this works for you (I don't have access to a windows system atm)? Thanks Carsten Carsten Ziegeler wrote: Felix Meschberger wrote: Hi, Without reading code, this sounds like depending on the order of keys in a HashMap or the order of entries in a Set ;-) Yepp, that's the problem :) Thanks Jeremias for reporting this and thanks Felix for finding the problem. Now it's my turn to fix the test case :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Assigned: (SLING-414) Environment properties like sling.id, or sling.home are not available when launchpad is not used.
[ https://issues.apache.org/jira/browse/SLING-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-414: -- Assignee: Carsten Ziegeler Environment properties like sling.id, or sling.home are not available when launchpad is not used. - Key: SLING-414 URL: https://issues.apache.org/jira/browse/SLING-414 Project: Sling Issue Type: Bug Components: Engine Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 The Sling core defines some environment properties like sling.id or sling.home; these props are set by the Sling class from the launchpad. However if you deploy Sling as bundles in a running OSGi container, these props are not available which might cause some bundles to fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-460) commons/osgi testAttributes() and testDirectives() fail under Windows
[ https://issues.apache.org/jira/browse/SLING-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-460. -- commons/osgi testAttributes() and testDirectives() fail under Windows -- Key: SLING-460 URL: https://issues.apache.org/jira/browse/SLING-460 Project: Sling Issue Type: Bug Components: Commons OSGi Affects Versions: 2.0.0 Environment: Windows XP SP2, Java 1.5.0_14 Reporter: Bertrand Delacretaz Assignee: Carsten Ziegeler Priority: Minor Fix For: 2.0.0 In http://markmail.org/message/2umcs2tbahereydy, Jeremias Maerki reports that those two tests fail under Windows. They work for me on macosx 10.5, java 1.5.0_13, svn revision 656970. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-414) Environment properties like sling.id, or sling.home are not available when launchpad is not used.
[ https://issues.apache.org/jira/browse/SLING-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597406#action_12597406 ] Carsten Ziegeler commented on SLING-414: The sling.home variable makes only sense if the sling launchpad is used. The best way is to provide an own service for the sling.id Environment properties like sling.id, or sling.home are not available when launchpad is not used. - Key: SLING-414 URL: https://issues.apache.org/jira/browse/SLING-414 Project: Sling Issue Type: Bug Components: Engine Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 The Sling core defines some environment properties like sling.id or sling.home; these props are set by the Sling class from the launchpad. However if you deploy Sling as bundles in a running OSGi container, these props are not available which might cause some bundles to fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-460) commons/osgi testAttributes() and testDirectives() fail under Windows
[ https://issues.apache.org/jira/browse/SLING-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-460: -- Assignee: Carsten Ziegeler commons/osgi testAttributes() and testDirectives() fail under Windows -- Key: SLING-460 URL: https://issues.apache.org/jira/browse/SLING-460 Project: Sling Issue Type: Bug Components: Commons OSGi Affects Versions: 2.0.0 Environment: Windows XP SP2, Java 1.5.0_14 Reporter: Bertrand Delacretaz Assignee: Carsten Ziegeler Priority: Minor Fix For: 2.0.0 In http://markmail.org/message/2umcs2tbahereydy, Jeremias Maerki reports that those two tests fail under Windows. They work for me on macosx 10.5, java 1.5.0_13, svn revision 656970. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-414) Environment properties like sling.id, or sling.home are not available when launchpad is not used.
[ https://issues.apache.org/jira/browse/SLING-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-414. -- Resolution: Fixed Added new SlingSettingsService in the engine module which creates the sling.id; removed the sling.id generation from the launchpad. Environment properties like sling.id, or sling.home are not available when launchpad is not used. - Key: SLING-414 URL: https://issues.apache.org/jira/browse/SLING-414 Project: Sling Issue Type: Bug Components: Engine Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 The Sling core defines some environment properties like sling.id or sling.home; these props are set by the Sling class from the launchpad. However if you deploy Sling as bundles in a running OSGi container, these props are not available which might cause some bundles to fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (SLING-461) Move Sling Console to Apache Felix
Hmm, reminds me of SLING-405 :) https://issues.apache.org/jira/browse/SLING-405 Carsten Felix Meschberger (JIRA) wrote: Move Sling Console to Apache Felix -- Key: SLING-461 URL: https://issues.apache.org/jira/browse/SLING-461 Project: Sling Issue Type: Task Components: Console Reporter: Felix Meschberger Assignee: Felix Meschberger After the respective votes in both communities [1], [2] and successfull IP Clearance [3] the console module can now be moved over. This issue tracks work on the Sling side. There will be a similar issue for Felix to track the work on the Felix side. [1] http://markmail.org/message/hio3klxm35pwgfea [2] http://markmail.org/message/bqwv3o2r2twdbapj [3] http://incubator.apache.org/ip-clearance/felix-osgi-console.html -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Updated: (SLING-365) Checkin versionable nodes in initial content
[ https://issues.apache.org/jira/browse/SLING-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-365: --- Fix Version/s: 2.0.0 This should be fixed for the first release. Checkin versionable nodes in initial content Key: SLING-365 URL: https://issues.apache.org/jira/browse/SLING-365 Project: Sling Issue Type: Improvement Components: JCR Resource Reporter: Alexander Saar Fix For: 2.0.0 Attachments: checkin-initial-content.diff As discussed in [1] a bundle developer should be able to decide wether a versionable node in his initial content should be checked in after the content is imported or not. [1] http://www.mail-archive.com/sling-dev@incubator.apache.org/msg03804.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-456) Add manifest header parser
Add manifest header parser -- Key: SLING-456 URL: https://issues.apache.org/jira/browse/SLING-456 Project: Sling Issue Type: New Feature Components: OSGi Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 We need to parse manifest entries at several places, therefore it makes sense to have a parser at a common place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-441) Windows Users receiving java.lang.NoClassDefFoundError: org/apache/sling/launcher/webapp/SlingServlet$ServletContextResourceProvider
[ https://issues.apache.org/jira/browse/SLING-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-441: -- Assignee: Carsten Ziegeler Windows Users receiving java.lang.NoClassDefFoundError: org/apache/sling/launcher/webapp/SlingServlet$ServletContextResourceProvider Key: SLING-441 URL: https://issues.apache.org/jira/browse/SLING-441 Project: Sling Issue Type: Bug Components: Testing Environment: Windows Reporter: Paul Noden Assignee: Carsten Ziegeler Priority: Minor Fix For: 2.0.0 Attachments: failure.txt Windows Users recieve java.lang.NoClassDefFoundError: org/apache/sling/launcher/webapp/SlingServlet$ServletContextResourceProvider when running tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling applications and initial content loading
Felix Meschberger wrote: Hi, Am Mittwoch, den 14.05.2008, 18:46 +0200 schrieb Juan José Vázquez Delgado: Hi, On Wed, May 14, 2008 at 4:40 PM, Felix Meschberger [EMAIL PROTECTED] wrote: I agree, that it would make sense to have this parseHeader code in the commons/osgi module for multiple uses. Now, the commons/osgi module has one class only: OsgiUtils. Doy you mean we should have a parseHeader method in OsgiUtils or a new parser class, e.g. HeaderParser? I have no strong preference, really. Probably a separate class used for representing a header entry (like PathEntry in the jcr/contentloader) and a static method to create a collection of such entry instances from a header string would be best. I just added a new ManifestHeader class to the commons osgi module. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Continuum
Hi, as we are through with all the refactorings (hopefully) I just added all projects to continuum again. So let's wait for the mails... Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Commented: (SLING-441) Windows Users receiving java.lang.NoClassDefFoundError: org/apache/sling/launcher/webapp/SlingServlet$ServletContextResourceProvider
[ https://issues.apache.org/jira/browse/SLING-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597055#action_12597055 ] Carsten Ziegeler commented on SLING-441: I just tested the latest from svn on vista with maven 2.0.9 and jdk 1.5.0.13 and everything runs fine. Could you please give more information about your environment and recheck with latest from svn? Windows Users receiving java.lang.NoClassDefFoundError: org/apache/sling/launcher/webapp/SlingServlet$ServletContextResourceProvider Key: SLING-441 URL: https://issues.apache.org/jira/browse/SLING-441 Project: Sling Issue Type: Bug Components: Testing Environment: Windows Reporter: Paul Noden Assignee: Carsten Ziegeler Priority: Minor Fix For: 2.0.0 Attachments: failure.txt Windows Users recieve java.lang.NoClassDefFoundError: org/apache/sling/launcher/webapp/SlingServlet$ServletContextResourceProvider when running tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (SLING-459) Remove :savePrefix parameter
Isn't this the same as https://issues.apache.org/jira/browse/SLING-394 ? Carsten Felix Meschberger (JIRA) wrote: Remove :savePrefix parameter Key: SLING-459 URL: https://issues.apache.org/jira/browse/SLING-459 Project: Sling Issue Type: Improvement Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 The SlingPostServlet supports a :savePrefix parameter which may be set to indicate which fields should actually be stored as content and which should just be ignored. The main use case is to use existing forms and to be able to explicitly tell which parameters should be saved or not. In the meantime we realized, that either the prefix is not used at all or it will always be the same ./, ../ or /. So the :savePrefix parameter is removed and content modification/creation operation just scans the parameters: * If no parameters have either of the prefixes, all parameters not prefixed with the colon (:) used as the command prefix are stored * If at least parameter has either of the prefix, only parameters with either of the prefixes will be stored * Parameters prefixed with the colon (:) will never be stored as they are intended as processing parameters -- Carsten Ziegeler [EMAIL PROTECTED]
Re: SLING-414 Framework properties
Ok, no answer so far :( I looked at the config admin and I think that we perhaps could achieve a simpler solution by providing a ConfigurationPlugin which adds the sling.id to the configuration. WDYT? Carsten Carsten Ziegeler wrote: Hi, I'm wondering how we solve this issue. Currently framework properties like sling.id, sling.home are created/set in the launcher code which starts the Felix framework. This comes with the problem that these values are not available when a differen launcher/OSGi container is issued. Afaik, only these three values defined in the CoreConstants class are concerned. Or is there anything else? From these three values only the sling.id should be important to bundles, sling.home, sling.home.url are only of interest for the logging bundle; so we should perhaps make it usable without these properties being available (perhaps it already works). One way to make the sling.id available is to define a service providing the value. However, this is a heavy solution for the simple problem. Is there any simpler solution? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Import/Export Generalization
would implement the ImportExportHandler interface. Users of the functionality such as the default GET servlet, the SlingPostServlet and the Initial Content Loader would use the ImportExportService for their tasks. This feature can well be implemented after a first release because it only touches implementation of current functionality. WDYT ? Sounds good to me; I guess we have to experiment a little bit with the interface during development to see what's best. I think we should postpone this until after the release. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Assigned: (SLING-446) Move Scheduling to commons
[ https://issues.apache.org/jira/browse/SLING-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-446: -- Assignee: Carsten Ziegeler Move Scheduling to commons -- Key: SLING-446 URL: https://issues.apache.org/jira/browse/SLING-446 Project: Sling Issue Type: Task Components: Scheduler Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 The scheduler is a common bundle which has no dependencies to Sling itself, so we should move it to commons. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-450) Move bundles from sling to extensions
[ https://issues.apache.org/jira/browse/SLING-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-450: -- Assignee: Carsten Ziegeler Move bundles from sling to extensions --- Key: SLING-450 URL: https://issues.apache.org/jira/browse/SLING-450 Project: Sling Issue Type: Task Components: Core Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 The following bundles should be moved to the extensions directory: adapter, bundleresource, httpauth, i18n -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-450) Move bundles from sling to extensions
[ https://issues.apache.org/jira/browse/SLING-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-450. -- Resolution: Fixed Moved all bundles to extensions Move bundles from sling to extensions --- Key: SLING-450 URL: https://issues.apache.org/jira/browse/SLING-450 Project: Sling Issue Type: Task Components: Core Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 The following bundles should be moved to the extensions directory: adapter, bundleresource, httpauth, i18n -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-446) Move Scheduling to commons
[ https://issues.apache.org/jira/browse/SLING-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-446. -- Resolution: Fixed Moved and refactored to commons package. Move Scheduling to commons -- Key: SLING-446 URL: https://issues.apache.org/jira/browse/SLING-446 Project: Sling Issue Type: Task Components: Scheduler Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 The scheduler is a common bundle which has no dependencies to Sling itself, so we should move it to commons. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SLING-449: Renaming core to engine
Felix Meschberger wrote: Hi, Am Mittwoch, den 14.05.2008, 10:23 +0200 schrieb Carsten Ziegeler: Hi, should we also rename the package from core to engine (and everything else)? I think so, but I just wanted to check before doing :) Yes, I would say so, too. In addtion: the core (or engine) bundle provides API. Should we create a separate engine-api bundle ? Just thinking loud ;-) Hmm, do we expect different engines? :) I hope not :) So I guess we're fine with one bundle. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Closed: (SLING-449) Rename sling/core to engine
[ https://issues.apache.org/jira/browse/SLING-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-449. -- Resolution: Fixed Move core to engine and renamed the packages, the artifact id and CoreConstants to EngineConstants Rename sling/core to engine --- Key: SLING-449 URL: https://issues.apache.org/jira/browse/SLING-449 Project: Sling Issue Type: Task Components: Core Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 The current sling/core module should be moved to the top level and renamed to engine -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-451) Rename current sling directory to servlets
[ https://issues.apache.org/jira/browse/SLING-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-451: -- Assignee: Carsten Ziegeler Rename current sling directory to servlets -- Key: SLING-451 URL: https://issues.apache.org/jira/browse/SLING-451 Project: Sling Issue Type: Task Components: Core Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-451) Rename current sling directory to servlets
[ https://issues.apache.org/jira/browse/SLING-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-451. -- Resolution: Fixed Directory has been renamed. servlets-get has been renamed to servlets/get and package is now o.a.s.servlets.get servlets-post has been renamed to servlets/post servlet-resolver has been renamed to servlets/resolver and package is now o.a.s.servlets.resolver (as well as the artifact id) Rename current sling directory to servlets -- Key: SLING-451 URL: https://issues.apache.org/jira/browse/SLING-451 Project: Sling Issue Type: Task Components: Core Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling applications and initial content loading
Felix Meschberger wrote: ... Sling-Initial-ContentSLING-INFO/content;path:=/root/location/Sling-Initial-Content Is there any code available for parsing this information? I think it would make sense to put this into the commons/osgi module, so each and every bundle can make use of it. We use the same syntax for the various additional information. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Created: (SLING-442) Check osgi exports, imports, manifest entries (nodetypes etc.) and dependencies
Check osgi exports, imports, manifest entries (nodetypes etc.) and dependencies --- Key: SLING-442 URL: https://issues.apache.org/jira/browse/SLING-442 Project: Sling Issue Type: Task Components: Core Reporter: Carsten Ziegeler Fix For: 2.0.0 We should check all poms for accurancy before the release as due to the refactoring some poms might not be correct anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[RT] Cleaning up our modules (Part V)
Hi, it seems that we are nearly through - so this could be the last part of the series for now :) I think the remaining part is the sling directory. I'm not sure if this contains some extensions we could move to the extensions dir? And I think we should find a better name than sling for this directory as everything is Sling :) (it made sense when we distinguished between micro sling and sling). So any good idea? And the last thing I noticed is that commons testing now contains references to other sling modules which is a little bit against the idea of commons being independent from Sling. As the testing stuff is about jcr testing, we could move it to the jcr modules? (This one is not that important though) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Closed: (SLING-439) Clean up node type definitions
[ https://issues.apache.org/jira/browse/SLING-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-439. -- Resolution: Fixed Removed selector node type together with object handling stuff from core. Clean up node type definitions -- Key: SLING-439 URL: https://issues.apache.org/jira/browse/SLING-439 Project: Sling Issue Type: Improvement Components: Core Affects Versions: 2.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 2.0.0 The following node types will be removed: sling/core: references.cnd and selection.cnd together with the *.objects.* classes from core The content.cnd will be moved to the jcr.resource module (together with docs) In the i18n module, message.cnd and slinglanguage.cnd will be combined into a single file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
