Jenkins build became unstable: sling-oak-it-1.6 #299

[Apache Jenkins Server]

See 

Re: SLING-4318 servlet that lists versions, potential conflict with V selector

[Tomek Rękawek]

Hello Justin,

On Wed, Jan 28, 2015 at 8:14 PM, Justin Edelson 
wrote:

> How about using ConfigurationPolicy.REQUIRE for this so that it needs
> to be manually enabled? I suspect that's probably a good idea for this
> feature anyway even if there was no potential collision.
>

Great idea! I can add the ConfigurationPolicy and set the configuration as
metatype, so users can create their configuration via Felix Console.

Bertrand, WDYT?

Regards,
Tomek


> On Wed, Jan 28, 2015 at 12:33 PM, Bertrand Delacretaz
>  wrote:
> > Hi,
> >
> > For SLING-4318 Tomek's contribution uses the V selector that I
> > suggested so that foo.V.json lists the versions of the foo node.
> >
> > Putting this servlet in our servlets.get bundle might interfere with
> > existing user servlets that use this selector.
> >
> > How should we avoid this potential collision? Put the new servlet in a
> > different bundle? Make its selector configurable?
> >
> > -Bertrand
>



-- 
Tomek Rękawek
Senior Software Engineer

Cognifide Polska Sp. z o.o.
skype: trekawek

www.cognifide.com

[jira] [Commented] (SLING-4344) Modifying i18n language node in a path outside the resource resolver's search path will not invalidate the ResourceBundle cache

[Alexander Klimetschek (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295900#comment-14295900
 ] 

Alexander Klimetschek commented on SLING-4344:
--

Hmm, while the fix might be good, I don't think it's a good idea to put 
resource bundles outside /apps or /libs. They are considered part of the code 
base and thus follow very different ACLs and lifecycle than say /content (as in 
above example), so you want to be really careful about this.

> Modifying i18n language node in a path outside the resource resolver's search 
> path will not invalidate the ResourceBundle cache
> ---
>
> Key: SLING-4344
> URL: https://issues.apache.org/jira/browse/SLING-4344
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: i18n 2.3.2
>Reporter: Konrad Windszus
> Fix For: i18n 2.3.4
>
> Attachments: SLING-4344-v02.patch
>
>
> Currently any modification of a Sling i18n message will not invalidate the 
> {{resourceBundleCache}} in the {{JcrResourceBundleProvide}} 
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L118),
>  because the {{languageRoots}} for a {{JcrResourceBundle}} with a unique 
> basename and contents only outside of the resource resolver's search path are 
> always empty 
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L211).
> I would argue that it should be allowed to place language nodes anywhere in 
> the repository, which seems to work well except for the cache invalidation. 
> The problem is in the {{loadFully}} method 
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L155)
>  which will only set languageRoots if they are below any of the resource 
> resolver's search paths.
> To reproduce the issue you can just add the following node structure
> {code}
> /content/languages
>+-- English (nt:folder, mix:language)
>|+-- jcr:language = en
>|+-- basename = myuniquebasename
>|+-- m1 (sling:messageEntry)
>||+-- sling:key = "msg001"
>||+-- sling:message = "This is a message"
> {code}
> Then load the key from this resource bundle (by giving the right basename). 
> It will internally put the resource bundle into the cache (although all 
> contents of the given resource bundle are outside any of the default search 
> paths /apps or /libs). Whenever you change the message that won't be 
> reflected, because the resource bundle cache is not invalidated (caused by 
> the empty {{languageRoots}}) therefore the old message would still be 
> exposed, until you restart the Sling i18n bundle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: SLING-4318 servlet that lists versions, potential conflict with V selector

[Justin Edelson]

How about using ConfigurationPolicy.REQUIRE for this so that it needs
to be manually enabled? I suspect that's probably a good idea for this
feature anyway even if there was no potential collision.

Regards,
Justin

On Wed, Jan 28, 2015 at 12:33 PM, Bertrand Delacretaz
 wrote:
> Hi,
>
> For SLING-4318 Tomek's contribution uses the V selector that I
> suggested so that foo.V.json lists the versions of the foo node.
>
> Putting this servlet in our servlets.get bundle might interfere with
> existing user servlets that use this selector.
>
> How should we avoid this potential collision? Put the new servlet in a
> different bundle? Make its selector configurable?
>
> -Bertrand

Re: SLING-4358 - provide/require capability, should we define a standard for capability names?

[Felix Meschberger]

Hi

I think the capability here really says „this bundle implements Sightly 
Language Spec 1.1“ And since this spec is outside of Sling at [1] and commonly 
referred to as sightly.io I would think we should be using a namespace which 
matches the Sightly Language Spec and is not implementation specific with Sling

We could, of course, add an attribute indicating that this would be the Sling 
implementation.

Regards
Felix

[1] https://github.com/Adobe-Marketing-Cloud/sightly-spec


