date:20140818

Hi,

I'm working on various experiments (like [1]) related to continuous
deployment with Sling, and having a clearer definition of the various
roles of the content that a typical Sling applications manages would
help. I'm saying roles instead of types on purpose, to avoid
confusion with Content-Type ;-)

There's a lot of ties between this and our recent discussions about
multi-tenancy, so refining this tentative list of roles might help for
that as well.

Does this list fit with your use cases? Do people see other roles?

My context is a number of Sling instances sharing a common content repository.

Deliverable content:
Displayed on a website or mobile app for example.
Can be global, shared between a group of tenants or tenant-specific.

System content:
Defines how a specific version of the system behaves.
Multiple system versions can coexist in a shared content repository
(as we demonstrated in [1], in a limited way)

Application content:
Extensions or overrides of system content, that modify how the system behaves.
Usually tenant-specific, or maybe shared between a group of tenants

Module state content:
The typical example is workflow models and state, which is not
deliverable but persistent and might be partially shared.

Instance-specific transient content:
Transient content that's relevant to a single Sling instance. Compiled
scripts, for example.
Not needed when the Sling instance starts.

WDYT?

-Bertrand

[1] https://github.com/ArtyomStetsenko/sling-devops-experiments

Sling Request Filter filtering

2014-08-18 Thread Felix Meschberger

Hi all

I had various discussions around execution of Servlet API Filters in the Sling 
Engine.

To recap: Currently all filters are always called. The service.ranking (or 
filter.order) service registration property can be used to define the order in 
which the filters are called and the filter.scope property is required to 
indicate at what stage in the request processing a filter has to be called. See 
[1] for the full story.

Turns out, that it would be good to have some simple and global flags to 
indicate when a filter should actually be called or not. This would be similar 
to the filter mappings of traditional web applications, where filters are bound 
to URL paths and/or servlets.

So I am proposing to introduce three new service registration properties, which 
may be set on Servlet Filter services handled by the Sling Engine:

  * filter.path: The Filter is only called if the path of the
   current Resource (SlingHttpServletRequest.getResource)
   matches any of the given paths. If the property is
   not set, the filter will always be called.
  * filter.resourceType: The Filter is only called if the resourceType
   of the current Resource (SlingHttpServletRequest.getResource)
   matches any of the given resource types. If the property is
   not set, the filter will always be called.
  * filter.ignore: The Filter is never called if this property
   is set to any true.


The implementation would be as follows:

 * The FilterListEntry class is augmented with a method to verify whether to 
call the filter at all
 * The AbstractSlingFilterChain.doFilter method is augmented to call this new 
method and to not call a filter for which the match fails. A 
RequestProgressTracker entry is generated for filters not called indicating why 
it has not been called.

Further extensions could be:

  * filter.expression: some scripting expression evaluating to
a boolean. If true the filter is called.
  * Filter service implements a new interface providing an filter
expression method returning a boolean. If true the filter
is called (comparable to the option servlet).

Regards
Felix

[1] http://sling.apache.org/documentation/the-sling-engine/filters.html

Re: Sling Request Filter filtering

Hi,

On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger fmesc...@adobe.com wrote:
... * filter.resourceType: The Filter is only called if the resourceType
of the current Resource (SlingHttpServletRequest.getResource)
matches any of the given resource types...

I've long been thinking that we should allow Sling's script/servlet
resolution logic to be used for more than finding request processing
servlets.

Is it something that would apply here?

I'm not sure how that could work, but as an initial experiment we
could add a SLING-FILTER selector to the request, resolve that to a
servlet and expect that to be a Filter. And if that works define that
better as presented like this it's quite a hack ;-)

-Bertrand

Re: Sling Request Filter filtering

2014-08-18 Thread Antonio Sanso

big and fat +1 from me :)

regards

antonio
On Aug 18, 2014, at 11:23 AM, Felix Meschberger fmesc...@adobe.com wrote:

 Hi all
 
 I had various discussions around execution of Servlet API Filters in the 
 Sling Engine.
 
 To recap: Currently all filters are always called. The service.ranking (or 
 filter.order) service registration property can be used to define the order 
 in which the filters are called and the filter.scope property is required to 
 indicate at what stage in the request processing a filter has to be called. 
 See [1] for the full story.
 
 Turns out, that it would be good to have some simple and global flags to 
 indicate when a filter should actually be called or not. This would be 
 similar to the filter mappings of traditional web applications, where filters 
 are bound to URL paths and/or servlets.
 
 So I am proposing to introduce three new service registration properties, 
 which may be set on Servlet Filter services handled by the Sling Engine:
 
  * filter.path: The Filter is only called if the path of the
   current Resource (SlingHttpServletRequest.getResource)
   matches any of the given paths. If the property is
   not set, the filter will always be called.
  * filter.resourceType: The Filter is only called if the resourceType
   of the current Resource (SlingHttpServletRequest.getResource)
   matches any of the given resource types. If the property is
   not set, the filter will always be called.
  * filter.ignore: The Filter is never called if this property
   is set to any true.
 
 
 The implementation would be as follows:
 
 * The FilterListEntry class is augmented with a method to verify whether to 
 call the filter at all
 * The AbstractSlingFilterChain.doFilter method is augmented to call this new 
 method and to not call a filter for which the match fails. A 
 RequestProgressTracker entry is generated for filters not called indicating 
 why it has not been called.
 
 Further extensions could be:
 
  * filter.expression: some scripting expression evaluating to
a boolean. If true the filter is called.
  * Filter service implements a new interface providing an filter
expression method returning a boolean. If true the filter
is called (comparable to the option servlet).
 
 Regards
 Felix
 
 [1] http://sling.apache.org/documentation/the-sling-engine/filters.html

Re: Sling Request Filter filtering

2014-08-18 Thread Jeff Young

Hi Felix,

I think to reduce the unexpected you'd need filter.resourceType to match
on the resource's supertype hierarchy too.

Cheers,
Jeff.


On 18/08/2014 10:23, Felix Meschberger fmesc...@adobe.com wrote:

Hi all

I had various discussions around execution of Servlet API Filters in the
Sling Engine.

To recap: Currently all filters are always called. The service.ranking
(or filter.order) service registration property can be used to define the
order in which the filters are called and the filter.scope property is
required to indicate at what stage in the request processing a filter has
to be called. See [1] for the full story.

Turns out, that it would be good to have some simple and global flags to
indicate when a filter should actually be called or not. This would be
similar to the filter mappings of traditional web applications, where
filters are bound to URL paths and/or servlets.

