Re: Requiring Maven 2.0.9
Gilles Scokart wrote: Except for the user that already have 2.0.7 installed and not 2.0.9. If you change your parent pom, you force them to reinstall maven. Sure, now, while I suggest everyone to upgrade to 2.0.9 I agree that we shouldn't change the requirement in Sling from 2.0.7 to 2.0.9 unless there is a good reason. So let's just leave it the way it is. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Assigned: (SLING-535) Align Node and Property Stores with Dojo's upcoming JsonRestStore
[ https://issues.apache.org/jira/browse/SLING-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-535: --- Assignee: Lars Trieloff Assigning to Lars on request Align Node and Property Stores with Dojo's upcoming JsonRestStore - Key: SLING-535 URL: https://issues.apache.org/jira/browse/SLING-535 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Lars Trieloff Assignee: Lars Trieloff Priority: Minor Dojo 1.2 will include (aside from widget beautification) a JsonRestStore that works very closely to what we already have in the dojo extensions, but it provides some additional features like object synchronization (which is good performance-wise if you are doing many reads on a node) and integration with Google Gears for offline support. Thanks to Michael Marth for spotting this and please assign this issue to me if possible. http://www.sitepen.com/blog/2008/06/13/restful-json-dojo-data/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: POST.esp when creating (201 - created)
Hi Erik, Am Samstag, den 14.06.2008, 20:52 +0200 schrieb Erik Buene: How can I make an esp that handles the request when creating a new node? .. and is it possible to do so for a specific resource type (or resource type of parent node)? POST.esp for resource type seems to work when the node is already created, but not at first post. If you request a resource, which does not exist, Sling uses a resource of type sling:nonexisting (Resource.RESOURCE_TYPE_NON_EXISTING constant), regardless of the request method. The path of the resource is HttpServletRequest.getPathInfo(). So you could well create a script /apps/sling/nonexisting/POST.esp which should be called when POST-ing to a non existing resource. Hope this helps. Regards Felix
Re: [jira] Created: (SLING-513) How to run the JCR Explorer with Sling?
Hi, Am Samstag, den 14.06.2008, 00:16 +0200 schrieb Jean-Yves Cronier: There is also another JCR Browser : http://sourceforge.net/projects/jcrbrowser Is it possible with this Eclipse plugin? Yes. It should be possible to connect to the repository embedded in Sling using RMI. by default the Sling embedded Jackrabbit repository is exposed in an RMI registry at port 1099 (the default RMI port) under the name jackrabbit. Hope this helps. Regards Felix
[jira] Commented: (SLING-533) Support multi-value type hints (eg. @TypeHint=String[])
[ https://issues.apache.org/jira/browse/SLING-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605216#action_12605216 ] Bertrand Delacretaz commented on SLING-533: --- I don't think this new behavior is tested, Alex could you maybe write some tests when you verify this feature? If you don't, please leave this issue open so that we don't forget to write tests when we find some time. Support multi-value type hints (eg. @TypeHint=String[]) --- Key: SLING-533 URL: https://issues.apache.org/jira/browse/SLING-533 Project: Sling Issue Type: New Feature Components: Servlets Post Reporter: Alexander Klimetschek Assignee: Carsten Ziegeler Fix For: 2.0.1 As discussed in SLING-522, when posting a single value to a property that should be multi-valued, an extension to the @TypeHint is needed that allows the explicit definition of a multi-value type. For example, for Strings this would be @TypeHint=String[]. Based on a quick look at the code, it should happen in o.a.s.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(). First of all the parsing of the getTypeHint() must be changed to look for an ending [] first, and then this isMultiValued information must be used to call the multi-value version of setProperty() in all cases (values.length = 0). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-534) Multi-Value Reference properties are not exposed to scripting the same way as single-value reference properties
[ https://issues.apache.org/jira/browse/SLING-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605217#action_12605217 ] Bertrand Delacretaz commented on SLING-534: --- Could you provide some automated tests for your patch? See https://svn.apache.org/repos/asf/incubator/sling/trunk/scripting/javascript/src/test/java/org/apache/sling/scripting/wrapper/ScriptableNodeTest.java for examples, the framework provides everything to make it very easy to add automated tests. Or let us know if something's missing, and we'll fix it. Multi-Value Reference properties are not exposed to scripting the same way as single-value reference properties --- Key: SLING-534 URL: https://issues.apache.org/jira/browse/SLING-534 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: 2.0.0 Reporter: Eric Norman Attachments: multival_refprops_lookup.diff If a node contains a multi-valued reference property, it is exposed to scripts as an array of UUID strings. For single-value reference properties the value is resolved to the referenced node. I'd expect the multi-value reference properties to be resolved the same way and exposed to scripting as an array of nodes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Automated tests please!
Hi, I've added subtle (hmm...) hints to some Jira issues and patches that lack tests - our test coverage is fairly decent at the moment, and we have very good infrastructure in place to write automated tests for most of our stuff (excluding OSGi bundle loading/unloading/reconfiguration unfortunately, that's on my wishlist at the moment [1]), so IMO there's no reason not to write them. I'd be very happy if people could make sure all new features or bug fixes are covered by automated tests, or at least create Jira issues to remind us to write them when we find some time. I'm available (within my unfortunate days-have-only-24-hours limitattions) for pointing people to existing example of tests and test helpers when needed, to help make that happen. Most of the tests that I wrote are based on the JUnit 3 interfaces, as I haven't spent enough time on the new stuff yet for it to come naturally when I write tests, but Carsten (at least) wrote some nice tests based on version 4 - so don't be shy to use that where it makes sense. -Bertrand [1] Creating or finding a framework that allows for injecting and configuring OSGi bundles during automated tests might be a nice way for someone to get involved without having to learn too much about Sling internals.
Re: License and notice files
Hi, On Fri, Jun 13, 2008 at 4:39 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...I've changed the handling of the notice/licence files as discussed recently. Each module has now a readme as well Thanks - I think the NOTICE files added under src/main/resources/META-INF are what my SLING-493 aimed to generate, but with Roy's explanations it is now clear why we disagreed on what needs to be there. ...So I think it's time to review this stuff and fix what needs to be fixed for a release. I hope we get through all of this by monday and can finally release Sling :)... Revision 668065 looks good to me, except launchpad/jcrapp/NOTICE which still contains a TODO. -Bertrand
[jira] Created: (SLING-536) Log configuration fails with ConfigurationException if log level configuration is missing
Log configuration fails with ConfigurationException if log level configuration is missing - Key: SLING-536 URL: https://issues.apache.org/jira/browse/SLING-536 Project: Sling Issue Type: Bug Components: Commons Log Affects Versions: 2.0.1 Reporter: Felix Meschberger Assignee: Felix Meschberger Currently configuraiton of a logger fails if the log level configuration setting is missing. The assumption was that a log level must be provided to clearly indicate the logging level required. This is probably true in the general case. However, when starting the commons/log bundle in an OSGi framework where the global log level is not set by a system property, the log level should be properly defaulted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Automated tests please!
Bertrand Delacretaz wrote: Most of the tests that I wrote are based on the JUnit 3 interfaces, as I haven't spent enough time on the new stuff yet for it to come naturally when I write tests, but Carsten (at least) wrote some nice tests based on version 4 - so don't be shy to use that where it makes sense. Yes, choose your fate :) However, junit 4 is defined in our parent pom, so this is the version we should use (you can still use the 3.x api with that version). We should define a different version in a child pom, as Maven (yes, again...) might choose junit 4 in your 3.x project and vice versa if you do the full build. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Automated tests please!
On Mon, Jun 16, 2008 at 10:15 AM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: Hi, I've added subtle (hmm...) hints to some Jira issues and patches that lack tests - our test coverage is fairly decent at the moment, and we have very good infrastructure in place to write automated tests for most of our stuff (excluding OSGi bundle loading/unloading/reconfiguration unfortunately, that's on my wishlist at the moment [1]), so IMO there's no reason not to write them. I'd be very happy if people could make sure all new features or bug fixes are covered by automated tests, or at least create Jira issues to remind us to write them when we find some time. I'm available (within my unfortunate days-have-only-24-hours limitattions) for pointing people to existing example of tests and test helpers when needed, to help make that happen. Most of the tests that I wrote are based on the JUnit 3 interfaces, as I haven't spent enough time on the new stuff yet for it to come naturally when I write tests, but Carsten (at least) wrote some nice tests based on version 4 - so don't be shy to use that where it makes sense. -Bertrand [1] Creating or finding a framework that allows for injecting and configuring OSGi bundles during automated tests might be a nice way for someone to get involved without having to learn too much about Sling internals. You might want to have a look at the spring framework: http://static.springframework.org/osgi/docs/current/reference/html/testing.html#testing:integration it looks promising but I haven't really found the time to test drive it myself... regards, Karl -- Karl Pauls [EMAIL PROTECTED]
Re: License and notice files
Bertrand Delacretaz wrote: Hi, On Fri, Jun 13, 2008 at 4:39 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...I've changed the handling of the notice/licence files as discussed recently. Each module has now a readme as well Thanks - I think the NOTICE files added under src/main/resources/META-INF are what my SLING-493 aimed to generate, but with Roy's explanations it is now clear why we disagreed on what needs to be there. Yes, it took me some time do understand this as well :) But now we are the first Java project at Apache doing it this way (at least I don't know of any other - but I don't know all of them...) ...So I think it's time to review this stuff and fix what needs to be fixed for a release. I hope we get through all of this by monday and can finally release Sling :)... Revision 668065 looks good to me, except launchpad/jcrapp/NOTICE which still contains a TODO. Ah yes, thanks - we won't release jcrapp in our first release, that's why I didn't cover it. I just made some minor updates, but we have to check everything for the first release of jcrapp. Thanks! Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: License and notice files
Bertrand Delacretaz wrote: Revision 668065 looks good to me. Great, thanks Bertrand. So I would like to hear a final comment from Jukka and Roy before cutting a release. Jukka? Roy? (Please note that we're currently waiting for a release of the Felix SCR module, the vote period is open but there are only two votes yet...) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: License and notice files
On Mon, Jun 16, 2008 at 11:22 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Bertrand Delacretaz wrote: Revision 668065 looks good to me. Great, thanks Bertrand. So I would like to hear a final comment from Jukka and Roy before cutting a release. Jukka? Roy? (Please note that we're currently waiting for a release of the Felix SCR module, the vote period is open but there are only two votes yet...) I will look at it tonight (i have been away last week). regards, Karl Carsten -- Carsten Ziegeler [EMAIL PROTECTED] -- Karl Pauls [EMAIL PROTECTED]
Re: POST.esp when creating (201 - created)
On Sat, Jun 14, 2008 at 8:52 PM, Erik Buene [EMAIL PROTECTED] wrote: ...How can I make an esp that handles the request when creating a new node? Depends on how you create it, but using the magic star resource, a script at at /apps/foo/POST.esp is executed if you do a POST to content/foo/*, for example. This works because a StarResource (see that class) is used for requests where the path ends with a star, and the launchpad uses the org.apache.sling.samples.pathbasedrtp.DefaultResourceTypeProvider to extract the resource type from the path (content/foo - foo), but only for paths under /content (configured in the DefaultResourceTypeProvider service). .. and is it possible to do so for a specific resource type (or resource type of parent node)?... In this case the resource type is set by the parent path, but that logic can be modified by implementing a different JcrResourceTypeProvider service. -Bertrand
[jira] Commented: (SLING-533) Support multi-value type hints (eg. @TypeHint=String[])
[ https://issues.apache.org/jira/browse/SLING-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605237#action_12605237 ] Alexander Klimetschek commented on SLING-533: - I tested it with a simple HTML file with different forms testing different cases (one value, multiple values, typehint set/not set) and it works so far (only Strings tested ATM). Now I am wondering how to automate this: the tests in the servlets/post module are purely based on a mocked (Sling) servlet request class. Using an actual HTML form is a better documentation IMHO - but it is also more of a larger integration test than a unit test. Support multi-value type hints (eg. @TypeHint=String[]) --- Key: SLING-533 URL: https://issues.apache.org/jira/browse/SLING-533 Project: Sling Issue Type: New Feature Components: Servlets Post Reporter: Alexander Klimetschek Assignee: Carsten Ziegeler Fix For: 2.0.1 As discussed in SLING-522, when posting a single value to a property that should be multi-valued, an extension to the @TypeHint is needed that allows the explicit definition of a multi-value type. For example, for Strings this would be @TypeHint=String[]. Based on a quick look at the code, it should happen in o.a.s.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(). First of all the parsing of the getTypeHint() must be changed to look for an ending [] first, and then this isMultiValued information must be used to call the multi-value version of setProperty() in all cases (values.length = 0). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-537) WebDAV module processes zip and xml files, should not happen
WebDAV module processes zip and xml files, should not happen Key: SLING-537 URL: https://issues.apache.org/jira/browse/SLING-537 Project: Sling Issue Type: Bug Components: JCR Reporter: Bertrand Delacretaz Priority: Minor Fix For: 2.0.0 The jcr/webdav/src/main/resources/webdav-resource-config.xml activates Jackrabbit's ZipHandler and XmlHandler, which means zip and xml files copied into the repository via WebDAV are expanded. This is not useful in the general case, and people do not expect it in the general case. I'll disable those configs in the jcr/webdav bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-533) Support multi-value type hints (eg. @TypeHint=String[])
[
https://issues.apache.org/jira/browse/SLING-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605241#action_12605241
]
Alexander Klimetschek commented on SLING-533:
-
There is one thing in the code that can be improved (in
SlingPropertyValueHelper): the list of values of the request property can never
have the length of null - RequestProperty.getStringValues() ensures this, and
it also does not make any sense with form posts, since a request parameter must
always have at least one value, otherwise it would simply not exist in the
request. So this code is superfluous (also for single-value property handling):
} else if (values.length == 0) {
// do not create new prop here, but clear existing
if (parent.hasProperty(prop.getName())) {
response.onModified(
parent.setProperty(prop.getName(), ).getPath()
);
}
Support multi-value type hints (eg. @TypeHint=String[])
---
Key: SLING-533
URL: https://issues.apache.org/jira/browse/SLING-533
Project: Sling
Issue Type: New Feature
Components: Servlets Post
Reporter: Alexander Klimetschek
Assignee: Carsten Ziegeler
Fix For: 2.0.1
As discussed in SLING-522, when posting a single value to a property that
should be multi-valued, an extension to the @TypeHint is needed that allows
the explicit definition of a multi-value type. For example, for Strings this
would be @TypeHint=String[].
Based on a quick look at the code, it should happen in
o.a.s.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs().
First of all the parsing of the getTypeHint() must be changed to look for an
ending [] first, and then this isMultiValued information must be used to
call the multi-value version of setProperty() in all cases (values.length =
0).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-533) Support multi-value type hints (eg. @TypeHint=String[])
[ https://issues.apache.org/jira/browse/SLING-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605245#action_12605245 ] Carsten Ziegeler commented on SLING-533: Ok, could you please open a new issue and attach a patch for this? Support multi-value type hints (eg. @TypeHint=String[]) --- Key: SLING-533 URL: https://issues.apache.org/jira/browse/SLING-533 Project: Sling Issue Type: New Feature Components: Servlets Post Reporter: Alexander Klimetschek Assignee: Carsten Ziegeler Fix For: 2.0.1 As discussed in SLING-522, when posting a single value to a property that should be multi-valued, an extension to the @TypeHint is needed that allows the explicit definition of a multi-value type. For example, for Strings this would be @TypeHint=String[]. Based on a quick look at the code, it should happen in o.a.s.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(). First of all the parsing of the getTypeHint() must be changed to look for an ending [] first, and then this isMultiValued information must be used to call the multi-value version of setProperty() in all cases (values.length = 0). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-538) SlingPropertyValueHelper.setPropertyAsIs() handles impossible empty-value-list case
SlingPropertyValueHelper.setPropertyAsIs() handles impossible empty-value-list
case
---
Key: SLING-538
URL: https://issues.apache.org/jira/browse/SLING-538
Project: Sling
Issue Type: Bug
Components: Servlets Post
Reporter: Alexander Klimetschek
Priority: Minor
The list of values of the request property can never have the length of null -
RequestProperty.getStringValues() ensures this, and it also does not make any
sense with form posts, since a request parameter must always have at least one
value, otherwise it would simply not exist in the request. So this code is
superfluous (also for single-value property handling):
} else if (values.length == 0) {
// do not create new prop here, but clear existing
if (parent.hasProperty(prop.getName())) {
response.onModified(
parent.setProperty(prop.getName(), ).getPath()
);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-533) Support multi-value type hints (eg. @TypeHint=String[])
[ https://issues.apache.org/jira/browse/SLING-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605249#action_12605249 ] Alexander Klimetschek commented on SLING-533: - Yup, see SLING-538. Support multi-value type hints (eg. @TypeHint=String[]) --- Key: SLING-533 URL: https://issues.apache.org/jira/browse/SLING-533 Project: Sling Issue Type: New Feature Components: Servlets Post Reporter: Alexander Klimetschek Assignee: Carsten Ziegeler Fix For: 2.0.1 As discussed in SLING-522, when posting a single value to a property that should be multi-valued, an extension to the @TypeHint is needed that allows the explicit definition of a multi-value type. For example, for Strings this would be @TypeHint=String[]. Based on a quick look at the code, it should happen in o.a.s.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(). First of all the parsing of the getTypeHint() must be changed to look for an ending [] first, and then this isMultiValued information must be used to call the multi-value version of setProperty() in all cases (values.length = 0). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: License and notice files
Jukka Zitting wrote: HI, On Mon, Jun 16, 2008 at 12:22 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: So I would like to hear a final comment from Jukka and Roy before cutting a release. Looks pretty good. Some comments: a) Some LICENSE files refer to feedparser tests, but I couldn't find them anywhere. Is the reference needed? No, its a copy-paste error :( b) Should we include Copyright (c) 2002 JSON.org in trunk/NOTICE? Hmm, Roy says we don't have to (at least this is what I understood during the whole discussion) - but lets add it. c) AFAIUI the year in Copyright ... The Apache Software Foundation statements should be 2008, not 2007-2008. See related discussion on [EMAIL PROTECTED] Not a blocker IMO. Yes, this is another one of those discussions :) I'll change all of them to 2008. d) Many of the generated bundles don't have complete NOTICE files (for example commons.log doesn't mention SLF4J even though SLF4J classes are included), but I wouldn't treat that as a blocker as the bundles are secondary release artifacts and the required information is still available in the LICENSE.* files. Great. Again these are things where Roy said we don't need them. e) The LICENSE files don't have references to the LICENSE.* files. Roy says they should. If we place references in LICENSE, I think we could just as well put the entire license texts there. I would go with a reference. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: License and notice files
Hi, On Mon, Jun 16, 2008 at 3:11 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On Mon, Jun 16, 2008 at 1:59 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Jukka Zitting wrote: ...d) Many of the generated bundles don't have complete NOTICE files (for example commons.log doesn't mention SLF4J even though SLF4J classes are included), but I wouldn't treat that as a blocker as the bundles are secondary release artifacts and the required information is still available in the LICENSE.* files. Great. Again these are things where Roy said we don't need them Jukka, are you talking about the NOTICE files under src/main/resources, i.e. the ones that get included in the binary artifacts? Yes. BR, Jukka Zitting
[jira] Closed: (SLING-537) WebDAV module processes zip and xml files, should not happen
[ https://issues.apache.org/jira/browse/SLING-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz closed SLING-537. - Resolution: Fixed Fixed in revision 668136, including tests which upload and check various types of files WebDAV module processes zip and xml files, should not happen Key: SLING-537 URL: https://issues.apache.org/jira/browse/SLING-537 Project: Sling Issue Type: Bug Components: JCR Reporter: Bertrand Delacretaz Priority: Minor Fix For: 2.0.0 The jcr/webdav/src/main/resources/webdav-resource-config.xml activates Jackrabbit's ZipHandler and XmlHandler, which means zip and xml files copied into the repository via WebDAV are expanded. This is not useful in the general case, and people do not expect it in the general case. I'll disable those configs in the jcr/webdav bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: License and notice files
Jukka Zitting wrote: This is also my understanding, i.e. we should include the attribution in NOTICE. Ok, so please go ahead and just add it - i'm fine with that. We already explicitly included the LICENSE file (LICENSE.slf4j in the example), so the question is whether we also need to include the copyright attribution in NOTICE. It's essentially the same question as above with JSON: should the copyright attribution go to NOTICE even if the third party license doesn't mandate where in a release the attribution should be? The source header and copyright notice policy says: The remainder of the NOTICE file is to be used for required third-party notices. (http://www.apache.org/legal/src-headers.html#notice) Actually if we can have everything at a single place seems to be easier for me. If you could just add the stuff, that would be great. Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: License and notice files
Hi, On Mon, Jun 16, 2008 at 3:44 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Jukka Zitting wrote: This is also my understanding, i.e. we should include the attribution in NOTICE. Ok, so please go ahead and just add it - i'm fine with that. OK. Actually if we can have everything at a single place seems to be easier for me. If you could just add the stuff, that would be great. OK, I'll do that. BR, Jukka Zitting
Re: License and notice files
On Mon, Jun 16, 2008 at 2:30 PM, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On Mon, Jun 16, 2008 at 3:13 PM, Karl Pauls [EMAIL PROTECTED] wrote: On Mon, Jun 16, 2008 at 1:59 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Jukka Zitting wrote: b) Should we include Copyright (c) 2002 JSON.org in trunk/NOTICE? Hmm, Roy says we don't have to (at least this is what I understood during the whole discussion) - but lets add it. I think we still need to keep the attribution as far as I understand his last mail... This is also my understanding, i.e. we should include the attribution in NOTICE. d) Many of the generated bundles don't have complete NOTICE files (for example commons.log doesn't mention SLF4J even though SLF4J classes are included), but I wouldn't treat that as a blocker as the bundles are secondary release artifacts and the required information is still available in the LICENSE.* files. Great. Again these are things where Roy said we don't need them. Again, I think for the binaries we do need the attribution and the LICENSE files because we don't embed the complete jar's. We only include some of the code -- hence, the original NOTICE and LICENSE files are not included in the resulting artifact and needs to be added by us. We already explicitly included the LICENSE file (LICENSE.slf4j in the example), so the question is whether we also need to include the copyright attribution in NOTICE. It's essentially the same question as above with JSON: should the copyright attribution go to NOTICE even if the third party license doesn't mandate where in a release the attribution should be? I think attribution should go in the NOTICE. Not doing that is confusing and really blurs the distinction between LICENSE and NOTICE file imo. regards, Karl The source header and copyright notice policy says: The remainder of the NOTICE file is to be used for required third-party notices. (http://www.apache.org/legal/src-headers.html#notice) BR, Jukka Zitting -- Karl Pauls [EMAIL PROTECTED]
[jira] Created: (SLING-539) Merge LICENSE.* information to LICENSE files
Merge LICENSE.* information to LICENSE files Key: SLING-539 URL: https://issues.apache.org/jira/browse/SLING-539 Project: Sling Issue Type: Improvement Components: General Reporter: Jukka Zitting Assignee: Jukka Zitting Fix For: 2.0.0 As discussed on the mailing list, we should merge third party license information from LICENSE.* files to the LICENSE files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-515) IncludeTest fails when run against another Sling instance
[ https://issues.apache.org/jira/browse/SLING-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-515: -- Fix Version/s: 2.0.0 IncludeTest fails when run against another Sling instance - Key: SLING-515 URL: https://issues.apache.org/jira/browse/SLING-515 Project: Sling Issue Type: Bug Components: Launchpad Affects Versions: 2.0.0 Reporter: Bertrand Delacretaz Priority: Minor Fix For: 2.0.0 Running the IncludeTest against a separate Sling instance like this: mvn -o -s /dev/null test -Dhttp.port=8080 -Dtest=IncludeTest -Dhttp.base.path=sling -Dwebdav.workspace.path=sling whereas it passes when run as part of the full build, where Sling runs in the same process and on / as opposed to /sling in the above example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-515) IncludeTest fails when run against another Sling instance
[ https://issues.apache.org/jira/browse/SLING-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz closed SLING-515. - Resolution: Fixed Fixed in revision 668150, DefaultErrorHandlerServlet outputs error info even if response is already committed, without changing response status. For some reason, the behavior is different when running the integration tests as part of the Maven build (response was not committed in this case) and when running them against a Sling webapp that was already started with mvn jetty:run. Different Jetty versions are used in both cases, that might explain the difference. Anyway, I think it's good for the DefaultErrorHandlerServlet to at least output error info even if it's too late to change the HTTP response status, instead of being silent in this case as before. IncludeTest fails when run against another Sling instance - Key: SLING-515 URL: https://issues.apache.org/jira/browse/SLING-515 Project: Sling Issue Type: Bug Components: Launchpad Affects Versions: 2.0.0 Reporter: Bertrand Delacretaz Priority: Minor Fix For: 2.0.0 Running the IncludeTest against a separate Sling instance like this: mvn -o -s /dev/null test -Dhttp.port=8080 -Dtest=IncludeTest -Dhttp.base.path=sling -Dwebdav.workspace.path=sling whereas it passes when run as part of the full build, where Sling runs in the same process and on / as opposed to /sling in the above example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Automated tests please!
Hi, Am Montag, den 16.06.2008, 11:42 +0200 schrieb Bertrand Delacretaz: On Mon, Jun 16, 2008 at 11:16 AM, Karl Pauls [EMAIL PROTECTED] wrote: ...You might want to have a look at the spring framework: http://static.springframework.org/osgi/docs/current/reference/html/testing.html#testing:integration.. Thanks for the pointer - David also reminds me that the jcrinstall module [1] might also help here, as with that bundles are installed by simply copying them into the repository. -Bertrand [1] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/jcrinstall/ That is certainly an option as soon as the repository involved. Technically, I would refrain from this as it just adds another heavy-weight to the tests, which should be fast, simple and furious ;-) We already have some infrastructure in place to provide bundles for installations during maven build time and requiring a running repository to have jcrinstall running is IMHO just too much. Regards Felix
[jira] Closed: (SLING-533) Support multi-value type hints (eg. @TypeHint=String[])
[ https://issues.apache.org/jira/browse/SLING-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek closed SLING-533. --- Verified that it works. I tested that it with other datatypes as well (Long, Double). Thanks for the quick fix Carsten! Support multi-value type hints (eg. @TypeHint=String[]) --- Key: SLING-533 URL: https://issues.apache.org/jira/browse/SLING-533 Project: Sling Issue Type: New Feature Components: Servlets Post Reporter: Alexander Klimetschek Assignee: Carsten Ziegeler Fix For: 2.0.1 Attachments: multival-post-test.html As discussed in SLING-522, when posting a single value to a property that should be multi-valued, an extension to the @TypeHint is needed that allows the explicit definition of a multi-value type. For example, for Strings this would be @TypeHint=String[]. Based on a quick look at the code, it should happen in o.a.s.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(). First of all the parsing of the getTypeHint() must be changed to look for an ending [] first, and then this isMultiValued information must be used to call the multi-value version of setProperty() in all cases (values.length = 0). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Automated tests please!
On Mon, Jun 16, 2008 at 3:24 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...We already have some infrastructure in place to provide bundles for installations during maven build time and requiring a running repository to have jcrinstall running is IMHO just too much Agree that if we can test bundle addition/removal/reconfiguration with a lighter setup than jcrinstall that's a good thing. -Bertrand
[jira] Assigned: (SLING-538) SlingPropertyValueHelper.setPropertyAsIs() handles impossible empty-value-list case
[
https://issues.apache.org/jira/browse/SLING-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-538:
--
Assignee: Carsten Ziegeler
SlingPropertyValueHelper.setPropertyAsIs() handles impossible
empty-value-list case
---
Key: SLING-538
URL: https://issues.apache.org/jira/browse/SLING-538
Project: Sling
Issue Type: Bug
Components: Servlets Post
Reporter: Alexander Klimetschek
Assignee: Carsten Ziegeler
Priority: Minor
Attachments: SLING-538.patch
The list of values of the request property can never have the length of null
- RequestProperty.getStringValues() ensures this, and it also does not make
any sense with form posts, since a request parameter must always have at
least one value, otherwise it would simply not exist in the request. So this
code is superfluous (also for single-value property handling):
} else if (values.length == 0) {
// do not create new prop here, but clear existing
if (parent.hasProperty(prop.getName())) {
response.onModified(
parent.setProperty(prop.getName(), ).getPath()
);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Releasing tomorrow morning
Hi, I plan to cut the (third) release candidate tomorrow morning CET - it seems that we will have a published Felix SCR release. So if you have any outstanding issues please fix them or at least bring them up by tomorrow morning. Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: svn commit: r668162 - /incubator/sling/trunk/servlets/get/pom.xml
Hi, I am not a fan of this. I did not export the renderes by intent. I am not sure, where we are heading with these and I do not want to burn some API we cannot sustain... And I am not sure, we should do this just for JST ! Rather we should include the renderers as private packages into the JST bundle if need be. Regards Felix Am Montag, den 16.06.2008, 13:54 + schrieb [EMAIL PROTECTED]: Author: bdelacretaz Date: Mon Jun 16 06:54:45 2008 New Revision: 668162 URL: http://svn.apache.org/viewvc?rev=668162view=rev Log: SLING-466 - export the org.apache.sling.servlets.get.helpers package: reusable default renderers Modified: incubator/sling/trunk/servlets/get/pom.xml Modified: incubator/sling/trunk/servlets/get/pom.xml URL: http://svn.apache.org/viewvc/incubator/sling/trunk/servlets/get/pom.xml?rev=668162r1=668161r2=668162view=diff == --- incubator/sling/trunk/servlets/get/pom.xml (original) +++ incubator/sling/trunk/servlets/get/pom.xml Mon Jun 16 06:54:45 2008 @@ -56,9 +56,11 @@ configuration instructions Private-Package -org.apache.sling.servlets.get.* +org.apache.sling.servlets.get.* ; -split-package:=merge-first /Private-Package - +Export-Package +org.apache.sling.servlets.get.helpers +/Export-Package Sling-Nodetypes SLING-INF/nodetypes/redirect.cnd /Sling-Nodetypes
Re: POST.esp when creating (201 - created)
Thank you Bertrand - this is what I was looking for! Is my assumption correct that we will have to process the changes to the repository in the script when using this approach? Regards, Erik Buene Bertrand Delacretaz wrote: On Sat, Jun 14, 2008 at 8:52 PM, Erik Buene [EMAIL PROTECTED] wrote: ...How can I make an esp that handles the request when creating a new node? Depends on how you create it, but using the magic star resource, a script at at /apps/foo/POST.esp is executed if you do a POST to content/foo/*, for example. This works because a StarResource (see that class) is used for requests where the path ends with a star, and the launchpad uses the org.apache.sling.samples.pathbasedrtp.DefaultResourceTypeProvider to extract the resource type from the path (content/foo - foo), but only for paths under /content (configured in the DefaultResourceTypeProvider service). .. and is it possible to do so for a specific resource type (or resource type of parent node)?... In this case the resource type is set by the parent path, but that logic can be modified by implementing a different JcrResourceTypeProvider service. -Bertrand
Re: Releasing tomorrow morning
Hi Carsten, Am Montag, den 16.06.2008, 15:58 +0200 schrieb Carsten Ziegeler: Hi, I plan to cut the (third) release candidate tomorrow morning CET Cool - it seems that we will have a published Felix SCR release. Yes, I will close the vote either today or tomorrow in the morning. So if you have any outstanding issues please fix them or at least bring them up by tomorrow morning. Regards Felix
Re: svn commit: r668162 - /incubator/sling/trunk/servlets/get/pom.xml
[EMAIL PROTECTED] wrote: Author: bdelacretaz Date: Mon Jun 16 06:54:45 2008 New Revision: 668162 URL: http://svn.apache.org/viewvc?rev=668162view=rev Log: SLING-466 - export the org.apache.sling.servlets.get.helpers package: reusable default renderers Hi, is this really required? I would like to export stuff only if we really really need it. The get servlets are not really public api. If someone wants to extend the servlets, its possible to just include the code from this module. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: svn commit: r668162 - /incubator/sling/trunk/servlets/get/pom.xml
On Mon, Jun 16, 2008 at 4:00 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...I am not sure, we should do this just for JST ! Rather we should include the renderers as private packages into the JST bundle if need be Ok, I see your point - I'll revert and use the renderers as private packages. The right way might be to create a separate bundle with those renderers, but we don't need this right now. -Bertrand Regards Felix Am Montag, den 16.06.2008, 13:54 + schrieb [EMAIL PROTECTED]: Author: bdelacretaz Date: Mon Jun 16 06:54:45 2008 New Revision: 668162 URL: http://svn.apache.org/viewvc?rev=668162view=rev Log: SLING-466 - export the org.apache.sling.servlets.get.helpers package: reusable default renderers Modified: incubator/sling/trunk/servlets/get/pom.xml Modified: incubator/sling/trunk/servlets/get/pom.xml URL: http://svn.apache.org/viewvc/incubator/sling/trunk/servlets/get/pom.xml?rev=668162r1=668161r2=668162view=diff == --- incubator/sling/trunk/servlets/get/pom.xml (original) +++ incubator/sling/trunk/servlets/get/pom.xml Mon Jun 16 06:54:45 2008 @@ -56,9 +56,11 @@ configuration instructions Private-Package -org.apache.sling.servlets.get.* +org.apache.sling.servlets.get.* ; -split-package:=merge-first /Private-Package - +Export-Package +org.apache.sling.servlets.get.helpers +/Export-Package Sling-Nodetypes SLING-INF/nodetypes/redirect.cnd /Sling-Nodetypes -- Bertrand Delacretaz http://www.codeconsult.ch
[jira] Commented: (SLING-538) SlingPropertyValueHelper.setPropertyAsIs() handles impossible empty-value-list case
[
https://issues.apache.org/jira/browse/SLING-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605295#action_12605295
]
Alexander Klimetschek commented on SLING-538:
-
Oh, I missed that one completely! Looks like this is by intention, ie. using
sling:ignore shall ignore the value.
But IIUC, this will lead to an empty property (values.length == 0 will trigger
parent.setProperty(prop.getName(), ) in setPropertyAsIs(). Seems to be a bug.
SlingPropertyValueHelper.setPropertyAsIs() handles impossible
empty-value-list case
---
Key: SLING-538
URL: https://issues.apache.org/jira/browse/SLING-538
Project: Sling
Issue Type: Bug
Components: Servlets Post
Reporter: Alexander Klimetschek
Assignee: Carsten Ziegeler
Priority: Minor
Attachments: SLING-538.patch
The list of values of the request property can never have the length of null
- RequestProperty.getStringValues() ensures this, and it also does not make
any sense with form posts, since a request parameter must always have at
least one value, otherwise it would simply not exist in the request. So this
code is superfluous (also for single-value property handling):
} else if (values.length == 0) {
// do not create new prop here, but clear existing
if (parent.hasProperty(prop.getName())) {
response.onModified(
parent.setProperty(prop.getName(), ).getPath()
);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r668162 - /incubator/sling/trunk/servlets/get/pom.xml
Hi, Thanks and Regards Felix Am Montag, den 16.06.2008, 16:04 +0200 schrieb Bertrand Delacretaz: On Mon, Jun 16, 2008 at 4:00 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...I am not sure, we should do this just for JST ! Rather we should include the renderers as private packages into the JST bundle if need be Ok, I see your point - I'll revert and use the renderers as private packages. The right way might be to create a separate bundle with those renderers, but we don't need this right now. -Bertrand Regards Felix Am Montag, den 16.06.2008, 13:54 + schrieb [EMAIL PROTECTED]: Author: bdelacretaz Date: Mon Jun 16 06:54:45 2008 New Revision: 668162 URL: http://svn.apache.org/viewvc?rev=668162view=rev Log: SLING-466 - export the org.apache.sling.servlets.get.helpers package: reusable default renderers Modified: incubator/sling/trunk/servlets/get/pom.xml Modified: incubator/sling/trunk/servlets/get/pom.xml URL: http://svn.apache.org/viewvc/incubator/sling/trunk/servlets/get/pom.xml?rev=668162r1=668161r2=668162view=diff == --- incubator/sling/trunk/servlets/get/pom.xml (original) +++ incubator/sling/trunk/servlets/get/pom.xml Mon Jun 16 06:54:45 2008 @@ -56,9 +56,11 @@ configuration instructions Private-Package -org.apache.sling.servlets.get.* +org.apache.sling.servlets.get.* ; -split-package:=merge-first /Private-Package - +Export-Package +org.apache.sling.servlets.get.helpers +/Export-Package Sling-Nodetypes SLING-INF/nodetypes/redirect.cnd /Sling-Nodetypes
[jira] Resolved: (SLING-508) Parameter decoding uses wrong default charset
[ https://issues.apache.org/jira/browse/SLING-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-508. - Resolution: Fixed Fix Version/s: 2.0.1 Committed the following fix to request parameter handling in Rev. 668173. Before asking the servlet container for its request parameters, the ParameterSupport.getContainerParameters() method sets the request character encoding to ISO-8859-1 if not already set by the request itself. This should cause the request parameters to be decoded as ISO-8859-1. After reading all request parameters all parameters (container parameters and multipart/form-data parameters) are re-coded to the encoding specified in the _charset_ parameter. For container parameters this means, they are converted to bytes again with ISO-8859-1 and then converted to strings using the _charset_ encoding. Thus UTF-8 submitted data should be treated correctly, no matter what servlet container is actually used. Parameter decoding uses wrong default charset - Key: SLING-508 URL: https://issues.apache.org/jira/browse/SLING-508 Project: Sling Issue Type: Bug Components: Engine Affects Versions: 2.0.0 Reporter: Tobias Bocanegra Assignee: Felix Meschberger Priority: Blocker Fix For: 2.0.1 As of SLING-152 the request paremeters are re-encoded if a _charset_ parameter is present. it assumes that the default encoding is UTF-8 which is not the case for servlet spec compliant containers (eg. tomcat). change the default encoding to ISO-8851-1 or make it configurable. see: http://svn.apache.org/viewvc/incubator/sling/trunk/engine/src/main/java/org/apache/sling/engine/impl/parameters/Util.java?view=markup -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-534) Multi-Value Reference properties are not exposed to scripting the same way as single-value reference properties
[ https://issues.apache.org/jira/browse/SLING-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-534: Attachment: SLING-534-fmeschbe.patch Very good point. Thanks Erik. But how about this patch ? It unifies the value handling in the wrap method handling reference values. This concentrates handling of REFERNCE values in a single place. Multi-Value Reference properties are not exposed to scripting the same way as single-value reference properties --- Key: SLING-534 URL: https://issues.apache.org/jira/browse/SLING-534 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: 2.0.0 Reporter: Eric Norman Attachments: multival_refprops_lookup.diff, SLING-534-fmeschbe.patch If a node contains a multi-valued reference property, it is exposed to scripts as an array of UUID strings. For single-value reference properties the value is resolved to the referenced node. I'd expect the multi-value reference properties to be resolved the same way and exposed to scripting as an array of nodes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-512) APT servlet takes over requests that do not have the aptml extension
[ https://issues.apache.org/jira/browse/SLING-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-512: --- Fix Version/s: (was: Servlets Resolver 2.0.2) Servlets Resolver 2.0.4 APT servlet takes over requests that do not have the aptml extension Key: SLING-512 URL: https://issues.apache.org/jira/browse/SLING-512 Project: Sling Issue Type: Bug Components: Servlets Resolver Affects Versions: 2.0.0 Reporter: Bertrand Delacretaz Assignee: Felix Meschberger Fix For: Servlets Resolver 2.0.4 I downloaded http://people.apache.org/~cziegeler/releases/sling/maven/org.apache.sling.launchpad.app-2.0.0-incubator.jar and started it with java -jar ... Going to http://localhost:8080/index.html shows the page with no css and no logo, and http://localhost:8080/sling-logo.png gives an Exception while parsing APT content error. After stopping the APT servlet bundle, everything's back to normal. Same problem in the trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-466) JST scripting engine: render indexable HTML and separate javascript code
[ https://issues.apache.org/jira/browse/SLING-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605326#action_12605326 ] Bertrand Delacretaz commented on SLING-466: --- Revision 668200 renders the HTML and javascript separately, using the JsCodeGeneratorServlet, mapped to the jst selector and js extension, to generate the javascript code. The page title is the value of the first of these properties that's set on the node being rendered, if they are present: title, name, description. If not, the title is the node path, relative from the root. I'm thinking of allowing additional head elements to be defined by the JST script, maybe something like !-- jst:head link rel=stylesheet href=/apps/foo/foo.css/ link rel=stylesheet href=/apps/foo/foo.print.css/ -- Where everything between the comments would be added to the generated html head element. And maybe also use something like !-- jst:body:class foo -- !-- jst:body:id bar -- To set class=foo and id=bar on the generated body element. JST scripting engine: render indexable HTML and separate javascript code Key: SLING-466 URL: https://issues.apache.org/jira/browse/SLING-466 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Bertrand Delacretaz Priority: Minor The JST scripting engine should output a default HTML rendering, meant to be indexed by search engines, with a script element that points to a separate javascript resource to render the page. The idea is that the javascript code will be cached by client browsers, being the same for all resources that have the same sling:resourceType. The HTML rendering should include a meaningful title element, using the value of a property named title or description, if present, or the node name if not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-541) Clarify scripting/ruby licensing
Clarify scripting/ruby licensing Key: SLING-541 URL: https://issues.apache.org/jira/browse/SLING-541 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Jukka Zitting The extensions/ruby component comes with the LICENSE.jruby file (which should be merged to LICENSE) and a jruby.codehaus.org notice, but I'm not sure if that covers everything included. The generated bundle contains lots of Ruby code and Java packages like com.sun.jna, jline, and org.joda.time that seem to come under different licenses. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-542) Clarify launchpad/jcrapp licensing
Clarify launchpad/jcrapp licensing -- Key: SLING-542 URL: https://issues.apache.org/jira/browse/SLING-542 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Jukka Zitting Priority: Minor The launchpad/jcrapp component doesn't come with correct LICENSE and NOTICE files to be included in the generated bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-539) Merge LICENSE.* information to LICENSE files
[ https://issues.apache.org/jira/browse/SLING-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved SLING-539. - Resolution: Fixed Resolving as Fixed with these followup issues: SLING-540: Clarify extensions/dojo licensing SLING-541: Clarify scripting/ruby licensing SLING-542: Clarify launchpad/jcrapp licensing Merge LICENSE.* information to LICENSE files Key: SLING-539 URL: https://issues.apache.org/jira/browse/SLING-539 Project: Sling Issue Type: Improvement Components: General Reporter: Jukka Zitting Assignee: Jukka Zitting Fix For: 2.0.0 As discussed on the mailing list, we should merge third party license information from LICENSE.* files to the LICENSE files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Releasing tomorrow morning
Hi, On Mon, Jun 16, 2008 at 4:58 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: So if you have any outstanding issues please fix them or at least bring them up by tomorrow morning. I've now merged all the license information to LICENSE files (SLING-539) and updated the META-INF/NOTICE files to cover all included dependencies. See [1] for all the related changes. I also filed some followup issues: SLING-540: Clarify extensions/dojo licensing SLING-541: Clarify scripting/ruby licensing SLING-542: Clarify launchpad/jcrapp licensing None of these is a blocker for the release, but we may want to avoid pushing those bundles to the Maven repository. [1] https://issues.apache.org/jira/browse/SLING-539?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel BR, Jukka Zitting
Re: Weekly Report for Sling/Scala [Need help in solving problem]
Hi, Thanks for throwing me a lifeline Bertrand.I'll write tests and proceed with the rest until a solution is found. I think Bertrand it would be best to ask from scala folks if possible. I posted about this in the scala mailing list some time ago but there was no positive reply. You can check this post by using the following link, http://www.nabble.com/Help-solve-exception-thrown-when-calling-interpreter-in-scala.-td17753046.html#a17753046 Also I found the following URL's which directed me to my conclusion. [1] https://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/build.examples.xml This shows that the path to the library is given in the xml. [2] http://www.nabble.com/Scala-Interpreter-inside-OSGi-td15733281.html This document shows the exception thrown when calling the Interpreter and it shows an example of setting the library path using a string. [3] http://www.nabble.com/Compiler-API-td12050645.html#a12051708 The error passed to Settings in the code given uses a guessed path according to whats defined in scala.tools.nsc.Settings. I realised this by looking at https://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/compiler/scala/tools/nsc/Main.scala A couple of questions more. 1. The engine needs to work with nodes so should I follow the path taken by the java script engine ? 2. To parse scala code within html can I use the filtering shown in EspReader.java in javascript engine ? Thanks Felix and Karl for sharing your views . regards, janandith.
Exception during Sling shutdown
I am making some tests with the current Sling code and I got the following exception when I shutdown Sling from the console. I'm just wondering if it is a well known issue. I didn't find something like this in markmail. So, I can create a new jira issue if needed. I'm running on XP. br, Christophe ERROR: EventDispatcher: Error during dispatch. (java.lang.IllegalStateException: Invalid BundleContext.) java.lang.IllegalStateException: Invalid BundleContext. at org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:453) at org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextImpl.java:422) at org.osgi.util.tracker.ServiceTracker.removedService(ServiceTracker.java:422) at org.osgi.util.tracker.ServiceTracker$Tracked.untrack(ServiceTracker.java:1117) at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:948) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:765) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:623) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:554) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3612) at org.apache.felix.framework.Felix.access$000(Felix.java:36) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:626) at org.apache.felix.framework.ServiceRegistry.fireServiceChanged(ServiceRegistry.java:559) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:96) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:112) at org.apache.felix.framework.ServiceRegistry.unregisterServices(ServiceRegistry.java:135) at org.apache.felix.framework.Felix._stopBundle(Felix.java:2034) at org.apache.felix.framework.Felix.stopBundle(Felix.java:1954) at org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1141) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:258) at java.lang.Thread.run(Unknown Source)