> Am 28.01.2015 um 13:43 schrieb Robert Munteanu :
> 
> Hi,
> 
> On Tue, Jan 27, 2015 at 6:33 PM, Bertrand Delacretaz
>  wrote:
>> Hi,
>> 
>> By analogy with
>> http://www.osgi.org/Specifications/ReferenceNamespaces, should we
>> agree on a prefix such as "org.apache.sling.capability.MMM" for our
>> capability names, where MMM is the module name like "sightly"?
> 
> I don't see why not, it's good to namespace them. I would be slightly
> inclined to drop the 'capability' from the prefix, since it would look
> a bit rendundant. Compare
> 
>   Require-Capability: org.apache.sling.capability.sightly;
> filter:="(version=1.0)"
> 
> with
> 
>   Require-Capability: org.apache.sling.sightly; filter:="(version=1.0)"
> 
> Cheers,
> 
> Robert

[jira] [Commented] (SLING-4340) SLING-4247 created odd side-effects

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295476#comment-14295476
 ] 

Justin Edelson commented on SLING-4340:
---

[~cziegeler] I think this will work for my use case, but I'd like to test a bit 
locally.

[~gknob] any thoughts?

> SLING-4247 created odd side-effects
> ---
>
> Key: SLING-4340
> URL: https://issues.apache.org/jira/browse/SLING-4340
> Project: Sling
>  Issue Type: Bug
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Resource Merger 1.2.4
>
>
> The change made in SLING-4247 created an unfortunate side effect for this 
> scenario:
> /apps/a/1/a - nt:unstructured node, no sling:resourceType property
> /apps/a/2/a - sling:resourceType set to foo/bar
> /apps/a/1 has sling:resourceSuperType set to /apps/a/2
> Then
> resourceResolver.getResource("/mnt/override/apps/a/1/a").getResourceType() 
> will be nt:unstructured
> This strikes me as wrong. And in fact screws up what is for me the main usage 
> of this feature because it shouldn't be necessary to set the 
> sling:resourceType all the time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

SLING-4318 servlet that lists versions, potential conflict with V selector

[Bertrand Delacretaz]

Hi,

For SLING-4318 Tomek's contribution uses the V selector that I
suggested so that foo.V.json lists the versions of the foo node.

Putting this servlet in our servlets.get bundle might interfere with
existing user servlets that use this selector.

How should we avoid this potential collision? Put the new servlet in a
different bundle? Make its selector configurable?

-Bertrand

[jira] [Updated] (SLING-4318) Sling resource API does not expose any versioning features - bounty offered.

[Bertrand Delacretaz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bertrand Delacretaz updated SLING-4318:
---
Attachment: SLING-4318-test.patch

The attached SLING-4318-test.patch provides some integration tests.

The new V selector can potentially conflict with existing user servlets, we 
might want to put the versions servlet in a different bundle or make its 
selector configurable - I'll discuss this on the dev list.

> Sling resource API does not expose any versioning features - bounty offered.
> 
>
> Key: SLING-4318
> URL: https://issues.apache.org/jira/browse/SLING-4318
> Project: Sling
>  Issue Type: New Feature
>  Components: Documentation, JCR, Servlets
>Affects Versions: Servlets Resolver 2.3.8
> Environment: N/A
>Reporter: Bruce Edge
>  Labels: api, crud, servlet-api, versioning, versions
> Attachments: SLING-4318-test.patch
>
>
> The javax.jcr.version.VersionManager is not exposed in the sling resource API:
> http://thread.gmane.org/gmane.comp.apache.sling.user/1610
> My company is interested in paying for this development. Please contact if 
> interested.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [PROPOSAL] JSNodeTypes contribution :: IP clearance needed?

[Bertrand Delacretaz]

Hi Sandro,

On Wed, Jan 28, 2015 at 5:37 PM, Sandro Boehme  wrote:
> ...If there are no objections I would commit it with SLING-4364 in the folder
> "/contrib/commons/js/nodetypes"
> with the Sling parent pom,
> the ArtifactId "org.apache.sling.commons.js.nodetypes"
> and the version "1.0.SNAPSHOT"

Works for me but maybe use 0.1.0-SNAPSHOT so that the first release can be 1.0.0

We use alternating odd/even versions so after 1.0.0 it's
1.0.1-SNAPSHOT and the next release is 1.0.2.

-Bertrand

Jenkins build is still unstable: sling-trunk-1.7 #1383

[Apache Jenkins Server]

See 

Re: [VOTE] Release Apache Sling Resource Resolver 1.1.12

[Antonio Sanso]

+1
On Jan 28, 2015, at 4:57 PM, Carsten Ziegeler  wrote:

> Hi,
> 
> we solved three issue
> https://issues.apache.org/jira/browse/SLING/fixforversion/12329309
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1178/
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1178 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ]  0 Don't care
> [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Jenkins build is still unstable: sling-trunk-1.8 #674

[Apache Jenkins Server]

See 

Jenkins build became unstable: sling-trunk-1.6 #2994

[Apache Jenkins Server]

See 

Re: [PROPOSAL] JSNodeTypes contribution :: IP clearance needed?

[Sandro Boehme]

Hi Bertrand,

thanks for your feedback, that sounds good!
If there are no objections I would commit it with SLING-4364 in the folder
"/contrib/commons/js/nodetypes"
with the Sling parent pom,
the ArtifactId "org.apache.sling.commons.js.nodetypes"
and the version "1.0.SNAPSHOT".
Does that fit in the general structure?

Best,

Sandro

Am 27.01.15 um 17:29 schrieb Bertrand Delacretaz:

Hi Sandro,

On Tue, Jan 27, 2015 at 4:51 PM, Sandro Boehme  wrote:

...Now that I'm a Committer in the meantime and I have written the JSNodeTypes
library solely on my own the question is if the IP clearance process is
still needed


IMO it's not needed in this case, committing code that you wrote
yourself is covered by your iCLA.

I suggest that you wait 24 hours for possible objections, and if
there's none go ahead and commit.

-Bertrand

[jira] [Created] (SLING-4364) Integrate new JavaScript node type library

[Sandro Boehme (JIRA)]

Sandro Boehme created SLING-4364:


 Summary: Integrate new JavaScript node type library
 Key: SLING-4364
 URL: https://issues.apache.org/jira/browse/SLING-4364
 Project: Sling
  Issue Type: New Feature
  Components: Commons
Reporter: Sandro Boehme
Assignee: Sandro Boehme


This copies the code I ([~sandro]) have written at GitHub [1] to Apache Sling 
as discussed [2] at the mailing list.

[1] - https://github.com/sandroboehme/jsNodeTypes
[2] - 
http://apache-sling.73963.n3.nabble.com/PROPOSAL-JSNodeTypes-contribution-tp4045070.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jenkins build became unstable: sling-trunk-1.7 #1382

[Apache Jenkins Server]

See 

Jenkins build became unstable: sling-trunk-1.8 #673

[Apache Jenkins Server]

See 

Re: [VOTE] Release Apache Sling Resource Resolver 1.1.12

[Carsten Ziegeler]

+1

Carsten


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Apache Sling Resource Resolver 1.1.12

[Daniel Klco]

+1
On Jan 28, 2015 4:57 PM, "Carsten Ziegeler"  wrote:

> Hi,
>
> we solved three issue
> https://issues.apache.org/jira/browse/SLING/fixforversion/12329309
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1178/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1178 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[VOTE] Release Apache Sling Resource Resolver 1.1.12

[Carsten Ziegeler]

Hi,

we solved three issue
https://issues.apache.org/jira/browse/SLING/fixforversion/12329309

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1178/

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1178 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Resolved] (SLING-4363) Unregistering a resource provider should also reregister the resource resolver factory

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-4363.
-
Resolution: Fixed