So I am proposing to introduce three new service registration properties,
which may be set on Servlet Filter services handled by the Sling Engine:

  * filter.path: The Filter is only called if the path of the
   current Resource (SlingHttpServletRequest.getResource)
   matches any of the given paths. If the property is
   not set, the filter will always be called.
  * filter.resourceType: The Filter is only called if the resourceType
   of the current Resource (SlingHttpServletRequest.getResource)
   matches any of the given resource types. If the property is
   not set, the filter will always be called.
  * filter.ignore: The Filter is never called if this property
   is set to any true.


The implementation would be as follows:

 * The FilterListEntry class is augmented with a method to verify whether
to call the filter at all
 * The AbstractSlingFilterChain.doFilter method is augmented to call this
new method and to not call a filter for which the match fails. A
RequestProgressTracker entry is generated for filters not called
indicating why it has not been called.

Further extensions could be:

  * filter.expression: some scripting expression evaluating to
a boolean. If true the filter is called.
  * Filter service implements a new interface providing an filter
expression method returning a boolean. If true the filter
is called (comparable to the option servlet).

Regards
Felix

[1] http://sling.apache.org/documentation/the-sling-engine/filters.html

Re: Sling Request Filter filtering

On Mon, Aug 18, 2014 at 12:08 PM, Jeff Young j...@adobe.com wrote:
 ...I think to reduce the unexpected you'd need filter.resourceType to match
 on the resource's supertype hierarchy too...

Which is where reusing the existing script resolution logic would
help, instead of reimplementing.

-Bertrand

Re: [VOTE] Apache Sling Commons Mime 2.1.6 and Apache Sling Commons OSGi 2.2.2

Hmm, org.apache.tika.mime;resolution:=optional;version=[1.0,2)


2014-08-17 19:24 GMT+02:00 Oliver Lietz apa...@oliverlietz.de:

 On Tuesday 12 August 2014 08:37:18 Carsten Ziegeler wrote:
  Hi,
 
  in order to get Launchpad 7 out, this is a vote to release
 
  Commons Mime 2.1.6
  https://issues.apache.org/jira/browse/SLING/fixforversion/12314795
  https://issues.apache.org/jira/browse/SLING/fixforversion/12326055

 -1 as Commons Mime now depends also on Tika[1] and this should be
 reflected in
 the version

  Commons OSGi 2.2.2
  https://issues.apache.org/jira/browse/SLING/fixforversion/12323512
  https://issues.apache.org/jira/browse/SLING/fixforversion/12316095

 +1

 O.


 [1]:

 2014-08-17 17:55:24,354 | ERROR | FelixStartLevel  | mime
 | 118 - org.apache.sling.commons.mime - 2.1.6 |
 [org.apache.sling.commons.mime.internal.TikaMimeTypeProvider(21)] Error
 during
 instantiation of the implementation object
 java.lang.NoClassDefFoundError: org/apache/tika/mime/MimeTypeException
 at java.lang.Class.getDeclaredConstructors0(Native
 Method)[:1.6.0_65]
 at java.lang.Class.privateGetDeclaredConstructors(Class.java:2446)
 [:1.6.0_65]
 at java.lang.Class.getConstructor0(Class.java:2756)[:1.6.0_65]
 at java.lang.Class.newInstance0(Class.java:328)[:1.6.0_65]
 at java.lang.Class.newInstance(Class.java:310)[:1.6.0_65]
 [...]
 Caused by: java.lang.ClassNotFoundException:
 org.apache.tika.mime.MimeTypeException not found by
 org.apache.sling.commons.mime [118]
 at

 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)
 [org.apache.felix.framework-4.2.1.jar:]
 at

 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
 [org.apache.felix.framework-4.2.1.jar:]
 at

 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_65]
 ... 59 more
 2014-08-17 17:55:24,356 | ERROR | FelixStartLevel  | mime
 | 118 - org.apache.sling.commons.mime - 2.1.6 |
 [org.apache.sling.commons.mime.internal.TikaMimeTypeProvider(21)] Failed
 creating the component instance; see log for reason




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

Re: Sling Request Filter filtering

2014-08-18 Thread Felix Meschberger

Hi

Am 18.08.2014 um 12:08 schrieb Jeff Young j...@adobe.com:

 Hi Felix,
 
 I think to reduce the unexpected you'd need filter.resourceType to match
 on the resource's supertype hierarchy too.

Yeah, match could be ResourceUtil.isA(). But it should not be adding to much 
overhead for the request processing.

Regards
Felix

 
 Cheers,
 Jeff.
 
 
 On 18/08/2014 10:23, Felix Meschberger fmesc...@adobe.com wrote:
 
 Hi all
 
 I had various discussions around execution of Servlet API Filters in the
 Sling Engine.
 
 To recap: Currently all filters are always called. The service.ranking
 (or filter.order) service registration property can be used to define the
 order in which the filters are called and the filter.scope property is
 required to indicate at what stage in the request processing a filter has
 to be called. See [1] for the full story.
 
 Turns out, that it would be good to have some simple and global flags to
 indicate when a filter should actually be called or not. This would be
 similar to the filter mappings of traditional web applications, where
 filters are bound to URL paths and/or servlets.
 
 So I am proposing to introduce three new service registration properties,
 which may be set on Servlet Filter services handled by the Sling Engine:
 
 * filter.path: The Filter is only called if the path of the
  current Resource (SlingHttpServletRequest.getResource)
  matches any of the given paths. If the property is
  not set, the filter will always be called.
 * filter.resourceType: The Filter is only called if the resourceType
  of the current Resource (SlingHttpServletRequest.getResource)
  matches any of the given resource types. If the property is
  not set, the filter will always be called.
 * filter.ignore: The Filter is never called if this property
  is set to any true.
 
 
 The implementation would be as follows:
 
 * The FilterListEntry class is augmented with a method to verify whether
 to call the filter at all
 * The AbstractSlingFilterChain.doFilter method is augmented to call this
 new method and to not call a filter for which the match fails. A
 RequestProgressTracker entry is generated for filters not called
 indicating why it has not been called.
 
 Further extensions could be:
 
 * filter.expression: some scripting expression evaluating to
   a boolean. If true the filter is called.
 * Filter service implements a new interface providing an filter
   expression method returning a boolean. If true the filter
   is called (comparable to the option servlet).
 
 Regards
 Felix
 
 [1] http://sling.apache.org/documentation/the-sling-engine/filters.html

Re: Sling Request Filter filtering

2014-08-18 Thread Felix Meschberger

Hi

I am not sure, whether we should go down that route.

A filter ist something which is a cross-cutting concern that the application 
places on the request processing. As such it is transparent to the client and 
it should not be client adressable. Otherwise unexpected behaviour is 
guaranteed.

Regards
Felix