Fixed in rev 1655361

> Unregistering a resource provider should also reregister the resource 
> resolver factory
> --
>
> Key: SLING-4363
> URL: https://issues.apache.org/jira/browse/SLING-4363
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.10
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Resource Resolver 1.1.12
>
>
> Right now, only if a resource provider factory is unregistered, the resource 
> resolver factory is reregistered. This is in order to notify all clients 
> which potentially have used an instance of the provider factory and restart 
> them.
> However, if a client holds resources from an unregistered resource provider, 
> this might result in a memory leak as well, therefore we should use the same 
> mechanism and reregister the resource provider factory



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-4363) Unregistering a resource provider should also reregister the resource resolver factory

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-4363:
---

 Summary: Unregistering a resource provider should also reregister 
the resource resolver factory
 Key: SLING-4363
 URL: https://issues.apache.org/jira/browse/SLING-4363
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.10
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Resource Resolver 1.1.12


Right now, only if a resource provider factory is unregistered, the resource 
resolver factory is reregistered. This is in order to notify all clients which 
potentially have used an instance of the provider factory and restart them.
However, if a client holds resources from an unregistered resource provider, 
this might result in a memory leak as well, therefore we should use the same 
mechanism and reregister the resource provider factory



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-4361) Improve handling of unregistering ResourceProviderFactories

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-4361.
-
Resolution: Fixed

I've refactored the handling in 1655358 to use a background thread for 
coordination. When an unregistration happens, the reregistration is delayed for 
2 secs

> Improve handling of unregistering ResourceProviderFactories
> ---
>
> Key: SLING-4361
> URL: https://issues.apache.org/jira/browse/SLING-4361
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.10
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Resource Resolver 1.1.12
>
>
> Right now, if a ResourceProviderFactory is unregistered, the 
> ResourceResolverFactory is first unregistered and then registered again. This 
> is in order to clean up all usages of ResourceResolvers which might have a 
> reference to the unregistered provider factory.
> This reregistration can lead to nearly the whole system going down and up 
> again. Therefore if there are several unregistrations in a row, the system 
> might go down and up several times. If there are circular dependencies, this 
> might also result in an endless down/up loop.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4362) [jcr mocks] Resource type not correctly loaded when using jcr mock

[Nicolas Peltier (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295235#comment-14295235
 ] 

Nicolas Peltier commented on SLING-4362:


my guess here is content loader uses modifiable value map to create the 
resource that actually set the resourceType, but returns a resource based on 
the node (whose transient space is disconected from the modifiable value map's 
transient space).

> [jcr mocks] Resource type not correctly loaded when using jcr mock
> --
>
> Key: SLING-4362
> URL: https://issues.apache.org/jira/browse/SLING-4362
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing JCR Mock 1.1.2
>Reporter: Nicolas Peltier
>
> when setting resource resolver type to 
> ResourceResolverType.JCR_MOCK 
> such loaded json 
> {Code}
> {
> "jcr:primaryType":"nt:unstructured",
> "sling:resourceType": "fooType",
> "thisIs": "child"
> }
> {Code}
> to /content
> gives /content/foo a resourceType == "nt:unstructured" instead of fooType, 
> other properties (here thisIs) are correctly loaded



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-4362) [jcr mocks] Resource type not correctly loaded when using jcr mock

[Nicolas Peltier (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Peltier updated SLING-4362:
---
Description: 
when setting resource resolver type to 
ResourceResolverType.JCR_MOCK 

such loaded json 
{Code}
{
"jcr:primaryType":"nt:unstructured",
"sling:resourceType": "fooType",
"thisIs": "child"
}
{Code}
to /content
gives /content/foo a resourceType == "nt:unstructured" instead of fooType, 
other properties (here thisIs) are correctly loaded

  was:
when setting resource resolver type to 
ResourceResolverType.JCR_MOCK 

such loaded json 
{Code}
{
  "jcr:primaryType":"nt:unstructured",
  "thisIs":"root",
  "foo":{
"jcr:primaryType":"nt:unstructured",
"sling:resourceType": "fooType",
"thisIs": "child"
  }
}
{Code}
to /content
gives /content/foo a resourceType == "nt:unstructured" instead of fooType, 
other properties (here thisIs) are correctly loaded


> [jcr mocks] Resource type not correctly loaded when using jcr mock
> --
>
> Key: SLING-4362
> URL: https://issues.apache.org/jira/browse/SLING-4362
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing JCR Mock 1.1.2
>Reporter: Nicolas Peltier
>
> when setting resource resolver type to 
> ResourceResolverType.JCR_MOCK 
> such loaded json 
> {Code}
> {
> "jcr:primaryType":"nt:unstructured",
> "sling:resourceType": "fooType",
> "thisIs": "child"
> }
> {Code}
> to /content
> gives /content/foo a resourceType == "nt:unstructured" instead of fooType, 
> other properties (here thisIs) are correctly loaded



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: svn commit: r1655278 - in /sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource: Resource.java ResourceResolver.java

[Carsten Ziegeler]

> 
> Not sure what the above is supposed to mean:
> 
> The same applies in general to all objects returned by this
> instance, especially for all instances
> 
Good catch, thanks - I meant "resources". Fixed now

Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (SLING-4358) Add the 'Provide-Capability' OSGi header to the org.apache.sling.scripting.sightly bundle

[David Bosschaert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295223#comment-14295223
 ] 

David Bosschaert commented on SLING-4358:
-

It will be in Enterprise R6.

However, we can also pre-empt that with a proprietary namespace. The once the 
standard capability comes in, we can simply provide that alongside...

> Add the 'Provide-Capability' OSGi header to the 
> org.apache.sling.scripting.sightly bundle
> -
>
> Key: SLING-4358
> URL: https://issues.apache.org/jira/browse/SLING-4358
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Reporter: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.0
>
>
> The OSGi {{Provide-Capability}} \[0\] header should be added to the 
> {{org.apache.sling.scripting.sightly}} bundle to easily identify what version 
> of the Sightly specification \[1\] the bundle implements.
> \[0\] - http://wiki.osgi.org/wiki/Provide-Capability
> \[1\] - https://github.com/Adobe-Marketing-Cloud/sightly-spec/releases



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: svn commit: r1655278 - in /sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource: Resource.java ResourceResolver.java

[Robert Munteanu]

On Wed, 2015-01-28 at 12:29 +, cziege...@apache.org wrote:
> Author: cziegeler
> Date: Wed Jan 28 12:29:44 2015
> New Revision: 1655278
> 
> URL: http://svn.apache.org/r1655278
> Log:
> Clarify lifetime of resource and resource resolver objects.
> 
> Modified:
> 
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/Resource.java
> 
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java
> 
> Modified: 
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/Resource.java
> URL: 
> http://svn.apache.org/viewvc/sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/Resource.java?rev=1655278&r1=1655277&r2=1655278&view=diff
> ==
> --- 
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/Resource.java
>  (original)
> +++ 
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/Resource.java
>  Wed Jan 28 12:29:44 2015
> @@ -29,6 +29,11 @@ import aQute.bnd.annotation.ProviderType
>   * other types. A JCR based resource might support adapting to the JCR Node 
> on
>   * which the resource is based.
>   * 
> + * A Resource object is valid for as long as the
> + * ResourceResolver that provided this instance is valid. The
> + * same applies in general to all objects returned by this instance,
> + * especially those returned by a call to {@link #adaptTo(Class)}.
> + * 
>   * All implementations must support returning a value map from
>   * {@link #getValueMap()}, even if the map is empty.
>   * 
> 
> Modified: 
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java
> URL: 
> http://svn.apache.org/viewvc/sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java?rev=1655278&r1=1655277&r2=1655278&view=diff
> ==
> --- 
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java
>  (original)
> +++ 
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java
>  Wed Jan 28 12:29:44 2015
> @@ -86,6 +86,12 @@ import aQute.bnd.annotation.ProviderType
>   * To check whether a Resource Resolver can still be used, the {@link 
> #isLive()}
>   * method can be called.
>   * 
> + * A ResourceResolver is only valid for as long as the
> + * ResourceResolverFactory that created this instance exists. 
> The
> + * same applies in general to all objects returned by this instance,
> + * especially for all instances. If the ResourceResolverFactory
> + * does not exist anymore, the resource resolver instances becomes invalid.
> + * 

Not sure what the above is supposed to mean:

The same applies in general to all objects returned by this
instance, especially for all instances

Robert

[jira] [Updated] (SLING-4362) [jcr mocks] Resource type not correctly loaded when using jcr mock

[Nicolas Peltier (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Peltier updated SLING-4362:
---
Description: 
when setting resource resolver type to 
ResourceResolverType.JCR_MOCK 

such loaded json 
{Code}
{
  "jcr:primaryType":"nt:unstructured",
  "thisIs":"root",
  "foo":{
"jcr:primaryType":"nt:unstructured",
"sling:resourceType": "fooType",
"thisIs": "child"
  }
}
{Code}
to /content
gives /content/foo a resourceType == "nt:unstructured" instead of fooType, 
other properties (here thisIs) are correctly loaded

  was:
when setting resource resolver type to 
ResourceResolverType.JCR_MOCK 

such loaded json 
{Code}
{
  "jcr:primaryType":"nt:unstructured",
  "thisIs":"root",
  "foo":{
"jcr:primaryType":"nt:unstructured",
"sling:resourceType": "fooType",
"thisIs": "child"
  }
}
{Code}
to /content
gives /content/foo a resourceType == "nt:unstructured" instead of fooType


> [jcr mocks] Resource type not correctly loaded when using jcr mock
> --
>
> Key: SLING-4362
> URL: https://issues.apache.org/jira/browse/SLING-4362
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing JCR Mock 1.1.2
>Reporter: Nicolas Peltier
>
> when setting resource resolver type to 
> ResourceResolverType.JCR_MOCK 
> such loaded json 
> {Code}
> {
>   "jcr:primaryType":"nt:unstructured",
>   "thisIs":"root",
>   "foo":{
> "jcr:primaryType":"nt:unstructured",
> "sling:resourceType": "fooType",
> "thisIs": "child"
>   }
> }
> {Code}
> to /content
> gives /content/foo a resourceType == "nt:unstructured" instead of fooType, 
> other properties (here thisIs) are correctly loaded



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-4362) [jcr mocks] Resource type not correctly loaded when using jcr mock

[Nicolas Peltier (JIRA)]

Nicolas Peltier created SLING-4362:
--

 Summary: [jcr mocks] Resource type not correctly loaded when using 
jcr mock
 Key: SLING-4362
 URL: https://issues.apache.org/jira/browse/SLING-4362
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: Testing JCR Mock 1.1.2
Reporter: Nicolas Peltier


when setting resource resolver type to 
ResourceResolverType.JCR_MOCK 

such loaded json 
{Code}
{
  "jcr:primaryType":"nt:unstructured",
  "thisIs":"root",
  "foo":{
"jcr:primaryType":"nt:unstructured",
"sling:resourceType": "fooType",
"thisIs": "child"
  }
}
{Code}
to /content
gives /content/foo a resourceType == "nt:unstructured" instead of fooType



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jenkins build is back to stable : sling-trunk-1.7 #1381

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-4358) Add the 'Provide-Capability' OSGi header to the org.apache.sling.scripting.sightly bundle

[Radu Cotescu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295167#comment-14295167
 ] 

Radu Cotescu commented on SLING-4358:
-

In what release of the spec do we expect to have the namespace standardisation?

> Add the 'Provide-Capability' OSGi header to the 
> org.apache.sling.scripting.sightly bundle
> -
>
> Key: SLING-4358
> URL: https://issues.apache.org/jira/browse/SLING-4358
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Reporter: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.0
>
>
> The OSGi {{Provide-Capability}} \[0\] header should be added to the 
> {{org.apache.sling.scripting.sightly}} bundle to easily identify what version 
> of the Sightly specification \[1\] the bundle implements.
> \[0\] - http://wiki.osgi.org/wiki/Provide-Capability
> \[1\] - https://github.com/Adobe-Marketing-Cloud/sightly-spec/releases



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-4361) Improve handling of unregistering ResourceProviderFactories

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-4361:
---

 Summary: Improve handling of unregistering 
ResourceProviderFactories
 Key: SLING-4361
 URL: https://issues.apache.org/jira/browse/SLING-4361
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.10
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Resource Resolver 1.1.12


Right now, if a ResourceProviderFactory is unregistered, the 
ResourceResolverFactory is first unregistered and then registered again. This 
is in order to clean up all usages of ResourceResolvers which might have a 
reference to the unregistered provider factory.
This reregistration can lead to nearly the whole system going down and up 
again. Therefore if there are several unregistrations in a row, the system 
might go down and up several times. If there are circular dependencies, this 
might also result in an endless down/up loop.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4358) Add the 'Provide-Capability' OSGi header to the org.apache.sling.scripting.sightly bundle

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295162#comment-14295162
 ] 

Carsten Ziegeler commented on SLING-4358:
-

The OSGi CPEG is currently of specifying a namespace for exactly saying "this 
bundle implements specification XYZ in version N", maybe it makes sense to wait 
for the official namespace.
Although adding an own doesn't hurt of course

> Add the 'Provide-Capability' OSGi header to the 
> org.apache.sling.scripting.sightly bundle
> -
>
> Key: SLING-4358
> URL: https://issues.apache.org/jira/browse/SLING-4358
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Reporter: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.0
>
>
> The OSGi {{Provide-Capability}} \[0\] header should be added to the 
> {{org.apache.sling.scripting.sightly}} bundle to easily identify what version 
> of the Sightly specification \[1\] the bundle implements.
> \[0\] - http://wiki.osgi.org/wiki/Provide-Capability
> \[1\] - https://github.com/Adobe-Marketing-Cloud/sightly-spec/releases



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [RT] Sling Resource Providers for NoSQL databases - MongoDB, Couchbase

[Carsten Ziegeler]

Am 27.01.15 um 17:09 schrieb Stefan Seifert:
> we currently evaluate to integrate a Couchbase NoSQL database [1] into a 
> sling resource tree. as a starting point i had a deeper look on the MongoDB 
> resource provider [2], because the concept is quite similar.
> 
> some thoughts on this:
> 
> 1. what is the status of the mongodb provider? is someone using it already in 
> production? looking at the code it seems to be not threadsafe concerning the 
> CRUD handling with non-synchronized hash maps.

Afaik, there are people using that code slightly modified (not sure what
the changes are) in production. I think the impl is thread safe as a
resource provider by itself must not be thread safe. But if it's not, we
should fix it.

> 
> 
> 3. the resource provider mixes up the in-memory CRUD handling with keeping 
> maps of changed/deleted resources, and the mapping to the NoSQL structure. if 
> these two aspects would be separated the former could be reused for all NoSQL 
> databases and the latter is responsible only for the flat list 
> resource-to-document mapping and will be different for each NoSQL database. 
> bonus: the thread-safety of the CRUD handling has to be implemented only 
> once, not once for each resource provider.
> additional logic like type mapping values to strings, generic value map 
> implementations, automatic tree creation etc. could be shared between all 
> NoSQL providers.
> 
Yes I heard this suggestion from several people already :) So +1 for
refactoring.


> 4. an open point is whether to support binary data as well, or to leave it 
> out in the first phase. storing binary data may be problematic for some NoSQL 
> databases, requiring a separate storage concept for this. the mongodb 
> resource provider currently does not support binary data.
> 
I guess as a first step, not supporting binaries is fine.

In general it would be cool to have some more/better NoSQL support in
Sling to attract devs using these storages.

Regards
Carsten


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Jenkins build became unstable: sling-trunk-1.7 #1380

[Apache Jenkins Server]

See 

[jira] [Resolved] (SLING-4360) Mark ResourceResolver and ResourceResolverFactory as invalid if factory is unregistered

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-4360.
-
Resolution: Fixed

Solved as explained above

> Mark ResourceResolver and ResourceResolverFactory as invalid if factory is 
> unregistered
> ---
>
> Key: SLING-4360
> URL: https://issues.apache.org/jira/browse/SLING-4360
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.10
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Resource Resolver 1.1.12
>
>
> If the resource resolver factory is unregistered, the factory object itself 
> can still be used (although it might fail) and the created resource resolver 
> instances are not aware that the factory is gone either.
> We should add a marker to the factory which can be used by the resource 
> resolver in the isLive() method



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-4360) Mark ResourceResolver and ResourceResolverFactory as invalid if factory is unregistered

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-4360:
---

 Summary: Mark ResourceResolver and ResourceResolverFactory as 