Am 18.08.2014 um 11:32 schrieb Bertrand Delacretaz bdelacre...@apache.org:

 Hi,
 
 On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger fmesc...@adobe.com 
 wrote:
 ... * filter.resourceType: The Filter is only called if the resourceType
   of the current Resource (SlingHttpServletRequest.getResource)
   matches any of the given resource types...
 
 I've long been thinking that we should allow Sling's script/servlet
 resolution logic to be used for more than finding request processing
 servlets.
 
 Is it something that would apply here?
 
 I'm not sure how that could work, but as an initial experiment we
 could add a SLING-FILTER selector to the request, resolve that to a
 servlet and expect that to be a Filter. And if that works define that
 better as presented like this it's quite a hack ;-)
 
 -Bertrand

Re: Sling Request Filter filtering

Do we really really need this? At least path based filtering can be done
with plain servlet filters already.

What are the use cases for this?

Carsten


2014-08-18 13:07 GMT+02:00 Felix Meschberger fmesc...@adobe.com:

 Hi

 I am not sure, whether we should go down that route.

 A filter ist something which is a cross-cutting concern that the
 application places on the request processing. As such it is transparent to
 the client and it should not be client adressable. Otherwise unexpected
 behaviour is guaranteed.

 Regards
 Felix

 Am 18.08.2014 um 11:32 schrieb Bertrand Delacretaz bdelacre...@apache.org
 :

  Hi,
 
  On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger fmesc...@adobe.com
 wrote:
  ... * filter.resourceType: The Filter is only called if the resourceType
of the current Resource (SlingHttpServletRequest.getResource)
matches any of the given resource types...
 
  I've long been thinking that we should allow Sling's script/servlet
  resolution logic to be used for more than finding request processing
  servlets.
 
  Is it something that would apply here?
 
  I'm not sure how that could work, but as an initial experiment we
  could add a SLING-FILTER selector to the request, resolve that to a
  servlet and expect that to be a Filter. And if that works define that
  better as presented like this it's quite a hack ;-)
 
  -Bertrand




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

[VOTE RESULT] Release Apache Sling Tenants 1.0.2

The vote passes with three binding +1 votes from Stefan Egli, Carsten
Ziegeler, and Robert Munteanu.

Carsten




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

[jira] [Closed] (SLING-3247) ClassCastException may be thrown if Session is not a JackrabbitSession


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

Carsten Ziegeler closed SLING-3247.
---


 ClassCastException may be thrown if Session is not a JackrabbitSession
 --

 Key: SLING-3247
 URL: https://issues.apache.org/jira/browse/SLING-3247
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Tenant 1.0.0
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: Tenant 1.0.2


 When mapping a ResourceResolver to a tenant and the Session backing the 
 ResourceResolver is not a JackrabbitSession, the 
 TenantAdapter.getAdapter(Session, Class?) method throws a 
 ClassCastException.
 Instead of checking for (session != null) at the beginning of the method we 
 should actually check for (session instanceof JackrabbitSession).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (SLING-3245) TenantAdapterFactory can return incorrect 'null' tenants depending on order of pathMatchers


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