invalid if factory is unregistered
 Key: SLING-4360
 URL: https://issues.apache.org/jira/browse/SLING-4360
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.10
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Resource Resolver 1.1.12


If the resource resolver factory is unregistered, the factory object itself can 
still be used (although it might fail) and the created resource resolver 
instances are not aware that the factory is gone either.
We should add a marker to the factory which can be used by the resource 
resolver in the isLive() method



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: SLING-4358 - provide/require capability, should we define a standard for capability names?

[Robert Munteanu]

Hi,

On Tue, Jan 27, 2015 at 6:33 PM, Bertrand Delacretaz
 wrote:
> Hi,
>
> By analogy with
> http://www.osgi.org/Specifications/ReferenceNamespaces, should we
> agree on a prefix such as "org.apache.sling.capability.MMM" for our
> capability names, where MMM is the module name like "sightly"?

I don't see why not, it's good to namespace them. I would be slightly
inclined to drop the 'capability' from the prefix, since it would look
a bit rendundant. Compare

   Require-Capability: org.apache.sling.capability.sightly;
filter:="(version=1.0)"

with

   Require-Capability: org.apache.sling.sightly; filter:="(version=1.0)"

Cheers,

Robert

Re: [RESULT] [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2

[Carsten Ziegeler]

Am 28.01.15 um 11:24 schrieb Carsten Ziegeler:
> Am 28.01.15 um 10:55 schrieb Stefan Seifert:
>> Hi,
>>
>> The vote has passed with the following result:
>>
>> +1 (binding): Robert Munteanu, Carsten Ziegeler, Stefan Egli
>>
>> I will promote the artifacts to the central Maven repository and update this 
>> sling site.
>>
>> @any PMC member: please copy this release to the Sling dist directory.
>>
> Will do
> 
Done


Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Jenkins build is back to stable : sling-trunk-1.7 #1378

[Apache Jenkins Server]

See 

Re: [RESULT] [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2

[Carsten Ziegeler]

Am 28.01.15 um 10:55 schrieb Stefan Seifert:
> Hi,
> 
> The vote has passed with the following result:
> 
> +1 (binding): Robert Munteanu, Carsten Ziegeler, Stefan Egli
> 
> I will promote the artifacts to the central Maven repository and update this 
> sling site.
> 
> @any PMC member: please copy this release to the Sling dist directory.
> 
Will do


Thhanks
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2

[Daniel Klco]

+1 

Sorry for the delay, been underwater lately.

> On Jan 28, 2015, at 10:36 AM, Carsten Ziegeler  wrote:
> 
>> Am 27.01.15 um 17:33 schrieb Bertrand Delacretaz:
>>> On Tue, Jan 27, 2015 at 5:15 PM, Stefan Seifert  
>>> wrote:
>>> one (binding) vote is missing...
>> 
>> it's fine for you to vote as well ;-)
> We need a third *binding* vote, and it realyl would be nice if more
> people would vote
> 
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Jenkins build is still unstable: sling-trunk-1.7 #1377

[Apache Jenkins Server]

See 

[RESULT] [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2

[Stefan Seifert]

Hi,

The vote has passed with the following result:

+1 (binding): Robert Munteanu, Carsten Ziegeler, Stefan Egli

I will promote the artifacts to the central Maven repository and update this 
sling site.

@any PMC member: please copy this release to the Sling dist directory.

stefan

[jira] [Commented] (SLING-4340) SLING-4247 created odd side-effects

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294941#comment-14294941
 ] 

Carsten Ziegeler commented on SLING-4340:
-

[~justinedelson] What about a compromise:
- we set the resource type based on Resource#getResourceType() as introduced in 
SLING-4247
- we set resource super type to sling:resourceType - if different from resource 
type

Would that help in your case?

> SLING-4247 created odd side-effects
> ---
>
> Key: SLING-4340
> URL: https://issues.apache.org/jira/browse/SLING-4340
> Project: Sling
>  Issue Type: Bug
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Resource Merger 1.2.4
>
>
> The change made in SLING-4247 created an unfortunate side effect for this 
> scenario:
> /apps/a/1/a - nt:unstructured node, no sling:resourceType property
> /apps/a/2/a - sling:resourceType set to foo/bar
> /apps/a/1 has sling:resourceSuperType set to /apps/a/2
> Then
> resourceResolver.getResource("/mnt/override/apps/a/1/a").getResourceType() 
> will be nt:unstructured
> This strikes me as wrong. And in fact screws up what is for me the main usage 
> of this feature because it shouldn't be necessary to set the 
> sling:resourceType all the time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2

[Carsten Ziegeler]

Am 27.01.15 um 17:33 schrieb Bertrand Delacretaz:
> On Tue, Jan 27, 2015 at 5:15 PM, Stefan Seifert  
> wrote:
>> one (binding) vote is missing...
> 
> it's fine for you to vote as well ;-)
> 
We need a third *binding* vote, and it realyl would be nice if more
people would vote

Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2

[Stefan Egli]

+1,
(verified md5/sha1)


Cheers,
Stefan

On 1/27/15 5:15 PM, "Stefan Seifert"  wrote:

>one (binding) vote is missing...
>
>stefan
>
>>-Original Message-
>>From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>>Sent: Thursday, January 22, 2015 10:11 PM
>>To: dev@sling.apache.org
>>Subject: [VOTE] Release Apache Sling Testing JCR Mock 1.1.2,
>>ResourceResolver
>>Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2
>>
>>Hi,
>>
>>We solved 2 issues in JCR Mock 1.1.2:
>>https://issues.apache.org/jira/browse/SLING/fixforversion/12329091
>>
>>We solved 2 issues in ResourceResolver Mock 1.1.2:
>>https://issues.apache.org/jira/browse/SLING/fixforversion/12329092
>>
>>We solved 3 issues in Sling Mock 1.1.2:
>>https://issues.apache.org/jira/browse/SLING/fixforversion/12329089
>>
>>We solved 2 issues in Sling Mock Jackrabbit 0.1.2:
>>https://issues.apache.org/jira/browse/SLING/fixforversion/12328858
>>
>>Staging repository:
>>https://repository.apache.org/content/repositories/orgapachesling-1175/
>>
>>You can use this UNIX script to download the release and verify the
>>signatures:
>>http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>>
>>Usage:
>>sh check_staged_release.sh 1175 /tmp/sling-staging
>>
>>Please vote to approve this release:
>>
>>  [ ] +1 Approve the release
>>  [ ]  0 Don't care
>>  [ ] -1 Don't release, because ...
>>
>>This majority vote is open for at least 72 hours.
>>
>>
>>stefan

[jira] [Created] (SLING-4359) LargeTopologyWithHubTest.testLargeTopologyWithHub test failure

[Stefan Egli (JIRA)]

Stefan Egli created SLING-4359:
--

 Summary: LargeTopologyWithHubTest.testLargeTopologyWithHub test 
failure
 Key: SLING-4359
 URL: https://issues.apache.org/jira/browse/SLING-4359
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Impl 1.0.12
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Impl 1.0.14


https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/1376/testReport/org.apache.sling.discovery.impl.topology/LargeTopologyWithHubTest/testLargeTopologyWithHub/

{code}
java.lang.AssertionError: expected:<101> but was:<43>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at 
org.apache.sling.discovery.impl.topology.TopologyTestHelper.assertTopologyConsistsOf(TopologyTestHelper.java:127)
at 
org.apache.sling.discovery.impl.topology.LargeTopologyWithHubTest.testLargeTopologyWithHub(LargeTopologyWithHubTest.java:84)
{code}

grepping for log.info testLargeTopologyWithHub shows :

{code}
28.01.2015 08:16:25 *INFO * [main] LargeTopologyWithHubTest: 
testLargeTopologyWithHub: checking if all connectors are registered, 
TopologyView has 47 Instances
...
28.01.2015 08:16:32 *INFO * [main] LargeTopologyWithHubTest: 
testLargeTopologyWithHub: checking if all connectors are registered, 
TopologyView has 46 Instances
...
28.01.2015 08:16:38 *INFO * [main] LargeTopologyWithHubTest: 
testLargeTopologyWithHub: checking if all connectors are registered, 
TopologyView has 45 Instances
...
28.01.2015 08:16:44 *INFO * [main] LargeTopologyWithHubTest: 
testLargeTopologyWithHub: checking if all connectors are registered, 
TopologyView has 44 Instances
{code}
basically the instances die one after each other - probably due to no longer 
sending heartbeats. I'll check



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-913) Add a cache for pre-compiled scripts

[Radu Cotescu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294895#comment-14294895
 ] 

Radu Cotescu commented on SLING-913:


Wouldn't this still need a read operation to be performed, which in this case 
would be more expensive than reading the last modified property?

> Add a cache for pre-compiled scripts
> 
>
> Key: SLING-913
> URL: https://issues.apache.org/jira/browse/SLING-913
> Project: Sling
>  Issue Type: New Feature
>  Components: Scripting
>Affects Versions: Scripting Core 2.0.2
>Reporter: Felix Meschberger
> Attachments: SLING-913.patch
>
>
> The Java Scripting API provides support for scripting langugages which may 
> precompile script source and reuse the precompiled scripts:
>   javax.script.Compilable: May be implemented by a ScriptEngine if 
> precompilation is
>   supported
>   javax.script.CompiledScript: Result of calling the Compilable.compile 
> method.
> The CompiledScript can be called to repeatedly execute the script without the 
> need for recompilation and thus for improved performance.
> The Sling Core Scripting support should make use of this functionality by 
> maintaining a cache compiled scripts with the following properties
>   * indexed by script path
>   * size limited (using LinkedHashMap overwriting the removeEldestEntry 
> method)
>   * entries are weak or soft references ot cache entries
> A cache entry consists of the following information:
>   * The CompiledScript instance
>   * The time of last compilation. this is compared to the last modification 
> time of the script to decide on whether to recompile
> We might probaly also try to add a reference to the script engine 
> implementation bundle to only use the cache entry if the bundle has not been 
> stopped since adding the cache entry
> Executing the script would then consist of the following steps:
>   1 Check the cache of precompiled scripts. if an entry exists and can be 
> used, use it
>   2. if the ScriptEngine is Compilable:
>   2a. Compile the script and add it to the cache and use it
>   2b. Otherwise have the script engine execute the script



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jenkins build became unstable: sling-trunk-1.7 #1376

[Apache Jenkins Server]

See 

Jenkins build is back to stable : sling-trunk-1.6 #2988

[Apache Jenkins Server]

See 

Jenkins build is back to stable : sling-trunk-1.8 #667

[Apache Jenkins Server]

See