Carsten Ziegeler closed SLING-3245.
---


 TenantAdapterFactory can return incorrect 'null' tenants depending on order 
 of pathMatchers
 ---

 Key: SLING-3245
 URL: https://issues.apache.org/jira/browse/SLING-3245
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Tenant 1.0.0
Reporter: Vikas Saurabh
Assignee: Felix Meschberger
Priority: Minor
 Fix For: Tenant 1.0.2

 Attachments: fix_early_tenantQuery_exit.patch


 For a case where users under /home/users/abc/tenant_name/ with an existing 
 tenant tenant_name (assuming pathMatchers have a correct regex to be matched) 
 should be identified with correct tenant without relying on order of entries 
 in pathMatchers.
 * Of course, the assumption is that pathMatchers can match a tenant name 
 uniquely
 * e.g. pathMathers={/home/users/([^/]+)/*, /home/users/abc/([^/]+)/*} 
 should work



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (SLING-3376) TenantProvider passes tenant with old state to TenantCustomizer


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

Carsten Ziegeler closed SLING-3376.
---


 TenantProvider passes tenant with old state to TenantCustomizer
 ---

 Key: SLING-3376
 URL: https://issues.apache.org/jira/browse/SLING-3376
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Tenant 1.0.0
Reporter: Roland Schaer
Assignee: Amit Gupta
Priority: Minor
 Fix For: Tenant 1.0.2

 Attachments: SLING-3376.patch


 The TenantProvider does pass a Tenant with the old state to the 
 TenantCustomizer#setup() method, making it impossible to handle changes  on 
 the update case. I would expect to have a Tenant (in a transient state) 
 passed which reflects the new state.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] Apache Sling Commons Mime 2.1.6 and Apache Sling Commons OSGi 2.2.2

Oliver, could you please revert your -1? Tika is not required and the
bundle runs without it, the Tika provider does not run, but that's
expected  - and I think this has already been the case for 2.1.4. So no new
requirements for this bundle.

Thanks
Carsten


2014-08-18 12:44 GMT+02:00 Carsten Ziegeler cziege...@apache.org:

 Hmm, org.apache.tika.mime;resolution:=optional;version=[1.0,2)


 2014-08-17 19:24 GMT+02:00 Oliver Lietz apa...@oliverlietz.de:

 On Tuesday 12 August 2014 08:37:18 Carsten Ziegeler wrote:
  Hi,
 
  in order to get Launchpad 7 out, this is a vote to release
 
  Commons Mime 2.1.6
  https://issues.apache.org/jira/browse/SLING/fixforversion/12314795
  https://issues.apache.org/jira/browse/SLING/fixforversion/12326055

 -1 as Commons Mime now depends also on Tika[1] and this should be
 reflected in
 the version

  Commons OSGi 2.2.2
  https://issues.apache.org/jira/browse/SLING/fixforversion/12323512
  https://issues.apache.org/jira/browse/SLING/fixforversion/12316095

 +1

 O.


 [1]:

 2014-08-17 17:55:24,354 | ERROR | FelixStartLevel  | mime
 | 118 - org.apache.sling.commons.mime - 2.1.6 |
 [org.apache.sling.commons.mime.internal.TikaMimeTypeProvider(21)] Error
 during
 instantiation of the implementation object
 java.lang.NoClassDefFoundError: org/apache/tika/mime/MimeTypeException
 at java.lang.Class.getDeclaredConstructors0(Native
 Method)[:1.6.0_65]
 at java.lang.Class.privateGetDeclaredConstructors(Class.java:2446)
 [:1.6.0_65]
 at java.lang.Class.getConstructor0(Class.java:2756)[:1.6.0_65]
 at java.lang.Class.newInstance0(Class.java:328)[:1.6.0_65]
 at java.lang.Class.newInstance(Class.java:310)[:1.6.0_65]
 [...]
 Caused by: java.lang.ClassNotFoundException:
 org.apache.tika.mime.MimeTypeException not found by
 org.apache.sling.commons.mime [118]
 at

 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)
 [org.apache.felix.framework-4.2.1.jar:]
 at

 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
 [org.apache.felix.framework-4.2.1.jar:]
 at

 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
 at
 java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_65]
 ... 59 more
 2014-08-17 17:55:24,356 | ERROR | FelixStartLevel  | mime
 | 118 - org.apache.sling.commons.mime - 2.1.6 |
 [org.apache.sling.commons.mime.internal.TikaMimeTypeProvider(21)] Failed
 creating the component instance; see log for reason




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




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

Re: [RT] The various roles of (multitenant) content

2014-08-18 Thread Ian Boston

Hi,
Is configuration part of application content or system content or both?

I can see that in a clustered environment you might want to have
configuration shared centrally amongst many versions of the running
application, but you might also need configuration local to a running
version, so that upgrades don't require all running instances to be
taken offline.

Best Regards
Ian


On 18 August 2014 10:12, Bertrand Delacretaz bdelacre...@apache.org wrote:
 Hi,

 I'm working on various experiments (like [1]) related to continuous
 deployment with Sling, and having a clearer definition of the various
 roles of the content that a typical Sling applications manages would
 help. I'm saying roles instead of types on purpose, to avoid
 confusion with Content-Type ;-)

 There's a lot of ties between this and our recent discussions about
 multi-tenancy, so refining this tentative list of roles might help for
 that as well.

 Does this list fit with your use cases? Do people see other roles?

 My context is a number of Sling instances sharing a common content repository.

 Deliverable content:
 Displayed on a website or mobile app for example.
 Can be global, shared between a group of tenants or tenant-specific.

 System content:
 Defines how a specific version of the system behaves.
 Multiple system versions can coexist in a shared content repository
 (as we demonstrated in [1], in a limited way)

 Application content:
 Extensions or overrides of system content, that modify how the system behaves.
 Usually tenant-specific, or maybe shared between a group of tenants

 Module state content:
 The typical example is workflow models and state, which is not
 deliverable but persistent and might be partially shared.

 Instance-specific transient content:
 Transient content that's relevant to a single Sling instance. Compiled
 scripts, for example.
 Not needed when the Sling instance starts.

 WDYT?

 -Bertrand

 [1] https://github.com/ArtyomStetsenko/sling-devops-experiments

Re: [RT] The various roles of (multitenant) content

Hi,

On Mon, Aug 18, 2014 at 2:56 PM, Ian Boston i...@tfd.co.uk wrote:
...
 Is configuration part of application content or system content or both?
...

We probably need a more fine-grained definition for configs - for now
I see the following types of configuration:

a) Global system-level config, like the URL of a remote logging
server. This can be either pure OSGi configs or based on shared
repository content with suitable access control.

b) Version-specific system config, where Sling instances that run the
same version of system and application code share the same config.
Also manageable in the content repository with access control.

c) Application or tenant-specific config. Using non-OSGi configs which
are just content in the repository, picked up on the fly by services
that process a tenant-specific request, works. But I don't think we
currently have a solution for tenant-specific configuration of OSGi
services, unless the services are specifically designed for that.

So I'd say with our current installer there is configuration both in
system and application content. and tenant-specific configurations
require specific code for now.

-Bertrand

[jira] [Commented] (SLING-3848) JcrNodeResource takes too long and initializes too much too soon


[ 
https://issues.apache.org/jira/browse/SLING-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100694#comment-14100694
 ] 

Carsten Ziegeler commented on SLING-3848:
-

I've applied the api patch in rev 1618601, I've also increased the package 
export for the resource package

 JcrNodeResource takes too long and initializes too much too soon
 

 Key: SLING-3848
 URL: https://issues.apache.org/jira/browse/SLING-3848
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Rob Ryan
Assignee: Carsten Ziegeler
 Fix For: JCR Resource 2.3.8, API 2.7.2

 Attachments: sling.api.diff, sling.jcr.resource.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.JcrNodeResource(ResourceResolver,
  Node, ClassLoader) taking  more than 20% of time used. The majority of this 
 time was spent in setting the resource metadata and to a lesser extent the 
 resource type.
 Because the metadata especially is not often accessed and even the resource 
 type is not always accessed, delaying these initializations led to a 
 noticeable performance improvement.
 The attached patch delays resourcetype lookup and metadata lookups until 
 needed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3848) JcrNodeResource takes too long and initializes too much too soon

2014-08-18 Thread Felix Meschberger (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100727#comment-14100727
 ] 

Felix Meschberger commented on SLING-3848:
--

One noticeable improvement in the resource type access would be to access the 
jcr:primaryType property directly instead of getting the primary node type and 
converting to a string:

{code}
node.getProperty(jcr:primaryType).getString()
{code}

 JcrNodeResource takes too long and initializes too much too soon
 

 Key: SLING-3848
 URL: https://issues.apache.org/jira/browse/SLING-3848
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Rob Ryan
Assignee: Carsten Ziegeler
 Fix For: JCR Resource 2.3.8, API 2.7.2

 Attachments: sling.api.diff, sling.jcr.resource.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.JcrNodeResource(ResourceResolver,
  Node, ClassLoader) taking  more than 20% of time used. The majority of this 
 time was spent in setting the resource metadata and to a lesser extent the 
 resource type.
 Because the metadata especially is not often accessed and even the resource 
 type is not always accessed, delaying these initializations led to a 
 noticeable performance improvement.
 The attached patch delays resourcetype lookup and metadata lookups until 
 needed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Jenkins build is still unstable: sling-trunk-1.8 » Apache Sling Launchpad Testing #41

See 
https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.launchpad.testing/41/

Jenkins build is back to stable : sling-trunk-1.8 » Apache Sling Pax Exam Utilities #41

See 
https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.paxexam.util/41/

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

See https://builds.apache.org/job/sling-trunk-1.8/changes

[jira] [Commented] (SLING-3848) JcrNodeResource takes too long and initializes too much too soon


[ 
https://issues.apache.org/jira/browse/SLING-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100743#comment-14100743
 ] 

Carsten Ziegeler commented on SLING-3848:
-

Thanks Felix, I'll add this to the patch

 JcrNodeResource takes too long and initializes too much too soon
 

 Key: SLING-3848
 URL: https://issues.apache.org/jira/browse/SLING-3848
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Rob Ryan
Assignee: Carsten Ziegeler
 Fix For: JCR Resource 2.3.8, API 2.7.2

 Attachments: sling.api.diff, sling.jcr.resource.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.JcrNodeResource(ResourceResolver,
  Node, ClassLoader) taking  more than 20% of time used. The majority of this 
 time was spent in setting the resource metadata and to a lesser extent the 
 resource type.
 Because the metadata especially is not often accessed and even the resource 
 type is not always accessed, delaying these initializations led to a 
 noticeable performance improvement.
 The attached patch delays resourcetype lookup and metadata lookups until 
 needed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Sling Request Filter filtering

2014-08-18 Thread Justin Edelson

Hi,

On Mon, Aug 18, 2014 at 1:30 PM, Dominik Süß dominik.su...@gmail.com wrote:
 Hi Felix,

 you probably remember our discussion - I checked and found out that
 resourceresolution is done with adminsession anyways and superTypeHierarchy
 being cached (at least from what I remember) therefore this shouldn't add
 much overhead.

 IMHO an important point is that it needs to be possible to add rules
 without deployment. What I have in mind is some kind of blacklisting of
 filters that by accident act in a situation where they shouldn't. In an
 ideal world a dev directly can fix that, in reallity the filter might be
 owned by a third party and cannot be directly fixed and therefore be a
 blocker.

Assuming this is all done by service registration properties, it is
all configurable. Just set the filter.ignore property to true. Whether
or not this counts as a deployment is up to you I suppose :)

Regards,
Justin


 Cheers
 Dominik


 On Mon, Aug 18, 2014 at 1:06 PM, Felix Meschberger fmesc...@adobe.com
 wrote:

 Hi

 Am 18.08.2014 um 12:08 schrieb Jeff Young j...@adobe.com:

  Hi Felix,
 
  I think to reduce the unexpected you'd need filter.resourceType to match
  on the resource's supertype hierarchy too.

 Yeah, match could be ResourceUtil.isA(). But it should not be adding to
 much overhead for the request processing.

 Regards
 Felix

 
  Cheers,
  Jeff.
 
 
  On 18/08/2014 10:23, Felix Meschberger fmesc...@adobe.com wrote:
 
  Hi all
 
  I had various discussions around execution of Servlet API Filters in the
  Sling Engine.
 
  To recap: Currently all filters are always called. The service.ranking
  (or filter.order) service registration property can be used to define
 the
  order in which the filters are called and the filter.scope property is
  required to indicate at what stage in the request processing a filter
 has
  to be called. See [1] for the full story.
 
  Turns out, that it would be good to have some simple and global flags to
  indicate when a filter should actually be called or not. This would be
  similar to the filter mappings of traditional web applications, where
  filters are bound to URL paths and/or servlets.
 
  So I am proposing to introduce three new service registration
 properties,
  which may be set on Servlet Filter services handled by the Sling Engine:
 
  * filter.path: The Filter is only called if the path of the
   current Resource (SlingHttpServletRequest.getResource)
   matches any of the given paths. If the property is
   not set, the filter will always be called.
  * filter.resourceType: The Filter is only called if the resourceType
   of the current Resource (SlingHttpServletRequest.getResource)
   matches any of the given resource types. If the property is
   not set, the filter will always be called.
  * filter.ignore: The Filter is never called if this property
   is set to any true.
 
 
  The implementation would be as follows:
 
  * The FilterListEntry class is augmented with a method to verify whether
  to call the filter at all
  * The AbstractSlingFilterChain.doFilter method is augmented to call this
  new method and to not call a filter for which the match fails. A
  RequestProgressTracker entry is generated for filters not called
  indicating why it has not been called.
 
  Further extensions could be:
 
  * filter.expression: some scripting expression evaluating to
a boolean. If true the filter is called.
  * Filter service implements a new interface providing an filter
expression method returning a boolean. If true the filter
is called (comparable to the option servlet).
 
  Regards
  Felix
 
  [1] http://sling.apache.org/documentation/the-sling-engine/filters.html

Re: [RT] The various roles of (multitenant) content

2014-08-18 Thread Ruben Reusser

looking at this it seems the same functionality would be handy for 
feature flags, no?


Ruben

On 8/18/2014 6:19 AM, Bertrand Delacretaz wrote:

Hi,

On Mon, Aug 18, 2014 at 2:56 PM, Ian Boston i...@tfd.co.uk wrote:
...

Is configuration part of application content or system content or both?

...

We probably need a more fine-grained definition for configs - for now
I see the following types of configuration:

a) Global system-level config, like the URL of a remote logging
server. This can be either pure OSGi configs or based on shared
repository content with suitable access control.

b) Version-specific system config, where Sling instances that run the
same version of system and application code share the same config.
Also manageable in the content repository with access control.

c) Application or tenant-specific config. Using non-OSGi configs which
are just content in the repository, picked up on the fly by services
that process a tenant-specific request, works. But I don't think we
currently have a solution for tenant-specific configuration of OSGi
services, unless the services are specifically designed for that.

So I'd say with our current installer there is configuration both in
system and application content. and tenant-specific configurations
require specific code for now.

-Bertrand

Re: Sling Request Filter filtering

2014-08-18 Thread Dominik Süß

Hi Carsten,

I've played around with filters a lot and the problem with them really is
that they often have way to much impact and are not constrainted as they
would need to be. Even those filters skipping often create a lot of
overhead because they do not skip fast and with cheap evaluations but
instanciate expensive objects and so on.

Therefore some easy but well performing mechanisms to perform checks in
first place would really help to avoid uncessary overhead in the request
livecycle.

Additionally the option to block filters in specific cases without
deployment would be really something that would help a lot in production
where waiting for some vendor to fix a filter might take way to long ;)

Cheers
Dominik

On Mon, Aug 18, 2014 at 1:17 PM, Carsten Ziegeler cziege...@apache.org
wrote:

 Do we really really need this? At least path based filtering can be done
 with plain servlet filters already.

 What are the use cases for this?

 Carsten


 2014-08-18 13:07 GMT+02:00 Felix Meschberger fmesc...@adobe.com:

  Hi
 
  I am not sure, whether we should go down that route.
 
  A filter ist something which is a cross-cutting concern that the
  application places on the request processing. As such it is transparent
 to
  the client and it should not be client adressable. Otherwise unexpected
  behaviour is guaranteed.
 
  Regards
  Felix
 
  Am 18.08.2014 um 11:32 schrieb Bertrand Delacretaz 
 bdelacre...@apache.org
  :
 
   Hi,
  
   On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger 
 fmesc...@adobe.com
  wrote:
   ... * filter.resourceType: The Filter is only called if the
 resourceType
 of the current Resource (SlingHttpServletRequest.getResource)
 matches any of the given resource types...
  
   I've long been thinking that we should allow Sling's script/servlet
   resolution logic to be used for more than finding request processing
   servlets.
  
   Is it something that would apply here?
  
   I'm not sure how that could work, but as an initial experiment we
   could add a SLING-FILTER selector to the request, resolve that to a
   servlet and expect that to be a Filter. And if that works define that
   better as presented like this it's quite a hack ;-)
  
   -Bertrand
 
 


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

Re: Sling Request Filter filtering

2014-08-18 Thread Dominik Süß

Hi Justin,
I'm not talking about global disable because the filter often is extremely
necessary but to be able to disable it for dedicated cases. I just remember
some obscure ColumnControlFilter only checking for the Pathending colctrl
and autorewriting the node underneath. Turning off that filter would break
a lot of funcitonality but it did mess around with nodes with a specific
resourcetype, so I was missing an option to deactivate it for this very
specific resourceType.

Best regards
Dominik


On Mon, Aug 18, 2014 at 7:33 PM, Justin Edelson jus...@justinedelson.com
wrote:

 Hi,

 On Mon, Aug 18, 2014 at 1:30 PM, Dominik Süß dominik.su...@gmail.com
 wrote:
  Hi Felix,
 
  you probably remember our discussion - I checked and found out that
  resourceresolution is done with adminsession anyways and
 superTypeHierarchy
  being cached (at least from what I remember) therefore this shouldn't add
  much overhead.
 
  IMHO an important point is that it needs to be possible to add rules
  without deployment. What I have in mind is some kind of blacklisting of
  filters that by accident act in a situation where they shouldn't. In an
  ideal world a dev directly can fix that, in reallity the filter might be
  owned by a third party and cannot be directly fixed and therefore be a
  blocker.

 Assuming this is all done by service registration properties, it is
 all configurable. Just set the filter.ignore property to true. Whether
 or not this counts as a deployment is up to you I suppose :)

 Regards,
 Justin

 
  Cheers
  Dominik
 
 
  On Mon, Aug 18, 2014 at 1:06 PM, Felix Meschberger fmesc...@adobe.com
  wrote:
 
  Hi
 
  Am 18.08.2014 um 12:08 schrieb Jeff Young j...@adobe.com:
 
   Hi Felix,
  
   I think to reduce the unexpected you'd need filter.resourceType to
 match
   on the resource's supertype hierarchy too.
 
  Yeah, match could be ResourceUtil.isA(). But it should not be adding to
  much overhead for the request processing.
 
  Regards
  Felix
 
  
   Cheers,
   Jeff.
  
  
   On 18/08/2014 10:23, Felix Meschberger fmesc...@adobe.com wrote:
  
   Hi all
  
   I had various discussions around execution of Servlet API Filters in
 the
   Sling Engine.
  
   To recap: Currently all filters are always called. The
 service.ranking
   (or filter.order) service registration property can be used to define
  the
   order in which the filters are called and the filter.scope property
 is
   required to indicate at what stage in the request processing a filter
  has
   to be called. See [1] for the full story.
  
   Turns out, that it would be good to have some simple and global
 flags to
   indicate when a filter should actually be called or not. This would
 be
   similar to the filter mappings of traditional web applications, where
   filters are bound to URL paths and/or servlets.
  
   So I am proposing to introduce three new service registration
  properties,
   which may be set on Servlet Filter services handled by the Sling
 Engine:
  
   * filter.path: The Filter is only called if the path of the
current Resource (SlingHttpServletRequest.getResource)
matches any of the given paths. If the property is
not set, the filter will always be called.
   * filter.resourceType: The Filter is only called if the resourceType
of the current Resource (SlingHttpServletRequest.getResource)
matches any of the given resource types. If the property is
not set, the filter will always be called.
   * filter.ignore: The Filter is never called if this property
is set to any true.
  
  
   The implementation would be as follows:
  
   * The FilterListEntry class is augmented with a method to verify
 whether
   to call the filter at all
   * The AbstractSlingFilterChain.doFilter method is augmented to call
 this
   new method and to not call a filter for which the match fails. A
   RequestProgressTracker entry is generated for filters not called
   indicating why it has not been called.
  
   Further extensions could be:
  
   * filter.expression: some scripting expression evaluating to
 a boolean. If true the filter is called.
   * Filter service implements a new interface providing an filter
 expression method returning a boolean. If true the filter
 is called (comparable to the option servlet).
  
   Regards
   Felix
  
   [1]
 http://sling.apache.org/documentation/the-sling-engine/filters.html

Re: Sling Request Filter filtering

Well, so the main argument is badly written code?


2014-08-18 19:35 GMT+02:00 Dominik Süß dominik.su...@gmail.com:

 Hi Carsten,

 I've played around with filters a lot and the problem with them really is
 that they often have way to much impact and are not constrainted as they
 would need to be. Even those filters skipping often create a lot of
 overhead because they do not skip fast and with cheap evaluations but
 instanciate expensive objects and so on.

 Therefore some easy but well performing mechanisms to perform checks in
 first place would really help to avoid uncessary overhead in the request
 livecycle.

 Additionally the option to block filters in specific cases without
 deployment would be really something that would help a lot in production
 where waiting for some vendor to fix a filter might take way to long ;)

 Cheers
 Dominik

 On Mon, Aug 18, 2014 at 1:17 PM, Carsten Ziegeler cziege...@apache.org
 wrote:

  Do we really really need this? At least path based filtering can be done
  with plain servlet filters already.
 
  What are the use cases for this?
 
  Carsten
 
 
  2014-08-18 13:07 GMT+02:00 Felix Meschberger fmesc...@adobe.com:
 
   Hi
  
   I am not sure, whether we should go down that route.
  
   A filter ist something which is a cross-cutting concern that the
   application places on the request processing. As such it is transparent
  to
   the client and it should not be client adressable. Otherwise unexpected
   behaviour is guaranteed.
  
   Regards
   Felix
  
   Am 18.08.2014 um 11:32 schrieb Bertrand Delacretaz 
  bdelacre...@apache.org
   :
  
Hi,
   
On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger 
  fmesc...@adobe.com
   wrote:
... * filter.resourceType: The Filter is only called if the
  resourceType
  of the current Resource (SlingHttpServletRequest.getResource)
  matches any of the given resource types...
   
I've long been thinking that we should allow Sling's script/servlet
resolution logic to be used for more than finding request processing
servlets.
   
Is it something that would apply here?
   
I'm not sure how that could work, but as an initial experiment we
could add a SLING-FILTER selector to the request, resolve that to a
servlet and expect that to be a Filter. And if that works define that
better as presented like this it's quite a hack ;-)
   
-Bertrand
  
  
 
 
  --
  Carsten Ziegeler
  Adobe Research Switzerland
  cziege...@apache.org
 




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

[jira] [Commented] (SLING-3848) JcrNodeResource takes too long and initializes too much too soon


[ 
https://issues.apache.org/jira/browse/SLING-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101244#comment-14101244
 ] 

Carsten Ziegeler commented on SLING-3848:
-

Thanks for your patch to the jcr resource bundle, Rob. I've applied a slightly 
modified version in rev 1618724:
- the resource metadata is always required, so I moved it's creation into the 
constructor
- I think in 99% of the cases getResourceType() is called, therefore I moved 
this to the constructor as well

[~fmeschbe] node.getProperty(jcr:primaryType).getString() resulted in an NPE 
for the integration tests, so apparently getProperty() returned null - which 
might be a temporary bug of the jackrabbit version used for testing. I'll have 
to investigate

 JcrNodeResource takes too long and initializes too much too soon
 

 Key: SLING-3848
 URL: https://issues.apache.org/jira/browse/SLING-3848
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Rob Ryan
Assignee: Carsten Ziegeler
 Fix For: JCR Resource 2.3.8, API 2.7.2

 Attachments: sling.api.diff, sling.jcr.resource.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.JcrNodeResource(ResourceResolver,
  Node, ClassLoader) taking  more than 20% of time used. The majority of this 
 time was spent in setting the resource metadata and to a lesser extent the 
 resource type.
 Because the metadata especially is not often accessed and even the resource 
 type is not always accessed, delaying these initializations led to a 
 noticeable performance improvement.
 The attached patch delays resourcetype lookup and metadata lookups until 
 needed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3848) JcrNodeResource takes too long and initializes too much too soon

2014-08-18 Thread Rob Ryan (JIRA)

[
https://issues.apache.org/jira/browse/SLING-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101298#comment-14101298
]

Rob Ryan commented on SLING-3848:
-

[~cziegeler] Thanks for the quick action.

WRT your comment about 99 % of cases resourceType always being needed was
contradicted by my experience. Consider Resolver.map() where each path up to
the root would be resolvedwhen all it needed from each level was the
sling:alias. In that case resourceType was irrelevant and in our use case
Resolver,map() was consuming significant CPU due to that loop. There is a
separate fix for that leveraging [~asanso]'s work on vanity paths and aliases,
but his work has to be disabled if there any many aliases or vanity paths...
That wasn't the only place experiencing the cost of instantiating resources,
but it is suggestive that there may be other places where resources are created
when only limited data is needed. Bear in mind that our use case is *not*
primarily sling render driven.

it take me awhile to get to it, but I'll re-verify. I expect to find that the
initialization of resourceType in the constructor will show to have a
noticeable impact. I'll check also whether delayed initialization is
significantly different than Felix's optimization.

JcrNodeResource takes too long and initializes too much too soon

Key: SLING-3848
URL: https://issues.apache.org/jira/browse/SLING-3848
Project: Sling
Issue Type: Improvement
Components: JCR
Reporter: Rob Ryan
Assignee: Carsten Ziegeler
Fix For: JCR Resource 2.3.8, API 2.7.2

Attachments: sling.api.diff, sling.jcr.resource.diff

In a performance test expected to reflect reasonably real-world conditions
(50 concurrent users of a mixed load 'forum' type application) I found
org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.JcrNodeResource(ResourceResolver,
Node, ClassLoader) taking more than 20% of time used. The majority of this
time was spent in setting the resource metadata and to a lesser extent the
resource type.
Because the metadata especially is not often accessed and even the resource
type is not always accessed, delaying these initializations led to a
noticeable performance improvement.
The attached patch delays resourcetype lookup and metadata lookups until
needed.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] Apache Sling Commons Mime 2.1.6 and Apache Sling Commons OSGi 2.2.2

2014-08-18 Thread Oliver Lietz

On Monday 18 August 2014 13:38:15 Carsten Ziegeler wrote:
 Oliver, could you please revert your -1? Tika is not required and the
 bundle runs without it, the Tika provider does not run, but that's
 expected  - and I think this has already been the case for 2.1.4. So no new
 requirements for this bundle.

There is a problem with 2.1.6 as it throws the exception when running the 
tests for Karaf - but I withdraw my vote as I do currently have no time to 
investigate further.

O.

 Thanks
 Carsten
 
 2014-08-18 12:44 GMT+02:00 Carsten Ziegeler cziege...@apache.org:
  Hmm, org.apache.tika.mime;resolution:=optional;version=[1.0,2)
  
  
  2014-08-17 19:24 GMT+02:00 Oliver Lietz apa...@oliverlietz.de:
  
  On Tuesday 12 August 2014 08:37:18 Carsten Ziegeler wrote:
   Hi,
   
   in order to get Launchpad 7 out, this is a vote to release
   
   Commons Mime 2.1.6
   https://issues.apache.org/jira/browse/SLING/fixforversion/12314795
   https://issues.apache.org/jira/browse/SLING/fixforversion/12326055
  
  -1 as Commons Mime now depends also on Tika[1] and this should be
  reflected in
  the version
  
   Commons OSGi 2.2.2
   https://issues.apache.org/jira/browse/SLING/fixforversion/12323512
   https://issues.apache.org/jira/browse/SLING/fixforversion/12316095
  
  +1
  
  O.
  
  
  [1]:
  
  2014-08-17 17:55:24,354 | ERROR | FelixStartLevel  | mime
  
  | 118 - org.apache.sling.commons.mime - 2.1.6 |
  
  [org.apache.sling.commons.mime.internal.TikaMimeTypeProvider(21)] Error
  during
  instantiation of the implementation object
  java.lang.NoClassDefFoundError: org/apache/tika/mime/MimeTypeException
  
  at java.lang.Class.getDeclaredConstructors0(Native
  
  Method)[:1.6.0_65]
  
  at
  java.lang.Class.privateGetDeclaredConstructors(Class.java:2446)
  
  [:1.6.0_65]
  
  at java.lang.Class.getConstructor0(Class.java:2756)[:1.6.0_65]
  at java.lang.Class.newInstance0(Class.java:328)[:1.6.0_65]
  at java.lang.Class.newInstance(Class.java:310)[:1.6.0_65]
  
  [...]
  Caused by: java.lang.ClassNotFoundException:
  org.apache.tika.mime.MimeTypeException not found by
  org.apache.sling.commons.mime [118]
  
  at
  
  org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegat
  ion(BundleWiringImpl.java:1532) [org.apache.felix.framework-4.2.1.jar:]
  
  at
  
  org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.
  java:75) [org.apache.felix.framework-4.2.1.jar:]
  
  at
  
  org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(
  BundleWiringImpl.java:1955)
  
  at
  
  java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_65]
  
  ... 59 more
  
  2014-08-17 17:55:24,356 | ERROR | FelixStartLevel  | mime
  
  | 118 - org.apache.sling.commons.mime - 2.1.6 |
  
  [org.apache.sling.commons.mime.internal.TikaMimeTypeProvider(21)] Failed
  creating the component instance; see log for reason
  
  --
  Carsten Ziegeler
  Adobe Research Switzerland
  cziege...@apache.org

Re: [VOTE] Apache Sling Commons Mime 2.1.6 and Apache Sling Commons OSGi 2.2.2

2014-08-18 Thread Oliver Lietz

On Monday 18 August 2014 23:21:44 Oliver Lietz wrote:
 On Monday 18 August 2014 13:38:15 Carsten Ziegeler wrote:
  Oliver, could you please revert your -1? Tika is not required and the
  bundle runs without it, the Tika provider does not run, but that's
  expected  - and I think this has already been the case for 2.1.4. So no
  new requirements for this bundle.

The optional Tika import is new in 2.1.6. Maybe missing Tika can be handled 
more gracefully?

O.

 There is a problem with 2.1.6 as it throws the exception when running the
 tests for Karaf - but I withdraw my vote as I do currently have no time to
 investigate further.
 
 O.
 
  Thanks
  Carsten
  
  2014-08-18 12:44 GMT+02:00 Carsten Ziegeler cziege...@apache.org:
   Hmm, org.apache.tika.mime;resolution:=optional;version=[1.0,2)
   
   
   2014-08-17 19:24 GMT+02:00 Oliver Lietz apa...@oliverlietz.de:
   
   On Tuesday 12 August 2014 08:37:18 Carsten Ziegeler wrote:
Hi,

in order to get Launchpad 7 out, this is a vote to release

Commons Mime 2.1.6
https://issues.apache.org/jira/browse/SLING/fixforversion/12314795
https://issues.apache.org/jira/browse/SLING/fixforversion/12326055
   
   -1 as Commons Mime now depends also on Tika[1] and this should be
   reflected in
   the version
   
Commons OSGi 2.2.2
https://issues.apache.org/jira/browse/SLING/fixforversion/12323512
https://issues.apache.org/jira/browse/SLING/fixforversion/12316095
   
   +1
   
   O.
   
   
   [1]:
   
   2014-08-17 17:55:24,354 | ERROR | FelixStartLevel  | mime
   
   | 118 - org.apache.sling.commons.mime - 2.1.6 |
   
   [org.apache.sling.commons.mime.internal.TikaMimeTypeProvider(21)]
   Error during
   instantiation of the implementation object
   java.lang.NoClassDefFoundError: org/apache/tika/mime/MimeTypeException
   
   at java.lang.Class.getDeclaredConstructors0(Native
   
   Method)[:1.6.0_65]
   
   at
   java.lang.Class.privateGetDeclaredConstructors(Class.java:2446
   )
   
   [:1.6.0_65]
   
   at java.lang.Class.getConstructor0(Class.java:2756)[:1.6.0_65]
   at java.lang.Class.newInstance0(Class.java:328)[:1.6.0_65]
   at java.lang.Class.newInstance(Class.java:310)[:1.6.0_65]
   
   [...]
   Caused by: java.lang.ClassNotFoundException:
   org.apache.tika.mime.MimeTypeException not found by
   org.apache.sling.commons.mime [118]
   
   at
   
   org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDeleg
   at ion(BundleWiringImpl.java:1532)
   [org.apache.felix.framework-4.2.1.jar:]
   
   at
   
   org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImp
   l. java:75) [org.apache.felix.framework-4.2.1.jar:]
   
   at
   
   org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClas
   s( BundleWiringImpl.java:1955)
   
   at
   
   java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_65]
   
   ... 59 more
   
   2014-08-17 17:55:24,356 | ERROR | FelixStartLevel  | mime
   
   | 118 - org.apache.sling.commons.mime - 2.1.6 |
   
   [org.apache.sling.commons.mime.internal.TikaMimeTypeProvider(21)]
   Failed creating the component instance; see log for reason
   
   --
   Carsten Ziegeler
   Adobe Research Switzerland
   cziege...@apache.org

Build failed in Jenkins: sling-trunk-1.8 #42

See https://builds.apache.org/job/sling-trunk-1.8/42/

--
[...truncated 226 lines...]
at 
org.tmatesoft.svn.core.internal.util.SVNSocketFactory.createPlainSocket(SVNSocketFactory.java:73)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.connect(HTTPConnection.java:280)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:451)
... 35 more
ERROR: Subversion update failed
java.io.IOException: remote file operation failed: 
https://builds.apache.org/job/sling-trunk-1.8/ws/ at 
hudson.remoting.Channel@6f0a1dfe:ubuntu-5
at hudson.FilePath.act(FilePath.java:910)
at hudson.FilePath.act(FilePath.java:887)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:936)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:871)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
at hudson.model.Run.execute(Run.java:1676)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:529)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: java.io.IOException
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:211)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2462)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: hudson.scm.subversion.UpdaterException: failed to perform svn update
... 14 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS 
/repos/asf/sling/trunk failed
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148)
at 
org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339)
at 
org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at

Build failed in Jenkins: sling-trunk-1.6 #2379

See https://builds.apache.org/job/sling-trunk-1.6/2379/

--
[...truncated 211 lines...]
Caused by: svn: E175002: timed out waiting for server
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:514)
... 35 more
Caused by: java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at 
org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
... 4 more
java.io.IOException: remote file operation failed: 
https://builds.apache.org/job/sling-trunk-1.6/ws/ at 
hudson.remoting.Channel@6f0a1dfe:ubuntu-5
at hudson.FilePath.act(FilePath.java:910)
at hudson.FilePath.act(FilePath.java:887)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:936)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:871)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
at hudson.model.Run.execute(Run.java:1676)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:529)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: java.io.IOException: Failed to check out 
http://svn.apache.org/repos/asf/sling/trunk
at 
hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:110)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:169)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:133)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2462)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS 
/repos/asf/sling/trunk failed
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)
at 
org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480)
at 
org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833)
at 
org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doCheckout(SVNUpdateClient16.java:875)
at

Re: [VOTE] Apache Sling Commons Mime 2.1.6 and Apache Sling Commons OSGi 2.2.2